[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CYTO3C0G7083.1TVFK6PN35G1B@bootlin.com>
Date: Thu, 01 Feb 2024 11:23:59 +0100
From: Théo Lebrun <theo.lebrun@...tlin.com>
To: "Linus Walleij" <linus.walleij@...aro.org>
Cc: "Gregory CLEMENT" <gregory.clement@...tlin.com>, "Michael Turquette"
<mturquette@...libre.com>, "Stephen Boyd" <sboyd@...nel.org>, "Rob Herring"
<robh+dt@...nel.org>, "Krzysztof Kozlowski"
<krzysztof.kozlowski+dt@...aro.org>, "Conor Dooley" <conor+dt@...nel.org>,
"Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
Rafał Miłecki <rafal@...ecki.pl>, "Philipp Zabel"
<p.zabel@...gutronix.de>, "Vladimir Kondratiev"
<vladimir.kondratiev@...ileye.com>, <linux-mips@...r.kernel.org>,
<linux-clk@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, "Thomas Petazzoni"
<thomas.petazzoni@...tlin.com>, "Tawfik Bayouk"
<tawfik.bayouk@...ileye.com>, <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v4 10/18] pinctrl: eyeq5: add platform driver
Hi Linus,
On Wed Jan 31, 2024 at 9:55 PM CET, Linus Walleij wrote:
> Hi Theo,
>
> thanks for your patch!
>
> On Wed, Jan 31, 2024 at 5:27 PM Théo Lebrun <theo.lebrun@...tlin.com> wrote:
>
> > Add the Mobileye EyeQ5 pin controller driver. It might grow to add later
> > support of other platforms from Mobileye. It belongs to a syscon region
> > called OLB.
> >
> > Existing pins and their function live statically in the driver code
> > rather than in the devicetree, see compatible match data.
> >
> > Signed-off-by: Théo Lebrun <theo.lebrun@...tlin.com>
>
> The driver looks very nice and is using all standard features, I'm pretty sure
> we can merge this soon.
It is useful to get some feedback that tells me your state of mind as
one involved maintainer. Thanks.
>
> > +static void eq5p_update_bits(const struct eq5p_pinctrl *pctrl,
> > + enum eq5p_bank bank, enum eq5p_regs reg,
> > + u32 mask, u32 val)
> > +{
> > + void __iomem *ptr = pctrl->base + eq5p_regs[bank][reg];
> > +
> > + writel((readl(ptr) & ~mask) | (val & mask), ptr);
> > +}
>
> This is in practice a reimplementation of regmap MMIO.
>
> Can't you just use regmap MMIO to access the banks then...?
>
> Maybe it doesn't add much here. I'm not sure.
Indeed, I went the minimalist route. You tell me if you'd prefer an MMIO
regmap.
I've not seen any helper to get a regmap based on a resource, targeting
by name. Is the expected procedure to acquire the resource then create
a regmap config then call devm_regmap_init_mmio()?
>
> > +static bool eq5p_readl_bit(const struct eq5p_pinctrl *pctrl,
>
> eq5p_test_bit() maybe? that describes better what the
> function does.
Good idea, thanks.
>
> > + enum eq5p_bank bank, enum eq5p_regs reg, int bit)
> > +{
> > + u32 val = readl(pctrl->base + eq5p_regs[bank][reg]);
> > +
> > + return (val & BIT(bit)) != 0;
> > +}
>
> Maybe add a check for bit > 31?
Will do. I like that sort of defensive programming. What behavior would
you expect?
- WARN_ON(bit > 31) and return false?
- Just return false?
- Something else?
Actually looking at uses of eq5p_readl_bit() I'm thinking about a bug
that might be occuring wrt the second bank and that offset. I'll make
sure to fix it for next revision.
> > +static int eq5p_pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
> > + unsigned int selector,
> > + const unsigned int **pins,
> > + unsigned int *num_pins)
> > +{
> > + *pins = &pctldev->desc->pins[selector].number;
> > + *num_pins = 1;
> > + return 0;
> > +}
>
> One pin per group, also known as the "qualcomm trick".
>
> (It's fine.)
:-)
Thanks!
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Powered by blists - more mailing lists