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]

Message-ID: <3012728.7zDNPtQ7kR@wuerfel>
Date:	Wed, 02 Mar 2016 10:11:06 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	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 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.

	Arnd