linux-kernel - Re: [PATCH v4 10/18] pinctrl: eyeq5: add platform driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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