[PATCH v7 1/3] devres: provide devm_krealloc()

[Andy Shevchenko]

On Tue, Aug 18, 2020 at 08:13:10PM +0200, Bartosz Golaszewski wrote:
> On Tue, Aug 18, 2020 at 7:19 PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> > On Tue, Aug 18, 2020 at 06:27:12PM +0200, Bartosz Golaszewski wrote:
> > > On Tue, Aug 18, 2020 at 10:40 AM Andy Shevchenko
> > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > On Mon, Aug 17, 2020 at 10:02:05PM +0200, Bartosz Golaszewski wrote:
> > > > > On Mon, Aug 17, 2020 at 7:43 PM Andy Shevchenko
> > > > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > > > On Mon, Aug 17, 2020 at 07:05:33PM +0200, Bartosz Golaszewski wrote:
> > > > > > > From: Bartosz Golaszewski <bgolaszewski at baylibre.com>

...

> > > > > > > +static struct devres *to_devres(void *data)
> > > > > > > +{
> > > > > > > +     return (struct devres *)((u8 *)data - ALIGN(sizeof(struct devres),
> > > > > > > +                                                 ARCH_KMALLOC_MINALIGN));
> > > > > >
> > > > > > Do you really need both explicit castings?
> > > > > >
> > > > >
> > > > > Yeah, we can probably drop the (struct devres *) here.
> > > >
> > > > void * -> u8 * here is also not needed, it is considered byte access IIRC.
> > > >
> > >
> > > Actually it turns out that while we don't need the (void *) -> (u8 *)
> > > casting, we must cast to (struct devres *) or the following error is
> > > produced:
> > >
> > > drivers/base/devres.c: In function ‘to_devres’:
> > > drivers/base/devres.c:41:21: error: returning ‘u8 *’ {aka ‘unsigned
> > > char *’} from a function with incompatible return type ‘struct devres
> > > *’ [-Werror=incompatible-pointer-types]
> > >   return ((u8 *)data - ALIGN(sizeof(struct devres),
> > >          ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >         ARCH_KMALLOC_MINALIGN));
> > >         ~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Of course, you have to drop u8 * casting as well.
> >
> 
> Yes, of course. Duh

With this addressed (and don't forget to remove also unneeded parentheses),
Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Thanks!

-- 
With Best Regards,
Andy Shevchenko