Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Fri, 2013-09-06 at 12:04 -0700, Greg Kroah-Hartman wrote: > 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 > > > > +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. > Yes, it is a filename that might contain some directories. We will fix up the documentation here to read filename in future patches. > And is the "firmware" just the initramfs image for the kernel to boot? > The firmware is usually a Linux kernel. The ramdisk is usually an initramfs image. We have separate sysfs entries for firmware and ramdisk filenames. Thanks, Sudeep Dutt > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
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 > > > +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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
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 > > +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. Thanks, Sudeep Dutt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Fri, Sep 06, 2013 at 11:29:17AM -0700, Sudeep Dutt wrote: > On Thu, 2013-09-05 at 21:58 -0700, Greg Kroah-Hartman wrote: > > Again, very minor fixups for later (I can even do them...) > > > > > +static DEVICE_ATTR(state, S_IRUGO|S_IWUSR, mic_show_state, > > > mic_store_state); > > > > DEVICE_ATTR_RW() please. > > > > Same for the other attributes you create in this patch. > > > > Sure, we will incorporate these changes along with your other feedback > in patch 1 and post the next revision of this patch series. There's no need to repost just yet. I can take these as-is after the merge window closes, and you can send follow-on patches for these minor issues, keeping you from having to do a respin, and me trying to remember what parts I reviewed and didn't review. So give me some time (i.e. wait for after 3.12-rc1 is out) and if I have further problems with the patches, I'll let you know, otherwise you'll get an automated email from my patch collection system saying the patches are applied. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Thu, 2013-09-05 at 21:58 -0700, Greg Kroah-Hartman wrote: > Again, very minor fixups for later (I can even do them...) > > > +static DEVICE_ATTR(state, S_IRUGO|S_IWUSR, mic_show_state, > > mic_store_state); > > DEVICE_ATTR_RW() please. > > Same for the other attributes you create in this patch. > Sure, we will incorporate these changes along with your other feedback in patch 1 and post the next revision of this patch series. Thanks for the review! Sudeep Dutt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Thu, 2013-09-05 at 22:00 -0700, Greg Kroah-Hartman wrote: > On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote: > > +What: /sys/class/mic/mic(x)/cmdline > > +Date: August 2013 > > +KernelVersion: 3.11 > > +Contact: Sudeep Dutt > > +Description: > > + An Intel MIC device runs a Linux OS during its operation. Before > > + booting this card OS, it is possible to pass kernel command line > > + options to configure various features in it, similar to > > + self-bootable machines. When read, this entry provides > > + information about the current kernel command line options set to > > + boot the card OS. This entry can be written to change the > > + existing kernel command line options. Typically, the user would > > + want to read the current command line options, append new ones > > + or modify existing ones and then write the whole kernel command > > + line back to this entry. > > Is a PAGE_SIZE value going to be big enough for your command line? I > know some embedded systems have horribly long command lines, hopefully > this will be enough for you. > Yes, PAGE_SIZE is more than sufficient for our command line. Thanks, Sudeep Dutt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Thu, 2013-09-05 at 22:00 -0700, Greg Kroah-Hartman wrote: On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote: +What: /sys/class/mic/mic(x)/cmdline +Date: August 2013 +KernelVersion: 3.11 +Contact: Sudeep Dutt sudeep.d...@intel.com +Description: + An Intel MIC device runs a Linux OS during its operation. Before + booting this card OS, it is possible to pass kernel command line + options to configure various features in it, similar to + self-bootable machines. When read, this entry provides + information about the current kernel command line options set to + boot the card OS. This entry can be written to change the + existing kernel command line options. Typically, the user would + want to read the current command line options, append new ones + or modify existing ones and then write the whole kernel command + line back to this entry. Is a PAGE_SIZE value going to be big enough for your command line? I know some embedded systems have horribly long command lines, hopefully this will be enough for you. Yes, PAGE_SIZE is more than sufficient for our command line. Thanks, Sudeep Dutt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Thu, 2013-09-05 at 21:58 -0700, Greg Kroah-Hartman wrote: Again, very minor fixups for later (I can even do them...) +static DEVICE_ATTR(state, S_IRUGO|S_IWUSR, mic_show_state, mic_store_state); DEVICE_ATTR_RW() please. Same for the other attributes you create in this patch. Sure, we will incorporate these changes along with your other feedback in patch 1 and post the next revision of this patch series. Thanks for the review! Sudeep Dutt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Fri, Sep 06, 2013 at 11:29:17AM -0700, Sudeep Dutt wrote: On Thu, 2013-09-05 at 21:58 -0700, Greg Kroah-Hartman wrote: Again, very minor fixups for later (I can even do them...) +static DEVICE_ATTR(state, S_IRUGO|S_IWUSR, mic_show_state, mic_store_state); DEVICE_ATTR_RW() please. Same for the other attributes you create in this patch. Sure, we will incorporate these changes along with your other feedback in patch 1 and post the next revision of this patch series. There's no need to repost just yet. I can take these as-is after the merge window closes, and you can send follow-on patches for these minor issues, keeping you from having to do a respin, and me trying to remember what parts I reviewed and didn't review. So give me some time (i.e. wait for after 3.12-rc1 is out) and if I have further problems with the patches, I'll let you know, otherwise you'll get an automated email from my patch collection system saying the patches are applied. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
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.d...@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. Thanks, Sudeep Dutt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
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.d...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Fri, 2013-09-06 at 12:04 -0700, Greg Kroah-Hartman wrote: 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.d...@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. Yes, it is a filename that might contain some directories. We will fix up the documentation here to read filename in future patches. And is the firmware just the initramfs image for the kernel to boot? The firmware is usually a Linux kernel. The ramdisk is usually an initramfs image. We have separate sysfs entries for firmware and ramdisk filenames. Thanks, Sudeep Dutt thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
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 > +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? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote: > +What:/sys/class/mic/mic(x)/cmdline > +Date:August 2013 > +KernelVersion: 3.11 > +Contact: Sudeep Dutt > +Description: > + An Intel MIC device runs a Linux OS during its operation. Before > + booting this card OS, it is possible to pass kernel command line > + options to configure various features in it, similar to > + self-bootable machines. When read, this entry provides > + information about the current kernel command line options set to > + boot the card OS. This entry can be written to change the > + existing kernel command line options. Typically, the user would > + want to read the current command line options, append new ones > + or modify existing ones and then write the whole kernel command > + line back to this entry. Is a PAGE_SIZE value going to be big enough for your command line? I know some embedded systems have horribly long command lines, hopefully this will be enough for you. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
Again, very minor fixups for later (I can even do them...) > +static DEVICE_ATTR(state, S_IRUGO|S_IWUSR, mic_show_state, mic_store_state); DEVICE_ATTR_RW() please. Same for the other attributes you create in this patch. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
This patch enables the following features: a) Boots and shuts down the card via sysfs entries. b) Allocates and maps a device page for communication with the card driver and updates the device page address via scratchpad registers. c) Provides sysfs entries for shutdown status, kernel command line, ramdisk and log buffer information. Co-author: Dasaratharaman Chandramouli Signed-off-by: Ashutosh Dixit Signed-off-by: Caz Yokoyama Signed-off-by: Dasaratharaman Chandramouli Signed-off-by: Harshavardhan R Kharche Signed-off-by: Nikhil Rao Signed-off-by: Sudeep Dutt Acked-by: Yaozu (Eddie) Dong Reviewed-by: Peter P Waskiewicz Jr --- Documentation/ABI/testing/sysfs-class-mic.txt | 113 drivers/misc/mic/common/mic_device.h | 7 + drivers/misc/mic/host/Makefile| 2 + drivers/misc/mic/host/mic_boot.c | 184 + drivers/misc/mic/host/mic_debugfs.c | 355 + drivers/misc/mic/host/mic_device.h| 60 + drivers/misc/mic/host/mic_main.c | 129 - drivers/misc/mic/host/mic_sysfs.c | 369 ++ drivers/misc/mic/host/mic_x100.c | 251 ++ drivers/misc/mic/host/mic_x100.h | 12 + include/uapi/linux/Kbuild | 1 + include/uapi/linux/mic_common.h | 74 ++ 12 files changed, 1553 insertions(+), 4 deletions(-) create mode 100644 drivers/misc/mic/host/mic_boot.c create mode 100644 drivers/misc/mic/host/mic_debugfs.c create mode 100644 include/uapi/linux/mic_common.h diff --git a/Documentation/ABI/testing/sysfs-class-mic.txt b/Documentation/ABI/testing/sysfs-class-mic.txt index 09eb3c6..82cdad3 100644 --- a/Documentation/ABI/testing/sysfs-class-mic.txt +++ b/Documentation/ABI/testing/sysfs-class-mic.txt @@ -32,3 +32,116 @@ Contact:Sudeep Dutt Description: Provides information about the silicon stepping for an Intel MIC device. For example - "A0" or "B0" + +What: /sys/class/mic/mic(x)/state +Date: August 2013 +KernelVersion: 3.11 +Contact: Sudeep Dutt +Description: + When read, this entry provides the current state of an Intel + MIC device in the context of the card OS. Possible values that + will be read are: + "offline" - The MIC device is ready to boot the card OS. + "online" - The MIC device has initiated booting a card OS. + "shutting_down" - The card OS is shutting down. + "reset_failed" - The MIC device has failed to reset. + + When written, this sysfs entry triggers different state change + operations depending upon the current state of the card OS. + Acceptable values are: + "boot" - Boot the card OS image specified by the combination +of firmware, ramdisk, cmdline and bootmode + sysfs entries. + "reset" - Initiates device reset. + "shutdown" - Initiates card OS shutdown. + +What: /sys/class/mic/mic(x)/shutdown_status +Date: August 2013 +KernelVersion: 3.11 +Contact: Sudeep Dutt +Description: + An Intel MIC device runs a Linux OS during its operation. This + OS can shutdown because of various reasons. When read, this + entry provides the status on why the card OS was shutdown. + Possible values are: + "nop" - shutdown status is not applicable, when the card OS is + "online" + "crashed" - Shutdown because of a HW or SW crash. + "halted" - Shutdown because of a halt command. + "poweroff" - Shutdown because of a poweroff command. + "restart" - Shutdown because of a restart command. + +What: /sys/class/mic/mic(x)/cmdline +Date: August 2013 +KernelVersion: 3.11 +Contact: Sudeep Dutt +Description: + An Intel MIC device runs a Linux OS during its operation. Before + booting this card OS, it is possible to pass kernel command line + options to configure various features in it, similar to + self-bootable machines. When read, this entry provides + information about the current kernel command line options set to + boot the card OS. This entry can be written to change the + existing kernel command line options. Typically, the user would + want to read the current command line options, append new ones + or modify existing ones and then write the whole kernel command + line back to this entry. + +What: /sys/class/mic/mic(x)/firmware +Date: August 2013 +KernelVersion: 3.11 +Contact: Sudeep Dutt +Description: + When
[PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
This patch enables the following features: a) Boots and shuts down the card via sysfs entries. b) Allocates and maps a device page for communication with the card driver and updates the device page address via scratchpad registers. c) Provides sysfs entries for shutdown status, kernel command line, ramdisk and log buffer information. Co-author: Dasaratharaman Chandramouli dasaratharaman.chandramo...@intel.com Signed-off-by: Ashutosh Dixit ashutosh.di...@intel.com Signed-off-by: Caz Yokoyama caz.yokoy...@intel.com Signed-off-by: Dasaratharaman Chandramouli dasaratharaman.chandramo...@intel.com Signed-off-by: Harshavardhan R Kharche harshavardhan.r.khar...@intel.com Signed-off-by: Nikhil Rao nikhil@intel.com Signed-off-by: Sudeep Dutt sudeep.d...@intel.com Acked-by: Yaozu (Eddie) Dong eddie.d...@intel.com Reviewed-by: Peter P Waskiewicz Jr peter.p.waskiewicz...@intel.com --- Documentation/ABI/testing/sysfs-class-mic.txt | 113 drivers/misc/mic/common/mic_device.h | 7 + drivers/misc/mic/host/Makefile| 2 + drivers/misc/mic/host/mic_boot.c | 184 + drivers/misc/mic/host/mic_debugfs.c | 355 + drivers/misc/mic/host/mic_device.h| 60 + drivers/misc/mic/host/mic_main.c | 129 - drivers/misc/mic/host/mic_sysfs.c | 369 ++ drivers/misc/mic/host/mic_x100.c | 251 ++ drivers/misc/mic/host/mic_x100.h | 12 + include/uapi/linux/Kbuild | 1 + include/uapi/linux/mic_common.h | 74 ++ 12 files changed, 1553 insertions(+), 4 deletions(-) create mode 100644 drivers/misc/mic/host/mic_boot.c create mode 100644 drivers/misc/mic/host/mic_debugfs.c create mode 100644 include/uapi/linux/mic_common.h diff --git a/Documentation/ABI/testing/sysfs-class-mic.txt b/Documentation/ABI/testing/sysfs-class-mic.txt index 09eb3c6..82cdad3 100644 --- a/Documentation/ABI/testing/sysfs-class-mic.txt +++ b/Documentation/ABI/testing/sysfs-class-mic.txt @@ -32,3 +32,116 @@ Contact:Sudeep Dutt sudeep.d...@intel.com Description: Provides information about the silicon stepping for an Intel MIC device. For example - A0 or B0 + +What: /sys/class/mic/mic(x)/state +Date: August 2013 +KernelVersion: 3.11 +Contact: Sudeep Dutt sudeep.d...@intel.com +Description: + When read, this entry provides the current state of an Intel + MIC device in the context of the card OS. Possible values that + will be read are: + offline - The MIC device is ready to boot the card OS. + online - The MIC device has initiated booting a card OS. + shutting_down - The card OS is shutting down. + reset_failed - The MIC device has failed to reset. + + When written, this sysfs entry triggers different state change + operations depending upon the current state of the card OS. + Acceptable values are: + boot - Boot the card OS image specified by the combination +of firmware, ramdisk, cmdline and bootmode + sysfs entries. + reset - Initiates device reset. + shutdown - Initiates card OS shutdown. + +What: /sys/class/mic/mic(x)/shutdown_status +Date: August 2013 +KernelVersion: 3.11 +Contact: Sudeep Dutt sudeep.d...@intel.com +Description: + An Intel MIC device runs a Linux OS during its operation. This + OS can shutdown because of various reasons. When read, this + entry provides the status on why the card OS was shutdown. + Possible values are: + nop - shutdown status is not applicable, when the card OS is + online + crashed - Shutdown because of a HW or SW crash. + halted - Shutdown because of a halt command. + poweroff - Shutdown because of a poweroff command. + restart - Shutdown because of a restart command. + +What: /sys/class/mic/mic(x)/cmdline +Date: August 2013 +KernelVersion: 3.11 +Contact: Sudeep Dutt sudeep.d...@intel.com +Description: + An Intel MIC device runs a Linux OS during its operation. Before + booting this card OS, it is possible to pass kernel command line + options to configure various features in it, similar to + self-bootable machines. When read, this entry provides + information about the current kernel command line options set to + boot the card OS. This entry can be written to change the + existing kernel command line options. Typically, the user would + want to read the current command line options,
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
Again, very minor fixups for later (I can even do them...) +static DEVICE_ATTR(state, S_IRUGO|S_IWUSR, mic_show_state, mic_store_state); DEVICE_ATTR_RW() please. Same for the other attributes you create in this patch. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote: +What:/sys/class/mic/mic(x)/cmdline +Date:August 2013 +KernelVersion: 3.11 +Contact: Sudeep Dutt sudeep.d...@intel.com +Description: + An Intel MIC device runs a Linux OS during its operation. Before + booting this card OS, it is possible to pass kernel command line + options to configure various features in it, similar to + self-bootable machines. When read, this entry provides + information about the current kernel command line options set to + boot the card OS. This entry can be written to change the + existing kernel command line options. Typically, the user would + want to read the current command line options, append new ones + or modify existing ones and then write the whole kernel command + line back to this entry. Is a PAGE_SIZE value going to be big enough for your command line? I know some embedded systems have horribly long command lines, hopefully this will be enough for you. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
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.d...@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? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
