public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: hauke@hauke-m•de (Hauke Mehrtens)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
Date: Thu, 25 Jul 2013 22:33:46 +0200	[thread overview]
Message-ID: <51F18BAA.1050806@hauke-m.de> (raw)
In-Reply-To: <20130724225443.GA29801@glitch>

On 07/25/2013 12:54 AM, Domenico Andreoli wrote:
> On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote:
>> On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
>>> On Wednesday, July 24, 2013, Hauke Mehrtens <hauke@hauke-m•de
>>> <mailto:hauke@hauke-m•de>> wrote:
>>>> On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
>>>>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
>>>>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig
>>> b/arch/arm/mach-bcm53xx/Kconfig
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..1e16e87
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>>>>>>>> @@ -0,0 +1,10 @@
>>>>>>>> +config ARCH_BCM53XX
>>>>>>>> +  bool "Broadcom BCM47XX / BCM53XX ARM SoC"
>>>>>>>
>>>>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx
>>>>>>> SoCs. This doesn't sound really easy to follow.
>>>>>
>>>>> At the time of the BCM281XX merge we considered that such directories
>>> would
>>>>> mostly contain board files only, being these new entries DT based. Hence
>>>>> the choice of mach-bcm to collect all of them.
>>>>>
>>>>> I think you should then put this stuff there.
>>>>
>>>> So you think I should move the file from
>>>> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
>>>
>>> yes
>>>
>>> this looks more comsistent with the actual soc name:
>>> arch/arm/mach-bcm/bcm530xx.c
>>>
>>> but I find also acceptable the complete name of the "parent" soc (as I'm
>>> doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c
>>
>> I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
>> have more in common than the vendor name, so I do not think it is a good
>> idea to place them all at mach-bcm.
> 
> In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever
> two or more SoCs share can hopefully modelled in a driver and as such
> would go in the drivers/ subtree. What's left is really SoC specific and,
> again hopefully, very minimal.
> 
> There should not be any SoC so weird to require a whole subdirectory full
> of that SoC specific stuff. So grouping everything by vendor name looks
> quite appealing to me.
> 
> Sharing the same subdir requires people working in it to talk and find
> agreements some more than the sparsely populated subdir did (because there
> is not a single maintainer who owns it). I think this is a big advantage
> Broadcomers can start with right now.

I want to be able to build the BCM5301X SoC without building the current
CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ?

My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom
submenu, but not build any code. Then the list of Broadcom SoCs is
opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM.

Hauke

  reply	other threads:[~2013-07-25 20:33 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-16 13:52 [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU Hauke Mehrtens
2013-07-16 15:14 ` Matt Porter
2013-07-16 15:39   ` Hauke Mehrtens
2013-07-16 18:13     ` Hauke Mehrtens
2013-07-16 23:52       ` Matt Porter
2013-07-16 23:44     ` Matt Porter
2013-07-16 23:08   ` Florian Fainelli
2013-07-16 23:42     ` Matt Porter
2013-07-19  2:06     ` Domenico Andreoli
2013-07-23 18:57       ` Matt Porter
2013-07-23 19:05         ` Florian Fainelli
2013-07-24 23:11           ` Domenico Andreoli
     [not found]             ` <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
2013-07-26  0:04               ` Matt Porter
2013-07-26 22:16                 ` Christian Daudt
2013-07-26 22:29                   ` Domenico Andreoli
2013-07-26 22:30                   ` Stephen Warren
2013-07-29  9:30                     ` Mark Rutland
2013-07-29 13:20                       ` Matt Porter
2013-07-29 17:06                         ` Stephen Warren
2013-07-30 23:08                           ` Christian Daudt
2013-07-23 18:49     ` Matt Porter
2013-07-23 18:56       ` Florian Fainelli
2013-07-23 19:14         ` Arend van Spriel
2013-07-23 19:22         ` Matt Porter
2013-07-24  0:10           ` Christian Daudt
     [not found]             ` <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
2013-07-24 19:21               ` Hauke Mehrtens
2013-07-24 22:54                 ` Domenico Andreoli
2013-07-25 20:33                   ` Hauke Mehrtens [this message]
2013-07-25 21:37                     ` Christian Daudt
2013-07-25 21:58                       ` Domenico Andreoli
2013-07-19 13:03   ` Arnd Bergmann
2013-07-16 15:20 ` Thomas Petazzoni
2013-07-16 15:35   ` Hauke Mehrtens
2013-07-19  1:36     ` Domenico Andreoli
2013-07-23 22:10       ` Hauke Mehrtens
2013-07-16 23:19   ` Russell King - ARM Linux
2013-07-19  2:23 ` Domenico Andreoli
2013-07-23 21:54   ` Hauke Mehrtens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51F18BAA.1050806@hauke-m.de \
    --to=hauke@hauke-m$(echo .)de \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox