| Message ID | 20221222063950.26018-1-joewu@msi.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | cros_ec_keyb: Add 3 buttons for monitor function | expand |
On Thu, Dec 22, 2022 at 02:39:50PM +0800, Joe Wu wrote: > Add 3 extra buttons: 'brightness up', 'brightness down' > and 'screen lock' to support monitor manipulating function. > > Signed-off-by: Joe Wu <joewu@msi.com> > --- > > drivers/input/keyboard/cros_ec_keyb.c | 15 +++++++++++++++ > include/linux/platform_data/cros_ec_commands.h | 3 +++ > 2 files changed, 18 insertions(+) > > diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c > index 6f435125ec03..e7ecfca838df 100644 > --- a/drivers/input/keyboard/cros_ec_keyb.c > +++ b/drivers/input/keyboard/cros_ec_keyb.c > @@ -100,6 +100,21 @@ static const struct cros_ec_bs_map cros_ec_keyb_bs[] = { > .code = KEY_VOLUMEDOWN, > .bit = EC_MKBP_VOL_DOWN, > }, > + { > + .ev_type = EV_KEY, > + .code = KEY_BRIGHTNESSUP, > + .bit = EC_MKBP_BRI_UP, > + }, > + { > + .ev_type = EV_KEY, > + .code = KEY_BRIGHTNESSDOWN, > + .bit = EC_MKBP_BRI_DOWN, > + }, > + { > + .ev_type = EV_KEY, > + .code = KEY_SCREENLOCK, > + .bit = EC_MKBP_SCREEN_LOCK, > + }, > > /* Switches */ > { > diff --git a/include/linux/platform_data/cros_ec_commands.h b/include/linux/platform_data/cros_ec_commands.h > index 5744a2d746aa..a2073ed43972 100644 > --- a/include/linux/platform_data/cros_ec_commands.h > +++ b/include/linux/platform_data/cros_ec_commands.h > @@ -3471,6 +3471,9 @@ struct ec_response_get_next_event_v1 { > #define EC_MKBP_VOL_UP 1 > #define EC_MKBP_VOL_DOWN 2 > #define EC_MKBP_RECOVERY 3 > +#define EC_MKBP_BRI_UP 4 > +#define EC_MKBP_BRI_DOWN 5 > +#define EC_MKBP_SCREEN_LOCK 6 > > /* Switches */ > #define EC_MKBP_LID_OPEN 0 > -- > 2.17.1 > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - It looks like you did not use your "real" name for the patch on either the Signed-off-by: line, or the From: line (both of which have to match). Please read the kernel file, Documentation/process/submitting-patches.rst for how to do this correctly. - This looks like a new version of a previously submitted patch, but you did not list below the --- line any changes from the previous version. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/process/submitting-patches.rst for what needs to be done here to properly describe this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
On Thu, Dec 22, 2022 at 02:39:50PM +0800, Joe Wu wrote: > Add 3 extra buttons: 'brightness up', 'brightness down' > and 'screen lock' to support monitor manipulating function. > > Signed-off-by: Joe Wu <joewu@msi.com> From: line does not match the signed-off-by (and is an invalid email address...) Please fix. thanks, greg k-h
On Fri, Jan 20, 2023 at 12:26:04PM +0100, Greg Kroah-Hartman wrote: > On Thu, Dec 22, 2022 at 02:39:50PM +0800, Joe Wu wrote: > > Add 3 extra buttons: 'brightness up', 'brightness down' > > and 'screen lock' to support monitor manipulating function. > > > > Signed-off-by: Joe Wu <joewu@msi.com> > > From: line does not match the signed-off-by (and is an invalid email > address...) What do you mean "it's an invalid email address"? You can definitely send emails there... I prefer people not to use Google partner domain accounts in the hope that their employment might outlast their involvement in Google projects, but that is it. I think if we ask people to stick "From: <whatever the company address is" in the body of the patch we can ignore the difference between sender address and from/signed-off-by when they use partner domain accounts. If anything, such accounts have better vetting than a random gmail or other free email service account some vendors have to create to be able to send a plain-text emails that we require. I mean, we have "Signed-off-by: George Spelvin <lkml@sdf.org>" present in our git history and nobody bats an eye... Thanks.
On Fri, Jan 20, 2023 at 09:24:18AM -0800, Dmitry Torokhov wrote: > On Fri, Jan 20, 2023 at 12:26:04PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Dec 22, 2022 at 02:39:50PM +0800, Joe Wu wrote: > > > Add 3 extra buttons: 'brightness up', 'brightness down' > > > and 'screen lock' to support monitor manipulating function. > > > > > > Signed-off-by: Joe Wu <joewu@msi.com> > > > > From: line does not match the signed-off-by (and is an invalid email > > address...) > > What do you mean "it's an invalid email address"? You can definitely > send emails there... I prefer people not to use Google partner domain > accounts in the hope that their employment might outlast their > involvement in Google projects, but that is it. I was told that this was not a valid email address to send and receive emails from, and was only an email alias given to companies to interact with Google through their gerrit systems. If that is incorrect, I'll not complain about this anymore, but someone needs to please verify this for me before I do so :) But even if it is valid, should we accept it as a way to get in contact with the original submitter over time? > I think if we ask people to stick "From: <whatever the company address > is" in the body of the patch we can ignore the difference between sender > address and from/signed-off-by when they use partner domain accounts. If > anything, such accounts have better vetting than a random gmail or other > free email service account some vendors have to create to be able to > send a plain-text emails that we require. I mean, we have > "Signed-off-by: George Spelvin <lkml@sdf.org>" present in our git > history and nobody bats an eye... Oh lots of people "batted an eye" about that one, I've had too many meetings with lawyers about that, which is one reason I now verify email addresses like I did here. thanks, greg k-h
On Sat, Jan 21, 2023 at 08:26:47AM +0100, Greg Kroah-Hartman wrote: > On Fri, Jan 20, 2023 at 09:24:18AM -0800, Dmitry Torokhov wrote: > > On Fri, Jan 20, 2023 at 12:26:04PM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Dec 22, 2022 at 02:39:50PM +0800, Joe Wu wrote: > > > > Add 3 extra buttons: 'brightness up', 'brightness down' > > > > and 'screen lock' to support monitor manipulating function. > > > > > > > > Signed-off-by: Joe Wu <joewu@msi.com> > > > > > > From: line does not match the signed-off-by (and is an invalid email > > > address...) > > > > What do you mean "it's an invalid email address"? You can definitely > > send emails there... I prefer people not to use Google partner domain > > accounts in the hope that their employment might outlast their > > involvement in Google projects, but that is it. > > I was told that this was not a valid email address to send and receive > emails from, and was only an email alias given to companies to interact > with Google through their gerrit systems. If that is incorrect, I'll > not complain about this anymore, but someone needs to please verify this > for me before I do so :) Not solely for gerrit, there are other systems at Google (for example the issue tracker) that require Google account and that is why we create them for partners. It is however a real account that can send and receive e-mails. Whether anyone is looking at it, especially after they moved to other projects, is a separate topic, but it is the same with a random gmail or whatever account that people are creating to submit a patch or two. > > But even if it is valid, should we accept it as a way to get in contact > with the original submitter over time? I believe that a real corp account is preferable for getting in contact with the engineer who submitted the patch. Unfortunately corp accounts often unsuitable for submitting patches to the kernel. Outgoing mail servers either force HTML, mangle the text, or add legal-sounding footers that result in snark replies. So submitters often try to use another account to submit the code, such us a throwaway gmail account, or as in this case, our "partner domain" account. Neither is ideal but we require from to match sign-off (including email part) and complain about sane option of overriding "from" in the mail body to be something more sensitive, like the email that is actually used by the person in question. Again, I have more trust for patches sent as "Joe Wu <joewu@msi.corp-partner.google.com>" with body From: Joe Wu <joewu@msi.com> ... Signed-off-by: Joe Wu <joewu@msi.com> ... then patches sent and signed off as "Joe Wu <joemsi-oss@gmail.com>" because I actually know that there is a process for establishing and managing that @msi.corp-partner.google.com. > > > I think if we ask people to stick "From: <whatever the company address > > is" in the body of the patch we can ignore the difference between sender > > address and from/signed-off-by when they use partner domain accounts. If > > anything, such accounts have better vetting than a random gmail or other > > free email service account some vendors have to create to be able to > > send a plain-text emails that we require. I mean, we have > > "Signed-off-by: George Spelvin <lkml@sdf.org>" present in our git > > history and nobody bats an eye... > > Oh lots of people "batted an eye" about that one, I've had too many > meetings with lawyers about that, which is one reason I now verify email > addresses like I did here. Would you attempt to verify it is you saw a sign-off from "Daniil Kharms <dank@gmail.com>"? What is the trigger for verification? How rigorous is it? Thanks.
diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c index 6f435125ec03..e7ecfca838df 100644 --- a/drivers/input/keyboard/cros_ec_keyb.c +++ b/drivers/input/keyboard/cros_ec_keyb.c @@ -100,6 +100,21 @@ static const struct cros_ec_bs_map cros_ec_keyb_bs[] = { .code = KEY_VOLUMEDOWN, .bit = EC_MKBP_VOL_DOWN, }, + { + .ev_type = EV_KEY, + .code = KEY_BRIGHTNESSUP, + .bit = EC_MKBP_BRI_UP, + }, + { + .ev_type = EV_KEY, + .code = KEY_BRIGHTNESSDOWN, + .bit = EC_MKBP_BRI_DOWN, + }, + { + .ev_type = EV_KEY, + .code = KEY_SCREENLOCK, + .bit = EC_MKBP_SCREEN_LOCK, + }, /* Switches */ { diff --git a/include/linux/platform_data/cros_ec_commands.h b/include/linux/platform_data/cros_ec_commands.h index 5744a2d746aa..a2073ed43972 100644 --- a/include/linux/platform_data/cros_ec_commands.h +++ b/include/linux/platform_data/cros_ec_commands.h @@ -3471,6 +3471,9 @@ struct ec_response_get_next_event_v1 { #define EC_MKBP_VOL_UP 1 #define EC_MKBP_VOL_DOWN 2 #define EC_MKBP_RECOVERY 3 +#define EC_MKBP_BRI_UP 4 +#define EC_MKBP_BRI_DOWN 5 +#define EC_MKBP_SCREEN_LOCK 6 /* Switches */ #define EC_MKBP_LID_OPEN 0
Add 3 extra buttons: 'brightness up', 'brightness down' and 'screen lock' to support monitor manipulating function. Signed-off-by: Joe Wu <joewu@msi.com> --- drivers/input/keyboard/cros_ec_keyb.c | 15 +++++++++++++++ include/linux/platform_data/cros_ec_commands.h | 3 +++ 2 files changed, 18 insertions(+)