linux-kernel - Re: [PATCHv5 0/8] 2c: Relax mandatory I2C ID table passing

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:	Tue, 10 May 2016 01:31:18 -0400
From:	Javier Martinez Canillas <javier@....samsung.com>
To:	Kieran Bingham <kieran@...uared.org.uk>,
	Wolfram Sang <wsa@...-dreams.de>,
	Lee Jones <lee.jones@...aro.org>
Cc:	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
	grant.likely@...aro.org, sameo@...ux.intel.com
Subject: Re: [PATCHv5 0/8] 2c: Relax mandatory I2C ID table passing

Hello Kieran,

On 05/04/2016 11:14 AM, Kieran Bingham wrote:
> This patch set finally pops up again, after a long time stuck somewhere in the
> midst of my stack.
> 
> As it stood last year, the requirements were to rename probe2 to probe_new, and
> ensure that it was correctly tested. The rename was the easy bit, but the
> testing took me more time to get things set up properly. And other commitments
> then got in the way of things. Of course this patch set has also been rebased
> as well, but there wasn't any major pain there.
> 
> Testing
> -------
> 
> To try to establish testing, I have used a beagle-bone-black, and a DS1307 RTC
> connected to the BBB SCL and SDA lines. The main reason for these choices is
> accesibility. i.e. I have them, and the BBB readily boots a kernel for me to
> test and iterate with.
> 
> I've tested the device with i2cdetect, and then worked through testing the
> sysfs interface, device tree, and module autoloading, each time ensuring that
> the RTC enumerates and operates
> 
> * new_device (built-in, and external module)
>   echo ds1307 0x68 > /sys/bus/i2c/devices/i2c-2/new_device
>   cat /sys/class/rtc/rtc0/date
> 
>  - Both of those worked fine.
> 
> * Device Tree
>   I tested that the device would still register by adding a node in the device
>   tree for the board, and testing with a built-in module. 
> 
>  - This worked fine.
> 
> * Module Autoloading
>   With the device tree node in the board dts file, it wouldn't automatically
>   load from the external module. This was due to the rtc-ds1307 module not
>   exporting an of_match table, and not yet having Javier's "report OF style
>   modalias when probing using DT" [0]  patch applied
> 
>  - With the module updated, and Javiers patch applied, the module autoloads
> 
> Finally, I feel I can safely add this tag to the patch set:
> Tested-by: Kieran Bingham <kieran@...gham.xyz>
>

Same here, I've tested this series using an Exynos5800 Peach Pi Chromebook
that has a I2C touchpad device (Atmel mXT540S). So I used this series and
removed the i2c_device_id table from the device driver.

The driver could match correctly using the of_device_id table and also the
module was auto-loaded when using my mentioned RFC patch to report OF style
module aliases instead of always using the legacy one.

I've also reviewed the patches and the changes looks good to me. I hope the
patches can finally land since have been in the list for almost 2 years [0].

[0]: https://lkml.org/lkml/2014/8/28/283

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