Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
On Sat, 17 Aug 2019, Andrew Cooper wrote: > On 17/08/2019 09:44, Borislav Petkov wrote: > > On Thu, Aug 15, 2019 at 10:25:24PM +0100, Andrew Cooper wrote: > >> I'm afraid that a number of hypervisors do write-discard, given the > >> propensity of OSes (certainly traditionally) to go poking at bits like > >> this without wrmsr_safe(). > >> > >> You either need to read the MSR back and observe that the bit has really > >> changed, or in this case as Thomas suggests, look at CPUID again (which > >> will likely be the faster option for the non-virtualised case). > > One thing I didn't think of when we talked about this: this happens only > > after you resume the hypervisor. > > :) It hadn't escaped my notice, hence the intervention on this thread. > > > And the words "resume the hypervisor" already means an improbable use case. > > Qubes and OpenXT are two laptop+hypervisor oriented distros where > suspend/resume is a big deal, and these will have to follow AMD's > recommendation here. > > However, for servers which don't do S3/S4, we can reason about safely > leaving RDRAND enabled, irrespective of guest configuration. Let the administrator reason about it. Default is off for sanity sake. Thanks, tglx
Re: [PATCH v5 2/2] hwmon: pmbus: Add Inspur Power System power supply driver
On Fri, 16 Aug 2019 at 10:19, John Wang wrote: > > Add the driver to monitor Inspur Power System power supplies > with hwmon over pmbus. > > This driver adds sysfs attributes for additional power supply data, > including vendor, model, part_number, serial number, > firmware revision, hardware revision, and psu mode(active/standby). > > Signed-off-by: John Wang > +static const struct i2c_device_id ipsps_id[] = { > + { "inspur_ipsps1", 0 }, Convention would be to use "ipsps" here, instead of "vendor_device"? > + {} > +}; > +MODULE_DEVICE_TABLE(i2c, ipsps_id); > + > +static const struct of_device_id ipsps_of_match[] = { > + { .compatible = "inspur,ipsps1" }, > + {} > +}; > +MODULE_DEVICE_TABLE(of, ipsps_of_match); Do we need the of match table? I thought the match on the device name from the i2c table would be enough. I will defer to Guenter here though. Assuming the device tables are okay: Reviewed-by: Joel Stanley Cheers, Joel > + > +static struct i2c_driver ipsps_driver = { > + .driver = { > + .name = "inspur-ipsps", > + .of_match_table = ipsps_of_match, > + }, > + .probe = ipsps_probe, > + .remove = pmbus_do_remove, > + .id_table = ipsps_id, > +};
Re: [PATCH v5 2/2] hwmon: pmbus: Add Inspur Power System power supply driver
On 8/18/19 7:20 PM, Joel Stanley wrote: On Fri, 16 Aug 2019 at 10:19, John Wang wrote: Add the driver to monitor Inspur Power System power supplies with hwmon over pmbus. This driver adds sysfs attributes for additional power supply data, including vendor, model, part_number, serial number, firmware revision, hardware revision, and psu mode(active/standby). Signed-off-by: John Wang +static const struct i2c_device_id ipsps_id[] = { + { "inspur_ipsps1", 0 }, Convention would be to use "ipsps" here, instead of "vendor_device"? ipsps1, but good catch. + {} +}; +MODULE_DEVICE_TABLE(i2c, ipsps_id); + +static const struct of_device_id ipsps_of_match[] = { + { .compatible = "inspur,ipsps1" }, + {} +}; +MODULE_DEVICE_TABLE(of, ipsps_of_match); Do we need the of match table? I thought the match on the device name from the i2c table would be enough. I will defer to Guenter here though. Strictly speaking it is unnecessary, but it is kind of customary to have it. The automatic detection also only works if the i2c device ID would be "ipsps1", without vendor ID embedded. I would recomment to have both, but name the i2c device "ipsps1" as you suggested, for consistency. I'll also have to check if we need of_match_ptr below in the assignment of of_match_table. Probably not, but it would save a few bytes if CONFIG_OF is not enabled. Thanks, Guenter Assuming the device tables are okay: Reviewed-by: Joel Stanley Cheers, Joel + +static struct i2c_driver ipsps_driver = { + .driver = { + .name = "inspur-ipsps", + .of_match_table = ipsps_of_match, + }, + .probe = ipsps_probe, + .remove = pmbus_do_remove, + .id_table = ipsps_id, +};
Re: [PATCH] docs: mtd: Update spi nor reference driver
Hi, On 16/08/19 3:50 PM, John Garry wrote: > On 06/08/2019 17:40, Schrempf Frieder wrote: [...] > > Hi, > > Could someone kindly advise on the following: > > I am looking at ACPI support only for an mtd spi nor driver we're > targeting for mainline support. > If its a new driver, please add it under drivers/spi implementing SPI MEM framework. There are few drivers under drivers/spi that can be used as example. (Search for "spi_mem_ops") > So for the host, I could use a proprietary HID in the DSDT for matching > in the kernel driver. > > About the child spi flash devices, is the recommendation to just use > PRP0001 HID and "jedec,spi-nor" compatible? > I am not quite familiar with ACPI systems, but child flash device should use "jedec,spi-nor" as compatible. Regards Vignesh > thanks, > John > > >> >> @Maintainers: >> Maybe the docs under Documentation/driver-api/mtd should be officially >> maintained by the MTD subsystem (and added to MAINTAINERS). And if there >> will be some driver API docs for SPI MEM it should probably live in >> Documentation/driver-api/spi instead of Documentation/driver-api/mtd, as >> spi-mem.c itself is in drivers/spi. >> >> Regards, >> Frieder >> >>> >>> Thanks, >>> John >>> @@ -59,7 +59,7 @@ Part III - How can drivers use the framework? The main API is spi_nor_scan(). Before you call the hook, a driver should initialize the necessary fields for spi_nor{}. Please see -drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c +drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to spi-fsl-qspi.c when you want to write a new driver for a SPI NOR controller. Another API is spi_nor_restore(), this is used to restore the status of SPI flash chip such as addressing mode. Call it whenever detach the driver from >>> >>> >>> >>> __ >>> Linux MTD discussion mailing list >>> http://lists.infradead.org/mailman/listinfo/linux-mtd/ > > -- Regards Vignesh
Re: [PATCH v5 0/9] FPGA DFL updates
On Mon, Aug 12, 2019 at 10:49:55AM +0800, Wu Hao wrote: > Hi Greg, > > This is v5 patchset which adds more features to FPGA DFL. Marjor changes > against v4 are sysfs related code rework to address comments on v4. > > Please help to take a look. Thanks! Hi Greg, Did you get a chance to take a look at this new version patchset? :) Thanks Hao > > Main changes from v4: > - convert code to use dev_groups for sysfs entries (#2, #3, #4, #6, #8). > - clean up for empty init function after remove sysfs add/remove (#1). > - introduce is_visible for sysfs groups (#3, #4, #6, #8). > - remove revision sysfs entries (#4, #6, #8). > - improve naming on shared functions (#5). > - reorganize sysfs entries for port and fme error reporting (#6, #8). > > Main changes from v3: > - drop avx512 partail reconfiguration patch for now. > - split dfl_fpga_cdev_config_port to 2 functions *_release/assign_port > (#1). > - split __dfl_fpga_cdev_config_port_vf into 2 functions with locking > added (#2). > - improve description in sysfs doc to avoid misunderstanding (#3). > - switch to boolean in sysfs entry store function (#3). > - remove dev_dbg in init/uinit callback function (#7, #9, #11). > - remove uinit callback which does does nothing (#8, #9) > > Main changes from v2: > - update kernel version/date in sysfs doc (patch #4, #5, #8, #10, #11). > - add back Documentation patch (patch #12). > > Main changes from v1: > - remove DRV/MODULE_VERSION modifications. (patch #1, #3, #4, #6) > - remove argsz from new ioctls. (patch #2) > - replace sysfs_create/remove_* with device_add/remove_* for sysfs entries. > (patch #5, #8, #11) > > Wu Hao (9): > fpga: dfl: make init callback optional > fpga: dfl: fme: convert platform_driver to use dev_groups > fpga: dfl: afu: convert platform_driver to use dev_groups > fpga: dfl: afu: add userclock sysfs interfaces. > fpga: dfl: afu: expose __afu_port_enable/disable function. > fpga: dfl: afu: add error reporting support. > fpga: dfl: afu: add STP (SignalTap) support > fpga: dfl: fme: add global error reporting support > Documentation: fpga: dfl: add descriptions for virtualization and new > interfaces. > > Documentation/ABI/testing/sysfs-platform-dfl-fme | 62 > Documentation/ABI/testing/sysfs-platform-dfl-port | 53 > Documentation/fpga/dfl.rst| 105 +++ > drivers/fpga/Makefile | 3 +- > drivers/fpga/dfl-afu-error.c | 230 ++ > drivers/fpga/dfl-afu-main.c | 230 +++--- > drivers/fpga/dfl-afu.h| 9 + > drivers/fpga/dfl-fme-error.c | 359 > ++ > drivers/fpga/dfl-fme-main.c | 42 +-- > drivers/fpga/dfl-fme.h| 3 + > drivers/fpga/dfl.c| 10 +- > drivers/fpga/dfl.h| 9 + > 12 files changed, 1041 insertions(+), 74 deletions(-) > create mode 100644 drivers/fpga/dfl-afu-error.c > create mode 100644 drivers/fpga/dfl-fme-error.c > > -- > 1.8.3.1
Re: [PATCH] docs: process: fix broken link
On Friday, August 16, 2019 2:22:09 PM CEST Jacob Huisman wrote: > http://linux.yyz.us/patch-format.html seems to be down since > approximately September 2018. There is a working archive copy on > arhive.org. Replaced the links in documenation + translations. > > Signed-off-by: Jacob Huisman Reviewed-by: Federico Vaga