On Tue, Jun 06, 2017 at 09:19:04PM +, Chris Packham wrote:
> "mvebu" is the current trend for this family of orion/kirkwood/armada
> SoCs. I can take mv64x60_edac.c and gut it to use as a base.
s/gut it/copy stuff for your own use in your *separate* driver/
Let's leave mv64x60_edac.c alone.
On 07/06/17 04:55, Borislav Petkov wrote:
> On Tue, Jun 06, 2017 at 03:07:04AM +, Chris Packham wrote:
>> I'll wait for feedback before sending a v2.
>
> You can't be expecting me to review PPC code reliably. :-)
Yeah sorry I should have included linuxppc-dev. Will do on v2.
I don't think th
On Tue, Jun 06, 2017 at 03:07:04AM +, Chris Packham wrote:
> I'll wait for feedback before sending a v2.
You can't be expecting me to review PPC code reliably. :-)
AFAIR from the recent discussion, Michael said that the aim is to remove
CONFIG_MV64X60 and since this driver depends on it, that
On 06/06/17 14:41, Chris Packham wrote:
> The #address-cells and #size-cells properties need to be accounted for
> when dealing with the "memory" device tree node.
>
> Signed-off-by: Chris Packham
> ---
> drivers/edac/mv64x60_edac.c | 30 +-
> 1 file changed, 21 ins
The #address-cells and #size-cells properties need to be accounted for
when dealing with the "memory" device tree node.
Signed-off-by: Chris Packham
---
drivers/edac/mv64x60_edac.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/edac/mv
5 matches
Mail list logo