linux-sh.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
Date: Wed, 13 Nov 2013 02:50:10 +0000	[thread overview]
Message-ID: <1586355.IPva4G58Xv@avalon> (raw)
In-Reply-To: <1383782061-7111-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Hi,

On Tuesday 12 November 2013 11:30:22 Simon Horman wrote:
> On Mon, Nov 11, 2013 at 09:45:12AM +0000, phil.edworthy@renesas.com wrote:
> > > On Friday 08 November 2013 14:57:29 stephen.lawrence@renesas.com wrote:
> > > > linux-sh-owner@vger.kernel.org wrote on 08/11/2013 06:08:05:
> > > > > On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> > > > > > On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart wrote:
> > > > > > > SH-Mobile platforms are transitioning from non-multiplatform to
> > > > > > > multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration
> > > > > > > symbol has been created to group all multiplatform-enabled SH-
> > > > > > > Mobile SoCs.
> > > > > > >
> > > > > > > The existing ARCH_SHMOBILE configuration symbol groups SoCs
> > > > > > > that haven't been converted yet.
> > > > 
> > > > I'm sure there are reasons for keeping it but looking forward I can't
> > > > help but wonder if this wouldn't be a good time to lose the SHMOBILE
> > > > tag for new platforms? It doesn't seem to be a great match to our
> > > > business or the architectures.
> > > > 
> > > > I know from conversations I've had in the last year or so that
> > > > external engineers working on R-Car sometimes do not find your good
> > > > work upstream as the combination of sh-mobile and using the product
> > > > number proved an effective method of concealment. Although of course
> > > > they could find it by searching the right files.
> > > 
> > > It's not a bad idea, but I'm not sure how we could proceed. SH-Mobile,
> > > R-Mobile and R-Car chipsets are all supported by a single code base, for
> > > which we need a name. Splitting the code base wouldn't make much sense
> > > from a technical point of view.
> > 
> > True, but it would be helpful to have Renesas in the device name
> > somewhere. Maybe include Renesas in the mach-shmobile/Kconfig description
> > for the devices, and also update the description in arm/Kconfig to
> > include R-Car.
> 
> Hi,
> 
> I have been involved in several discussions relating to moving away from
> the shmobile name.
> 
> Prior to this thread the most recent discussion I was involved in was with
> Olof Johansson, ARM-SoC co-maintainer, and Magnus. Due to the amount of
> churn involved in changing the name of the mach-shmobile directory or
> somehow splitting the code between multiple mach- directories, which was
> the variant of the topic under discussion, the consensus was that moving
> things around was not on the cards at this time.  There is also, as Laurent
> mentioned, the technical issue that splitting the code doesn't make a whole
> lot of sense from an implementation point of view.
> 
> From my point of view changing the SHMOBILE potion of ARCH_SHMOBILE_*
> only really makes sense if the name of mach-shmobile directory is changed
> in a similar way, which as I mentioned above that seems to be off the cards
> at this time. The reason I think this is that if the ARCH_XXX name doesn't
> match the directory we will add confusion rather than removing it.
> 
> With the above in mind I think that Phil's proposal to enhance the
> descriptions in mach-shmobile/Kconfig and arm/Kconfig is an excellent one
> given the hand of cards we have available to play.

Is someone going to submit a patch or should I do it ?

-- 
Regards,

Laurent Pinchart


  parent reply	other threads:[~2013-11-13  2:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06 23:54 [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Laurent Pinchart
2013-11-07  6:04 ` Magnus Damm
2013-11-07 13:35   ` Laurent Pinchart
2013-11-08  6:08   ` Simon Horman
2013-11-09 12:34     ` Laurent Pinchart
2013-11-12  2:30       ` Simon Horman
2013-11-08 14:57 ` stephen.lawrence
2013-11-09 12:39 ` Laurent Pinchart
2013-11-11  9:45 ` phil.edworthy
2013-11-12  2:30 ` Simon Horman
2013-11-13  2:50 ` Laurent Pinchart [this message]
2013-11-13 13:47 ` phil.edworthy
2013-11-14 12:04 ` stephen.lawrence

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=1586355.IPva4G58Xv@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=linux-sh@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).