lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 23 Feb 2017 15:56:21 -0700
From:   Logan Gunthorpe <>
To:     Bjorn Helgaas <>
Cc:     Keith Busch <>,
        Myron Stowe <>,
        Greg Kroah-Hartman <>,
        Bjorn Helgaas <>,
        Geert Uytterhoeven <>,
        Jonathan Corbet <>,
        "David S. Miller" <>,
        Andrew Morton <>,
        Emil Velikov <>,
        Mauro Carvalho Chehab <>,
        Guenter Roeck <>,
        Jarkko Sakkinen <>,
        Linus Walleij <>,
        Ryusuke Konishi <>,
        Stefan Berger <>,
        Wei Zhang <>,
        Kurt Schwemmer <>,
        Stephen Bates <>,,,,
Subject: Re: [PATCH v2 3/4] switchtec: Add sysfs attributes to the Switchtec

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/pci0000:00/0000:00:00.0/stats/...

Well our device shows up here in the tree:


(Which userspace can get to by following the link at
/sys/class/switchtec/switchtec0) The switch is then always:




Powered by blists - more mailing lists