Re: [PATCH 2/2] serial: mctrl_gpio: Support all GPIO suffixes (gpios vs gpio)

[Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>]

On Tue, Aug 13, 2019 at 01:42:58PM +0200, Pavel Machek wrote:
> On Mon 2019-08-12 13:53:07, Andy Shevchenko wrote:
> > On Thu, Aug 08, 2019 at 03:59:36PM +0200, Stefan Roese wrote:
> > > On 08.08.19 15:48, Andy Shevchenko wrote:
> > > > On Thu, Aug 08, 2019 at 03:25:43PM +0200, Stefan Roese wrote:

> > I tried hard to find an evidence of this in Linux kernel, I assume that comes
> > from DT compiler or something, but fail. Linux kernel OF properties handling is
> > written in the assumption of arbitrary length of the property name.
> > 
> > It might be that my hard was not hard at all and I missed something.
> > 
> > > > Or maybe we can still continue using kasprintf() approach?
> > > 
> > > Frankly, I was feeling a bit uncomfortable with this memory allocation
> > > in a loop. And Pavel also commented on this:
> > > 
> > > https://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg2066286.html
> > 
> > If memory allocator fails, it's a big issue, and what will happen next probably
> > much less important.
> 
> Not... really. With "too big" allocations, it will fail.

Yeah, or with relatively small if memory is too much fragmented.
But we are talking about really small allocations here in most cases, right?

> Anyway, my point is that allocating in a loop for this is slow and
> ugly. If we don't have a maximum property length, we should probably
> invent some. I mean, we can agree that 64KB property name is not okay,
> right?

My point that is should be declared on the level of property API.
Restricting it on the level of one, 'client' to that API, framework is not
a solution.

-- 
With Best Regards,
Andy Shevchenko