Hi Jon, 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 ? Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
