linux-kernel - Re: i2c: introduce i2c helper i2c_find_client_by

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 21 Jun 2013 17:27:49 -0700
From:	Bin Gao <bin_gao@...ux.intel.com>
To:	Wolfram Sang <wsa@...-dreams.de>
CC:	Bin Gao <bin.gao@...ux.intel.com>,
	Andy Shevchenko <andy.shevchenko@...il.com>,
	linux-i2c@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: i2c: introduce i2c helper i2c_find_client_by_name()

On 6/19/2013 3:13 AM, Wolfram Sang wrote:
>
>> Even you prefer to extend v4l2, you still need this helper.
>> The idea is just to move the unregister/register from a specific ISP driver
>> to v4l2.
>>
>> I think you misunderstood my pionts somehow. Let me clarfiy a little bit:
>>
>> Current solution:
>> 1. Platform codes(on top of DT/ACPI5/SFI) don't call i2c_register_board_info(),
>> instead, prepare a table(kind of platform data) that has all camera i2c device information.
>> 2. ISP driver registers devices listed in the table to i2c core - this makes sure
>> v4l2 takes over these devices.
>> The problem with this solution is that when a camera device runs on both ACPI5 and
>> SFI, the platform codes will get a bit complicated and it's difficult to ensure one
>> binary kernel runs on both platforms(ACPI5 and SFI).
>> (To extend v4l2 with this solution doen't resolve my problem)
>>
>> Solution I'm suggesting:
>> 1. Let the platform codes call i2c_register_board_info() anyway.
>> 2. Since ISP driver knows which camera devices it supports, so it simply unregisters
>> those devices (get the client by the introduced helper), then register it within v4l2.
>> This solution ensure one binary kernel can run on both platforms.
>> (To extend v4l2 with this solution could not be feasible, the device table is
>> ISP driver specific, not v4l2 specific)
>
> I also wonder about the need to unregister. I have to admit I don't know
> much about I2C handling in v4l2. But if it requires unregistering from
> i2c core and registering to v4l2 core, then it sounds to me like we
> could check if there is a more fundamential cleanup needed? Deferring
> for now, looks like an issue worth looking at, yet there are other
> things in the queue first.
>

Platform codes are supposed to call i2c_register_board_info() or 
i2c_new_device() to register devices, we don't want to change this.
Not sure v4l2 can still take over the devices without 
unregistering/registering. Need look deeply into the v4l2 code...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/