RE: RFC: ARM Boot standard for passing device tree blob
Hi -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: 26 March 2010 23:04 To: Grant Likely Cc: Nicolas Pitre; Mitch Bradley; Catalin Marinas; devicetree-discuss; Philippe Robin; David Rusling; Jeremy Kerr; Dave P Martin; linux-arm-ker...@lists.infradead.org Subject: Re: RFC: ARM Boot standard for passing device tree blob [...] 2. No ARM CPU supports having the D-cache enabled without the MMU; the data cache needs to be told via the page tables what can be cached and what can't - it needs to be told that RAM can cached but IO devices must not be. In short, the MMU must always be off, which in turn means the D-cache must always be disabled. Further to this, it's worth pointing out that some systems have external caches (such as non-architected L2 cache etc.) which are not integrated into the the CPU. If we allow D-cache to be turned on at all, we would have to be clear that external caches must be turned off or configured in a very precise way in order to avoid breaking the kernel's bootstrap process. This is especially important when assumptions about the cache arrangement are not fixed at build time (in the device tree context, such assumptions generally won't be completely fixed). There's a potential world of problems here--- it seems best avoided. It could be worth clarifying that the L1 I-cache is the _only_ cache which is permitted to be enabled at kernel entry, and that all other caches in the system must be disabled. Cheers ---Dave ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch] of: check for IS_ERR()
On Fri, Feb 26, 2010 at 01:54:20AM -0800, David Miller wrote:
From: Dan Carpenter erro...@gmail.com
Date: Fri, 26 Feb 2010 12:49:41 +0300
get_phy_device() can return an ERR_PTR()
Signed-off-by: Dan Carpenter erro...@gmail.com
---
I don't have a cross compile environment set up so I can't even compile
test this. :/ But err.h is included so it should be OK.
It should return ERR_PTR() consistently. Checking for both
NULL and ERR_PTR() is undesirable.
Hi Giulio,
get_phy_device() currently returns NULL because of: 3ee82383f0098a2 phy:
fix phy address bug. If I change it to return ERR_PTR(-ENODEV) that
will mean we break out of the loop with an error in mdiobus_register()
where before we would just continue on.
drivers/net/phy/mdio_bus.c
119 phydev = mdiobus_scan(bus, i);
120 if (IS_ERR(phydev)) {
121 err = PTR_ERR(phydev);
122 goto error;
123 }
Is that OK?
I'm not really familiar with this hardware at all, I'm just going based
on static analysis. :/
regards,
dan carpenter
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: RFC: ARM Boot standard for passing device tree blob
Dave P. Martin wrote: Hi -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: 26 March 2010 23:04 To: Grant Likely Cc: Nicolas Pitre; Mitch Bradley; Catalin Marinas; devicetree-discuss; Philippe Robin; David Rusling; Jeremy Kerr; Dave P Martin; linux-arm-ker...@lists.infradead.org Subject: Re: RFC: ARM Boot standard for passing device tree blob [...] 2. No ARM CPU supports having the D-cache enabled without the MMU; the data cache needs to be told via the page tables what can be cached and what can't - it needs to be told that RAM can cached but IO devices must not be. In short, the MMU must always be off, which in turn means the D-cache must always be disabled. Further to this, it's worth pointing out that some systems have external caches (such as non-architected L2 cache etc.) which are not integrated into the the CPU. If we allow D-cache to be turned on at all, we would have to be clear that external caches must be turned off or configured in a very precise way in order to avoid breaking the kernel's bootstrap process. This is especially important when assumptions about the cache arrangement are not fixed at build time (in the device tree context, such assumptions generally won't be completely fixed). There's a potential world of problems here--- it seems best avoided. It could be worth clarifying that the L1 I-cache is the _only_ cache which is permitted to be enabled at kernel entry, and that all other caches in the system must be disabled. Catalin said that on some platforms, the L2 cache is unavoidably enabled by the time of kernel boot and it cannot be turned off. So the above cannot be satisfied. -- Jamie ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
