This adds syscon_regmap_lookup_by_phandle_optional() function to get an
optional regmap.
It behaves the same as syscon_regmap_lookup_by_phandle() except where
there is no regmap phandle. In this case, instead of returning -ENODEV,
the function returns NULL. This makes error checking simpler when the
regmap phandle is optional.
Suggested-by: Nicolas Boichat <[email protected]>
Signed-off-by: Enric Balletbo i Serra <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
---
Changes in v2:
- Add Matthias r-b tag.
- Add the explanation from the patch description to the code.
- Return NULL instead of -ENOTSUPP when regmap helpers are not enabled.
drivers/mfd/syscon.c | 18 ++++++++++++++++++
include/linux/mfd/syscon.h | 11 +++++++++++
2 files changed, 29 insertions(+)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca465794ea9c..c6f139b2e0c0 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -255,6 +255,24 @@ struct regmap *syscon_regmap_lookup_by_phandle_args(struct device_node *np,
}
EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle_args);
+/*
+ * It behaves the same as syscon_regmap_lookup_by_phandle() except where
+ * there is no regmap phandle. In this case, instead of returning -ENODEV,
+ * the function returns NULL.
+ */
+struct regmap *syscon_regmap_lookup_by_phandle_optional(struct device_node *np,
+ const char *property)
+{
+ struct regmap *regmap;
+
+ regmap = syscon_regmap_lookup_by_phandle(np, property);
+ if (IS_ERR(regmap) && PTR_ERR(regmap) == -ENODEV)
+ return NULL;
+
+ return regmap;
+}
+EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle_optional);
+
static int syscon_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
index 7f20e9b502a5..fecc2fa2a364 100644
--- a/include/linux/mfd/syscon.h
+++ b/include/linux/mfd/syscon.h
@@ -28,6 +28,9 @@ extern struct regmap *syscon_regmap_lookup_by_phandle_args(
const char *property,
int arg_count,
unsigned int *out_args);
+extern struct regmap *syscon_regmap_lookup_by_phandle_optional(
+ struct device_node *np,
+ const char *property);
#else
static inline struct regmap *device_node_to_regmap(struct device_node *np)
{
@@ -59,6 +62,14 @@ static inline struct regmap *syscon_regmap_lookup_by_phandle_args(
{
return ERR_PTR(-ENOTSUPP);
}
+
+static inline struct regmap *syscon_regmap_lookup_by_phandle_optional(
+ struct device_node *np,
+ const char *property)
+{
+ return NULL;
+}
+
#endif
#endif /* __LINUX_MFD_SYSCON_H__ */
--
2.28.0
On Tue, Nov 10, 2020 at 5:13 PM Enric Balletbo i Serra
<[email protected]> wrote:
>
> This adds syscon_regmap_lookup_by_phandle_optional() function to get an
> optional regmap.
>
> It behaves the same as syscon_regmap_lookup_by_phandle() except where
> there is no regmap phandle. In this case, instead of returning -ENODEV,
> the function returns NULL. This makes error checking simpler when the
> regmap phandle is optional.
>
> Suggested-by: Nicolas Boichat <[email protected]>
> Signed-off-by: Enric Balletbo i Serra <[email protected]>
> Reviewed-by: Matthias Brugger <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
On Tue, 10 Nov 2020, Enric Balletbo i Serra wrote:
> This adds syscon_regmap_lookup_by_phandle_optional() function to get an
> optional regmap.
>
> It behaves the same as syscon_regmap_lookup_by_phandle() except where
> there is no regmap phandle. In this case, instead of returning -ENODEV,
> the function returns NULL. This makes error checking simpler when the
> regmap phandle is optional.
>
> Suggested-by: Nicolas Boichat <[email protected]>
> Signed-off-by: Enric Balletbo i Serra <[email protected]>
> Reviewed-by: Matthias Brugger <[email protected]>
> ---
>
> Changes in v2:
> - Add Matthias r-b tag.
> - Add the explanation from the patch description to the code.
> - Return NULL instead of -ENOTSUPP when regmap helpers are not enabled.
>
> drivers/mfd/syscon.c | 18 ++++++++++++++++++
> include/linux/mfd/syscon.h | 11 +++++++++++
> 2 files changed, 29 insertions(+)
Applied, thanks.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi Lee,
On 13/11/2020 11:19, Lee Jones wrote:
> On Tue, 10 Nov 2020, Enric Balletbo i Serra wrote:
>
>> This adds syscon_regmap_lookup_by_phandle_optional() function to get an
>> optional regmap.
>>
>> It behaves the same as syscon_regmap_lookup_by_phandle() except where
>> there is no regmap phandle. In this case, instead of returning -ENODEV,
>> the function returns NULL. This makes error checking simpler when the
>> regmap phandle is optional.
>>
>> Suggested-by: Nicolas Boichat <[email protected]>
>> Signed-off-by: Enric Balletbo i Serra <[email protected]>
>> Reviewed-by: Matthias Brugger <[email protected]>
>> ---
>>
>> Changes in v2:
>> - Add Matthias r-b tag.
>> - Add the explanation from the patch description to the code.
>> - Return NULL instead of -ENOTSUPP when regmap helpers are not enabled.
>>
>> drivers/mfd/syscon.c | 18 ++++++++++++++++++
>> include/linux/mfd/syscon.h | 11 +++++++++++
>> 2 files changed, 29 insertions(+)
>
> Applied, thanks.
>
I've a series [1] that's based on this patch, could you provide a stable branch
for it, so that I can take the series.
Thanks,
Matthias
[1]
https://lore.kernel.org/linux-mediatek/[email protected]/
On Tue, 17 Nov 2020, Matthias Brugger wrote:
> Hi Lee,
>
> On 13/11/2020 11:19, Lee Jones wrote:
> > On Tue, 10 Nov 2020, Enric Balletbo i Serra wrote:
> >
> > > This adds syscon_regmap_lookup_by_phandle_optional() function to get an
> > > optional regmap.
> > >
> > > It behaves the same as syscon_regmap_lookup_by_phandle() except where
> > > there is no regmap phandle. In this case, instead of returning -ENODEV,
> > > the function returns NULL. This makes error checking simpler when the
> > > regmap phandle is optional.
> > >
> > > Suggested-by: Nicolas Boichat <[email protected]>
> > > Signed-off-by: Enric Balletbo i Serra <[email protected]>
> > > Reviewed-by: Matthias Brugger <[email protected]>
> > > ---
> > >
> > > Changes in v2:
> > > - Add Matthias r-b tag.
> > > - Add the explanation from the patch description to the code.
> > > - Return NULL instead of -ENOTSUPP when regmap helpers are not enabled.
> > >
> > > drivers/mfd/syscon.c | 18 ++++++++++++++++++
> > > include/linux/mfd/syscon.h | 11 +++++++++++
> > > 2 files changed, 29 insertions(+)
> >
> > Applied, thanks.
> >
>
> I've a series [1] that's based on this patch, could you provide a stable
> branch for it, so that I can take the series.
Why can't you base it off of for-mfd-next?
https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=for-mfd-next
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
On 17/11/2020 13:37, Lee Jones wrote:
> On Tue, 17 Nov 2020, Matthias Brugger wrote:
>
>> Hi Lee,
>>
>> On 13/11/2020 11:19, Lee Jones wrote:
>>> On Tue, 10 Nov 2020, Enric Balletbo i Serra wrote:
>>>
>>>> This adds syscon_regmap_lookup_by_phandle_optional() function to get an
>>>> optional regmap.
>>>>
>>>> It behaves the same as syscon_regmap_lookup_by_phandle() except where
>>>> there is no regmap phandle. In this case, instead of returning -ENODEV,
>>>> the function returns NULL. This makes error checking simpler when the
>>>> regmap phandle is optional.
>>>>
>>>> Suggested-by: Nicolas Boichat <[email protected]>
>>>> Signed-off-by: Enric Balletbo i Serra <[email protected]>
>>>> Reviewed-by: Matthias Brugger <[email protected]>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - Add Matthias r-b tag.
>>>> - Add the explanation from the patch description to the code.
>>>> - Return NULL instead of -ENOTSUPP when regmap helpers are not enabled.
>>>>
>>>> drivers/mfd/syscon.c | 18 ++++++++++++++++++
>>>> include/linux/mfd/syscon.h | 11 +++++++++++
>>>> 2 files changed, 29 insertions(+)
>>>
>>> Applied, thanks.
>>>
>>
>> I've a series [1] that's based on this patch, could you provide a stable
>> branch for it, so that I can take the series.
>
> Why can't you base it off of for-mfd-next?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=for-mfd-next
>
I can do that, if you are willing to not overwrite the commit history. In my
case it can happen that I drop a patch from my for-next branch as I realize that
it e.g. breaks something. I think that's the reason why normally a stable branch
get's created, as the commit ID won't change although you change the commit
history of your for-mfd-next branch.
If you want to go the route for me rebasing my tree on top of for-mfd-next then
I'd like to have at least a stable tag, so that it will be easier to provide the
pull-request later on. Would that be a compromise?
Regards,
Matthias
On Tue, 17 Nov 2020, Matthias Brugger wrote:
>
>
> On 17/11/2020 13:37, Lee Jones wrote:
> > On Tue, 17 Nov 2020, Matthias Brugger wrote:
> >
> > > Hi Lee,
> > >
> > > On 13/11/2020 11:19, Lee Jones wrote:
> > > > On Tue, 10 Nov 2020, Enric Balletbo i Serra wrote:
> > > >
> > > > > This adds syscon_regmap_lookup_by_phandle_optional() function to get an
> > > > > optional regmap.
> > > > >
> > > > > It behaves the same as syscon_regmap_lookup_by_phandle() except where
> > > > > there is no regmap phandle. In this case, instead of returning -ENODEV,
> > > > > the function returns NULL. This makes error checking simpler when the
> > > > > regmap phandle is optional.
> > > > >
> > > > > Suggested-by: Nicolas Boichat <[email protected]>
> > > > > Signed-off-by: Enric Balletbo i Serra <[email protected]>
> > > > > Reviewed-by: Matthias Brugger <[email protected]>
> > > > > ---
> > > > >
> > > > > Changes in v2:
> > > > > - Add Matthias r-b tag.
> > > > > - Add the explanation from the patch description to the code.
> > > > > - Return NULL instead of -ENOTSUPP when regmap helpers are not enabled.
> > > > >
> > > > > drivers/mfd/syscon.c | 18 ++++++++++++++++++
> > > > > include/linux/mfd/syscon.h | 11 +++++++++++
> > > > > 2 files changed, 29 insertions(+)
> > > >
> > > > Applied, thanks.
> > > >
> > >
> > > I've a series [1] that's based on this patch, could you provide a stable
> > > branch for it, so that I can take the series.
> >
> > Why can't you base it off of for-mfd-next?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=for-mfd-next
> >
>
> I can do that, if you are willing to not overwrite the commit history. In my
> case it can happen that I drop a patch from my for-next branch as I realize
> that it e.g. breaks something. I think that's the reason why normally a
> stable branch get's created, as the commit ID won't change although you
> change the commit history of your for-mfd-next branch.
>
> If you want to go the route for me rebasing my tree on top of for-mfd-next
> then I'd like to have at least a stable tag, so that it will be easier to
> provide the pull-request later on. Would that be a compromise?
I don't usually provide immutable branches/tags unless I'm sharing
topic branches for other maintainers to pick-up, in order to avoid
merge conflicts.
It's highly irregular (in fact this is a first for me) for a
contributor to request one to base their work on top of.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
On Tue, Nov 17, 2020 at 5:07 PM Lee Jones <[email protected]> wrote:
> On Tue, 17 Nov 2020, Matthias Brugger wrote:
> > On 17/11/2020 13:37, Lee Jones wrote:
> > > On Tue, 17 Nov 2020, Matthias Brugger wrote:
> >
> > If you want to go the route for me rebasing my tree on top of for-mfd-next
> > then I'd like to have at least a stable tag, so that it will be easier to
> > provide the pull-request later on. Would that be a compromise?
>
> I don't usually provide immutable branches/tags unless I'm sharing
> topic branches for other maintainers to pick-up, in order to avoid
> merge conflicts.
I think that's what Matthias is planning to do though. If he wants
to send me a Mediatek specific branch for the soc tree, it needs to
be based on a stable commit in the mtd tree to avoid duplicating
the commit.
Arnd
On 17/11/2020 17:40, Arnd Bergmann wrote:
> On Tue, Nov 17, 2020 at 5:07 PM Lee Jones <[email protected]> wrote:
>> On Tue, 17 Nov 2020, Matthias Brugger wrote:
>>> On 17/11/2020 13:37, Lee Jones wrote:
>>>> On Tue, 17 Nov 2020, Matthias Brugger wrote:
>>>
>>> If you want to go the route for me rebasing my tree on top of for-mfd-next
>>> then I'd like to have at least a stable tag, so that it will be easier to
>>> provide the pull-request later on. Would that be a compromise?
>>
>> I don't usually provide immutable branches/tags unless I'm sharing
>> topic branches for other maintainers to pick-up, in order to avoid
>> merge conflicts.
>
> I think that's what Matthias is planning to do though. If he wants
> to send me a Mediatek specific branch for the soc tree, it needs to
> be based on a stable commit in the mtd tree to avoid duplicating
> the commit.
>
Exactly, I'm the maintainer of MediaTek SoCs and I would need to pull this patch
into my tree to be able to accept the series I mentioned [1]. Can you provide me
a stable tag/branch, against just that patch or against your whole tree?
Regards,
Matthias
[1]
https://lore.kernel.org/linux-mediatek/[email protected]/
On Wed, 18 Nov 2020, Matthias Brugger wrote:
>
>
> On 17/11/2020 17:40, Arnd Bergmann wrote:
> > On Tue, Nov 17, 2020 at 5:07 PM Lee Jones <[email protected]> wrote:
> > > On Tue, 17 Nov 2020, Matthias Brugger wrote:
> > > > On 17/11/2020 13:37, Lee Jones wrote:
> > > > > On Tue, 17 Nov 2020, Matthias Brugger wrote:
> > > >
> > > > If you want to go the route for me rebasing my tree on top of for-mfd-next
> > > > then I'd like to have at least a stable tag, so that it will be easier to
> > > > provide the pull-request later on. Would that be a compromise?
> > >
> > > I don't usually provide immutable branches/tags unless I'm sharing
> > > topic branches for other maintainers to pick-up, in order to avoid
> > > merge conflicts.
> >
> > I think that's what Matthias is planning to do though. If he wants
> > to send me a Mediatek specific branch for the soc tree, it needs to
> > be based on a stable commit in the mtd tree to avoid duplicating
> > the commit.
> >
>
> Exactly, I'm the maintainer of MediaTek SoCs and I would need to pull this
> patch into my tree to be able to accept the series I mentioned [1]. Can you
> provide me a stable tag/branch, against just that patch or against your
> whole tree?
Oh, I see. I thought you wanted to develop on top of it. Apologies.
PR to follow (I'll reply directly to the patch).
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Enjoy!
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-mediatek-v5.11
for you to fetch changes up to 86b9d170da98bae13b307d621638954aef645331:
mfd: syscon: Add syscon_regmap_lookup_by_phandle_optional() function. (2020-11-19 08:30:11 +0000)
----------------------------------------------------------------
Immutable branch between MFD and MediaTek due for the v5.11 merge window
----------------------------------------------------------------
Enric Balletbo i Serra (1):
mfd: syscon: Add syscon_regmap_lookup_by_phandle_optional() function.
drivers/mfd/syscon.c | 18 ++++++++++++++++++
include/linux/mfd/syscon.h | 11 +++++++++++
2 files changed, 29 insertions(+)
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
On 19/11/2020 09:32, Lee Jones wrote:
> On Wed, 18 Nov 2020, Matthias Brugger wrote:
>
>>
>>
>> On 17/11/2020 17:40, Arnd Bergmann wrote:
>>> On Tue, Nov 17, 2020 at 5:07 PM Lee Jones <[email protected]> wrote:
>>>> On Tue, 17 Nov 2020, Matthias Brugger wrote:
>>>>> On 17/11/2020 13:37, Lee Jones wrote:
>>>>>> On Tue, 17 Nov 2020, Matthias Brugger wrote:
>>>>>
>>>>> If you want to go the route for me rebasing my tree on top of for-mfd-next
>>>>> then I'd like to have at least a stable tag, so that it will be easier to
>>>>> provide the pull-request later on. Would that be a compromise?
>>>>
>>>> I don't usually provide immutable branches/tags unless I'm sharing
>>>> topic branches for other maintainers to pick-up, in order to avoid
>>>> merge conflicts.
>>>
>>> I think that's what Matthias is planning to do though. If he wants
>>> to send me a Mediatek specific branch for the soc tree, it needs to
>>> be based on a stable commit in the mtd tree to avoid duplicating
>>> the commit.
>>>
>>
>> Exactly, I'm the maintainer of MediaTek SoCs and I would need to pull this
>> patch into my tree to be able to accept the series I mentioned [1]. Can you
>> provide me a stable tag/branch, against just that patch or against your
>> whole tree?
>
> Oh, I see. I thought you wanted to develop on top of it. Apologies.
>
> PR to follow (I'll reply directly to the patch).
>
No problems. Thanks a lot!
Matthias