linux-kernel - Re: [PATCH v5 06/10] dmaengine: add API for getting dma controller's quirk

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:	Fri, 9 Oct 2015 19:23:40 +0800
From:	Shawn Lin <shawn.lin@...k-chips.com>
To:	Vinod Koul <vinod.koul@...el.com>
Cc:	shawn.lin@...k-chips.com, Heiko Stuebner <heiko@...ech.de>,
	Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>, Mark Brown <broonie@...nel.org>,
	Doug Anderson <dianders@...omium.org>,
	Olof Johansson <olof@...om.net>,
	Sonny Rao <sonnyrao@...omium.org>,
	Addy Ke <addy.ke@...k-chips.com>, dmaengine@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org, alsa-devel@...a-project.org,
	linux-spi@...r.kernel.org
Subject: Re: [PATCH v5 06/10] dmaengine: add API for getting dma controller's
 quirk

On 2015/10/7 22:32, Vinod Koul wrote:
> On Tue, Oct 06, 2015 at 05:21:13PM +0800, Shawn Lin wrote:
>
>>>> +	int (*device_get_quirks)(struct dma_chan *chan);
>>>
>>> And why do we want to expose this to users? THis doesnt seem right!
>>>
>>
>> Basically I agree not to expose dma's quirk to slave controllers...But, the
>> fact I mentioned on cover letter explain the reasons why I have to let slave
>> controllers know that they are working with a broken dma. It's a dilemma
>> that if we don't want that to be exposed(let slave controllers' driver get
>> the info via a API), we have to add broken quirk for all of them ,here and
>> there, which seems to be a disaster:(
>>
>> I would appreciate it if you could give me some suggestions at your earliest
>> convenience. :)
>>
>>> A quirk may exists but should be handled inside the controller driver and do
>>> appropriate action. You don't tell users or expect them to handle these
>>>
> I laready gave one re-read the above lines.
>
> Anyway I went ahead and read the usage. You are setting the slave parameters
> for this. I can see two ways:
> 1. Have the quirk to driver and based on quirk reset the slave settings when
> they are set by client.
> 2. Put this in DT and set the dma properties based on these quirks and let
> driver and cleint be agnostic to it

+Mark Brown

Thanks for these.

The first one is hard for dma to distinguish "broken 
slave"(I2S/SPI/UART..) from the unbroken ones(block devices like 
mmc/SFC...). If all clients are broken for that, it's easy to reset the 
slave parameters in dma driver. Unfortunately, not always, at least for 
rockchips' Socs.

And before V4, I did pass quirks to clents from DT, but Mark thought we 
should avoid to get it from dt. Anyway, now I think about it again,

(1) dma drivers doesn't know the users who should use limited burst and 
who won't. That make it's impossible for dma drivers to handle it alone 
or expose new API of burst capabilities to clients.
(2) It's inappropriate to expose quirks to clients.

so the only way I can see is to make some tricks from DT.
I would prefer to add "burst limit" property for the broken slaves 
instead of quirks for them which I did before V4.

Something like:

&spi{
max-burst-len=<1>;
}

How about?
:)

>


-- 
Best Regards
Shawn Lin

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