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
