linux-kernel - Re: [PATCH v2 1/7] tty: 8250: Fix IS-200 PCI ID comment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2023101411-disarray-olive-afc3@gregkh>
Date:   Sat, 14 Oct 2023 20:28:59 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Cameron Williams <cang1@...e.co.uk>
Cc:     jirislaby@...nel.org, linux-kernel@...r.kernel.org,
        linux-serial@...r.kernel.org
Subject: Re: [PATCH v2 1/7] tty: 8250: Fix IS-200 PCI ID comment

On Sat, Oct 14, 2023 at 12:56:31PM +0100, Cameron Williams wrote:
> On Sat, Oct 14, 2023 at 10:28:33AM +0200, Greg KH wrote:
> > On Fri, Oct 13, 2023 at 11:11:09PM +0100, Cameron Williams wrote:
> > > Fix the PCI comment for the IS-200 card
> > 
> > "Fix" it how?  What was wrong with it, and what is now right with it?
> >
> I should have specified better, my mistake. The PCI ID comment (135a.0811)
> is incorrect, the card ID itself is 0x0d80 and the definition used
> (PCI_DEVICE_ID_INTASHIELD_IS200) is indeed 0x0d80. It's just a cosmetic change
> as the rest of the IS range of cards are also being added in this series and their
> IDs are all 0x0020 offset from each other (though the IS-300, 0x0da0 is in a
> parport_serial patch). Makes no functional difference.

Please put that info in the changelog text when you send your next
version.

> > > Signed-off-by: Cameron Williams <cang1@...e.co.uk>
> > > ---
> > > This is a resubmission series for the patch series below. That series
> > > was lots of changes sent to lots of maintainers, this series is just for
> > > the tty/serial/8250 subsystem.
> > 
> > Your patches here are not threaded at all, was that intentional?  Our
> > tools will not pick them up properly, and so I would have to do it by
> > hand, slowing things down and making me dread handling them.  Any reason
> > you didn't just use 'git send-email' to send it?
> > 
> This was not intentional, no. I had problems getting git send-email set up,
> somthing to do with TLS issues and since Mutt was already set up for general
> email, I chose to use that instead for convenience. I can look into getting
> git send-email working and re-sending this series as v3 if you want the
> series threading properly.

You can use mutt to thread things, you need to do it "by hand" with
mutt, that's what I used to do all the time before git send-email was
created (it's based on some old scripts of mine.)  But I would recommend
setting up git send-email if you want to send lots of patches over time.

thanks,

greg k-h