| /linux/drivers/net/wireless/broadcom/brcm80211/brcmsmac/ |
| H A D | dma.c | 38 #define DMA64TXREGOFFS(di, field) (di->d64txregbase + DMA64REGOFFS(field)) argument
39 #define DMA64RXREGOFFS(di, field) (di->d64rxregbase + DMA64REGOFFS(field)) argument
313 static uint txd(struct dma_info *di, uint x) in txd() argument
315 return xxd(x, di->ntxd); in txd()
318 static uint rxd(struct dma_info *di, uint x) in rxd() argument
320 return xxd(x, di->nrxd); in rxd()
323 static uint nexttxd(struct dma_info *di, uint i) in nexttxd() argument
325 return txd(di, i + 1); in nexttxd()
328 static uint prevtxd(struct dma_info *di, uint i) in prevtxd() argument
330 return txd(di, i - 1); in prevtxd()
[all …]
|
| /linux/drivers/power/supply/ |
| H A D | ds2760_battery.c | 254 static int ds2760_battery_read_status(struct ds2760_device_info *di) in ds2760_battery_read_status() argument
258 if (di->update_time && time_before(jiffies, di->update_time + in ds2760_battery_read_status()
264 if (di->update_time == 0) { in ds2760_battery_read_status()
272 ret = w1_ds2760_read(di->dev, di->raw + start, start, count); in ds2760_battery_read_status()
274 dev_warn(di->dev, "call to w1_ds2760_read failed (0x%p)\n", in ds2760_battery_read_status()
275 di->dev); in ds2760_battery_read_status()
279 di->update_time = jiffies; in ds2760_battery_read_status()
283 di->voltage_raw = (di->raw[DS2760_VOLTAGE_MSB] << 3) | in ds2760_battery_read_status()
284 (di->raw[DS2760_VOLTAGE_LSB] >> 5); in ds2760_battery_read_status()
285 di->voltage_uV = di->voltage_raw * 4880; in ds2760_battery_read_status()
[all …]
|
| H A D | bq27xxx_battery_hdq.c | 40 static int bq27xxx_battery_hdq_read(struct bq27xxx_device_info *di, u8 reg, in bq27xxx_battery_hdq_read() argument
43 struct w1_slave *sl = dev_to_w1_slave(di->dev); in bq27xxx_battery_hdq_read()
77 struct bq27xxx_device_info *di; in bq27xxx_battery_hdq_add_slave() local
79 di = devm_kzalloc(&sl->dev, sizeof(*di), GFP_KERNEL); in bq27xxx_battery_hdq_add_slave()
80 if (!di) in bq27xxx_battery_hdq_add_slave()
83 dev_set_drvdata(&sl->dev, di); in bq27xxx_battery_hdq_add_slave()
85 di->dev = &sl->dev; in bq27xxx_battery_hdq_add_slave()
86 di->chip = BQ27000; in bq27xxx_battery_hdq_add_slave()
87 di->name = "bq27000-battery"; in bq27xxx_battery_hdq_add_slave()
88 di->bus.read = bq27xxx_battery_hdq_read; in bq27xxx_battery_hdq_add_slave()
[all …]
|
| /linux/drivers/gpu/ipu-v3/ |
| H A D | ipu-di.c | 123 static inline u32 ipu_di_read(struct ipu_di *di, unsigned offset) in ipu_di_read() argument
125 return readl(di->base + offset); in ipu_di_read()
128 static inline void ipu_di_write(struct ipu_di *di, u32 value, unsigned offset) in ipu_di_write() argument
130 writel(value, di->base + offset); in ipu_di_write()
133 static void ipu_di_data_wave_config(struct ipu_di *di, in ipu_di_data_wave_config() argument
140 ipu_di_write(di, reg, DI_DW_GEN(wave_gen)); in ipu_di_data_wave_config()
143 static void ipu_di_data_pin_config(struct ipu_di *di, int wave_gen, int di_pin, in ipu_di_data_pin_config() argument
148 reg = ipu_di_read(di, DI_DW_GEN(wave_gen)); in ipu_di_data_pin_config()
151 ipu_di_write(di, reg, DI_DW_GEN(wave_gen)); in ipu_di_data_pin_config()
153 ipu_di_write(di, (down << 16) | up, DI_DW_SET(wave_gen, set)); in ipu_di_data_pin_config()
[all …]
|
| /linux/Documentation/translations/it_IT/locking/ |
| H A D | locktorture.rst | 12 L'opzione di configurazione CONFIG_LOCK_TORTURE_TEST fornisce un
13 modulo kernel che esegue delle verifiche che *torturano* le primitive di
20 programma si basa sulle modalità di verifica di RCU tramite rcutorture.
22 Questa verifica consiste nella creazione di un certo numero di thread
24 quantità di tempo così da simulare diversi comportamenti nelle sezioni
25 critiche. La quantità di contese su un blocco può essere simulata
35 Specifici di locktorture
39 Numero di thread del kernel che stresseranno l'acquisizione
40 esclusiva dei blocchi (scrittori). Il valore di base è il
41 doppio del numero di processori attivi presenti.
[all …]
|
| H A D | lockstat.rst | 24 *Lockdep* ha punti di collegamento nelle funzioni di blocco e inoltre
25 mappa le istanze di blocco con le relative classi. Partiamo da questo punto
28 funzioni di blocco e i vari punti di collegamenti che ci sono al loro
51 lock, unlock - le classiche funzioni di blocco
52 __* - i punti di collegamento
55 Grazie a questi punti di collegamento possiamo fornire le seguenti statistiche:
58 - numero di contese su un blocco che riguarda dati di un processore
61 - numero di acquisizioni di blocchi che hanno dovuto attendere
65 - tempo minimo (diverso da zero) che sia mai stato speso in attesa di
69 - tempo massimo che sia mai stato speso in attesa di un blocco
[all …]
|
| H A D | lockdep-design.rst | 5 Validatore di sincronizzazione durante l'esecuzione
8 Classi di blocchi
11 L'oggetto su cui il validatore lavora è una "classe" di blocchi.
13 Una classe di blocchi è un gruppo di blocchi che seguono le stesse regole di
15 decine di migliaia). Per esempio un blocco nella struttura inode è una classe,
16 mentre ogni inode sarà un'istanza di questa classe di blocco.
18 Il validatore traccia lo "stato d'uso" di una classe di blocchi e le sue
19 dipendenze con altre classi. L'uso di un blocco indica come quel blocco viene
20 usato rispetto al suo contesto d'interruzione, mentre le dipendenze di un blocco
22 che un processo cerca di acquisire L2 mentre già trattiene L1. Dal punto di
[all …]
|
| /linux/Documentation/translations/it_IT/process/ |
| H A D | 1.Intro.rst | 14 Il resto di questa sezione riguarda il processo di sviluppo del kernel e
15 quella sorta di frustrazione che gli sviluppatori e i loro datori di lavoro
19 differenti modalità, e la capacità di influenzare la direzione dello sviluppo
24 La sezione :ref:`it_development_process` introduce il processo di sviluppo,
25 il ciclo di rilascio del kernel, ed i meccanismi della finestra
26 d'incorporazione. Il capitolo copre le varie fasi di una modifica: sviluppo,
28 liste di discussione. Gli sviluppatori che sono in attesa di poter sviluppare
33 pianificazione di un progetto di sviluppo, con particolare enfasi sul
36 La sezione :ref:`it_development_coding` riguarda il processo di scrittura
42 La sezione :ref:`it_development_posting` parla del processo di pubblicazione
[all …]
|
| H A D | deprecated.rst | 14 In un mondo perfetto, sarebbe possibile prendere tutti gli usi di
16 possibile rimuovere la vecchia interfaccia in un singolo ciclo di sviluppo.
18 le tempistiche, non è sempre possibile fare questo tipo di conversione tutta
19 in una volta. Questo significa che nuove istanze di una vecchia interfaccia
20 potrebbero aggiungersi al kernel proprio quando si sta cercando di rimuoverle,
21 aumentando così il carico di lavoro. Al fine di istruire gli sviluppatori su
30 perché uno degli obiettivi del kernel è quello di compilare senza avvisi;
32 di `__deprecated` in un file d'intestazione sia opportuno per segnare una
45 sono stati ripristinati?). Molto spesso l'uso di BUG()
47 impossibile un'attività di debug o anche solo leggere un rapporto
[all …]
|
| H A D | volatile-considered-harmful.rst | 12 essere cambiate al di fuori dal thread di esecuzione corrente; come risultato,
15 *volatile* come una variabile atomica di facile utilizzo, ma non è così.
16 L'uso di *volatile* nel kernel non è quasi mai corretto; questo documento ne
19 Il punto chiave da capire su *volatile* è che il suo scopo è quello di
23 Il processo di protezione contro gli accessi concorrenti indesiderati eviterà
28 (spinlock, mutex, barriere di sincronizzazione, ecc) sono progettate per
30 non ci sarà bisogno di utilizzare *volatile*. Se vi sembra che *volatile* sia
32 In un pezzo di codice kernel scritto a dovere, *volatile* può solo servire a
35 Considerate questo tipico blocco di codice kernel::
42 Se tutto il codice seguisse le regole di sincronizzazione, il valore di un
[all …]
|
| H A D | 3.Early-stage.rst | 11 Osservando un progetto di sviluppo per il kernel Linux, si potrebbe essere
14 viene fatta prima che una sola linea di codice venga scritta. Il tempo speso
21 Come qualsiasi progetto ingegneristico, un miglioramento del kernel di
26 può portare all'emergere di problemi.
35 lista di discussione linux-kernel, dove incontrò subito dei problemi.
37 Per gli sviluppatori audio, questo modulo di sicurezza era sufficiente a
41 e un rischio per la stabilità del sistema. Le loro soluzioni di punta nel
46 La comunità audio, comunque, non poteva vedere al di là della singola
48 Il conseguente dissenso lasciò in quegli sviluppatori un senso di
49 disillusione nei confronti dell'intero processo di sviluppo; uno di loro
[all …]
|
| H A D | management-style.rst | 8 Il modello di gestione del kernel Linux
11 Questo breve documento descrive il modello di gestione del kernel Linux.
14 ed è principalmente scritto per evitare di rispondere [#f1]_ in continuazione
17 Il modello di gestione è qualcosa di molto personale e molto più difficile da
18 qualificare rispetto a delle semplici regole di codifica, quindi questo
26 occupate di convalidare acquisti o avete una qualche idea sul budget del vostro
30 Prima di tutto, suggerirei di acquistare "Le sette regole per avere successo",
31 e di non leggerlo. Bruciatelo, è un grande gesto simbolico.
35 di come rispondere.
49 Il gioco consiste nell'"evitare" di dover prendere decisioni. In particolare
[all …]
|
| H A D | maintainer-pgp-guide.rst | 23 Il ruolo di PGP nello sviluppo del kernel Linux
27 di sviluppo del kernel e, in secondo luogo, stabilisce canali di comunicazione
28 affidabili tra sviluppatori attraverso lo scambio di email firmate con PGP.
33 - repositori distribuiti di sorgenti (git)
34 - rilasci periodici di istantanee (archivi tar)
40 hanno sul loro posto di lavoro. A tal scopo:
50 Fin dal 2011, quando i sistemi di kernel.org furono compromessi, il principio
51 generale del progetto Kernel Archives è stato quello di assumere che qualsiasi
56 pratiche di sicurezza messe in atto.
60 non sia fatto semplicemente per incolpare qualcun'altro per future falle di
[all …]
|
| H A D | botching-up-ioctls.rst | 6 (Come evitare di) Raffazzonare delle ioctl
14 imparato negli ultimi anni è l'inutilità di cercare di creare un'interfaccia
15 unificata per gestire la memoria e le unità esecutive di diverse GPU. Dunque,
16 oggigiorno ogni driver ha il suo insieme di ioctl per allocare memoria ed
18 sistema che finge di essere generico, ma al suo posto ci sono interfacce
21 Per evitare di ripetere gli stessi errori ho preso nota delle lezioni imparate
22 mentre raffazzonavo il driver drm/i915. La maggior parte di queste lezioni si
25 GPU. Probabilmente, ogni sviluppatore di driver per GPU dovrebbe imparare queste
33 partenza e ritrovarvi ad aggiungere un livello di compatibilità a 32-bit.
48 quando si passano vettori di strutture dati al kernel, o quando il kernel
[all …]
|
| H A D | 7.AdvancedTopics.rst | 12 di sviluppo. Ma rimane comunque molto da imparare! Questo capitolo copre
14 per diventare parte integrante del processo di sviluppo del kernel.
19 L'uso di un sistema distribuito per il controllo delle versioni del kernel
21 BitKeeper. Nonostante l'uso di BitKeeper fosse opinabile, di certo il suo
25 peggio, il progetto del kernel ha deciso di usare git per gestire i sorgenti.
30 strumento giovane e potente che è ancora in fase di civilizzazione da parte
31 dei suoi sviluppatori. Questo documento non ha lo scopo di insegnare l'uso
32 di git ai suoi lettori; ci sarebbe materiale a sufficienza per un lungo
34 git è parte del processo di sviluppo del kernel. Gli sviluppatori che
44 La prima cosa da fare prima di usarlo per produrre patch che saranno
[all …]
|
| H A D | 6.Followthrough.rst | 14 perfetta di patch. Uno dei più grandi errori che possono essere commessi
15 persino da sviluppatori kernel esperti è quello di concludere che il
18 probabilmente, ancora un po' di lavoro da fare.
21 ci sia alcuno spazio di miglioramento. Il programma di sviluppo del kernel
23 del codice pubblicato. Voi, in qualità di autori del codice, dovrete
33 da parte di altri sviluppatori dato che avranno revisionato il codice.
35 più intimidatoria del processo di sviluppo del kernel. La vita può esservi
39 comprenderanno il valore e il perché vi siete presi il disturbo di
43 richiesti - da piccoli problemi di stile a sostanziali ristesure -
53 tentazione di rispondere a tono. La revisione riguarda il codice e non
[all …]
|
| /linux/Documentation/translations/it_IT/i2c/ |
| H A D | i2c-protocol.rst | 5 Questo documento è una panoramica delle transazioni di base I2C e delle API
12 S Condizione di avvio
13 P Condizione di stop
14 Rd/Wr (1 bit) Bit di lettura/scrittura. Rd vale 1, Wr vale 0.
15 A, NA (1 bit) Bit di riconoscimento (ACK) e di non riconoscimento (NACK).
18 Dati (8 bit) Un byte di dati.
25 Transazione semplice di invio
33 Transazione semplice di ricezione
46 Sono come le transazioni di cui sopra, ma invece di uno condizione di stop P
47 viene inviata una condizione di inizio S e la transazione continua.
[all …]
|
| /linux/Documentation/translations/it_IT/core-api/ |
| H A D | symbol-namespaces.rst | 17 l'API esposta internamente al kernel. Permette ai manutentori di un
18 sottosistema di organizzare i simboli esportati in diversi spazi di
21 la disponibilità di un gruppo di simboli in altre parti del kernel. Ad
22 oggi, i moduli che usano simboli esportati da uno spazio di nomi
24 della configurazione, potrebbe rifiutare di caricare il modulo o
25 avvisare l'utente di un'importazione mancante.
32 EXPORT_SYMBOL e simili vengono guidati verso la creazione di voci in ksymtab.
38 di esportare simboli del kernel nella rispettiva tabella, ci sono
39 varianti che permettono di esportare simboli all'interno di uno spazio dei
43 essere un simbolo di preprocessore. Per esempio per esportare il
[all …]
|
| /linux/Documentation/translations/it_IT/RCU/ |
| H A D | torture.rst | 12 L'opzione CONFIG_RCU_TORTURE_TEST è disponibile per tutte le implementazione di
18 I parametri di modulo hanno tutti il prefisso "rcutortute.", vedere
35 usare altri comandi per visualizzare i messaggi di printk(). La funzione
38 La prima e l'ultima riga mostrano i parametri di module di rcutorture, e solo
47 * "ver": Il numero di volte dall'avvio che il processo scrittore di RCU ha
50 * "tfle": se non è zero, indica la lista di strutture "torture freelist" da
54 * "rta": numero di strutture allocate dalla lista "torture freelist".
56 * "rtaf": il numero di allocazioni fallite dalla lista "torture freelist" a
58 un brutto segno se questo numero rappresenta una frazione troppo alta di
61 * "rtf": il numero di rilasci nella lista "torture freelist"
[all …]
|
| /linux/Documentation/translations/it_IT/doc-guide/ |
| H A D | contributing.rst | 8 La documentazione è una parte importante di ogni progetto di sviluppo
10 permette a quelli già presenti di lavorare in modo più efficace. Senza una
11 documentazione di qualità, si spreca molto tempo nel decifrare il codice a
15 quello che dovrebbe essere per sostenere un progetto di queste dimensioni e
20 sviluppatori con diversi livelli di esperienza; sono un modo relativamente
21 semplice per imparare il processo di sviluppo del kernel in generale e
29 C'è un elenco infinito di compiti da svolgere per portare la nostra
38 incredibile di avvisi. Quando ce ne sono così tanti, è come se non ce ne
40 loro lavoro ne aggiunge di nuovi. Per questo motivo, eliminare gli avvisi è
48 quasi sempre un problema reale; farli sparire richiede di comprendere il
[all …]
|
| H A D | parse-headers.rst | 4 Includere i file di intestazione uAPI
7 Qualche volta è utile includere dei file di intestazione e degli esempi di codice C
8 al fine di descrivere l'API per lo spazio utente e per generare dei riferimenti
12 di mantenere allineate la documentazione della uAPI (API spazio utente)
27 parse_headers.py - analizza un file C al fine di identificare funzioni,
46 Il programma è capace di identificare ``define``, ``struct``, ``typedef``,
47 ``enum`` e ``symbol`` di un enumerato, creando i riferimenti per ognuno di
50 Inoltre, esso è capace di distinguere le ``#define`` utilizzate per
51 specificare le macro specifiche di Linux usate per definire gli ``ioctl``.
53 Il file ``FILE_RULES``, opzionale, contiene un insieme di regole come le
[all …]
|
| H A D | sphinx.rst | 18 I file reStructuredText possono contenere delle direttive che permettono di
19 includere i commenti di documentazione, o di tipo kernel-doc, dai file
22 e l'architettura del codice. I commenti di tipo kernel-doc hanno una struttura
25 Inoltre, ci sono migliaia di altri documenti in formato testo sparsi nella
26 cartella ``Documentation``. Alcuni di questi verranno probabilmente convertiti,
27 nel tempo, in formato reStructuredText, ma la maggior parte di questi rimarranno
42 programmi e librerie è fragile e non è raro che dopo un aggiornamento di
46 Un modo per evitare questo genere di problemi è quello di utilizzare una
48 vi raccomandiamo di installare Sphinx dentro ad un ambiente virtuale usando
49 ``virtualenv-3`` o ``virtualenv`` a seconda di come Python 3 è stato
[all …]
|
| H A D | maintainer-profile.rst | 5 Profilo del manutentore del sottosistema di documentazione
8 Il "sottosistema" della documentazione è il punto di coordinamento
10 Copre la gerarchia sotto Documentation/ (con l'eccezione di
14 Vale la pena notare, però, che i confini di questo sottosistema sono più sfumati
15 del normale. Molti altri manutentori di sottosistemi preferiscono mantenere il
16 controllo di alcune parti di Documentation/, e molti altri ancora vi applicano
18 documentazione del kernel si trova nel codice sorgente sotto forma di commenti
22 La lista di discussione per la documentazione è linux-doc@vger.kernel.org.
26 Aggiunta alla checklist di invio
40 dello spazio utente, utenti finali e/o amministratori di sistema, e
[all …]
|
| /linux/fs/ceph/ |
| H A D | dir.c | 33 static bool __dentry_lease_is_valid(struct ceph_dentry_info *di);
41 struct ceph_dentry_info *di; in ceph_d_init() local
44 di = kmem_cache_zalloc(ceph_dentry_cachep, GFP_KERNEL); in ceph_d_init()
45 if (!di) in ceph_d_init()
48 di->dentry = dentry; in ceph_d_init()
49 di->lease_session = NULL; in ceph_d_init()
50 di->time = jiffies; in ceph_d_init()
51 dentry->d_fsdata = di; in ceph_d_init()
52 INIT_LIST_HEAD(&di->lease_list); in ceph_d_init()
195 struct ceph_dentry_info *di; in __dcache_readdir() local
[all …]
|
| /linux/Documentation/translations/it_IT/arch/riscv/ |
| H A D | patch-acceptance.rst | 12 L'insieme di istruzioni RISC-V sono sviluppate in modo aperto: le
13 bozze in fase di sviluppo sono disponibili a tutti per essere
15 dei nuovi moduli o estensioni possono cambiare in fase di sviluppo - a
17 flessibilità può portare a dei problemi di manutenzioni per il
19 l'abbandono del codice, e il processo di sviluppo del kernel
28 RISC-V ha un'istanza di patchwork dov'è possibile controllare lo stato delle patch:
32 Se la vostra patch non appare nella vista predefinita, i manutentori di RISC-V
36 Il processo automatico viene eseguito su questa istanza di patchwork, costruendo
40 caso contrario, utilizzerà il ramo `master` di RISC-V. L'esatto commit a cui è
41 stata applicata una serie di patch sarà annotato su patchwork. È improbabile che
[all …]
|