diff mbox

[2/2] sb_edac: Claim a different PCI device

Message ID 59f55d679cc596731589516a71075b6059fcaaa5.1408051536.git.luto@amacapital.net (mailing list archive)
State New, archived
Delegated to: Bjorn Helgaas
Headers show

Commit Message

Andy Lutomirski Aug. 14, 2014, 9:45 p.m. UTC
sb_edac controls a large number of different PCI functions.  Rather
than registering as a normal PCI driver for all of them, it
registers for just one so that it gets probed and, at probe time, it
looks for all the others.

Coincidentally, the device it registers for also contains the SMBUS
registers, so the PCI core will refuse to probe both sb_edac and a
future iMC SMBUS driver.  The drivers don't actually conflict, so
just change sb_edac's device table to probe a different device.

An alternative fix would be to merge the two drivers, but sb_edac
will also refuse to load on non-ECC systems, whereas i2c_imc would
still be useful without ECC.

The only user-visible change should be that sb_edac appears to bind
a different device.

Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Rui Wang <ruiv.wang@gmail.com>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 drivers/edac/sb_edac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Aristeu Rozanski Sept. 8, 2014, 2:10 p.m. UTC | #1
On Thu, Aug 14, 2014 at 02:45:41PM -0700, Andy Lutomirski wrote:
> sb_edac controls a large number of different PCI functions.  Rather
> than registering as a normal PCI driver for all of them, it
> registers for just one so that it gets probed and, at probe time, it
> looks for all the others.
> 
> Coincidentally, the device it registers for also contains the SMBUS
> registers, so the PCI core will refuse to probe both sb_edac and a
> future iMC SMBUS driver.  The drivers don't actually conflict, so
> just change sb_edac's device table to probe a different device.
> 
> An alternative fix would be to merge the two drivers, but sb_edac
> will also refuse to load on non-ECC systems, whereas i2c_imc would
> still be useful without ECC.
> 
> The only user-visible change should be that sb_edac appears to bind
> a different device.
> 
> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: Rui Wang <ruiv.wang@gmail.com>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>  drivers/edac/sb_edac.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index a2597e9313c6..e3bc2cced580 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -432,7 +432,7 @@ static const struct pci_id_table pci_dev_descr_ibridge_table[] = {
>   *	pci_device_id	table for which devices we are looking for
>   */
>  static const struct pci_device_id sbridge_pci_tbl[] = {
> -	{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA)},
> +	{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0)},
>  	{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA)},
>  	{0,}			/* 0 terminated list. */
>  };

Acked-by: Aristeu Rozanski <aris@redhat.com>
Andy Lutomirski Sept. 8, 2014, 9:49 p.m. UTC | #2
On Mon, Sep 8, 2014 at 7:10 AM, Aristeu Rozanski <aris@redhat.com> wrote:
> On Thu, Aug 14, 2014 at 02:45:41PM -0700, Andy Lutomirski wrote:
>> sb_edac controls a large number of different PCI functions.  Rather
>> than registering as a normal PCI driver for all of them, it
>> registers for just one so that it gets probed and, at probe time, it
>> looks for all the others.
>>
>> Coincidentally, the device it registers for also contains the SMBUS
>> registers, so the PCI core will refuse to probe both sb_edac and a
>> future iMC SMBUS driver.  The drivers don't actually conflict, so
>> just change sb_edac's device table to probe a different device.
>>
>> An alternative fix would be to merge the two drivers, but sb_edac
>> will also refuse to load on non-ECC systems, whereas i2c_imc would
>> still be useful without ECC.
>>
>> The only user-visible change should be that sb_edac appears to bind
>> a different device.
>>
>> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
>> Cc: Rui Wang <ruiv.wang@gmail.com>
>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>> ---
>>  drivers/edac/sb_edac.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
>> index a2597e9313c6..e3bc2cced580 100644
>> --- a/drivers/edac/sb_edac.c
>> +++ b/drivers/edac/sb_edac.c
>> @@ -432,7 +432,7 @@ static const struct pci_id_table pci_dev_descr_ibridge_table[] = {
>>   *   pci_device_id   table for which devices we are looking for
>>   */
>>  static const struct pci_device_id sbridge_pci_tbl[] = {
>> -     {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA)},
>> +     {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0)},
>>       {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA)},
>>       {0,}                    /* 0 terminated list. */
>>  };
>
> Acked-by: Aristeu Rozanski <aris@redhat.com>
>

Whose tree will this go through?

FWIW, this git am can't apply this to 3.17-rc4, but git am --3way can,
and it's a one-liner in any case.  Should I send a trivially rebased
version?

--Andy

> --
> Aristeu
>
Greg KH Sept. 8, 2014, 11:41 p.m. UTC | #3
On Mon, Sep 08, 2014 at 02:49:59PM -0700, Andy Lutomirski wrote:
> On Mon, Sep 8, 2014 at 7:10 AM, Aristeu Rozanski <aris@redhat.com> wrote:
> > On Thu, Aug 14, 2014 at 02:45:41PM -0700, Andy Lutomirski wrote:
> >> sb_edac controls a large number of different PCI functions.  Rather
> >> than registering as a normal PCI driver for all of them, it
> >> registers for just one so that it gets probed and, at probe time, it
> >> looks for all the others.
> >>
> >> Coincidentally, the device it registers for also contains the SMBUS
> >> registers, so the PCI core will refuse to probe both sb_edac and a
> >> future iMC SMBUS driver.  The drivers don't actually conflict, so
> >> just change sb_edac's device table to probe a different device.
> >>
> >> An alternative fix would be to merge the two drivers, but sb_edac
> >> will also refuse to load on non-ECC systems, whereas i2c_imc would
> >> still be useful without ECC.
> >>
> >> The only user-visible change should be that sb_edac appears to bind
> >> a different device.
> >>
> >> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
> >> Cc: Rui Wang <ruiv.wang@gmail.com>
> >> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> >> ---
> >>  drivers/edac/sb_edac.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> >> index a2597e9313c6..e3bc2cced580 100644
> >> --- a/drivers/edac/sb_edac.c
> >> +++ b/drivers/edac/sb_edac.c
> >> @@ -432,7 +432,7 @@ static const struct pci_id_table pci_dev_descr_ibridge_table[] = {
> >>   *   pci_device_id   table for which devices we are looking for
> >>   */
> >>  static const struct pci_device_id sbridge_pci_tbl[] = {
> >> -     {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA)},
> >> +     {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0)},
> >>       {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA)},
> >>       {0,}                    /* 0 terminated list. */
> >>  };
> >
> > Acked-by: Aristeu Rozanski <aris@redhat.com>
> >
> 
> Whose tree will this go through?

Mauro should have a tree for this as he's the subsystem maintainer.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mauro Carvalho Chehab Sept. 9, 2014, 9:25 a.m. UTC | #4
Em Mon, 08 Sep 2014 16:41:31 -0700
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:

> On Mon, Sep 08, 2014 at 02:49:59PM -0700, Andy Lutomirski wrote:
> > On Mon, Sep 8, 2014 at 7:10 AM, Aristeu Rozanski <aris@redhat.com> wrote:
> > > On Thu, Aug 14, 2014 at 02:45:41PM -0700, Andy Lutomirski wrote:
> > >> sb_edac controls a large number of different PCI functions.  Rather
> > >> than registering as a normal PCI driver for all of them, it
> > >> registers for just one so that it gets probed and, at probe time, it
> > >> looks for all the others.
> > >>
> > >> Coincidentally, the device it registers for also contains the SMBUS
> > >> registers, so the PCI core will refuse to probe both sb_edac and a
> > >> future iMC SMBUS driver.  The drivers don't actually conflict, so
> > >> just change sb_edac's device table to probe a different device.
> > >>
> > >> An alternative fix would be to merge the two drivers, but sb_edac
> > >> will also refuse to load on non-ECC systems, whereas i2c_imc would
> > >> still be useful without ECC.
> > >>
> > >> The only user-visible change should be that sb_edac appears to bind
> > >> a different device.
> > >>
> > >> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
> > >> Cc: Rui Wang <ruiv.wang@gmail.com>
> > >> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> > >> ---
> > >>  drivers/edac/sb_edac.c | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> > >> index a2597e9313c6..e3bc2cced580 100644
> > >> --- a/drivers/edac/sb_edac.c
> > >> +++ b/drivers/edac/sb_edac.c
> > >> @@ -432,7 +432,7 @@ static const struct pci_id_table pci_dev_descr_ibridge_table[] = {
> > >>   *   pci_device_id   table for which devices we are looking for
> > >>   */
> > >>  static const struct pci_device_id sbridge_pci_tbl[] = {
> > >> -     {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA)},
> > >> +     {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0)},
> > >>       {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA)},
> > >>       {0,}                    /* 0 terminated list. */
> > >>  };
> > >
> > > Acked-by: Aristeu Rozanski <aris@redhat.com>
> > >
> > 
> > Whose tree will this go through?
> 
> Mauro should have a tree for this as he's the subsystem maintainer.

Yes, I'll handle it.

> > FWIW, this git am can't apply this to 3.17-rc4, but git am --3way can,
> > and it's a one-liner in any case.  Should I send a trivially rebased
> > version?

No need. I'll fix any merge conflicts that might arise.

Regards.
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index a2597e9313c6..e3bc2cced580 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -432,7 +432,7 @@  static const struct pci_id_table pci_dev_descr_ibridge_table[] = {
  *	pci_device_id	table for which devices we are looking for
  */
 static const struct pci_device_id sbridge_pci_tbl[] = {
-	{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA)},
+	{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0)},
 	{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA)},
 	{0,}			/* 0 terminated list. */
 };