[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <005d01d812c8$0ea9ae30$2bfd0a90$@opensource.cirrus.com>
Date: Wed, 26 Jan 2022 15:19:05 +0000
From: Stefan Binding <sbinding@...nsource.cirrus.com>
To: "'Rafael J. Wysocki'" <rafael@...nel.org>
CC: 'Platform Driver' <platform-driver-x86@...r.kernel.org>,
"'moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...'"
<alsa-devel@...a-project.org>,
'ACPI Devel Maling List' <linux-acpi@...r.kernel.org>,
'Linux Kernel Mailing List' <linux-kernel@...r.kernel.org>,
'Takashi Iwai' <tiwai@...e.com>,
'Mark Gross' <markgross@...nel.org>,
'Hans de Goede' <hdegoede@...hat.com>,
'Mark Brown' <broonie@...nel.org>,
<patches@...nsource.cirrus.com>,
'linux-spi' <linux-spi@...r.kernel.org>,
'Len Brown' <lenb@...nel.org>
Subject: RE: [PATCH v5 7/9] platform/x86: serial-multi-instantiate: Add SPI support
> -----Original Message-----
> From: Alsa-devel <alsa-devel-bounces@...a-project.org> On Behalf Of
> Rafael J. Wysocki
> Sent: 21 January 2022 17:15
> To: Stefan Binding <sbinding@...nsource.cirrus.com>
> Cc: Platform Driver <platform-driver-x86@...r.kernel.org>; moderated
> list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM... <alsa-
> devel@...a-project.org>; ACPI Devel Maling List <linux-
> acpi@...r.kernel.org>; Rafael J. Wysocki <rafael@...nel.org>; Linux Kernel
> Mailing List <linux-kernel@...r.kernel.org>; Takashi Iwai <tiwai@...e.com>;
> Mark Gross <markgross@...nel.org>; Hans de Goede
> <hdegoede@...hat.com>; Mark Brown <broonie@...nel.org>;
> patches@...nsource.cirrus.com; linux-spi <linux-spi@...r.kernel.org>; Len
> Brown <lenb@...nel.org>
> Subject: Re: [PATCH v5 7/9] platform/x86: serial-multi-instantiate: Add SPI
> support
>
> > > > @@ -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.
I added a default case here purely for static analysis reasons. I don’t think it necessarily required, and I can remove it if necessary.
Thanks,
Stefan
Powered by blists - more mailing lists