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]
Date:   Mon, 7 Nov 2016 23:14:22 -0300
From:   Javier Martinez Canillas <javier@....samsung.com>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     Kieran Bingham <kieran@...uared.org.uk>,
        Lee Jones <lee.jones@...aro.org>, linux-i2c@...r.kernel.org,
        linux-kernel@...r.kernel.org, sameo@...ux.intel.com
Subject: Re: [PATCHv7 10/11] mfd: as3722: Rid driver of superfluous I2C device
 ID structure

Hello Wolfram,

On 11/07/2016 08:09 PM, Wolfram Sang wrote:
> 
>> Remember that i2c_device_uevent() always reports modalias of the form
>> MODALIAS=i2c:<foo> even when your series allows to match without a I2C
>> device ID table.
> 
> Not always. Can't we do something similar like ACPI does with

Right, I meant that it always report a platform I2C modalias for both OF
and legacy platform data I2C device registration mechanisms.

> acpi_device_uevent_modalias()?
>

Yes, doing that is trivial. I posted a RFC patch about a year ago that
changes i2c_device_uevent() to report a proper OF modalias [0] as a part
of a series that fixed module autoload in a bunch of I2C drivers [1].

What's tricky is to make sure that the change won't introduce regressions
in current I2C drivers. I enumerated the possible issues if the I2C core
starts reporting OF modaliases and fixed some of them in the same series.

> I mean the whole point of this series is to remove the need of having an
> I2C device ID table...
>

Agreed, one of the issues was that the I2C table was needed anyways for
the core to match and pass a struct i2c_device_id to the probe's function.

This series solves that so once it lands, I plan to address the possible
issues in the I2C drivers and re-send [0] as a proper patch.

[0]: https://patchwork.kernel.org/patch/6903991/
[1]: https://lkml.org/lkml/2015/7/30/519

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ