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: <20211119074015.kji2hzarevxgfl5l@pengutronix.de>
Date:   Fri, 19 Nov 2021 08:40:15 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-spi@...r.kernel.org,
        Javier Martinez Canillas <javierm@...hat.com>,
        kernel@...gutronix.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] spidev: Make probe to fail early if a spidev compatible
 is used

On Thu, Nov 18, 2021 at 06:21:27PM +0000, Mark Brown wrote:
> On Wed, Nov 10, 2021 at 08:42:47AM +0100, Uwe Kleine-König wrote:
> 
> > Up to 6840615f85f6 the choices you had to use the spidev driver were
> > (assuing a dt machine):
> 
> >  a) Use compatible = "spidev" and ignore the warning
> >  b) Use compatible = $chipname and add $chipname to the list of
> >     supported devices for the spidev driver. (e.g. "rohm,dh2228fv")
> >  c) Use compatible = $chipname and force binding the spidev driver using
> > 
> >    	echo spidev > /sys/bus/spi/devices/spiX.Y/driver_override
> > 	echo spiX.Y > /sys/bus/spi/drivers/spidev/bind
> 
> > Commit 6840615f85f6 changed that in situation a) you had to switch to c)
> > (well, or b) adding "spidev" to the spi id list).
> 
> > With the change introduced by this patch, you make it impossible to bind
> > the spidev driver to such a device (without kernel source changes) even
> > using approach c). I wonder if this is too harsh given that changing the
> > dtb is difficult on some machines.
> 
> Following up from discussion on IRC: it's not clear to me how option c
> is affected?  The change only causes an error if of_device_is_compatible()
> is true and driver_override works with spi_device_id not compatibles (I
> didn't actually test, in the middle of some other stuff right now).

It affects c) only if the device tree has a device with compatible =
"spidev". For such a device the history is:

  - Before 956b200a846e ("spi: spidev: Warn loudly if instantiated from
    DT as "spidev"") in v4.1-rc1:
    Just bound silently

  - After 956b200a846e up to 6840615f85f6 ("spi: spidev: Add SPI ID
    table") in v5.15-rc6:
    The device was automatically bound with a warning

  - After 6840615f85f6:
    The device doesn't bind automatically, when using driver_override
    you get a warning.

  - With the proposed patch:
    The device cannot be bound even using driver_override

Not this affects also devices that use

	compatible = "myvender,devicename", "spidev";

.

Best regards
Uwe




-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ