[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160517142735.GA19617@kroah.com>
Date: Tue, 17 May 2016 07:27:35 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Jes Sorensen <Jes.Sorensen@...hat.com>
Cc: David Kershner <david.kershner@...sys.com>, corbet@....net,
tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
erik.arfvidson@...sys.com, timothy.sell@...sys.com,
hofrat@...dl.org, dzickus@...hat.com, alexander.curtin@...sys.com,
janani.rvchndrn@...il.com, sudipm.mukherjee@...il.com,
prarit@...hat.com, david.binder@...sys.com, nhorman@...hat.com,
dan.j.williams@...el.com, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, driverdev-devel@...uxdriverproject.org,
sparmaintainer@...sys.com
Subject: Re: [PATCH 0/5] add bus driver for Unisys s-Par paravirtualized
devices to arch/x86
On Tue, May 17, 2016 at 10:01:55AM -0400, Jes Sorensen wrote:
> Greg KH <gregkh@...uxfoundation.org> writes:
> > On Tue, May 17, 2016 at 03:27:56AM -0400, David Kershner wrote:
> >> This patchset moves the visorbus driver (fromdrivers/staging/unisys/visorbus)
> >> and its dependent headers files (from drivers/staging/unisys/include)
> >> out of staging into the main kernel tree.
> >>
> >> The visorbus driver is a bus driver for various paravirtualized devices
> >> presented within a Unisys s-Par guest environment. Drivers for these
> >> devices are also currently present under drivers/staging/unisys/, which we
> >> intend to also move out of staging immediately after visorbus. All of
> >> these other drivers are dependent upon visorbus and the include directory,
> >> which is why we would like to move these first.
> >>
> >> Our initial consultations with various members of the community have led us
> >> to the conclusion that the most appropriate locations for these is:
> >> arch/x86/visorbus/ (driver)
> >> include/linux/visorbus/ (header files)
> >>
> >> The rationale is that visorbus is dependent on x86-64 architecture.
> >
> > What makes it dependent on x86? What prevents it from running on some
> > other architecture (not the fact that no one has made such hardware,
> > just the code reasons please.)
>
> It's dependent on system firmware which is only available on the S-Par
> platform which is x86_64 only. The closest similarity is probably what
> you find on the PPC and Sparc platforms.
Ok, but still no need to put it under arch/ anything, it should go in
drivers/ like all other drivers and busses are, no matter what the arch
it happens to run on is.
thanks,
greg k-h
Powered by blists - more mailing lists