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:	Sat, 02 Feb 2013 21:17:04 +0400
From:	Sergei Shtylyov <sshtylyov@...sta.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
CC:	Felipe Balbi <balbi@...com>, Matt Porter <mporter@...com>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Chris Ball <cjb@...top.org>,
	"Cousson, Benoit" <b-cousson@...com>,
	Arnd Bergmann <arnd@...db.de>,
	Linux Documentation List <linux-doc@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Devicetree Discuss <devicetree-discuss@...ts.ozlabs.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linux MMC List <linux-mmc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Vinod Koul <vinod.koul@...el.com>,
	Rob Landley <rob@...dley.net>, Dan Williams <djbw@...com>,
	Linux SPI Devel List 
	<spi-devel-general@...ts.sourceforge.net>,
	Linux OMAP List <linux-omap@...r.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello.

On 02-02-2013 20:45, Russell King - ARM Linux wrote:

>>> There are two people on this thread CC list who were also involved or
>>> CC'd on the mails from the thread in 2010...  Tony and Felipe.
>>> Unfortunately, the person who agreed to do the work is no longer in the
>>> land of the living.  Yes I know it's inconvenient for people to die
>>> when they've still got lots of important work to do but that's what can
>>> happen...

>>     Hm... wasn't it David Brownell? He's the only person who I know has
>> died recently who has dealt with DaVinci, MUSB and the releated stuff.

> Actually, it wasn't David who was going to do it - that's where the email
> thread gets messy because the mailer David was using makes no distinction
> in text format between what bits of text make up the original email being
> replied to, and which bits of text are written by David.

    Hm, strange...

> It might have been Felipe; there appears to be an email from Felipe saying
> that as the immediate parent to David's email.  But that's not really the
> point here.  The point is that _someone_ agreed to put the work in, and
> _that_ agreement is what caused the patch to be discarded.

> And, as I've already explained, you brought up the subject of it being
> discarded shortly after, and it got discussed there _again_, and the
> same things were said _again_ by at least two people about it being in
> drivers/dma.

    It wasn't said that somebody concrete was going to work on it. I had to 
explcitly write an email laying all further responsibility on CPPI 4.1 support 
on TI back then.

> But anyway, that's all past history.  What was said back then about it
> being elsewhere in the tree is just as relevant today as it was back
> then.  The only difference is that because that message wasn't received,
> it's now two years later with no progress on that.  And that's got
> *nothing* what so ever to do with me.

    Yes, of course. In my original mail that started the discussion I said 
that we have to wait indefinitely for TI to write the new DMA driver. I just 
wondered wouldn't it be better to use the same approach as for EDMA with 
transitioning to drivers/dma/ step by step.

> I know people like to blame me just because I'm apparantly the focus of
> the blame culture, but really this is getting beyond a joke.

> So, I want an apology from you for your insistance that I'm to blame
> for this.

    OK, I apologise if you consider yourself the target of my blame. My aim 
was rather to establish the truth about that decision taken back in Dec 2010 
-- which we seem to have achieved.

> Moreover, _I_ want to know what is going to happen in the
> future with this so that I don't end up being blamed anymore for the
> lack of progress on this issue.

    Nothing. My blame for the lack of progress has long been laid on TI, after 
I explictly passed the responsibility for the driver to them. My intent with 
the mail that started the discussion was to probe whether we still have 
another opportunity of having MUSB DMA support for OMAP-L1x and Sitara. I just 
thought that you might have changed your mind somehow on the matter.

WBR, Sergei

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