[PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion
afzal at ti.com
Tue May 8 02:27:18 EDT 2012
On Mon, May 07, 2012 at 21:53:34, Hunter, Jon wrote:
> >>>> Write protect is a pin and there is only one. Like the waitpins and CS
> >>>> signals this needs to be associated with a device. It would make sense
> >>>> that this is associated with the cs data.
> >>> As far as platform are concerned, it is associated with cs, it is only
> >>> that while configuring CS, it is propagated such that it is done once.
> >> Hmmm ... but here it looks like if write-protect is used you are going
> >> to turn it on. A feature like this seems that it does need to be handled
> >> by the device's driver. Enabling and disabling write-protect are
> >> functions that I would expect are exported to the device's driver and
> >> not directly enabled in the gpmc driver during probe. However, maybe is
> >> could be valid for the write protect to be enabled by default which
> >> could make sense. However, I don't see anywhere else in the driver to
> >> control it.
> >> Shouldn't we warn on multiple devices trying to use write-protect when
> >> parsing their configuration?
> > Even if a single device sets write protect, kernel will log it.
> That does not seem sufficient. It should be flagged as an error.
> Write protect is a resource like the CS and waitpins and so I would have
> thought that it should be reserved in the same way.
Isn't it valid for multiple devices to make use of write protect pin ?
More information about the linux-arm-kernel