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: <CAA3gFWtDiza1V3_eM84JxseHRDJMH_NF4Rx=-dOPD-Usp=pVNA@mail.gmail.com>
Date:	Tue, 8 Dec 2015 10:21:35 +0100
From:	Neil Armstrong <narmstrong@...libre.com>
To:	Josh Cartwright <joshc@...com>
Cc:	Nicolas Ferre <nicolas.ferre@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	Harini Katakam <harini.katakam@...inx.com>,
	Boris BREZILLON <boris.brezillon@...e-electrons.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	linux-kernel@...r.kernel.org, netdev <netdev@...r.kernel.org>,
	devicetree@...r.kernel.org
Subject: Re: [PATCH net 1/2] net: cadence: macb: Disable USRIO register on
 some platforms

Hi Josh,

2015-12-07 20:32 GMT+01:00 Josh Cartwright <joshc@...com>:
> On Mon, Dec 07, 2015 at 11:58:33AM +0100, Neil Armstrong wrote:
>> On some platforms, the macb integration does not use the USRIO
>> register to configure the (R)MII port and clocks.
>> When the register is not implemented and the MACB error signal
>> is connected to the bus error, reading or writing to the USRIO
>> register can trigger some Imprecise External Aborts on ARM platforms.
>> ---
>
> Does this make sense to even be a separate bool device tree property?
>
> This sort of configuration is typically done by:
>    1. Creating a new 'caps' bit; relevant codepaths check that bit
>    2. Creating a new "compatible" string for your platform's macb
>       instance
>    3. Creating a new 'struct macb_config' instance for your platform,
>       setting any relevant caps bits when it is selected.
>
>   Josh

I see the point, but according to the User Guide :
>User I/O Register
> The MACB design provides up to 16 inputs and 16 outputs,
> for which the state of the I/O may
> be read or set under the control of the processor interface.
> If the user I/O is disabled as a configuration option, this address space is defined
> as reserved, and hence will be a read-only register of value 0x0.

On the design I worked on, the macb_user_* signals were commented,
thus disabling this register.

The implementation is not mandatory, and the "generic" macb compatible
"cdns,macb" should disable
usage of USRIO register by default and be only used for platform
specific macb instances...

Is it OK if I add a new 'caps' bit and use it for the "generic" macb instance ?

For the device tree property, it should be safe to have the generic
instances of macb and gem to
rely on these properties instead of hardcoded instances.
(it's the biggest aim of device tree, no ? no more hardcoded 'caps' bit ?)
The "no-usrio" and other should eventually map 'caps' bits along the
generic instances.

Neil
--
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