Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h

2019-08-18 Thread Thomas Gleixner
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

2019-08-18 Thread Joel Stanley
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

2019-08-18 Thread Guenter Roeck

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

2019-08-18 Thread Vignesh Raghavendra
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

2019-08-18 Thread Wu Hao
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

2019-08-18 Thread Federico Vaga
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