linux-kernel - Re: [PATCH v3] software node: Implement device_get_match

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] [day] [month] [year] [list]

Message-ID: <Zn2ZkcT5fsUrYUdJ@google.com>
Date: Thu, 27 Jun 2024 09:55:45 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Sui Jingfeng <sui.jingfeng@...ux.dev>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	linux-acpi@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org, Daniel Scally <djrscally@...il.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
	Biju Das <biju.das.jz@...renesas.com>
Subject: Re: [PATCH v3] software node: Implement device_get_match_data fwnode
 callback

On Sun, Jun 23, 2024 at 12:58:25AM -0700, Dmitry Torokhov wrote:
> On Sun, Jun 23, 2024 at 03:38:23PM +0800, Sui Jingfeng wrote:
> > Hi,
> > 
> > On 6/23/24 03:29, Dmitry Torokhov wrote:
> > > > In case of non-OF match (which
> > > > > includes the case where you use software nodes) the match data is coming
> > > > > from matching spi_device_id entry in the driver.
> > > > 
> > > > We don't care about much how it is probed now, rather, after the driver
> > > > probed by a non-OF way, how does the additional devices properties
> > > > can be get?
> > > > 
> > > > 
> > > > Say:
> > > > 
> > > > 1) "device_property_read_u32(dev, "rotation", &rotation);" and
> > > > 2) "!device_property_read_string(dev, "pervasive,thermal-zone",
> > > > &thermal_zone))"
> > > > 
> > > > 
> > > > For those spi/i2c/platform devices, what we argues are that
> > > > those drivers really should just depend on "OF" before we have
> > > > a reliable fwnode API backend to redirect to.
> > > They are working fine without such restriction now,
> > 
> > 
> > You still *NOT* answer where the additional devices properties[1][2]
> > can be acquire.
> > 
> > [1] device_property_read_u32(dev, "rotation", &rotation)
> > 
> > [2] device_property_read_string(dev, "pervasive,thermal-zone",
> > &thermal_zone))
> > 
> > 
> > > so I see absolutely no reason imposing this restriction.
> > 
> > The reason is rigorous.
> > 
> > You are acclaiming that works by hardcode or by ignoring the flaws
> > is fine, then all driver are working fine by *your* standard.
> > 
> > Your personal standard has nothing to do with this patch.
> > 
> > > > Where the additional device_property_read_xxxx() calls redirect to?
> > > > 
> > > > What if users want to invoke more device_property_read_xxxx() function?
> > > They are being directed to first the primary FW node instance, which may
> > > be either OF, ACPI, or SW node, and then, if property is not present
> > > there, to the secondary FW node, which can be either again.
> > 
> > 
> > What I'm asking is, on the non-OF and no-ACPI cases, where's those
> > device_property_read_xxx() calls can be directed to?
> > 
> > > At no point ->device_get_match_data() callback in involved in this
> > > process.
> > > 
> > 
> > The patch is written for people who need it, not for people who don't.
> > 
> > It will be involved if the device is associated with software node.
> > Its for fwnode API user to get a consistent experience, that is
> > to get a matching data without introduce extra/duplicated match
> > mechanism.
> > 
> > The patch is focus on fixing the undefined behavior, is discussing
> > the correct way to consolidate the fwnode API. Its not going to
> > discuss how does the those *old" and/or how does those non-fwnode
> > systems works.
> > 
> > Its NOT discussing how does the driver itself can be probed, a driver
> > can be probed multiple way and is another question. Being probed and
> > extract matching data can two different thing and is perfectly valid.
> > 
> > Your problem is that you are not fully understand what other people
> > does before you rush into the discussion. You are putting restrictions
> > onto other people, while leaving the problem itself there unsolved.
> > 
> > Its not a place to express your personal value or you personal status,
> > such as, you are "ready" or "not ready" for something. Or persuading
> > somebody should get used to what or teaching people to talks with a
> > whatever tone like a God.
> > 
> > None of those junk words are technical, I can not see constructive
> > ideas.
> 
> Yes, indeed, it appears that further discussion is pointless at this
> point.
> 
> Andy, Heikki, Greg, and others: FWIW this is a NAK from me.

Even though I said I will not discuss this topic, I stumbled across some
of your patches to the DRM subsystem and it looks like what you want is
actually to help push through this set of patches allowing buses (such as
platform) define their own ->get_match_data() callback so that
device_get_match_data() can be used universally:

https://lore.kernel.org/all/20230804161728.394920-2-biju.das.jz@bp.renesas.com/

Thanks.

-- 
Dmitry