Update MAINTAINERS for AUXDISPLAY subsystem in accordance to the last
(administrative) changes.
In v2:
- included Geert as Reviewer and added Git tree
- added two more patches that are related to MAINTAINERS
Andy Shevchenko (3):
auxdisplay: Take over maintainership, but in Odd Fixes mode
auxdisplay: Move cfag12864b.h to the subsystem folder
auxdisplay: Add 7 and 14 segment mappings to MAINTAINERS
MAINTAINERS | 11 ++++++-----
drivers/auxdisplay/cfag12864b.c | 2 +-
{include/linux => drivers/auxdisplay}/cfag12864b.h | 0
drivers/auxdisplay/cfag12864bfb.c | 3 ++-
4 files changed, 9 insertions(+), 7 deletions(-)
rename {include/linux => drivers/auxdisplay}/cfag12864b.h (100%)
--
2.43.0.rc1.1.gbec44491f096
There is no users outside of auxdisplay subsystem for the cfag12864b.h.
Move include/linux/cfag12864b.h to drivers/auxdisplay.
Signed-off-by: Andy Shevchenko <[email protected]>
---
MAINTAINERS | 3 ---
drivers/auxdisplay/cfag12864b.c | 2 +-
{include/linux => drivers/auxdisplay}/cfag12864b.h | 0
drivers/auxdisplay/cfag12864bfb.c | 3 ++-
4 files changed, 3 insertions(+), 5 deletions(-)
rename {include/linux => drivers/auxdisplay}/cfag12864b.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index e2a804e22c3b..e981d7274756 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3412,7 +3412,6 @@ S: Odd Fixes
T: git git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay.git
F: Documentation/devicetree/bindings/auxdisplay/
F: drivers/auxdisplay/
-F: include/linux/cfag12864b.h
AVIA HX711 ANALOG DIGITAL CONVERTER IIO DRIVER
M: Andreas Klinger <[email protected]>
@@ -4900,13 +4899,11 @@ CFAG12864B LCD DRIVER
M: Miguel Ojeda <[email protected]>
S: Maintained
F: drivers/auxdisplay/cfag12864b.c
-F: include/linux/cfag12864b.h
CFAG12864BFB LCD FRAMEBUFFER DRIVER
M: Miguel Ojeda <[email protected]>
S: Maintained
F: drivers/auxdisplay/cfag12864bfb.c
-F: include/linux/cfag12864b.h
CHAR and MISC DRIVERS
M: Arnd Bergmann <[email protected]>
diff --git a/drivers/auxdisplay/cfag12864b.c b/drivers/auxdisplay/cfag12864b.c
index 6526aa51fb1d..6a8368a37121 100644
--- a/drivers/auxdisplay/cfag12864b.c
+++ b/drivers/auxdisplay/cfag12864b.c
@@ -23,8 +23,8 @@
#include <linux/vmalloc.h>
#include <linux/workqueue.h>
#include <linux/ks0108.h>
-#include <linux/cfag12864b.h>
+#include "cfag12864b.h"
#define CFAG12864B_NAME "cfag12864b"
diff --git a/include/linux/cfag12864b.h b/drivers/auxdisplay/cfag12864b.h
similarity index 100%
rename from include/linux/cfag12864b.h
rename to drivers/auxdisplay/cfag12864b.h
diff --git a/drivers/auxdisplay/cfag12864bfb.c b/drivers/auxdisplay/cfag12864bfb.c
index 5ba19c339f08..19ba3977ad7d 100644
--- a/drivers/auxdisplay/cfag12864bfb.c
+++ b/drivers/auxdisplay/cfag12864bfb.c
@@ -16,7 +16,8 @@
#include <linux/fb.h>
#include <linux/mm.h>
#include <linux/platform_device.h>
-#include <linux/cfag12864b.h>
+
+#include "cfag12864b.h"
#define CFAG12864BFB_NAME "cfag12864bfb"
--
2.43.0.rc1.1.gbec44491f096
On Mon, Feb 12, 2024 at 03:23:54PM +0200, Andy Shevchenko wrote:
> There is no users outside of auxdisplay subsystem for the cfag12864b.h.
> Move include/linux/cfag12864b.h to drivers/auxdisplay.
..
> F: drivers/auxdisplay/cfag12864b.c
> -F: include/linux/cfag12864b.h
>
> CFAG12864BFB LCD FRAMEBUFFER DRIVER
> M: Miguel Ojeda <[email protected]>
> S: Maintained
> F: drivers/auxdisplay/cfag12864bfb.c
> -F: include/linux/cfag12864b.h
Should be replaced. Done locally.
--
With Best Regards,
Andy Shevchenko
The mapping files are tightly related to auxdisplay subsystem.
Add them to the MAINTAINERS database.
Signed-off-by: Andy Shevchenko <[email protected]>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e981d7274756..1c39b89ba749 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3412,6 +3412,8 @@ S: Odd Fixes
T: git git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay.git
F: Documentation/devicetree/bindings/auxdisplay/
F: drivers/auxdisplay/
+F: include/uapi/linux/map_to_14segment.h
+F: include/uapi/linux/map_to_7segment.h
AVIA HX711 ANALOG DIGITAL CONVERTER IIO DRIVER
M: Andreas Klinger <[email protected]>
--
2.43.0.rc1.1.gbec44491f096
I have no time for this, but since it looks like I'm the main
contributor for the last few years to the subsystem, I'll take
it for now. Geert agreed to help me with as a designated reviwer.
Let's see how it will go...
Signed-off-by: Andy Shevchenko <[email protected]>
---
MAINTAINERS | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 75cf018922a4..e2a804e22c3b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3406,8 +3406,10 @@ F: drivers/base/auxiliary.c
F: include/linux/auxiliary_bus.h
AUXILIARY DISPLAY DRIVERS
-M: Miguel Ojeda <[email protected]>
-S: Maintained
+M: Andy Shevchenko <[email protected]>
+R: Geert Uytterhoeven <[email protected]>
+S: Odd Fixes
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay.git
F: Documentation/devicetree/bindings/auxdisplay/
F: drivers/auxdisplay/
F: include/linux/cfag12864b.h
--
2.43.0.rc1.1.gbec44491f096
On Mon, Feb 12, 2024 at 05:33:39PM +0100, Thomas Zimmermann wrote:
> (cc'ing Javier Martinez Canillas)
>
> Hi
>
> Am 12.02.24 um 14:23 schrieb Andy Shevchenko:
> > I have no time for this, but since it looks like I'm the main
> > contributor for the last few years to the subsystem, I'll take
> > it for now. Geert agreed to help me with as a designated reviwer.
> > Let's see how it will go...
>
> A few days ago, I talked to Javier about how auxdisplay is a hotchpodge of
> various drivers that seem to belong into other subsystems. Could we attempt
> to move all drivers into other places and then remove the auxdisplay
> subsystem?
Can you be more precise on how it can be done? We have at least two clusters of
the displays: line-display and HD44780-based ones. Moreover, the latter might
use the former in the future (in some cases).
--
With Best Regards,
Andy Shevchenko
(cc'ing Javier Martinez Canillas)
Hi
Am 12.02.24 um 14:23 schrieb Andy Shevchenko:
> I have no time for this, but since it looks like I'm the main
> contributor for the last few years to the subsystem, I'll take
> it for now. Geert agreed to help me with as a designated reviwer.
> Let's see how it will go...
A few days ago, I talked to Javier about how auxdisplay is a hotchpodge
of various drivers that seem to belong into other subsystems. Could we
attempt to move all drivers into other places and then remove the
auxdisplay subsystem?
Best regards
Thomas
>
> Signed-off-by: Andy Shevchenko <[email protected]>
> ---
> MAINTAINERS | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 75cf018922a4..e2a804e22c3b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3406,8 +3406,10 @@ F: drivers/base/auxiliary.c
> F: include/linux/auxiliary_bus.h
>
> AUXILIARY DISPLAY DRIVERS
> -M: Miguel Ojeda <[email protected]>
> -S: Maintained
> +M: Andy Shevchenko <[email protected]>
> +R: Geert Uytterhoeven <[email protected]>
> +S: Odd Fixes
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay.git
> F: Documentation/devicetree/bindings/auxdisplay/
> F: drivers/auxdisplay/
> F: include/linux/cfag12864b.h
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
On Mon, Feb 12, 2024 at 03:23:52PM +0200, Andy Shevchenko wrote:
> Update MAINTAINERS for AUXDISPLAY subsystem in accordance to the last
> (administrative) changes.
Found a couple of issues, but I will wait for tags other comments
and then update the whole series.
--
With Best Regards,
Andy Shevchenko
On Mon, Feb 12, 2024 at 03:23:53PM +0200, Andy Shevchenko wrote:
> I have no time for this, but since it looks like I'm the main
> contributor for the last few years to the subsystem, I'll take
> it for now. Geert agreed to help me with as a designated reviwer.
The typo ("reviewer") has been fixed locally.
> Let's see how it will go...
--
With Best Regards,
Andy Shevchenko
On Mon, Feb 12, 2024 at 06:42:48PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 12, 2024 at 05:33:39PM +0100, Thomas Zimmermann wrote:
> > Am 12.02.24 um 14:23 schrieb Andy Shevchenko:
> > > I have no time for this, but since it looks like I'm the main
> > > contributor for the last few years to the subsystem, I'll take
> > > it for now. Geert agreed to help me with as a designated reviwer.
> > > Let's see how it will go...
> >
> > A few days ago, I talked to Javier about how auxdisplay is a hotchpodge of
> > various drivers that seem to belong into other subsystems. Could we attempt
> > to move all drivers into other places and then remove the auxdisplay
> > subsystem?
>
> Can you be more precise on how it can be done? We have at least two clusters of
> the displays: line-display and HD44780-based ones. Moreover, the latter might
> use the former in the future (in some cases).
Btw, I have no time for major things here, if you wish, please take over,
I will be happy to get rid of this.
--
With Best Regards,
Andy Shevchenko
On Mon, Feb 12, 2024 at 2:27 PM Andy Shevchenko
<[email protected]> wrote:
>
> I have no time for this, but since it looks like I'm the main
> contributor for the last few years to the subsystem, I'll take
> it for now. Geert agreed to help me with as a designated reviwer.
> Let's see how it will go...
Thanks Andy, I appreciate it:
Acked-by: Miguel Ojeda <[email protected]>
if you want to already take it yourself :)
Otherwise I can pick it up.
Cheers,
Miguel
Andy Shevchenko <[email protected]> writes:
Hello Andy,
> On Mon, Feb 12, 2024 at 06:42:48PM +0200, Andy Shevchenko wrote:
>> On Mon, Feb 12, 2024 at 05:33:39PM +0100, Thomas Zimmermann wrote:
>> > Am 12.02.24 um 14:23 schrieb Andy Shevchenko:
>> > > I have no time for this, but since it looks like I'm the main
>> > > contributor for the last few years to the subsystem, I'll take
>> > > it for now. Geert agreed to help me with as a designated reviwer.
>> > > Let's see how it will go...
AFAICT Miguel Ojeda is quite responsive and is still doing reviews/acks
for auxdisplay patches. Can you elaborate why the maintainership change
has to be made?
You can still be listed as co-maintainer of course, and maybe Miguel is
on board to drop this but then I think that should be mentioned in your
commit message (and have an ack from him).
>> >
>> > A few days ago, I talked to Javier about how auxdisplay is a hotchpodge of
>> > various drivers that seem to belong into other subsystems. Could we attempt
>> > to move all drivers into other places and then remove the auxdisplay
>> > subsystem?
>>
>> Can you be more precise on how it can be done? We have at least two clusters of
>> the displays: line-display and HD44780-based ones. Moreover, the latter might
>> use the former in the future (in some cases).
>
For line-display and 7-segment display I'm less sure, and it may be that
we do need a specific subsystem for those. But then maybe it has to be
renamed to text-based or character based displays instead ?
I wonder though if these can be modeled as an output only tty instead.
There are though more than these two types of display, for example the
cfag12864bfb driver is a FB_VISUAL_MONO10 fbdev driver:
https://elixir.bootlin.com/linux/latest/source/drivers/auxdisplay/cfag12864bfb.c
Now that we have better support in DRM/KMS for monochrome displays, it
seems to me that could be even ported and be a modesetting driver. I've
mentioned this to a colleague who wants to get start with Linux graphics
as a good learning exercise.
I believe the problem is that auxdisplay is too vague of a term, so anything
could be an "auxdisplay". Even tiny I2C/SPI panels could be defined as that.
> Btw, I have no time for major things here, if you wish, please take over,
> I will be happy to get rid of this.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Hi
Am 12.02.24 um 17:42 schrieb Andy Shevchenko:
> On Mon, Feb 12, 2024 at 05:33:39PM +0100, Thomas Zimmermann wrote:
>> (cc'ing Javier Martinez Canillas)
>>
>> Hi
>>
>> Am 12.02.24 um 14:23 schrieb Andy Shevchenko:
>>> I have no time for this, but since it looks like I'm the main
>>> contributor for the last few years to the subsystem, I'll take
>>> it for now. Geert agreed to help me with as a designated reviwer.
>>> Let's see how it will go...
>> A few days ago, I talked to Javier about how auxdisplay is a hotchpodge of
>> various drivers that seem to belong into other subsystems. Could we attempt
>> to move all drivers into other places and then remove the auxdisplay
>> subsystem?
> Can you be more precise on how it can be done? We have at least two clusters of
> the displays: line-display and HD44780-based ones. Moreover, the latter might
> use the former in the future (in some cases).
I see. Taking a closer look, it's not as simple as I implied.
We noticed that cfag1286bfb and ht16k33 are fbdev-based drivers. They
seem to belong into video/fbdev. But OTOH ht16k33 appears to drive
14-segment displays and fbdev appears to be an odd choice for such
devices. And as Javier already noted, we wondered if these charlcd
displays aren't just a special case of TTYs.
Best regards
Thomas
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Hi Thomas,
On Tue, Feb 13, 2024 at 9:28 AM Thomas Zimmermann <tzimmermann@susede> wrote:
> Am 12.02.24 um 17:42 schrieb Andy Shevchenko:
> > On Mon, Feb 12, 2024 at 05:33:39PM +0100, Thomas Zimmermann wrote:
> >> (cc'ing Javier Martinez Canillas)
> >> Am 12.02.24 um 14:23 schrieb Andy Shevchenko:
> >>> I have no time for this, but since it looks like I'm the main
> >>> contributor for the last few years to the subsystem, I'll take
> >>> it for now. Geert agreed to help me with as a designated reviwer.
> >>> Let's see how it will go...
> >> A few days ago, I talked to Javier about how auxdisplay is a hotchpodge of
> >> various drivers that seem to belong into other subsystems. Could we attempt
> >> to move all drivers into other places and then remove the auxdisplay
> >> subsystem?
> > Can you be more precise on how it can be done? We have at least two clusters of
> > the displays: line-display and HD44780-based ones. Moreover, the latter might
> > use the former in the future (in some cases).
>
> I see. Taking a closer look, it's not as simple as I implied.
>
> We noticed that cfag1286bfb and ht16k33 are fbdev-based drivers. They
> seem to belong into video/fbdev. But OTOH ht16k33 appears to drive
> 14-segment displays and fbdev appears to be an odd choice for such
> devices. And as Javier already noted, we wondered if these charlcd
> displays aren't just a special case of TTYs.
HT16K33 uses line-display for 7/14-segment displays, and fbdev
for dot-matrix displays. And input for the optional keypad.
I started working on splitting the functionality, at least
CONFIG_*-wise, so you can still build it for line-display with
CONFIG_FB=n, but I was distracted by more important work...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Feb 13, 2024 at 9:10 AM Javier Martinez Canillas
<[email protected]> wrote:
>
> AFAICT Miguel Ojeda is quite responsive and is still doing reviews/acks
> for auxdisplay patches. Can you elaborate why the maintainership change
> has to be made?
>
> You can still be listed as co-maintainer of course, and maybe Miguel is
> on board to drop this but then I think that should be mentioned in your
> commit message (and have an ack from him).
Thanks Javier, I appreciate the kind words.
To clarify, auxdisplay has had just about 16 patches a year (i.e. very
low), and a significant fraction of those came from Andy and Geert. In
addition, they have some of the relevant hardware and have tested
patches in the past (which I really appreciated). By contrast, I have
not had any of the hardware for years now.
So I asked Geert and Andy in private if they wanted to become the
maintainers/reviewers. They do not have much time, but Andy wants to
submit a new driver anyway, so we ended up going with Andy as M and
Geert as R, which I really appreciate.
If somebody else wants to join, I am sure they would be happy to. And
for those that may not be involved with upstream development but have
some kernel development experience, this may be a nice opportunity as
well to try becoming a reviewer/maintainer -- it is a small, fun
subsystem (if you have the hardware), with low traffic, and with a few
experienced maintainers around it like Andy and Geert that may be able
to help test patches etc.
Cheers,
Miguel
On Tue, Feb 13, 2024 at 09:10:48AM +0100, Javier Martinez Canillas wrote:
> Andy Shevchenko <[email protected]> writes:
> > On Mon, Feb 12, 2024 at 06:42:48PM +0200, Andy Shevchenko wrote:
> >> On Mon, Feb 12, 2024 at 05:33:39PM +0100, Thomas Zimmermann wrote:
> >> > Am 12.02.24 um 14:23 schrieb Andy Shevchenko:
..
> >> > > I have no time for this, but since it looks like I'm the main
> >> > > contributor for the last few years to the subsystem, I'll take
> >> > > it for now. Geert agreed to help me with as a designated reviwer.
> >> > > Let's see how it will go...
>
> AFAICT Miguel Ojeda is quite responsive and is still doing reviews/acks
> for auxdisplay patches. Can you elaborate why the maintainership change
> has to be made?
>
> You can still be listed as co-maintainer of course, and maybe Miguel is
> on board to drop this but then I think that should be mentioned in your
> commit message (and have an ack from him).
He answered you in a separate email. I have nothing to add.
..
> >> > A few days ago, I talked to Javier about how auxdisplay is a hotchpodge of
> >> > various drivers that seem to belong into other subsystems. Could we attempt
> >> > to move all drivers into other places and then remove the auxdisplay
> >> > subsystem?
> >>
> >> Can you be more precise on how it can be done? We have at least two clusters of
> >> the displays: line-display and HD44780-based ones. Moreover, the latter might
> >> use the former in the future (in some cases).
>
> For line-display and 7-segment display I'm less sure, and it may be that
> we do need a specific subsystem for those. But then maybe it has to be
> renamed to text-based or character based displays instead ?
"text" is incorrect term here, as 7-segment LEDs can only emulate text to some
extent. Poorly TBH. HD44780 can hold the overrides for the font, which makes
it not so text either (yes, the old xGA [x = C,E,V,...] display controllers
already can do the same in some text modes).
> I wonder though if these can be modeled as an output only tty instead.
>
> There are though more than these two types of display, for example the
> cfag12864bfb driver is a FB_VISUAL_MONO10 fbdev driver:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/auxdisplay/cfag12864bfb.c
>
> Now that we have better support in DRM/KMS for monochrome displays, it
> seems to me that could be even ported and be a modesetting driver. I've
> mentioned this to a colleague who wants to get start with Linux graphics
> as a good learning exercise.
I believe you are too much focused on the _exceptional_ drivers, most of which
are _not_ FB ones.
> I believe the problem is that auxdisplay is too vague of a term, so anything
> could be an "auxdisplay". Even tiny I2C/SPI panels could be defined as that.
I understand the term well, SPI/I2C display, when it's the main one can't be
aux. The latter one, e.g., is an LCD on the server panel, or 7-segment LEDs
on the motherboard for debug.
Definitely, as a maintainer, I would not accept the driver that belongs to
FB/DRM if it's clear that it has no tights to the 7-seg/N-seg / line or its
main usage is display panels.
> > Btw, I have no time for major things here, if you wish, please take over,
> > I will be happy to get rid of this.
--
With Best Regards,
Andy Shevchenko
On Mon, Feb 12, 2024 at 03:23:52PM +0200, Andy Shevchenko wrote:
> Update MAINTAINERS for AUXDISPLAY subsystem in accordance to the last
> (administrative) changes.
>
> In v2:
> - included Geert as Reviewer and added Git tree
> - added two more patches that are related to MAINTAINERS
Pushed to my tree, thanks!
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 14, 2024 at 5:59 PM Geert Uytterhoeven <[email protected]> wrote:
>
> /me looked at your branch
>
> Just use a pattern? drivers/auxdisplay/cfag12864b*
+1
In fact, for `cfag12864b{,fb}` and `ks0108`, they should probably go
into staging anyway and removed if nobody complains (I am not aware of
anyone using them nowadays).
Cheers,
Miguel
Hi Andy,
On Mon, Feb 12, 2024 at 2:37 PM Andy Shevchenko
<[email protected]> wrote:
> On Mon, Feb 12, 2024 at 03:23:54PM +0200, Andy Shevchenko wrote:
> > There is no users outside of auxdisplay subsystem for the cfag12864b.h.
> > Move include/linux/cfag12864b.h to drivers/auxdisplay.
>
> ...
>
> > F: drivers/auxdisplay/cfag12864b.c
> > -F: include/linux/cfag12864b.h
> >
> > CFAG12864BFB LCD FRAMEBUFFER DRIVER
> > M: Miguel Ojeda <[email protected]>
> > S: Maintained
> > F: drivers/auxdisplay/cfag12864bfb.c
> > -F: include/linux/cfag12864b.h
>
> Should be replaced. Done locally.
/me looked at your branch
Just use a pattern? drivers/auxdisplay/cfag12864b*
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Feb 12, 2024 at 2:27 PM Andy Shevchenko
<[email protected]> wrote:
> The mapping files are tightly related to auxdisplay subsystem.
> Add them to the MAINTAINERS database.
>
> Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Feb 14, 2024 at 06:15:48PM +0100, Miguel Ojeda wrote:
> On Wed, Feb 14, 2024 at 5:59 PM Geert Uytterhoeven <[email protected]> wrote:
> >
> > /me looked at your branch
> >
> > Just use a pattern? drivers/auxdisplay/cfag12864b*
>
> +1
I don't want to rebase, esp. taking into account the proposal below.
> In fact, for `cfag12864b{,fb}` and `ks0108`, they should probably go
> into staging anyway and removed if nobody complains (I am not aware of
> anyone using them nowadays).
Send a patch?
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 14, 2024 at 6:40 PM Andy Shevchenko
<[email protected]> wrote:
>
> I don't want to rebase, esp. taking into account the proposal below.
Why do you not want to rebase?
The proposal is orthogonal in any case.
Cheers,
Miguel
Hi Andy,
On Wed, Feb 14, 2024 at 6:50 PM Andy Shevchenko
<[email protected]> wrote:
> On Wed, Feb 14, 2024 at 06:42:56PM +0100, Miguel Ojeda wrote:
> > On Wed, Feb 14, 2024 at 6:40 PM Andy Shevchenko
> > <[email protected]> wrote:
> > > I don't want to rebase, esp. taking into account the proposal below.
> >
> > Why do you not want to rebase?
>
> It's a standard practice in the Linux kernel development.
> If it's not a so critical issue, why should we rebase?
>
> rebasing will break SHA sums and it's not appreciated especially at the late
> rcX weeks. Linus can even refuse to accept a PR based on this fact.
Come on, we're only at rc4.
Given the (lack of a) gazillion of auxdisplay users, I doubt anyone is
basing a tree to be pulled in some other subsystem on your auxdisplay
tree.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Feb 14, 2024 at 6:50 PM Andy Shevchenko
<[email protected]> wrote:
>
> It's a standard practice in the Linux kernel development.
> If it's not a so critical issue, why should we rebase?
>
> rebasing will break SHA sums and it's not appreciated especially at the late
> rcX weeks. Linus can even refuse to accept a PR based on this fact.
I am well aware of what rebasing does and the rules for PRs to Linus, thank you.
First of all, you should have not applied the patch this quickly.
Nobody gave a tag for it and you yourself are the author. Even if
someone gave you a tag, 2 days is way too little time for something
like auxdisplay. 2 weeks would be a more reasonable time frame.
The point is: you seem to be rejecting feedback on the basis that you
already applied a patch that you yourself authored 2 days ago. Not
good.
Now, for branches in linux-next, what you should avoid is rebasing
wildly, but you can still do so if needed. If you are uncomfortable
with that, then you should avoid rushing patches to begin with so that
you don't have to do that.
Regarding PRs to Linus, we are still in -rc4. There is plenty of time
to bake things in `linux-next`. Unless you meant to sent this to a -rc
release. But in that case: 1) there is no rush, 2) please see the
first point again.
Cheers,
Miguel
On Wed, Feb 14, 2024 at 06:42:56PM +0100, Miguel Ojeda wrote:
> On Wed, Feb 14, 2024 at 6:40 PM Andy Shevchenko
> <[email protected]> wrote:
> >
> > I don't want to rebase, esp. taking into account the proposal below.
>
> Why do you not want to rebase?
It's a standard practice in the Linux kernel development.
If it's not a so critical issue, why should we rebase?
rebasing will break SHA sums and it's not appreciated especially at the late
rcX weeks. Linus can even refuse to accept a PR based on this fact.
> The proposal is orthogonal in any case.
True.
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 14, 2024 at 07:48:31PM +0100, Miguel Ojeda wrote:
> On Wed, Feb 14, 2024 at 6:50 PM Andy Shevchenko
> <[email protected]> wrote:
> >
> > It's a standard practice in the Linux kernel development.
> > If it's not a so critical issue, why should we rebase?
> >
> > rebasing will break SHA sums and it's not appreciated especially at the late
> > rcX weeks. Linus can even refuse to accept a PR based on this fact.
>
> I am well aware of what rebasing does and the rules for PRs to Linus, thank you.
>
> First of all, you should have not applied the patch this quickly.
> Nobody gave a tag for it and you yourself are the author. Even if
> someone gave you a tag, 2 days is way too little time for something
> like auxdisplay. 2 weeks would be a more reasonable time frame.
>
> The point is: you seem to be rejecting feedback on the basis that you
> already applied a patch that you yourself authored 2 days ago. Not
> good.
>
> Now, for branches in linux-next, what you should avoid is rebasing
> wildly, but you can still do so if needed. If you are uncomfortable
> with that, then you should avoid rushing patches to begin with so that
> you don't have to do that.
>
> Regarding PRs to Linus, we are still in -rc4. There is plenty of time
> to bake things in `linux-next`. Unless you meant to sent this to a -rc
> release. But in that case: 1) there is no rush, 2) please see the
> first point again.
Okay, I dropped that patch from the queue.
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 14, 2024 at 08:54:02PM +0200, Andy Shevchenko wrote:
> On Wed, Feb 14, 2024 at 07:48:31PM +0100, Miguel Ojeda wrote:
> > On Wed, Feb 14, 2024 at 6:50 PM Andy Shevchenko
> > <[email protected]> wrote:
> > >
> > > It's a standard practice in the Linux kernel development.
> > > If it's not a so critical issue, why should we rebase?
> > >
> > > rebasing will break SHA sums and it's not appreciated especially at the late
> > > rcX weeks. Linus can even refuse to accept a PR based on this fact.
> >
> > I am well aware of what rebasing does and the rules for PRs to Linus, thank you.
> >
> > First of all, you should have not applied the patch this quickly.
> > Nobody gave a tag for it and you yourself are the author. Even if
> > someone gave you a tag, 2 days is way too little time for something
> > like auxdisplay. 2 weeks would be a more reasonable time frame.
> >
> > The point is: you seem to be rejecting feedback on the basis that you
> > already applied a patch that you yourself authored 2 days ago. Not
> > good.
> >
> > Now, for branches in linux-next, what you should avoid is rebasing
> > wildly, but you can still do so if needed. If you are uncomfortable
> > with that, then you should avoid rushing patches to begin with so that
> > you don't have to do that.
> >
> > Regarding PRs to Linus, we are still in -rc4. There is plenty of time
> > to bake things in `linux-next`. Unless you meant to sent this to a -rc
> > release. But in that case: 1) there is no rush, 2) please see the
> > first point again.
>
> Okay, I dropped that patch from the queue.
To be clear why:
- I don't see how to use pattern that won't collide with the other record
- reducing churn in case you want to move this to staging
--
With Best Regards,
Andy Shevchenko