linux-kernel - Re: [RFC PATCH] drivers: ata: Read Rx water mark value from device-tree

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:	Wed, 2 Mar 2016 10:27:51 +0100
From:	Michal Simek <michal.simek@...inx.com>
To:	Arnd Bergmann <arnd@...db.de>,
	Michal Simek <michal.simek@...inx.com>
CC:	Anurag Kumar Vulisha <anuragku@...inx.com>,
	Rob Herring <robh@...nel.org>,
	Sören Brinkmann <soren.brinkmann@...inx.com>,
	"pawel.moll@....com" <pawel.moll@....com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"tj@...nel.org" <tj@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
	Anirudha Sarangi <anirudh@...inx.com>,
	Srikanth Vemula <svemula@...inx.com>,
	"Punnaiah Choudary Kalluri" <punnaia@...inx.com>
Subject: Re: [RFC PATCH] drivers: ata: Read Rx water mark value from
 device-tree

On 2.3.2016 10:11, Arnd Bergmann wrote:
> On Wednesday 02 March 2016 09:05:49 Michal Simek wrote:
>> On 2.3.2016 06:53, Anurag Kumar Vulisha wrote:
>>>>>>>
>>>>>>> I would probably make this dependent on the compatible string
>>>>>>> instead, and have a table in the device driver that uses a
>>>>>>> specific value for each variant of the device, but either way should be
>>>> fine.
>>>>>>>
>>>>>>> Having a separate property is most appropriate if for each
>>>>>>> hardware revision there is exactly one ideal value, while a table
>>>>>>> in the driver makes more sense if this takes a bit of tuning and
>>>>>>> the driver might choose to optimize it differently based on other
>>>>>>> constraints, such as its own interrupt handler implementation.
>>
>> that 0x40 is value choose based on testing that it is not causing any
>> visible problem and this is used as default value in the driver
>> (PTC_RX_WM_VAL - ahci_ceva.c)
>>
>> Values which you can setup are in range 0x0 - 0x7f (7bits). It means
>> hardware fifo size is probably 0x80.
>>
>> And this dt/module parameter is IMHO just sw setting setup by user.
>> It means I am not quite sure that this is DT parameter because it is
>> just SW setting.
>> I expect this range will be valid for all silicon revisions.
>> If happen that any silicon revision can't setup certain level because of
>> HW bug we can handle it via DT parameter or specific compatible string.
>> But setting up watermark SW level via DT doesn't look correct to me.
>>
>> Please let me know what you think.
> 
> Ok, thanks for the background. I think we should just leave it to be
> set by the driver then. Please make sure that each SoC specific .dtsi
> file has a unique "compatible" string for the device though, so that
> the driver can later override it based on the specific variant if
> that ends up being necessary for performance or bug-avoidance.

No problem with default value in driver. Something has to be setup.
Reset value based on reg spec I was checking is 0x20. Based on our
testing we saw some issues that's why 0x40 was setup as default value.
There is a need to be able to configure this value for example for
testing different values that's why I think module parameter should be
the right way to go.

If this should be DT parameters there should be different ceva IP which
allows different fifo size and different watermark level to be setup by
user.

What do you think? Does it sound reasonable.

Thanks,
Michal