Messages in this thread |  | | From | Andy Shevchenko <> | Date | Mon, 3 Feb 2020 14:48:01 +0200 | Subject | Re: [PATCH 0/3] dmaengine: Stear users towards dma_request_slave_chan() |
| |
On Mon, Feb 3, 2020 at 2:09 PM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote: > On 03/02/2020 13.16, Andy Shevchenko wrote: > > On Mon, Feb 3, 2020 at 12:59 PM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote: > >> On 03/02/2020 12.37, Andy Shevchenko wrote: > >>> On Mon, Feb 3, 2020 at 12:32 PM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote: > > > >>>> Advise users of dma_request_slave_channel() and > >>>> dma_request_slave_channel_compat() to move to dma_request_slave_chan() > >>> > >>> How? There are legacy ARM boards you have to care / remove before. > >>> DMAengine subsystem makes a p*s off decisions > >> > >> The dma_slave_map support is added few years back for the legacy ARM > >> boards, because we do care. > >> daVinci, OMAP1, pxa, s3cx4xx and even m68k/coldfire moved over. > > > > Then why simple not to convert (start converting) those few drivers to > > new API and simple remove the old one? > > _if_ the dma_request_slave_channel_compat() is really falling back after > dma_request_chan() - this is what it calls first, then it is not a > simple convert to a new API. > 1. The arch needs to define the dma_slave_map for the SoC. > 2. The dma driver needs few lines to add it to DMAengine core (+pdata > change). > After this the _compat() can be replaced with dma_request_chan() >
> In most cases I do not have access to documentation and boards to test.
So, why everyone with the boards outside of your scope has to suffer?
...
> >> Imho it is confusing to have 4+ APIs to do the same thing, but in a > >> slightly different way. > > > > It was always an excuse by authors "that too many drivers to convert..." > > Sure, but before you accuse anyone with neglect, can you check the git > log for 'dma_request_slave_channel' in the commit messages?
It's good people, and you, are taking care of it, but make user suffer because somebody wants to call for *developers* is a bad idea. And it happened not first time in the DMA engine subsystem.
...
> > No, it's a reason when you first take care of existing users and > > decide to obsolete an API followed by removal few releases later. > > I'm fine to drop the pr_info()
Yes, please do.
> and the __deprecated mark for > dma_request_slave_channel.
This OTOH is for *developers* and its scope won't scary people. So, it's more or less fine.
> > But > > I see no reason to keep such APIs at all, so, instead of this > > *wonderful* messages perhaps somebody should do better work? > > To touch the _compat() variant one needs to have access to the > documentation of the SoC on which the code falls back. It is not a > matter of sloppy/poor/ignorant/etc work attitude. > I have kept clear on touching those few drivers using it [1] as I don't > have documentation. > > >> New drivers should not use the old API i new code and developers tend to > >> pick the API they use after a quick 'git grep dma_request_' and see what > >> the majority is using. > > > > Isn't it a point to do better review rather than scary end users? > > Sure, but we rarely CCd on new client drivers for DMAengine API usage.
Linux Next allows people to `git grep -n dma_slave_DO_NOT_CALL` and tell developers. Isn't it the job good maintainer can do?
> [1] fwiw, there are drivers using dma_request_channel() and by the look > their use is either _compat() or the dma_request_chan_by_mask() style > and some even have a twist here and there...
Bottom line, if you need to tell *developers* about something, please don't bother *end users*.
-- With Best Regards, Andy Shevchenko
|  |