drivers/tty/serial/8250/8250_pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
The PCI_VDEVICE macro assigns 0 to .class and .class_mask to allow the
next value in the initializer to define the value for .driver_data.
So the construct
{
PCI_VDEVICE(INTASHIELD, 0x0D21),
.class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
.class_mask = 0xffff00,
.driver_data = pbn_b2_4_115200,
},
introduced in commit 44e55f1f3088 ("serial: 8250_pci: Consistently
define pci_device_ids using named initializers") has conflicting
assignments. In only some configurations (i.e. W=1 for me) that makes
the compiler unhappy.
So convert the two affected items to PCI_DEVICE which doesn't have that
hidden assigment to .class and .class_mask.
Fixes: 44e55f1f3088 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers")
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/tty/serial/8250/8250_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 3e5bc9e8d269..58b4e525bdb6 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -5394,12 +5394,12 @@ static const struct pci_device_id serial_pci_tbl[] = {
* Brainboxes UC-260/271/701/756
*/
{
- PCI_VDEVICE(INTASHIELD, 0x0D21),
+ PCI_DEVICE(PCI_VENDOR_ID_INTASHIELD, 0x0D21),
.class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
.class_mask = 0xffff00,
.driver_data = pbn_b2_4_115200,
}, {
- PCI_VDEVICE(INTASHIELD, 0x0E34),
+ PCI_DEVICE(PCI_VENDOR_ID_INTASHIELD, 0x0E34),
.class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
.class_mask = 0xffff00,
.driver_data = pbn_b2_4_115200,
base-commit: 44e55f1f3088e4a471a943fbcf087ea7783a0199
--
2.47.3
On Wed, Jun 03, 2026 at 11:56:16AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> The PCI_VDEVICE macro assigns 0 to .class and .class_mask to allow the
> next value in the initializer to define the value for .driver_data.
>
> So the construct
>
> {
> PCI_VDEVICE(INTASHIELD, 0x0D21),
> .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
> .class_mask = 0xffff00,
> .driver_data = pbn_b2_4_115200,
> },
>
> introduced in commit 44e55f1f3088 ("serial: 8250_pci: Consistently
> define pci_device_ids using named initializers") has conflicting
> assignments. In only some configurations (i.e. W=1 for me) that makes
> the compiler unhappy.
>
> So convert the two affected items to PCI_DEVICE which doesn't have that
> hidden assigment to .class and .class_mask.
Reported-by? Closes?
> Fixes: 44e55f1f3088 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers")
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
I will test it right away.
--
With Best Regards,
Andy Shevchenko
On Wed, Jun 03, 2026 at 01:45:37PM +0300, Andy Shevchenko wrote:
> On Wed, Jun 03, 2026 at 11:56:16AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > The PCI_VDEVICE macro assigns 0 to .class and .class_mask to allow the
> > next value in the initializer to define the value for .driver_data.
> >
> > So the construct
> >
> > {
> > PCI_VDEVICE(INTASHIELD, 0x0D21),
> > .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
> > .class_mask = 0xffff00,
> > .driver_data = pbn_b2_4_115200,
> > },
> >
> > introduced in commit 44e55f1f3088 ("serial: 8250_pci: Consistently
> > define pci_device_ids using named initializers") has conflicting
> > assignments. In only some configurations (i.e. W=1 for me) that makes
> > the compiler unhappy.
> >
> > So convert the two affected items to PCI_DEVICE which doesn't have that
> > hidden assigment to .class and .class_mask.
>
> Reported-by? Closes?
>
> > Fixes: 44e55f1f3088 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers")
> > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
>
> I will test it right away.
Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Closes: https://lore.kernel.org/linux-serial/ah_5qVKOf8LXG1Xo@ashevche-desk.local/T/#ma6eab90ca801b4292639f5c255a89b4033b33d21
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
Hello Andy,
On Wed, Jun 03, 2026 at 01:51:51PM +0300, Andy Shevchenko wrote:
> On Wed, Jun 03, 2026 at 01:45:37PM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 03, 2026 at 11:56:16AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > The PCI_VDEVICE macro assigns 0 to .class and .class_mask to allow the
> > > next value in the initializer to define the value for .driver_data.
> > >
> > > So the construct
> > >
> > > {
> > > PCI_VDEVICE(INTASHIELD, 0x0D21),
> > > .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
> > > .class_mask = 0xffff00,
> > > .driver_data = pbn_b2_4_115200,
> > > },
> > >
> > > introduced in commit 44e55f1f3088 ("serial: 8250_pci: Consistently
> > > define pci_device_ids using named initializers") has conflicting
> > > assignments. In only some configurations (i.e. W=1 for me) that makes
> > > the compiler unhappy.
> > >
> > > So convert the two affected items to PCI_DEVICE which doesn't have that
> > > hidden assigment to .class and .class_mask.
> >
> > Reported-by? Closes?
> >
> > > Fixes: 44e55f1f3088 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers")
> > > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> >
> > I will test it right away.
>
> Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Closes: https://lore.kernel.org/linux-serial/ah_5qVKOf8LXG1Xo@ashevche-desk.local/T/#ma6eab90ca801b4292639f5c255a89b4033b33d21
> Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Thanks for the quick confirmation and also for providing the footers
that I should have added already.
Uwe
© 2016 - 2026 Red Hat, Inc.