On Tue, Nov 13, 2018 at 12:48 AM Daniel Mack <daniel@xxxxxxxxxx> wrote: > On 12/11/2018 3:12 PM, Linus Walleij wrote: > > Simplify things by making the PXA MCI driver just use > > slot GPIO with descriptors instead of passing around the global > > GPIO numbers that we want to get rid of. > > > > This involves augmenting more or less every PXA boardfile, > > associating each card detect or write protect line with the > > right GPIO chip or GPIO expander. > > > > As we are no longer checking for global GPIO numbers we avoid > > having to fill them in at all in the platform data including > > the kludge of setting the GPIO to -1 when we don't have either > > signal. We just look for the slot GPIO descriptor for CD and > > WP and if we find it we use it. > > > > We take care of correctly specifying the edge sensitivity of > > the GPIO lines (active low or active high) so we can later > > on use this flag even though the MMC slot GPIO code uses the > > *raw accessors and rely on the caps2 flags > > MMC_CAP2_CD_ACTIVE_HIGH and MMC_CAP2_RO_ACTIVE_HIGH for polarity > > inversion semantics as of now. > > > > Cc: Daniel Mack <daniel@xxxxxxxxxx> > > Cc: Robert Jarzmik <robert.jarzmik@xxxxxxx> > > Cc: Bartosz Golaszewski <brgl@xxxxxxxx> > > Cc: Andrea Adami <andrea.adami@xxxxxxxxx> > > Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > > --- > > ... > > > arch/arm/mach-pxa/raumfeld.c | 2 -- > > Thanks for doing this! > > However, I'm planning to remove that file entirely very soon, and > replace it with a dtb version. In order to avoid conflicts in the merge > window - could you respin and leave the file untouched? That's not usually how we do things. It's better if Ulf apply the patches to an immutable branch and we pull that into ARM SoC so they have the changes and then you can remove it on top of that. Another possibility is to let linux-next (and Torvalds) deal with the conflict when the file gets removed in one pull request and altered in another. In fact that is usually what we do. Yours, Linus Walleij
