RE: [PATCH 2/2] spi: img-spfi: fix spfi_setup by removing gpio_request_one

[Sifan Naeem <Sifan.Naeem@xxxxxxxxxx>]

Please find the new patch in http://marc.info/?l=linux-spi&m=143816718611912&w=2

Thanks,
Sifan

> -----Original Message-----
> From: Sifan Naeem
> Sent: 27 July 2015 17:54
> To: 'Mark Brown'; Andrew Bresticker
> Cc: linux-spi@xxxxxxxxxxxxxxx; Stable kernel (v4.1)
> Subject: RE: [PATCH 2/2] spi: img-spfi: fix spfi_setup by removing
> gpio_request_one
> 
> Thanks Mark, Andrew.
> 
> I'll rework this and submit a new patch.
> 
> Thanks,
> Sifan
> 
> > -----Original Message-----
> > From: Mark Brown [mailto:broonie@xxxxxxxxxx]
> > Sent: 27 July 2015 17:40
> > To: Andrew Bresticker
> > Cc: Sifan Naeem; linux-spi@xxxxxxxxxxxxxxx; Stable kernel (v4.1)
> > Subject: Re: [PATCH 2/2] spi: img-spfi: fix spfi_setup by removing
> > gpio_request_one
> >
> > On Mon, Jul 27, 2015 at 09:34:41AM -0700, Andrew Bresticker wrote:
> > > On Mon, Jul 27, 2015 at 5:11 AM, Sifan Naeem
> > > <sifan.naeem@xxxxxxxxxx>
> > wrote:
> >
> > > > spfi_setup may be called many times bye the spi framework, but
> > > > gpio_request_one can only be called once without freeing,
> > > > repeatedly calling gpio_request_one will cause an error to be
> > > > thrown, which causes the request to spi_setup to be marked as failed.
> >
> > > > We can simply use gpio_direction_output to set the direction of
> > > > the gpio instead of gpio_request_one to put the gpio in to initial
> > > > state, after which the spi framework can control the chipselect
> > > > line via gpio using gpio_set_value.
> >
> > > I don't think we want to leave the CS GPIOs un-requested.  Instead,
> > > we could either request them all at probe() time (and then set
> > > direction in setup()) or have a per-spi_device flag that indicates
> > > whether or not the GPIO has been requested.
> >
> > Not requesting the GPIOs at all would just be a straight up bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html