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-next>] [day] [month] [year] [list]
Date:	Mon, 09 Dec 2013 13:34:32 +0400
From:	Sergei Ianovich <ynvich@...il.com>
To:	Daniel Mack <zonque@...il.com>
Cc:	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Landley <rob@...dley.net>,
	Russell King <linux@....linux.org.uk>,
	Chris Ball <cjb@...top.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	Seungwon Jeon <tgih.jun@...sung.com>,
	"open list:OPEN FIRMWARE AND..." <devicetree@...r.kernel.org>,
	DOCUMENTATION <linux-doc@...r.kernel.org>,
	Robert Jarzmik <robert.jarzmik@...e.fr>
Subject: Re: [PATCH 5/9] ARM: dts: provide DMA config to pxamci

On Mon, 2013-12-09 at 10:04 +0100, Daniel Mack wrote:
> On 12/09/2013 02:33 AM, Arnd Bergmann wrote:
> > On Sunday 08 December 2013, Sergei Ianovich wrote:
> >> Non-dts implementation supply required DMA channel numbers as
> >> IORESOURCE_DMA. However, there is was no way to get them from
> >> device tree.
> > 
> > I just wrote a lengthy reply to this email to explain in what ways
> > you got it wrong, but then I saw that Daniel has already done all
> > the work in the right way in August, so nevermind that.
> > 
> > It hasn't made it upstream yet, but see http://list-archives.org/2013/08/07/linux-mtd-lists-infradead-org/patch-00-20-arm-pxa-move-core-and-drivers-to-dmaengine/f/3444199144
> > for how it's done. Maybe Daniel can comment on the status of his
> > patches.
> 
> I recently rebased all my patches on top of 3.13-rc3, and will resend in
> couple of days.
> 
> The real problem here is that by reworking the DMA related PXA bits, all
> drivers have to be changed at once, and a gradual transition seems
> impossible. For that, I was asking for help in areas where I don't have
> any hardware to test my patches on, but unfortunately, nobody got back
> to me yet.

Nice to have Daniel in this conversation. Your patch series is a big and
important work. However, I am not sure I will ever land as is exactly
for this reason.

DMA is a per-physical-device concept, not per-platform. Only the DMA
controller is per-platform. This means we need to rewrite all platform
drivers at once. This is roughly equivalent to adding a new platform
support in one patch, which is not going to work.

In patch 08/20 in the series above, you change 10% lines of the pxa mmc
driver. If we don't count boilerplate lines, this will amount to over
50%. In other word, the output is a new driver.

My proposal in to actually add new drivers for each platform device with
DMA and mark new ones EXPERIMENTAL. When they receive adequate testing
we remove the tag and mark the old one OBSOLETE. When we have a new
driver for every device presently supported, we will drop the whole old
series.

This should be very close to a gradual transition.

While we are in transition, I propose that we allow 'hackish' support
for device tree in the existing drivers. Platform devices are declared
in dtsi files, so when we move to a new driver we just change the
compatible string there. Actual devices with their one dts file won't
need any change. They will need a dtb recompile, though. This way we can
begin a migration to device tree in pxa immediately.

The patch series does just that.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ