Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2021-12-28 at 10:35 -0600, Bjorn Helgaas wrote:
> On Tue, Dec 28, 2021 at 04:25:25PM +0100, Niklas Schnelle wrote:
> > On Mon, 2021-12-27 at 16:33 -0600, Bjorn Helgaas wrote:
> > > On Mon, Dec 27, 2021 at 05:43:13PM +0100, Niklas Schnelle wrote:
> > > If we keep it in drivers/pci, please update the subject line to make
> > > it more specific and match the convention, e.g.,
> > > 
> > >   PCI: Compile quirk_tigerpoint_bm_sts() only when HAS_IOPORT set
> > 
> > Ah yeah I was going back and forth between matching this within the
> > series vs matching the subsystem. I guess going with the subsystem is
> > mote important long term.
> 
> Haha, yes, a little ambiguity there.  I do think the subsystem is more
> important because the identity of the series is mostly lost after it's
> applied.  Thanks for thinking about it!
> 
> > > BTW, git complains about some whitespace errors in other patches:
> > > 
> > >   Applying: char: impi, tpm: depend on HAS_IOPORT
> > >   .git/rebase-apply/patch:92: trailing whitespace.
> > > 	    If you have a TPM security chip from Atmel say Yes and it
> > >   .git/rebase-apply/patch:93: trailing whitespace.
> > > 	    will be accessible from within Linux.  To compile this driver
> > >   warning: 2 lines add whitespace errors.
> > >   Applying: video: handle HAS_IOPORT dependencies
> > >   .git/rebase-apply/patch:23: trailing whitespace.
> > > 
> > >   warning: 1 line adds whitespace errors.
> > 
> > That is very strange. I did run checkpatch before. There are a few
> > warnings not to touch obsolete code unnecessarily and a check about
> > using udelay() (pre-existing) plus two missing blank lines in pci-
> > quirks.h that I ignored because it matches the sorounding style.
> > 
> > I did notice that lore fails to render the subject lines for some of
> > the patches. But I just tried fetching the patches with b4 on top of
> > v5.16-rc7 and the resulting tree passes "./scripts/checkpatch.pl --git
> > v5.16-rc7..HEAD" and has an empty diff to my branch. What tool did you
> > use to check?
> 
> "git am" is what complained.  Here's what I did:
> 
>   $ git checkout -b wip/niklas v5.16-rc1

Ah this seems to be because my patches are against v5.16-rc7. I noted
that in the cover letter but I guess that is easy to miss and might not
match expectations.

>   Switched to a new branch 'wip/niklas'
>   10:30:06 ~/linux (wip/niklas)$ b4 am -om/ 20211227164317.4146918-1-schnelle@xxxxxxxxxxxxx
>   Looking up https://lore.kernel.org/r/20211227164317.4146918-1-schnelle%40linux.ibm.com
>   Grabbing thread from lore.kernel.org/all/20211227164317.4146918-1-schnelle%40linux.ibm.com/t.mbox.gz
>   Analyzing 70 messages in the thread
>   Checking attestation on all messages, may take a moment...
>   ---
>     ✓ [PATCH RFC 1/32] Kconfig: introduce and depend on LEGACY_PCI
>     ✓ [PATCH RFC 2/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
>     ✓ [PATCH RFC 3/32] ACPI: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 4/32] parport: PC style parport depends on HAS_IOPORT
>     ✓ [PATCH RFC 5/32] char: impi, tpm: depend on HAS_IOPORT
>     ✓ [PATCH RFC 6/32] speakup: Kconfig: add HAS_IOPORT dependencies
>       + Reviewed-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
>     ✓ [PATCH RFC 7/32] Input: gameport: add ISA and HAS_IOPORT dependencies
>     ✓ [PATCH RFC 8/32] comedi: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 9/32] sound: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 11/32] Input: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 13/32] hwmon: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 14/32] leds: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 15/32] media: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 16/32] misc: handle HAS_IOPORT dependencies
>     ✓ [PATCH RFC 17/32] net: Kconfig: add HAS_IOPORT dependencies
>       + Acked-by: Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx>
>     ✓ [PATCH RFC 18/32] pcmcia: Kconfig: add HAS_IOPORT dependencies
>       + Acked-by: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
>     ✓ [PATCH RFC 19/32] platform: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 20/32] pnp: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 21/32] power: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 22/32] video: handle HAS_IOPORT dependencies
>     ✓ [PATCH RFC 23/32] rtc: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 24/32] scsi: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
>     ✓ [PATCH RFC 26/32] drm: handle HAS_IOPORT dependencies
>     ✓ [PATCH RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT
>     ✓ [PATCH RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
>     ✓ [PATCH RFC 29/32] firmware: dmi-sysfs: handle HAS_IOPORT dependencies
>     ✓ [PATCH RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
>     ✓ [PATCH RFC 31/32] usb: handle HAS_IOPORT dependencies
>     ✓ [PATCH RFC 32/32] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
>     ---
>     ✓ Signed: DKIM/ibm.com (From: schnelle@xxxxxxxxxxxxx)
> 

Interesting now I have to figure out why I do get bad DKIM signature
checks with b4 and my mails. Maybe b4 has an endianess bug as I'm
usually working on mainframe.




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux