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:   Mon, 03 Dec 2018 11:36:32 +0100
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Neil Armstrong <narmstrong@...libre.com>,
        Xingyu Chen <xingyu.chen@...ogic.com>,
        linus.walleij@...aro.org, linux-gpio@...r.kernel.org
Cc:     khilman@...libre.com, carlo@...one.org,
        martin.blumenstingl@...glemail.com, robh@...nel.org,
        jianxin.pan@...ogic.com, linux-amlogic@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pinctrl: meson: fix G12A ao pull registers base address

On Mon, 2018-12-03 at 11:27 +0100, Neil Armstrong wrote:
> Hi Xingyu,
> 
> 
> On 03/12/2018 04:05, Xingyu Chen wrote:
> > Since Meson G12A SoC, Introduce new ao registers AO_RTI_PULL_UP_EN_REG
> > and AO_GPIO_O.
> > 
> > These bits of controlling output level are remapped to the new register
> > AO_GPIO_O, and the AO_GPIO_O_EN_N support only controlling output enable.
> > 
> > These bits of controlling pull enable are remapped to the new register
> > AO_RTI_PULL_UP_EN_REG, and the AO_RTI_PULL_UP_REG support only controlling
> > pull type(up/down).
> > 
> > The new layout of ao gpio/pull registers is as follows:
> > - AO_GPIO_O_EN_N        [offset: 0x9 << 2]
> > - AO_GPIO_I             [offset: 0xa << 2]
> > - AO_RTI_PULL_UP_REG    [offset: 0xb << 2]
> > - AO_RTI_PULL_UP_EN_REG [offset: 0xc << 2]
> > - AO_GPIO_O             [offset: 0xd << 2]
> > 
> > From above, we can see ao GPIO registers region has been separated by the
> > ao pull registers. In order to ensure the continuity of the region on
> > software, the ao GPIO and ao pull registers use the same base address, but
> > can be identified by the offset.
> > 
> > Fixes: 29ae0952e85f ("pinctrl: meson-g12a: add pinctrl driver support")
> > Signed-off-by: Xingyu Chen <xingyu.chen@...ogic.com>
> > Signed-off-by: Jianxin Pan <jianxin.pan@...ogic.com>
> > ---
> >  drivers/pinctrl/meson/pinctrl-meson.c | 22 ++++++++++++----------
> >  1 file changed, 12 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/pinctrl/meson/pinctrl-meson.c
> > b/drivers/pinctrl/meson/pinctrl-meson.c
> > index 53d449076dee..7ff40cd7a0cb 100644
> > --- a/drivers/pinctrl/meson/pinctrl-meson.c
> > +++ b/drivers/pinctrl/meson/pinctrl-meson.c
> > @@ -31,6 +31,9 @@
> >   * In some cases the register ranges for pull enable and pull
> >   * direction are the same and thus there are only 3 register ranges.
> >   *
> > + * Since Meson G12A SoC, the ao register ranges for gpio, pull enable
> > + * and pull direction are the same, so there are only 2 register ranges.
> > + *
> >   * For the pull and GPIO configuration every bank uses a contiguous
> >   * set of bits in the register sets described above; the same register
> >   * can be shared by more banks with different offsets.
> > @@ -487,23 +490,22 @@ static int meson_pinctrl_parse_dt(struct
> > meson_pinctrl *pc,
> >  		return PTR_ERR(pc->reg_mux);
> >  	}
> >  
> > -	pc->reg_pull = meson_map_resource(pc, gpio_np, "pull");
> > -	if (IS_ERR(pc->reg_pull)) {
> > -		dev_err(pc->dev, "pull registers not found\n");
> > -		return PTR_ERR(pc->reg_pull);
> > +	pc->reg_gpio = meson_map_resource(pc, gpio_np, "gpio");
> > +	if (IS_ERR(pc->reg_gpio)) {
> > +		dev_err(pc->dev, "gpio registers not found\n");
> > +		return PTR_ERR(pc->reg_gpio);
> >  	}
> >  
> > +	pc->reg_pull = meson_map_resource(pc, gpio_np, "pull");
> > +	/* Use gpio region if pull one is not present */
> > +	if (IS_ERR(pc->reg_pull))
> > +		pc->reg_pull = pc->reg_gpio;
> > +
> >  	pc->reg_pullen = meson_map_resource(pc, gpio_np, "pull-enable");
> >  	/* Use pull region if pull-enable one is not present */
> >  	if (IS_ERR(pc->reg_pullen))
> >  		pc->reg_pullen = pc->reg_pull;
> >  
> > -	pc->reg_gpio = meson_map_resource(pc, gpio_np, "gpio");
> > -	if (IS_ERR(pc->reg_gpio)) {
> > -		dev_err(pc->dev, "gpio registers not found\n");
> > -		return PTR_ERR(pc->reg_gpio);
> > -	}
> > -
> >  	return 0;
> >  }
> >  
> > 
> Doesn't it need an update of the bindings ?

Going even further, shouldn't we stop trying make multiple regions out of
this, and have just one ? 

On all the Amlogic SoC we have seen so far, all the regions a very (VERY)
close to each other. It seems very unlikely that there something unrelated to
GPIO in between.

It looks like everything is mostly there in the driver to deal with offset, so
change would be minimal.

Of course, for  DT stability we will need to carry the legacy, but for newer
SoC, such as the g12, does it really makes sense to have multiple regions ?

> 
> Neil
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ