On Fri, Jan 21, 2022 at 5:55 PM Stefan Binding <sbinding@xxxxxxxxxxxxxxxxxxxxx> wrote: > > Hi, > > > -----Original Message----- > > From: Rafael J. Wysocki <rafael@xxxxxxxxxx> > > Sent: 21 January 2022 15:31 > > To: Stefan Binding <sbinding@xxxxxxxxxxxxxxxxxxxxx> > > Cc: Mark Brown <broonie@xxxxxxxxxx>; Rafael J . Wysocki > > <rafael@xxxxxxxxxx>; Len Brown <lenb@xxxxxxxxxx>; Hans de Goede > > <hdegoede@xxxxxxxxxx>; Mark Gross <markgross@xxxxxxxxxx>; Jaroslav > > Kysela <perex@xxxxxxxx>; Takashi Iwai <tiwai@xxxxxxxx>; moderated > > list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM... <alsa- > > devel@xxxxxxxxxxxxxxxx>; Linux Kernel Mailing List <linux- > > kernel@xxxxxxxxxxxxxxx>; linux-spi <linux-spi@xxxxxxxxxxxxxxx>; ACPI Devel > > Maling List <linux-acpi@xxxxxxxxxxxxxxx>; Platform Driver <platform-driver- > > x86@xxxxxxxxxxxxxxx>; patches@xxxxxxxxxxxxxxxxxxxxx > > Subject: Re: [PATCH v5 7/9] platform/x86: serial-multi-instantiate: Add SPI > > support > > > > > > > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig > > > index 5b65d687f046..28f5bbf0f27a 100644 > > > --- a/drivers/platform/x86/Kconfig > > > +++ b/drivers/platform/x86/Kconfig > > > @@ -991,12 +991,12 @@ config TOPSTAR_LAPTOP > > > If you have a Topstar laptop, say Y or M here. > > > > > > config SERIAL_MULTI_INSTANTIATE > > > - tristate "I2C multi instantiate pseudo device driver" > > > - depends on I2C && ACPI > > > + tristate "I2C and SPI multi instantiate pseudo device driver" > > > + depends on I2C && SPI && ACPI > > > > Should this be (I2C || SPI) && ACPI ? > > We made it dependent on both I2C and SPI because of how interconnected the > serial-multi-instantiate driver is with both SPI and I2C. We felt attempting to make > the driver compatible with one without the other would end up very complicated. That's fine IMV, but it would be good to mention it in the changelog. > > > @@ -146,7 +247,21 @@ static int smi_probe(struct platform_device *pdev) > > > > > > platform_set_drvdata(pdev, smi); > > > > > > - return smi_i2c_probe(pdev, adev, smi, inst_array); > > > + switch (node->bus_type) { > > > + case SMI_I2C: > > > + return smi_i2c_probe(pdev, adev, smi, node->instances); > > > + case SMI_SPI: > > > + return smi_spi_probe(pdev, adev, smi, node->instances); > > > + case SMI_AUTO_DETECT: > > > + if (i2c_acpi_client_count(adev) > 0) > > > + return smi_i2c_probe(pdev, adev, smi, node->instances); > > > + else > > > + return smi_spi_probe(pdev, adev, smi, node->instances); > > > + default: > > > + break; > > > > Why is this needed? > > This return code is attempting to ensure that we don’t try to guess whether we > expect devices to be I2C or SPI - especially with regards to existing devices. > We wanted to maintain compatibility with existing devices, which would all be > I2C. > For the device for which we are adding, the same HID is used by both the same > chip for both I2C and SPI, so we also needed a way to support both. I meant why was the "default" case needed. Sorry for the confusion.