All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sudeep Dutt <sudeep.dutt@intel.com>
Cc: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>,
	"Yaozu (Eddie) Dong" <eddie.dong@intel.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Ashutosh Dixit <ashutosh.dixit@intel.com>,
	Rob Landley <rob@landley.net>,
	Caz Yokoyama <Caz.Yokoyama@intel.com>,
	Dasaratharaman Chandramouli
	<dasaratharaman.chandramouli@intel.com>
Subject: Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
Date: Fri, 6 Sep 2013 12:04:46 -0700	[thread overview]
Message-ID: <20130906190446.GA7965@kroah.com> (raw)
In-Reply-To: <1378492863.107744.69.camel@localhost>

On Fri, Sep 06, 2013 at 11:41:03AM -0700, Sudeep Dutt wrote:
> On Thu, 2013-09-05 at 22:01 -0700, Greg Kroah-Hartman wrote:
> > On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote:
> > > +What:		/sys/class/mic/mic(x)/firmware
> > > +Date:		August 2013
> > > +KernelVersion:	3.11
> > > +Contact:	Sudeep Dutt <sudeep.dutt@intel.com>
> > > +Description:
> > > +		When read, this sysfs entry provides the path name under
> > > +		/lib/firmware/ where the firmware image to be booted on the
> > > +		card can be found. The entry can be written to change the
> > > +		firmware image location under /lib/firmware/.
> > 
> > I don't understand, is the path under the HOST device, or the Client
> > device's disk?  Why do you need to change the path on the HOST?  What's
> > wrong with the existing firmware path selection we have in the kernel?
> > 
> 
> The path is on the host. The card does not have a physical persistent
> disk device. Our customers like the flexibility of changing the card
> firmware/ramdisk contents and file names for individual MIC cards. This
> flexibility is not possible with a static set of firmware file names in
> the kernel for all cards.
> 
> Once the firmware/ramdisk path under /lib/firmware/ is set up via sysfs,
> card boot is initiated via the "state" sysfs entry. The host driver then
> obtains the contents of the firmware and ramdisk via the standard
> request_firmware(..) interface, copies the contents to card memory and
> interrupts the card BIOS to initiate boot.

So this is really a "filename" that might contain some directories as
well, right?  The fact you used "path" confused me, as that doesn't
usually imply a filename.

And is the "firmware" just the initramfs image for the kernel to boot?

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sudeep Dutt <sudeep.dutt@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Rusty Russell <rusty@rustcorp.com.au>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Rob Landley <rob@landley.net>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-doc@vger.kernel.org, Asias He <asias@redhat.com>,
	Nikhil Rao <nikhil.rao@intel.com>,
	Ashutosh Dixit <ashutosh.dixit@intel.com>,
	Caz Yokoyama <Caz.Yokoyama@intel.com>,
	Dasaratharaman Chandramouli 
	<dasaratharaman.chandramouli@intel.com>,
	Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>,
	"Yaozu (Eddie) Dong" <eddie.dong@intel.com>,
	Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Subject: Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
Date: Fri, 6 Sep 2013 12:04:46 -0700	[thread overview]
Message-ID: <20130906190446.GA7965@kroah.com> (raw)
In-Reply-To: <1378492863.107744.69.camel@localhost>

On Fri, Sep 06, 2013 at 11:41:03AM -0700, Sudeep Dutt wrote:
> On Thu, 2013-09-05 at 22:01 -0700, Greg Kroah-Hartman wrote:
> > On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote:
> > > +What:		/sys/class/mic/mic(x)/firmware
> > > +Date:		August 2013
> > > +KernelVersion:	3.11
> > > +Contact:	Sudeep Dutt <sudeep.dutt@intel.com>
> > > +Description:
> > > +		When read, this sysfs entry provides the path name under
> > > +		/lib/firmware/ where the firmware image to be booted on the
> > > +		card can be found. The entry can be written to change the
> > > +		firmware image location under /lib/firmware/.
> > 
> > I don't understand, is the path under the HOST device, or the Client
> > device's disk?  Why do you need to change the path on the HOST?  What's
> > wrong with the existing firmware path selection we have in the kernel?
> > 
> 
> The path is on the host. The card does not have a physical persistent
> disk device. Our customers like the flexibility of changing the card
> firmware/ramdisk contents and file names for individual MIC cards. This
> flexibility is not possible with a static set of firmware file names in
> the kernel for all cards.
> 
> Once the firmware/ramdisk path under /lib/firmware/ is set up via sysfs,
> card boot is initiated via the "state" sysfs entry. The host driver then
> obtains the contents of the firmware and ramdisk via the standard
> request_firmware(..) interface, copies the contents to card memory and
> interrupts the card BIOS to initiate boot.

So this is really a "filename" that might contain some directories as
well, right?  The fact you used "path" confused me, as that doesn't
usually imply a filename.

And is the "firmware" just the initramfs image for the kernel to boot?

thanks,

greg k-h

  reply	other threads:[~2013-09-06 19:04 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-05 23:41 [PATCH RESEND v3 0/7] Enable Drivers for Intel MIC X100 Coprocessors Sudeep Dutt
2013-09-05 23:41 ` Sudeep Dutt
2013-09-05 23:41 ` [PATCH RESEND v3 1/7] Intel MIC Host Driver for X100 family Sudeep Dutt
2013-09-05 23:41   ` Sudeep Dutt
2013-09-06  4:55   ` Greg Kroah-Hartman
2013-09-06  4:55     ` Greg Kroah-Hartman
2013-09-06  4:57   ` Greg Kroah-Hartman
2013-09-06  4:57   ` Greg Kroah-Hartman
2013-09-05 23:41 ` [PATCH RESEND v3 2/7] Intel MIC Host Driver Interrupt/SMPT support Sudeep Dutt
2013-09-05 23:41 ` Sudeep Dutt
2013-09-05 23:41 ` [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management Sudeep Dutt
2013-09-05 23:41   ` Sudeep Dutt
2013-09-06  4:58   ` Greg Kroah-Hartman
2013-09-06  4:58     ` Greg Kroah-Hartman
2013-09-06 18:29     ` Sudeep Dutt
2013-09-06 18:29       ` Sudeep Dutt
2013-09-06 18:41       ` Greg Kroah-Hartman
2013-09-06 18:41         ` Greg Kroah-Hartman
2013-09-06  5:00   ` Greg Kroah-Hartman
2013-09-06  5:00     ` Greg Kroah-Hartman
2013-09-06 18:30     ` Sudeep Dutt
2013-09-06 18:30     ` Sudeep Dutt
2013-09-06  5:01   ` Greg Kroah-Hartman
2013-09-06  5:01     ` Greg Kroah-Hartman
2013-09-06 18:41     ` Sudeep Dutt
2013-09-06 18:41       ` Sudeep Dutt
2013-09-06 19:04       ` Greg Kroah-Hartman [this message]
2013-09-06 19:04         ` Greg Kroah-Hartman
2013-09-06 22:00         ` Sudeep Dutt
2013-09-06 22:00         ` Sudeep Dutt
2013-09-05 23:42 ` [PATCH RESEND v3 4/7] Intel MIC Card Driver for X100 family Sudeep Dutt
2013-09-05 23:42   ` Sudeep Dutt
2013-09-05 23:42 ` [PATCH RESEND v3 5/7] Intel MIC Host Driver Changes for Virtio Devices Sudeep Dutt
2013-09-05 23:42 ` Sudeep Dutt
2013-09-05 23:42 ` [PATCH RESEND v3 6/7] Intel MIC Card " Sudeep Dutt
2013-09-05 23:42   ` Sudeep Dutt
2013-09-05 23:42 ` [PATCH RESEND v3 7/7] Sample Implementation of Intel MIC User Space Daemon Sudeep Dutt
2013-09-05 23:42   ` Sudeep Dutt
2013-09-06  1:36 ` [PATCH RESEND v3 0/7] Enable Drivers for Intel MIC X100 Coprocessors Joe Perches
2013-09-06 18:27   ` Sudeep Dutt
2013-09-06 18:27     ` Sudeep Dutt
2013-09-26 20:54   ` Greg Kroah-Hartman
2013-09-26 20:54     ` Greg Kroah-Hartman
2013-09-26 21:33     ` Joe Perches
2013-09-26 21:40       ` Sudeep Dutt
2013-09-26 21:40         ` Sudeep Dutt
2013-09-26 21:33     ` Joe Perches
2013-09-06  1:36 ` Joe Perches
2013-09-26 20:53 ` Greg Kroah-Hartman
2013-09-26 20:53   ` Greg Kroah-Hartman

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=20130906190446.GA7965@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Caz.Yokoyama@intel.com \
    --cc=arnd@arndb.de \
    --cc=ashutosh.dixit@intel.com \
    --cc=dasaratharaman.chandramouli@intel.com \
    --cc=eddie.dong@intel.com \
    --cc=harshavardhan.r.kharche@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=peter.p.waskiewicz.jr@intel.com \
    --cc=rob@landley.net \
    --cc=sudeep.dutt@intel.com \
    --cc=virtualization@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.