linux-kernel - Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

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: <20141216070413.GW16827@intel.com>
Date:	Tue, 16 Dec 2014 12:34:13 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	Simon Horman <horms+renesas@...ge.net.au>,
	Jürg Billeter <j@...ron.ch>,
	Magnus Damm <damm+renesas@...nsource.se>,
	Phil Edworthy <phil.edworthy@...esas.com>,
	linux-kernel@...r.kernel.org, linux-sh@...r.kernel.org,
	dmaengine@...r.kernel.org
Subject: Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor
 allocation failure

On Mon, Dec 15, 2014 at 10:04:45PM +0200, Laurent Pinchart wrote:
> Hi Vinod,
> 
> On Monday 15 December 2014 12:08:35 Vinod Koul wrote:
> > On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> > > On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> > >>>> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > >>>>> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > >>>>>>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> > >>>>>>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> > >>>>>>> 
> > >>>>>>> And I dont seem to have this request in my Inbox :(
> > >>>>>>> Yes I do see it in archieves, so not sure how this is not
> > >>>>>>> present, not sure if the servers mangeled it!!
> > >>>>>> 
> > >>>>>> I haven't CC'ed you, I'll make sure to do so next time. The mail
> > >>>>>> should still have reached you through the mailing list though (I
> > >>>>>> assume you're subscribed to dmaengine@...r.kernel.org ;-)).
> > >>>>> 
> > >>>>> Yes I am, so should have reached me even though i wasnt cced
> > >>>>> I do see email reaching me from list without me being in CC, but
> > >>>>> then it wont hit my inbox and go to ML folder :)
> > >>>>> So generally its a good practice to CC relvant folks, lots of
> > >>>>> folks do ask that if ML is high volume
> > >>>> 
> > >>>> Hey Laurent,
> > >>>> 
> > >>>> I see that the oddity in commitlogs with change since artifacts
> > >>>> after SOB, can you please fix that up
> > >>> 
> > >>> My bad. I've fixed the problem and pushed the result to the same
> > >>> branch
> > >>> 
> > >>> 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> > >>> 
> > >>> The only difference lies in the commit logs.
> > >> 
> > >> If my understanding was correct, we need to be based on Vinod's
> > >> topic/slave_caps_device_control_fix
> > > 
> > > Vinod, could you please comment on that ? To which kernel version do you
> > > plan to push this series ? Do I need to rebase it ?
> > 
> > Hi Laurent,
> > 
> > I did a quick at the series, looks fine mostly. I have already sent by pull
> > request to linus earlier last week and its merged, so we need to merge it
> > for next one. So yes we need to fix and test this for caps and control API
> > fix. Can you do that and I will pull and put in my next for 3.20
> 
> That's very annoying given that I have users waiting for the driver to be 
> merged, and that I've sent the pull request two weeks and a half ago.
Sorry cant help if I dont see the PULL request :( Apprently once a year
intel domain gets kicked out causing us to be unsubscribed, just bad timing
here...

> I suppose I have no choice anyway. Please provide me with a v3.20 development 
> branch on which I can rebase the patch set, I don't want to rebase it twice.
Please use topic/slave_caps_device_control_fix. I am going to rebase this
once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
impact you.

> > One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2
> > DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can
> > you please explain a bit more on it, why do you need to modify addresses
> > based on config option?
> 
> Because there's no need to write the upper bits (above 32) of the DMA 
> addresses when the DMA address spans 32 bits only, and because there's no need 
> to check for transfers that cross a 4GB boundary (that's a hardware 
> limitation) when the DMA address space is 4GB in total.
I was hoping that dma_addr_t should take care of this... but lots of HW
limitations

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