linux-kernel - Re: [PATCH v2 3/3] drivers: cleanup Kconfig stuff

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20101019111613.GJ31170@legolas.emea.dhcp.ti.com>
Date:	Tue, 19 Oct 2010 14:16:13 +0300
From:	Felipe Balbi <balbi@...com>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	"Balbi, Felipe" <balbi@...com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	linux-omap <linux-omap@...r.kernel.org>,
	linux-main <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>, Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH v2 3/3] drivers: cleanup Kconfig stuff

Hi,

On Tue, Oct 19, 2010 at 05:59:58AM -0500, Felipe Contreras wrote:
>The USB_MUSB_HDRC dependency on NOP_USB_XCEIV || TWL4030_USB is
>already there, I'm just making it explicit. The rest are not
>dependencies, just sensible defaults, and they are already in
>drivers/usb/musb/Kconfig, I'm just moving them.

might be true, but what will happen is that other developers will just
"follow what's in the tree" so they'll keep on adding more and more
"sesible defaults" to this line.

Linus had some really good comments about Kconfig usage some time ago
and I'm sure he wouldn't like us adding "sensible defaults" all over the
place.

>If you have a better approach to avoid manually selecting TWL4030_USB
>on defconfigs, and making sure USB_MUSB_HDRC works, please share it.

that's the thing. Currently, I don't think it should be automatic as we
can only have one transceiver structure. Look into
drivers/usb/otg/otg.c, it's just a static global pointer on that file,
which prevents us from having a working solution if you enable more than
one transceiver.

Ideally there would be a class or something similar to allow us to
register N transceiver and use the correct one in runtime, that would
make distro-makers' life easier. It'll probably help Linaro also at some
point, but as of today, enabling more than one transceiver will never
work.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/