November 2023 - kernelnewbies@kernelnewbies.org

Source code organization
by Billie Alsup (balsup) April 23, 2024

April 23, 2024

I have a set of drivers that I would like to upstream. These are primarily MFD style drivers supporting Cisco-8000 FPGAs. The devices can be instantiated through multiple top level drivers, which provide the access mechanism for the MFD driver. For example, an FPGA can be accessed via PCI, or via i2c, or via SLPC, or via P2PM (a point-to-point interface). We currently build these drivers out of tree, under a single directory drivers/cisco. I note that existing drivers are spread out across the kernel tree, sometimes by bus (pci, i2c), sometimes by function (gpio, net/mdio, spi), and sometimes under the generic mfd. I would like to start the upstream review process for our drivers, but first want to get recommendations on the source code layout. Is it permissible to keep a top level directory such as drivers/cisco to organize our code? It is not only the source code that is affected, but also provides a central place for Kconfig entries. Our FPGAs have multiple logical blocks, each of which is handled by a different MFD driver, e.g. i2c controllers, gpio controllers, spi controllers, mdio controllers. There can be multiple instances of each block as well (so multiple MFD devices are instantiated for each driver). And of course, there can be multiple FPGAs in a system, each with different combinations of logical blocks. The drivers themselves are pretty specific to our FPGAs, thus it makes sense to use Kconfig to select a hardware platform to automatically select the set of MFD drivers (and top level bus drivers) that would apply. Would a source layout putting all the code under drivers/cisco be acceptable in this case, or do I need to move things around and spread out the Kconfig entries across directories? I note that a single drivers/cisco would simplify any related modifications to MAINTAINERS as well.

2 5

Linux 4 block device driver infrastructure
by Alexandru Goia Dec. 8, 2023

Dec. 8, 2023

Greetings ! I am a Unix/Linux hobbyist from Romania, interested in kernel stuff. I need some clarifications, related to block device subsystem in Linux 4, so I will ask them here, if you can answer me, please... 1) Why (in Linux 4) in struct block_device_operations, the (*open)(struct block_device *, fmode_t) has a different signature than the (*release)(struct gendisk *, fmode_t) ? Why open() uses block_device, while release() uses gendisk ? They are both in a struct block_device_operations. Why they not refer to the same thing ? I understand that gendisk refer to a real disk, and block_device (s) to logical disk (s) and partitions. But why the kernel developers have chosen to use different signatures ? 2) Release() is also synonim to close() ? 3) Why is not explicitely present a close() function ? 4) Why struct gendisk does not have inside it pointers to struct block_device ? Thank you very much, Alexander, Computer hobbyist, Romania

2 2

how to find the octeon driver in menuconfig?
by Chen shuo Nov. 14, 2023

Nov. 14, 2023

I want to recompile the octeon driver, when i searching the octeon,it logs out │ Symbol: AHCI_OCTEON [=n] │ │ Type : tristate │ │ Defined at drivers/ata/Kconfig:240 │ │ Prompt: Cavium Octeon Soc Serial ATA │ │ Depends on: ATA [=y] && HAS_DMA [=y] && SATA_AHCI_PLATFORM [=y] && CAVIUM_OCTEON_SOC │ │ Location: │ │ -> Device Drivers │ │ (1) -> Serial ATA and Parallel ATA drivers (libata) (ATA [=y]) │ │ -> Cavium Octeon Soc Serial ATA (AHCI_OCTEON [=n]) │ │ │ │ │ │ Symbol: CAVIUM_OCTEON_SOC [=CAVIUM_OCTEON_SOC] │ │ Type : unknown │ │ │ │ │ │ Symbol: CPU_CAVIUM_OCTEON [=CPU_CAVIUM_OCTEON] │ │ Type : unknown I have set the ATA [=y]、HAS_DMA [=y]、SATA_AHCI_PLATFORM [=y].But i don't know about CAVIUM_OCTEON_SOC When i search the CAVIUM_OCTEON_SOC,It print out: Symbol: CAVIUM_OCTEON_SOC [=CAVIUM_OCTEON_SOC] │ │ Type : unknown What should i do? Thanks Chen Shuo

2 1

What situation will an anonymous writer come?
by mlin＠mail.ustc.edu.cn Nov. 11, 2023

Nov. 11, 2023

Hi, I find this function __up_writer refering to an anonymous a writer? How does it occur? ``` // kernel/locking/rwsem.c static inline void __up_write(struct rw_semaphore *sem) { long tmp; DEBUG_RWSEMS_WARN_ON(sem->magic != sem, sem); /* * sem->owner may differ from current if the ownership is transferred * to an anonymous writer by setting the RWSEM_NONSPINNABLE bits. */ DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem); <------------------ is it necessary? preempt_disable(); rwsem_clear_owner(sem); tmp = atomic_long_fetch_add_release(-RWSEM_WRITER_LOCKED, &sem->count); if (unlikely(tmp & RWSEM_FLAG_WAITERS)) rwsem_wake(sem); preempt_enable(); } ``` I do a search by using `git blame` and find it's added in this commit 02f1082b003a0cd48f48f12533d969cdbf1c2b63, and in this commit d7d760efad70c7a030725499bf9f342f04af24dd, it refers to below situation that can have an anonymous writer: > There are use cases where a rwsem can be acquired by one task, but > released by another task. In thess cases, optimistic spinning may need > to be disabled. One example will be the filesystem freeze/thaw code > where the task that freezes the filesystem will acquire a write lock > on a rwsem and then un-owns it before returning to userspace. Later on, > another task will come along, acquire the ownership, thaw the filesystem > and release the rwsem. > > Bit 0 of the owner field was used to designate that it is a reader > owned rwsem. It is now repurposed to mean that the owner of the rwsem > is not known. If only bit 0 is set, the rwsem is reader owned. If bit > 0 and other bits are set, it is writer owned with an unknown owner. > One such value for the latter case is (-1L). So we can set owner to 1 for > reader-owned, -1 for writer-owned. The owner is unknown in both cases. > > To handle transfer of rwsem ownership, the higher level code should > set the owner field to -1 to indicate a write-locked rwsem with unknown > owner. Optimistic spinning will be disabled in this case. > > Once the higher level code figures who the new owner is, it can then > set the owner field accordingly. As it mentions that at higher level, we set -1 to owner subjectively in order to do an owner migration, and I only find it's used in only one place, i.e. percpu-rwsem in this commit 5a817641f68a6399a5fac8b7d2da67a73698ffed which has been removed in commit 7f26482a872c36b2ee87ea95b9dcd96e3d5805df. So does it mean an anonymous writer don't exist at current kernel? should we remove the second condition in this assert check? DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem); Thanks, Mu

2 1

how to use perf record effectively
by jim.cromie＠gmail.com Nov. 10, 2023

Nov. 10, 2023

I have a working patchset which de-duplicates the pr_debug per-callsite ( module, filename, function ) data. it loads that column data into 3 maple-trees, and simple accessor fns retrieve the data by lookup with the pr-debug address. So it stores these callsites: [ 0.721980] dyndbg: 3653 prdebugs in 307 modules, 19 KiB in ddebug tables, 114 kiB .. into these intervals: [ 104.047210] dyndbg: mt-funcs has 2174 entries [ 104.047816] dyndbg: mt-files has 539 entries [ 104.048410] dyndbg: mt-mods has 312 entries once these are loaded, the __dyndbg_sites section, which separates the 3 columns from the __dyndbg section, can be recycled.contains ALL GOOD SO FAR. BUT WHATS THE RUNTIME COST OF THIS ? perf stat -r200 cat /proc/dynamic_debug/control > /dev/null; this should be a good test - it calls all 3 accessors for each pr-debug in the kernel. but comparing master against this branch shows little change, and adding --table to see the variations in the runs suggests that the change is less than the variation within a test. MASTER - v6.6 bash-5.2# perf stat -r 200 cat /proc/dynamic_debug/control > /dev/null Performance counter stats for 'cat /proc/dynamic_debug/control' (200 runs): 10.29 msec task-clock # 0.713 CPUs utilized ( +- 0.56% ) 43 context-switches # 4.177 K/sec ( +- 0.03% ) 1 cpu-migrations # 97.142 /sec ( +- 5.80% ) 73 page-faults # 7.091 K/sec ( +- 0.10% ) 8906200 cycles # 0.865 GHz ( +- 0.17% ) 147349 stalled-cycles-frontend # 1.65% frontend cycles idle ( +- 0.18% ) 24971 stalled-cycles-backend # 0.28% backend cycles idle ( +- 8.18% ) 20589718 instructions # 2.31 insn per cycle # 0.01 stalled cycles per insn ( +- 0.02% ) 5470202 branches # 531.388 M/sec ( +- 0.01% ) 0 branch-misses 0.0144421 +- 0.0000647 seconds time elapsed ( +- 0.45% ) DE_DUPLICATION branch bash-5.2# perf stat -r200 cat /proc/dynamic_debug/control > /dev/null Performance counter stats for 'cat /proc/dynamic_debug/control' (200 runs): 21.89 msec task-clock # 0.622 CPUs utilized ( +- 0.69% ) 44 context-switches # 2.010 K/sec ( +- 0.12% ) 1 cpu-migrations # 45.693 /sec ( +- 3.87% ) 73 page-faults # 3.336 K/sec ( +- 0.10% ) 52017542 cycles # 2.377 GHz ( +- 0.54% ) 177875 stalled-cycles-frontend # 0.34% frontend cycles idle ( +- 0.48% ) 134469 stalled-cycles-backend # 0.26% backend cycles idle ( +- 4.24% ) 134707837 instructions # 2.59 insn per cycle # 0.00 stalled cycles per insn ( +- 0.30% ) 39386555 branches # 1.800 G/sec ( +- 0.29% ) 0 branch-misses 0.035188 +- 0.000167 seconds time elapsed ( +- 0.47% ) I tried perf stat record, then perf-diff on the results, it showed empty comparisons on a handful of event-types [jimc@frodo boots-dump]$ perf diff -v v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0* v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675* v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906* > foo group desc not available pmu capabilities not available group desc not available pmu capabilities not available group desc not available pmu capabilities not available group desc not available pmu capabilities not available group desc not available pmu capabilities not available group desc not available pmu capabilities not available group desc not available pmu capabilities not available [jimc@frodo boots-dump]$ more foo # Event 'task-clock' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1 Delta Abs/2 Delta Abs/3 Delta Abs/4 Delta Abs/5 Shared Object Symbol # .......... ........... ........... ........... ........... ........... ............. ...... # # Event 'context-switches' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1 Delta Abs/2 Delta Abs/3 Delta Abs/4 Delta Abs/5 Shared Object Symbol # .......... ........... ........... ........... ........... ........... ............. ...... # # Event 'cpu-migrations' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1 Delta Abs/2 Delta Abs/3 Delta Abs/4 Delta Abs/5 Shared Object Symbol # .......... ........... ........... ........... ........... ........... ............. ...... # # Event 'page-faults' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1 Delta Abs/2 Delta Abs/3 Delta Abs/4 Delta Abs/5 Shared Object Symbol # .......... ........... ........... ........... ........... ........... ............. ...... # # Event 'cycles' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1 Delta Abs/2 Delta Abs/3 Delta Abs/4 Delta Abs/5 Shared Object Symbol # .......... ........... ........... ........... ........... ........... ............. ...... # # Event 'stalled-cycles-frontend' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1 Delta Abs/2 Delta Abs/3 Delta Abs/4 Delta Abs/5 Shared Object Symbol # .......... ........... ........... ........... ........... ........... ............. ...... # # Event 'stalled-cycles-backend' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1 Delta Abs/2 Delta Abs/3 Delta Abs/4 Delta Abs/5 Shared Object Symbol # .......... ........... ........... ........... ........... ........... ............. ...... # # Event 'instructions' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1 Delta Abs/2 Delta Abs/3 Delta Abs/4 Delta Abs/5 Shared Object Symbol # .......... ........... ........... ........... ........... ........... ............. ...... # # Event 'branches' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1 Delta Abs/2 Delta Abs/3 Delta Abs/4 Delta Abs/5 Shared Object Symbol # .......... ........... ........... ........... ........... ........... ............. ...... # # Event 'branch-misses' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-00008-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1 Delta Abs/2 Delta Abs/3 Delta Abs/4 Delta Abs/5 Shared Object Symbol # .......... ........... ........... ........... ........... ........... ............. ...... # Does anyone here have enough experience with perf to recommend some tests to tease out the differences ?

1 0

How should I integrate my SPI driver into kernel?
by Patryk Nov. 4, 2023

Nov. 4, 2023

Hi, First, let me explain what I would like to achieve. I'm using the NXP LS1028a CPU, which will be used as a base for our SoM. This CPU features two types of SPI controllers: - 1 FlexSPI (cabable of Single/Dual/Quad/Octal mode) - 3 traditional SPIs Because of the design of our SoM all traditional SPIs are not available (designed to be used for other needs), so the only one left is FlexSPI. This FlexSPI will be used to communicate with 3 different things: - SPI NOR Flash - SPI NOR Flash - Hilsher netX90 As far as I understand FlexSPI is designed to work with Flash-like devices, which are obviously Flash memories. Each time one wants to send something over this FlexSPI it puts the data on the bus like this: - opcode | addr | dummy | data So communication with Flash memories won't be a problem. The problem I see is the communication with this Hilsher thing. Fortunately, we can put on the Hilsher our own FW that will handle SPI communication. So my idea was to: - develop a FW designed for Hilsher that will behave like a Flash device - develop a driver on the Linux side that will use this FlexSPI controller to communicate with Hisler in a Flash (thus FlexSPI) compatible manner. However, I'm not sure how I should go about this. I checked and e.g. driver that we use to communicate with SPI NOR Flash (jedec,spi-nor) uses something like spi-nor which in turn uses a driver spi-mem. Obviously, I get that the spi-nor is designed to work with SPI NOR flashes so that's not the way I'm going to go, however, I'm curious about this spi-mem thing. Is this spi-mem designed to work with devices that are like memory-mapped but not necessarily flash memories? What would you advise in this case? BR Patrick

1 0

Sharing the same SPI between two devices.
by Patryk Nov. 2, 2023

Nov. 2, 2023

Hi, I want to have two devices on the same SPI bus. These devices are: - SPI nor flash (QSPI compatible) - my custom device (SPI compatible). For SPI NOR flash I have the driver in the kernel, for my custom device I do not have such a driver. My question is - how the access to this particular SPI peripheral can be serialized between these two drivers in order to prevent simultaneous access that would result in a mess on the SPI? Do I have to modify the existing driver for SPI NOR flash or not? How about different configurations for these devices - as I mentioned one is QSPI compatible whereas the other one is SPI compatible. Can I reconfigure the SPI bus driver before each "transaction"? Best regards Patryk

3 2

How can I make dma_alloc to use the device's reserved memory?
by 김찬 Nov. 2, 2023

Nov. 2, 2023

Hi kernel experts, If some memory was reserved for a dma-able device using device tree's 'reserved-memory' property, if I do dma_alloc_coherent for the device, does it allocate memory in that reserved memory? I don't think so because dma_alloc_coherent works regardless of wether there is reserved memory for the device or not. Then how can I make the kernel reserve the dma memory from that reserved memory?  Thank you. Chan Kim

1 0