| Message ID | 2024010439-cauterize-trash-b603@gregkh (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | patch "maple: make maple_bus_type static and const" added to char-misc-testing | expand |
Hi Greg! On Thu, 2024-01-04 at 14:37 +0100, gregkh@linuxfoundation.org wrote: > This is a note to let you know that I've just added the patch titled > > maple: make maple_bus_type static and const > > to my char-misc git tree which can be found at > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > in the char-misc-testing branch. > > The patch will show up in the next release of the linux-next tree > (usually sometime within the next 24 hours during the week.) > > The patch will be merged to the char-misc-next branch sometime soon, > after it passes testing, and the merge window is open. > > If you have any questions about this process, please let me know. > > > From e76933a9bfa9b7f28a387f2e13cb3e689adc200d Mon Sep 17 00:00:00 2001 > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Date: Tue, 19 Dec 2023 15:06:19 +0100 > Subject: maple: make maple_bus_type static and const > > There is no need to export maple_bus_type as no one uses it outside of > maple.c, so make it static, AND make it const as it can be read-only as > no one modifies it. I was planning to start reviewing patches for arch/sh the upcoming weekend, so you don't have to take the patch through your own tree. I was on vacation the past two weeks, so I didn't do any kernel stuff. Adrian
On Thu, Jan 04, 2024 at 02:48:18PM +0100, John Paul Adrian Glaubitz wrote: > Hi Greg! > > On Thu, 2024-01-04 at 14:37 +0100, gregkh@linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > > > maple: make maple_bus_type static and const > > > > to my char-misc git tree which can be found at > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > > in the char-misc-testing branch. > > > > The patch will show up in the next release of the linux-next tree > > (usually sometime within the next 24 hours during the week.) > > > > The patch will be merged to the char-misc-next branch sometime soon, > > after it passes testing, and the merge window is open. > > > > If you have any questions about this process, please let me know. > > > > > > From e76933a9bfa9b7f28a387f2e13cb3e689adc200d Mon Sep 17 00:00:00 2001 > > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Date: Tue, 19 Dec 2023 15:06:19 +0100 > > Subject: maple: make maple_bus_type static and const > > > > There is no need to export maple_bus_type as no one uses it outside of > > maple.c, so make it static, AND make it const as it can be read-only as > > no one modifies it. > > I was planning to start reviewing patches for arch/sh the upcoming weekend, > so you don't have to take the patch through your own tree. No worries, this way it gets into 6.8-rc1. thanks, greg k-h
On Thu, 2024-01-04 at 14:57 +0100, Greg KH wrote: > > I was planning to start reviewing patches for arch/sh the upcoming weekend, > > so you don't have to take the patch through your own tree. > > No worries, this way it gets into 6.8-rc1. But the merge window for 6.8-rc1 isn't open yet, is it? I wanted to at least get a chance for review before something is landed for arch/sh. Adrian
Hi Adrian, On Thu, Jan 4, 2024 at 3:02 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > On Thu, 2024-01-04 at 14:57 +0100, Greg KH wrote: > > > I was planning to start reviewing patches for arch/sh the upcoming weekend, > > > so you don't have to take the patch through your own tree. > > > > No worries, this way it gets into 6.8-rc1. > > But the merge window for 6.8-rc1 isn't open yet, is it? The merge window will open this Monday. However, everything should be present in linux-next before that, which means it should be applied today, before Stephen (UTC+11!) wakes up... Gr{oetje,eeting}s, Geert
On Thu, Jan 04, 2024 at 03:02:36PM +0100, John Paul Adrian Glaubitz wrote: > On Thu, 2024-01-04 at 14:57 +0100, Greg KH wrote: > > > I was planning to start reviewing patches for arch/sh the upcoming weekend, > > > so you don't have to take the patch through your own tree. > > > > No worries, this way it gets into 6.8-rc1. > > But the merge window for 6.8-rc1 isn't open yet, is it? It has to be in linux-next _BEFORE_ the merge window opens. thanks, greg k-h
On Thu, 2024-01-04 at 15:20 +0100, Greg KH wrote: > On Thu, Jan 04, 2024 at 03:02:36PM +0100, John Paul Adrian Glaubitz wrote: > > On Thu, 2024-01-04 at 14:57 +0100, Greg KH wrote: > > > > I was planning to start reviewing patches for arch/sh the upcoming weekend, > > > > so you don't have to take the patch through your own tree. > > > > > > No worries, this way it gets into 6.8-rc1. > > > > But the merge window for 6.8-rc1 isn't open yet, is it? > > It has to be in linux-next _BEFORE_ the merge window opens. Well, if I do the review on Saturday, it will be in linux-next before the merge window opens. I also don't have to send the pull request to Linus the day the merge window opens. I don't understand the hurry. Adrian
Hi Adrian, On Thu, Jan 4, 2024 at 3:41 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > On Thu, 2024-01-04 at 15:20 +0100, Greg KH wrote: > > On Thu, Jan 04, 2024 at 03:02:36PM +0100, John Paul Adrian Glaubitz wrote: > > > On Thu, 2024-01-04 at 14:57 +0100, Greg KH wrote: > > > > > I was planning to start reviewing patches for arch/sh the upcoming weekend, > > > > > so you don't have to take the patch through your own tree. > > > > > > > > No worries, this way it gets into 6.8-rc1. > > > > > > But the merge window for 6.8-rc1 isn't open yet, is it? > > > > It has to be in linux-next _BEFORE_ the merge window opens. > > Well, if I do the review on Saturday, it will be in linux-next before the merge > window opens. I also don't have to send the pull request to Linus the day the > merge window opens. If Linux is still in FI, the merge window may open before this Monday's release of linux-next ;-) > I don't understand the hurry. You really should aim to have your for-next branch ready by rc7, so testers can find and report most issues, and you can get them fixed, before the merge window opens. I do admit my (tiny) m68k for-v6.8 branch was created a bit late, due to covid and Xmas holidays, but it is part of linux-next as of today. Thanks! Gr{oetje,eeting}s, Geert
On Thu, 2024-01-04 at 17:01 +0100, Geert Uytterhoeven wrote: > > I don't understand the hurry. > > You really should aim to have your for-next branch ready by rc7, so > testers can find and report most issues, and you can get them fixed, > before the merge window opens. Do testers not go on holiday vacations? I was just on vacation for two weeks and I find it irritating that my work is now overridden because of that. > I do admit my (tiny) m68k for-v6.8 branch was created a bit late, due > to covid and Xmas holidays, but it is part of linux-next as of today. Yes, and I wanted to do it for my tree on Saturday. Adrian
On Thu, Jan 04, 2024 at 07:44:30PM +0100, John Paul Adrian Glaubitz wrote: > On Thu, 2024-01-04 at 17:01 +0100, Geert Uytterhoeven wrote: > > > I don't understand the hurry. > > > > You really should aim to have your for-next branch ready by rc7, so > > testers can find and report most issues, and you can get them fixed, > > before the merge window opens. > > Do testers not go on holiday vacations? I was just on vacation for two > weeks and I find it irritating that my work is now overridden because > of that. What is being overridden here? confused, greg k-h
Hi Adrian, On Thu, Jan 4, 2024 at 7:44 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > On Thu, 2024-01-04 at 17:01 +0100, Geert Uytterhoeven wrote: > > > I don't understand the hurry. > > > > You really should aim to have your for-next branch ready by rc7, so > > testers can find and report most issues, and you can get them fixed, > > before the merge window opens. > > Do testers not go on holiday vacations? I was just on vacation for two > weeks and I find it irritating that my work is now overridden because > of that. Everybody goes on holidays, once in a while. But, you are unhappy about Linus Torvalds announcing during your holidays that there would be an extra rc, postponing the merge window by one week? And without this postponing you would have missed the merge window for sure, so this delay is actually beneficial to you? The merge window is the period when Linus Torvalds merges new developments for the next kernel release. The merge window is not the period when maintainers review and collect new developments for the next kernel release. If you are on holidays just before or during the merge window, you should prepare your branches, and send pull requests, before the merge window opens. Several maintainers have already sent pull requests (the first arrived almost 2 weeks ago). Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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 Fri, 2024-01-05 at 08:34 +0100, Greg KH wrote: > On Thu, Jan 04, 2024 at 07:44:30PM +0100, John Paul Adrian Glaubitz wrote: > > On Thu, 2024-01-04 at 17:01 +0100, Geert Uytterhoeven wrote: > > > > I don't understand the hurry. > > > > > > You really should aim to have your for-next branch ready by rc7, so > > > testers can find and report most issues, and you can get them fixed, > > > before the merge window opens. > > > > Do testers not go on holiday vacations? I was just on vacation for two > > weeks and I find it irritating that my work is now overridden because > > of that. > > What is being overridden here? > > confused, My role as a maintainer of arch/sh to review and apply the patch to my own tree. My understanding is that such a procedure is only applied when the maintainer hasn't been active for months and there has been zero communication from their side. But this has not been the case. I have neither been inactive nor was I not communicating. I was just on vacation. Adrian
On Fri, Jan 05, 2024 at 10:38:00AM +0100, John Paul Adrian Glaubitz wrote: > On Fri, 2024-01-05 at 08:34 +0100, Greg KH wrote: > > On Thu, Jan 04, 2024 at 07:44:30PM +0100, John Paul Adrian Glaubitz wrote: > > > On Thu, 2024-01-04 at 17:01 +0100, Geert Uytterhoeven wrote: > > > > > I don't understand the hurry. > > > > > > > > You really should aim to have your for-next branch ready by rc7, so > > > > testers can find and report most issues, and you can get them fixed, > > > > before the merge window opens. > > > > > > Do testers not go on holiday vacations? I was just on vacation for two > > > weeks and I find it irritating that my work is now overridden because > > > of that. > > > > What is being overridden here? > > > > confused, > > My role as a maintainer of arch/sh to review and apply the patch to my own tree. Maintainer roles are never "no one else can touch my portions of the tree". This specific cleanup patch was sent on December 19, and then due to no response, I applied it to my tree on January 4, a little over 2 week. For a cleanup patch, that didn't add a new feature or do anything really "serious", 2 weeks with no response makes me assume that no one objects to it so I'll just sweep it up with the rest of those types of patches and add them to my tree, especially as the merge window is about to close for new stuff like this. Nothing special, this is how normal tree-wide changes happen all the time, especially for "trivial" stuff like this. thanks, greg k-h
On Fri, 2024-01-05 at 10:45 +0100, Greg KH wrote: > Maintainer roles are never "no one else can touch my portions of the > tree". This specific cleanup patch was sent on December 19, and then > due to no response, I applied it to my tree on January 4, a little over > 2 week. As I said before, I wasn't replying because I was on Christmas vacation. > For a cleanup patch, that didn't add a new feature or do anything really > "serious", 2 weeks with no response makes me assume that no one objects > to it so I'll just sweep it up with the rest of those types of patches > and add them to my tree, especially as the merge window is about to > close for new stuff like this. > > Nothing special, this is how normal tree-wide changes happen all the > time, especially for "trivial" stuff like this. Well, I'm still a newcomer to kernel development and I think it's desirable for newcomers to do the work themselves instead of the experienced people taking away the work. I also would like to do this work at my own pace without being put under pressure to get things reviewed as soon as possible. Adrian
On Fri, 2024-01-05 at 10:13 +0100, Geert Uytterhoeven wrote: > Everybody goes on holidays, once in a while. > > But, you are unhappy about Linus Torvalds announcing during your > holidays that there would be an extra rc, postponing the merge window > by one week? And without this postponing you would have missed the > merge window for sure, so this delay is actually beneficial to you? No, I'm unhappy about the work being taken away from me just because I went on vacation. I'm still practicing all this being relatively new to the kernel work, after all. > The merge window is the period when Linus Torvalds merges new > developments for the next kernel release. > The merge window is not the period when maintainers review and collect > new developments for the next kernel release. I have done some reviews during the merge window before. It's not like the merge window is just open for one day. I know it's not how it's supposed to be, but I am also not sending huge pull requests, so it isn't really an issue at the moment. > If you are on holidays just before or during the merge window, you > should prepare your branches, and send pull requests, before the merge > window opens. Several maintainers have already sent pull requests > (the first arrived almost 2 weeks ago). I am not getting paid for doing kernel stuff. I am doing this completely in my free time, on top of all the time and effort I am investing in Debian to still provide a distribution for older architectures. And, naturally, my primary job has priority over what I do for the kernel. Thus, I cannot always plan my kernel work with the upstream schedule. Adrian
diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c index e05473c5c267..16018009a5a6 100644 --- a/drivers/sh/maple/maple.c +++ b/drivers/sh/maple/maple.c @@ -59,6 +59,7 @@ struct maple_device_specify { static bool checked[MAPLE_PORTS]; static bool empty[MAPLE_PORTS]; static struct maple_device *baseunits[MAPLE_PORTS]; +static const struct bus_type maple_bus_type; /** * maple_driver_register - register a maple driver @@ -773,11 +774,10 @@ static struct maple_driver maple_unsupported_device = { /* * maple_bus_type - core maple bus structure */ -struct bus_type maple_bus_type = { +static const struct bus_type maple_bus_type = { .name = "maple", .match = maple_match_bus_driver, }; -EXPORT_SYMBOL_GPL(maple_bus_type); static struct device maple_bus = { .init_name = "maple", diff --git a/include/linux/maple.h b/include/linux/maple.h index 9b140272ee16..9aae44efcfd4 100644 --- a/include/linux/maple.h +++ b/include/linux/maple.h @@ -5,7 +5,6 @@ #include <mach/maple.h> struct device; -extern struct bus_type maple_bus_type; /* Maple Bus command and response codes */ enum maple_code {
This is a note to let you know that I've just added the patch titled maple: make maple_bus_type static and const to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the char-misc-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From e76933a9bfa9b7f28a387f2e13cb3e689adc200d Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Date: Tue, 19 Dec 2023 15:06:19 +0100 Subject: maple: make maple_bus_type static and const There is no need to export maple_bus_type as no one uses it outside of maple.c, so make it static, AND make it const as it can be read-only as no one modifies it. Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: <linux-sh@vger.kernel.org> Link: https://lore.kernel.org/r/2023121918-rejoicing-frostlike-d976@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/sh/maple/maple.c | 4 ++-- include/linux/maple.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-)