All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Raphaël Gallais-Pou" <rgallaispou@gmail.com>
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: fbtft: ili9341: use macro FBTFT_REGISTER_SPI_DRIVER
Date: Mon, 3 Jul 2023 15:25:00 +0200	[thread overview]
Message-ID: <2023070312-pasty-divisive-fa22@gregkh> (raw)
In-Reply-To: <ae400e28-0cd4-cdf8-811d-843e62cd4a95@gmail.com>

On Sun, Jul 02, 2023 at 03:05:25PM +0200, Raphaël Gallais-Pou wrote:
> Hi,
> 
> Le 02/07/2023 à 14:02, Greg Kroah-Hartman a écrit :
> > On Sun, Jul 02, 2023 at 10:03:24AM +0200, Raphael Gallais-Pou wrote:
> > > Using FBTFT_REGISTER_DRIVER resolves to a NULL struct spi_device_id. This
> > > ultimately causes the module to an early exit at probe time.
> > 
> > So this doesn't work at all today?  Has it ever worked?  What commit
> > does thi fix?
> 
> I tested again with only a tweak in my device-tree. The early exit in the
> driver's code is caused by a missing field. So regarding this particular
> driver the macro works.
> 
> It resolves to set spi_driver.id_table = NULL, which yields a warning in
> __spi_register_driver(). So I guess this patch only fixes a warning.

Ok, please fix the changelog text when you resend this.

> > > In addition the MODULE_ALIASes can be dropped.
> > 
> > Why?  When you say "also" or "in addition", that's a huge hint it should
> > be a separate patch.
> I did not find any reference to those aliases in the kernel, which led me to
> remove those.

Aliases are used by userspace, not the kernel.

> If you think they are still necessary, I'll split them in an upcoming v2.

Please document why they are not needed in order to be able to be
removed.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Raphaël Gallais-Pou" <rgallaispou@gmail.com>
Cc: linux-fbdev@vger.kernel.org, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] staging: fbtft: ili9341: use macro FBTFT_REGISTER_SPI_DRIVER
Date: Mon, 3 Jul 2023 15:25:00 +0200	[thread overview]
Message-ID: <2023070312-pasty-divisive-fa22@gregkh> (raw)
In-Reply-To: <ae400e28-0cd4-cdf8-811d-843e62cd4a95@gmail.com>

On Sun, Jul 02, 2023 at 03:05:25PM +0200, Raphaël Gallais-Pou wrote:
> Hi,
> 
> Le 02/07/2023 à 14:02, Greg Kroah-Hartman a écrit :
> > On Sun, Jul 02, 2023 at 10:03:24AM +0200, Raphael Gallais-Pou wrote:
> > > Using FBTFT_REGISTER_DRIVER resolves to a NULL struct spi_device_id. This
> > > ultimately causes the module to an early exit at probe time.
> > 
> > So this doesn't work at all today?  Has it ever worked?  What commit
> > does thi fix?
> 
> I tested again with only a tweak in my device-tree. The early exit in the
> driver's code is caused by a missing field. So regarding this particular
> driver the macro works.
> 
> It resolves to set spi_driver.id_table = NULL, which yields a warning in
> __spi_register_driver(). So I guess this patch only fixes a warning.

Ok, please fix the changelog text when you resend this.

> > > In addition the MODULE_ALIASes can be dropped.
> > 
> > Why?  When you say "also" or "in addition", that's a huge hint it should
> > be a separate patch.
> I did not find any reference to those aliases in the kernel, which led me to
> remove those.

Aliases are used by userspace, not the kernel.

> If you think they are still necessary, I'll split them in an upcoming v2.

Please document why they are not needed in order to be able to be
removed.

thanks,

greg k-h

  reply	other threads:[~2023-07-03 13:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-02  8:03 [PATCH] staging: fbtft: ili9341: use macro FBTFT_REGISTER_SPI_DRIVER Raphael Gallais-Pou
2023-07-02  8:03 ` Raphael Gallais-Pou
2023-07-02 12:02 ` Greg Kroah-Hartman
2023-07-02 12:02   ` Greg Kroah-Hartman
2023-07-02 13:05   ` Raphaël Gallais-Pou
2023-07-02 13:05     ` Raphaël Gallais-Pou
2023-07-03 13:25     ` Greg Kroah-Hartman [this message]
2023-07-03 13:25       ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2023070312-pasty-divisive-fa22@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=rgallaispou@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.