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] [day] [month] [year] [list]
Message-ID: <d51a3e4e0ea960df60d5ba91817ae50eba0a4026.camel@gmail.com>
Date: Fri, 17 Oct 2025 20:14:43 +0200
From: Alexander Sverdlin <alexander.sverdlin@...il.com>
To: Mark Brown <broonie@...nel.org>, Javier Martinez Canillas
	 <javierm@...hat.com>, Wolfram Sang <wsa@...-dreams.de>
Cc: Herve Codina <herve.codina@...tlin.com>, David Rhodes	
 <david.rhodes@...rus.com>, Richard Fitzgerald <rf@...nsource.cirrus.com>, 
 Liam Girdwood <lgirdwood@...il.com>, 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 Mark, Wolfram and all,

On Fri, 2025-10-17 at 16:01 +0100, Mark Brown wrote:
> On Fri, Oct 17, 2025 at 04:41:53PM +0200, Alexander Sverdlin wrote:
> 
> > 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...
> 
> IIRC this has been round the loop a few times and whatever you do
> something breaks.

it turns out it has been changed back in v4.18, with commit af503716ac14
("i2c: core: report OF style module alias for devices registered via OF"), 

but the change is not symmetric with SPI, and SPI core doesn't call 
of_device_uevent_modalias().

Not only is this inconsistent with SPI, but I anticipate yet another problem
if SPI would also adopt the same mechanism:

for instance there are many CODEC drivers in sound/soc, which have
SPI and I2C backends modelled as distinct modules.

In the current situation most of them have MODULE_DEVICE_TABLE(i2c,
and are therefore broken regarding module autoloading.

"Reparing" them as Herve proposed would result in I2C modules being
loaded only via "of:" style modalias and SPI still via "spi:". Which
sounds all but consistent.

If SPI ever adopts the same of_device_uevent_modalias(), both backends
would require "of:" prefixed modalias, and it will not be possible to
load the proper one for the corresponding bus type.

What are your thoughs on this?

-- 
Alexander Sverdlin.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ