On 10/3/19 9:41 PM, Mark Brown wrote: > On Thu, Oct 03, 2019 at 09:21:06PM +0200, Jacek Anaszewski wrote: >> On 10/3/19 8:35 PM, Mark Brown wrote: >>> On Thu, Oct 03, 2019 at 07:43:17PM +0200, Jacek Anaszewski wrote: >>>> On 10/3/19 2:47 PM, Jean-Jacques Hiblot wrote: >>>>> On 03/10/2019 12:42, Sebastian Reichel wrote: >>>>>> On Thu, Oct 03, 2019 at 10:28:09AM +0200, Jean-Jacques Hiblot wrote: > >>> This mail has nothing relevant in the subject line and pages of quotes >>> before the question for me, it's kind of lucky I noticed it.... > >> Isn't it all about creating proper filters? > > My point there is that there's nothing obvious in the mail that suggests > it should get past filters - just being CCed on a mail isn't super > reliable, people often get pulled in due to things like checkpatch or > someone copying a CC list from an earlier patch series where there were > things were relevant. OK, updated the subject. >>>> I wonder if it wouldn't make sense to add support for fwnode >>>> parsing to regulator core. Or maybe it is either somehow supported >>>> or not supported on purpose? > >>> Anything attempting to use the regulator DT bindings in ACPI has very >>> serious problems, ACPI has its own power model which isn't compatible >>> with that used in DT. > >> We have a means for checking if fwnode refers to of_node: > >> is_of_node(const struct fwnode_handle *fwnode) > >> Couldn't it be employed for OF case? > > Why would we want to do that? We'd continue to support only DT systems, > just with code that's less obviously DT only and would need to put > checks in. I'm not seeing an upside here. For instance few weeks ago we had a patch [0] in the LED core switching from using struct device's of_node property to fwnode for conveying device property data. And this transition to fwnode property API can be observed as a frequent pattern across subsystems. Recently there is an ongoing effort aiming to add generic support for handling regulators in the LED core [1], but it turns out to require bringing back initialization of of_node property for devm_regulator_get_optional() to work properly. Support for OF related fwnodes in regulator core could help reducing this noise. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/leds/led-class.c?id=fd81d7e946c6bdb86dbf0bd88fee3e1a545e7979 [1] https://lore.kernel.org/linux-leds/20190923102059.17818-4-jjhiblot@xxxxxx/ -- Best regards, Jacek Anaszewski
