From: Lee Jones <lee.jones@linaro.org>
To: Frank Rowand <frowand.list@gmail.com>
Cc: devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
broonie@kernel.org, michael@walle.cc,
linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com,
robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
andriy.shevchenko@linux.intel.com, robin.murphy@arm.com,
linus.walleij@linaro.org, linux@roeck-us.net
Subject: Re: [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes
Date: Wed, 24 Jun 2020 07:41:45 +0100 [thread overview]
Message-ID: <20200624064145.GC954398@dell> (raw)
In-Reply-To: <30f03734-61fd-1b6b-bf11-21b6423a7c50@gmail.com>
On Tue, 23 Jun 2020, Frank Rowand wrote:
> On 2020-06-11 14:10, Lee Jones wrote:
> > Currently, when a child platform device (sometimes referred to as a
> > sub-device) is registered via the Multi-Functional Device (MFD) API,
> > the framework attempts to match the newly registered platform device
> > with its associated Device Tree (OF) node. Until now, the device has
> > been allocated the first node found with an identical OF compatible
> > string. Unfortunately, if there are, say for example '3' devices
> > which are to be handled by the same driver and therefore have the same
> > compatible string, each of them will be allocated a pointer to the
> > *first* node.
>
> As you mentioned elsewhere in this thread, this series "fixes" the
> problem related to the "stericsson,ab8500-pwm" compatible.
>
> I know, I said I would drop discussion of that compatible, but bear
> with me for a second. :-)
>
> The "problem" is that the devices for multiple mfd child nodes with
> the same compatible value of "stericsson,ab8500-pwm" will all have
> a pointer to the first child node. At the moment the same child
> of_node being used by more than one device does not cause any
> incorrect behavior.
>
> Just in case the driver for "stericsson,ab8500-pwm" is modified
> in a way that the child of_node needs to be distinct for each
> device, and that changes gets back ported, it would be useful
> to have Fixes: tags for this patch series.
>
> So, at your discretion (and I'll let you worry about the correct
> Fixes: tag format), this series fixes:
>
> bad76991d7847b7877ae797cc79745d82ffd9120 mfd: Register ab8500 devices using the newly DT:ed MFD API
This patch isn't actually broken.
The issue is the DTB, which [0] addresses.
[0]
https://lkml.kernel.org/lkml/20200622083432.1491715-1-lee.jones@linaro.org/
> c94bb233a9fee3314dc5d9c7de9fa702e91283f2 mfd: Make MFD core code Device Tree and IRQ domain aware
It sounds reasonable to list this one, thanks.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Frank Rowand <frowand.list@gmail.com>
Cc: andy.shevchenko@gmail.com, michael@walle.cc, robh+dt@kernel.org,
broonie@kernel.org, devicetree@vger.kernel.org,
linus.walleij@linaro.org, linux@roeck-us.net,
andriy.shevchenko@linux.intel.com, robin.murphy@arm.com,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes
Date: Wed, 24 Jun 2020 07:41:45 +0100 [thread overview]
Message-ID: <20200624064145.GC954398@dell> (raw)
In-Reply-To: <30f03734-61fd-1b6b-bf11-21b6423a7c50@gmail.com>
On Tue, 23 Jun 2020, Frank Rowand wrote:
> On 2020-06-11 14:10, Lee Jones wrote:
> > Currently, when a child platform device (sometimes referred to as a
> > sub-device) is registered via the Multi-Functional Device (MFD) API,
> > the framework attempts to match the newly registered platform device
> > with its associated Device Tree (OF) node. Until now, the device has
> > been allocated the first node found with an identical OF compatible
> > string. Unfortunately, if there are, say for example '3' devices
> > which are to be handled by the same driver and therefore have the same
> > compatible string, each of them will be allocated a pointer to the
> > *first* node.
>
> As you mentioned elsewhere in this thread, this series "fixes" the
> problem related to the "stericsson,ab8500-pwm" compatible.
>
> I know, I said I would drop discussion of that compatible, but bear
> with me for a second. :-)
>
> The "problem" is that the devices for multiple mfd child nodes with
> the same compatible value of "stericsson,ab8500-pwm" will all have
> a pointer to the first child node. At the moment the same child
> of_node being used by more than one device does not cause any
> incorrect behavior.
>
> Just in case the driver for "stericsson,ab8500-pwm" is modified
> in a way that the child of_node needs to be distinct for each
> device, and that changes gets back ported, it would be useful
> to have Fixes: tags for this patch series.
>
> So, at your discretion (and I'll let you worry about the correct
> Fixes: tag format), this series fixes:
>
> bad76991d7847b7877ae797cc79745d82ffd9120 mfd: Register ab8500 devices using the newly DT:ed MFD API
This patch isn't actually broken.
The issue is the DTB, which [0] addresses.
[0]
https://lkml.kernel.org/lkml/20200622083432.1491715-1-lee.jones@linaro.org/
> c94bb233a9fee3314dc5d9c7de9fa702e91283f2 mfd: Make MFD core code Device Tree and IRQ domain aware
It sounds reasonable to list this one, thanks.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2020-06-24 6:44 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 19:10 [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes Lee Jones
2020-06-11 19:10 ` Lee Jones
2020-06-11 19:10 ` [PATCH v2 2/3] mfd: core: Fix formatting of MFD helpers Lee Jones
2020-06-11 19:10 ` Lee Jones
2020-06-12 12:27 ` Frank Rowand
2020-06-12 12:27 ` Frank Rowand
2020-06-11 19:10 ` [PATCH v2 3/3] mfd: core: Add OF_MFD_CELL_REG() helper Lee Jones
2020-06-11 19:10 ` Lee Jones
2020-06-12 12:28 ` Frank Rowand
2020-06-12 12:28 ` Frank Rowand
2020-06-12 12:26 ` [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes Frank Rowand
2020-06-12 12:26 ` Frank Rowand
2020-06-15 1:19 ` Frank Rowand
2020-06-15 1:19 ` Frank Rowand
2020-06-15 9:26 ` Lee Jones
2020-06-15 9:26 ` Lee Jones
2020-06-18 17:34 ` Frank Rowand
2020-06-18 17:34 ` Frank Rowand
2020-06-22 8:50 ` Lee Jones
2020-06-22 14:32 ` Frank Rowand
2020-06-22 14:35 ` Frank Rowand
2020-06-22 15:10 ` Lee Jones
2020-06-22 18:01 ` Frank Rowand
2020-06-22 18:04 ` Frank Rowand
2020-06-22 19:11 ` Lee Jones
2020-06-22 22:23 ` Frank Rowand
2020-06-23 1:17 ` Frank Rowand
2020-06-23 1:37 ` Frank Rowand
2020-06-23 6:47 ` Lee Jones
2020-06-23 17:55 ` Frank Rowand
2020-06-23 17:55 ` Frank Rowand
2020-06-23 19:59 ` Lee Jones
2020-06-23 19:59 ` Lee Jones
2020-06-23 22:33 ` Frank Rowand
2020-06-23 22:33 ` Frank Rowand
2020-06-24 7:46 ` Lee Jones
2020-06-24 7:46 ` Lee Jones
2020-06-24 15:51 ` Frank Rowand
2020-06-24 15:51 ` Frank Rowand
2020-06-24 16:14 ` Lee Jones
2020-06-24 16:14 ` Lee Jones
2020-06-24 16:25 ` Frank Rowand
2020-06-24 16:25 ` Frank Rowand
2020-06-22 8:09 ` Lee Jones
2020-06-22 16:09 ` Frank Rowand
2020-06-22 16:53 ` Lee Jones
2020-06-23 22:21 ` Frank Rowand
2020-06-23 22:21 ` Frank Rowand
2020-06-24 6:45 ` Lee Jones
2020-06-24 6:45 ` Lee Jones
2020-06-23 23:03 ` Frank Rowand
2020-06-23 23:03 ` Frank Rowand
2020-06-24 6:41 ` Lee Jones [this message]
2020-06-24 6:41 ` Lee Jones
2020-06-24 7:47 ` Michael Walle
2020-06-24 7:47 ` Michael Walle
2020-06-24 8:23 ` Lee Jones
2020-06-24 8:23 ` Lee Jones
2020-06-24 9:19 ` Michael Walle
2020-06-24 9:19 ` Michael Walle
2020-06-24 11:24 ` Lee Jones
2020-06-24 11:24 ` Lee Jones
-- strict thread matches above, loose matches on Subject: below --
2020-06-11 19:12 Lee Jones
2020-06-11 19:12 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200624064145.GC954398@dell \
--to=lee.jones@linaro.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=michael@walle.cc \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.