Re: [PATCH RFT v3 4/4] hwmon: (spd5118) Add support for reading SPD data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 01.06.24 um 16:08 schrieb Thomas Weißschuh:

On 2024-06-01 06:48:29+0000, Guenter Roeck wrote:

<snip>

Makes sense. Another question:

This:

+        struct nvmem_config nvmem_config = {
+               .type = NVMEM_TYPE_EEPROM,
+               .name = dev_name(dev),
+               .id = NVMEM_DEVID_AUTO,

results in:

$ ls /sys/bus/nvmem/devices
0-00501  0-00512  0-00523  0-00534  cmos_nvram0
^^^^^^^  ^^^^^^^  ^^^^^^^  ^^^^^^^

which really doesn't look good. My current plan is to go with NVMEM_DEVID_NONE,
which results in

$ ls /sys/bus/nvmem/devices
0-0050	0-0051	0-0052	0-0053	cmos_nvram0

We could also used fixed strings, but "spd" results in "spd[1-4]" which
I think would be a bit misleading since the DDR3/4 SPD data format is
different, and "spd5118" would result in "spd5118[1-4]" which again would
look odd. Any suggestions ?
In order of descending, personal preference:

* spd-ddr5-[0-3] (.id = client->address - 0x50)

Hi,

this will break as soon as more than 8 DDR5 DIMMs are installed.

* spd-ddr5-[0-3] (NVMEM_DEVID_AUTO)
* Same with only "ddr5-"
* spd5118-[0-3]
* Your proposal from above
* nvmem[0-3] (default handling)
* 0-0050-[0-3]

Also can't a user of the eeprom already figure out which kind of module
it is by looking at the eeprom contents?
The first few bytes used for that seem to be compatible between at least
DDR4 and DDR5.

So using plain spd[1-4] could be enough.

This could cause problems when DDR6 arrives.
Personally i would prefer the spd5118-X (NVMEM_DEVID_AUTO) format.

Thanks,
Armin Wolf






[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux