[1/3] pinctrl: mcp23s08: fix debugfs entry for mcp23s18 device
diff mbox series

Message ID 20180925145616.12610-2-m.felsch@pengutronix.de
State New
Headers show
Series
  • Fixes for mcp23s08
Related show

Commit Message

Marco Felsch Sept. 25, 2018, 2:56 p.m. UTC
This patch fixes 'commit 9b3e4207661e ("pinctrl: mcp23s08: spi: Fix regmap
debugfs entries")'. For sure the MCP23S18 device has only 1 address pin
but this will get decoded into three internally ([1], section 1.4).

[1] http://ww1.microchip.com/downloads/en/DeviceDoc/22103a.pdf

Cc: stable@vger.kernel.org
Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
Fixes: 9b3e4207661e ('pinctrl: mcp23s08: spi: Fix regmap debugfs entries')
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
 drivers/pinctrl/pinctrl-mcp23s08.c | 49 ++++++++++++++----------------
 1 file changed, 23 insertions(+), 26 deletions(-)

Comments

Phil Reid Sept. 25, 2018, 11:55 p.m. UTC | #1
G'day Marco,

On 25/09/2018 10:56 PM, Marco Felsch wrote:
> This patch fixes 'commit 9b3e4207661e ("pinctrl: mcp23s08: spi: Fix regmap
> debugfs entries")'. For sure the MCP23S18 device has only 1 address pin
> but this will get decoded into three internally ([1], section 1.4).
> 
> [1] http://ww1.microchip.com/downloads/en/DeviceDoc/22103a.pdf

The MCP23018 (i2c) has an address pin that's decoded to 8 addresses.
The spi MCP23s18 does not from what I can see.

reference:
TABLE 1-2: SPI PINOUT DESCRIPTION (MCP23S18)

and

> 1.4 Multi-bit Address Decoder
> The ADDR pin is used to set the slave address of the
> MCP23018 (I2C only) to allow up to eight devices on
> the bus using only a

So I think the original code is correct.


> 
> Cc: stable@vger.kernel.org
> Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
> Fixes: 9b3e4207661e ('pinctrl: mcp23s08: spi: Fix regmap debugfs entries')
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
>   drivers/pinctrl/pinctrl-mcp23s08.c | 49 ++++++++++++++----------------
>   1 file changed, 23 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-mcp23s08.c b/drivers/pinctrl/pinctrl-mcp23s08.c
> index 4a8a8efadefa..472746931ea8 100644
> --- a/drivers/pinctrl/pinctrl-mcp23s08.c
> +++ b/drivers/pinctrl/pinctrl-mcp23s08.c
> @@ -794,41 +794,38 @@ static int mcp23s08_probe_one(struct mcp23s08 *mcp, struct device *dev,
>   	switch (type) {
>   #ifdef CONFIG_SPI_MASTER
>   	case MCP_TYPE_S08:
> -	case MCP_TYPE_S17:
> -		switch (type) {
> -		case MCP_TYPE_S08:
> -			one_regmap_config =
> -				devm_kmemdup(dev, &mcp23x08_regmap,
> -					sizeof(struct regmap_config), GFP_KERNEL);
> -			mcp->reg_shift = 0;
> -			mcp->chip.ngpio = 8;
> -			mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL,
> -					"mcp23s08.%d", raw_chip_address);
> -			break;
> -		case MCP_TYPE_S17:
> -			one_regmap_config =
> -				devm_kmemdup(dev, &mcp23x17_regmap,
> -					sizeof(struct regmap_config), GFP_KERNEL);
> -			mcp->reg_shift = 1;
> -			mcp->chip.ngpio = 16;
> -			mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL,
> -					"mcp23s17.%d", raw_chip_address);
> -			break;
> -		}
> +		one_regmap_config = devm_kmemdup(dev, &mcp23x08_regmap,
> +						 sizeof(struct regmap_config),
> +						 GFP_KERNEL);
>   		if (!one_regmap_config)
>   			return -ENOMEM;
>   
> -		one_regmap_config->name = devm_kasprintf(dev, GFP_KERNEL, "%d", raw_chip_address);
> +		mcp->reg_shift = 0;
> +		mcp->chip.ngpio = 8;
> +		mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL, "mcp23s08.%d",
> +						 raw_chip_address);
> +		one_regmap_config->name = devm_kasprintf(dev, GFP_KERNEL, "%d",
> +							 raw_chip_address);
>   		mcp->regmap = devm_regmap_init(dev, &mcp23sxx_spi_regmap, mcp,
>   					       one_regmap_config);
>   		break;
> -
> +	case MCP_TYPE_S17:
>   	case MCP_TYPE_S18:
> -		mcp->regmap = devm_regmap_init(dev, &mcp23sxx_spi_regmap, mcp,
> -					       &mcp23x17_regmap);
> +		one_regmap_config = devm_kmemdup(dev, &mcp23x17_regmap,
> +						 sizeof(struct regmap_config),
> +						 GFP_KERNEL);
> +		if (!one_regmap_config)
> +			return -ENOMEM;
> +
>   		mcp->reg_shift = 1;
>   		mcp->chip.ngpio = 16;
> -		mcp->chip.label = "mcp23s18";
> +		mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL, "mcp23s%s.%d",
> +						 type == MCP_TYPE_S17 ?
> +						 "17" : "18", raw_chip_address);
> +		one_regmap_config->name = devm_kasprintf(dev, GFP_KERNEL, "%d",
> +							 raw_chip_address);
> +		mcp->regmap = devm_regmap_init(dev, &mcp23sxx_spi_regmap, mcp,
> +					       one_regmap_config);
>   		break;
>   #endif /* CONFIG_SPI_MASTER */
>   
>
Jan Kundrát Sept. 26, 2018, 7:39 a.m. UTC | #2
On úterý 25. září 2018 16:56:14 CEST, Marco Felsch wrote:
> This patch fixes 'commit 9b3e4207661e ("pinctrl: mcp23s08: spi: Fix regmap
> debugfs entries")'. For sure the MCP23S18 device has only 1 address pin
> but this will get decoded into three internally ([1], section 1.4).
>
> [1] http://ww1.microchip.com/downloads/en/DeviceDoc/22103a.pdf

Hi Marco, Section 1.4 only applies to I2C devices. Quoting the first 
paragraph:

> The ADDR pin is used to set the slave address of the MCP23018 (I2C only) 
> to allow up to eight devices on the bus using only a single pin. 
> Typically, this would require three pins.

Here's my summary of how it works among the whole family of these chips:

- MCP23O18 is an I2C device. Its address selection is a bit unusual, but it 
can still provide 8 different addresses. In Linux, these are separate I2C 
clients as usual.

- MCP23S18, on the other hand, is an SPI device. It does not support any 
extra addressing apart from the SPI CS pin (see page 13 of the datasheet 
you linked to). As far as I can tell, it's always just one device on a 
given SPI CS signal.

- MCP23S17 is also a SPI device, but it supports a creative/hacky 
"addressing" scheme where up to eight devices can share the same SPI CS 
signal. On Linux, this opens an ugly can of warms with several "gpiochip" 
instances within the same SPI client, but that's not relevant in the 
context of this patch.

I know that the current code works with MCP23S17 -- we have a board with 
two chips with a shared SPI CS, but a different "address" prefix. Looking 
at the datasheet, MCP23S18 works in a different manner. I therefore don't 
think that this patch which effectively unifies handling of both ...S18 and 
...S17 is correct.

Can you please clarify what doesn't work for you, and how it should work? 
Did my patch 9b3e4207661e broke something?

With kind regards,
Jan
Marco Felsch Sept. 26, 2018, 9:42 a.m. UTC | #3
On 18-09-26 07:55, Phil Reid wrote:
> G'day Marco,
> 
> On 25/09/2018 10:56 PM, Marco Felsch wrote:
> > This patch fixes 'commit 9b3e4207661e ("pinctrl: mcp23s08: spi: Fix regmap
> > debugfs entries")'. For sure the MCP23S18 device has only 1 address pin
> > but this will get decoded into three internally ([1], section 1.4).
> > 
> > [1] http://ww1.microchip.com/downloads/en/DeviceDoc/22103a.pdf
> 
> The MCP23018 (i2c) has an address pin that's decoded to 8 addresses.
> The spi MCP23s18 does not from what I can see.
> 
> reference:
> TABLE 1-2: SPI PINOUT DESCRIPTION (MCP23S18)
> 
> and
> 
> > 1.4 Multi-bit Address Decoder
> > The ADDR pin is used to set the slave address of the
> > MCP23018 (I2C only) to allow up to eight devices on
> > the bus using only a
> 
> So I think the original code is correct.

Sorry, mixed up different RM and the commit message isn't correct too,
shame on me.

The patch should be smaller and should not do more than one at the same
time: fixing and uniform the code. Sorry for that.

Without the patch this would ever be true, since one_regmap_config is
initialised to NULL gets only modified in case of S08/S17.

...

case MCP_TYPE_S18:
	if (!one_regmap_config)
		return -ENOMEM;

...

This was the fixing part. The other one is to uniform the handling and
the debugfs entries.

Kind regards,
Marco

> 
> 
> > 
> > Cc: stable@vger.kernel.org
> > Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
> > Fixes: 9b3e4207661e ('pinctrl: mcp23s08: spi: Fix regmap debugfs entries')
> > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > ---
> >   drivers/pinctrl/pinctrl-mcp23s08.c | 49 ++++++++++++++----------------
> >   1 file changed, 23 insertions(+), 26 deletions(-)
> > 
> > diff --git a/drivers/pinctrl/pinctrl-mcp23s08.c b/drivers/pinctrl/pinctrl-mcp23s08.c
> > index 4a8a8efadefa..472746931ea8 100644
> > --- a/drivers/pinctrl/pinctrl-mcp23s08.c
> > +++ b/drivers/pinctrl/pinctrl-mcp23s08.c
> > @@ -794,41 +794,38 @@ static int mcp23s08_probe_one(struct mcp23s08 *mcp, struct device *dev,
> >   	switch (type) {
> >   #ifdef CONFIG_SPI_MASTER
> >   	case MCP_TYPE_S08:
> > -	case MCP_TYPE_S17:
> > -		switch (type) {
> > -		case MCP_TYPE_S08:
> > -			one_regmap_config =
> > -				devm_kmemdup(dev, &mcp23x08_regmap,
> > -					sizeof(struct regmap_config), GFP_KERNEL);
> > -			mcp->reg_shift = 0;
> > -			mcp->chip.ngpio = 8;
> > -			mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL,
> > -					"mcp23s08.%d", raw_chip_address);
> > -			break;
> > -		case MCP_TYPE_S17:
> > -			one_regmap_config =
> > -				devm_kmemdup(dev, &mcp23x17_regmap,
> > -					sizeof(struct regmap_config), GFP_KERNEL);
> > -			mcp->reg_shift = 1;
> > -			mcp->chip.ngpio = 16;
> > -			mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL,
> > -					"mcp23s17.%d", raw_chip_address);
> > -			break;
> > -		}
> > +		one_regmap_config = devm_kmemdup(dev, &mcp23x08_regmap,
> > +						 sizeof(struct regmap_config),
> > +						 GFP_KERNEL);
> >   		if (!one_regmap_config)
> >   			return -ENOMEM;
> > -		one_regmap_config->name = devm_kasprintf(dev, GFP_KERNEL, "%d", raw_chip_address);
> > +		mcp->reg_shift = 0;
> > +		mcp->chip.ngpio = 8;
> > +		mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL, "mcp23s08.%d",
> > +						 raw_chip_address);
> > +		one_regmap_config->name = devm_kasprintf(dev, GFP_KERNEL, "%d",
> > +							 raw_chip_address);
> >   		mcp->regmap = devm_regmap_init(dev, &mcp23sxx_spi_regmap, mcp,
> >   					       one_regmap_config);
> >   		break;
> > -
> > +	case MCP_TYPE_S17:
> >   	case MCP_TYPE_S18:
> > -		mcp->regmap = devm_regmap_init(dev, &mcp23sxx_spi_regmap, mcp,
> > -					       &mcp23x17_regmap);
> > +		one_regmap_config = devm_kmemdup(dev, &mcp23x17_regmap,
> > +						 sizeof(struct regmap_config),
> > +						 GFP_KERNEL);
> > +		if (!one_regmap_config)
> > +			return -ENOMEM;
> > +
> >   		mcp->reg_shift = 1;
> >   		mcp->chip.ngpio = 16;
> > -		mcp->chip.label = "mcp23s18";
> > +		mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL, "mcp23s%s.%d",
> > +						 type == MCP_TYPE_S17 ?
> > +						 "17" : "18", raw_chip_address);
> > +		one_regmap_config->name = devm_kasprintf(dev, GFP_KERNEL, "%d",
> > +							 raw_chip_address);
> > +		mcp->regmap = devm_regmap_init(dev, &mcp23sxx_spi_regmap, mcp,
> > +					       one_regmap_config);
> >   		break;
> >   #endif /* CONFIG_SPI_MASTER */
> > 
> 
> 
> -- 
> Regards
> Phil Reid
> 
>
Marco Felsch Sept. 26, 2018, 9:51 a.m. UTC | #4
On 18-09-26 09:39, Jan Kundrát wrote:
> On úterý 25. září 2018 16:56:14 CEST, Marco Felsch wrote:
> > This patch fixes 'commit 9b3e4207661e ("pinctrl: mcp23s08: spi: Fix regmap
> > debugfs entries")'. For sure the MCP23S18 device has only 1 address pin
> > but this will get decoded into three internally ([1], section 1.4).
> > 
> > [1] http://ww1.microchip.com/downloads/en/DeviceDoc/22103a.pdf
> 
> Hi Marco, Section 1.4 only applies to I2C devices. Quoting the first
> paragraph:
> 
> > The ADDR pin is used to set the slave address of the MCP23018 (I2C only)
> > to allow up to eight devices on the bus using only a single pin.
> > Typically, this would require three pins.

Hi Jan,

sorry I mixed up different versions of the MCP RMs.

> 
> Here's my summary of how it works among the whole family of these chips:
> 
> - MCP23O18 is an I2C device. Its address selection is a bit unusual, but it
> can still provide 8 different addresses. In Linux, these are separate I2C
> clients as usual.
> 
> - MCP23S18, on the other hand, is an SPI device. It does not support any
> extra addressing apart from the SPI CS pin (see page 13 of the datasheet you
> linked to). As far as I can tell, it's always just one device on a given SPI
> CS signal.
> 
> - MCP23S17 is also a SPI device, but it supports a creative/hacky
> "addressing" scheme where up to eight devices can share the same SPI CS
> signal. On Linux, this opens an ugly can of warms with several "gpiochip"
> instances within the same SPI client, but that's not relevant in the context
> of this patch.
> 
> I know that the current code works with MCP23S17 -- we have a board with two
> chips with a shared SPI CS, but a different "address" prefix. Looking at the
> datasheet, MCP23S18 works in a different manner. I therefore don't think
> that this patch which effectively unifies handling of both ...S18 and ...S17
> is correct.
> 
> Can you please clarify what doesn't work for you, and how it should work?
> Did my patch 9b3e4207661e broke something?

Sorry as I mentioned to Phil I mixed up different things: fixing and
uniforming. The fixing patch should only remove this:

8<---

case MCP_TYPE_S18:
-	if (!one_regmap_config)
-		return -ENOMEM;

8<---

Or is there a corner point I didn't saw?

Kind Regards,
Marco

> 
> With kind regards,
> Jan
>
Phil Reid Sept. 27, 2018, 1:45 a.m. UTC | #5
On 26/09/2018 5:42 PM, Marco Felsch wrote:
> On 18-09-26 07:55, Phil Reid wrote:
>> G'day Marco,
>>
>> On 25/09/2018 10:56 PM, Marco Felsch wrote:
>>> This patch fixes 'commit 9b3e4207661e ("pinctrl: mcp23s08: spi: Fix regmap
>>> debugfs entries")'. For sure the MCP23S18 device has only 1 address pin
>>> but this will get decoded into three internally ([1], section 1.4).
>>>
>>> [1]http://ww1.microchip.com/downloads/en/DeviceDoc/22103a.pdf
>> The MCP23018 (i2c) has an address pin that's decoded to 8 addresses.
>> The spi MCP23s18 does not from what I can see.
>>
>> reference:
>> TABLE 1-2: SPI PINOUT DESCRIPTION (MCP23S18)
>>
>> and
>>
>>> 1.4 Multi-bit Address Decoder
>>> The ADDR pin is used to set the slave address of the
>>> MCP23018 (I2C only) to allow up to eight devices on
>>> the bus using only a
>> So I think the original code is correct.
> Sorry, mixed up different RM and the commit message isn't correct too,
> shame on me.
> 
> The patch should be smaller and should not do more than one at the same
> time: fixing and uniform the code. Sorry for that.
> 
> Without the patch this would ever be true, since one_regmap_config is
> initialised to NULL gets only modified in case of S08/S17.
> 
> ...
> 
> case MCP_TYPE_S18:
> 	if (!one_regmap_config)
> 		return -ENOMEM;
> 
> ...
> 
> This was the fixing part. The other one is to uniform the handling and
> the debugfs entries.
G'day Marco,

Sorry I still don't follow.
I've got a mcp23s18 in one of my systems and debugfs seems to work fine.

one_regmap_config is only used for the S08/S17 to fiddle with the name / label
Marco Felsch Sept. 27, 2018, 8:55 a.m. UTC | #6
Hi Phil,

On 18-09-27 09:45, Phil Reid wrote:
> On 26/09/2018 5:42 PM, Marco Felsch wrote:
> > On 18-09-26 07:55, Phil Reid wrote:
> > > G'day Marco,
> > > 
> > > On 25/09/2018 10:56 PM, Marco Felsch wrote:
> > > > This patch fixes 'commit 9b3e4207661e ("pinctrl: mcp23s08: spi: Fix regmap
> > > > debugfs entries")'. For sure the MCP23S18 device has only 1 address pin
> > > > but this will get decoded into three internally ([1], section 1.4).
> > > > 
> > > > [1]http://ww1.microchip.com/downloads/en/DeviceDoc/22103a.pdf
> > > The MCP23018 (i2c) has an address pin that's decoded to 8 addresses.
> > > The spi MCP23s18 does not from what I can see.
> > > 
> > > reference:
> > > TABLE 1-2: SPI PINOUT DESCRIPTION (MCP23S18)
> > > 
> > > and
> > > 
> > > > 1.4 Multi-bit Address Decoder
> > > > The ADDR pin is used to set the slave address of the
> > > > MCP23018 (I2C only) to allow up to eight devices on
> > > > the bus using only a
> > > So I think the original code is correct.
> > Sorry, mixed up different RM and the commit message isn't correct too,
> > shame on me.
> > 
> > The patch should be smaller and should not do more than one at the same
> > time: fixing and uniform the code. Sorry for that.
> > 
> > Without the patch this would ever be true, since one_regmap_config is
> > initialised to NULL gets only modified in case of S08/S17.
> > 
> > ...
> > 
> > case MCP_TYPE_S18:
> > 	if (!one_regmap_config)
> > 		return -ENOMEM;
> > 
> > ...
> > 
> > This was the fixing part. The other one is to uniform the handling and
> > the debugfs entries.
> G'day Marco,
> 
> Sorry I still don't follow.
> I've got a mcp23s18 in one of my systems and debugfs seems to work fine.
> 
> one_regmap_config is only used for the S08/S17 to fiddle with the name / label

I know, but if I read the code correctly it shouldn't work, because in
your case one_regmap_config is never modified, as you told. But it is
initialized to NULL. This confuses me a bit.

This tested should not be made for the MCP_TYPE_S18 case.

Kind regards,
Marco

> 
> 
> 
> -- 
> Regards
> Phil Reid
> 
> ElectroMagnetic Imaging Technology Pty Ltd
> Development of Geophysical Instrumentation & Software
> www.electromag.com.au
> 
> 3 The Avenue, Midland WA 6056, AUSTRALIA
> Ph: +61 8 9250 8100
> Fax: +61 8 9250 7100
> Email: preid@electromag.com.au
>
Jan Kundrát Sept. 27, 2018, 10:54 a.m. UTC | #7
On čtvrtek 27. září 2018 10:55:11 CEST, Marco Felsch wrote:
> Hi Phil,
>
> On 18-09-27 09:45, Phil Reid wrote:
>> On 26/09/2018 5:42 PM, Marco Felsch wrote:
>>> On 18-09-26 07:55, Phil Reid wrote: ...
>> G'day Marco,
>> 
>> Sorry I still don't follow.
>> I've got a mcp23s18 in one of my systems and debugfs seems to work fine.
>> 
>> one_regmap_config is only used for the S08/S17 to fiddle with 
>> the name / label
>
> I know, but if I read the code correctly it shouldn't work, because in
> your case one_regmap_config is never modified, as you told. But it is
> initialized to NULL. This confuses me a bit.
>
> This tested should not be made for the MCP_TYPE_S18 case.

Ah, right. This means that the stable tree(s) need this follow-up patch 
from February, too:

  https://patchwork.ozlabs.org/patch/875045/

Thanks for catching this.

With kind regards,
Jan
Marco Felsch Sept. 27, 2018, 12:31 p.m. UTC | #8
On 18-09-27 12:54, Jan Kundrát wrote:
> On čtvrtek 27. září 2018 10:55:11 CEST, Marco Felsch wrote:
> > Hi Phil,
> > 
> > On 18-09-27 09:45, Phil Reid wrote:
> > > On 26/09/2018 5:42 PM, Marco Felsch wrote:
> > > > On 18-09-26 07:55, Phil Reid wrote: ...
> > > G'day Marco,
> > > 
> > > Sorry I still don't follow.
> > > I've got a mcp23s18 in one of my systems and debugfs seems to work fine.
> > > 
> > > one_regmap_config is only used for the S08/S17 to fiddle with the
> > > name / label
> > 
> > I know, but if I read the code correctly it shouldn't work, because in
> > your case one_regmap_config is never modified, as you told. But it is
> > initialized to NULL. This confuses me a bit.
> > 
> > This tested should not be made for the MCP_TYPE_S18 case.

Hi Jan,

> 
> Ah, right. This means that the stable tree(s) need this follow-up patch from
> February, too:
> 
>  https://patchwork.ozlabs.org/patch/875045/
> 
> Thanks for catching this.

Okay, so we can drop this patch too. Can you give me some feedback for
patch "pinctrl: mcp23s08: fix irq and irqchip setup order"?

Kind regards,
Marco

> 
> With kind regards,
> Jan
> 
>
Phil Reid Sept. 27, 2018, 12:32 p.m. UTC | #9
On 27/09/2018 6:54 PM, Jan Kundrát wrote:
> On čtvrtek 27. září 2018 10:55:11 CEST, Marco Felsch wrote:
>> Hi Phil,
>>
>> On 18-09-27 09:45, Phil Reid wrote:
>>> On 26/09/2018 5:42 PM, Marco Felsch wrote:
>>>> On 18-09-26 07:55, Phil Reid wrote: ...
>>> G'day Marco,
>>>
>>> Sorry I still don't follow.
>>> I've got a mcp23s18 in one of my systems and debugfs seems to work fine.
>>>
>>> one_regmap_config is only used for the S08/S17 to fiddle with the name / label
>>
>> I know, but if I read the code correctly it shouldn't work, because in
>> your case one_regmap_config is never modified, as you told. But it is
>> initialized to NULL. This confuses me a bit.
>>
>> This tested should not be made for the MCP_TYPE_S18 case.
> 
> Ah, right. This means that the stable tree(s) need this follow-up patch from February, too:
> 
>   https://patchwork.ozlabs.org/patch/875045/
> 
> Thanks for catching this.
> 
I'd forgotten about that patch.
Jan Kundrát Sept. 27, 2018, 12:45 p.m. UTC | #10
On čtvrtek 27. září 2018 14:31:31 CEST, Marco Felsch wrote:
> Can you give me some feedback for
> patch "pinctrl: mcp23s08: fix irq and irqchip setup order"?

I don't understand kernel's IRQ subsystem, so I cannot review correctness 
of that one, sorry.

Do you want me to test it (just the default path, I cannot easily trigger 
the error-handling one)?

Cheers,
Jan

Patch
diff mbox series

diff --git a/drivers/pinctrl/pinctrl-mcp23s08.c b/drivers/pinctrl/pinctrl-mcp23s08.c
index 4a8a8efadefa..472746931ea8 100644
--- a/drivers/pinctrl/pinctrl-mcp23s08.c
+++ b/drivers/pinctrl/pinctrl-mcp23s08.c
@@ -794,41 +794,38 @@  static int mcp23s08_probe_one(struct mcp23s08 *mcp, struct device *dev,
 	switch (type) {
 #ifdef CONFIG_SPI_MASTER
 	case MCP_TYPE_S08:
-	case MCP_TYPE_S17:
-		switch (type) {
-		case MCP_TYPE_S08:
-			one_regmap_config =
-				devm_kmemdup(dev, &mcp23x08_regmap,
-					sizeof(struct regmap_config), GFP_KERNEL);
-			mcp->reg_shift = 0;
-			mcp->chip.ngpio = 8;
-			mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL,
-					"mcp23s08.%d", raw_chip_address);
-			break;
-		case MCP_TYPE_S17:
-			one_regmap_config =
-				devm_kmemdup(dev, &mcp23x17_regmap,
-					sizeof(struct regmap_config), GFP_KERNEL);
-			mcp->reg_shift = 1;
-			mcp->chip.ngpio = 16;
-			mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL,
-					"mcp23s17.%d", raw_chip_address);
-			break;
-		}
+		one_regmap_config = devm_kmemdup(dev, &mcp23x08_regmap,
+						 sizeof(struct regmap_config),
+						 GFP_KERNEL);
 		if (!one_regmap_config)
 			return -ENOMEM;
 
-		one_regmap_config->name = devm_kasprintf(dev, GFP_KERNEL, "%d", raw_chip_address);
+		mcp->reg_shift = 0;
+		mcp->chip.ngpio = 8;
+		mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL, "mcp23s08.%d",
+						 raw_chip_address);
+		one_regmap_config->name = devm_kasprintf(dev, GFP_KERNEL, "%d",
+							 raw_chip_address);
 		mcp->regmap = devm_regmap_init(dev, &mcp23sxx_spi_regmap, mcp,
 					       one_regmap_config);
 		break;
-
+	case MCP_TYPE_S17:
 	case MCP_TYPE_S18:
-		mcp->regmap = devm_regmap_init(dev, &mcp23sxx_spi_regmap, mcp,
-					       &mcp23x17_regmap);
+		one_regmap_config = devm_kmemdup(dev, &mcp23x17_regmap,
+						 sizeof(struct regmap_config),
+						 GFP_KERNEL);
+		if (!one_regmap_config)
+			return -ENOMEM;
+
 		mcp->reg_shift = 1;
 		mcp->chip.ngpio = 16;
-		mcp->chip.label = "mcp23s18";
+		mcp->chip.label = devm_kasprintf(dev, GFP_KERNEL, "mcp23s%s.%d",
+						 type == MCP_TYPE_S17 ?
+						 "17" : "18", raw_chip_address);
+		one_regmap_config->name = devm_kasprintf(dev, GFP_KERNEL, "%d",
+							 raw_chip_address);
+		mcp->regmap = devm_regmap_init(dev, &mcp23sxx_spi_regmap, mcp,
+					       one_regmap_config);
 		break;
 #endif /* CONFIG_SPI_MASTER */