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:	Wed, 19 Jun 2013 12:13:49 +0200
From:	Wolfram Sang <wsa@...-dreams.de>
To:	Bin Gao <bin.gao@...ux.intel.com>
Cc:	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()


> 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.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ