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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53748227.3050809@ti.com>
Date:	Thu, 15 May 2014 14:30:23 +0530
From:	Sekhar Nori <nsekhar@...com>
To:	Peter Ujfalusi <peter.ujfalusi@...com>,
	Arnd Bergmann <arnd@...db.de>
CC:	<joelf@...com>, <linux@....linux.org.uk>, <vinod.koul@...el.com>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <linux-omap@...r.kernel.org>,
	<devicetree@...r.kernel.org>, <linux-doc@...r.kernel.org>,
	<tony@...mide.com>, <bcousson@...libre.com>,
	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <Pawel.Moll@....com>,
	"Mattson, Mark" <m-mattson@...com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>
Subject: Re: [PATCH v2 3/5] dt/bindings: ti,edma: Remove redundant properties
 from documentation

+ DT bindings maintainers

On Thursday 15 May 2014 01:48 PM, Peter Ujfalusi wrote:
> On 05/15/2014 11:01 AM, Arnd Bergmann wrote:
>> On Tuesday 13 May 2014 13:30:30 Peter Ujfalusi wrote:
>>> From CCCFG register of eDMA3 we can get all the needed information for the
>>> driver about the IP:
>>> Number of channels: NUM_DMACH
>>> Number of regions: NUM_REGN
>>> Number of slots (PaRAM sets): NUM_PAENTRY
>>> Number of TC/EQ: NUM_EVQUE
>>>
>>> The ti,edma-regions; ti,edma-slots and dma-channels in DT are
>>> redundant since the very same information can be obtained from the HW.
>>> The mentioned properties can be removed from the binding document.
>>>
>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@...com>
>>
>> I wonder if we should keep them listed as "optional" properties so you
>> can have a dtb file that still works with older kernels which need them.
>>
>> What you do is an incompatible change to the binding, which we shouldn't
>> do lightly. Any new dts files don't need this information of course, but
>> as a general rule, I'd rather keep things like this around unless we
>> already have to enforce an ABI break that is well documented.
> 
> We could keep them as optional, or to be precise: ignored properties since we
> are not going to even look at them in the future.
> But I do not really see the reason to do so. With this change new kernels will
> boot with old DTB - if it can not be changed which I have not seen yet. Sure
> old kernel would not boot with this change, but why would you downgrade the
> kernel and update the DTB on a board?
> Bisecting is not a good reason since the bug you might be hunting for could be
> in the DTS or in the kernel code so you need to update both of them to be sure
> you reach the commit you are looking for.

Agree with Peter here. The bisecting corner case can hopefully be
handled by appended DTB even if the original DTB was ROMed.

Thanks,
Sekhar
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ