linux-kernel - Re: [PATCH v8 1/2] pinctrl: pinctrl-loongson2: add pinctrl driver support

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] [day] [month] [year] [list]

Date:   Fri, 11 Nov 2022 13:23:48 +0200
From:   Andy Shevchenko <andriy.shevchenko@...el.com>
To:     Yinbo Zhu <zhuyinbo@...ngson.cn>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        zhanghongchen <zhanghongchen@...ngson.cn>
Subject: Re: [PATCH v8 1/2] pinctrl: pinctrl-loongson2: add pinctrl driver
 support

On Fri, Nov 11, 2022 at 11:53:37AM +0800, Yinbo Zhu wrote:
> 在 2022/11/9 下午11:40, Andy Shevchenko 写道:
> > On Wed, Nov 09, 2022 at 02:11:21PM +0800, Yinbo Zhu wrote:

...

> > > +static const unsigned int lio_pins[]    = {};
> > > +static const unsigned int uart2_pins[]  = {};
> > > +static const unsigned int uart1_pins[]  = {};
> > > +static const unsigned int camera_pins[] = {};
> > > +static const unsigned int dvo1_pins[]   = {};
> > > +static const unsigned int dvo0_pins[]   = {};
> > 
> > No sure what this means.
> There are some fuzzy reuse relationships on loongson2, e.g., lio can be
> reused as gpio, which is one of the reserved gpios but the manual not
> indicates this gpio index.

The rule of thumb is to avoid putting something you are not able to test.

...

> > > +	unsigned long reg = (unsigned long)pctrl->reg_base +
> > > +				loongson2_pmx_groups[group_num].reg;
> > 
> > Why casting?!
> There are some registers that determine the pin reuse relationship. For
> example, register A determines the sdio reuse relationship, and register
> A+offset determines the uart reuse relationship

I'm asking about something different. Why do you need casting for iomem offset?

...

> > > +	val = readl((void *)reg);
> > 
> > Ouch.

^^^ You see, this is a real issue with code, without fix which it's no go.

...

> > > +	writel(val, (void *)reg);
> > 
> > Ouch!
> I will keep writel/readl.

Yes, but you need to take care about annotations of the addresses (__iomem)
and remove ugly castings.

-- 
With Best Regards,
Andy Shevchenko