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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 1 Dec 2020 00:05:11 +0000 From: Dan Scally <djrscally@...il.com> To: Laurent Pinchart <laurent.pinchart@...asonboard.com> Cc: Sakari Ailus <sakari.ailus@....fi>, linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org, linux-gpio@...r.kernel.org, linux-i2c@...r.kernel.org, linux-media@...r.kernel.org, devel@...ica.org, rjw@...ysocki.net, lenb@...nel.org, gregkh@...uxfoundation.org, mika.westerberg@...ux.intel.com, andriy.shevchenko@...ux.intel.com, linus.walleij@...aro.org, bgolaszewski@...libre.com, wsa@...nel.org, yong.zhi@...el.com, sakari.ailus@...ux.intel.com, bingbu.cao@...el.com, tian.shu.qiu@...el.com, mchehab@...nel.org, robert.moore@...el.com, erik.kaneda@...el.com, pmladek@...e.com, rostedt@...dmis.org, sergey.senozhatsky@...il.com, linux@...musvillemoes.dk, kieran.bingham+renesas@...asonboard.com, jacopo+renesas@...ndi.org, laurent.pinchart+renesas@...asonboard.com, jorhand@...ux.microsoft.com, kitakar@...il.com, heikki.krogerus@...ux.intel.com Subject: Re: [PATCH 18/18] ipu3: Add driver for dummy INT3472 ACPI device On 30/11/2020 23:21, Laurent Pinchart wrote: >>> Instead, I propose, that you add this as an option to the tps68470 driver >>> that figures out whether the ACPI device for the tps68470 device actually >>> describes something else, in a similar fashion you do with the cio2-bridge >>> driver. I think it may need a separate Kconfig option albeit this and >>> cio2-bridge cannot be used separately. >> It actually occurs to me that that may not work (I know I called that >> out as an option we considered, but that was a while ago actually). The >> reason I wasn't worried about the existing tps68470 driver binding to >> these devices is that it's an i2c driver, and these dummy devices don't >> have an I2cSerialBusV2, so no I2C device is created by them the kernel. >> >> Won't that mean the tps68470 driver won't ever be probed for these devices? > I think we can create a platform driver in that case. The same module > can register multiple drivers (platform and I2C). Ah, I follow. OK, that's an option then.
Powered by blists - more mailing lists