linux-kernel - Re: [PATCH 1/2] dma: shdma: fix runtime PM: clear channel buffers on reset

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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.1203280858120.4583@axis700.grange>
Date:	Wed, 28 Mar 2012 09:02:38 +0200 (CEST)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Paul Mundt <lethal@...ux-sh.org>
cc:	linux-kernel@...r.kernel.org, Vinod Koul <vinod.koul@...el.com>,
	linux-sh@...r.kernel.org, linux-pm@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Magnus Damm <magnus.damm@...il.com>
Subject: Re: [PATCH 1/2] dma: shdma: fix runtime PM: clear channel buffers
 on reset

On Wed, 28 Mar 2012, Paul Mundt wrote:

> On Wed, Jan 04, 2012 at 03:34:17PM +0100, Guennadi Liakhovetski wrote:
> > On platforms, supporting power domains, if the domain, containing a DMAC
> > instance is powered down, the driver fails to resume correctly. On those
> > platforms DMAC channels have an additional CHCLR register for clearing
> > channel buffers. Using this register during runtime resume fixes the
> > problem.
> > 
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@....de>
> 
> ..
> 
> > @@ -139,6 +157,10 @@ static int sh_dmae_rst(struct sh_dmae_device *shdev)
> >  		dev_warn(shdev->common.dev, "Can't initialize DMAOR.\n");
> >  		return -EIO;
> >  	}
> > +	if (shdev->pdata->dmaor_init & ~dmaor)
> > +		dev_warn(shdev->common.dev,
> > +			 "DMAOR=0x%x hasn't latched the initial value 0x%x.\n",
> > +			 dmaor, shdev->pdata->dmaor_init);
> >  	return 0;
> >  }
> >  
> I've just hit this on SH7786, which I suspect means that I've got it
> wired up incorrectly somehow. This hunk also appears completely unrelated
> to the changelog, so I'm wondering what exactly it's for. If this is a
> probe attempt then presumably we should be handing down an error and
> -ENODEV'ing in the init path? Is it expected that this is non-fatal in
> the other reset cases?

The answer is "I don't know." I'm also seeing this in several cases, e.g., 
on sh7372 one of the two USB DMA controllers always triggers this, IIRC. 
This failure does indeed seem to be non-fatal, and it has been simply 
ignored in the past. I just hit it in my tests and decided it was worth 
drawing attention to it to maybe actually find out what's going on there.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/