Re: [PATCH v3 100/108] gpio: mvebu: Make use of devm_pwmchip_alloc() function

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 3263 bytes --]

Hello Bart,

On Fri, Nov 24, 2023 at 10:16:40PM +0100, Bartosz Golaszewski wrote:
> On Fri, Nov 24, 2023 at 1:14 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Wed, Nov 22, 2023 at 11:36:19AM +0100, Bartosz Golaszewski wrote:
> > > On Wed, Nov 22, 2023 at 10:05 AM Uwe Kleine-König
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > On Tue, Nov 21, 2023 at 05:11:11PM +0100, Uwe Kleine-König wrote:
> > > > > On Tue, Nov 21, 2023 at 03:02:39PM +0100, Bartosz Golaszewski wrote:
> > > > > > Eh... I had a talk at LPC where I explained why I really dislike this
> > > > > > approach but I guess this ship has sailed now and it's not a subsystem
> > > > > > where I have any say anyway.
> > > > >
> > > > > Is there a record of your talk? I'm open to hear your arguments.
> > > >
> > > > I found your slides at
> > > > https://lpc.events/event/17/contributions/1627/attachments/1258/2725/Linux%20Plumbers%20Conference%202023.pdf
> > > >
> > >
> > > My talk is here: https://www.youtube.com/watch?v=VxaAorwL89c&t=29310s
> >
> > I've been watching this along with Laurent's talk from last year (and I
> > guess I should probably also go through Wolfram's patch from earlier
> > this year) and I really like what you presented. It also sounds like
> > there was a lot of support across various audience members, so I think
> > it'd be good to rally around such a common pattern so we can start to
> > improve things on a more wide basis.
> >
> > Given that this wasn't very long ago, I wouldn't expect that much work
> > has happened yet on the resmgr library. However, I think it would fit
> > very well both with how PWM works today and with what Uwe has in mind
> > for the character device support.
> >
> > Thierry
> 
> Hi Thierry,
> 
> Thanks for the kind words. No work has been done so far other than
> thinking about the possible API. I'm currently in the process of
> trying to fix the object life-time and concurrent access in GPIO -
> mostly improving the dire locking situation. My goal is to implement
> all I spoke about in GPIO first and then try to generalize it to some
> other subsystem like what Greg KH suggested.
> 
> I've already got support from Wolfram on that and we of course could
> use any help we can get.
> 
> I admit I've been quite busy but I do plan on going through Uwe's
> series next week and maybe running tests similar to what I have for
> GPIO on it. I'm quite certain (correct me if I'm wrong) that this
> series doesn't improve the locking (specifically hot-unplug events
> during API calls). I think that my proposal has the advantage of
> having the pointer to the implementation in the "wrapper" which can be
> easily protected with RCU.

Maybe I didn't understand the problem yet, but I think hotplugging isn't
a problem for my approach. The hardware accesses in the lowlevel driver
(probably) fail then but that's something you cannot prevent. And
because pwmchip->lock is held during calls in the lowlevel driver,
removal of the driver is delayed accordingly.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]