lkml.org 
[lkml]   [2014]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/7] MIPS: Move device-tree files to a common location
    On 08/27/2014 11:30 AM, Andrew Bresticker wrote:
    > On Mon, Aug 25, 2014 at 8:17 AM, Jonas Gorski <jogo@openwrt.org> wrote:
    >> On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
    >> <geert@linux-m68k.org> wrote:
    >>> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof@lixom.net> wrote:
    >>>>>> arch/arm/boot/dts/<vendor>/
    >>>>>>
    >>>>>> Is this something we should do for the MIPS and update the other architectures
    >>>>>> to follow that scheme?
    >>>>>
    >>>>> I recall reading that as well and that it would be adopted for ARM64,
    >>>>> but that hasn't seemed to have happened. Perhaps Olof (CC'ed) will no
    >>>>> more.
    >>>>
    >>>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
    >>>> and the amount of files in that directory is becoming pretty
    >>>> insane. Moving to a subdirectory structure later gets messy which is
    >>>> why we've been holding off on it.
    >>>
    >>> It would mean we can change our scripts to operate on "interesting"
    >>> DTS files from
    >>>
    >>> do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
    >>>
    >>> to
    >>>
    >>> do-something-with arch/arm/boot/dts/$vendor/*
    >>>
    >>> which is easier to type...
    >>
    >> Btw, do you mean chip-vendor or device-vendor with vendor?
    >> Device-vendor could get a bit messy on the source part as the router
    >> manufacturers tend to switch them quite often. E.g. d-link used arm,
    >> mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
    >> and ralink for their dir-615 router, happily switching back and forth.
    >> There are 14 known different hardware revisions of it where the chip
    >> differed from the previous one.
    >
    > I'm going to assume it means chip/SoC vendor. That would result in
    > the following structure (I think):
    >
    > Octeon -> cavium/

    To match the state of the art naming we have in other MIPS related
    directories, it should probably be "cavium-octeon/" (See
    arch/mips/cavium-octeon, and arch/mips/include/asm/mach-cavium-octeon)

    David Daney


    \
     
     \ /
      Last update: 2014-08-27 21:41    [W:4.744 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site