| /linux-6.15/drivers/net/fddi/skfp/h/ |
| H A D | smt.h | 110 #define SMTSETPARA(p,t) (p)->para.p_type = (t),\ 111 (p)->para.p_len = sizeof(*(p)) - PARA_LEN 120 struct smt_para para ; /* generic parameter header */ member 135 struct smt_para para ; /* generic parameter header */ member 149 struct smt_para para ; /* generic parameter header */ member 171 struct smt_para para ; /* generic parameter header */ member 182 struct smt_para para ; /* generic parameter header */ member 199 struct smt_para para ; /* generic parameter header */ member 213 struct smt_para para ; /* generic parameter header */ member 262 struct smt_para para ; /* generic parameter header */ member [all …]
|
| /linux-6.15/drivers/net/fddi/skfp/ |
| H A D | ess.c | 497 chg->s_type.para.p_type = SMT_P0015 ; in ess_send_response() 502 chg->cmd.para.p_type = SMT_P0016 ; in ess_send_response() 507 chg->path.para.p_type = SMT_P320B ; in ess_send_response() 527 chg->cat.para.p_type = SMT_P001A ; in ess_send_response() 588 req->s_type.para.p_type = SMT_P0015 ; in ess_send_alc_req() 593 req->cmd.para.p_type = SMT_P0016 ; in ess_send_alc_req() 603 req->path.para.p_type = SMT_P320B ; in ess_send_alc_req() 610 req->pl_req.para.p_type = SMT_P0017 ; in ess_send_alc_req() 640 req->cat.para.p_type = SMT_P001A ; in ess_send_alc_req() 645 req->tneg.para.p_type = SMT_P001B ; in ess_send_alc_req() [all …]
|
| /linux-6.15/include/uapi/linux/ |
| H A D | virtio_crypto.h | 107 struct virtio_crypto_cipher_session_para para; member 132 struct virtio_crypto_hash_session_para para; member 162 struct virtio_crypto_mac_session_para para; member 184 struct virtio_crypto_aead_session_para para; member 236 struct virtio_crypto_akcipher_session_para para; member 401 struct virtio_crypto_cipher_para para; member 407 struct virtio_crypto_hash_para para; member 413 struct virtio_crypto_mac_para para; member 440 struct virtio_crypto_alg_chain_data_para para; member 457 struct virtio_crypto_aead_para para; member [all …]
|
| /linux-6.15/Documentation/translations/sp_SP/process/ |
| H A D | maintainer-kvm-x86.rst | 33 Por lo general, las correcciones para el ciclo en curso se aplican 67 ventana de fusión, por ejemplo, la semana siguiente a rc7 para las 74 suave alrededor de rc6 para correcciones (para la próxima versión; fíjese 75 más arriba para las correcciones dirigidas a la versión actual). 149 exportaciones de KVM para reforzar esto). 230 razón para hacerlo. 294 para KVM_INTEL=m KVM_AMD=m, y KVM_WERROR=y. Construir todas las 339 soporte para un a través de KVM_GET_SUPPORTED_CPUID, es decir, para 341 para las que no existe una verdadera habilitación. 395 valioso para futuros lectores. [all …]
|
| H A D | email-clients.rst | 8 Información de clientes de correo electrónico para Linux 17 usan ``git am`` para aplicar los parches. 118 Algunos usan esto con éxito para sus parches. 126 para insertar el parche. 134 Algunos usan Kmail con éxito para los parches. 177 adjunto esté en línea para que sea más visible. 184 solo para el usuario, por lo que tendrá que cambiarlos para que sean 224 para enviarlos:: 298 hay formas para obligarlo a comportarse. 337 lea su manual para saber cómo hacer esto. [all …]
|
| H A D | 4.Coding.rst | 43 cierta uniformidad para que los desarrolladores puedan comprender 67 para ajustarse al límite de 80 columnas, por ejemplo), perfecto. 75 `Documentation/dev-tools/clang-format.rst` para más detalles. 80 para obtener más información: https://editorconfig.org/ 204 disponibles para elegir la herramienta adecuada para el trabajo. El código 206 difícil para ser incluido en el kernel principal. 236 que la creación de interfaces para el espacio de usuario sea 266 "make KCFLAGS=-W" para obtener el conjunto completo. 306 (tanto para desarrolladores como para usuarios) en un sistema desplegado; 309 habilitado antes de ser enviado para su inclusión. [all …]
|
| H A D | coding-style.rst | 78 No use comas para evitar el uso de llaves: 85 Siempre use llaves para múltiples declaraciones: 204 vacías para poner comentarios. 391 útiles solamente para: 423 (c) cuando lo use para crear literalmente un tipo **nuevo** para 559 La razón para usar gotos es: 636 y ``scripts/kernel-doc`` para más detalles. 643 * Este es el estilo preferido para comentarios 665 comas para múltiples declaraciones de datos). Esto le deja espacio para un 755 útil para ordenar ``#includes``, para alinear variables/macros, para [all …]
|
| H A D | 2.Process.rst | 15 ha tenido que adaptar varios procesos para mantener el desarrollo sin 17 para ser una parte efectiva del mismo. 73 excepción ocasional para los drivers de hardware que no se admitía 122 considerado para un lanzamiento de actualización, un parche debe 150 cuestión de que un maintainer tenga la necesidad y el tiempo para 152 largo plazo para ningún lanzamiento especifico próximo. 202 para su revisión y fusión. 358 Cc’d para cualquier parche para el driver. Las reglas actuales exigen 379 documento, pero hay espacio para algunos consejos. 388 Algún tipo de familiaridad con git es casi un requisito para los [all …]
|
| H A D | 1.Intro.rst | 18 incluyendo la disponibilidad automática para los usuarios, el apoyo de la 45 ayudar a garantizar la mejor recepción posible para su trabajo. 59 fuentes para obtener más información sobre el desarrollo del kernel. 71 eficiente, y escalable para casi cualquier situación. 83 cambiar Linux para que se adapte mejor a sus necesidades. 144 para mañana. 156 el desarrollador y para el usuario. La incorporación al mainline 195 que el kernel funcione mejor para sus necesidades. 234 difícil para sus usuarios obtener soporte de la comunidad. 239 Podría requerir docenas de compilaciones de un solo módulo para [all …]
|
| H A D | 7.AdvancedTopics.rst | 20 El uso del control de versiones distribuido para el kernel comenzó a 26 varias alternativas gratuitas a BitKeeper. Para bien o para mal, el 29 Administrar parches con git puede hacer la vida mucho más fácil para el 34 usar git; eso sería material suficiente para un documento extenso por 46 y comprender cómo funciona git antes de intentar usarlo para poner 57 Usar git para generar parches para enviarlos por correo electrónico puede 60 Cuando esté listo para comenzar a publicar árboles de git para que otros 67 https://kernel.org/faq/ para más información. 76 en forma completa y listos para usar – no antes. 148 árbol git para eludir el proceso de revisión. Publique un resumen [all …]
|
| H A D | 5.Posting.rst | 11 Tarde o temprano, llega el momento en que su trabajo esté listo para ser 12 presentado a la comunidad para su revisión y, eventualmente, su inclusión 16 fácil para todos los involucrados. Este documento intentará cubrir estas 34 Al publicar código que aún no se considera listo para su inclusión, es 50 compiladores cruzados para compilar para diferentes arquitecturas, etc. 60 se realizó para un empleador, es probable que el empleador tenga 70 La preparación de parches para su publicación puede ser una cantidad 84 de trabajo para resolver conflictos y lidiar con los cambios de API. 97 camino que tomó para llegar a esos cambios. 280 para obtener más detalles. [all …]
|
| H A D | adding-syscalls.rst | 65 Diseñando el API: Planeando para extensiones 129 para usar los descriptores de archivos. 144 archivo listo para leer o escribir es la forma normal para que el kernel 215 para el repositorio man-pages. 250 tener que ser ajustada para resolver conflictos. 260 (tipicamente en ``init/Kconfig``) para ella. Como es usual para opciones 288 entrada "común" (para x86_64 y x86_32) en 517 instalado para compilar el test. 525 xfstests para cambios filesystem-related 537 en el cover del email para el patchset, para la conveniencia de los [all …]
|
| H A D | submitting-patches.rst | 8 Envío de parches: la guía esencial para incluir su código en el kernel 21 Documentation/process/submit-checklist.rst para obtener una lista de 47 preparados para esos árboles. Revise el campo **T:** para el subsistema 110 código fuente para cambiar su comportamiento. 114 del commit, para que sea más fácil para los revisores saber de qué se 567 use para acreditar peticiones de características. 573 para los testers. 584 evaluar su idoneidad y preparación para su inclusión en 625 sentirán inspirados para ayudarnos nuevamente en el futuro. 633 :ref:`describe_changes` para más detalles. [all …]
|
| H A D | submit-checklist.rst | 8 Lista de comprobación para enviar parches del kernel de Linux 35 ``make pdfdocs`` para comprobar la compilación y corregir cualquier 41 4) ppc64 es una buena arquitectura para verificar la compilación cruzada 42 por que tiende a usar ``unsigned long`` para cantidades de 64-bits. 44 5) Verifique su parche para el estilo general según se detalla en 70 candidata para el cambio. 72 11) Incluya :ref:`kernel-doc <kernel_doc>` para documentar las API 75 para comprobar el :ref:`kernel-doc <kernel_doc>` y solucionar 101 (o ``Documentation/ABI/README``) para obtener más información. 112 ``make KCFLAGS=-W``). Esto generara mucho ruido per es buena para [all …]
|
| H A D | howto.rst | 32 es necesario para desarrollar en el kernel. Lenguaje ensamblador (en 51 gcc (`info gcc`) para obtener información al respecto. 211 Es un gran lugar para comenzar. Describe una lista de problemas 241 - linux-next, para integración y testing 329 linux-next, para integración y testing 370 para informar o rastrear; sin embargo, todos los errores para todo el kernel 395 archivo MAINTAINERS para obtener referencias de lo que estas listas para 478 cosas que puede intentar hacer para evitar problemas: 493 - "Esto lo necesita mi empresa para ganar dinero" 533 Las razones para dividir las cosas son las siguientes: [all …]
|
| H A D | 3.Early-stage.rst | 23 casos, este paso es sencillo: cuando se necesita un driver para un hardware 38 para resolver su problema inmediato. Sin embargo, para la comunidad más 40 diseñado para otorgar privilegios a procesos que de otro modo no los 43 del mecanismo de rlimit a corto plazo, y trabajo continuo para reducir la 144 opción es buscar en el archivo MAINTAINERS un lugar relevante para 151 archivo MAINTAINERS es el lugar para empezar. Sin embargo, ese archivo 159 las personas que estarán mejor posicionadas para ayudar con un nuevo 164 script para facilitar el proceso: 181 efectiva de encontrar a un maintainer para un código específico. 196 (o incluso perspectivas de código) para respaldarlos, y (3) nadie está [all …]
|
| H A D | embargoed-hardware-issues.rst | 77 responsable para operar y administrar el resto de la infraestructura de 97 para la coordinación entre diferentes vendedores de OS, distribuidores, 136 efectivo y seguro para estos tipos de problemas. 149 encriptada específica para el incidente que se utilizará para la discusión 170 problema. Esto sirve para varios propósitos: 209 el kernel principal y las ramas backport para versiones estables del 225 razón convincente para objetar, entonces esta objeción debe plantearse 243 tiempo mínimo que se requiere para que todas las partes involucradas 245 embargo artificialmente para cumplir con las fechas de discusión de la 308 de la lista de correo y la configuración que se usa para asegurar la [all …]
|
| H A D | 6.Followthrough.rst | 20 espacio para la mejora. El proceso de desarrollo del kernel reconoce este 23 comunidad del kernel para asegurarse de que su código esté a la altura de 32 revisores puede ser, para muchos desarrolladores, la parte más intimidante 46 kernel, pero hay poca fama duradera para aquellos que lo revisaron. Así 63 estilo de codificación y solicitudes para factorizar parte de su código 81 de acuerdo con el revisor, tómese un tiempo para reflexionar nuevamente 127 quizás, dedicado a los parches planificados para la próxima ventana de 128 fusión y otro para trabajos a más largo plazo. 130 Para los parches que se aplican a áreas para las que no hay un árbol de 171 un driver para hardware que aún no está disponible, se sorprenderá de [all …]
|
| H A D | researcher-guidelines.rst | 6 Directrices para Investigadores 19 de Linux para mejorar a partir de ella. En cualquier caso, se recomienda 37 el proyecto están participando en buena fe para mejorar Linux. La 56 con ellos, pero ya han dado su consentimiento para recibir contribuciones 57 en buena fe. No se ha dado consentimiento para enviar parches intencionalmente 60 ejemplo, agotar el tiempo, el esfuerzo, y la moral) y perjudicial para el 63 los esfuerzos para proporcionar reacciones constructivas a los colaboradores 73 parche ha sido tradicionalmente la mejor manera para hacer un impacto. 92 otra herramienta o método utilizado para realizar el trabajo. 96 * ¿Que se cambió para solucionar el problema y por qué se cree es correcto? [all …]
|
| H A D | code-of-conduct.rst | 8 Código de Conducta para Contribuyentes 16 acoso para todo el mundo, independientemente de la edad, dimensión corporal, 28 para nuestra comunidad: 35 * Centrarse en lo que sea mejor no sólo para nosotros como individuos, sino 36 para la comunidad en general 64 Código de Conducta, y comunicarán las razones para sus decisiones de 96 Consulte el documento :ref:`code_of_conduct_interpretation` para ver cómo
|
| H A D | security-bugs.rst | 12 seguridad para que pueda ser corregido y divulgado lo más rápido posible. 25 de mantenedores del área para comprender y corregir la vulnerabilidad de 49 comienza el proceso de lanzamiento. Las soluciones para errores conocidos 52 Aunque nuestra preferencia es lanzar soluciones para errores no divulgados 57 más tiempo. La única razón válida para aplazar la publicación de una 58 solución es para acomodar la logística de QA y los despliegues a gran 62 confianza para desarrollar una solución, dicha información no se publicará 91 El equipo de seguridad no asigna CVEs, ni los requerimos para informes o 96 caso se retrasará la inclusión de un parche para esperar a que llegue un
|
| H A D | handling-regressions.rst | 11 regla del desarrollo del kernel de Linux" y que implica en la práctica para 147 para asociar los informes por regresiones con los cambios que las 252 afectados para evaluar o incluso testear el cambio propuesto; si 254 para todos. 310 posible para cualquiera que estuviese involucrado. 322 posible tanto para la gente que lo reporta, como para los desarrolladores. 375 no involucre a regzbot para incidencias normales. Pero es correcto para 493 la regla es que continúe trabajando para tí. 612 La regla para regresiones para el kernel es para cuando se 656 erróneo - funcionaba para él/ella. [all …]
|
| /linux-6.15/drivers/net/wwan/t7xx/ |
| H A D | t7xx_dpmaif.c | 216 para->intr_types[para->intr_cnt] = intr_type; in t7xx_dpmaif_set_intr_para() 217 para->intr_queues[para->intr_cnt] = intr_queue; in t7xx_dpmaif_set_intr_para() 218 para->intr_cnt++; in t7xx_dpmaif_set_intr_para() 226 struct dpmaif_hw_intr_st_para *para) in t7xx_dpmaif_hw_check_tx_intr() argument 234 t7xx_dpmaif_set_intr_para(para, DPF_INTR_UL_DONE, value); in t7xx_dpmaif_hw_check_tx_intr() 242 t7xx_dpmaif_set_intr_para(para, DPF_INTR_UL_DRB_EMPTY, value); in t7xx_dpmaif_hw_check_tx_intr() 254 t7xx_dpmaif_set_intr_para(para, DPF_INTR_UL_LEN_ERR, value); in t7xx_dpmaif_hw_check_tx_intr() 265 struct dpmaif_hw_intr_st_para *para, int qno) in t7xx_dpmaif_hw_check_rx_intr() argument 345 struct dpmaif_hw_intr_st_para *para, int qno) in t7xx_dpmaif_hw_get_intr_cnt() argument 370 t7xx_dpmaif_hw_check_tx_intr(hw_info, tx_intr_status, para); in t7xx_dpmaif_hw_get_intr_cnt() [all …]
|
| /linux-6.15/drivers/crypto/virtio/ |
| H A D | virtio_crypto_akcipher_algs.c | 99 struct virtio_crypto_akcipher_session_para *para, in virtio_crypto_alg_akcipher_init_session() argument 123 memcpy(&ctrl->u.akcipher_create_session.para, para, sizeof(*para)); in virtio_crypto_alg_akcipher_init_session() 297 akcipher_req->para.src_data_len = cpu_to_le32(req->src_len); in virtio_crypto_rsa_do_req() 298 akcipher_req->para.dst_data_len = cpu_to_le32(req->dst_len); in virtio_crypto_rsa_do_req() 348 struct virtio_crypto_akcipher_session_para para; in virtio_crypto_rsa_set_key() local 392 para.algo = cpu_to_le32(VIRTIO_CRYPTO_AKCIPHER_RSA); in virtio_crypto_rsa_set_key() 393 para.keytype = cpu_to_le32(keytype); in virtio_crypto_rsa_set_key() 394 para.keylen = cpu_to_le32(keylen); in virtio_crypto_rsa_set_key() 395 para.u.rsa.padding_algo = cpu_to_le32(padding_algo); in virtio_crypto_rsa_set_key() 396 para.u.rsa.hash_algo = cpu_to_le32(hash_algo); in virtio_crypto_rsa_set_key() [all …]
|
| /linux-6.15/Documentation/translations/sp_SP/scheduler/ |
| H A D | sched-design-CFS.rst | 19 para el gestor de tareas EEVDF, cuya documentación se puede ver en 63 en inglés), multi-tarea y varias variantes del algoritmo para identificar 81 para situar las nuevas tareas en la parte izquierda del árbol tanto 101 para que otra tarea sea "la tarea más hacia la izquierda" del árbol 103 cantidad de distancia relativa a la tarea más hacia la izquierda para 106 para que se ejecute, y la tarea en ejecución es interrumpida. 145 tareas que se usan para tareas normales. 151 para trabajos de procesado de datos. 154 no es un gestor "idle" para evitar caer en el problema de la 195 Cuando una tarea deja de ser ejecutable, esta función se llama para [all …]
|