linux-kernel - Re: [PATCH v2 01/10] ARM: NUC900: Add nuc970 machine support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Jul 2016 10:23:32 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Wan Zongshun <vw@...mu.org>
Cc:	devicetree@...r.kernel.org, jason@...edaemon.net,
	Wan Zongshun <mcuos.com@...il.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Russell King <linux@...linux.org.uk>,
	linux-kernel@...r.kernel.org, p.zabel@...gutronix.de,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 01/10] ARM: NUC900: Add nuc970 machine support

On Tuesday, July 12, 2016 3:14:47 PM CEST Wan Zongshun wrote:
> On 2016年07月12日 12:30, Wan Zongshun wrote:
> >
> >
> > On 2016年07月12日 00:04, Arnd Bergmann wrote:
> >> On Sunday, July 10, 2016 3:27:21 PM CEST Wan Zongshun wrote:
> >>> +ifeq ($(CONFIG_SOC_NUC970),)
> >>>   obj-y                          := irq.o time.o mfp.o gpio.o clock.o
> >>>   obj-y                          += clksel.o dev.o cpu.o
> >>> +endif
> >>>   # W90X900 CPU support files
> >>
> >> When mfp.o is disabled like this, I get a link error in two drivers
> >> using the exported interface:
> >>
> >> ERROR: "mfp_set_groupg" [drivers/spi/spi-nuc900.ko] undefined!
> >> ERROR: "mfp_set_groupi" [drivers/input/keyboard/w90p910_keypad.ko]
> >> undefined!
> >
> > Why remove mfp modules? this multifunction pin driver should be used for
> > those two drivers, if no mfp_set_groupX, I don't think driver can work.
> >
> > Now mfp has standard driver subsystem?
> >
> >>
> >> Any idea for a better migration strategy?
> 
> Arnd, If you still think the mfp should be removed, we can send a series 
> patches to instead of using mfp interface quickly, and do mfp set in 
> local driver. Do you think it is ok?

I don't think setting it locally in the driver is a good idea.

In the long run, this should go through the pinctrl framework, but
there is no need to implement that right away. Until then, I think
using the existing mfp.o code is fine, it will just need to be
adapted slightly to understand the DT based device names.

	Arnd