Re: [PATCH] net: can: Enable xilinx driver for all ARCHs

[SÃren Brinkmann]

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@xxxxxxxxxx>
> >>>>>>>> Acked-by: SÃren Brinkmann <soren.brinkmann@xxxxxxxxxx>
> >>>>>>>> ---
> >>>>>>>>
> >>>>>>>> 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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/