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]
Message-ID: <1425976298.2440.26.camel@mm-sol.com>
Date:	Tue, 10 Mar 2015 10:31:38 +0200
From:	"Ivan T. Ivanov" <iivanov@...sol.com>
To:	Stephen Boyd <sboyd@...eaurora.org>
Cc:	Mark Brown <broonie@...nel.org>, linus.walleij@...aro.org,
	linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 2/2] spi: qup: Request CS GPIO's during probe

Hi, 

On Mon, 2015-03-09 at 11:53 -0700, Stephen Boyd wrote:
> On 03/09/15 01:20, Ivan T. Ivanov wrote:
> > Hi Stephen,
> > 
> > > On Mar 6, 2015, at 8:34 PM, Stephen Boyd <sboyd@...eaurora.org> wrote:
> > > On 03/06/15 07:26, Ivan T. Ivanov wrote:
> > > > Ensure that driver is owner of the GPIO's used for CS signals.
> > > Why? What happens if we don’t?
> > We can have wrong DT configuration, which could reconfigure
> > GPIO’s without any warning or error.
> 
> Ouch. That sounds bad. Can you please add this information to the commit
> text?

Sure.

> > > > +       for (cs = 0; cs < master->num_chipselect; cs++) {
> > > > +               cs_gpio = of_get_named_gpio(dev->of_node, "cs-gpios", cs);
> > > > +
> > > > +               if (!gpio_is_valid(cs_gpio))
> > > > +                       continue;
> > > > +
> > > > +               ret = devm_gpio_request(&pdev->dev, cs_gpio, "spi-qup-cs");
> > > > +               if (ret) {
> > > > +                       dev_err(&pdev->dev, "can't get cs gpios\n");
> > > > +                       goto error;
> > > > +               }
> > > > +       }
> > > > +
> > > >         master->bus_num = pdev->id;
> > > Is this related to [1]? In that case I was just relying on DT/pinctrl to
> > > properly request the gpios.
> > But the DT/pinctrl did not request GPIO’s, it just configure them.
> > For some reason we are ending without any pinctrl_map of type
> > PIN_MAP_TYPE_MUX_GROUP, which is used for pin reservation.
> > 
> 
> Ah ok. I seem to be misremembering the details.

:-) I still have version of downstream "msm-pinctrl" driver, 
which create PIN_MAP_TYPE_MUX_GROUP maps during node to map
parsing. 

> 
> Can you please use the gpiod interfaces here (devm_gpiod_get_index)?

Sure.

> That's more modern. Also, don't print any error because -EPROBE_DEFER
may come out and 

Well, this could not happen. Driver probe will not called until default 
pinctrl state is not available and we rely on this for proper driver
functionality. 

> because __gpiod_get_index() already prints an error on
> failure at the debug level.

Ok.

Thanks, 
Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ