Re: [PATCH] serial: max310x: add comments for membase address workaround

[Hugo Villeneuve]

On Mon, 7 Aug 2023 17:27:38 +0200
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:

> On Mon, Aug 07, 2023 at 11:24:41AM -0400, Hugo Villeneuve wrote:
> > On Fri, 4 Aug 2023 10:17:22 -0400
> > Hugo Villeneuve <hugo@xxxxxxxxxxx> wrote:
> > 
> > > On Fri, 4 Aug 2023 15:07:50 +0200
> > > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > 
> > > > On Thu, Aug 03, 2023 at 10:05:51AM -0400, Hugo Villeneuve wrote:
> > > > > From: Hugo Villeneuve <hvilleneuve@xxxxxxxxxxxx>
> > > > > 
> > > > > Add comments about workaround used to configure membase address. This
> > > > > follows suggestions made during review of a sc16is7xx driver patch to
> > > > > add the same workaround.
> > > > > 
> > > > > Link: https://lore.kernel.org/lkml/2936e18f-44ea-faed-9fa0-2ddefe7c3194@xxxxxxxxxxxxxxx
> > > > > Link: https://lore.kernel.org/lkml/20230801131655.80bd8f97f018dda6155d65f6@xxxxxxxxxxx/
> > > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@xxxxxxxxxxxx>
> > > > > ---
> > > > >  drivers/tty/serial/max310x.c | 5 +++++
> > > > >  1 file changed, 5 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
> > > > > index 416d553b73a7..5903dd033fd0 100644
> > > > > --- a/drivers/tty/serial/max310x.c
> > > > > +++ b/drivers/tty/serial/max310x.c
> > > > > @@ -1369,6 +1369,11 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
> > > > >  		s->p[i].port.flags	= UPF_FIXED_TYPE | UPF_LOW_LATENCY;
> > > > >  		s->p[i].port.iotype	= UPIO_PORT;
> > > > >  		s->p[i].port.iobase	= i;
> > > > > +		/*
> > > > > +		 * Use all ones as membase to make sure uart_configure_port() in
> > > > > +		 * serial_core.c does not abort for SPI/I2C devices where the
> > > > > +		 * membase address is not applicable.
> > > > > +		 */
> > > > >  		s->p[i].port.membase	= (void __iomem *)~0;
> > > > >  		s->p[i].port.uartclk	= uartclk;
> > > > >  		s->p[i].port.rs485_config = max310x_rs485_config;
> > > > > 
> > > > > base-commit: 426263d5fb400ccde5444748693dc75bda18f01e
> > > > > -- 
> > > > > 2.30.2
> > > > > 
> > > > 
> > > > Meta-comment, your email system is not correct and is not able to be
> > > > verified as I get the following when attempting to apply your patch:
> > > > 
> > > > ---
> > > >   ✗ [PATCH] serial: max310x: add comments for membase address workaround
> > > >   ---
> > > >   ✗ BADSIG: DKIM/hugovil.com
> > > > 
> > > > Please fix up for future submissions.
> > > > 
> > > > thanks,
> > > > 
> > > > greg k-h
> > > 
> > > Hi Greg,
> > > I will look into it. Thank you.
> > 
> > Hi Greg,
> > I double-checked my DKIM setup, but everything looks fine. If I send
> > emails to gmail or outlook servers, they both report "DKIM
> > signature=pass", and I also checked with an online DKIM validation
> > service and it is also ok.
> > 
> > What tool are you using to check the DKIM signature?
> 
> The patatt tool as part of `b4`.  I just checked, your direct email to
> me here passes, BUT the message you sent to the mailing list did not.
> Check it out yourself, look at the message on lore.kernel.org for this
> response and see if that passes the DKIM check or not.

Hi Greg,
if I look on lore.kernel.org for this response, here it is:

    https://lore.kernel.org/all/2023080738-headcount-jigsaw-efb7@gregkh/raw

If I save this raw message and run it thru patatt, I get:

$ patatt validate test-lore.kernel.mail
 NOSIG | Re: [PATCH] serial: max310x: add comments for membase address
 workaround
       | no signatures found

But if I use another tool, dkimverify (from dkimpy), then it works ok:

$ dkimverify < test-lore.kernel.mail 
signature ok

and if I check the original patch:

    https://lore.kernel.org/all/20230803140551.970141-1-hugo@xxxxxxxxxxx/raw

I also get a similar failure like you did:

$ dkimverify < test-lore.kernel-original-patch.mail
signature verification failed

The only difference between the two is that the original patch was sent
using 'git send-email'. But in the end, both messages passed thru the
same server (my mail server) running Exim4 v4.92 on a Debian box.

I found that by modifying my Exim configuration and adding the
following (simpler configuration) seems to solve the problem with 'git
send-email' and DKIM:

---------------
DKIM_SIGN_HEADERS =
content-transfer-encoding:mime-version:message-id:date:subject:to:from:cc:subject:date:message-id:reply-to
---------------

I am not an expert in Exim, and I am not sure this is the most
elegant solution, but hope this can help others...

Thank you,
Hugo.