On 10/3/19 9:41 PM, Mark Brown wrote:
On Thu, Oct 03, 2019 at 09:21:06PM +0200, Jacek Anaszewski wrote:OK, updated the subject.
On 10/3/19 8:35 PM, Mark Brown wrote:My point there is that there's nothing obvious in the mail that suggests
On Thu, Oct 03, 2019 at 07:43:17PM +0200, Jacek Anaszewski wrote:Isn't it all about creating proper filters?
On 10/3/19 2:47 PM, Jean-Jacques Hiblot wrote:This mail has nothing relevant in the subject line and pages of quotes
On 03/10/2019 12:42, Sebastian Reichel wrote:
On Thu, Oct 03, 2019 at 10:28:09AM +0200, Jean-Jacques Hiblot wrote:
before the question for me, it's kind of lucky I noticed it....
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.
For instance few weeks ago we had a patch [0] in the LED core switchingWhy would we want to do that? We'd continue to support only DT systems,We have a means for checking if fwnode refers to of_node:I wonder if it wouldn't make sense to add support for fwnodeAnything attempting to use the regulator DT bindings in ACPI has very
parsing to regulator core. Or maybe it is either somehow supported
or not supported on purpose?
serious problems, ACPI has its own power model which isn't compatible
with that used in DT.
is_of_node(const struct fwnode_handle *fwnode)
Couldn't it be employed for OF case?
just with code that's less obviously DT only and would need to put
checks in. I'm not seeing an upside here.
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/