Message ID | 4096fa4ceae72817d8e64d9a1da738038a5c864a.1425890926.git.michal.simek@xilinx.com |
---|---|
State | Awaiting Upstream, archived |
Delegated to: | David Miller |
Headers | show |
On 03/09/2015 09:48 AM, Michal Simek wrote: > Remove Kconfig dependency and enable driver for > all ARCHs. > > Signed-off-by: Michal Simek <michal.simek@xilinx.com> > Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com> > --- > > Test for all archs done by Kbuild test robot without any problem. > --- > drivers/net/can/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig > index 98d73aab52fe..f690c3fb3088 100644 > --- a/drivers/net/can/Kconfig > +++ b/drivers/net/can/Kconfig > @@ -131,7 +131,6 @@ config CAN_RCAR > > config CAN_XILINXCAN > tristate "Xilinx CAN" > - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST I think that's what COMPILE_TEST ist for? Marc
On 03/09/2015 09:50 AM, Marc Kleine-Budde wrote: > On 03/09/2015 09:48 AM, Michal Simek wrote: >> Remove Kconfig dependency and enable driver for >> all ARCHs. >> >> Signed-off-by: Michal Simek <michal.simek@xilinx.com> >> Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com> >> --- >> >> Test for all archs done by Kbuild test robot without any problem. >> --- >> drivers/net/can/Kconfig | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig >> index 98d73aab52fe..f690c3fb3088 100644 >> --- a/drivers/net/can/Kconfig >> +++ b/drivers/net/can/Kconfig >> @@ -131,7 +131,6 @@ config CAN_RCAR >> >> config CAN_XILINXCAN >> tristate "Xilinx CAN" >> - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST > > I think that's what COMPILE_TEST ist for? For compilation yes but not for enabling. Currently this driver can be also used on ARM64 that's why people suggesting directly to remove dependency on arch and then COMPILE_TEST can be removed too. Or do you want me to change description to mention that this is for ARM64 enabling? Thanks, Michal
On 03/09/2015 09:58 AM, Michal Simek wrote: > On 03/09/2015 09:50 AM, Marc Kleine-Budde wrote: >> On 03/09/2015 09:48 AM, Michal Simek wrote: >>> Remove Kconfig dependency and enable driver for >>> all ARCHs. >>> >>> Signed-off-by: Michal Simek <michal.simek@xilinx.com> >>> Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com> >>> --- >>> >>> Test for all archs done by Kbuild test robot without any problem. >>> --- >>> drivers/net/can/Kconfig | 1 - >>> 1 file changed, 1 deletion(-) >>> >>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig >>> index 98d73aab52fe..f690c3fb3088 100644 >>> --- a/drivers/net/can/Kconfig >>> +++ b/drivers/net/can/Kconfig >>> @@ -131,7 +131,6 @@ config CAN_RCAR >>> >>> config CAN_XILINXCAN >>> tristate "Xilinx CAN" >>> - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST >> >> I think that's what COMPILE_TEST ist for? > > For compilation yes but not for enabling. Currently this driver > can be also used on ARM64 that's why people suggesting directly > to remove dependency on arch and then COMPILE_TEST can be removed > too. In the past (May 2014) I had people complaining that certain ARM SoC specific drivers are enabled on ARM in general, not just on that SoC. As I'm not following arm64 in detail, has the notion of using depends on ARCH changes since then? > Or do you want me to change description to mention that this is for > ARM64 enabling? Given this is consensus, a remark to ARM64 would be appreciated. :) Marc
On 03/09/2015 10:13 AM, Marc Kleine-Budde wrote: > On 03/09/2015 09:58 AM, Michal Simek wrote: >> On 03/09/2015 09:50 AM, Marc Kleine-Budde wrote: >>> On 03/09/2015 09:48 AM, Michal Simek wrote: >>>> Remove Kconfig dependency and enable driver for >>>> all ARCHs. >>>> >>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com> >>>> Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com> >>>> --- >>>> >>>> Test for all archs done by Kbuild test robot without any problem. >>>> --- >>>> drivers/net/can/Kconfig | 1 - >>>> 1 file changed, 1 deletion(-) >>>> >>>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig >>>> index 98d73aab52fe..f690c3fb3088 100644 >>>> --- a/drivers/net/can/Kconfig >>>> +++ b/drivers/net/can/Kconfig >>>> @@ -131,7 +131,6 @@ config CAN_RCAR >>>> >>>> config CAN_XILINXCAN >>>> tristate "Xilinx CAN" >>>> - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST >>> >>> I think that's what COMPILE_TEST ist for? >> >> For compilation yes but not for enabling. Currently this driver >> can be also used on ARM64 that's why people suggesting directly >> to remove dependency on arch and then COMPILE_TEST can be removed >> too. > > In the past (May 2014) I had people complaining that certain ARM SoC > specific drivers are enabled on ARM in general, not just on that SoC. As > I'm not following arm64 in detail, has the notion of using depends on > ARCH changes since then? > >> Or do you want me to change description to mention that this is for >> ARM64 enabling? > > Given this is consensus, a remark to ARM64 would be appreciated. :) David has applied this patch which is in general just the same as this one. (linux-next) Remove architecture dependency 28811a8c00fe0d899b8a544421f3b4947425d5e8 Mark Brown has suggested to do so for spi and don't check architecture at all. I have also sent similar patch for watchdog driver too. I think it is up to you if you want to add ARM64 to Kconfig or just remove that arch dependencies. To be honest my goal is to enable this driver for ARM64. Please tell me what way you prefer. Thanks, Michal
On 03/09/2015 10:52 AM, Michal Simek wrote: > On 03/09/2015 10:13 AM, Marc Kleine-Budde wrote: >> On 03/09/2015 09:58 AM, Michal Simek wrote: >>> On 03/09/2015 09:50 AM, Marc Kleine-Budde wrote: >>>> On 03/09/2015 09:48 AM, Michal Simek wrote: >>>>> Remove Kconfig dependency and enable driver for >>>>> all ARCHs. >>>>> >>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com> >>>>> Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com> >>>>> --- >>>>> >>>>> Test for all archs done by Kbuild test robot without any problem. >>>>> --- >>>>> drivers/net/can/Kconfig | 1 - >>>>> 1 file changed, 1 deletion(-) >>>>> >>>>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig >>>>> index 98d73aab52fe..f690c3fb3088 100644 >>>>> --- a/drivers/net/can/Kconfig >>>>> +++ b/drivers/net/can/Kconfig >>>>> @@ -131,7 +131,6 @@ config CAN_RCAR >>>>> >>>>> config CAN_XILINXCAN >>>>> tristate "Xilinx CAN" >>>>> - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST >>>> >>>> I think that's what COMPILE_TEST ist for? >>> >>> For compilation yes but not for enabling. Currently this driver >>> can be also used on ARM64 that's why people suggesting directly >>> to remove dependency on arch and then COMPILE_TEST can be removed >>> too. >> >> In the past (May 2014) I had people complaining that certain ARM SoC >> specific drivers are enabled on ARM in general, not just on that SoC. As >> I'm not following arm64 in detail, has the notion of using depends on >> ARCH changes since then? >> >>> Or do you want me to change description to mention that this is for >>> ARM64 enabling? >> >> Given this is consensus, a remark to ARM64 would be appreciated. :) > > David has applied this patch which is in general just the same as this one. > > (linux-next) Remove architecture dependency > 28811a8c00fe0d899b8a544421f3b4947425d5e8 > > Mark Brown has suggested to do so for spi and don't check architecture at > all. > I have also sent similar patch for watchdog driver too. > > I think it is up to you if you want to add ARM64 to Kconfig or just remove > that arch dependencies. > To be honest my goal is to enable this driver for ARM64. > Please tell me what way you prefer. I like the idea of removing the depends on ARCH completely. Jean, what do you think? regards, Marc
Le Monday 09 March 2015 à 10:56 +0100, Marc Kleine-Budde a écrit : > On 03/09/2015 10:52 AM, Michal Simek wrote: > > On 03/09/2015 10:13 AM, Marc Kleine-Budde wrote: > >> On 03/09/2015 09:58 AM, Michal Simek wrote: > >>> On 03/09/2015 09:50 AM, Marc Kleine-Budde wrote: > >>>> On 03/09/2015 09:48 AM, Michal Simek wrote: > >>>>> Remove Kconfig dependency and enable driver for > >>>>> all ARCHs. > >>>>> > >>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com> > >>>>> Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com> > >>>>> --- > >>>>> > >>>>> Test for all archs done by Kbuild test robot without any problem. > >>>>> --- > >>>>> drivers/net/can/Kconfig | 1 - > >>>>> 1 file changed, 1 deletion(-) > >>>>> > >>>>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig > >>>>> index 98d73aab52fe..f690c3fb3088 100644 > >>>>> --- a/drivers/net/can/Kconfig > >>>>> +++ b/drivers/net/can/Kconfig > >>>>> @@ -131,7 +131,6 @@ config CAN_RCAR > >>>>> > >>>>> config CAN_XILINXCAN > >>>>> tristate "Xilinx CAN" > >>>>> - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST > >>>> > >>>> I think that's what COMPILE_TEST ist for? > >>> > >>> For compilation yes but not for enabling. Currently this driver > >>> can be also used on ARM64 that's why people suggesting directly > >>> to remove dependency on arch and then COMPILE_TEST can be removed > >>> too. > >> > >> In the past (May 2014) I had people complaining that certain ARM SoC > >> specific drivers are enabled on ARM in general, not just on that SoC. As > >> I'm not following arm64 in detail, has the notion of using depends on > >> ARCH changes since then? > >> > >>> Or do you want me to change description to mention that this is for > >>> ARM64 enabling? > >> > >> Given this is consensus, a remark to ARM64 would be appreciated. :) > > > > David has applied this patch which is in general just the same as this one. > > > > (linux-next) Remove architecture dependency > > 28811a8c00fe0d899b8a544421f3b4947425d5e8 > > > > Mark Brown has suggested to do so for spi and don't check architecture at > > all. > > I have also sent similar patch for watchdog driver too. > > > > I think it is up to you if you want to add ARM64 to Kconfig or just remove > > that arch dependencies. > > To be honest my goal is to enable this driver for ARM64. > > Please tell me what way you prefer. > > I like the idea of removing the depends on ARCH completely. Jean, what > do you think? Removing the dependency completely will let the option be displayed on systems where the driver is useless. I am in favor of having hardware dependencies on as many drivers as possible to avoid bothering the user with irrelevant questions. The list of Kconfig entries has grown a lot over time! If the current dependency is too strict then I would suggest to extend it or to make it broader (depends on ARM || ARM64 || COMPILE_TEST would be acceptable IMHO.) Dropping it completely only makes sense if the part is used on so many systems that the dependency becomes too long or is a pain to maintain. Thanks,
On 03/09/2015 02:53 PM, Jean Delvare wrote: > Le Monday 09 March 2015 à 10:56 +0100, Marc Kleine-Budde a écrit : >> On 03/09/2015 10:52 AM, Michal Simek wrote: >>> On 03/09/2015 10:13 AM, Marc Kleine-Budde wrote: >>>> On 03/09/2015 09:58 AM, Michal Simek wrote: >>>>> On 03/09/2015 09:50 AM, Marc Kleine-Budde wrote: >>>>>> On 03/09/2015 09:48 AM, Michal Simek wrote: >>>>>>> Remove Kconfig dependency and enable driver for >>>>>>> all ARCHs. >>>>>>> >>>>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com> >>>>>>> Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com> >>>>>>> --- >>>>>>> >>>>>>> Test for all archs done by Kbuild test robot without any problem. >>>>>>> --- >>>>>>> drivers/net/can/Kconfig | 1 - >>>>>>> 1 file changed, 1 deletion(-) >>>>>>> >>>>>>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig >>>>>>> index 98d73aab52fe..f690c3fb3088 100644 >>>>>>> --- a/drivers/net/can/Kconfig >>>>>>> +++ b/drivers/net/can/Kconfig >>>>>>> @@ -131,7 +131,6 @@ config CAN_RCAR >>>>>>> >>>>>>> config CAN_XILINXCAN >>>>>>> tristate "Xilinx CAN" >>>>>>> - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST >>>>>> >>>>>> I think that's what COMPILE_TEST ist for? >>>>> >>>>> For compilation yes but not for enabling. Currently this driver >>>>> can be also used on ARM64 that's why people suggesting directly >>>>> to remove dependency on arch and then COMPILE_TEST can be removed >>>>> too. >>>> >>>> In the past (May 2014) I had people complaining that certain ARM SoC >>>> specific drivers are enabled on ARM in general, not just on that SoC. As >>>> I'm not following arm64 in detail, has the notion of using depends on >>>> ARCH changes since then? >>>> >>>>> Or do you want me to change description to mention that this is for >>>>> ARM64 enabling? >>>> >>>> Given this is consensus, a remark to ARM64 would be appreciated. :) >>> >>> David has applied this patch which is in general just the same as this one. >>> >>> (linux-next) Remove architecture dependency >>> 28811a8c00fe0d899b8a544421f3b4947425d5e8 >>> >>> Mark Brown has suggested to do so for spi and don't check architecture at >>> all. >>> I have also sent similar patch for watchdog driver too. >>> >>> I think it is up to you if you want to add ARM64 to Kconfig or just remove >>> that arch dependencies. >>> To be honest my goal is to enable this driver for ARM64. >>> Please tell me what way you prefer. >> >> I like the idea of removing the depends on ARCH completely. Jean, what >> do you think? > > Removing the dependency completely will let the option be displayed on > systems where the driver is useless. I am in favor of having hardware > dependencies on as many drivers as possible to avoid bothering the user > with irrelevant questions. The list of Kconfig entries has grown a lot > over time! > > If the current dependency is too strict then I would suggest to extend > it or to make it broader (depends on ARM || ARM64 || COMPILE_TEST would > be acceptable IMHO.) Dropping it completely only makes sense if the part > is used on so many systems that the dependency becomes too long or is a > pain to maintain. Sounds reasonable. Michael, make it so. Marc
On 03/09/2015 02:55 PM, Marc Kleine-Budde wrote: > On 03/09/2015 02:53 PM, Jean Delvare wrote: >> Le Monday 09 March 2015 à 10:56 +0100, Marc Kleine-Budde a écrit : >>> On 03/09/2015 10:52 AM, Michal Simek wrote: >>>> On 03/09/2015 10:13 AM, Marc Kleine-Budde wrote: >>>>> On 03/09/2015 09:58 AM, Michal Simek wrote: >>>>>> On 03/09/2015 09:50 AM, Marc Kleine-Budde wrote: >>>>>>> On 03/09/2015 09:48 AM, Michal Simek wrote: >>>>>>>> Remove Kconfig dependency and enable driver for >>>>>>>> all ARCHs. >>>>>>>> >>>>>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com> >>>>>>>> Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com> >>>>>>>> --- >>>>>>>> >>>>>>>> Test for all archs done by Kbuild test robot without any problem. >>>>>>>> --- >>>>>>>> drivers/net/can/Kconfig | 1 - >>>>>>>> 1 file changed, 1 deletion(-) >>>>>>>> >>>>>>>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig >>>>>>>> index 98d73aab52fe..f690c3fb3088 100644 >>>>>>>> --- a/drivers/net/can/Kconfig >>>>>>>> +++ b/drivers/net/can/Kconfig >>>>>>>> @@ -131,7 +131,6 @@ config CAN_RCAR >>>>>>>> >>>>>>>> config CAN_XILINXCAN >>>>>>>> tristate "Xilinx CAN" >>>>>>>> - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST >>>>>>> >>>>>>> I think that's what COMPILE_TEST ist for? >>>>>> >>>>>> For compilation yes but not for enabling. Currently this driver >>>>>> can be also used on ARM64 that's why people suggesting directly >>>>>> to remove dependency on arch and then COMPILE_TEST can be removed >>>>>> too. >>>>> >>>>> In the past (May 2014) I had people complaining that certain ARM SoC >>>>> specific drivers are enabled on ARM in general, not just on that SoC. As >>>>> I'm not following arm64 in detail, has the notion of using depends on >>>>> ARCH changes since then? >>>>> >>>>>> Or do you want me to change description to mention that this is for >>>>>> ARM64 enabling? >>>>> >>>>> Given this is consensus, a remark to ARM64 would be appreciated. :) >>>> >>>> David has applied this patch which is in general just the same as this one. >>>> >>>> (linux-next) Remove architecture dependency >>>> 28811a8c00fe0d899b8a544421f3b4947425d5e8 >>>> >>>> Mark Brown has suggested to do so for spi and don't check architecture at >>>> all. >>>> I have also sent similar patch for watchdog driver too. >>>> >>>> I think it is up to you if you want to add ARM64 to Kconfig or just remove >>>> that arch dependencies. >>>> To be honest my goal is to enable this driver for ARM64. >>>> Please tell me what way you prefer. >>> >>> I like the idea of removing the depends on ARCH completely. Jean, what >>> do you think? >> >> Removing the dependency completely will let the option be displayed on >> systems where the driver is useless. I am in favor of having hardware >> dependencies on as many drivers as possible to avoid bothering the user >> with irrelevant questions. The list of Kconfig entries has grown a lot >> over time! >> >> If the current dependency is too strict then I would suggest to extend >> it or to make it broader (depends on ARM || ARM64 || COMPILE_TEST would >> be acceptable IMHO.) Dropping it completely only makes sense if the part >> is used on so many systems that the dependency becomes too long or is a >> pain to maintain. > > Sounds reasonable. Michael, make it so. I have sent v2 which add arm64 to Kconfig and I am keeping just dependency on ARCH_ZYNQ not all ARM platforms. Thanks, Michal
On Mon, 2015-03-09 at 03:04PM +0100, Michal Simek wrote: > On 03/09/2015 02:55 PM, Marc Kleine-Budde wrote: > > On 03/09/2015 02:53 PM, Jean Delvare wrote: > >> Le Monday 09 March 2015 à 10:56 +0100, Marc Kleine-Budde a écrit : > >>> On 03/09/2015 10:52 AM, Michal Simek wrote: > >>>> On 03/09/2015 10:13 AM, Marc Kleine-Budde wrote: > >>>>> On 03/09/2015 09:58 AM, Michal Simek wrote: > >>>>>> On 03/09/2015 09:50 AM, Marc Kleine-Budde wrote: > >>>>>>> On 03/09/2015 09:48 AM, Michal Simek wrote: > >>>>>>>> Remove Kconfig dependency and enable driver for > >>>>>>>> all ARCHs. > >>>>>>>> > >>>>>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com> > >>>>>>>> Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com> > >>>>>>>> --- > >>>>>>>> > >>>>>>>> Test for all archs done by Kbuild test robot without any problem. > >>>>>>>> --- > >>>>>>>> drivers/net/can/Kconfig | 1 - > >>>>>>>> 1 file changed, 1 deletion(-) > >>>>>>>> > >>>>>>>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig > >>>>>>>> index 98d73aab52fe..f690c3fb3088 100644 > >>>>>>>> --- a/drivers/net/can/Kconfig > >>>>>>>> +++ b/drivers/net/can/Kconfig > >>>>>>>> @@ -131,7 +131,6 @@ config CAN_RCAR > >>>>>>>> > >>>>>>>> config CAN_XILINXCAN > >>>>>>>> tristate "Xilinx CAN" > >>>>>>>> - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST > >>>>>>> > >>>>>>> I think that's what COMPILE_TEST ist for? > >>>>>> > >>>>>> For compilation yes but not for enabling. Currently this driver > >>>>>> can be also used on ARM64 that's why people suggesting directly > >>>>>> to remove dependency on arch and then COMPILE_TEST can be removed > >>>>>> too. > >>>>> > >>>>> In the past (May 2014) I had people complaining that certain ARM SoC > >>>>> specific drivers are enabled on ARM in general, not just on that SoC. As > >>>>> I'm not following arm64 in detail, has the notion of using depends on > >>>>> ARCH changes since then? > >>>>> > >>>>>> Or do you want me to change description to mention that this is for > >>>>>> ARM64 enabling? > >>>>> > >>>>> Given this is consensus, a remark to ARM64 would be appreciated. :) > >>>> > >>>> David has applied this patch which is in general just the same as this one. > >>>> > >>>> (linux-next) Remove architecture dependency > >>>> 28811a8c00fe0d899b8a544421f3b4947425d5e8 > >>>> > >>>> Mark Brown has suggested to do so for spi and don't check architecture at > >>>> all. > >>>> I have also sent similar patch for watchdog driver too. > >>>> > >>>> I think it is up to you if you want to add ARM64 to Kconfig or just remove > >>>> that arch dependencies. > >>>> To be honest my goal is to enable this driver for ARM64. > >>>> Please tell me what way you prefer. > >>> > >>> I like the idea of removing the depends on ARCH completely. Jean, what > >>> do you think? > >> > >> Removing the dependency completely will let the option be displayed on > >> systems where the driver is useless. I am in favor of having hardware > >> dependencies on as many drivers as possible to avoid bothering the user > >> with irrelevant questions. The list of Kconfig entries has grown a lot > >> over time! > >> > >> If the current dependency is too strict then I would suggest to extend > >> it or to make it broader (depends on ARM || ARM64 || COMPILE_TEST would > >> be acceptable IMHO.) Dropping it completely only makes sense if the part > >> is used on so many systems that the dependency becomes too long or is a > >> pain to maintain. > > > > Sounds reasonable. Michael, make it so. > > I have sent v2 which add arm64 to Kconfig and I am keeping just dependency on > ARCH_ZYNQ not all ARM platforms. You could (and some people do that with some devices) use these devices from x86(_64) if you plug your FPGA/Zynq platform into a PCIe slot (FWIW, this should work for any platform that supports PCIe). I think we just had somebody sending patches to enable the Zynq UART, IIRC, for x86. Sören -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/09/2015 04:51 PM, Sören Brinkmann wrote: >>> Sounds reasonable. Michael, make it so. >> >> I have sent v2 which add arm64 to Kconfig and I am keeping just dependency on >> ARCH_ZYNQ not all ARM platforms. > > You could (and some people do that with some devices) use these devices > from x86(_64) if you plug your FPGA/Zynq platform into a PCIe slot > (FWIW, this should work for any platform that supports PCIe). I think we > just had somebody sending patches to enable the Zynq UART, IIRC, for x86. Nice :) The "depends on" can easily be changed with once there's PCIe glue code for the driver. Marc
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 98d73aab52fe..f690c3fb3088 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -131,7 +131,6 @@ config CAN_RCAR config CAN_XILINXCAN tristate "Xilinx CAN" - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST depends on COMMON_CLK && HAS_IOMEM ---help--- Xilinx CAN driver. This driver supports both soft AXI CAN IP and