| /Linux-v5.4/arch/powerpc/mm/ |
| D | hugetlbpage.c | 115 pud_t *pu; in huge_pte_alloc() local 137 pu = pud_alloc(mm, pg, addr); in huge_pte_alloc() 138 if (!pu) in huge_pte_alloc() 141 return (pte_t *)pu; in huge_pte_alloc() 143 ptl = pud_lockptr(mm, pu); in huge_pte_alloc() 144 hpdp = (hugepd_t *)pu; in huge_pte_alloc() 147 pm = pmd_alloc(mm, pu, addr); in huge_pte_alloc() 165 pu = pud_alloc(mm, pg, addr); in huge_pte_alloc() 166 if (!pu) in huge_pte_alloc() 169 ptl = pud_lockptr(mm, pu); in huge_pte_alloc() [all …]
|
| /Linux-v5.4/drivers/gpu/drm/nouveau/nvkm/engine/disp/ |
| D | sorgm200.c | 27 gm200_sor_dp_drive(struct nvkm_ior *sor, int ln, int pc, int dc, int pe, int pu) in gm200_sor_dp_drive() argument 34 pu &= 0x0f; in gm200_sor_dp_drive() 39 if ((data[2] & 0x00000f00) < (pu << 8) || ln == 0) in gm200_sor_dp_drive() 40 data[2] = (data[2] & ~0x00000f00) | (pu << 8); in gm200_sor_dp_drive()
|
| D | sornv50.c | 47 nv50_sor_power(struct nvkm_ior *sor, bool normal, bool pu, in nv50_sor_power() argument 53 const u32 state = 0x80000000 | (0x00000001 * !!pu) << shift; in nv50_sor_power()
|
| D | dacnv50.c | 66 nv50_dac_power(struct nvkm_ior *dac, bool normal, bool pu, in nv50_dac_power() argument 72 const u32 state = 0x80000000 | (0x00000040 * ! pu | in nv50_dac_power()
|
| D | piornv50.c | 58 nv50_pior_power(struct nvkm_ior *pior, bool normal, bool pu, in nv50_pior_power() argument 64 const u32 state = 0x80000000 | (0x00000001 * !!pu) << shift; in nv50_pior_power()
|
| D | sorgf119.c | 71 gf119_sor_dp_drive(struct nvkm_ior *sor, int ln, int pc, int dc, int pe, int pu) in gf119_sor_dp_drive() argument 81 if ((data[2] & 0x0000ff00) < (pu << 8) || ln == 0) in gf119_sor_dp_drive() 82 data[2] = (data[2] & ~0x0000ff00) | (pu << 8); in gf119_sor_dp_drive()
|
| D | sorg94.c | 58 g94_sor_dp_drive(struct nvkm_ior *sor, int ln, int pc, int dc, int pe, int pu) in g94_sor_dp_drive() argument 68 if ((data[2] & 0x0000ff00) < (pu << 8) || ln == 0) in g94_sor_dp_drive() 69 data[2] = (data[2] & ~0x0000ff00) | (pu << 8); in g94_sor_dp_drive()
|
| /Linux-v5.4/Documentation/translations/it_IT/process/ |
| D | deprecated.rst | 41 (o simili) per via del rischio di overflow. Questo può portare a valori più 43 allocare può portare ad un overflow della memoria di heap e altri 45 compilatore può generare avvisi circa un potenziale overflow. Tuttavia usare 79 i possibili overflow, e questo può portare il chiamante a generare risultati 88 di destinazione. Questo può portare ad un overflow oltre i limiti del 107 può continuare ad essere usata, ma i buffer di destinazione devono essere 115 è inefficiente e può portare a overflow di lettura quando la stringa non è 126 Questo può portare a dei malfunzionamenti, potrebbe sovrascrivere
|
| D | volatile-considered-harmful.rst | 32 In un pezzo di codice kernel scritto a dovere, *volatile* può solo servire a 55 critica, dove sappiamo che in realtà nessun altro può accedervi. Mentre si 77 La chiamata cpu_relax() può ridurre il consumo di energia del processore 97 volta che viene letta ma può essere lette senza alcuna sincronizzazione. 98 Quindi jiffies può essere *volatile*, ma l'aggiunta ad altre variabili di 104 essere modificata da dispositivi di I/O può, a volte, essere legittimamente 105 *volatile*. Un esempio pratico può essere quello di un adattatore di rete 109 Per la maggior parte del codice, nessuna delle giustificazioni sopracitate può
|
| D | 7.AdvancedTopics.rst | 27 Gestire le modifiche con git può rendere la vita dello sviluppatore molto 56 Utilizzare git per produrre patch da sottomettere via email può essere 69 può essere separata in "rami per argomenti" e gestiti indipendentemente. 78 oppure che ha un qualche tipo di baco evidente) può essere corretta sul posto 79 o fatta sparire completamente dalla storia. Una serie di patch può essere 83 di git per revisionare la storia può aiutare nella creazione di una serie 86 Un uso eccessivo può portare ad altri tipi di problemi, tuttavia, oltre 112 per rimanere sempre aggiornati. Per un ramo privato, il *rebase* può essere 121 può essere utile; questo strumento si ricorda come i conflitti di *merge* 158 otterranno dall'integrazione. Il comando git request-pull può essere d'aiuto; [all …]
|
| D | 4.Coding.rst | 62 assoluta che non può mai essere trasgredita. Se c’è un a buona ragione 84 ha dimostrato che un'eccessiva o prematura astrazione può rivelarsi dannosa 128 condizionatamente può essere confinato a funzioni tali che, nel caso in cui 151 può causare rallentamenti importanti. Le funzioni inline, di norma, dovrebbero 213 Spesso si è argomentato che una regressione può essere giustificata se essa 221 via nasconde insidie, e nessuno può sapere del tutto se state facendo 270 generato da questi avvertimenti può risultare verboso, ma non bisogna 279 - DEBUG_SLAB può trovare svariati errori di uso e di allocazione di memoria; 294 interruzione, eccetera. Inoltre esso può assicurare che i *lock* vengano 297 lockdep può scovare diversi scenari nei quali il sistema potrebbe, in rari [all …]
|
| D | 1.Intro.rst | 88 per gli sviluppatori; chiunque con le capacità richieste può migliorare 92 progetti di software libero. Un classico ciclo di sviluppo trimestrale può 105 Il processo di sviluppo del Kernel può, dall'altro lato, risultare 139 distributori Linux). Nel breve termine, contribuire al codice può sembrare 140 un costo inutile; può sembra più facile tenere separato il proprio codice e 175 clienti può portare a sorprendenti risultati che migliorano i vostri 220 niente in questo documento può essere considerato come un consiglio legale. 221 Il vero stato legale dei moduli proprietari può essere determinato 234 comprensiva, può essere richiesto di produrre dozzine di singoli moduli. 240 del tutto disponibile, non può essere revisionato dalla comunità e avrà, [all …]
|
| D | 6.Followthrough.rst | 34 Lavorare con i revisori può rivelarsi, per molti sviluppatori, la parte 35 più intimidatoria del processo di sviluppo del kernel. La vita può esservi 59 di lavoro può cambiare. Davvero, senza praticamente eccezioni, loro 86 aggiuntivo; ciò può essere d'aiuto ai futuri revisori nell'evitare domande 110 comunità di sviluppo del kernel; lui può spesso sbrogliare situazioni che 133 L'inclusione nei sorgenti di un sottosistema può comportare per una patch, 150 può rivelarsi una spina nel fianco, ma consideratevi fortunati: prima 239 modo può essere avvilente e scoraggiante, ma la comunità ricorderà come
|
| D | 3.Early-stage.rst | 15 nella pianificazione e la comunicazione può far risparmiare molto 26 può portare all'emergere di problemi. 85 nell'implementazione. Una discussione preliminare può far risparmiare sia 151 Trovare manutentori può rivelarsi un po' difficoltoso. Ancora, il file 188 elaborato per l'implementazione. Ogni informazione fornita può aiutare 215 è stato rilascio espressamente con licenza GPL-compatibile può rivelarsi 227 Detto ciò, ci sono anche casi dove l'azienda legittimamente non può rivelare
|
| D | submitting-drivers.rst | 15 quello che viene detto qui può essere trovato anche negli altri documenti
|
| D | 2.Process.rst | 70 successivo (un'eccezione può essere fatta per i driver per hardware non 176 il più aperto possibile; questo può far risparmiare molto tempo evitando 231 Esiste una sola persona che può inserire le patch nel repositorio principale 235 una dimensione tale per cui un singolo sviluppatore non può controllare e 253 altri metadati. In ogni momento, il manutentore può individuare quale patch 270 catena di repositori può essere più o meno lunga, benché raramente ecceda 356 La *preparazione* può essere una via relativamente facile per inserire nuovi 439 la conversazione può essere strettamente tecnica e i partecipanti non sono 473 - Chiedete nella lista di discussione corretta. Linux-kernel può essere un 493 di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace. [all …]
|
| /Linux-v5.4/drivers/lightnvm/ |
| D | pblk-trace.h | 60 (u64)(((struct ppa_addr *)(&__entry->ppa))->m.pu), 86 (u64)(((struct ppa_addr *)(&__entry->ppa))->m.pu),
|
| /Linux-v5.4/arch/arm/boot/dts/ |
| D | imx6q.dtsi | 50 pu-supply = <®_pu>; 84 pu-supply = <®_pu>; 118 pu-supply = <®_pu>; 152 pu-supply = <®_pu>;
|
| /Linux-v5.4/include/linux/ |
| D | lightnvm.h | 65 u64 pu : NVM_GEN_LUN_BITS; member 459 l.ppa |= ((u64)r.m.pu) << lbaf->lun_offset; in generic_to_dev_addr() 488 l.m.pu = (r.ppa & lbaf->lun_mask) >> lbaf->lun_offset; in dev_to_generic_addr() 550 ppa64.m.pu = (ppa32 & lbaf->lun_mask) >> in nvm_ppa32_to_ppa64() 588 ppa32 |= ppa64.m.pu << lbaf->lun_offset; in nvm_ppa64_to_ppa32()
|
| /Linux-v5.4/Documentation/translations/it_IT/doc-guide/ |
| D | parse-headers.rst | 40 Dove <options> può essere: --debug, --usage o --help. 100 Per entrambe le dichiarazioni, il \ **tipo**\ può essere uno dei seguenti: 148 \ **symbol**\. Il tipo di riferimento può essere definito esplicitamente
|
| /Linux-v5.4/Documentation/translations/it_IT/kernel-hacking/ |
| D | locking.rst | 89 La prelazione può sortire gli stessi effetti, anche se c'è una sola CPU: 117 spinlock (``include/asm/spinlock.h``), un semplice *lock* che può essere 118 trattenuto solo da un processo: se non si può trattenere lo spinlock, allora 139 quando nessun altro processo può essere eseguito in simultanea, allora 240 Lo stesso softirq può essere eseguito su un diverso processore: allo scopo 270 avrete due preoccupazioni. Primo, il softirq può essere interrotto da 279 è in esecuzione: per questo si può usare :c:func:`spin_lock()`, che è un po' 298 anche questi. Tenuto conto di questo si può dire che 330 diversi contesti. In alcuni casi, lo stesso contesto può essere eseguito solo 332 sincronizzazione (per esempio, un thread può essere eseguito solo su un [all …]
|
| D | hacking.rst | 36 In qualsiasi momento ognuna delle CPU di un sistema può essere: 49 può avvicendarsi solo ad uno di quelli sottostanti. Per esempio, mentre un 50 softirq è in esecuzione su d'una CPU, nessun altro softirq può avvicendarsi 51 nell'esecuzione, ma un'interruzione hardware può. Ciò nonostante, le altre CPU 163 per cui non si può usare. 259 Essa è utile per il debugging o per la notifica di errori; può essere 336 Non dorme. Meno affidabile di ``GFP_KERNEL``, ma può essere usata in un 398 La famiglia di funzioni :c:func:`cpu_to_be32()` (dove "32" può essere 476 e :c:func:`module_exit()` semplifica la scrittura di codice che può funzionare 486 La funzione può ritornare un numero d'errore negativo per scatenare un [all …]
|
| /Linux-v5.4/fs/nls/ |
| D | nls_base.c | 55 int utf8_to_utf32(const u8 *s, int inlen, unicode_t *pu) in utf8_to_utf32() argument 71 *pu = (unicode_t) l; in utf8_to_utf32()
|
| /Linux-v5.4/Documentation/devicetree/bindings/input/ |
| D | st,stpmic1-onkey.txt | 15 - st,onkey-pu-inactive: onkey pull up is not active
|
| /Linux-v5.4/drivers/pinctrl/ |
| D | pinctrl-st.c | 229 struct regmap_field *alt, *oe, *pu, *od; member 244 const int alt, oe, pu, od, rt; member 346 .alt = 0, .oe = 40, .pu = 50, .od = 60, .rt = 100, 357 .pu = -1, /* Not Available */ 387 struct regmap_field *pull_up = pc->pu; in st_pinconf_set_config() 585 if (pc->pu) { in st_pinconf_get_direction() 586 regmap_field_read(pc->pu, &pu_value); in st_pinconf_get_direction() 1148 pc->pu = st_pc_get_value(dev, regmap, bank/4, data->pu, lsb, msb); in st_parse_syscfgs()
|