linux-kernel - Re: [PATCH 1/3] ASoC: cs4271: Fix cs4271 I2C and SPI drivers automatic module loading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4b851d47bf1d03988a27671ae21208cdeed76837.camel@gmail.com>
Date: Fri, 17 Oct 2025 16:41:53 +0200
From: Alexander Sverdlin <alexander.sverdlin@...il.com>
To: Herve Codina <herve.codina@...tlin.com>
Cc: David Rhodes <david.rhodes@...rus.com>, Richard Fitzgerald	
 <rf@...nsource.cirrus.com>, Liam Girdwood <lgirdwood@...il.com>, Mark Brown
	 <broonie@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski	
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Jaroslav Kysela	
 <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, Nikita Shubin	
 <nikita.shubin@...uefel.me>, Axel Lin <axel.lin@...ics.com>, Brian Austin	
 <brian.austin@...rus.com>, linux-sound@...r.kernel.org, 
	patches@...nsource.cirrus.com, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 1/3] ASoC: cs4271: Fix cs4271 I2C and SPI drivers
 automatic module loading

Hi Herve,

On Fri, 2025-10-17 at 15:25 +0200, Alexander Sverdlin wrote:
> > > > In order to have the I2C or the SPI module loaded automatically, move
> > > > the MODULE_DEVICE_TABLE(of, ...) the core to I2C and SPI parts.
> > > > Also move cs4271_dt_ids itself from the core part to I2C and SPI parts
> > > > as both the call to MODULE_DEVICE_TABLE(of, ...) and the cs4271_dt_ids
> > > > table itself need to be in the same file.  
> > > 
> > > I'm a bit confused by this change.
> > > What do you have in SYSFS "uevent" entry for the real device?
> > 
> > Here is my uevent content:
> > --- 8<---
> > # cat /sys/bus/i2c/devices/3-0010/uevent 
> > DRIVER=cs4271
> > OF_NAME=cs4271
> > OF_FULLNAME=/i2c@...30000/cs4271@10
> > OF_COMPATIBLE_0=cirrus,cs4271
> > OF_COMPATIBLE_N=1
> > MODALIAS=of:Ncs4271T(null)Ccirrus,cs4271
> > # 
> > --- 8< ---
> 
> that's what I get with SPI-connected CS4271, and this is actually what I'd
> expect (linux-next as of 2433b8476165):
> 
> # cat /sys/bus/spi/devices/spi0.0/uevent
> DRIVER=cs4271
> OF_NAME=codec
> OF_FULLNAME=/soc/spi@...a0000/codec@0
> OF_COMPATIBLE_0=cirrus,cs4271
> OF_COMPATIBLE_N=1
> MODALIAS=spi:cs4271
> 
> > > If you consider spi_uevent() and i2c_device_uevent(), "MODALIAS=" in the
> > > "uevent" should be prefixed with either "spi:" or "i2c:".
> > > And this isn't what you adress in your patch.
> > > 
> > > You provide [identical] "of:" prefixed modalias to two different modules
> > > (not sure, how this should work), but cs4271 is not an MMIO device,
> > > so it should not generate an "of:" prefixed uevent.
> > > 
> > > Could you please show the relevant DT snippet for the affected HW?
> > 
> > And this is the related DT part:
> > --- 8< ---
> > &i2c3 {
> >   status = "okay";
> > 
> >   cs4271@10 {
> >   compatible = "cirrus,cs4271";
> >   reg = <0x10>;
> >   clocks = <&cru SCLK_I2S_8CH_OUT>;
> >   clock-names = "mclk";
> > 
> >   ...
> >   };
> > };
> > --- 8< ---
> > 
> > i2c3 is the following node:
> > https://elixir.bootlin.com/linux/v6.17.1/source/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi#L732
> 
> the above looks OK to me on the first glance, I'm really puzzled what
> is the reason for "of:" prefixed MODALIAS in the uevent for an i2c device.
> 
> I still believe, that the culprit is the creation of a platform device
> from the DT for an i2c device.
> 
> I don't have any real I2C-connected CS4271, but I think I could fake one
> in any DT just to verify how uevents would look like on my side.

indeed, that's what I've got for a fake I2C device:

# cat /sys/bus/i2c/devices/0-0010/uevent 
OF_NAME=cs4271
OF_FULLNAME=/soc/i2c@...0000/cs4271@10
OF_COMPATIBLE_0=cirrus,cs4271
OF_COMPATIBLE_N=1
MODALIAS=of:Ncs4271T(null)Ccirrus,cs4271

to me it looks like a bug somewhere in I2C core...

-- 
Alexander Sverdlin.