netdev - Re: [PATCH v4 1/4] ethernet: arc: Add support for Rockchip SoC layer device tree bindings

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: <3545574.7Z5WmaTlg0@wuerfel>
Date:	Wed, 03 Sep 2014 14:50:22 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Heiko Stübner <heiko@...ech.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Romain Perier <romain.perier@...il.com>,
	linux-rockchip@...ts.infradead.org, devicetree@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH v4 1/4] ethernet: arc: Add support for Rockchip SoC layer device tree bindings

On Wednesday 03 September 2014 14:20:50 Heiko Stübner wrote:
> > 
> > One last question: is this the location given as .grf_offset the
> > only thing in grf that is potentially of concern to this driver?
> > 
> > If it is, you can change the binding to include the register number
> > in the syscon reference, like
> > 
> >       rockchip,grf = <&grf 0x154>;
> > 
> > and then read it from there, to simplify the code needed to get the
> > number from the device id.
> 
> I would disagree here 
> 
> Specific to the emac, there also exists a second register in the grf (0xa8 for 
> the rk3188) that contains a field 
> 
> ----
> emac_newrcv_en - the selection of RMII receive selection
> 0: don't support the data package without header
> 1: support the data package without header
> ----
> 
> which we don't handle currently but somebody might want to in the future.
> [There also is no documentation of this at all]

Ok, fair enough. If there is a chance that there would be more of these
fields that we may want to support in the future, the table approach
seems reasonable.

The main advantage of putting the register number into the syscon
reference is to support future models without driver changes, but
it's not clear if that's worth it.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html