netdev - Re: [RESEND PATCH v5 1/2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

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, 3 Jun 2016 19:15:29 +0200
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Ulrich Hecht <ulrich.hecht@...il.com>,
	Ramesh Shanmugasundaram <ramesh.shanmugasundaram@...renesas.com>
Cc:	"mkl@...gutronix.de" <mkl@...gutronix.de>,
	"wg@...ndegger.com" <wg@...ndegger.com>,
	"linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Chris Paterson <Chris.Paterson2@...esas.com>,
	Simon Horman <horms@...ge.net.au>,
	Magnus Damm <magnus.damm@...il.com>,
	"linux-renesas-soc@...r.kernel.org" 
	<linux-renesas-soc@...r.kernel.org>
Subject: Re: [RESEND PATCH v5 1/2] can: rcar_canfd: Add Renesas R-Car CAN FD
 driver

On 06/03/2016 07:03 PM, Ulrich Hecht wrote:

> Thanks; I missed that every register is described twice.
>
> Nevertheless, names often vary more or less subtly between your patch
> and the specs, making it very hard to review. Some have letters added,
> some have letters removed, and some are just plain confusing. For
> instance, RCANFD_DCFG_* apparently does not describe, as one might
> think, RSCFDnCFDCmDCFG, but RSCFDnCFDCmFDCFG. These names are, of
> course, completely ridiculous, but inventing a new set makes things
> even worse, IMO.

???

You suggest to use 'completely ridiculous' definitions in favor to 
definitions that have a proper name space RCANFD_ ?

When there is a more readable way that maintains proper readable code 
there's no reason to adopt crappy definitions just because some chip 
designer has no clue how to design proper register names.

When there's some mapping from RSCFDnCFDCmFDCFG to RCANFD_DCFG_* this 
could be mentioned in the comments.

But I'm totally against these blurry upper/lower case letter stuff for 
register definitions.

Regards,
Oliver


>
> At least for the bits, I'd stick with the names given in the
> datasheet. They usually make a modicum of sense, and it makes it way
> easier to search for them. It would also help if the bits were sorted
> consistently.
>
> CU
> Uli
>