linux-kernel - Re: [RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

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]

Date:	Mon, 19 Oct 2015 14:26:38 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Liviu Dudau <Liviu.Dudau@....com>
Cc:	David Airlie <airlied@...ux.ie>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Mark Yao <mark.yao@...k-chips.com>,
	Heiko Stuebner <heiko@...ech.de>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	linux-rockchip <linux-rockchip@...ts.infradead.org>,
	LAKML <linux-arm-kernel@...ts.infradead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 1/4] drm: Introduce generic probe function for
 component based masters.

On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
> On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote:
> > Please don't move this into here, it's completely inappropriate.  Just
> > because something makes use of this does not mean they only support
> > 32-bit DMA.  Besides, this has nothing to do with whether or not it's
> > OF-based or not.
> 
> Understood. My thinking process was that component-based drivers are all
> OF-enabled (how else do you make use of the framework?) and 32-bit DMA is
> present in 2 out of 3 drivers that are converted, so it looks to be common
> enough that adding it to armada would not hurt. It was all done in the name of
> collecting common code in a single function.

Which is an utterly crap reason.

It's also not appropriate.  I'm really not sure why you think that moving
this here would in any way be appropriate - from my point of view, the
mere proposal is utterly insane.

The "container" device does not do any DMA, so it's inappropriate for
it to have DMA masks set or negotiated on it.  So, actually, no one
should be setting the DMA mask for their container device.  It's wrong.

What if we have a 64-bit OF based platform wanting to use the component
helper, and they want to call this function?  You prevent them doing so
by moving this into here, because they're then forced down to 32-bit DMA.
Please, get rid of it, and leave this crappiness in the respective
drivers.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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/