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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 11 Jun 2013 10:11:19 -0700
From:	Bin Gao <bin.gao@...ux.intel.com>
To:	Andy Shevchenko <andy.shevchenko@...il.com>
Cc:	Wolfram Sang <wsa@...-dreams.de>, 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 Sun, Jun 09, 2013 at 10:53:35PM +0300, Andy Shevchenko wrote:
> Please, try to avoid top posting in the future emails.
> 
> On Fri, Jun 7, 2013 at 12:26 AM, Bin Gao <bin.gao@...ux.intel.com> wrote:
> > With v4l2, the camera sensor i2c devices are taken over by v4l2 master
> > driver, i.e. ISP driver, and are not expected to be accessed from
> > user sapce by ioctl. So ISP driver has to register them by itself to
> > get all related information for further communication. Please check
> > v4l2_i2c_new_subdev_board() in drivers/media/video/v4l2-common.c for details.
> 
> Yes, this is legacy approach for non-DT/non-ACPI5 platforms.

So what's the new approach for DT/ACPI5 platforms?

> 
> > The platform code can definitely disallow calling i2c_register_board_info()
> > to register them but keep the i2c devices list and then let ISP driver register
> > them. But, problems come when a single kernel is going to run on two platforms
> > - one platform has ACPI5 and the other has SFI.
> 
> You have to forget about SFI. Your ISP subdevices use plain platform
> data anyway.

Why have to forget about SFI which is supported by upstream kernel?

> In ACPI 5 case v4l2 framework must be extended to cover that case.

To extend v4l2 framework is one of the options, but this helper is also one
option.

> > The dynamic unregister and then
> > register based on this new helper will not have dependency on firmware interface -
> > the same platform code will work for all platforms.
> 
> It's not a care of the ISP driver. I think you have to talk to Sakari
> about your issues.

We have to do it in the ISP driver if we want one binary kernel
supporting multiple platforms.

> > On Thu, Jun 06, 2013 at 11:32:06PM +0300, Andy Shevchenko wrote:
> >> On Thu, Jun 6, 2013 at 9:33 PM, Bin Gao <bin.gao@...ux.intel.com> wrote:
> >> > There is a requirement to get the i2c_client pointer dynamically without
> >> > knowing the bus and slave address. But we do know the client name,
> >> > i.e. the name in the i2c_board_info. This patch is to fit this requirement.
> >> >
> >> > A good example is that an ISP(Imaging Signal Processor) driver needs
> >> > register i2c camera sensor devices via v4l2, so it has to unregister
> >> > all i2c clients that were previously registered by calling
> >> > i2c_register_board_info(), and then re-register. For this case we
> >> > can use this helper to get i2c_client by passing the client name.
> >>
> >> Why ISP driver would like to register sensor drivers in the first place?
> >> That seems the task of platform code, or DT, or ACPI5
> >>
> >> Why do you need to re-register them at run time?
> 
> --
> With Best Regards,
> Andy Shevchenko
--
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/