[v2,2/3] auxdisplay: Move cfag12864b.h to the subsystem folder

  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 <andriy.shevchenko@linux.intel.com>
---
 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%)
  

Hi Andy,

On Mon, Feb 12, 2024 at 2:37 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> 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 <ojeda@kernel.org>
> >  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
  

On Wed, Feb 14, 2024 at 5:59 PM Geert Uytterhoeven <geert@linux-m68k.org> 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
  

On Wed, Feb 14, 2024 at 06:15:48PM +0100, Miguel Ojeda wrote:
> On Wed, Feb 14, 2024 at 5:59 PM Geert Uytterhoeven <geert@linux-m68k.org> 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?
  

On Wed, Feb 14, 2024 at 6:40 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> 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
  

On Wed, Feb 14, 2024 at 06:42:56PM +0100, Miguel Ojeda wrote:
> On Wed, Feb 14, 2024 at 6:40 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> 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.
  

Hi Andy,

On Wed, Feb 14, 2024 at 6:50 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> 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
> > <andriy.shevchenko@linux.intel.com> 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
  

On Wed, Feb 14, 2024 at 6:50 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> 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 07:48:31PM +0100, Miguel Ojeda wrote:
> On Wed, Feb 14, 2024 at 6:50 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> 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.
  

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
> > <andriy.shevchenko@linux.intel.com> 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