diff mbox

net: can: Enable xilinx driver for all ARCHs

Message ID 4096fa4ceae72817d8e64d9a1da738038a5c864a.1425890926.git.michal.simek@xilinx.com
State Awaiting Upstream, archived
Delegated to: David Miller
Headers show

Commit Message

Michal Simek March 9, 2015, 8:48 a.m. UTC 
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(-)

Comments

Marc Kleine-Budde March 9, 2015, 8:50 a.m. UTC | #1 
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
Michal Simek March 9, 2015, 8:58 a.m. UTC | #2 
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
Marc Kleine-Budde March 9, 2015, 9:13 a.m. UTC | #3 
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
Michal Simek March 9, 2015, 9:52 a.m. UTC | #4 
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
Marc Kleine-Budde March 9, 2015, 9:56 a.m. UTC | #5 
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
Jean Delvare March 9, 2015, 1:53 p.m. UTC | #6 
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,
Marc Kleine-Budde March 9, 2015, 1:55 p.m. UTC | #7 
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
Michal Simek March 9, 2015, 2:04 p.m. UTC | #8 
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
Soren Brinkmann March 9, 2015, 3:51 p.m. UTC | #9 
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
Marc Kleine-Budde March 9, 2015, 3:56 p.m. UTC | #10 
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 mbox

Patch

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