From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751976AbdKHK1A (ORCPT ); Wed, 8 Nov 2017 05:27:00 -0500 Received: from mail-oi0-f66.google.com ([209.85.218.66]:49705 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751141AbdKHK0i (ORCPT ); Wed, 8 Nov 2017 05:26:38 -0500 X-Google-Smtp-Source: ABhQp+Rk6O9VouNKz31zsyawcef4LqD6kyfD2uQHFMluCW2hbn3q48BszW0c9ihy0vwqVwW2fTnjsAOUqpu8buRBvLI= MIME-Version: 1.0 In-Reply-To: References: From: Arnd Bergmann Date: Wed, 8 Nov 2017 11:26:37 +0100 X-Google-Sender-Auth: fpuFOtDjeWcEaWHRl_0JGQ-ZuyE Message-ID: Subject: Re: [PATCH 00/31] Andes(nds32) Linux Kernel Port To: Greentime Hu Cc: Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 8, 2017 at 6:54 AM, Greentime Hu wrote: > This patchset adds core architecture support to Linux for Andestech's > N13, N15, D15, N10, D10 processor cores. > > Based on the 16/32-bit AndeStar RISC-like architecture, we designed the > configurable AndesCore series of embedded processor families. AndesCores > range from highly performance-efficient small-footprint cores for > microcontrollers and deeply-embedded applications to 1GHz+ cores running > Linux, covering general-purpose N-series cores for a wide range of computing > need, DSP-capable D-series cores for digital signal control, > instruction-extensible E-series cores for application-specific acceleration, > and secure S-series cores for best protection of the most valuable. I looked at the entire patch series now and commented on anything I noticed that could be improved, overall this looks very nice, great work! Most of my comments are about tiny details that are easy to address. I see two areas that need to be looked at carefully, and that may take a few more rounds to get right: - In the user space ABI, you have a couple of things that differ from the normal asm-generic definitions, i.e. s few syscall entry points and some types in asm/posix-types.h. I guess you did that to remain compatible with an older glibc port, but IMHO this compatibility should be broken in favor of having the standard ABI before the port gets merged. - For the boot interface, you need to clearly define what can be expected and what cannot. This involves the presence of the l2cc, the physical memory address, the built-in dtb, and probably a few more things I missed. For long-term maintainability, you probably want to ensure that you can build a kernel that runs on as much diverse hardware as possible. Arnd