[PATCH 2/3] PCI: Allow specifying devices using a base bus and path of devfns
When specifying PCI devices on the kernel command line using a
BDF, the bus numbers can change when adding or replacing a device,
changing motherboard firmware, or applying kernel parameters like
pci=assign-buses. When this happens, it is usually undesirable to
apply whatever command line tweak to the wrong device.
Therefore, it is useful to be able to specify devices with a base
bus number and the path of devfns needed to get to it. (Similar to
the "device scope" structure in the Intel VT-d spec, Section 8.3.1.)
Thus, we add an option to specify devices in the following format:
path:[:]:./.[/ ...]
The path can be any segment within the PCI hierarchy of any length and
determined through the use of 'lspci -t'. When specified this way, it is
less likely that a renumbered bus will result in a valid device specification
and the tweak won't be applied to the wrong device.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Reviewed-by: Stephen Bates <sba...@raithlin.com>
---
Documentation/admin-guide/kernel-parameters.txt | 12 ++-
drivers/pci/pci.c | 106 +++-
2 files changed, 112 insertions(+), 6 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 894aa516ceab..519ab95bb418 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2986,9 +2986,10 @@
Some options herein operate on a specific device
or a set of devices (). These are
- specified in one of two formats:
+ specified in one of three formats:
[:]:.
+
path:[:]:./.[/ ...]
pci::[::]
Note: the first format specifies a PCI
@@ -2996,9 +2997,12 @@
if new hardware is inserted, if motherboard
firmware changes, or due to changes caused
by other kernel parameters. The second format
- selects devices using IDs from the
- configuration space which may match multiple
- devices in the system.
+ specifies a path from a device through
+ a path of multiple slot/function addresses
+ (this is more robust against renumbering
+ issues). The third format selects devices using
+ IDs from the configuration space which may match
+ multiple devices in the system.
earlydump [X86] dump PCI config space before the kernel
changes anything
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 85fec5e2640b..53ea0d7b02ce 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -184,22 +184,116 @@ EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
#endif
/**
+ * pci_dev_str_match_path - test if a path string matches a device
+ * @dev:the PCI device to test
+ * @p: string to match the device against
+ * @endptr: pointer to the string after the match
+ *
+ * Test if a string (typically from a kernel parameter) formated as a
+ * path of slot/function addresses matches a PCI device. The string must
+ * be of the form:
+ *
+ * [:]:./.[/ ...]
+ *
+ * A path for a device can be obtained using 'lspci -t'. Using a path
+ * is more robust against renumbering of devices than using only
+ * a single bus, slot and function address.
+ *
+ * Returns 1 if the string matches the device, 0 if it does not and
+ * a negative error code if it fails to parse the string.
+ */
+static int pci_dev_str_match_path(struct pci_dev *dev, const char *p,
+ const char **endptr)
+{
+ int ret;
+ int seg, bus, slot, func, count;
+ u8 *devfn_path;
+ int num_devfn = 0;
+ struct pci_dev *tmp;
+
+ ret = sscanf(p, "%x:%x:%x.%x%n", , , ,
+, );
+ if (ret != 4) {
+ seg = 0;
+ ret = sscanf(p, "%x:%x.%x%n", , ,
+, );
+ if (ret != 3)
+ return -EINVAL;
+ }
+
+ p += count;
+
+ devfn_path = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ devfn_path[num_devfn++] = PCI_DEVFN(slot, func);
+
+ while (*p && *p != ',' && *p != ';') {
+ ret = sscanf(p, "/%x.%x%n", , , );
+ if (ret != 2) {
+ ret = -EINVAL;
+ goto free_and_exit;
+ }
+
+ p += count;
+ devfn_path[num_devfn++]
[PATCH 0/3] Add parameter for disabling ACS redirection for P2P
Hi, As discussed in our PCI P2PDMA series, we'd like to add a kernel parameter for selectively disabling ACS redirection for select bridges. Seeing this turned out to be a small series in itself, we've decided to send this separately from the P2P work. This series generalizes the code already done for the resource_alignment option that already exists. The first patch creates a helper function to match PCI devices against strings based on the code that already existed in pci_specified_resource_alignment(). The second patch expands the new helper to optionally take a path of PCI devfns. This is to address Alex's renumbering concern when using simple bus-devfns. The implementation is essentially how he described it and similar to the Intel VT-d spec (Section 8.3.1). The final patch adds the disable_acs_redir kernel parameter which takes a list of PCI devices and will disable the ACS P2P Request Redirect, ACS P2P Completion Redirect and ACS P2P Egress Control bits for the selected devices. This allows P2P traffic between selected bridges and seeing it's done at boot, before IOMMU group creating the IOMMU groups will be created correctly based on the bits. Thanks, Logan Logan Gunthorpe (3): PCI: Make specifying PCI devices in kernel parameters reusable PCI: Allow specifying devices using a base bus and path of devfns PCI: Introduce the disable_acs_redir parameter Documentation/admin-guide/kernel-parameters.txt | 39 ++- drivers/pci/pci.c | 358 2 files changed, 336 insertions(+), 61 deletions(-) -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] PCI: Introduce the disable_acs_redir parameter
In order to support P2P traffic on a segment of the PCI hierarchy,
we must be able to disable the ACS redirect bits for select
PCI bridges. The bridges must be selected before the devices are
discovered by the kernel and the IOMMU groups created. Therefore,
a kernel command line parameter is created to specify devices
which must have their ACS bits disabled.
The new parameter takes a list of devices separated by a semicolon.
Each device specified will have it's ACS redirect bits disabled.
This is similar to the existing 'resource_alignment' parameter and just
like it we also create a sysfs bus attribute which can be used to
read the parameter. Writing the parameter is not supported
as it would require forcibly hot plugging the affected device as
well as all devices whose IOMMU groups might change.
The ACS Request P2P Request Redirect, P2P Completion Redirect and P2P
Egress Control bits are disabled which is sufficient to always allow
passing P2P traffic uninterrupted. The bits are set after the kernel
(optionally) enables the ACS bits itself. It is also done regardless of
whether the kernel sets the bits or not seeing some BIOS firmware is known
to set the bits on boot.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Reviewed-by: Stephen Bates <sba...@raithlin.com>
---
Documentation/admin-guide/kernel-parameters.txt | 9 +++
drivers/pci/pci.c | 103 +++-
2 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 519ab95bb418..215285c4772d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3176,6 +3176,15 @@
Adding the window is slightly risky (it may
conflict with unreported devices), so this
taints the kernel.
+ disable_acs_redir=[; ...]
+ Specify one or more PCI devices (in the format
+ specified above) separated by semicolons.
+ Each device specified will have the PCI ACS
+ redirect capabilities forced off which will
+ allow P2P traffic between devices through
+ bridges without forcing it upstream. Note:
+ this removes isolation between devices and
+ will make the IOMMU groups less granular.
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State
Power
Management.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 53ea0d7b02ce..3465895a55ab 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2998,6 +2998,92 @@ void pci_request_acs(void)
pci_acs_enable = 1;
}
+#define DISABLE_ACS_REDIR_PARAM_SIZE COMMAND_LINE_SIZE
+static char disable_acs_redir_param[DISABLE_ACS_REDIR_PARAM_SIZE] = {0};
+static DEFINE_SPINLOCK(disable_acs_redir_lock);
+
+static ssize_t pci_set_disable_acs_redir_param(const char *buf, size_t count)
+{
+ if (count > DISABLE_ACS_REDIR_PARAM_SIZE - 1)
+ count = DISABLE_ACS_REDIR_PARAM_SIZE - 1;
+ spin_lock(_acs_redir_lock);
+ strncpy(disable_acs_redir_param, buf, count);
+ disable_acs_redir_param[count] = '\0';
+ spin_unlock(_acs_redir_lock);
+ return count;
+}
+
+static ssize_t pci_disable_acs_redir_show(struct bus_type *bus, char *buf)
+{
+ size_t count;
+
+ spin_lock(_acs_redir_lock);
+ count = snprintf(buf, PAGE_SIZE, "%s\n", disable_acs_redir_param);
+ spin_unlock(_acs_redir_lock);
+ return count;
+}
+
+static BUS_ATTR(disable_acs_redir, 0444, pci_disable_acs_redir_show, NULL);
+
+static int __init pci_disable_acs_redir_sysfs_init(void)
+{
+ return bus_create_file(_bus_type, _attr_disable_acs_redir);
+}
+late_initcall(pci_disable_acs_redir_sysfs_init);
+
+/**
+ * pci_disable_acs_redir - disable ACS redirect capabilities
+ * @dev: the PCI device
+ *
+ * For only devices specified in the disable_acs_redir parameter.
+ */
+static void pci_disable_acs_redir(struct pci_dev *dev)
+{
+ int ret = 0;
+ const char *p;
+ int pos;
+ u16 ctrl;
+
+ spin_lock(_acs_redir_lock);
+
+ p = disable_acs_redir_param;
+ while (*p) {
+ ret = pci_dev_str_match(dev, p, );
+ if (ret < 0) {
+ pr_info_once("PCI: Can't parse disable_acs_redir
parameter: %s\n",
+disable_acs_redir_param);
+
+ break;
+ } else if (ret == 1) {
+ /* Found a match */
+ break;
+ }
+
+ if (*p != ';' && *p != ',') {
+
[PATCH 1/3] PCI: Make specifying PCI devices in kernel parameters reusable
Separate out the code to match a PCI device with a string (typically
originating from a kernel parameter) from the
pci_specified_resource_alignment() function into its own helper
function.
While we are at it, this change fixes the kernel style of the function
(fixing a number of long lines and extra parentheses).
Additionally, make the analogous change to the kernel parameter
documentation: Separating the description of how to specify a PCI device
into it's own section at the head of the pci= parameter.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Reviewed-by: Stephen Bates <sba...@raithlin.com>
---
Documentation/admin-guide/kernel-parameters.txt | 26 +++-
drivers/pci/pci.c | 153 +++-
2 files changed, 120 insertions(+), 59 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 11fc28ecdb6d..894aa516ceab 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2982,7 +2982,24 @@
See header of drivers/block/paride/pcd.c.
See also Documentation/blockdev/paride.txt.
- pci=option[,option...] [PCI] various PCI subsystem options:
+ pci=option[,option...] [PCI] various PCI subsystem options.
+
+ Some options herein operate on a specific device
+ or a set of devices (). These are
+ specified in one of two formats:
+
+ [:]:.
+ pci::[::]
+
+ Note: the first format specifies a PCI
+ bus/slot/function address which may change
+ if new hardware is inserted, if motherboard
+ firmware changes, or due to changes caused
+ by other kernel parameters. The second format
+ selects devices using IDs from the
+ configuration space which may match multiple
+ devices in the system.
+
earlydump [X86] dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
@@ -3111,11 +3128,10 @@
window. The default value is 64 megabytes.
resource_alignment=
Format:
- [@][:]:.[; ...]
- [@]pci::\
- [::][;
...]
+ [@][; ...]
Specifies alignment and device to reassign
- aligned memory resources.
+ aligned memory resources. How to
+ specify the device is described above.
If is not specified,
PAGE_SIZE is used as alignment.
PCI-PCI bridge can be specified, if resource
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index dbfe7c4f3776..85fec5e2640b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -183,6 +183,88 @@ void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int
bar)
EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
#endif
+/**
+ * pci_dev_str_match - test if a string matches a device
+ * @dev:the PCI device to test
+ * @p: string to match the device against
+ * @endptr: pointer to the string after the match
+ *
+ * Test if a string (typically from a kernel parameter) matches a
+ * specified. The string may be of one of two forms formats:
+ *
+ * [:]:.
+ * pci::[::]
+ *
+ * The first format specifies a PCI bus/slot/function address which
+ * may change if new hardware is inserted, if motherboard firmware changes,
+ * or due to changes caused in kernel parameters.
+ *
+ * The second format matches devices using IDs in the configuration
+ * space which may match multiple devices in the system. A value of 0
+ * for any field will match all devices.
+ *
+ * Returns 1 if the string matches the device, 0 if it does not and
+ * a negative error code if the string cannot be parsed.
+ */
+static int pci_dev_str_match(struct pci_dev *dev, const char *p,
+const char **endptr)
+{
+ int ret;
+ int seg, bus, slot, func, count;
+ unsigned short vendor, device, subsystem_vendor, subsystem_device;
+
+ if (strncmp(p, "pci:", 4) == 0) {
+ /* PCI vendor/device (subvendor/subdevice) ids are specified */
+ p += 4;
+ ret = sscanf(p, "%hx:%hx:%hx:%hx%n", , ,
+_vendor, _device, );
+ if (ret !=
Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
Hi Linus, On 14/06/17 03:59 AM, Linus Walleij wrote: > I started to take a stab at it at one point and incorporated some feedback > from Torvalds etc, it's here: > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/commit/?h=chrdev-warn=65e5b1e9eb3f777ab7535b74b490e882eeec79d7 Yes, thanks, I did find your work after a google search. However, seeing it seems to recover only a handful of numbers with some significant complexity required it seemed like a stopgap solution anyway. I posted a proposal in this thread that simply extends the dynamic range into a region above 256 which seems to work well. This means regular configurations won't be affected an any configuration requiring more than 20 dynamic majors will simply end up with high numbers. So unless anyone can think of a reason why this won't work, it's my preferred direction. > Making them all dynamic seemed dangerous because I was afraid > of userspace ABI breakage because of old userlands with > static mknod:s. I agree. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
On 13/06/17 11:00 PM, Greg Kroah-Hartman wrote: > No, don't modify any drivers, do this in the core chardev code. Ok, well then maybe I misunderstood what you originally asked for because I don't see how you can change a fixed allocation to a dynamic one without touching the driver code which needs to know the major that was assigned in the end. > At quick glance, looks good to me, care to clean it up and make it behind > a config option? Sure. However, is a config option really necessary here? As is, the extended dynamic region will only be used if there are too many chardev majors and it shouldn't have _any_ effect on users that have a small number. So it seems like not selecting that option is just telling the kernel to be broken for no obvious trade-off. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
On 13/06/17 10:35 AM, Greg Kroah-Hartman wrote:
> For char devices, I doubt it, but we can't take the chance, which is why
> you make it an option. Then, it's enabled for 'allmodconfig' builds,
> which helps testers out.
Well I took a look at this and it looks like a lot of work to modify all
the drivers to support a possible dynamic allocation and I'm not really
able to do all that right now.
However, correct me if I'm missing something, but it looks fairly
straightforward to extend the dynamic region above 256 in cases like
this. There are already fixed major numbers above 255 and the
infrastructure appears to support it. So what are your thoughts on the
change below? I'd be happy to clean it up into a proper patch if you
agree it's a workable option.
Thanks,
Logan
diff --git a/fs/char_dev.c b/fs/char_dev.c
index fb8507f521b2..539352425d95 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -59,6 +59,29 @@ void chrdev_show(struct seq_file *f, off_t offset)
#endif /* CONFIG_PROC_FS */
+static int find_dynamic_major(void)
+{
+ int i;
+ struct char_device_struct **cp;
+
+ for (i = ARRAY_SIZE(chrdevs)-1; i > CHRDEV_MAJOR_DYN_END; i--) {
+ if (chrdevs[i] == NULL)
+ return i;
+ }
+
+ for (i = CHRDEV_MAJOR_DYN_EXT_START;
+i > CHRDEV_MAJOR_DYN_EXT_END; i--) {
+ for (cp = [major_to_index(i)]; *cp; cp = &(*cp)->next)
+ if ((*cp)->major == i)
+ break;
+
+ if (*cp == NULL || (*cp)->major != i)
+ return i;
+ }
+
+ return -EBUSY;
+}
+
/*
* Register a single major with a specified minor range.
*
@@ -84,22 +107,11 @@ __register_chrdev_region(unsigned int major,
unsigned int baseminor,
mutex_lock(_lock);
- /* temporary */
if (major == 0) {
- for (i = ARRAY_SIZE(chrdevs)-1; i > 0; i--) {
- if (chrdevs[i] == NULL)
- break;
- }
-
- if (i < CHRDEV_MAJOR_DYN_END)
- pr_warn("CHRDEV \"%s\" major number %d goes below the
dynamic
allocation range\n",
- name, i);
-
- if (i == 0) {
- ret = -EBUSY;
+ ret = find_dynamic_major();
+ if (ret < 0)
goto out;
- }
- major = i;
+ major = ret;
}
cd->major = major;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 249dad4e8d26..5780d69034ca 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2448,6 +2448,9 @@ static inline void bd_unlink_disk_holder(struct
block_device *bdev,
#define CHRDEV_MAJOR_HASH_SIZE 255
/* Marks the bottom of the first segment of free char majors */
#define CHRDEV_MAJOR_DYN_END 234
+#define CHRDEV_MAJOR_DYN_EXT_START 511
+#define CHRDEV_MAJOR_DYN_EXT_END 384
+
extern int alloc_chrdev_region(dev_t *, unsigned, unsigned, const char *);
extern int register_chrdev_region(dev_t, unsigned, const char *);
extern int __register_chrdev(unsigned int major, unsigned int baseminor,
This results in char devices like this (another patch might be prudent
to fix the ordering):
Character devices:
510 ttySLM
1 mem
511 noz
4 /dev/vc/0
4 tty
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
9 st
10 misc
13 input
21 sg
29 fb
43 ttyI
45 isdn
68 capi20
86 ch
90 mtd
99 ppdev
108 ppp
128 ptm
136 pts
152 aoechr
153 spi
161 ircomm
172 ttyMX
174 ttyMI
202 cpu/msr
203 cpu/cpuid
204 ttyJ
204 ttyMAX
206 osst
226 drm
235 ttyS
236 ttyRP
237 ttyARC
238 ttyPS
239 ttyIFX
494 rio_cm
240 ttySC
495 cros_ec
241 ipmidev
496 hidraw
242 rio_mport
497 ttySDIO
243 xz_dec_test
498 uio
244 bsg
499 firewire
245 pvfs2-req
500 nvme
246 watchdog
501 aac
247 iio
502 mei
248 ptp
503 phantom
249 pps
504 aux
250 dax
505 cmx
251 dimmctl
506 cmm
252 ndctl
507 ttySLP
253 tpm
508 ttyIPWp
254 gpiochip
509 ttySL
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
On 12/06/17 10:35 PM, Greg Kroah-Hartman wrote: > Or better yet, just turn all char major allocations into dynamic, which > would be really good for test systems. I thought someone proposed > patches for that a long time ago, but I can't find them anymore. That > would be the simplest solution here. Would people not complain about that? I would not be surprised if some crazy application is using hard coded major numbers in userspace. So such a change could potentially break userspace... Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
On 13/06/17 05:48 AM, Alan Cox wrote: > If you dump the list of majors and drivers do they all look valid or is > there any corruption or repetition that looks odd (wondering if we've > got too many devices or a leak) ? They look valid to me. Logan Character devices: 1 mem 4 /dev/vc/0 4 tty 4 ttyS 5 /dev/tty 5 /dev/console 5 /dev/ptmx 7 vcs 9 st 10 misc 13 input 21 sg 29 fb 43 ttyI 45 isdn 68 capi20 86 ch 90 mtd 99 ppdev 108 ppp 128 ptm 136 pts 152 aoechr 153 spi 161 ircomm 172 ttyMX 174 ttyMI 202 cpu/msr 203 cpu/cpuid 204 ttyJ 204 ttyMAX 206 osst 216 rio_cm 217 cros_ec 218 hidraw 219 ttySDIO 220 uio 221 firewire 222 nvme 223 aac 224 mei 225 phantom 226 drm 227 aux 228 cmx 229 cmm 230 ttySLP 231 ttyIPWp 232 ttySL 233 ttySLM 234 noz 235 ttyS 236 ttyRP 237 ttyARC 238 ttyPS 239 ttyIFX 240 ttySC 241 ipmidev 242 rio_mport 243 xz_dec_test 244 bsg 245 pvfs2-req 246 watchdog 247 iio 248 ptp 249 pps 250 dax 251 dimmctl 252 ndctl 253 tpm 254 gpiochip -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
On 12/06/17 10:18 PM, Greg Kroah-Hartman wrote: > What test causes so many major numbers to be allocated? Is this > in-kernel test code? Do you really have a system that requires so many > different drivers that all want a dynamic char major? This is a 0day kernel robot test. I'm not sure the motivations of its design but it seems to be similar to an allyesconfig. So all/most modules are compiled in and allocating their char device regions on boot of a qemu instance. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/4] New Microsemi PCI Switch Management Driver
On 09/03/17 12:55 PM, Bjorn Helgaas wrote: > Applied to pci/switchtec for v4.12, thanks! Great! Thanks so much! Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/4] switchtec: Add user interface documentation
This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.com> Reviewed-by: Wei Zhang <wzh...@fb.com> Reviewed-by: Jens Axboe <ax...@fb.com> --- Documentation/switchtec.txt | 53 + MAINTAINERS | 1 + 2 files changed, 54 insertions(+) create mode 100644 Documentation/switchtec.txt diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt new file mode 100644 index 000..4bced4c --- /dev/null +++ b/Documentation/switchtec.txt @@ -0,0 +1,53 @@ + +Linux Switchtec Support + + +Microsemi's "Switchtec" line of PCI switch devices is already +supported by the kernel with standard PCI switch drivers. However, the +Switchtec device advertises a special management endpoint which +enables some additional functionality. This includes: + +* Packet and Byte Counters +* Firmware Upgrades +* Event and Error logs +* Querying port link status +* Custom user firmware commands + +The switchtec kernel module implements this functionality. + + +Interface += + +The primary means of communicating with the Switchtec management firmware is +through the Memory-mapped Remote Procedure Call (MRPC) interface. +Commands are submitted to the interface with a 4-byte command +identifier and up to 1KB of command specific data. The firmware will +respond with a 4 bytes return code and up to 1KB of command specific +data. The interface only processes a single command at a time. + + +Userspace Interface +=== + +The MRPC interface will be exposed to userspace through a simple char +device: /dev/switchtec#, one for each management endpoint in the system. + +The char device has the following semantics: + +* A write must consist of at least 4 bytes and no more than 1028 bytes. + The first four bytes will be interpreted as the command to run and + the remainder will be used as the input data. A write will send the + command to the firmware to begin processing. + +* Each write must be followed by exactly one read. Any double write will + produce an error and any read that doesn't follow a write will + produce an error. + +* A read will block until the firmware completes the command and return + the four bytes of status plus up to 1024 bytes of output data. (The + length will be specified by the size parameter of the read call -- + reading less than 4 bytes will produce an error. + +* The poll call will also be supported for userspace applications that + need to do other things while waiting for the command to complete. diff --git a/MAINTAINERS b/MAINTAINERS index a57686f..aa702b0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9512,6 +9512,7 @@ M:Stephen Bates <stephen.ba...@microsemi.com> M: Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained +F: Documentation/switchtec.txt F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/4] New Microsemi PCI Switch Management Driver
Hi, Hopefully this is the last change necessary. The new code to handle unbind follows Jason's suggestions and is a lot easier to reason about. It's also been tested interrupting a number of operations. Thanks, Logan -- Changes since v5: * Reworked cleanup during unbind again. This time we follow the pattern roughly suggested by Jason Gunthorpe: we use an alive flag that's checked with a rw semaphore held by the cdev ops. Except instead of using the rwsem we just use the already existing mrpc_mutex. (Seeing the vast majority of locations that would use the semaphore overlap with the existing mutex.) * Added a small performance enhancement so the code reads less io memory if the user is quick in submitting their read request. Changes since v4: * Turns out pushing the pci release code into the device release function didn't work as I would have liked. If you try to unbind the device with an instance open, then you hit a kernel bug at drivers/pci/msi.c:371. (This didn't occur in v3.) To solve this, we've moved the pci release code back into the unregister function and reintroduced an alive flag. This time, however, the alive flag is protected by mrpc_mutex and we're very careful about what happens to devices still in use (they should all be released through the timeout path and an ENODEV error returned to userspace; while new commands are blocked with the same error). Changes since v3: * Removed stdev_is_alive and moved pci deinit functions into the device release function which only occurs after all cdev instances are closed. (per Bjorn) * Reduced locking in read/write functions (per Bjorn) * Use pci_alloc_irq_vectors to vastly improve ISR initialization (Bjorn) * A few other minor nits and cleanup as noticed by Bjorn Changes since v2: * Collected reviewed and tested tags * Very minor fix to the error path in the create function Changes since v1: * Rebased onto 4.10-rc6 (cleanly) * Split the patch into a few more easily digestible patches (as suggested by Greg Kroah-Hartman) * Folded switchtec.c into switchtec.h (per Greg) * Fixed a bunch of 32bit build warnings caught by the kbuild test robot * Fixed some issues in the documentation so it has a proper reStructredText format (as noted by Jonathan Corbet) * Fixed padding and sizes in the IOCTL structures as noticed by Emil Velikov and used pahole to verify their consistency across 32 and 64 bit builds * Reworked one of the IOCTL interfaces to be more future proof (per Emil). Changes since RFC: * Fixed incorrect use of the drive model as pointed out by Greg Kroah-Hartman * Used devm functions as suggested by Keith Busch * Added a handful of sysfs attributes to the switchtec class * Added a handful of IOCTLs to the switchtec device * A number of miscellaneous bug fixes -- Hi, This is a continuation of the RFC we posted lasted month [1] which proposes a management driver for Microsemi's Switchtec line of PCI switches. This hardware is still looking to be used in the Open Compute Platform To make this entirely clear: the Switchtec products are compliant with the PCI specifications and are supported today with the standard in-kernel driver. However, these devices also expose a management endpoint on a separate PCI function address which can be used to perform some advanced operations. This is a driver for that function. See the patch for more information. Since the RFC, we've made the changes requested by Greg Kroah-Hartman and Keith Busch, and we've also fleshed out a number of features. We've added a couple of IOCTLs and sysfs attributes which are documented in the patch. Significant work has also been done on the userspace tool which is available under a GPL license at [2]. We've also had testing done by some of the interested parties. We hope to see this work included in either 4.11 or 4.12 assuming a smooth review process. The patch is based off of the v4.10-rc6 release. Thanks for your review, Logan [1] https://www.spinics.net/lists/linux-pci/msg56897.html [2] https://github.com/sbates130272/switchtec-user Logan Gunthorpe (4): MicroSemi Switchtec management interface driver switchtec: Add user interface documentation switchtec: Add sysfs attributes to the Switchtec driver switchtec: Add IOCTLs to the Switchtec driver Documentation/ABI/testing/sysfs-class-switchtec | 96 ++ Documentation/ioctl/ioctl-number.txt|1 + Documentation/switchtec.txt | 80 ++ MAINTAINERS | 11 + drivers/pci/Kconfig |1 + drivers/pci/Makefile|1 + drivers/pci/switch/Kconfig | 13 + drivers/pci/switch/Makefile |1 + drivers/pci/switch/switchtec.c | 1599 +++ include/uapi/linux/switchtec_ioctl.h| 132 ++ 10 files changed, 1935 insertions(+) create mode 100644
[PATCH v7 4/4] switchtec: Add IOCTLs to the Switchtec driver
This patch introduces a couple of special IOCTLs which are provided to:
* Inform userspace of firmware partition locations
* Pass event counts and allow userspace to wait on events
* Translate between PFF numbers used by the switch to
port numbers.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.com>
Reviewed-by: Wei Zhang <wzh...@fb.com>
Reviewed-by: Jens Axboe <ax...@fb.com>
---
Documentation/ioctl/ioctl-number.txt | 1 +
Documentation/switchtec.txt | 27 ++
MAINTAINERS | 1 +
drivers/pci/switch/switchtec.c | 481 +++
include/uapi/linux/switchtec_ioctl.h | 132 ++
5 files changed, 642 insertions(+)
create mode 100644 include/uapi/linux/switchtec_ioctl.h
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 81c7f2b..032b33c 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -191,6 +191,7 @@ Code Seq#(hex) Include FileComments
'W'00-1F linux/watchdog.hconflict!
'W'00-1F linux/wanrouter.h conflict! (pre 3.9)
'W'00-3F sound/asound.h conflict!
+'W'40-5F drivers/pci/switch/switchtec.c
'X'all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h
and include/linux/falloc.h
diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt
index 4bced4c..a0a9c7b 100644
--- a/Documentation/switchtec.txt
+++ b/Documentation/switchtec.txt
@@ -51,3 +51,30 @@ The char device has the following semantics:
* The poll call will also be supported for userspace applications that
need to do other things while waiting for the command to complete.
+
+The following IOCTLs are also supported by the device:
+
+* SWITCHTEC_IOCTL_FLASH_INFO - Retrieve firmware length and number
+ of partitions in the device.
+
+* SWITCHTEC_IOCTL_FLASH_PART_INFO - Retrieve address and lengeth for
+ any specified partition in flash.
+
+* SWITCHTEC_IOCTL_EVENT_SUMMARY - Read a structure of bitmaps
+ indicating all uncleared events.
+
+* SWITCHTEC_IOCTL_EVENT_CTL - Get the current count, clear and set flags
+ for any event. This ioctl takes in a switchtec_ioctl_event_ctl struct
+ with the event_id, index and flags set (index being the partition or PFF
+ number for non-global events). It returns whether the event has
+ occurred, the number of times and any event specific data. The flags
+ can be used to clear the count or enable and disable actions to
+ happen when the event occurs.
+ By using the SWITCHTEC_IOCTL_EVENT_FLAG_EN_POLL flag,
+ you can set an event to trigger a poll command to return with
+ POLLPRI. In this way, userspace can wait for events to occur.
+
+* SWITCHTEC_IOCTL_PFF_TO_PORT and SWITCHTEC_IOCTL_PORT_TO_PFF convert
+ between PCI Function Framework number (used by the event system)
+ and Switchtec Logic Port ID and Partition number (which is more
+ user friendly).
diff --git a/MAINTAINERS b/MAINTAINERS
index 6fed938..c1a9a30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9515,6 +9515,7 @@ S:Maintained
F: Documentation/switchtec.txt
F: Documentation/ABI/testing/sysfs-class-switchtec
F: drivers/pci/switch/switchtec*
+F: include/uapi/linux/switchtec_ioctl.h
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 4888e23..1f045c9 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -13,6 +13,8 @@
*
*/
+#include
+
#include
#include
#include
@@ -778,6 +780,431 @@ static unsigned int switchtec_dev_poll(struct file *filp,
poll_table *wait)
return ret;
}
+static int ioctl_flash_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+
+ info.flash_length = ioread32(>flash_length);
+ info.num_partitions = SWITCHTEC_IOCTL_NUM_PARTITIONS;
+
+ if (copy_to_user(uinfo, , sizeof(info)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static void set_fw_info_part(struct switchtec_ioctl_flash_part_info *info,
+struct partition_info __iomem *pi)
+{
+ info->address = ioread32(>address);
+ info->length = ioread32(>length);
+}
+
+static int ioctl_flash_part_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_part_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_part_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+ u32 active_addr = -1;
+
+ if (copy
[PATCH v7 1/4] MicroSemi Switchtec management interface driver
Microsemi's "Switchtec" line of PCI switch devices is already well
supported by the kernel with standard PCI switch drivers. However, the
Switchtec device advertises a special management endpoint with a separate
PCI function address and class code. This endpoint enables some additional
functionality which includes:
* Packet and Byte Counters
* Switch Firmware Upgrades
* Event and Error logs
* Querying port link status
* Custom user firmware commands
This patch introduces the switchtec kernel module which provides
PCI driver that exposes a char device. The char device provides
userspace access to this interface through read, write and (optionally)
poll calls.
A userspace tool and library which utilizes this interface is available
at [1]. This tool takes inspiration (and borrows some code) from
nvme-cli [2]. The tool is largely complete at this time but additional
features may be added in the future.
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.com>
Reviewed-by: Wei Zhang <wzh...@fb.com>
Reviewed-by: Jens Axboe <ax...@fb.com>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
MAINTAINERS|8 +
drivers/pci/Kconfig|1 +
drivers/pci/Makefile |1 +
drivers/pci/switch/Kconfig | 13 +
drivers/pci/switch/Makefile|1 +
drivers/pci/switch/switchtec.c | 1006
6 files changed, 1030 insertions(+)
create mode 100644 drivers/pci/switch/Kconfig
create mode 100644 drivers/pci/switch/Makefile
create mode 100644 drivers/pci/switch/switchtec.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 527d137..a57686f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9506,6 +9506,14 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/aardvark-pci.txt
F: drivers/pci/host/pci-aardvark.c
+PCI DRIVER FOR MICROSEMI SWITCHTEC
+M: Kurt Schwemmer <kurt.schwem...@microsemi.com>
+M: Stephen Bates <stephen.ba...@microsemi.com>
+M: Logan Gunthorpe <log...@deltatee.com>
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/pci/switch/switchtec*
+
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
L: linux-te...@vger.kernel.org
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 6555eb7..f72e8c5 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -133,3 +133,4 @@ config PCI_HYPERV
source "drivers/pci/hotplug/Kconfig"
source "drivers/pci/host/Kconfig"
+source "drivers/pci/switch/Kconfig"
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 8db5079..15b46dd 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -68,3 +68,4 @@ ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
# PCI host controller drivers
obj-y += host/
+obj-y += switch/
diff --git a/drivers/pci/switch/Kconfig b/drivers/pci/switch/Kconfig
new file mode 100644
index 000..4c49648
--- /dev/null
+++ b/drivers/pci/switch/Kconfig
@@ -0,0 +1,13 @@
+menu "PCI switch controller drivers"
+ depends on PCI
+
+config PCI_SW_SWITCHTEC
+ tristate "MicroSemi Switchtec PCIe Switch Management Driver"
+ help
+Enables support for the management interface for the MicroSemi
+Switchtec series of PCIe switches. Supports userspace access
+to submit MRPC commands to the switch via /dev/switchtecX
+devices. See for more
+information.
+
+endmenu
diff --git a/drivers/pci/switch/Makefile b/drivers/pci/switch/Makefile
new file mode 100644
index 000..37d8cfb
--- /dev/null
+++ b/drivers/pci/switch/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PCI_SW_SWITCHTEC) += switchtec.o
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
new file mode 100644
index 000..084e4ed
--- /dev/null
+++ b/drivers/pci/switch/switchtec.c
@@ -0,0 +1,1006 @@
+/*
+ * Microsemi Switchtec(tm) PCIe Management Driver
+ * Copyright (c) 2017, Microsemi Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCIe Management Driver");
+MODULE_VERSION("0.1");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Microsemi Cor
[PATCH v6 1/4] MicroSemi Switchtec management interface driver
Microsemi's "Switchtec" line of PCI switch devices is already well
supported by the kernel with standard PCI switch drivers. However, the
Switchtec device advertises a special management endpoint with a separate
PCI function address and class code. This endpoint enables some additional
functionality which includes:
* Packet and Byte Counters
* Switch Firmware Upgrades
* Event and Error logs
* Querying port link status
* Custom user firmware commands
This patch introduces the switchtec kernel module which provides
PCI driver that exposes a char device. The char device provides
userspace access to this interface through read, write and (optionally)
poll calls.
A userspace tool and library which utilizes this interface is available
at [1]. This tool takes inspiration (and borrows some code) from
nvme-cli [2]. The tool is largely complete at this time but additional
features may be added in the future.
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.com>
Reviewed-by: Wei Zhang <wzh...@fb.com>
Reviewed-by: Jens Axboe <ax...@fb.com>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
MAINTAINERS|8 +
drivers/pci/Kconfig|1 +
drivers/pci/Makefile |1 +
drivers/pci/switch/Kconfig | 13 +
drivers/pci/switch/Makefile|1 +
drivers/pci/switch/switchtec.c | 1005
6 files changed, 1029 insertions(+)
create mode 100644 drivers/pci/switch/Kconfig
create mode 100644 drivers/pci/switch/Makefile
create mode 100644 drivers/pci/switch/switchtec.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 527d137..a57686f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9506,6 +9506,14 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/aardvark-pci.txt
F: drivers/pci/host/pci-aardvark.c
+PCI DRIVER FOR MICROSEMI SWITCHTEC
+M: Kurt Schwemmer <kurt.schwem...@microsemi.com>
+M: Stephen Bates <stephen.ba...@microsemi.com>
+M: Logan Gunthorpe <log...@deltatee.com>
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/pci/switch/switchtec*
+
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
L: linux-te...@vger.kernel.org
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 6555eb7..f72e8c5 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -133,3 +133,4 @@ config PCI_HYPERV
source "drivers/pci/hotplug/Kconfig"
source "drivers/pci/host/Kconfig"
+source "drivers/pci/switch/Kconfig"
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 8db5079..15b46dd 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -68,3 +68,4 @@ ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
# PCI host controller drivers
obj-y += host/
+obj-y += switch/
diff --git a/drivers/pci/switch/Kconfig b/drivers/pci/switch/Kconfig
new file mode 100644
index 000..4c49648
--- /dev/null
+++ b/drivers/pci/switch/Kconfig
@@ -0,0 +1,13 @@
+menu "PCI switch controller drivers"
+ depends on PCI
+
+config PCI_SW_SWITCHTEC
+ tristate "MicroSemi Switchtec PCIe Switch Management Driver"
+ help
+Enables support for the management interface for the MicroSemi
+Switchtec series of PCIe switches. Supports userspace access
+to submit MRPC commands to the switch via /dev/switchtecX
+devices. See for more
+information.
+
+endmenu
diff --git a/drivers/pci/switch/Makefile b/drivers/pci/switch/Makefile
new file mode 100644
index 000..37d8cfb
--- /dev/null
+++ b/drivers/pci/switch/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PCI_SW_SWITCHTEC) += switchtec.o
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
new file mode 100644
index 000..2993c0c
--- /dev/null
+++ b/drivers/pci/switch/switchtec.c
@@ -0,0 +1,1005 @@
+/*
+ * Microsemi Switchtec(tm) PCIe Management Driver
+ * Copyright (c) 2017, Microsemi Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCIe Management Driver");
+MODULE_VERSION("0.1");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Microsemi Cor
[PATCH v6 3/4] switchtec: Add sysfs attributes to the Switchtec driver
This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.com> Reviewed-by: Wei Zhang <wzh...@fb.com> Reviewed-by: Jens Axboe <ax...@fb.com> Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- Documentation/ABI/testing/sysfs-class-switchtec | 96 MAINTAINERS | 1 + drivers/pci/switch/switchtec.c | 113 3 files changed, 210 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec diff --git a/Documentation/ABI/testing/sysfs-class-switchtec b/Documentation/ABI/testing/sysfs-class-switchtec new file mode 100644 index 000..48cb4c1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-switchtec @@ -0,0 +1,96 @@ +switchtec - Microsemi Switchtec PCI Switch Management Endpoint + +For details on this subsystem look at Documentation/switchtec.txt. + +What: /sys/class/switchtec +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: The switchtec class subsystem folder. + Each registered switchtec driver is represented by a switchtecX + subfolder (X being an integer >= 0). + + +What: /sys/class/switchtec/switchtec[0-9]+/component_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component identifier as stored in the hardware (eg. PM8543) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component revision stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/device_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Device version as stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/fw_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Currently running firmware version (read only) +Values:integer (in hexadecimal). + + +What: /sys/class/switchtec/switchtec[0-9]+/partition +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Partition number for this device in the switch (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/partition_count +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Total number of partitions in the switch (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product identifier as stored in the hardware (eg. PSX 48XG3) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product revision stored in the hardware (eg. RevB) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. diff --git a/MAINTAINERS b/MAINTAINERS index aa702b0..6fed938 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9513,6 +9513,7 @@ M:Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained F: Documentation/switchtec.txt +F: Documentation/ABI/testing/sysfs-class-switchtec F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA diff --gi
Re: [PATCH v6 0/4] New Microsemi PCI Switch Management Driver
Hey, Ah, sorry, sorry. I noticed another minor mistake. I'll send a v7 in a second. Thanks, Logan On 02/03/17 04:07 PM, Logan Gunthorpe wrote: > Hi, > > Hopefully this is the last change necessary. The new code to handle > unbind follows Jason's suggestions and is a lot easier to reason about. > It's also been tested interrupting a number of operations. > > Thanks, > > Logan > > -- > > Changes since v5: > > * Reworked cleanup during unbind again. This time we follow the pattern > roughly suggested by Jason Gunthorpe: we use an alive flag > that's checked with a rw semaphore held by the cdev ops. Except > instead of using the rwsem we just use the already existing > mrpc_mutex. (Seeing the vast majority of locations that would use the > semaphore overlap with the existing mutex.) > * Added a small performance enhancement so the code reads less io memory > if the user is quick in submitting their read request. > > Changes since v4: > > * Turns out pushing the pci release code into the device release > function didn't work as I would have liked. If you try to unbind the > device with an instance open, then you hit a kernel bug at > drivers/pci/msi.c:371. (This didn't occur in v3.) > > To solve this, we've moved the pci release code back into the > unregister function and reintroduced an alive flag. This time, > however, the alive flag is protected by mrpc_mutex and we're very > careful about what happens to devices still in use (they should > all be released through the timeout path and an ENODEV error > returned to userspace; while new commands are blocked with the > same error). > > Changes since v3: > > * Removed stdev_is_alive and moved pci deinit functions > into the device release function which only occurs after all > cdev instances are closed. (per Bjorn) > * Reduced locking in read/write functions (per Bjorn) > * Use pci_alloc_irq_vectors to vastly improve ISR initialization (Bjorn) > * A few other minor nits and cleanup as noticed by Bjorn > > Changes since v2: > > * Collected reviewed and tested tags > * Very minor fix to the error path in the create function > > Changes since v1: > > * Rebased onto 4.10-rc6 (cleanly) > * Split the patch into a few more easily digestible patches (as > suggested by Greg Kroah-Hartman) > * Folded switchtec.c into switchtec.h (per Greg) > * Fixed a bunch of 32bit build warnings caught by the kbuild test robot > * Fixed some issues in the documentation so it has a proper > reStructredText format (as noted by Jonathan Corbet) > * Fixed padding and sizes in the IOCTL structures as noticed by Emil > Velikov and used pahole to verify their consistency across 32 and 64 > bit builds > * Reworked one of the IOCTL interfaces to be more future proof (per > Emil). > > Changes since RFC: > > * Fixed incorrect use of the drive model as pointed out by Greg > Kroah-Hartman > * Used devm functions as suggested by Keith Busch > * Added a handful of sysfs attributes to the switchtec class > * Added a handful of IOCTLs to the switchtec device > * A number of miscellaneous bug fixes > > -- > > Hi, > > This is a continuation of the RFC we posted lasted month [1] which > proposes a management driver for Microsemi's Switchtec line of PCI > switches. This hardware is still looking to be used in the Open > Compute Platform > > To make this entirely clear: the Switchtec products are compliant > with the PCI specifications and are supported today with the standard > in-kernel driver. However, these devices also expose a management endpoint > on a separate PCI function address which can be used to perform some > advanced operations. This is a driver for that function. See the patch > for more information. > > Since the RFC, we've made the changes requested by Greg Kroah-Hartman > and Keith Busch, and we've also fleshed out a number of features. We've > added a couple of IOCTLs and sysfs attributes which are documented in > the patch. Significant work has also been done on the userspace tool > which is available under a GPL license at [2]. We've also had testing > done by some of the interested parties. > > We hope to see this work included in either 4.11 or 4.12 assuming a > smooth review process. > > The patch is based off of the v4.10-rc6 release. > > Thanks for your review, > > Logan > > [1] https://www.spinics.net/lists/linux-pci/msg56897.html > [2] https://github.com/sbates130272/switchtec-user > > Logan Gunthorpe (4): > MicroSemi Switchtec management interface driver > switchtec: Add user interface documentation > switchtec: Add sysfs attribu
[PATCH v6 4/4] switchtec: Add IOCTLs to the Switchtec driver
This patch introduces a couple of special IOCTLs which are provided to:
* Inform userspace of firmware partition locations
* Pass event counts and allow userspace to wait on events
* Translate between PFF numbers used by the switch to
port numbers.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.com>
Reviewed-by: Wei Zhang <wzh...@fb.com>
Reviewed-by: Jens Axboe <ax...@fb.com>
---
Documentation/ioctl/ioctl-number.txt | 1 +
Documentation/switchtec.txt | 27 ++
MAINTAINERS | 1 +
drivers/pci/switch/switchtec.c | 481 +++
include/uapi/linux/switchtec_ioctl.h | 132 ++
5 files changed, 642 insertions(+)
create mode 100644 include/uapi/linux/switchtec_ioctl.h
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 81c7f2b..032b33c 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -191,6 +191,7 @@ Code Seq#(hex) Include FileComments
'W'00-1F linux/watchdog.hconflict!
'W'00-1F linux/wanrouter.h conflict! (pre 3.9)
'W'00-3F sound/asound.h conflict!
+'W'40-5F drivers/pci/switch/switchtec.c
'X'all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h
and include/linux/falloc.h
diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt
index 4bced4c..a0a9c7b 100644
--- a/Documentation/switchtec.txt
+++ b/Documentation/switchtec.txt
@@ -51,3 +51,30 @@ The char device has the following semantics:
* The poll call will also be supported for userspace applications that
need to do other things while waiting for the command to complete.
+
+The following IOCTLs are also supported by the device:
+
+* SWITCHTEC_IOCTL_FLASH_INFO - Retrieve firmware length and number
+ of partitions in the device.
+
+* SWITCHTEC_IOCTL_FLASH_PART_INFO - Retrieve address and lengeth for
+ any specified partition in flash.
+
+* SWITCHTEC_IOCTL_EVENT_SUMMARY - Read a structure of bitmaps
+ indicating all uncleared events.
+
+* SWITCHTEC_IOCTL_EVENT_CTL - Get the current count, clear and set flags
+ for any event. This ioctl takes in a switchtec_ioctl_event_ctl struct
+ with the event_id, index and flags set (index being the partition or PFF
+ number for non-global events). It returns whether the event has
+ occurred, the number of times and any event specific data. The flags
+ can be used to clear the count or enable and disable actions to
+ happen when the event occurs.
+ By using the SWITCHTEC_IOCTL_EVENT_FLAG_EN_POLL flag,
+ you can set an event to trigger a poll command to return with
+ POLLPRI. In this way, userspace can wait for events to occur.
+
+* SWITCHTEC_IOCTL_PFF_TO_PORT and SWITCHTEC_IOCTL_PORT_TO_PFF convert
+ between PCI Function Framework number (used by the event system)
+ and Switchtec Logic Port ID and Partition number (which is more
+ user friendly).
diff --git a/MAINTAINERS b/MAINTAINERS
index 6fed938..c1a9a30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9515,6 +9515,7 @@ S:Maintained
F: Documentation/switchtec.txt
F: Documentation/ABI/testing/sysfs-class-switchtec
F: drivers/pci/switch/switchtec*
+F: include/uapi/linux/switchtec_ioctl.h
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index ab08aa4..27ced6f 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -13,6 +13,8 @@
*
*/
+#include
+
#include
#include
#include
@@ -778,6 +780,431 @@ static unsigned int switchtec_dev_poll(struct file *filp,
poll_table *wait)
return ret;
}
+static int ioctl_flash_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+
+ info.flash_length = ioread32(>flash_length);
+ info.num_partitions = SWITCHTEC_IOCTL_NUM_PARTITIONS;
+
+ if (copy_to_user(uinfo, , sizeof(info)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static void set_fw_info_part(struct switchtec_ioctl_flash_part_info *info,
+struct partition_info __iomem *pi)
+{
+ info->address = ioread32(>address);
+ info->length = ioread32(>length);
+}
+
+static int ioctl_flash_part_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_part_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_part_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+ u32 active_addr = -1;
+
+ if (copy
[PATCH v7 2/4] switchtec: Add user interface documentation
This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.com> Reviewed-by: Wei Zhang <wzh...@fb.com> Reviewed-by: Jens Axboe <ax...@fb.com> --- Documentation/switchtec.txt | 53 + MAINTAINERS | 1 + 2 files changed, 54 insertions(+) create mode 100644 Documentation/switchtec.txt diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt new file mode 100644 index 000..4bced4c --- /dev/null +++ b/Documentation/switchtec.txt @@ -0,0 +1,53 @@ + +Linux Switchtec Support + + +Microsemi's "Switchtec" line of PCI switch devices is already +supported by the kernel with standard PCI switch drivers. However, the +Switchtec device advertises a special management endpoint which +enables some additional functionality. This includes: + +* Packet and Byte Counters +* Firmware Upgrades +* Event and Error logs +* Querying port link status +* Custom user firmware commands + +The switchtec kernel module implements this functionality. + + +Interface += + +The primary means of communicating with the Switchtec management firmware is +through the Memory-mapped Remote Procedure Call (MRPC) interface. +Commands are submitted to the interface with a 4-byte command +identifier and up to 1KB of command specific data. The firmware will +respond with a 4 bytes return code and up to 1KB of command specific +data. The interface only processes a single command at a time. + + +Userspace Interface +=== + +The MRPC interface will be exposed to userspace through a simple char +device: /dev/switchtec#, one for each management endpoint in the system. + +The char device has the following semantics: + +* A write must consist of at least 4 bytes and no more than 1028 bytes. + The first four bytes will be interpreted as the command to run and + the remainder will be used as the input data. A write will send the + command to the firmware to begin processing. + +* Each write must be followed by exactly one read. Any double write will + produce an error and any read that doesn't follow a write will + produce an error. + +* A read will block until the firmware completes the command and return + the four bytes of status plus up to 1024 bytes of output data. (The + length will be specified by the size parameter of the read call -- + reading less than 4 bytes will produce an error. + +* The poll call will also be supported for userspace applications that + need to do other things while waiting for the command to complete. diff --git a/MAINTAINERS b/MAINTAINERS index a57686f..aa702b0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9512,6 +9512,7 @@ M:Stephen Bates <stephen.ba...@microsemi.com> M: Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained +F: Documentation/switchtec.txt F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/4] New Microsemi PCI Switch Management Driver
Because getting it right correctly the first time is appearantly hard and I caught this mistake while reading the email I had just sent :( I'm very sorry about the extra noise. Logan -- Changes since v6: * I screwed up the device_unregister path and left a potential use after free bug in. I'm not sure why I didn't see a failure because of it but it all tested fine. This version is correct though. Changes since v5: * Reworked cleanup during unbind again. This time we follow the pattern roughly suggested by Jason Gunthorpe: we use an alive flag that's checked with a rw semaphore held by the cdev ops. Except instead of using the rwsem we just use the already existing mrpc_mutex. (Seeing the vast majority of locations that would use the semaphore overlap with the existing mutex.) * Added a small performance enhancement so the code reads less io memory if the user is quick in submitting their read request. Changes since v4: * Turns out pushing the pci release code into the device release function didn't work as I would have liked. If you try to unbind the device with an instance open, then you hit a kernel bug at drivers/pci/msi.c:371. (This didn't occur in v3.) To solve this, we've moved the pci release code back into the unregister function and reintroduced an alive flag. This time, however, the alive flag is protected by mrpc_mutex and we're very careful about what happens to devices still in use (they should all be released through the timeout path and an ENODEV error returned to userspace; while new commands are blocked with the same error). Changes since v3: * Removed stdev_is_alive and moved pci deinit functions into the device release function which only occurs after all cdev instances are closed. (per Bjorn) * Reduced locking in read/write functions (per Bjorn) * Use pci_alloc_irq_vectors to vastly improve ISR initialization (Bjorn) * A few other minor nits and cleanup as noticed by Bjorn Changes since v2: * Collected reviewed and tested tags * Very minor fix to the error path in the create function Changes since v1: * Rebased onto 4.10-rc6 (cleanly) * Split the patch into a few more easily digestible patches (as suggested by Greg Kroah-Hartman) * Folded switchtec.c into switchtec.h (per Greg) * Fixed a bunch of 32bit build warnings caught by the kbuild test robot * Fixed some issues in the documentation so it has a proper reStructredText format (as noted by Jonathan Corbet) * Fixed padding and sizes in the IOCTL structures as noticed by Emil Velikov and used pahole to verify their consistency across 32 and 64 bit builds * Reworked one of the IOCTL interfaces to be more future proof (per Emil). Changes since RFC: * Fixed incorrect use of the drive model as pointed out by Greg Kroah-Hartman * Used devm functions as suggested by Keith Busch * Added a handful of sysfs attributes to the switchtec class * Added a handful of IOCTLs to the switchtec device * A number of miscellaneous bug fixes -- Hi, This is a continuation of the RFC we posted lasted month [1] which proposes a management driver for Microsemi's Switchtec line of PCI switches. This hardware is still looking to be used in the Open Compute Platform To make this entirely clear: the Switchtec products are compliant with the PCI specifications and are supported today with the standard in-kernel driver. However, these devices also expose a management endpoint on a separate PCI function address which can be used to perform some advanced operations. This is a driver for that function. See the patch for more information. Since the RFC, we've made the changes requested by Greg Kroah-Hartman and Keith Busch, and we've also fleshed out a number of features. We've added a couple of IOCTLs and sysfs attributes which are documented in the patch. Significant work has also been done on the userspace tool which is available under a GPL license at [2]. We've also had testing done by some of the interested parties. We hope to see this work included in either 4.11 or 4.12 assuming a smooth review process. The patch is based off of the v4.10-rc6 release. Thanks for your review, Logan [1] https://www.spinics.net/lists/linux-pci/msg56897.html [2] https://github.com/sbates130272/switchtec-user Logan Gunthorpe (4): MicroSemi Switchtec management interface driver switchtec: Add user interface documentation switchtec: Add sysfs attributes to the Switchtec driver switchtec: Add IOCTLs to the Switchtec driver Documentation/ABI/testing/sysfs-class-switchtec | 96 ++ Documentation/ioctl/ioctl-number.txt|1 + Documentation/switchtec.txt | 80 ++ MAINTAINERS | 11 + drivers/pci/Kconfig |1 + drivers/pci/Makefile|1 + drivers/pci/switch/Kconfig | 13 + drivers/pci/switch/Makefile |1 + drivers/pci
[PATCH v7 3/4] switchtec: Add sysfs attributes to the Switchtec driver
This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.com> Reviewed-by: Wei Zhang <wzh...@fb.com> Reviewed-by: Jens Axboe <ax...@fb.com> Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- Documentation/ABI/testing/sysfs-class-switchtec | 96 MAINTAINERS | 1 + drivers/pci/switch/switchtec.c | 113 3 files changed, 210 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec diff --git a/Documentation/ABI/testing/sysfs-class-switchtec b/Documentation/ABI/testing/sysfs-class-switchtec new file mode 100644 index 000..48cb4c1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-switchtec @@ -0,0 +1,96 @@ +switchtec - Microsemi Switchtec PCI Switch Management Endpoint + +For details on this subsystem look at Documentation/switchtec.txt. + +What: /sys/class/switchtec +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: The switchtec class subsystem folder. + Each registered switchtec driver is represented by a switchtecX + subfolder (X being an integer >= 0). + + +What: /sys/class/switchtec/switchtec[0-9]+/component_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component identifier as stored in the hardware (eg. PM8543) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component revision stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/device_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Device version as stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/fw_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Currently running firmware version (read only) +Values:integer (in hexadecimal). + + +What: /sys/class/switchtec/switchtec[0-9]+/partition +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Partition number for this device in the switch (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/partition_count +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Total number of partitions in the switch (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product identifier as stored in the hardware (eg. PSX 48XG3) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product revision stored in the hardware (eg. RevB) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. diff --git a/MAINTAINERS b/MAINTAINERS index aa702b0..6fed938 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9513,6 +9513,7 @@ M:Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained F: Documentation/switchtec.txt +F: Documentation/ABI/testing/sysfs-class-switchtec F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA diff --gi
Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver
On 01/03/17 05:23 PM, Logan Gunthorpe wrote: > Because of how poll works, I don't see how I can just hold a semaphore > inside every fops call like the tpm code does. On 01/03/17 04:58 PM, Jason Gunthorpe wrote: > Both infiniband and TPM have the 'detach' flavour of unplug where the > user is not forced to close their open cdevs. For simpler cases you > can just wait for all cdevs to close with a simple rwsem, much like > sysfs does already during device_del. Though, after reading your email again, a hard fence on close sounds like a good idea. Tomorrow I'll post a v6 that uses that approach. Thanks, Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver
On 01/03/17 04:58 PM, Jason Gunthorpe wrote: > On Wed, Mar 01, 2017 at 03:49:04PM -0700, Logan Gunthorpe wrote: > >> Seems to me like an elegant solution would be to implement a 'cdev_kill' >> function which could kill all the processes using a cdev. Thus, during >> an unbind, a driver could call it and be sure that there are no users >> left and it can safely allow the devres unwind to continue. Then no >> difficult and racy 'alive' flags would be necessary and it would be much >> easier on drivers. > > That could help, but this would mean cdev would have to insert a shim > to grab locks around the various file ops. Hmm, I was hoping something more along the lines of actually killing the processes instead of just shimming away fops. > AFAIK TPM is correct and has been robustly tested now. We have a 'vtpm' > driver that agressively uses hot-unplug. Ah, thanks for the explanation of how that works. I didn't notice the semaphore usage. Switchtec is a bit more tricky because a) there's no upper level driver to handle things and b) userspace may be inside a wait_for_completion (via read or poll) that needs to be completed. If a so called 'cdev_kill' could actually just kill these processes it would be a bit easier. Currently, in the Switchtec code, there's a timeout if the interrupt doesn't fire (which occurs if the pci device has been torn down) and the code will check an alive bit (under mutex protection) and error out if it's not alive. Because of how poll works, I don't see how I can just hold a semaphore inside every fops call like the tpm code does. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver
On 01/03/17 05:32 PM, Bjorn Helgaas wrote: > It's not a perfect fit in drivers/pci because it's not bus > infrastructure and I don't want to be the default maintainer of it, > but I agree there's not really an alternative that's clearly better, > so let's leave it where it is for now. Sounds good, thanks. It would be nice if it could stay where it is for organization but go through other maintainers trees (though I'm not sure who). I understand why you wouldn't want to take on the maintenance of it. Hopefully, myself and the other Microsemi developers will be able to do the bulk of the maintenance work for the driver. Thanks, Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver
On 01/03/17 03:59 PM, Keith Busch wrote: > Okay, I see. Was mistakenliy looking at v4. The v5 looks right. Great! Thanks for reviewing that for me. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver
Hey, Seems to me like an elegant solution would be to implement a 'cdev_kill' function which could kill all the processes using a cdev. Thus, during an unbind, a driver could call it and be sure that there are no users left and it can safely allow the devres unwind to continue. Then no difficult and racy 'alive' flags would be necessary and it would be much easier on drivers. However, I don't think any such thing exists at the moment and it's not likely to be done in the near term. I'm reasonably confident in the correctness of v5 of my driver (especially when compared to other drivers) and unless someone can describe how it's wrong or a better solution I'd rather see it merged as is. If and when a better approach arrives I'd happily patch it to improve the situation. Logan On 01/03/17 03:24 PM, Logan Gunthorpe wrote: > > > On 01/03/17 02:41 PM, Bjorn Helgaas wrote: >> I don't think this is indicating a bug in the PCI core (although I do >> think a BUG_ON() here is an excessive response). I think it's an >> indication that the driver didn't disconnect its ISR. Without more >> details of the failure it's hard to tell if the BUG_ON is a symptom of >> a problem in the driver or what. > > Yes, my assumption was that when you force an unbind on the PCI core, > it's designed to stop using the PCI device right away even if there are > users using it. Thus it becomes the drivers responsibility to handle > this situation. > >> An "alive" flag feels racy, and I can't tell if it's really the best >> way to deal with this, or if it's just avoiding the issue. There must >> be other drivers with the same cleanup issue -- do they handle it the >> same way? > > I haven't done a comprehensive search, but it's very common for people > to use (and this is what I've adopted again in v5): > > devm_request_irq(>dev, ...) > > In this way, the IRQs are released with the pci_dev (or often platform) > and thus the BUG_ON never hits. However, it means any user space program > waiting on an IRQ (like via a cdev call) will hang unless handled with > other means. Exactly what those means are seems driver specific and not > always obvious. I wouldn't be surprised if a lot of drivers get this > aspect wrong. > > A couple examples I've looked at: > > 1) drivers/dax/dax.c uses an alive flag without any mutexes, atomics or > anything. So I don't know if it's racy or perhaps correct for other reasons. > > 2) drivers/char/hw_random has a drop_current_rng that looks like it > could easily be racy with the get_current_rng in the userspace flow. > > 3) A couple of drivers drivers/char/tpm doesn't seem to have any > protection at all and appears like they would continue to use io > operations even after the they may get unmapped because the char device > persists. > > So I'm not sure where you'd find a driver that does it correctly and in > a simpler way.. > > Another thing: based on comments in [1], a lot of people don't seem to > realize that cdev instances can persist long after cdev_del so it's > probably very common for drivers to get this wrong. > > Logan > > [1] https://lists.01.org/pipermail/linux-nvdimm/2017-February/009001.html -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver
On 01/03/17 03:26 PM, Keith Busch wrote: > I think this is from using the managed device resource API to request the > irq actions. The scope of the resource used to be tied to the pci_dev's > dev, but now it's the new switchec class dev, which has a different > lifetime while open references exist, so it's not releasing the irq's. The scope of the IRQ was originally tied to the pci_dev. Then in v4 I tied it to the switchtec device in order to try and keep using the pci device after unbind. This didn't work, so I switched it back to using the pci_dev. (This seems to be the way most drivers work anyway.) > One thing about the BUG_ON that is confusing me is how it's getting > to free_msi_irq's BUG in v4 or v5. I don't see any part releasing the > allocated ones. Maybe the devres API is harder to use than having the > driver manage all the resources... free_msi_irqs seems to be called via pci_disable_device in pcim_release which devres will call during release of the PCI device and before all the references to the pci_dev are freed (I tried adding an extra get_device which gets put in the child devices release -- this didn't work): [ 1079.845616] Call Trace: [ 1079.845652] ? pcim_release+0x35/0x96 [ 1079.845691] ? release_nodes+0x15b/0x17c [ 1079.845730] ? device_release_driver_internal+0x12d/0x1cb [ 1079.845771] ? unbind_store+0x59/0x89 [ 1079.845809] ? kernfs_fop_write+0xe7/0x129 [ 1079.845847] ? __vfs_write+0x1c/0xa2 [ 1079.845885] ? kmem_cache_alloc+0xc5/0x131 [ 1079.845923] ? fput+0xd/0x7d [ 1079.845958] ? filp_close+0x5a/0x61 [ 1079.845993] ? vfs_write+0xa2/0xe4 [ 1079.846028] ? SyS_write+0x48/0x73 [ 1079.846066] ? entry_SYSCALL_64_fastpath+0x13/0x94 v5 is correct because it registers the irqs against the pci_dev (with devm_request_irq) and thus they get freed in time as part of the devres unwind. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver
On 01/03/17 02:41 PM, Bjorn Helgaas wrote: > I don't think this is indicating a bug in the PCI core (although I do > think a BUG_ON() here is an excessive response). I think it's an > indication that the driver didn't disconnect its ISR. Without more > details of the failure it's hard to tell if the BUG_ON is a symptom of > a problem in the driver or what. Yes, my assumption was that when you force an unbind on the PCI core, it's designed to stop using the PCI device right away even if there are users using it. Thus it becomes the drivers responsibility to handle this situation. > An "alive" flag feels racy, and I can't tell if it's really the best > way to deal with this, or if it's just avoiding the issue. There must > be other drivers with the same cleanup issue -- do they handle it the > same way? I haven't done a comprehensive search, but it's very common for people to use (and this is what I've adopted again in v5): devm_request_irq(>dev, ...) In this way, the IRQs are released with the pci_dev (or often platform) and thus the BUG_ON never hits. However, it means any user space program waiting on an IRQ (like via a cdev call) will hang unless handled with other means. Exactly what those means are seems driver specific and not always obvious. I wouldn't be surprised if a lot of drivers get this aspect wrong. A couple examples I've looked at: 1) drivers/dax/dax.c uses an alive flag without any mutexes, atomics or anything. So I don't know if it's racy or perhaps correct for other reasons. 2) drivers/char/hw_random has a drop_current_rng that looks like it could easily be racy with the get_current_rng in the userspace flow. 3) A couple of drivers drivers/char/tpm doesn't seem to have any protection at all and appears like they would continue to use io operations even after the they may get unmapped because the char device persists. So I'm not sure where you'd find a driver that does it correctly and in a simpler way.. Another thing: based on comments in [1], a lot of people don't seem to realize that cdev instances can persist long after cdev_del so it's probably very common for drivers to get this wrong. Logan [1] https://lists.01.org/pipermail/linux-nvdimm/2017-February/009001.html >> To solve this, we've moved the pci release code back into the >> unregister function and reintroduced an alive flag. This time, >> however, the alive flag is protected by mrpc_mutex and we're very >> careful about what happens to devices still in use (they should >> all be released through the timeout path and an ENODEV error >> returned to userspace; while new commands are blocked with the >> same error). -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver
> This driver doesn't have anything to do with the PCI core, other than
> using the pci_register_driver() interface (just like all other drivers
> for PCI-connected devices), so drivers/pci doesn't really feel like
> the right place for it. Putting it in drivers/pci leads to the sort
> of confusion you mentioned above ("To make this entirely clear ...").
>
> Would drivers/perf or drivers/misc/switchtec/ be possible places for
> it?
I made a similar argument when we made the decision of where to put the
code. In the end, the device _is_ a PCI Switch and someone going through
menuconfig or the source tree would probably look there first.
As for drivers/perf, our device does a fair bit more than performance
counters so it doesn't seem like it really fits in there. drivers/misc
just seems like a dumping ground which we'd prefer not to contribute to.
We also considered drivers/char (seeing it exposes a char device), but
that also seems like a dumping ground with stuff that belongs and other
stuff that just ended up stuck between the cracks.
If you still feel strongly about this we can move it into misc, but I
think from an organizational perspective pci/switch makes a bit more sense.
In any case, I also wish we could have had this discussion 3 months ago
when we posted the RFC and not when I have people pushing to get this
merged.
Thanks,
Logan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/4] switchtec: Add user interface documentation
This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.com> Reviewed-by: Wei Zhang <wzh...@fb.com> Reviewed-by: Jens Axboe <ax...@fb.com> --- Documentation/switchtec.txt | 53 + MAINTAINERS | 1 + 2 files changed, 54 insertions(+) create mode 100644 Documentation/switchtec.txt diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt new file mode 100644 index 000..4bced4c --- /dev/null +++ b/Documentation/switchtec.txt @@ -0,0 +1,53 @@ + +Linux Switchtec Support + + +Microsemi's "Switchtec" line of PCI switch devices is already +supported by the kernel with standard PCI switch drivers. However, the +Switchtec device advertises a special management endpoint which +enables some additional functionality. This includes: + +* Packet and Byte Counters +* Firmware Upgrades +* Event and Error logs +* Querying port link status +* Custom user firmware commands + +The switchtec kernel module implements this functionality. + + +Interface += + +The primary means of communicating with the Switchtec management firmware is +through the Memory-mapped Remote Procedure Call (MRPC) interface. +Commands are submitted to the interface with a 4-byte command +identifier and up to 1KB of command specific data. The firmware will +respond with a 4 bytes return code and up to 1KB of command specific +data. The interface only processes a single command at a time. + + +Userspace Interface +=== + +The MRPC interface will be exposed to userspace through a simple char +device: /dev/switchtec#, one for each management endpoint in the system. + +The char device has the following semantics: + +* A write must consist of at least 4 bytes and no more than 1028 bytes. + The first four bytes will be interpreted as the command to run and + the remainder will be used as the input data. A write will send the + command to the firmware to begin processing. + +* Each write must be followed by exactly one read. Any double write will + produce an error and any read that doesn't follow a write will + produce an error. + +* A read will block until the firmware completes the command and return + the four bytes of status plus up to 1024 bytes of output data. (The + length will be specified by the size parameter of the read call -- + reading less than 4 bytes will produce an error. + +* The poll call will also be supported for userspace applications that + need to do other things while waiting for the command to complete. diff --git a/MAINTAINERS b/MAINTAINERS index a57686f..aa702b0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9512,6 +9512,7 @@ M:Stephen Bates <stephen.ba...@microsemi.com> M: Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained +F: Documentation/switchtec.txt F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/4] New Microsemi PCI Switch Management Driver
Changes since v4: * Turns out pushing the pci release code into the device release function didn't work as I would have liked. If you try to unbind the device with an instance open, then you hit a kernel bug at drivers/pci/msi.c:371. (This didn't occur in v3.) To solve this, we've moved the pci release code back into the unregister function and reintroduced an alive flag. This time, however, the alive flag is protected by mrpc_mutex and we're very careful about what happens to devices still in use (they should all be released through the timeout path and an ENODEV error returned to userspace; while new commands are blocked with the same error). Changes since v3: * Removed stdev_is_alive and moved pci deinit functions into the device release function which only occurs after all cdev instances are closed. (per Bjorn) * Reduced locking in read/write functions (per Bjorn) * Use pci_alloc_irq_vectors to vastly improve ISR initialization (Bjorn) * A few other minor nits and cleanup as noticed by Bjorn Changes since v2: * Collected reviewed and tested tags * Very minor fix to the error path in the create function Changes since v1: * Rebased onto 4.10-rc6 (cleanly) * Split the patch into a few more easily digestible patches (as suggested by Greg Kroah-Hartman) * Folded switchtec.c into switchtec.h (per Greg) * Fixed a bunch of 32bit build warnings caught by the kbuild test robot * Fixed some issues in the documentation so it has a proper reStructredText format (as noted by Jonathan Corbet) * Fixed padding and sizes in the IOCTL structures as noticed by Emil Velikov and used pahole to verify their consistency across 32 and 64 bit builds * Reworked one of the IOCTL interfaces to be more future proof (per Emil). Changes since RFC: * Fixed incorrect use of the drive model as pointed out by Greg Kroah-Hartman * Used devm functions as suggested by Keith Busch * Added a handful of sysfs attributes to the switchtec class * Added a handful of IOCTLs to the switchtec device * A number of miscellaneous bug fixes -- Hi, This is a continuation of the RFC we posted lasted month [1] which proposes a management driver for Microsemi's Switchtec line of PCI switches. This hardware is still looking to be used in the Open Compute Platform To make this entirely clear: the Switchtec products are compliant with the PCI specifications and are supported today with the standard in-kernel driver. However, these devices also expose a management endpoint on a separate PCI function address which can be used to perform some advanced operations. This is a driver for that function. See the patch for more information. Since the RFC, we've made the changes requested by Greg Kroah-Hartman and Keith Busch, and we've also fleshed out a number of features. We've added a couple of IOCTLs and sysfs attributes which are documented in the patch. Significant work has also been done on the userspace tool which is available under a GPL license at [2]. We've also had testing done by some of the interested parties. We hope to see this work included in either 4.11 or 4.12 assuming a smooth review process. The patch is based off of the v4.10-rc6 release. Thanks for your review, Logan [1] https://www.spinics.net/lists/linux-pci/msg56897.html [2] https://github.com/sbates130272/switchtec-user Logan Gunthorpe (4): MicroSemi Switchtec management interface driver switchtec: Add user interface documentation switchtec: Add sysfs attributes to the Switchtec driver switchtec: Add IOCTLs to the Switchtec driver Documentation/ABI/testing/sysfs-class-switchtec | 96 ++ Documentation/ioctl/ioctl-number.txt|1 + Documentation/switchtec.txt | 80 ++ MAINTAINERS | 11 + drivers/pci/Kconfig |1 + drivers/pci/Makefile|1 + drivers/pci/switch/Kconfig | 13 + drivers/pci/switch/Makefile |1 + drivers/pci/switch/switchtec.c | 1535 +++ include/uapi/linux/switchtec_ioctl.h| 132 ++ 10 files changed, 1871 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec create mode 100644 Documentation/switchtec.txt create mode 100644 drivers/pci/switch/Kconfig create mode 100644 drivers/pci/switch/Makefile create mode 100644 drivers/pci/switch/switchtec.c create mode 100644 include/uapi/linux/switchtec_ioctl.h -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/4] MicroSemi Switchtec management interface driver
Microsemi's "Switchtec" line of PCI switch devices is already well
supported by the kernel with standard PCI switch drivers. However, the
Switchtec device advertises a special management endpoint with a separate
PCI function address and class code. This endpoint enables some additional
functionality which includes:
* Packet and Byte Counters
* Switch Firmware Upgrades
* Event and Error logs
* Querying port link status
* Custom user firmware commands
This patch introduces the switchtec kernel module which provides
PCI driver that exposes a char device. The char device provides
userspace access to this interface through read, write and (optionally)
poll calls.
A userspace tool and library which utilizes this interface is available
at [1]. This tool takes inspiration (and borrows some code) from
nvme-cli [2]. The tool is largely complete at this time but additional
features may be added in the future.
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.com>
Reviewed-by: Wei Zhang <wzh...@fb.com>
Reviewed-by: Jens Axboe <ax...@fb.com>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
MAINTAINERS| 8 +
drivers/pci/Kconfig| 1 +
drivers/pci/Makefile | 1 +
drivers/pci/switch/Kconfig | 13 +
drivers/pci/switch/Makefile| 1 +
drivers/pci/switch/switchtec.c | 955 +
6 files changed, 979 insertions(+)
create mode 100644 drivers/pci/switch/Kconfig
create mode 100644 drivers/pci/switch/Makefile
create mode 100644 drivers/pci/switch/switchtec.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 527d137..a57686f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9506,6 +9506,14 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/aardvark-pci.txt
F: drivers/pci/host/pci-aardvark.c
+PCI DRIVER FOR MICROSEMI SWITCHTEC
+M: Kurt Schwemmer <kurt.schwem...@microsemi.com>
+M: Stephen Bates <stephen.ba...@microsemi.com>
+M: Logan Gunthorpe <log...@deltatee.com>
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/pci/switch/switchtec*
+
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
L: linux-te...@vger.kernel.org
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 6555eb7..f72e8c5 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -133,3 +133,4 @@ config PCI_HYPERV
source "drivers/pci/hotplug/Kconfig"
source "drivers/pci/host/Kconfig"
+source "drivers/pci/switch/Kconfig"
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 8db5079..15b46dd 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -68,3 +68,4 @@ ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
# PCI host controller drivers
obj-y += host/
+obj-y += switch/
diff --git a/drivers/pci/switch/Kconfig b/drivers/pci/switch/Kconfig
new file mode 100644
index 000..4c49648
--- /dev/null
+++ b/drivers/pci/switch/Kconfig
@@ -0,0 +1,13 @@
+menu "PCI switch controller drivers"
+ depends on PCI
+
+config PCI_SW_SWITCHTEC
+ tristate "MicroSemi Switchtec PCIe Switch Management Driver"
+ help
+Enables support for the management interface for the MicroSemi
+Switchtec series of PCIe switches. Supports userspace access
+to submit MRPC commands to the switch via /dev/switchtecX
+devices. See for more
+information.
+
+endmenu
diff --git a/drivers/pci/switch/Makefile b/drivers/pci/switch/Makefile
new file mode 100644
index 000..37d8cfb
--- /dev/null
+++ b/drivers/pci/switch/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PCI_SW_SWITCHTEC) += switchtec.o
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
new file mode 100644
index 000..4aaf89b
--- /dev/null
+++ b/drivers/pci/switch/switchtec.c
@@ -0,0 +1,955 @@
+/*
+ * Microsemi Switchtec(tm) PCIe Management Driver
+ * Copyright (c) 2017, Microsemi Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCIe Management Driver");
+MODULE_VERSION("0.1");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Microsemi Corporation"
[PATCH v5 4/4] switchtec: Add IOCTLs to the Switchtec driver
This patch introduces a couple of special IOCTLs which are provided to:
* Inform userspace of firmware partition locations
* Pass event counts and allow userspace to wait on events
* Translate between PFF numbers used by the switch to
port numbers.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.com>
Reviewed-by: Wei Zhang <wzh...@fb.com>
Reviewed-by: Jens Axboe <ax...@fb.com>
---
Documentation/ioctl/ioctl-number.txt | 1 +
Documentation/switchtec.txt | 27 ++
MAINTAINERS | 1 +
drivers/pci/switch/switchtec.c | 467 +++
include/uapi/linux/switchtec_ioctl.h | 132 ++
5 files changed, 628 insertions(+)
create mode 100644 include/uapi/linux/switchtec_ioctl.h
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 81c7f2b..032b33c 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -191,6 +191,7 @@ Code Seq#(hex) Include FileComments
'W'00-1F linux/watchdog.hconflict!
'W'00-1F linux/wanrouter.h conflict! (pre 3.9)
'W'00-3F sound/asound.h conflict!
+'W'40-5F drivers/pci/switch/switchtec.c
'X'all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h
and include/linux/falloc.h
diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt
index 4bced4c..a0a9c7b 100644
--- a/Documentation/switchtec.txt
+++ b/Documentation/switchtec.txt
@@ -51,3 +51,30 @@ The char device has the following semantics:
* The poll call will also be supported for userspace applications that
need to do other things while waiting for the command to complete.
+
+The following IOCTLs are also supported by the device:
+
+* SWITCHTEC_IOCTL_FLASH_INFO - Retrieve firmware length and number
+ of partitions in the device.
+
+* SWITCHTEC_IOCTL_FLASH_PART_INFO - Retrieve address and lengeth for
+ any specified partition in flash.
+
+* SWITCHTEC_IOCTL_EVENT_SUMMARY - Read a structure of bitmaps
+ indicating all uncleared events.
+
+* SWITCHTEC_IOCTL_EVENT_CTL - Get the current count, clear and set flags
+ for any event. This ioctl takes in a switchtec_ioctl_event_ctl struct
+ with the event_id, index and flags set (index being the partition or PFF
+ number for non-global events). It returns whether the event has
+ occurred, the number of times and any event specific data. The flags
+ can be used to clear the count or enable and disable actions to
+ happen when the event occurs.
+ By using the SWITCHTEC_IOCTL_EVENT_FLAG_EN_POLL flag,
+ you can set an event to trigger a poll command to return with
+ POLLPRI. In this way, userspace can wait for events to occur.
+
+* SWITCHTEC_IOCTL_PFF_TO_PORT and SWITCHTEC_IOCTL_PORT_TO_PFF convert
+ between PCI Function Framework number (used by the event system)
+ and Switchtec Logic Port ID and Partition number (which is more
+ user friendly).
diff --git a/MAINTAINERS b/MAINTAINERS
index 6fed938..c1a9a30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9515,6 +9515,7 @@ S:Maintained
F: Documentation/switchtec.txt
F: Documentation/ABI/testing/sysfs-class-switchtec
F: drivers/pci/switch/switchtec*
+F: include/uapi/linux/switchtec_ioctl.h
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 2e47d79..94384e7 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -13,6 +13,8 @@
*
*/
+#include
+
#include
#include
#include
@@ -740,6 +742,417 @@ static unsigned int switchtec_dev_poll(struct file *filp,
poll_table *wait)
return ret;
}
+static int ioctl_flash_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+
+ info.flash_length = ioread32(>flash_length);
+ info.num_partitions = SWITCHTEC_IOCTL_NUM_PARTITIONS;
+
+ if (copy_to_user(uinfo, , sizeof(info)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static void set_fw_info_part(struct switchtec_ioctl_flash_part_info *info,
+struct partition_info __iomem *pi)
+{
+ info->address = ioread32(>address);
+ info->length = ioread32(>length);
+}
+
+static int ioctl_flash_part_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_part_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_part_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+ u32 active_addr = -1;
+
+ if (copy
[PATCH v4 3/4] switchtec: Add sysfs attributes to the Switchtec driver
This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.com> Reviewed-by: Wei Zhang <wzh...@fb.com> Reviewed-by: Jens Axboe <ax...@fb.com> Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- Documentation/ABI/testing/sysfs-class-switchtec | 96 MAINTAINERS | 1 + drivers/pci/switch/switchtec.c | 113 3 files changed, 210 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec diff --git a/Documentation/ABI/testing/sysfs-class-switchtec b/Documentation/ABI/testing/sysfs-class-switchtec new file mode 100644 index 000..48cb4c1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-switchtec @@ -0,0 +1,96 @@ +switchtec - Microsemi Switchtec PCI Switch Management Endpoint + +For details on this subsystem look at Documentation/switchtec.txt. + +What: /sys/class/switchtec +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: The switchtec class subsystem folder. + Each registered switchtec driver is represented by a switchtecX + subfolder (X being an integer >= 0). + + +What: /sys/class/switchtec/switchtec[0-9]+/component_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component identifier as stored in the hardware (eg. PM8543) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component revision stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/device_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Device version as stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/fw_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Currently running firmware version (read only) +Values:integer (in hexadecimal). + + +What: /sys/class/switchtec/switchtec[0-9]+/partition +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Partition number for this device in the switch (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/partition_count +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Total number of partitions in the switch (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product identifier as stored in the hardware (eg. PSX 48XG3) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product revision stored in the hardware (eg. RevB) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. diff --git a/MAINTAINERS b/MAINTAINERS index aa702b0..6fed938 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9513,6 +9513,7 @@ M:Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained F: Documentation/switchtec.txt +F: Documentation/ABI/testing/sysfs-class-switchtec F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA diff --gi
[PATCH v4 4/4] switchtec: Add IOCTLs to the Switchtec driver
This patch introduces a couple of special IOCTLs which are provided to:
* Inform userspace of firmware partition locations
* Pass event counts and allow userspace to wait on events
* Translate between PFF numbers used by the switch to
port numbers.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.com>
Reviewed-by: Wei Zhang <wzh...@fb.com>
Reviewed-by: Jens Axboe <ax...@fb.com>
---
Documentation/ioctl/ioctl-number.txt | 1 +
Documentation/switchtec.txt | 27 ++
MAINTAINERS | 1 +
drivers/pci/switch/switchtec.c | 467 +++
include/uapi/linux/switchtec_ioctl.h | 132 ++
5 files changed, 628 insertions(+)
create mode 100644 include/uapi/linux/switchtec_ioctl.h
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 81c7f2b..032b33c 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -191,6 +191,7 @@ Code Seq#(hex) Include FileComments
'W'00-1F linux/watchdog.hconflict!
'W'00-1F linux/wanrouter.h conflict! (pre 3.9)
'W'00-3F sound/asound.h conflict!
+'W'40-5F drivers/pci/switch/switchtec.c
'X'all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h
and include/linux/falloc.h
diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt
index 4bced4c..a0a9c7b 100644
--- a/Documentation/switchtec.txt
+++ b/Documentation/switchtec.txt
@@ -51,3 +51,30 @@ The char device has the following semantics:
* The poll call will also be supported for userspace applications that
need to do other things while waiting for the command to complete.
+
+The following IOCTLs are also supported by the device:
+
+* SWITCHTEC_IOCTL_FLASH_INFO - Retrieve firmware length and number
+ of partitions in the device.
+
+* SWITCHTEC_IOCTL_FLASH_PART_INFO - Retrieve address and lengeth for
+ any specified partition in flash.
+
+* SWITCHTEC_IOCTL_EVENT_SUMMARY - Read a structure of bitmaps
+ indicating all uncleared events.
+
+* SWITCHTEC_IOCTL_EVENT_CTL - Get the current count, clear and set flags
+ for any event. This ioctl takes in a switchtec_ioctl_event_ctl struct
+ with the event_id, index and flags set (index being the partition or PFF
+ number for non-global events). It returns whether the event has
+ occurred, the number of times and any event specific data. The flags
+ can be used to clear the count or enable and disable actions to
+ happen when the event occurs.
+ By using the SWITCHTEC_IOCTL_EVENT_FLAG_EN_POLL flag,
+ you can set an event to trigger a poll command to return with
+ POLLPRI. In this way, userspace can wait for events to occur.
+
+* SWITCHTEC_IOCTL_PFF_TO_PORT and SWITCHTEC_IOCTL_PORT_TO_PFF convert
+ between PCI Function Framework number (used by the event system)
+ and Switchtec Logic Port ID and Partition number (which is more
+ user friendly).
diff --git a/MAINTAINERS b/MAINTAINERS
index 6fed938..c1a9a30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9515,6 +9515,7 @@ S:Maintained
F: Documentation/switchtec.txt
F: Documentation/ABI/testing/sysfs-class-switchtec
F: drivers/pci/switch/switchtec*
+F: include/uapi/linux/switchtec_ioctl.h
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 2e3a45b..18286d3 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -13,6 +13,8 @@
*
*/
+#include
+
#include
#include
#include
@@ -717,6 +719,417 @@ static unsigned int switchtec_dev_poll(struct file *filp,
poll_table *wait)
return ret;
}
+static int ioctl_flash_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+
+ info.flash_length = ioread32(>flash_length);
+ info.num_partitions = SWITCHTEC_IOCTL_NUM_PARTITIONS;
+
+ if (copy_to_user(uinfo, , sizeof(info)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static void set_fw_info_part(struct switchtec_ioctl_flash_part_info *info,
+struct partition_info __iomem *pi)
+{
+ info->address = ioread32(>address);
+ info->length = ioread32(>length);
+}
+
+static int ioctl_flash_part_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_part_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_part_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+ u32 active_addr = -1;
+
+ if (copy
[PATCH v4 0/4] New Microsemi PCI Switch Management Driver
Changes since v3: * Removed stdev_is_alive and moved pci deinit functions into the device release function which only occurs after all cdev instances are closed. (per Bjorn) * Reduced locking in read/write functions (per Bjorn) * Use pci_alloc_irq_vectors to vastly improve ISR initialization (Bjorn) * A few other minor nits and cleanup as noticed by Bjorn Changes since v2: * Collected reviewed and tested tags * Very minor fix to the error path in the create function Changes since v1: * Rebased onto 4.10-rc6 (cleanly) * Split the patch into a few more easily digestible patches (as suggested by Greg Kroah-Hartman) * Folded switchtec.c into switchtec.h (per Greg) * Fixed a bunch of 32bit build warnings caught by the kbuild test robot * Fixed some issues in the documentation so it has a proper reStructredText format (as noted by Jonathan Corbet) * Fixed padding and sizes in the IOCTL structures as noticed by Emil Velikov and used pahole to verify their consistency across 32 and 64 bit builds * Reworked one of the IOCTL interfaces to be more future proof (per Emil). Changes since RFC: * Fixed incorrect use of the drive model as pointed out by Greg Kroah-Hartman * Used devm functions as suggested by Keith Busch * Added a handful of sysfs attributes to the switchtec class * Added a handful of IOCTLs to the switchtec device * A number of miscellaneous bug fixes -- Hi, This is a continuation of the RFC we posted lasted month [1] which proposes a management driver for Microsemi's Switchtec line of PCI switches. This hardware is still looking to be used in the Open Compute Platform To make this entirely clear: the Switchtec products are compliant with the PCI specifications and are supported today with the standard in-kernel driver. However, these devices also expose a management endpoint on a separate PCI function address which can be used to perform some advanced operations. This is a driver for that function. See the patch for more information. Since the RFC, we've made the changes requested by Greg Kroah-Hartman and Keith Busch, and we've also fleshed out a number of features. We've added a couple of IOCTLs and sysfs attributes which are documented in the patch. Significant work has also been done on the userspace tool which is available under a GPL license at [2]. We've also had testing done by some of the interested parties. We hope to see this work included in either 4.11 or 4.12 assuming a smooth review process. The patch is based off of the v4.10-rc6 release. Thanks for your review, Logan [1] https://www.spinics.net/lists/linux-pci/msg56897.html [2] https://github.com/sbates130272/switchtec-user Logan Gunthorpe (4): MicroSemi Switchtec management interface driver switchtec: Add user interface documentation switchtec: Add sysfs attributes to the Switchtec driver switchtec: Add IOCTLs to the Switchtec driver Documentation/ABI/testing/sysfs-class-switchtec | 96 ++ Documentation/ioctl/ioctl-number.txt|1 + Documentation/switchtec.txt | 80 ++ MAINTAINERS | 11 + drivers/pci/Kconfig |1 + drivers/pci/Makefile|1 + drivers/pci/switch/Kconfig | 13 + drivers/pci/switch/Makefile |1 + drivers/pci/switch/switchtec.c | 1503 +++ include/uapi/linux/switchtec_ioctl.h| 132 ++ 10 files changed, 1839 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec create mode 100644 Documentation/switchtec.txt create mode 100644 drivers/pci/switch/Kconfig create mode 100644 drivers/pci/switch/Makefile create mode 100644 drivers/pci/switch/switchtec.c create mode 100644 include/uapi/linux/switchtec_ioctl.h -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/4] MicroSemi Switchtec management interface driver
Microsemi's "Switchtec" line of PCI switch devices is already well
supported by the kernel with standard PCI switch drivers. However, the
Switchtec device advertises a special management endpoint with a separate
PCI function address and class code. This endpoint enables some additional
functionality which includes:
* Packet and Byte Counters
* Switch Firmware Upgrades
* Event and Error logs
* Querying port link status
* Custom user firmware commands
This patch introduces the switchtec kernel module which provides
PCI driver that exposes a char device. The char device provides
userspace access to this interface through read, write and (optionally)
poll calls.
A userspace tool and library which utilizes this interface is available
at [1]. This tool takes inspiration (and borrows some code) from
nvme-cli [2]. The tool is largely complete at this time but additional
features may be added in the future.
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.com>
Reviewed-by: Wei Zhang <wzh...@fb.com>
Reviewed-by: Jens Axboe <ax...@fb.com>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
MAINTAINERS| 8 +
drivers/pci/Kconfig| 1 +
drivers/pci/Makefile | 1 +
drivers/pci/switch/Kconfig | 13 +
drivers/pci/switch/Makefile| 1 +
drivers/pci/switch/switchtec.c | 923 +
6 files changed, 947 insertions(+)
create mode 100644 drivers/pci/switch/Kconfig
create mode 100644 drivers/pci/switch/Makefile
create mode 100644 drivers/pci/switch/switchtec.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 527d137..a57686f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9506,6 +9506,14 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/aardvark-pci.txt
F: drivers/pci/host/pci-aardvark.c
+PCI DRIVER FOR MICROSEMI SWITCHTEC
+M: Kurt Schwemmer <kurt.schwem...@microsemi.com>
+M: Stephen Bates <stephen.ba...@microsemi.com>
+M: Logan Gunthorpe <log...@deltatee.com>
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/pci/switch/switchtec*
+
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
L: linux-te...@vger.kernel.org
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 6555eb7..f72e8c5 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -133,3 +133,4 @@ config PCI_HYPERV
source "drivers/pci/hotplug/Kconfig"
source "drivers/pci/host/Kconfig"
+source "drivers/pci/switch/Kconfig"
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 8db5079..15b46dd 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -68,3 +68,4 @@ ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
# PCI host controller drivers
obj-y += host/
+obj-y += switch/
diff --git a/drivers/pci/switch/Kconfig b/drivers/pci/switch/Kconfig
new file mode 100644
index 000..4c49648
--- /dev/null
+++ b/drivers/pci/switch/Kconfig
@@ -0,0 +1,13 @@
+menu "PCI switch controller drivers"
+ depends on PCI
+
+config PCI_SW_SWITCHTEC
+ tristate "MicroSemi Switchtec PCIe Switch Management Driver"
+ help
+Enables support for the management interface for the MicroSemi
+Switchtec series of PCIe switches. Supports userspace access
+to submit MRPC commands to the switch via /dev/switchtecX
+devices. See for more
+information.
+
+endmenu
diff --git a/drivers/pci/switch/Makefile b/drivers/pci/switch/Makefile
new file mode 100644
index 000..37d8cfb
--- /dev/null
+++ b/drivers/pci/switch/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PCI_SW_SWITCHTEC) += switchtec.o
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
new file mode 100644
index 000..f5813e0
--- /dev/null
+++ b/drivers/pci/switch/switchtec.c
@@ -0,0 +1,923 @@
+/*
+ * Microsemi Switchtec(tm) PCIe Management Driver
+ * Copyright (c) 2017, Microsemi Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCIe Management Driver");
+MODULE_VERSION("0.1");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Microsemi Corporation"
[PATCH v4 2/4] switchtec: Add user interface documentation
This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.com> Reviewed-by: Wei Zhang <wzh...@fb.com> Reviewed-by: Jens Axboe <ax...@fb.com> --- Documentation/switchtec.txt | 53 + MAINTAINERS | 1 + 2 files changed, 54 insertions(+) create mode 100644 Documentation/switchtec.txt diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt new file mode 100644 index 000..4bced4c --- /dev/null +++ b/Documentation/switchtec.txt @@ -0,0 +1,53 @@ + +Linux Switchtec Support + + +Microsemi's "Switchtec" line of PCI switch devices is already +supported by the kernel with standard PCI switch drivers. However, the +Switchtec device advertises a special management endpoint which +enables some additional functionality. This includes: + +* Packet and Byte Counters +* Firmware Upgrades +* Event and Error logs +* Querying port link status +* Custom user firmware commands + +The switchtec kernel module implements this functionality. + + +Interface += + +The primary means of communicating with the Switchtec management firmware is +through the Memory-mapped Remote Procedure Call (MRPC) interface. +Commands are submitted to the interface with a 4-byte command +identifier and up to 1KB of command specific data. The firmware will +respond with a 4 bytes return code and up to 1KB of command specific +data. The interface only processes a single command at a time. + + +Userspace Interface +=== + +The MRPC interface will be exposed to userspace through a simple char +device: /dev/switchtec#, one for each management endpoint in the system. + +The char device has the following semantics: + +* A write must consist of at least 4 bytes and no more than 1028 bytes. + The first four bytes will be interpreted as the command to run and + the remainder will be used as the input data. A write will send the + command to the firmware to begin processing. + +* Each write must be followed by exactly one read. Any double write will + produce an error and any read that doesn't follow a write will + produce an error. + +* A read will block until the firmware completes the command and return + the four bytes of status plus up to 1024 bytes of output data. (The + length will be specified by the size parameter of the read call -- + reading less than 4 bytes will produce an error. + +* The poll call will also be supported for userspace applications that + need to do other things while waiting for the command to complete. diff --git a/MAINTAINERS b/MAINTAINERS index a57686f..aa702b0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9512,6 +9512,7 @@ M:Stephen Bates <stephen.ba...@microsemi.com> M: Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained +F: Documentation/switchtec.txt F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] MicroSemi Switchtec management interface driver
Hey Bjorn,
Thanks for the thorough review. It definitely helped a lot to make the
code as good as it can be.
I've made all of the changes you suggested. I'm just going to do a bit
more testing and then post a v4. See my responses to all of your
feedback bellow.
Logan
On 23/02/17 05:35 PM, Bjorn Helgaas wrote:
> Would it make any sense to integrate this with the perf tool? It
> looks like switchtec-user measures bandwidth and latency, which sounds
> sort of perf-ish.
That would be cool but lets file that under potential future work. This
driver also enables more than bandwidth and latency so it's still
required for us.
>> +MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCI-E Management Driver");
>
> Nit: s/PCI-E/PCIe/
>
Fixed.
>> +MODULE_VERSION("0.1");
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Microsemi Corporation");
>> +
>> +static int max_devices = 16;
>
> This static initialization is slightly misleading because
> switchtec_init() immediately sets max_devices to at least 256.
Oops copied that from dax without thinking. I've just removed the max()
call in the init function.
>> +atomic_t event_cnt;
>
> Why is this atomic_t? You only do an atomic_set() (in stdev_create())
> and atomic_reads() -- no writes other than the initial one. So I'm
> not sure what value atomic_t brings.
If you looked at a following patch in the series you'd see that there's
an atomic_inc in the ISR. The splitting of the series wasn't as precise
as it maybe should have been and thus this became a bit confusing.
>> +memcpy_fromio(stuser->data, >mmio_mrpc->output_data,
>> + sizeof(stuser->data));
>
> Apparently you always get 1K of data back, no matter what?
Yes, sort of unfortunately. Because these transactions can occur before
the user actually does the read, we don't know how much data the user
wants. This may be a performance improvement in the future (ie. if the
user reads before the MRPC transaction comes back, then only read the
requested amount). But we will leave it this way for now.
>> +if (!stdev_is_alive(stdev))
>> +return -ENXIO;
>
> What exactly does this protect against? Is it OK if stdev_is_alive()
> becomes false immediately after we check?
Yup, you're right: that's racy. Turns out cleanup is hard and I've
learned a lot even in the short time since I wrote this code. I've
gotten rid of stdev_is_alive and moved the pci cleanup code into the
device's release function so they won't occur until the last user closes
the cdev. I think that should work better but please let me know if you
see an issue with this.
>> +
>> +if (size < sizeof(stuser->cmd) ||
>> +size > sizeof(stuser->cmd) + SWITCHTEC_MRPC_PAYLOAD_SIZE)
>
> I think I would use "sizeof(stuser->data)" instead of
> SWITCHTEC_MRPC_PAYLOAD_SIZE so it matches what mrpc_complete_cmd()
> does. Same below in switchtec_dev_read().
Ok.
> mrpc_mutex doesn't protect the stuser things, does it? If not, you
> could do this without the gotos. And I think it's a little easier to
> be confident there are no buffer overruns:
I was using the mutex to protect stuser->state as well. But I've made
your changes and just adjusted stuser->state to be atomic and I think
this should be just as good.
>> +static int switchtec_init_msix_isr(struct switchtec_dev *stdev)
>> +{
>> +struct pci_dev *pdev = stdev->pdev;
>> +int rc, i, msix_count, node;
>> +
>> +node = dev_to_node(>dev);
>
> Unused?
Yup, I've removed it.
>> +for (i = 0; i < ARRAY_SIZE(stdev->msix); ++i)
>> +stdev->msix[i].entry = i;
>> +
>> +msix_count = pci_enable_msix_range(pdev, stdev->msix, 1,
>> + ARRAY_SIZE(stdev->msix));
>> +if (msix_count < 0)
>> +return msix_count;
>
> Maybe this could be simplified by using pci_alloc_irq_vectors()?
Yup! I wasn't aware of that function. It's a _huge_ improvement. Thanks.
Still I'd really appreciate a quick re-review after I post v4 just to
make sure I got it correct.
>> +stdev->event_irq = ioread32(>mmio_part_cfg->vep_vector_number);
>> +if (stdev->event_irq < 0 || stdev->event_irq >= msix_count) {
>> +rc = -EFAULT;
>> +goto err_msix_request;
>> +}
>
> Not sure what this is doing, but you immediately overwrite
> stdev->event_irq below. If you're using it as just a temporary above
> for doing some validation, I would just use a local variable to avoid
> the connection with stdev->event_irq.
Yes, I made this temporary.
>> +stdev->event_irq = stdev->msix[stdev->event_irq].vector;
>
> Oh, I guess you allocate several MSI-X vectors, but you only actually
> use one of them? Why is that? I was confused about why you allocate
> several vectors, but there's only one devm_request_irq() call below.
The event_irq is configurable in hardware and won't necessarily be the
first irq available. (It should always be in the first four.) As I
understand it, we need to allocate all of
[PATCH v3 4/4] switchtec: Add IOCTLs to the Switchtec driver
This patch introduces a couple of special IOCTLs which are provided to:
* Inform userspace of firmware partition locations
* Pass event counts and allow userspace to wait on events
* Translate between PFF numbers used by the switch to
port numbers.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.com>
Reviewed-by: Wei Zhang <wzh...@fb.com>
Reviewed-by: Jens Axboe <ax...@fb.com>
---
Documentation/ioctl/ioctl-number.txt | 1 +
Documentation/switchtec.txt | 27 ++
MAINTAINERS | 1 +
drivers/pci/switch/switchtec.c | 467 +++
include/uapi/linux/switchtec_ioctl.h | 132 ++
5 files changed, 628 insertions(+)
create mode 100644 include/uapi/linux/switchtec_ioctl.h
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 81c7f2b..032b33c 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -191,6 +191,7 @@ Code Seq#(hex) Include FileComments
'W'00-1F linux/watchdog.hconflict!
'W'00-1F linux/wanrouter.h conflict! (pre 3.9)
'W'00-3F sound/asound.h conflict!
+'W'40-5F drivers/pci/switch/switchtec.c
'X'all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h
and include/linux/falloc.h
diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt
index 4bced4c..a0a9c7b 100644
--- a/Documentation/switchtec.txt
+++ b/Documentation/switchtec.txt
@@ -51,3 +51,30 @@ The char device has the following semantics:
* The poll call will also be supported for userspace applications that
need to do other things while waiting for the command to complete.
+
+The following IOCTLs are also supported by the device:
+
+* SWITCHTEC_IOCTL_FLASH_INFO - Retrieve firmware length and number
+ of partitions in the device.
+
+* SWITCHTEC_IOCTL_FLASH_PART_INFO - Retrieve address and lengeth for
+ any specified partition in flash.
+
+* SWITCHTEC_IOCTL_EVENT_SUMMARY - Read a structure of bitmaps
+ indicating all uncleared events.
+
+* SWITCHTEC_IOCTL_EVENT_CTL - Get the current count, clear and set flags
+ for any event. This ioctl takes in a switchtec_ioctl_event_ctl struct
+ with the event_id, index and flags set (index being the partition or PFF
+ number for non-global events). It returns whether the event has
+ occurred, the number of times and any event specific data. The flags
+ can be used to clear the count or enable and disable actions to
+ happen when the event occurs.
+ By using the SWITCHTEC_IOCTL_EVENT_FLAG_EN_POLL flag,
+ you can set an event to trigger a poll command to return with
+ POLLPRI. In this way, userspace can wait for events to occur.
+
+* SWITCHTEC_IOCTL_PFF_TO_PORT and SWITCHTEC_IOCTL_PORT_TO_PFF convert
+ between PCI Function Framework number (used by the event system)
+ and Switchtec Logic Port ID and Partition number (which is more
+ user friendly).
diff --git a/MAINTAINERS b/MAINTAINERS
index 6fed938..c1a9a30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9515,6 +9515,7 @@ S:Maintained
F: Documentation/switchtec.txt
F: Documentation/ABI/testing/sysfs-class-switchtec
F: drivers/pci/switch/switchtec*
+F: include/uapi/linux/switchtec_ioctl.h
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index c09d335..04d35f4 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -13,6 +13,8 @@
*
*/
+#include
+
#include
#include
#include
@@ -755,6 +757,417 @@ static unsigned int switchtec_dev_poll(struct file *filp,
poll_table *wait)
return ret;
}
+static int ioctl_flash_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+
+ info.flash_length = ioread32(>flash_length);
+ info.num_partitions = SWITCHTEC_IOCTL_NUM_PARTITIONS;
+
+ if (copy_to_user(uinfo, , sizeof(info)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static void set_fw_info_part(struct switchtec_ioctl_flash_part_info *info,
+struct partition_info __iomem *pi)
+{
+ info->address = ioread32(>address);
+ info->length = ioread32(>length);
+}
+
+static int ioctl_flash_part_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_part_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_part_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+ u32 active_addr = -1;
+
+ if (copy
[PATCH v3 2/4] switchtec: Add user interface documentation
This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.com> Reviewed-by: Wei Zhang <wzh...@fb.com> Reviewed-by: Jens Axboe <ax...@fb.com> --- Documentation/switchtec.txt | 53 + MAINTAINERS | 1 + 2 files changed, 54 insertions(+) create mode 100644 Documentation/switchtec.txt diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt new file mode 100644 index 000..4bced4c --- /dev/null +++ b/Documentation/switchtec.txt @@ -0,0 +1,53 @@ + +Linux Switchtec Support + + +Microsemi's "Switchtec" line of PCI switch devices is already +supported by the kernel with standard PCI switch drivers. However, the +Switchtec device advertises a special management endpoint which +enables some additional functionality. This includes: + +* Packet and Byte Counters +* Firmware Upgrades +* Event and Error logs +* Querying port link status +* Custom user firmware commands + +The switchtec kernel module implements this functionality. + + +Interface += + +The primary means of communicating with the Switchtec management firmware is +through the Memory-mapped Remote Procedure Call (MRPC) interface. +Commands are submitted to the interface with a 4-byte command +identifier and up to 1KB of command specific data. The firmware will +respond with a 4 bytes return code and up to 1KB of command specific +data. The interface only processes a single command at a time. + + +Userspace Interface +=== + +The MRPC interface will be exposed to userspace through a simple char +device: /dev/switchtec#, one for each management endpoint in the system. + +The char device has the following semantics: + +* A write must consist of at least 4 bytes and no more than 1028 bytes. + The first four bytes will be interpreted as the command to run and + the remainder will be used as the input data. A write will send the + command to the firmware to begin processing. + +* Each write must be followed by exactly one read. Any double write will + produce an error and any read that doesn't follow a write will + produce an error. + +* A read will block until the firmware completes the command and return + the four bytes of status plus up to 1024 bytes of output data. (The + length will be specified by the size parameter of the read call -- + reading less than 4 bytes will produce an error. + +* The poll call will also be supported for userspace applications that + need to do other things while waiting for the command to complete. diff --git a/MAINTAINERS b/MAINTAINERS index a57686f..aa702b0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9512,6 +9512,7 @@ M:Stephen Bates <stephen.ba...@microsemi.com> M: Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained +F: Documentation/switchtec.txt F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/4] New Microsemi PCI Switch Management Driver
Changes since v2: * Collected reviewed and tested tags * Very minor fix to the error path in the create function Changes since v1: * Rebased onto 4.10-rc6 (cleanly) * Split the patch into a few more easily digestible patches (as suggested by Greg Kroah-Hartman) * Folded switchtec.c into switchtec.h (per Greg) * Fixed a bunch of 32bit build warnings caught by the kbuild test robot * Fixed some issues in the documentation so it has a proper reStructredText format (as noted by Jonathan Corbet) * Fixed padding and sizes in the IOCTL structures as noticed by Emil Velikov and used pahole to verify their consistency across 32 and 64 bit builds * Reworked one of the IOCTL interfaces to be more future proof (per Emil). Changes since RFC: * Fixed incorrect use of the drive model as pointed out by Greg Kroah-Hartman * Used devm functions as suggested by Keith Busch * Added a handful of sysfs attributes to the switchtec class * Added a handful of IOCTLs to the switchtec device * A number of miscellaneous bug fixes -- Hi, This is a continuation of the RFC we posted lasted month [1] which proposes a management driver for Microsemi's Switchtec line of PCI switches. This hardware is still looking to be used in the Open Compute Platform To make this entirely clear: the Switchtec products are compliant with the PCI specifications and are supported today with the standard in-kernel driver. However, these devices also expose a management endpoint on a separate PCI function address which can be used to perform some advanced operations. This is a driver for that function. See the patch for more information. Since the RFC, we've made the changes requested by Greg Kroah-Hartman and Keith Busch, and we've also fleshed out a number of features. We've added a couple of IOCTLs and sysfs attributes which are documented in the patch. Significant work has also been done on the userspace tool which is available under a GPL license at [2]. We've also had testing done by some of the interested parties. We hope to see this work included in either 4.11 or 4.12 assuming a smooth review process. The patch is based off of the v4.10-rc6 release. Thanks for your review, Logan [1] https://www.spinics.net/lists/linux-pci/msg56897.html [2] https://github.com/sbates130272/switchtec-user -- Logan Gunthorpe (4): MicroSemi Switchtec management interface driver switchtec: Add user interface documentation switchtec: Add sysfs attributes to the Switchtec driver switchtec: Add IOCTLs to the Switchtec driver Documentation/ABI/testing/sysfs-class-switchtec | 96 ++ Documentation/ioctl/ioctl-number.txt|1 + Documentation/switchtec.txt | 80 ++ MAINTAINERS | 11 + drivers/pci/Kconfig |1 + drivers/pci/Makefile|1 + drivers/pci/switch/Kconfig | 13 + drivers/pci/switch/Makefile |1 + drivers/pci/switch/switchtec.c | 1611 +++ include/uapi/linux/switchtec_ioctl.h| 132 ++ 10 files changed, 1947 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec create mode 100644 Documentation/switchtec.txt create mode 100644 drivers/pci/switch/Kconfig create mode 100644 drivers/pci/switch/Makefile create mode 100644 drivers/pci/switch/switchtec.c create mode 100644 include/uapi/linux/switchtec_ioctl.h -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] switchtec: Add sysfs attributes to the Switchtec driver
This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> Tested-by: Krishna Dhulipala <krish...@fb.com> Reviewed-by: Wei Zhang <wzh...@fb.com> Reviewed-by: Jens Axboe <ax...@fb.com> Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- Documentation/ABI/testing/sysfs-class-switchtec | 96 MAINTAINERS | 1 + drivers/pci/switch/switchtec.c | 113 3 files changed, 210 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec diff --git a/Documentation/ABI/testing/sysfs-class-switchtec b/Documentation/ABI/testing/sysfs-class-switchtec new file mode 100644 index 000..48cb4c1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-switchtec @@ -0,0 +1,96 @@ +switchtec - Microsemi Switchtec PCI Switch Management Endpoint + +For details on this subsystem look at Documentation/switchtec.txt. + +What: /sys/class/switchtec +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: The switchtec class subsystem folder. + Each registered switchtec driver is represented by a switchtecX + subfolder (X being an integer >= 0). + + +What: /sys/class/switchtec/switchtec[0-9]+/component_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component identifier as stored in the hardware (eg. PM8543) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component revision stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/device_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Device version as stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/fw_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Currently running firmware version (read only) +Values:integer (in hexadecimal). + + +What: /sys/class/switchtec/switchtec[0-9]+/partition +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Partition number for this device in the switch (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/partition_count +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Total number of partitions in the switch (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product identifier as stored in the hardware (eg. PSX 48XG3) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product revision stored in the hardware (eg. RevB) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. diff --git a/MAINTAINERS b/MAINTAINERS index aa702b0..6fed938 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9513,6 +9513,7 @@ M:Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained F: Documentation/switchtec.txt +F: Documentation/ABI/testing/sysfs-class-switchtec F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA diff --gi
[PATCH v3 1/4] MicroSemi Switchtec management interface driver
Microsemi's "Switchtec" line of PCI switch devices is already well
supported by the kernel with standard PCI switch drivers. However, the
Switchtec device advertises a special management endpoint with a separate
PCI function address and class code. This endpoint enables some additional
functionality which includes:
* Packet and Byte Counters
* Switch Firmware Upgrades
* Event and Error logs
* Querying port link status
* Custom user firmware commands
This patch introduces the switchtec kernel module which provides
PCI driver that exposes a char device. The char device provides
userspace access to this interface through read, write and (optionally)
poll calls.
A userspace tool and library which utilizes this interface is available
at [1]. This tool takes inspiration (and borrows some code) from
nvme-cli [2]. The tool is largely complete at this time but additional
features may be added in the future.
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.com>
Reviewed-by: Wei Zhang <wzh...@fb.com>
Reviewed-by: Jens Axboe <ax...@fb.com>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
MAINTAINERS|8 +
drivers/pci/Kconfig|1 +
drivers/pci/Makefile |1 +
drivers/pci/switch/Kconfig | 13 +
drivers/pci/switch/Makefile|1 +
drivers/pci/switch/switchtec.c | 1031
6 files changed, 1055 insertions(+)
create mode 100644 drivers/pci/switch/Kconfig
create mode 100644 drivers/pci/switch/Makefile
create mode 100644 drivers/pci/switch/switchtec.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 527d137..a57686f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9506,6 +9506,14 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/aardvark-pci.txt
F: drivers/pci/host/pci-aardvark.c
+PCI DRIVER FOR MICROSEMI SWITCHTEC
+M: Kurt Schwemmer <kurt.schwem...@microsemi.com>
+M: Stephen Bates <stephen.ba...@microsemi.com>
+M: Logan Gunthorpe <log...@deltatee.com>
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/pci/switch/switchtec*
+
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
L: linux-te...@vger.kernel.org
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 6555eb7..f72e8c5 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -133,3 +133,4 @@ config PCI_HYPERV
source "drivers/pci/hotplug/Kconfig"
source "drivers/pci/host/Kconfig"
+source "drivers/pci/switch/Kconfig"
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 8db5079..15b46dd 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -68,3 +68,4 @@ ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
# PCI host controller drivers
obj-y += host/
+obj-y += switch/
diff --git a/drivers/pci/switch/Kconfig b/drivers/pci/switch/Kconfig
new file mode 100644
index 000..4c49648
--- /dev/null
+++ b/drivers/pci/switch/Kconfig
@@ -0,0 +1,13 @@
+menu "PCI switch controller drivers"
+ depends on PCI
+
+config PCI_SW_SWITCHTEC
+ tristate "MicroSemi Switchtec PCIe Switch Management Driver"
+ help
+Enables support for the management interface for the MicroSemi
+Switchtec series of PCIe switches. Supports userspace access
+to submit MRPC commands to the switch via /dev/switchtecX
+devices. See for more
+information.
+
+endmenu
diff --git a/drivers/pci/switch/Makefile b/drivers/pci/switch/Makefile
new file mode 100644
index 000..37d8cfb
--- /dev/null
+++ b/drivers/pci/switch/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PCI_SW_SWITCHTEC) += switchtec.o
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
new file mode 100644
index 000..f6bcff1
--- /dev/null
+++ b/drivers/pci/switch/switchtec.c
@@ -0,0 +1,1031 @@
+/*
+ * Microsemi Switchtec(tm) PCIe Management Driver
+ * Copyright (c) 2017, Microsemi Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCI-E Management Driver");
+MODULE_VERSION("0.1");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Microsemi Cor
Re: [PATCH v2 3/4] switchtec: Add sysfs attributes to the Switchtec driver
On 23/02/17 03:43 PM, Bjorn Helgaas wrote:
> This path seems a little generic. I don't see other cases where a
> product brand name ("Switchtec") appears at the top level of
> /sys/class/...
Ok, well we are certainly open to suggestions, but there isn't really a
generic version of this device available so I'm not sure how we would
change that. Per device-type classes aren't that uncommon though, a
quick grep shows things like:
platform/chrome/cros_ec_dev.c:40:static struct class cros_class
s390/char/raw3270.h:94:extern struct class *class3270;
net/ethernet/hisilicon/hns/hnae.c:19:static struct class *hnae_class;
mfd/ucb1x00-core.c:490:static struct class ucb1x00_class
> My question is based on "ls Documentation/ABI/testing/sysfs-class*",
> not on any great knowledge of sysfs, and I see Greg has already given
> a Reviewed-by for this, so maybe this is the right approach.
>
> It does seem like the path could include a clue that this is related
> to PCI.
I mean, we could change it to pci-switchtec or something if you think
that would be better..?? But I'm not sure how else to accommodate this.
> Is there a link to the switch PCI device itself, e.g., to
> /sys/devices/pci*? Should these attributes simply be put in a
> subdirectory there, e.g., in
>
> /sys/devices/pci:00/:00:00.0/stats/...
Well our device shows up here in the tree:
/sys/devices/pci:00/:00:03.0/:03:00.1/switchtec/switchtec0
(Which userspace can get to by following the link at
/sys/class/switchtec/switchtec0) The switch is then always:
/sys/devices/pci:00/:00:03.0
Thanks,
Logan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver
Thanks Bjorn! I understand your busy and we appreciate your time in this matter. I'll prepare a v3 with a collected set of tags shortly. We're more than happy to clean this up to make your job as easy as possible. We were just looking for direction in how to move this forward. Logan On 23/02/17 03:14 PM, Bjorn Helgaas wrote: > On Thu, Feb 23, 2017 at 01:36:51PM -0700, Logan Gunthorpe wrote: >> Hello, >> >> We're still waiting on any kind of response from Bjorn. (If you're >> listening please say something!) >> >> Does anyone have any suggestions for dealing with an unresponsive >> maintainer? Or a way for us to move forward with this quickly and get it >> merged? > > I try to deal with regressions first and other bug fixes second. > After that, I look at things that add new functionality. I try to > look at the new stuff in roughly chronological order, as you would see > here: > > https://patchwork.ozlabs.org/project/linux-pci/list/?order=date=1 > > If other folks have feedback, as they did on your 12/17, 1/31, and > even the 2/2 posting, I generally let that get sorted out before I > look at it. I apologize that I haven't responded to your queries > about posting a v3 vs updating v2. > > To answer that question, it's much simpler for me to deal with a > fresh, clean new series than it is to tweak things in an > already-posted series, partly because a series with discussion other > than simple acks and reviewed-bys looks more like work-in-progress. > > Bjorn > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver
On 23/02/17 01:51 PM, Sinan Kaya wrote: > You'll want to be careful during the merge window (these days) as the > maintainer is usually busy with code delivery. You can't rush your code in at > the last minute. Thanks for the advice, we will continue to wait. However, I would say we've been very patient. It's been three weeks since we posted the latest revision, a month since the first version and almost 3 months since our RFC. I don't think it's too much to expect at least a response saying that it's in the works or something. That long with dead silence from the maintainer is a bit much. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver
Hello, We're still waiting on any kind of response from Bjorn. (If you're listening please say something!) Does anyone have any suggestions for dealing with an unresponsive maintainer? Or a way for us to move forward with this quickly and get it merged? ie. Can anyone else pick this up through another route? In the end, it's just a fairly basic driver and doesn't touch any core PCI functionality and we've had a fair amount of review from other kernel contributors, all of which we've addressed. Thanks, Logan On 17/02/17 01:36 PM, Logan Gunthorpe wrote: > Hi Bjorn, > > Can you give us an idea of when you might be able to comment on our > patchset? We've addressed all the outstanding issues and have a couple > of reviewed and tested tags. So we'd like to see this move forward as > soon as possible. > > I can do a respin with the tags collected or address any concerns you > may have, just please let us know. > > Thanks, > > Logan > > On 02/02/17 11:05 AM, Logan Gunthorpe wrote: >> Changes since v1: >> >> * Rebased onto 4.10-rc6 (cleanly) >> * Split the patch into a few more easily digestible patches (as >> suggested by Greg Kroah-Hartman) >> * Folded switchtec.c into switchtec.h (per Greg) >> * Fixed a bunch of 32bit build warnings caught by the kbuild test robot >> * Fixed some issues in the documentation so it has a proper >> reStructredText format (as noted by Jonathan Corbet) >> * Fixed padding and sizes in the IOCTL structures as noticed by Emil >> Velikov and used pahole to verify their consistency across 32 and 64 >> bit builds >> * Reworked one of the IOCTL interfaces to be more future proof (per >> Emil). >> >> Changes since RFC: >> >> * Fixed incorrect use of the drive model as pointed out by Greg >> Kroah-Hartman >> * Used devm functions as suggested by Keith Busch >> * Added a handful of sysfs attributes to the switchtec class >> * Added a handful of IOCTLs to the switchtec device >> * A number of miscellaneous bug fixes >> >> -- >> >> Hi, >> >> This is a continuation of the RFC we posted lasted month [1] which >> proposes a management driver for Microsemi's Switchtec line of PCI >> switches. This hardware is still looking to be used in the Open >> Compute Platform >> >> To make this entirely clear: the Switchtec products are compliant >> with the PCI specifications and are supported today with the standard >> in-kernel driver. However, these devices also expose a management endpoint >> on a separate PCI function address which can be used to perform some >> advanced operations. This is a driver for that function. See the patch >> for more information. >> >> Since the RFC, we've made the changes requested by Greg Kroah-Hartman >> and Keith Busch, and we've also fleshed out a number of features. We've >> added a couple of IOCTLs and sysfs attributes which are documented in >> the patch. Significant work has also been done on the userspace tool >> which is available under a GPL license at [2]. We've also had testing >> done by some of the interested parties. >> >> We hope to see this work included in either 4.11 or 4.12 assuming a >> smooth review process. >> >> The patch is based off of the v4.10-rc6 release. >> >> Thanks for your review, >> >> Logan >> >> [1] https://www.spinics.net/lists/linux-pci/msg56897.html >> [2] https://github.com/sbates130272/switchtec-user >> >> -- >> >> Logan Gunthorpe (4): >> MicroSemi Switchtec management interface driver >> switchtec: Add user interface documentation >> switchtec: Add sysfs attributes to the Switchtec driver >> switchtec: Add IOCTLs to the Switchtec driver >> >> Documentation/ABI/testing/sysfs-class-switchtec | 96 ++ >> Documentation/ioctl/ioctl-number.txt|1 + >> Documentation/switchtec.txt | 80 ++ >> MAINTAINERS | 11 + >> drivers/pci/Kconfig |1 + >> drivers/pci/Makefile|1 + >> drivers/pci/switch/Kconfig | 13 + >> drivers/pci/switch/Makefile |1 + >> drivers/pci/switch/switchtec.c | 1608 >> +++ >> include/uapi/linux/switchtec_ioctl.h| 132 ++ >> 10 files changed, 1944 insertions(+) >> create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec >> create mode 100644 Documentation/switchtec.txt >> create mode 100644 drivers/pci/switch/Kconfig >> create mode 100644 drivers/pci/switch/Makefile >> create mode 100644 drivers/pci/switch/switchtec.c >> create mode 100644 include/uapi/linux/switchtec_ioctl.h >> >> -- >> 2.1.4 >> -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] switchtec: cleanup cdev init
On 19/02/17 02:43 PM, Dan Williams wrote: > Is this race present for all file operations? I've only seen it with > mmap() and late faults. So if these other drivers do not support mmap > it's not clear they can trigger the failure. I don't see how it's related to mmap only. I think there's a number of variations on this but the race I see happens if you try to take a reference to the device in the open/close handlers of a char device file. If a driver puts the last remaining reference in the release handler, then the device structure will be freed, and on returning from the release handler, the char_dev code will try to put the last reference to the cdev structure which may have already been free'd. There needs to be a way for the cdev structure to take a reference on the device structure so it doesn't get freed and the kobj.parent trick seems to accomplish this fairly well. Really, in any situation where there's a cdev and a device in the same structure, the life cycles of the two become linked but their reference counts are not and that is the problem here. I feel like a number of developers have made the same realization independently so this would probably be a good thing to clean up. See these commits for examples spanning around 5 years: 4a215aa Input: fix use-after-free introduced with dynamic minor changes 0d5b7da iio: Prevent race between IIO chardev opening and IIO device ba0ef85 tpm: Fix initialization of the cdev Also, seems both my brother and I have independently looked into this exact issue: https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg25692.html So, I think it would be a good idea to clean it up with Dan's proposed API cleanup. If I have some time tomorrow, I may throw together a patch set with that patch and the changes to the instances around the kernel. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] switchtec: cleanup cdev init
Hi,
Please don't apply this patch and instead apply the switchtec driver as
we submitted in v2. As per the discussion in [1], not using the cdev's
kobj parent results in incorrect reference counting and a possible use
of the cdev after its containing structure is freed.
I've also done a quick review around the kernel and found the pattern in
question to be quite prevalent. It's used in, at least, these drivers:
drivers/dax/dax.c:708
drivers/input/evdev.c:1419
drivers/input/joydev.c:908
drivers/input/mousedev.c:904
drivers/gpio/gpiolib.c:1039
drivers/char/tpm/tpm-chip.c:190
drivers/platform/chrome/cros_ec_dev.c:411
drivers/infiniband/hw/hfi1/device.c:72
drivers/infiniband/core/uverbs_main.c:1168
drivers/infiniband/core/user_mad.c:1186
drivers/infiniband/core/user_mad.c:1205
drivers/iio/industrialio-core.c:1721
drivers/media/cec/cec-core.c:140
drivers/media/media-devnode.c:258
Dan Williams has proposed a helper API in [2] that could make this code
appear significantly less suspect which I think would be a good idea.
However, for now, I feel the switchtec code should also follow this
pattern (ie. the way it was submitted in v2) and can be changed or
cleaned up when/if the above numerous examples are fixed up.
Thanks,
Logan
[1] https://lkml.org/lkml/2017/2/10/589
[2] https://lkml.org/lkml/2017/2/13/700
On 10/02/17 10:57 AM, Logan Gunthorpe wrote:
> Per a suggestion from Greg Kroah-Hartman [1], don't set the cdev's
> kobject parent. This allows us to use device_register instead of init
> and add.
>
> [1] https://lkml.org/lkml/2017/2/10/370
> ---
> drivers/pci/switch/switchtec.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
> index 82bfd18..014eaec 100644
> --- a/drivers/pci/switch/switchtec.c
> +++ b/drivers/pci/switch/switchtec.c
> @@ -1222,24 +1222,23 @@ static struct switchtec_dev *stdev_create(struct
> pci_dev *pdev)
> return ERR_PTR(minor);
>
> dev = >dev;
> - device_initialize(dev);
> dev->devt = MKDEV(MAJOR(switchtec_devt), minor);
> - dev->class = switchtec_class;
> - dev->parent = >dev;
> - dev->groups = switchtec_device_groups;
> - dev->release = stdev_release;
> - dev_set_name(dev, "switchtec%d", minor);
>
> cdev = >cdev;
> cdev_init(cdev, _fops);
> cdev->owner = THIS_MODULE;
> - cdev->kobj.parent = >kobj;
>
> rc = cdev_add(>cdev, dev->devt, 1);
> if (rc)
> goto err_cdev;
>
> - rc = device_add(dev);
> + dev->class = switchtec_class;
> + dev->parent = >dev;
> + dev->groups = switchtec_device_groups;
> + dev->release = stdev_release;
> + dev_set_name(dev, "switchtec%d", minor);
> +
> + rc = device_register(dev);
> if (rc) {
> cdev_del(>cdev);
> put_device(dev);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] New Microsemi PCI Switch Management Driver
Hi Bjorn, Can you give us an idea of when you might be able to comment on our patchset? We've addressed all the outstanding issues and have a couple of reviewed and tested tags. So we'd like to see this move forward as soon as possible. I can do a respin with the tags collected or address any concerns you may have, just please let us know. Thanks, Logan On 02/02/17 11:05 AM, Logan Gunthorpe wrote: > Changes since v1: > > * Rebased onto 4.10-rc6 (cleanly) > * Split the patch into a few more easily digestible patches (as > suggested by Greg Kroah-Hartman) > * Folded switchtec.c into switchtec.h (per Greg) > * Fixed a bunch of 32bit build warnings caught by the kbuild test robot > * Fixed some issues in the documentation so it has a proper > reStructredText format (as noted by Jonathan Corbet) > * Fixed padding and sizes in the IOCTL structures as noticed by Emil > Velikov and used pahole to verify their consistency across 32 and 64 > bit builds > * Reworked one of the IOCTL interfaces to be more future proof (per > Emil). > > Changes since RFC: > > * Fixed incorrect use of the drive model as pointed out by Greg > Kroah-Hartman > * Used devm functions as suggested by Keith Busch > * Added a handful of sysfs attributes to the switchtec class > * Added a handful of IOCTLs to the switchtec device > * A number of miscellaneous bug fixes > > -- > > Hi, > > This is a continuation of the RFC we posted lasted month [1] which > proposes a management driver for Microsemi's Switchtec line of PCI > switches. This hardware is still looking to be used in the Open > Compute Platform > > To make this entirely clear: the Switchtec products are compliant > with the PCI specifications and are supported today with the standard > in-kernel driver. However, these devices also expose a management endpoint > on a separate PCI function address which can be used to perform some > advanced operations. This is a driver for that function. See the patch > for more information. > > Since the RFC, we've made the changes requested by Greg Kroah-Hartman > and Keith Busch, and we've also fleshed out a number of features. We've > added a couple of IOCTLs and sysfs attributes which are documented in > the patch. Significant work has also been done on the userspace tool > which is available under a GPL license at [2]. We've also had testing > done by some of the interested parties. > > We hope to see this work included in either 4.11 or 4.12 assuming a > smooth review process. > > The patch is based off of the v4.10-rc6 release. > > Thanks for your review, > > Logan > > [1] https://www.spinics.net/lists/linux-pci/msg56897.html > [2] https://github.com/sbates130272/switchtec-user > > -- > > Logan Gunthorpe (4): > MicroSemi Switchtec management interface driver > switchtec: Add user interface documentation > switchtec: Add sysfs attributes to the Switchtec driver > switchtec: Add IOCTLs to the Switchtec driver > > Documentation/ABI/testing/sysfs-class-switchtec | 96 ++ > Documentation/ioctl/ioctl-number.txt|1 + > Documentation/switchtec.txt | 80 ++ > MAINTAINERS | 11 + > drivers/pci/Kconfig |1 + > drivers/pci/Makefile|1 + > drivers/pci/switch/Kconfig | 13 + > drivers/pci/switch/Makefile |1 + > drivers/pci/switch/switchtec.c | 1608 > +++ > include/uapi/linux/switchtec_ioctl.h| 132 ++ > 10 files changed, 1944 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec > create mode 100644 Documentation/switchtec.txt > create mode 100644 drivers/pci/switch/Kconfig > create mode 100644 drivers/pci/switch/Makefile > create mode 100644 drivers/pci/switch/switchtec.c > create mode 100644 include/uapi/linux/switchtec_ioctl.h > > -- > 2.1.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] MicroSemi Switchtec management interface driver
On 10/02/17 10:09 AM, Greg Kroah-Hartman wrote: > Sure, or just wait for these to be applied to the PCI tree and then send > a follow-on patch. It's up to Bjorn really, as to what he wants. Ok, I sent a working follow-on patch to this thread. @Bjorn: I'm happy to send the patches however you like. Just let me know. If at all possible, we'd really like to see this in for the 4.11 merge window. Thanks, Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] switchtec: cleanup cdev init
Per a suggestion from Greg Kroah-Hartman [1], don't set the cdev's
kobject parent. This allows us to use device_register instead of init
and add.
[1] https://lkml.org/lkml/2017/2/10/370
---
drivers/pci/switch/switchtec.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 82bfd18..014eaec 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -1222,24 +1222,23 @@ static struct switchtec_dev *stdev_create(struct
pci_dev *pdev)
return ERR_PTR(minor);
dev = >dev;
- device_initialize(dev);
dev->devt = MKDEV(MAJOR(switchtec_devt), minor);
- dev->class = switchtec_class;
- dev->parent = >dev;
- dev->groups = switchtec_device_groups;
- dev->release = stdev_release;
- dev_set_name(dev, "switchtec%d", minor);
cdev = >cdev;
cdev_init(cdev, _fops);
cdev->owner = THIS_MODULE;
- cdev->kobj.parent = >kobj;
rc = cdev_add(>cdev, dev->devt, 1);
if (rc)
goto err_cdev;
- rc = device_add(dev);
+ dev->class = switchtec_class;
+ dev->parent = >dev;
+ dev->groups = switchtec_device_groups;
+ dev->release = stdev_release;
+ dev_set_name(dev, "switchtec%d", minor);
+
+ rc = device_register(dev);
if (rc) {
cdev_del(>cdev);
put_device(dev);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] MicroSemi Switchtec management interface driver
On 10/02/17 09:55 AM, Greg Kroah-Hartman wrote: > Yes, but try it yourself to verify it really is correct :) Yes, of course... turns out it wasn't. I accidentally refereed to dev before I assigned it. I had mainly just wanted your feedback to ensure that switching to device_register made sense. > And it can just be an add-on patch, no need to respin a whole new > version for just that simple change, it doesn't hurt anything as-is, > it's just "not needed". Ok... How should I do that exactly? Attempt to reply to the thread with another patch? Thanks, Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] MicroSemi Switchtec management interface driver
Hey Greg,
Thanks so much for the review.
On 10/02/17 07:51 AM, Greg Kroah-Hartman wrote:
> On Thu, Feb 02, 2017 at 11:06:00AM -0700, Logan Gunthorpe wrote:
>> +cdev = >cdev;
>> +cdev_init(cdev, _fops);
>> +cdev->owner = THIS_MODULE;
>> +cdev->kobj.parent = >kobj;
>
> Minor nit, the kobject in a cdev is unlike any other kobject you have
> ever seen, don't mess with it, it's not doing anything like you think it
> is doing. So no need to set the parent field.
Ok, that makes sense. I'll do a v3 shortly.
I copied this from drivers/dax/dax.c so when I have a spare moment I'll
submit a patch to remove it from there as well.
Just to make sure I get this right without extra churn: does this look
correct?
cdev = >cdev;
cdev_init(cdev, _fops);
cdev->owner = THIS_MODULE;
rc = cdev_add(>cdev, dev->devt, 1);
if (rc)
goto err_cdev;
dev = >dev;
dev->devt = MKDEV(MAJOR(switchtec_devt), minor);
dev->class = switchtec_class;
dev->parent = >dev;
dev->groups = switchtec_device_groups;
dev->release = stdev_release;
dev_set_name(dev, "switchtec%d", minor);
rc = device_register(dev);
if (rc) {
cdev_del(>cdev);
put_device(dev);
return ERR_PTR(rc);
}
Thanks,
Logan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] switchtec: Add user interface documentation
This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> --- Documentation/switchtec.txt | 53 + MAINTAINERS | 1 + 2 files changed, 54 insertions(+) create mode 100644 Documentation/switchtec.txt diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt new file mode 100644 index 000..4bced4c --- /dev/null +++ b/Documentation/switchtec.txt @@ -0,0 +1,53 @@ + +Linux Switchtec Support + + +Microsemi's "Switchtec" line of PCI switch devices is already +supported by the kernel with standard PCI switch drivers. However, the +Switchtec device advertises a special management endpoint which +enables some additional functionality. This includes: + +* Packet and Byte Counters +* Firmware Upgrades +* Event and Error logs +* Querying port link status +* Custom user firmware commands + +The switchtec kernel module implements this functionality. + + +Interface += + +The primary means of communicating with the Switchtec management firmware is +through the Memory-mapped Remote Procedure Call (MRPC) interface. +Commands are submitted to the interface with a 4-byte command +identifier and up to 1KB of command specific data. The firmware will +respond with a 4 bytes return code and up to 1KB of command specific +data. The interface only processes a single command at a time. + + +Userspace Interface +=== + +The MRPC interface will be exposed to userspace through a simple char +device: /dev/switchtec#, one for each management endpoint in the system. + +The char device has the following semantics: + +* A write must consist of at least 4 bytes and no more than 1028 bytes. + The first four bytes will be interpreted as the command to run and + the remainder will be used as the input data. A write will send the + command to the firmware to begin processing. + +* Each write must be followed by exactly one read. Any double write will + produce an error and any read that doesn't follow a write will + produce an error. + +* A read will block until the firmware completes the command and return + the four bytes of status plus up to 1024 bytes of output data. (The + length will be specified by the size parameter of the read call -- + reading less than 4 bytes will produce an error. + +* The poll call will also be supported for userspace applications that + need to do other things while waiting for the command to complete. diff --git a/MAINTAINERS b/MAINTAINERS index 9c35198..0ab858d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9513,6 +9513,7 @@ M:Stephen Bates <stephen.ba...@microsemi.com> M: Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained +F: Documentation/switchtec.txt F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] New Microsemi PCI Switch Management Driver
Changes since v1: * Rebased onto 4.10-rc6 (cleanly) * Split the patch into a few more easily digestible patches (as suggested by Greg Kroah-Hartman) * Folded switchtec.c into switchtec.h (per Greg) * Fixed a bunch of 32bit build warnings caught by the kbuild test robot * Fixed some issues in the documentation so it has a proper reStructredText format (as noted by Jonathan Corbet) * Fixed padding and sizes in the IOCTL structures as noticed by Emil Velikov and used pahole to verify their consistency across 32 and 64 bit builds * Reworked one of the IOCTL interfaces to be more future proof (per Emil). Changes since RFC: * Fixed incorrect use of the drive model as pointed out by Greg Kroah-Hartman * Used devm functions as suggested by Keith Busch * Added a handful of sysfs attributes to the switchtec class * Added a handful of IOCTLs to the switchtec device * A number of miscellaneous bug fixes -- Hi, This is a continuation of the RFC we posted lasted month [1] which proposes a management driver for Microsemi's Switchtec line of PCI switches. This hardware is still looking to be used in the Open Compute Platform To make this entirely clear: the Switchtec products are compliant with the PCI specifications and are supported today with the standard in-kernel driver. However, these devices also expose a management endpoint on a separate PCI function address which can be used to perform some advanced operations. This is a driver for that function. See the patch for more information. Since the RFC, we've made the changes requested by Greg Kroah-Hartman and Keith Busch, and we've also fleshed out a number of features. We've added a couple of IOCTLs and sysfs attributes which are documented in the patch. Significant work has also been done on the userspace tool which is available under a GPL license at [2]. We've also had testing done by some of the interested parties. We hope to see this work included in either 4.11 or 4.12 assuming a smooth review process. The patch is based off of the v4.10-rc6 release. Thanks for your review, Logan [1] https://www.spinics.net/lists/linux-pci/msg56897.html [2] https://github.com/sbates130272/switchtec-user -- Logan Gunthorpe (4): MicroSemi Switchtec management interface driver switchtec: Add user interface documentation switchtec: Add sysfs attributes to the Switchtec driver switchtec: Add IOCTLs to the Switchtec driver Documentation/ABI/testing/sysfs-class-switchtec | 96 ++ Documentation/ioctl/ioctl-number.txt|1 + Documentation/switchtec.txt | 80 ++ MAINTAINERS | 11 + drivers/pci/Kconfig |1 + drivers/pci/Makefile|1 + drivers/pci/switch/Kconfig | 13 + drivers/pci/switch/Makefile |1 + drivers/pci/switch/switchtec.c | 1608 +++ include/uapi/linux/switchtec_ioctl.h| 132 ++ 10 files changed, 1944 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec create mode 100644 Documentation/switchtec.txt create mode 100644 drivers/pci/switch/Kconfig create mode 100644 drivers/pci/switch/Makefile create mode 100644 drivers/pci/switch/switchtec.c create mode 100644 include/uapi/linux/switchtec_ioctl.h -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] MicroSemi Switchtec management interface driver
Microsemi's "Switchtec" line of PCI switch devices is already well
supported by the kernel with standard PCI switch drivers. However, the
Switchtec device advertises a special management endpoint with a separate
PCI function address and class code. This endpoint enables some additional
functionality which includes:
* Packet and Byte Counters
* Switch Firmware Upgrades
* Event and Error logs
* Querying port link status
* Custom user firmware commands
This patch introduces the switchtec kernel module which provides
PCI driver that exposes a char device. The char device provides
userspace access to this interface through read, write and (optionally)
poll calls.
A userspace tool and library which utilizes this interface is available
at [1]. This tool takes inspiration (and borrows some code) from
nvme-cli [2]. The tool is largely complete at this time but additional
features may be added in the future.
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
---
MAINTAINERS|8 +
drivers/pci/Kconfig|1 +
drivers/pci/Makefile |1 +
drivers/pci/switch/Kconfig | 13 +
drivers/pci/switch/Makefile|1 +
drivers/pci/switch/switchtec.c | 1028
6 files changed, 1052 insertions(+)
create mode 100644 drivers/pci/switch/Kconfig
create mode 100644 drivers/pci/switch/Makefile
create mode 100644 drivers/pci/switch/switchtec.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f10c28..9c35198 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9507,6 +9507,14 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/aardvark-pci.txt
F: drivers/pci/host/pci-aardvark.c
+PCI DRIVER FOR MICROSEMI SWITCHTEC
+M: Kurt Schwemmer <kurt.schwem...@microsemi.com>
+M: Stephen Bates <stephen.ba...@microsemi.com>
+M: Logan Gunthorpe <log...@deltatee.com>
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/pci/switch/switchtec*
+
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
L: linux-te...@vger.kernel.org
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 6555eb7..f72e8c5 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -133,3 +133,4 @@ config PCI_HYPERV
source "drivers/pci/hotplug/Kconfig"
source "drivers/pci/host/Kconfig"
+source "drivers/pci/switch/Kconfig"
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 8db5079..15b46dd 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -68,3 +68,4 @@ ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
# PCI host controller drivers
obj-y += host/
+obj-y += switch/
diff --git a/drivers/pci/switch/Kconfig b/drivers/pci/switch/Kconfig
new file mode 100644
index 000..4c49648
--- /dev/null
+++ b/drivers/pci/switch/Kconfig
@@ -0,0 +1,13 @@
+menu "PCI switch controller drivers"
+ depends on PCI
+
+config PCI_SW_SWITCHTEC
+ tristate "MicroSemi Switchtec PCIe Switch Management Driver"
+ help
+Enables support for the management interface for the MicroSemi
+Switchtec series of PCIe switches. Supports userspace access
+to submit MRPC commands to the switch via /dev/switchtecX
+devices. See for more
+information.
+
+endmenu
diff --git a/drivers/pci/switch/Makefile b/drivers/pci/switch/Makefile
new file mode 100644
index 000..37d8cfb
--- /dev/null
+++ b/drivers/pci/switch/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PCI_SW_SWITCHTEC) += switchtec.o
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
new file mode 100644
index 000..e4a4294
--- /dev/null
+++ b/drivers/pci/switch/switchtec.c
@@ -0,0 +1,1028 @@
+/*
+ * Microsemi Switchtec(tm) PCIe Management Driver
+ * Copyright (c) 2017, Microsemi Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCI-E Management Driver");
+MODULE_VERSION("0.1");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Microsemi Corporation");
+
+static int max_devices = 16;
+module_param(max_devices, int, 0644);
+MODULE_PARM_DESC(max_devices, "max number of switchtec device instances");
+
+static dev_t switchtec_devt;
+static stru
[PATCH v2 4/4] switchtec: Add IOCTLs to the Switchtec driver
This patch introduces a couple of special IOCTLs which are provided to:
* Inform userspace of firmware partition locations
* Pass event counts and allow userspace to wait on events
* Translate between PFF numbers used by the switch to
port numbers.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
---
Documentation/ioctl/ioctl-number.txt | 1 +
Documentation/switchtec.txt | 27 ++
MAINTAINERS | 1 +
drivers/pci/switch/switchtec.c | 467 +++
include/uapi/linux/switchtec_ioctl.h | 132 ++
5 files changed, 628 insertions(+)
create mode 100644 include/uapi/linux/switchtec_ioctl.h
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 81c7f2b..032b33c 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -191,6 +191,7 @@ Code Seq#(hex) Include FileComments
'W'00-1F linux/watchdog.hconflict!
'W'00-1F linux/wanrouter.h conflict! (pre 3.9)
'W'00-3F sound/asound.h conflict!
+'W'40-5F drivers/pci/switch/switchtec.c
'X'all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h
and include/linux/falloc.h
diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt
index 4bced4c..a0a9c7b 100644
--- a/Documentation/switchtec.txt
+++ b/Documentation/switchtec.txt
@@ -51,3 +51,30 @@ The char device has the following semantics:
* The poll call will also be supported for userspace applications that
need to do other things while waiting for the command to complete.
+
+The following IOCTLs are also supported by the device:
+
+* SWITCHTEC_IOCTL_FLASH_INFO - Retrieve firmware length and number
+ of partitions in the device.
+
+* SWITCHTEC_IOCTL_FLASH_PART_INFO - Retrieve address and lengeth for
+ any specified partition in flash.
+
+* SWITCHTEC_IOCTL_EVENT_SUMMARY - Read a structure of bitmaps
+ indicating all uncleared events.
+
+* SWITCHTEC_IOCTL_EVENT_CTL - Get the current count, clear and set flags
+ for any event. This ioctl takes in a switchtec_ioctl_event_ctl struct
+ with the event_id, index and flags set (index being the partition or PFF
+ number for non-global events). It returns whether the event has
+ occurred, the number of times and any event specific data. The flags
+ can be used to clear the count or enable and disable actions to
+ happen when the event occurs.
+ By using the SWITCHTEC_IOCTL_EVENT_FLAG_EN_POLL flag,
+ you can set an event to trigger a poll command to return with
+ POLLPRI. In this way, userspace can wait for events to occur.
+
+* SWITCHTEC_IOCTL_PFF_TO_PORT and SWITCHTEC_IOCTL_PORT_TO_PFF convert
+ between PCI Function Framework number (used by the event system)
+ and Switchtec Logic Port ID and Partition number (which is more
+ user friendly).
diff --git a/MAINTAINERS b/MAINTAINERS
index d39b7fd..ea461d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9516,6 +9516,7 @@ S:Maintained
F: Documentation/switchtec.txt
F: Documentation/ABI/testing/sysfs-class-switchtec
F: drivers/pci/switch/switchtec*
+F: include/uapi/linux/switchtec_ioctl.h
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.red...@gmail.com>
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 354ddfd..82bfd18 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -13,6 +13,8 @@
*
*/
+#include
+
#include
#include
#include
@@ -755,6 +757,417 @@ static unsigned int switchtec_dev_poll(struct file *filp,
poll_table *wait)
return ret;
}
+static int ioctl_flash_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+
+ info.flash_length = ioread32(>flash_length);
+ info.num_partitions = SWITCHTEC_IOCTL_NUM_PARTITIONS;
+
+ if (copy_to_user(uinfo, , sizeof(info)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static void set_fw_info_part(struct switchtec_ioctl_flash_part_info *info,
+struct partition_info __iomem *pi)
+{
+ info->address = ioread32(>address);
+ info->length = ioread32(>length);
+}
+
+static int ioctl_flash_part_info(struct switchtec_dev *stdev,
+ struct switchtec_ioctl_flash_part_info __user *uinfo)
+{
+ struct switchtec_ioctl_flash_part_info info = {0};
+ struct flash_info_regs __iomem *fi = stdev->mmio_flash_info;
+ u32 active_addr = -1;
+
+ if (copy_from_user(, uinfo, sizeof(info)))
+ return -EFAULT;
+
+ switch (info.flash_partition) {
+ case SWITCHTEC_IOCTL
[PATCH v2 3/4] switchtec: Add sysfs attributes to the Switchtec driver
This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> --- Documentation/ABI/testing/sysfs-class-switchtec | 96 MAINTAINERS | 1 + drivers/pci/switch/switchtec.c | 113 3 files changed, 210 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec diff --git a/Documentation/ABI/testing/sysfs-class-switchtec b/Documentation/ABI/testing/sysfs-class-switchtec new file mode 100644 index 000..48cb4c1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-switchtec @@ -0,0 +1,96 @@ +switchtec - Microsemi Switchtec PCI Switch Management Endpoint + +For details on this subsystem look at Documentation/switchtec.txt. + +What: /sys/class/switchtec +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: The switchtec class subsystem folder. + Each registered switchtec driver is represented by a switchtecX + subfolder (X being an integer >= 0). + + +What: /sys/class/switchtec/switchtec[0-9]+/component_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component identifier as stored in the hardware (eg. PM8543) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component revision stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/device_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Device version as stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/fw_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Currently running firmware version (read only) +Values:integer (in hexadecimal). + + +What: /sys/class/switchtec/switchtec[0-9]+/partition +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Partition number for this device in the switch (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/partition_count +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Total number of partitions in the switch (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product identifier as stored in the hardware (eg. PSX 48XG3) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product revision stored in the hardware (eg. RevB) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/product_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Product vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. diff --git a/MAINTAINERS b/MAINTAINERS index 0ab858d..d39b7fd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9514,6 +9514,7 @@ M:Logan Gunthorpe <log...@deltatee.com> L: linux-...@vger.kernel.org S: Maintained F: Documentation/switchtec.txt +F: Documentation/ABI/testing/sysfs-class-switchtec F: drivers/pci/switch/switchtec* PCI DRIVER FOR NVIDIA TEGRA diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c index e4a4294..354ddfd 100644 --- a/drivers/pci/switch/switchtec.c +++ b/drivers/pci/switch/switchtec.c @@ -485,6 +485,118 @@ static void mrpc
Re: [PATCH 1/1] MicroSemi Switchtec management interface driver
On 01/02/17 05:10 AM, Emil Velikov wrote: > You can keep it roughly as-is if you're ~reasonably certain one won't > change it in the future. I've made the change anyway. I think it's better now. > Some teams frown upon adding new IOCTL(s) where existing ones can be > made backward/forward compatible. > I'm not fully aware of the general direction/consensus on the topic, > so it might be a minority. Sure, I just don't know what might be needed in the future so it's hard to add a version or flags ioctl now. > On the other hand, reading through sysfs for module version in order > to use IOCTL A or B sounds quite hacky. Do you have an example where > this is used or pointed out as good approach ? I don't know of anything doing it that way now. But it sure would be easy and make a bit of sense. (We'd actually use the module version for something useful.) Either way, it would really depend on if and how things change in the future. The point is there are options to expand if needed. > Afaict the idea is to not ship/bundle/release userspace until kernel > parts are in. > The "do not commit the changes" is implied as [very rarely] distros > package from "random" git checkouts. Leading to all sorts of fun when > it is mismatched wrt the kernel parts. Likelihood of doing that here > is virtually none here, so this is a JFYI inspired by some past > experiences. Understood. > Glad to hear. Then again you already had most of the things nicely done, imho. Great, thanks. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] MicroSemi Switchtec management interface driver
On 31/01/17 11:57 AM, Greg Kroah-Hartman wrote: > Sorry, it was probably me :) Nope, it was Christoph Hellwig. I don't mind changing it. It's just hard to know what's expected all the time. > Why do you need this? Wherever you put it, it should be built as part > of the online kernel documentation. Who is the audience for this > documentation? Well usually documenting how to use the device is a good thing. Is it not? The audience would be people wanting to make use of the userspace interface. Though in fairness, the vast majority of people should use our library. I also thought it would be useful to reviewers to more quickly understand the interface we are creating. If maintainers want us to leave it out, we can, but that seems like an odd request. > Do future stuff in the future, no need for that now, right? > > Simple is best. Ok, I can push it all into the C file for v2. > I'll leave that up to the PCI maintainer, but just a single .c file in a > subdir seems odd to me. Thanks, Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] DRAFT: New Microsemi PCI Switch Management Driver
Hi, This is a continuation of the RFC we posted lasted month [1] which proposes a management driver for Microsemi's Switchtec line of PCI switches. This hardware is still looking to be used in the Open Compute Platform To make this entirely clear: the Switchtec products are compliant with the PCI specifications and are supported today with the standard in-kernel driver. However, these devices also expose a management endpoint on a separate PCI function address which can be used to perform some advanced operations. This is a driver for that function. See the patch for more information. Since the RFC, we've made the changes requested by Greg Kroah-Hartman and Keith Busch, and we've also fleshed out a number of features. We've added a couple of IOCTLs and sysfs attributes which are documented in the patch. Significant work has also been done on the userspace tool which is available under a GPL license at [2]. We've also had testing done by some of the interested parties. We hope to see this work included in either 4.11 or 4.12 assuming a smooth review process. The patch is based off of the v4.9 release. Thanks for your review, Logan [1] https://www.spinics.net/lists/linux-pci/msg56897.html [2] https://github.com/sbates130272/switchtec-user -- Changes since RFC: * Fixed incorrect use of the drive model as pointed out by Greg Kroah-Hartman * Used devm functions as suggested by Keith Busch * Added a handful of sysfs attributes to the switchtec class * Added a handful of IOCTLs to the switchtec device * A number of miscelaneous bug fixes -- Logan Gunthorpe (1): MicroSemi Switchtec management interface driver Documentation/ABI/testing/sysfs-class-switchtec | 96 ++ Documentation/ioctl/ioctl-number.txt|1 + Documentation/switchtec.txt | 80 ++ MAINTAINERS | 11 + drivers/pci/Kconfig |1 + drivers/pci/Makefile|1 + drivers/pci/switch/Kconfig | 13 + drivers/pci/switch/Makefile |1 + drivers/pci/switch/switchtec.c | 1320 +++ drivers/pci/switch/switchtec.h | 266 + include/uapi/linux/switchtec_ioctl.h| 129 +++ 11 files changed, 1919 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec create mode 100644 Documentation/switchtec.txt create mode 100644 drivers/pci/switch/Kconfig create mode 100644 drivers/pci/switch/Makefile create mode 100644 drivers/pci/switch/switchtec.c create mode 100644 drivers/pci/switch/switchtec.h create mode 100644 include/uapi/linux/switchtec_ioctl.h -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] MicroSemi Switchtec management interface driver
On 31/01/17 10:26 AM, Greg Kroah-Hartman wrote: > That's one big patch to review, would you want to do that? Sorry, will do. > Can you break it up into smaller parts? At least put the documentation > separately, right? Ha, funny. Last time I sent a patch someone asked for the documentation to be in the same patch. But I can easily split this up. > And don't dump a .txt file into Documentation/ anymore, people are > working to move to the newer format. Fair. I wasn't sure where a good place to put it was. Any suggestions? > Also, please rebase against Linus's tree at the least, we can't go back > in time and apply this to the 4.9 kernel tree. Will do. > Why a .h file for a single .c file? I wanted to keep the hardware defining structs and macros in a separate file for future expansion. This hardware is also capable of some NTB functions which may find it's way into the kernel in the future. > Also, why a whole new directory? We didn't feel it fit in the pci director which was for standard pci stuff. We're more than open to other suggestions as to where this code belongs. Thanks, Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] MicroSemi Switchtec management interface driver
Microsemi's "Switchtec" line of PCI switch devices is already well supported by the kernel with standard PCI switch drivers. However, the Switchtec device advertises a special management endpoint with a separate PCI function address and class code. This endpoint enables some additional functionality which includes: * Packet and Byte Counters * Switch Firmware Upgrades * Event and Error logs * Querying port link status * Custom user firmware commands This patch introduces the switchtec kernel module which provides PCI driver that exposes a char device. The char device provides userspace access to this interface through read, write and (optionally) poll calls. A couple of special IOCTLs are provided to: * Inform userspace of firmware partition locations * Pass event counts and allow userspace to wait on events A short text file is provided which documents the switchtec driver, outlines the semantics of using the char device and describes the IOCTLs. The device also exposes a few read-only sysfs attributes which provide some device information component names and versions which is provided by the hardware. These are documented in Documentation/ABI/testing/sysfs-class-switchtec A userspace tool and library which utilizes this interface is available at [1]. This tool takes inspiration (and borrows some code) from nvme-cli [2]. The tool is largely complete at this time but additional features may be added in the future. [1] https://github.com/sbates130272/switchtec-user [2] https://github.com/linux-nvme/nvme-cli Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com> --- Documentation/ABI/testing/sysfs-class-switchtec | 96 ++ Documentation/ioctl/ioctl-number.txt|1 + Documentation/switchtec.txt | 80 ++ MAINTAINERS | 11 + drivers/pci/Kconfig |1 + drivers/pci/Makefile|1 + drivers/pci/switch/Kconfig | 13 + drivers/pci/switch/Makefile |1 + drivers/pci/switch/switchtec.c | 1320 +++ drivers/pci/switch/switchtec.h | 266 + include/uapi/linux/switchtec_ioctl.h| 129 +++ 11 files changed, 1919 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-switchtec create mode 100644 Documentation/switchtec.txt create mode 100644 drivers/pci/switch/Kconfig create mode 100644 drivers/pci/switch/Makefile create mode 100644 drivers/pci/switch/switchtec.c create mode 100644 drivers/pci/switch/switchtec.h create mode 100644 include/uapi/linux/switchtec_ioctl.h diff --git a/Documentation/ABI/testing/sysfs-class-switchtec b/Documentation/ABI/testing/sysfs-class-switchtec new file mode 100644 index 000..4fbc417 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-switchtec @@ -0,0 +1,96 @@ +switchtec - Microsemi Switchtec PCI Switch Management Endpoint + +For details on this subsystem look at Documentation/switchtec.txt. + +What: /sys/class/switchtec +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: The switchtec class subsystem folder. + Each registered switchtec driver is represented by a switchtecX + subfolder (X being an integer >= 0). + + +What: /sys/class/switchtec/switchtec[0-9]+/component_id +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component identifier as stored in the hardware (eg. PM4385) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_revision +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component revision stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/component_vendor +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Component vendor as stored in the hardware (eg. MICROSEM) + (read only) +Values:arbitrary string. + + +What: /sys/class/switchtec/switchtec[0-9]+/device_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Device version as stored in the hardware (read only) +Values:integer. + + +What: /sys/class/switchtec/switchtec[0-9]+/fw_version +Date: 05-Jan-2017 +KernelVersion: v4.11 +Contact: Logan Gunthorpe <log...@deltatee.com> +Description: Currently running firmware version (read only) +Values:integer (in hexadecimal). + + +What: /sys/class/sw
Re: [RFC 1/1] MicroSemi Switchtec management interface driver
On 19/12/16 10:02 AM, Keith Busch wrote: > Some of this would be simplified if you use the managed device API's: > devm_request_irq, pcim_enable_device, pcim_iomap, etc... Thanks Keith, I'll look into using those. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/1] MicroSemi Switchtec management interface driver
Hi Greg,
Thanks for the quick review!
On 18/12/16 12:51 AM, Greg Kroah-Hartman wrote:
On Sat, Dec 17, 2016 at 10:09:22AM -0700, Logan Gunthorpe wrote:
+struct switchtec_dev {
+ struct pci_dev *pdev;
+ struct msix_entry *msix;
+ struct device *dev;
+ struct kref kref;
Why do you have a pointer to a device, yet a kref as well? Just have
this structure embed a 'struct device' in itself, like you did for a
kref, and you will be fine. Otherwise you are dealing with two
different sets of reference counting here, for no good reason.
Ok, understood. I had referenced the device dax driver which did it this
way in 4.8 but looks like it was changed to the way you suggest in 4.9.
+#define stdev_pdev(stdev) ((stdev)->pdev)
+#define stdev_pdev_dev(stdev) (_pdev(stdev)->dev)
+#define stdev_name(stdev) pci_name(stdev_pdev(stdev))
+#define stdev_dev(stdev) ((stdev)->dev)
Ick, just open code these please. That's a huge hint your use of the
driver model is not correct :)
Ok, will do. For reference, I was copying
drivers/ntb/hw/intel/ntb_hw_intel.h
which does a similar thing.
Logan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
