Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 4, 2019 at 10:05 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Jan 04, 2019 at 09:55:02AM +0100, Sergio Paracuellos wrote:
> > Hi Greg,
> >
> > On Fri, Jan 4, 2019 at 9:32 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Thu, Jan 03, 2019 at 09:23:57AM +0100, Sergio Paracuellos wrote:
> > > > On Thu, Jan 3, 2019 at 3:02 AM NeilBrown <neil@xxxxxxxxxx> wrote:
> > > > >
> > > > > On Mon, Dec 31 2018, Sergio Paracuellos wrote:
> > > > >
> > > > > > dt_node_to_map and dt_free_map operations can use pinconf-generic API's
> > > > > > instead of redefine operations in the driver. Make use of them cleaning
> > > > > > a bit driver's code.
> > > > > >
> > > > > > Update DT accordly to make sure used bindings property in code match
> > > > > > with the board's DT bindings.
> > > > > >
> > > > > > Changes are only compile-tested.
> > > > >
> > > > > Thanks.  This appears to work for me.
> > > > > It is awkward to test pinctrl changes because the firmware preconfigures
> > > > > all the pins, so the hardware will work correctly if pinctrl does
> > > > > nothing.
> > > > > So I change the dts file to mis-configure some pins for driving LEDs,
> > > > > and checked that the LEDs broken.  The fixed the dts, and the LEDs
> > > > > started working again.
> > > > > I think that will have to do.
> > > > >
> > > > > Tested-by: NeilBrown <neil@xxxxxxxxxx>
> > > > >
> > > > > Thanks,
> > > > > NeilBrown
> > > >
> > > > Cool! Thanks for testing and let me know.
> > > >
> > > > So, I sent this patch which solves a problem:
> > > >
> > > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html
> > > >
> > > > And this new patch is generated with that applied. Also this patch
> > > > solves the original problem
> > > > also and seems the way to go... Should be better to re-do this one
> > > > with all the fixed and reported by
> > > > tags added as a solution?
> > > >
> > > > What do you prefer, Greg?
> > >
> > > I'm sorry, but I do not understand.  Is this 2 patch series not
> > > acceptable to merge?  Should I drop it and use some other patch series?
> > > Should I ignore some other patch series?
> >
> > Sorry, let me try to explain it better.
> > Both this series and the patch in [1] can solve the same problem. Both
> > of them also work. This series can be applied after the patch in [1].
> > as a clean up because this series are rebased onto it. So the question
> > here is you don't have problems to take both of them or if I should
> > re-do this one with two patches as a solution of the problem and
> > forget about the one in [1].
> >
> > [1]: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html
>
> How about I drop all of the pending patches from you, and you resend a
> new series with whatever you think needs to be applied.  That makes it
> very obvious as to what I need to ignore and what I need to
> review/apply.

Ok. I'll send the last series as a fix. Sorry for the noise.
>
> thanks,

>
> greg k-h

Best regards,
    Sergio Paracuellos
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux