Re: FUSE: write operations trigger balance_dirty_pages when using writeback cache

[刘硕然]

Thank you for the prompt reply.

I tried this config, but still can get balance_dirty_pages triggered.

[root@A01-R20-I31-77-8S5FKM2 example]# stat -c %d /mnt/fuse/
42
[root@A01-R20-I31-77-8S5FKM2 example]# echo 20 > 
/sys/devices/virtual/bdi/0:`stat -c %d /mnt/fuse/`/max_ratio
[root@A01-R20-I31-77-8S5FKM2 example]# cat 
/sys/devices/virtual/bdi/0\:42/max_ratio 
20
[root@A01-R20-I31-77-8S5FKM2 example]# dd if=/dev/zero of=/mnt/fuse/tmp/test001 
bs=4k count=2

...
dd-633   [001]  273499.083059: balance_dirty_pages: bdi 0:42: limit=3180556 
setpoint=2782501 dirty=310 bdi_setpoint=0 bdi_dirty=13 dirty_ratelimit=32 
task_ratelimit=0 dirtied=1 dirtied_pause=0 paused=0 pause=14 period=14 think=1 
cgroup_ino=1
dd-633   [001]  273499.098089: balance_dirty_pages: bdi 0:42: limit=3180556 
setpoint=2782501 dirty=311 bdi_setpoint=0 bdi_dirty=14 dirty_ratelimit=32 
task_ratelimit=0 dirtied=1 dirtied_pause=0 paused=0 pause=15 period=15 think=1 
cgroup_ino=1
dd-633   [001]  273499.114082: balance_dirty_pages: bdi 0:42: limit=3180556 
setpoint=2782501 dirty=312 bdi_setpoint=0 bdi_dirty=15 dirty_ratelimit=32 
task_ratelimit=0 dirtied=1 dirtied_pause=0 paused=0 pause=16 period=16 think=1 
cgroup_ino=1
...


Regards,
Shuoran

-邮件原件-
发件人: Miklos Szeredi [mailto:mik...@szeredi.hu] 
发送时间: 2018年8月9日 15:14
收件人: 刘硕然 
抄送: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org
主题: Re: FUSE: write operations trigger balance_dirty_pages when using writeback 
cache

On Thu, Aug 9, 2018 at 5:37 AM, 刘硕然  wrote:
> Dear Miklos,
>
> Recently I've been testing FUSE and libfuse example passthrough_ll with 
> writeback cache on, and found out that the performance drops significantly 
> compared to that in local filesystem. As I can see from trace, 
> balance_dirty_pages is triggered very frequently even if there not enough 
> pages that shall be sent to libfuse. I'm not sure if this is a known fact or 
> the FUSE writeback feature requires some specific configurations. Trace log 
> is attached.
>
> dd-19067 [001]  195295.568097: balance_dirty_pages: bdi 0:42: 
> limit=3180390 setpoint=2782421 dirty=5 bdi_setpoint=0 bdi_dirty=32 
> dirty_ratelimit=32 task_ratelimit=0 dirtied=32 dirtied_pause=32 paused=0 
> pause=33 period=33 think=0 cgroup_ino=1
> dd-19067 [001]  195295.602029: balance_dirty_pages: bdi 0:42: 
> limit=3180390 setpoint=2782421 dirty=5 bdi_setpoint=0 bdi_dirty=33 
> dirty_ratelimit=32 task_ratelimit=0 dirtied=1 dirtied_pause=0 paused=0 
> pause=34 period=34 think=1 cgroup_ino=1
> dd-19067 [001]  195295.637026: balance_dirty_pages: bdi 0:42: 
> limit=3180390 setpoint=2782421 dirty=5 bdi_setpoint=0 bdi_dirty=34 
> dirty_ratelimit=32 task_ratelimit=0 dirtied=1 dirtied_pause=0 paused=0 
> pause=35 period=35 think=1 cgroup_ino=1
>
> BTW, I'm using Linux kernel 4.17.12 and libfuse 3.2.5. Look forward to 
> hearing from you. Thanks in advance.

Try

   echo 20 > /sys/devices/virtual/bdi/0:`stat -c %d /mnt/fuse/`/max_ratio

where you replace /mnt/fuse with your mountpoint.

Thanks,
Miklos

Re: [PATCH v8 20/22] KVM: s390: Handling of Cypto control block in VSIE

[Pierre Morel]

On 09/08/2018 08:20, Janosch Frank wrote:

On 08.08.2018 16:44, Tony Krowiak wrote:

From: Pierre Morel 
+#define ECA_APIE 0x0008

That shouldn't be necessary, it's defined in kvm_host.h which vsie.c
includes. Or is it not?


This was forgotten here for a long long time!
You are right I remove it.




+static int shadow_crycb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
+{
+   struct kvm_s390_sie_block *scb_s = _page->scb_s;
+   struct kvm_s390_sie_block *scb_o = vsie_page->scb_o;
+   const uint32_t crycbd_o = READ_ONCE(scb_o->crycbd);
+   const u32 crycb_addr = crycbd_o & 0x7ff8U;
+   int g2_fmt = vcpu->arch.sie_block->crycbd & CRYCB_FORMAT_MASK;
+   int g3_fmt = crycbd_o & CRYCB_FORMAT_MASK;
+   int g2_apie, g2_msa3, g3_apie, g3_msa3;
+   int size, ret;
+
+   /* crycb should not cross a page boundary */
+   size = (g3_fmt == CRYCB_FORMAT2) ? 0x100 : 0x80;
+   if ((crycb_addr & PAGE_MASK) != ((crycb_addr + size) & PAGE_MASK))
+   return set_validity_icpt(scb_s, 0x003CU);
+
+   g2_apie = vcpu->arch.sie_block->eca & ECA_APIE;
+   g3_apie = scb_o->eca & g2_apie;
+
+   g2_msa3 = test_kvm_facility(vcpu->kvm, 76);
+   g3_msa3 = (g3_fmt != CRYCB_FORMAT0) & g2_msa3;
+
+   scb_s->crycbd = 0;
+   /* If no AP instructions and no keys we just set crycbd to 0 */
+   if (!(g3_apie || g3_msa3))
+   return 0;
+
+   if (!crycb_addr)
+   return set_validity_icpt(scb_s, 0x0039U);
+
+   if (g3_apie) {
+   ret = copy_apcb(vcpu, vsie_page, g2_fmt, g3_fmt);
+   if (ret)
+   goto out;

s/goto out;/return ret;/


better

Thanks

Pierre

--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany

Re: [PATCH v5 5/5] Auto-detect whether a FPU exists

[Alan Kao]

On Thu, Aug 09, 2018 at 12:02:58AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 09, 2018 at 02:43:36PM +0800, Alan Kao wrote:
> > It does look a little bit weird.  Should I send a v6 for this?
> 
> Yes, please resend the series or just this patch.
> 
> I think the hswap.h definition should go away and we should just
> keep the switch_to.h one, even if that means including the header
> in another C file.
> 

It turns out that only cpufeature.c and switch_to.h are affected
by hwcap.h.  As switch_to.h already had extern has_fpu declaration,
the one in hwcap.h is redundant and can be removed safely.

I will resend just this patch, and mark it as v6.

Re: [RFC PATCH 2/3] mm/memory_hotplug: Create __shrink_pages and move it to offline_pages

[Michal Hocko]

On Wed 08-08-18 12:58:15, Jerome Glisse wrote:
> On Wed, Aug 08, 2018 at 08:47:58AM +0200, Michal Hocko wrote:
> > On Tue 07-08-18 11:18:10, Jerome Glisse wrote:
> > > On Tue, Aug 07, 2018 at 04:59:00PM +0200, Michal Hocko wrote:
> > > > On Tue 07-08-18 09:52:21, Jerome Glisse wrote:
> > > > > On Tue, Aug 07, 2018 at 03:37:56PM +0200, 
> > > > > osalva...@techadventures.net wrote:
> > > > > > From: Oscar Salvador 
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > > > > > index 9bd629944c91..e33555651e46 100644
> > > > > > --- a/mm/memory_hotplug.c
> > > > > > +++ b/mm/memory_hotplug.c
> > > > > 
> > > > > [...]
> > > > > 
> > > > > >  /**
> > > > > >   * __remove_pages() - remove sections of pages from a zone
> > > > > > - * @zone: zone from which pages need to be removed
> > > > > > + * @nid: node which pages belong to
> > > > > >   * @phys_start_pfn: starting pageframe (must be aligned to start 
> > > > > > of a section)
> > > > > >   * @nr_pages: number of pages to remove (must be multiple of 
> > > > > > section size)
> > > > > >   * @altmap: alternative device page map or %NULL if default memmap 
> > > > > > is used
> > > > > > @@ -548,7 +557,7 @@ static int __remove_section(struct zone *zone, 
> > > > > > struct mem_section *ms,
> > > > > >   * sure that pages are marked reserved and zones are adjust 
> > > > > > properly by
> > > > > >   * calling offline_pages().
> > > > > >   */
> > > > > > -int __remove_pages(struct zone *zone, unsigned long phys_start_pfn,
> > > > > > +int __remove_pages(int nid, unsigned long phys_start_pfn,
> > > > > >  unsigned long nr_pages, struct vmem_altmap *altmap)
> > > > > >  {
> > > > > > unsigned long i;
> > > > > > @@ -556,10 +565,9 @@ int __remove_pages(struct zone *zone, unsigned 
> > > > > > long phys_start_pfn,
> > > > > > int sections_to_remove, ret = 0;
> > > > > >  
> > > > > > /* In the ZONE_DEVICE case device driver owns the memory region 
> > > > > > */
> > > > > > -   if (is_dev_zone(zone)) {
> > > > > > -   if (altmap)
> > > > > > -   map_offset = vmem_altmap_offset(altmap);
> > > > > > -   } else {
> > > > > > +   if (altmap)
> > > > > > +   map_offset = vmem_altmap_offset(altmap);
> > > > > > +   else {
> > > > > 
> > > > > This will break ZONE_DEVICE at least for HMM. While i think that
> > > > > altmap -> ZONE_DEVICE (ie altmap imply ZONE_DEVICE) the reverse
> > > > > is not true ie ZONE_DEVICE does not necessarily imply altmap. So
> > > > > with the above changes you change the expected behavior.
> > > > 
> > > > Could you be more specific what is the expected behavior here?
> > > > Is this about calling release_mem_region_adjustable? Why does is it not
> > > > suitable for zone device ranges?
> > > 
> > > Correct, you should not call release_mem_region_adjustable() the device
> > > region is not part of regular iomem resource as it might not necessarily
> > > be enumerated through known ways to the kernel (ie only the device driver
> > > can discover the region and core kernel do not know about it).
> > 
> > If there is no region registered with the range then the call should be
> > mere nop, no? So why do we have to special case?
> 
> IIRC this is because you can not release the resource ie the resource
> is still own by the device driver even if you hotremove the memory.
> The device driver might still be using the resource without struct page.

But then it seems to be a property of a device rather than zone_device,
no? If there are devices which want to preserve the resource then they
should tell that. Doing that unconditionally for all zone_device users
seems just wrong.
-- 
Michal Hocko
SUSE Labs

[PATCH v5 2/4] ACPI / scan: Create platform device for fwnodes with multiple i2c devices

[Hans de Goede]

Some devices have multiple I2cSerialBus resources and for things to work
an i2c-client must be instantiated for each, each with its own
i2c_device_id.

Normally we only instantiate an i2c-client for the first resource, using
the ACPI HID as id.

This commit adds a list of HIDs of devices, which need multiple i2c-clients
instantiated from a single fwnode, to acpi_device_enumeration_by_parent and
makes acpi_device_enumeration_by_parent return false for these devices so
that a platform device will be instantiated.

This allows the drivers/platform/x86/i2c-multi-instantiate.c driver, which
knows which i2c_device_id to use for each resource, to bind to the fwnode
and initiate an i2c-client for each resource.

Signed-off-by: Hans de Goede 
---
Changes in v3:
-New patch in v3 of this patch-set

Changes in v4:
-Some small code-style fixes
---
 drivers/acpi/scan.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 6799d00dd790..b51913372e21 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1540,6 +1540,18 @@ static bool acpi_device_enumeration_by_parent(struct 
acpi_device *device)
 {
struct list_head resource_list;
bool is_serial_bus_slave = false;
+   /*
+* These devices have multiple I2cSerialBus resources and an i2c-client
+* must be instantiated for each, each with its own i2c_device_id.
+* Normally we only instantiate an i2c-client for the first resource,
+* using the ACPI HID as id. These special cases are handled by the
+* drivers/platform/x86/i2c-multi-instantiate.c driver, which knows
+* which i2c_device_id to use for each resource.
+*/
+   static const struct acpi_device_id i2c_multi_instantiate_ids[] = {
+   {"BSG1160", },
+   {}
+   };
 
if (acpi_is_indirect_io_slave(device))
return true;
@@ -1551,6 +1563,10 @@ static bool acpi_device_enumeration_by_parent(struct 
acpi_device *device)
 fwnode_property_present(>fwnode, "baud")))
return true;
 
+   /* Instantiate a pdev for the i2c-multi-instantiate drv to bind to */
+   if (!acpi_match_device_ids(device, i2c_multi_instantiate_ids))
+   return false;
+
INIT_LIST_HEAD(_list);
acpi_dev_get_resources(device, _list,
   acpi_check_serial_bus_slave,
-- 
2.18.0

[PATCH v5 1/4] ACPI / scan: Initialize status to ACPI_STA_DEFAULT

[Hans de Goede]

Since commit 63347db0affa ("ACPI / scan: Use acpi_bus_get_status() to
initialize ACPI_TYPE_DEVICE devs") the status field of normal acpi_devices
gets set to 0 by acpi_bus_type_and_status() and filled with its actual
value later when acpi_add_single_object() calls acpi_bus_get_status().

This means that any acpi_match_device_ids() calls in between will always
fail with -ENOENT.

We already have a workaround for this, which temporary forces status to
ACPI_STA_DEFAULT in drivers/acpi/x86/utils.c: acpi_device_always_present()
and the next commit in this series adds another acpi_match_device_ids()
call between status being initialized as 0 and the acpi_bus_get_status()
call.

Rather then adding another workaround, this commit makes
acpi_bus_type_and_status() initialize status to ACPI_STA_DEFAULT, this is
safe to do as the only code looking at status between the initialization
and the acpi_bus_get_status() call is those acpi_match_device_ids() calls.

Note this does mean that we need to (re)set status to 0 in case the
acpi_bus_get_status() call fails.

Signed-off-by: Hans de Goede 
---
Changes in v3:
-New patch in v3 of this patch-set

Changes in v4:
-This is not a fix for acpi_is_indirect_io_slave() as I thought at first,
 acpi_is_indirect_io_slave() calls acpi_match_device_ids() on its parent
 device, where status is already set properly. Rewrite the commit message
 accordingly.
---
 drivers/acpi/scan.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 970dd87d347c..6799d00dd790 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1612,7 +1612,8 @@ static int acpi_add_single_object(struct acpi_device 
**child,
 * Note this must be done before the get power-/wakeup_dev-flags calls.
 */
if (type == ACPI_BUS_TYPE_DEVICE)
-   acpi_bus_get_status(device);
+   if (acpi_bus_get_status(device) < 0)
+   acpi_set_device_status(device, 0);
 
acpi_bus_get_power_flags(device);
acpi_bus_get_wakeup_device_flags(device);
@@ -1690,7 +1691,7 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
int *type,
 * acpi_add_single_object updates this once we've an acpi_device
 * so that acpi_bus_get_status' quirk handling can be used.
 */
-   *sta = 0;
+   *sta = ACPI_STA_DEFAULT;
break;
case ACPI_TYPE_PROCESSOR:
*type = ACPI_BUS_TYPE_PROCESSOR;
-- 
2.18.0

[PATCH v5 0/4] i2c-multi-instantiate pseudo driver

[Hans de Goede]

Hi All,

Here is v5 of my patch-series for dealing with multiple independent i2c
devices being described in a single ACPI fwnode.

Changes in v5:
-s/no_clients/num_clients/
-Change patch 4 Subject prefix to platform/x86

Changes in v4:
-Rewrite commit message of first patch as this is NOT a bug fix for
 acpi_is_indirect_io_slave() as I thought at first, it is still necessary
 as a preperation patch for the rest of the series
-MAINTAINER and Kconfig entry fixes
-Some minor coding style fixes

Changes in v3:
-Drop the patch adding the I2C_CLIENT_IGNORE_BUSY flag/hack
-Add patches to make ACPI fwnode-s with affected acpi_ids get enumerated as
 platform device instead of i2c-client
-Change the i2c-multi-instantiate driver to a platform driver

Changes in v2:
-Rebase on 4.18-rc2

Changes in v1:
-Second attempt at dealing with this using a new design where a separate
 driver (which can be build as a module) is used to instantiate the
 i2c-clients instead of modifying the i2c core
-Add an I2C_CLIENT_IGNORE_BUSY flag to make it possible for this driver to bind
 to the client instantiated for the first i2c resource and still create a new
 client using the i2c_client_id for the actual driver for the first resource,
 resulting in 2 clients at the same address (of which one is inactive)

About merging this series, the platform-driver and ACPI patches can be
merged independently of each other, they platform driver relies on the ACPI
changes to gets its platform device instantiated, but if those changes are
not in place yet, nothing bad happens.

So if everyone is happy with this series I suggest that each part gets
merged separately through the relevant trees.

Regards,

Hans

[PATCH v5 3/4] ACPI / x86-utils: Remove status workaround from acpi_device_always_present()

[Hans de Goede]

Now that we init the status field to ACPI_STA_DEFAULT rather then to 0,
the workaround for acpi_match_device_ids() always returning -ENOENT when
status is 0 is no longer needed.

Signed-off-by: Hans de Goede 
---
Changes in v3:
-New patch in v3 of this patch-set
---
 drivers/acpi/x86/utils.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
index ec5b0f190231..a4fb97d64b3b 100644
--- a/drivers/acpi/x86/utils.c
+++ b/drivers/acpi/x86/utils.c
@@ -103,13 +103,9 @@ static const struct always_present_id always_present_ids[] 
= {
 
 bool acpi_device_always_present(struct acpi_device *adev)
 {
-   u32 *status = (u32 *)>status;
-   u32 old_status = *status;
bool ret = false;
unsigned int i;
 
-   /* acpi_match_device_ids checks status, so set it to default */
-   *status = ACPI_STA_DEFAULT;
for (i = 0; i < ARRAY_SIZE(always_present_ids); i++) {
if (acpi_match_device_ids(adev, always_present_ids[i].hid))
continue;
@@ -125,15 +121,9 @@ bool acpi_device_always_present(struct acpi_device *adev)
!dmi_check_system(always_present_ids[i].dmi_ids))
continue;
 
-   if (old_status != ACPI_STA_DEFAULT) /* Log only once */
-   dev_info(>dev,
-"Device [%s] is in always present list\n",
-adev->pnp.bus_id);
-
ret = true;
break;
}
-   *status = old_status;
 
return ret;
 }
-- 
2.18.0

[PATCH v5 4/4] platform/x86: Add ACPI i2c-multi-instantiate pseudo driver

[Hans de Goede]

On systems with ACPI instantiated i2c-clients, normally there is 1 fw_node
per i2c-device and that fw-node contains 1 I2cSerialBus resource for that 1
i2c-device.

But in some rare cases the manufacturer has decided to describe multiple
i2c-devices in a single ACPI fwnode with multiple I2cSerialBus resources.

An earlier attempt to fix this in the i2c-core resulted in a lot of extra
code to support this corner-case.

This commit introduces a new i2c-multi-instantiate driver which fixes this
in a different way. This new driver can be built as a module which will
only loaded on affected systems.

This driver will instantiate a new i2c-client per I2cSerialBus resource,
using the driver_data from the acpi_device_id it is binding to to tell it
which chip-type (and optional irq-resource) to use when instantiating.

Note this driver depends on a platform device being instantiated for the
ACPI fwnode, see the i2c_multi_instantiate_ids list of ACPI device-ids in
drivers/acpi/scan.c: acpi_device_enumeration_by_parent().

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Rebase on top of 4.18-rc2

Changes in v3:
-Change from an i2c-driver using a hack to allow having multiple i2c clients
 at the same address to a platform-driver

Changes in v4:
-Tweak MAINTAINERS entry a bit

Changes in v5:
-s/no_clients/num_clients/
-Change patch Subject prefix to platform/x86
---
 MAINTAINERS  |   6 +
 drivers/platform/x86/Kconfig |  11 ++
 drivers/platform/x86/Makefile|   1 +
 drivers/platform/x86/i2c-multi-instantiate.c | 131 +++
 4 files changed, 149 insertions(+)
 create mode 100644 drivers/platform/x86/i2c-multi-instantiate.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9b377508f24f..dbe7836e4f6b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -367,6 +367,12 @@ L: linux-a...@vger.kernel.org
 S: Maintained
 F: drivers/acpi/arm64
 
+ACPI I2C MULTI INSTANTIATE DRIVER
+M: Hans de Goede 
+L: platform-driver-...@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/i2c-multi-instantiate.c
+
 ACPI PMIC DRIVERS
 M: "Rafael J. Wysocki" 
 M: Len Brown 
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 85a93453237c..64c82592d4b6 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1219,6 +1219,17 @@ config INTEL_CHTDC_TI_PWRBTN
  To compile this driver as a module, choose M here: the module
  will be called intel_chtdc_ti_pwrbtn.
 
+config I2C_MULTI_INSTANTIATE
+   tristate "I2C multi instantiate pseudo device driver"
+   depends on I2C && ACPI
+   help
+ Some ACPI-based systems list multiple i2c-devices in a single ACPI
+ firmware-node. This driver will instantiate separate i2c-clients
+ for each device in the firmware-node.
+
+ To compile this driver as a module, choose M here: the module
+ will be called i2c-multi-instantiate.
+
 endif # X86_PLATFORM_DEVICES
 
 config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 8d9477114fb5..e6d1becf81ce 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -91,3 +91,4 @@ obj-$(CONFIG_PMC_ATOM)+= pmc_atom.o
 obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
 obj-$(CONFIG_INTEL_TURBO_MAX_3) += intel_turbo_max_3.o
 obj-$(CONFIG_INTEL_CHTDC_TI_PWRBTN)+= intel_chtdc_ti_pwrbtn.o
+obj-$(CONFIG_I2C_MULTI_INSTANTIATE)+= i2c-multi-instantiate.o
diff --git a/drivers/platform/x86/i2c-multi-instantiate.c 
b/drivers/platform/x86/i2c-multi-instantiate.c
new file mode 100644
index ..75c00630ecde
--- /dev/null
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * I2C multi-instantiate driver, pseudo driver to instantiate multiple
+ * i2c-clients from a single fwnode.
+ *
+ * Copyright 2018 Hans de Goede 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct i2c_inst_data {
+   const char *type;
+   int irq_idx;
+};
+
+struct i2c_multi_inst_data {
+   int num_clients;
+   struct i2c_client *clients[0];
+};
+
+static int i2c_multi_inst_probe(struct platform_device *pdev)
+{
+   struct i2c_multi_inst_data *multi;
+   const struct acpi_device_id *match;
+   const struct i2c_inst_data *inst_data;
+   struct i2c_board_info board_info = {};
+   struct device *dev = >dev;
+   struct acpi_device *adev;
+   char name[32];
+   int i, ret;
+
+   match = acpi_match_device(dev->driver->acpi_match_table, dev);
+   if (!match) {
+   dev_err(dev, "Error ACPI match data is missing\n");
+   return -ENODEV;
+   }
+   inst_data = (const struct i2c_inst_data *)match->driver_data;
+
+   adev = ACPI_COMPANION(dev);
+
+   /* Count number of clients to instantiate */
+   for (i = 0; inst_data[i].type; i++) {}
+
+   

Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator

[Vincent Guittot]

On Tue, 24 Jul 2018 at 14:26, Quentin Perret  wrote:
>
> From: Morten Rasmussen 
>
> Energy-aware scheduling is only meant to be active while the system is
> _not_ over-utilized. That is, there are spare cycles available to shift
> tasks around based on their actual utilization to get a more
> energy-efficient task distribution without depriving any tasks. When
> above the tipping point task placement is done the traditional way based
> on load_avg, spreading the tasks across as many cpus as possible based
> on priority scaled load to preserve smp_nice. Below the tipping point we
> want to use util_avg instead. We need to define a criteria for when we
> make the switch.
>
> The util_avg for each cpu converges towards 100% (1024) regardless of

remove the "(1024)" because util_avg converges to max cpu capacity
which can be different from 1024

> how many task additional task we may put on it. If we define
> over-utilized as:
>
> sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
>
> some individual cpus may be over-utilized running multiple tasks even
> when the above condition is false. That should be okay as long as we try
> to spread the tasks out to avoid per-cpu over-utilization as much as
> possible and if all tasks have the _same_ priority. If the latter isn't
> true, we have to consider priority to preserve smp_nice.
>

Re: [PATCH] ASoC: adau1761: Mark expected switch fall-though

[Mark Brown]

On Wed, Aug 08, 2018 at 02:22:13PM -0500, Gustavo A. R. Silva wrote:

> @@ -518,7 +518,8 @@ static int adau1761_setup_digmic_jackdetect(struct 
> snd_soc_component *component)
>   ARRAY_SIZE(adau1761_jack_detect_controls));
>   if (ret)
>   return ret;
> - case ADAU1761_DIGMIC_JACKDET_PIN_MODE_NONE: /* fallthrough */
> + /* fall through */
> + case ADAU1761_DIGMIC_JACKDET_PIN_MODE_NONE:
>   ret = snd_soc_dapm_add_routes(dapm, adau1761_no_dmic_routes,
>   ARRAY_SIZE(adau1761_no_dmic_routes));
>   if (ret)

Again, are you *sure* here?


signature.asc
Description: PGP signature

Re: [PATCH v5 4/4] platform/x86: Add ACPI i2c-multi-instantiate pseudo driver

[Wolfram Sang]

On Thu, Aug 09, 2018 at 11:15:58AM +0200, Hans de Goede wrote:
> On systems with ACPI instantiated i2c-clients, normally there is 1 fw_node
> per i2c-device and that fw-node contains 1 I2cSerialBus resource for that 1
> i2c-device.
> 
> But in some rare cases the manufacturer has decided to describe multiple
> i2c-devices in a single ACPI fwnode with multiple I2cSerialBus resources.
> 
> An earlier attempt to fix this in the i2c-core resulted in a lot of extra
> code to support this corner-case.
> 
> This commit introduces a new i2c-multi-instantiate driver which fixes this
> in a different way. This new driver can be built as a module which will
> only loaded on affected systems.
> 
> This driver will instantiate a new i2c-client per I2cSerialBus resource,
> using the driver_data from the acpi_device_id it is binding to to tell it
> which chip-type (and optional irq-resource) to use when instantiating.
> 
> Note this driver depends on a platform device being instantiated for the
> ACPI fwnode, see the i2c_multi_instantiate_ids list of ACPI device-ids in
> drivers/acpi/scan.c: acpi_device_enumeration_by_parent().
> 
> Signed-off-by: Hans de Goede 

From my I2C PoV:

Acked-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH v8 09/26] kernel/cpu_pm: Manage runtime PM in the idle path for CPUs

[Sudeep Holla]

On Wed, Aug 08, 2018 at 12:02:48PM -0600, Lina Iyer wrote:

[...]

> I will not speak to any comparison of benchmarks between OSI and PC.
> AFAIK, there are no platforms supporting both.
>

That's the fundamental issue here. So we have never ever done a proper
comparison.

> But, the OSI feature is critical for QCOM mobile platforms. The
> last man activities during cpuidle save quite a lot of power. Powering
> off the clocks, busses, regulators and even the oscillator is very
> important to have a reasonable battery life when using the phone.
> Platform coordinated approach falls quite short of the needs of a
> powerful processor with a desired battery efficiency.
>

As mentioned above, without the actual comparison it's hard to justify
that. While there are corner cases where OSI is able to make better
judgement, may be we can add ways to deal with that in the firmware
with PC mode, have we explored that before adding complexity to the OSPM ?
Since the firmware complexity with OSI remains same as PC mode, isn't it
worth checking if the corner case we are talking here can be handled in
the firmware.

--
Regards,
Sudeep

Re: [PATCH v5 1/4] ACPI / scan: Initialize status to ACPI_STA_DEFAULT

[Rafael J. Wysocki]

On Thu, Aug 9, 2018 at 11:58 AM, Hans de Goede  wrote:
> Hi,
>
> On 09-08-18 11:51, Andy Shevchenko wrote:
>>
>> On Thu, Aug 9, 2018 at 12:39 PM, Hans de Goede 
>> wrote:
>>>
>>> On 09-08-18 11:35, Rafael J. Wysocki wrote:

 On Thu, Aug 9, 2018 at 11:15 AM, Hans de Goede 
 wrote:
>>
>>
 I've applied the v4 of this patch and I don't think there are any
 changes from it here.
>>>
>>>
>>>
>>> Correct, there were only changes to the 4th patch in the series.
>>>
 As for the rest of the series I'll wait from comments from Wolfram and
 the other reviewers.
>>>
>>>
>>>
>>> Ok, note if you've taken patch 1 you may also want to take patch 3 which
>>> is an ACPI code cleanup made possible by patch 1 and otherwise is
>>> unrelated.
>>
>>
>> I'm under impression Rafael is going to take entire series (at least
>> for patch 4 I'm expecting to give an Ack).
>
>
> As I mentioned in the coverletter, my idea was to have Rafael take
> patches 1-3 and then merge the 4th patch through the platform/x86
> tree. There are only runtime dependencies between the 2 parts and
> merging them independently should not cause any issues.

I can apply the 4th one too if it is ACKed by everyone with a vested interest.

Re: [PATCH 03/11] dt-bindings: interrupt-controller: RISC-V PLIC documentation

[Marc Zyngier]

On 08/08/18 17:57, Christoph Hellwig wrote:
> On Wed, Aug 08, 2018 at 05:47:40PM +0100, Marc Zyngier wrote:
>> The original GIC driver deals with 2.5 revisions of the architecture
>> (yes, there was something pre-GICv1...), and implementers have been
>> creative to the extreme. Still, we could have done without most of these
>> compat strings. Hindsight and all that jazz.
>>
>> GICv3 is a much more controlled architecture, and although people have
>> come up with a number of turds masquerading as implementations, it has
>> never been bad enough to mandate a different set of compat strings.
>> Also, you cannot describe that kind of stuff in ACPI, and we need to
>> support both, so we've come up with different ways of handling this.
> 
> So the claim from SiFive is that all their current plic blocks are
> the same.  Based on that I'd be really tempted to just match for
> sifive,plic (or sifive,plic1 as suggested by them), but also require
> each device to actually provide a board specific compatible string,
> just in case that something goes wrong.  Which I suspect is what you
> are doing with GICv3, right?

We do it slightly differently:

Each GICv3 implementation has a set of ID registers that uniquely
identifies the implementer and revision of the HW block. This allows us
to quirk individual implementations while only having a single matching
property, and be independent of a single firmware implementation (DT vs
ACPI).

We don't mandate anything at the board or even SoC level though (it
would quickly become unmanageable given the number of SOCs and devices).

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH RFC v2 02/10] mm: Make shrink_slab() lockless

[Tetsuo Handa]

On 2018/08/09 18:21, Kirill Tkhai wrote:
> 2)SRCU. Pros are there are no the above problems; we will have completely 
> unlocked and
>   scalable shrink_slab(). We will also have a possibility to avoid 
> unregistering delays,
>   like I did for superblock shrinker. There will be full scalability.
>   Cons is enabling SRCU.
> 

How unregistering delays can be avoided? Since you traverse all shrinkers
using one shrinker_srcu, synchronize_srcu(_srcu) will block
unregistering threads until longest inflight srcu_read_lock() user calls
srcu_read_unlock().

Unless you use per shrinker counter like below, I wonder whether
unregistering delays can be avoided...

  https://marc.info/?l=linux-mm=151060909613004
  https://marc.info/?l=linux-mm=151060909713005

[PATCH] staging: rtl8712: remove unused array iw_operation_mode

[Colin King]

From: Colin Ian King 

Array iw_operation_mode is defined but is never used hence it is
redundant and can be removed. This array has been like this since
the driver was added back in 2010

Cleans up clang warning:
warning: 'iw_operation_mode' defined but not used [-Wunused-const-variable=]

Signed-off-by: Colin Ian King 
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index c3ff7c3e6681..12af6f4baa48 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -67,11 +67,6 @@ static const long ieee80211_wlan_frequencies[] = {
2472, 2484
 };
 
-static const char * const iw_operation_mode[] = {
-   "Auto", "Ad-Hoc", "Managed",  "Master", "Repeater", "Secondary",
-"Monitor"
-};
-
 void r8712_indicate_wx_assoc_event(struct _adapter *padapter)
 {
union iwreq_data wrqu;
-- 
2.17.1

Re: [PATCH wireless-drivers] mt76x0: Remove VLA usage

[Kalle Valo]

Stanislaw Gruszka  writes:

> On Wed, Aug 08, 2018 at 08:41:28AM -0700, Kees Cook wrote:
>> >> I thought SPDX line is needed only if file has no license and eeprom.c
>> >> file and other mt76x0 files have specified the license. Is SPDX still
>> >> needed in that case ?
>> 
>> I thought all source files needed SPDX: https://lwn.net/Articles/739183/
>
> Ok, goal is to have all kernel source files with SPDX header.

Yeah, it's a goal but I don't think it's a hard requirement yet. At
least I don't see it as a reason to reject patches.

And besides, mt76 uses ISC license and that's not in LICENSES directory.
So someone should add that first, and I think that patch should go via
Jonathan Corbet's tree (CCed).

-- 
Kalle Valo

[PATCH 0/2] arm64: dts: meson-g12a: Introduce new DT files for Meson-G12A SoC

[Jianxin Pan]

From: Jianxin 

This attempt will try to add new DT files to support Meson-G12A SoC.

1) first, Please notice that, in this patch series, the DT node about 16M 
reserved
memory for hwrom is removed, since it's not needed by G12A SoC.
2) second, the pclk for uart_AO need to be fixed once G12A clock_ao driver is
merged. In this version, it rely on bootloader to enable the pclk gate which 
belong to AO clock domain. Please add clk_ignore_unused to bootargs.


Jianxin Pan (2):
  dt-bindings: arm: amlogic: Add Meson G12A binding
  arm64: dts: meson-g12a: add initial g12a s905d2 SoC DT support

 Documentation/devicetree/bindings/arm/amlogic.txt |   6 +
 arch/arm64/boot/dts/amlogic/Makefile  |   1 +
 arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts   |  22 +++
 arch/arm64/boot/dts/amlogic/meson-g12a.dtsi   | 174 ++
 4 files changed, 203 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12a.dtsi

-- 
1.9.1

Re: Droid 4: suspend to RAM?

[Tony Lindgren]

* Pavel Machek  [180808 21:35]:
> On Wed 2018-08-08 02:05:12, Tony Lindgren wrote:
> > Then for deeper idle modes, you need to also idle UARTs, and unbind or
> > unload USB related modules. You should get to something like 160mW
> > power consumption with mdm6600 enabled and SoC suspended that way.
> 
> That's slightly interesting. echo mem > /sys/power/state should do all
> the work, right? Disable UARTs etc. Plus, is 160mW still a bit high?

Yes suspend will do it, you still need to configure wake-up events
though at least for the UARTs. I think I got enabled mdm6600 to low-power
state after connecting over UART ts27010 and then suspending OHCI:

ohci=$(find /sys/bus/platform/devices -name \*.ohci)
devices=$(find ${ohci}/ -type d -name control)
for device in ${devices}; do
echo -n "auto" > ${device}/level
echo -n "control" > ${device}/level
done

echo "usb-phy@1" > /sys/bus/platform/drivers/phy-mapphone-mdm6600/unbind

For power consumption, 160mW is high yeah. We currently cannot hit core
retention on omap4 until some GPIO issues are fixed. I've been trying to
think for a good fix for that, but need to debug it more when I get a chance.

>From few months ago, I recall I got droid4 to run at around 65mW idle
with WLAN connected and modem off with my test hacks. With modem on
and USB suspended I think I got to around 100mW.

Then I recall measuring droid4 with stock android in flight mode
measuring at around 15 - 30mW. But that requires off mode to work on
omap4, maybe we'll get to that too at some point after core retention.

Regards,

Tony

[PATCH v3] mm: Use special value SHRINKER_REGISTERING instead list_empty() check

[Kirill Tkhai]

v3: Added missed #ifdef CONFIG_MEMCG_KMEM around idr_replace()

v2: Improved comments to SHRINKER_REGISTERING and written
long description about all the things to the patch.

The patch introduces a special value SHRINKER_REGISTERING
to use instead of list_empty() to differ a registering
shrinker from unregistered shrinker. Why we need that at all?
The below is long description of all shrinker heroes and
explanation.

Shrinker registration is split in two parts. The first one
is prealloc_shrinker(), which allocates shrinker memory and
reserves ID in shrinker_idr. This function can fail.
The second is register_shrinker_prepared(), and it finalizes
the registration. This function actually makes shrinker
available to be used from shrink_slab(), and it can't fail.

One shrinker may be based on more then one LRU lists. So,
we never clear the bit in memcg shrinker maps, when (one of)
corresponding LRU list becomes empty, since other LRU lists
may be not empty. See superblock shrinker for example:
it is based on two LRU lists: s_inode_lru and s_dentry_lru.
We do not want to clear shrinker bit, when there are no inodes
in s_inode_lru, as s_dentry_lru may contain dentries.

Instead of that, we use special algorithm to detect shrinkers
having no elements at all its LRU lists, and this is made
in shrink_slab_memcg(). See the comment in this function
for the details.

Also, in shrink_slab_memcg() we clear shrinker bit in the map,
when we meet unregistered shrinker (bit is set, while there is
no a shrinker in IDR). Otherwise, we would have done that
at the moment of shrinker unregistration for all memcgs (and this
looks worse, since iteration over all memcg may take much time).
Also this would have imposed restrictions on shrinker unregistration
order for its users: they would have had to guarantee, there are
no new elements after unregister_shrinker() (otherwise, a new
added element would have set a bit).

So, if we meet a set bit in map and no shrinker in IDR
when we're iterating over the map in shrink_slab_memcg(),
this means the corresponding shrinker is unregistered, and we
must clear the bit.

Another case is shrinker registration. We want two things there:

1)do_shrink_slab() can be called only for completely registered
  shrinkers;
2)shrinker internal lists may be populated in any order with
  register_shrinker_prepared() (let's talk on the example with sb).
  Both of:

  a)list_lru_add(>i_sb->s_inode_lru, >i_lru); [cpu0]
memcg_set_shrinker_bit();   [cpu0]
...
register_shrinker_prepared();   [cpu1]

  and

  b)register_shrinker_prepared();   [cpu0]
...
list_lru_add(>i_sb->s_inode_lru, >i_lru); [cpu1]
memcg_set_shrinker_bit();   [cpu1]

   are legitimate. We don't want to impose restriction here and
   to force people to use only (b) variant. We don't want to force
   people to care, there is no elements in LRU lists before
   the shrinker is completely registered. Internal users LRU lists
   and shrinker code are two different subsystems, and they have
   to be closed in themselves each other.

In (a) case we have the bit set before shrinker is completely
registered. We don't want do_shrink_slab() is called at this moment,
so we have to detect such the registering shrinkers.

Before this patch list_empty() (shrinker is not linked to the list)
check was used for that. So, in (a) there could be a bit set, but
we don't call do_shrink_slab() unless shrinker is linked to the list.
It's just an indicator, I just overloaded linking to the list.

This was not the best solution, since it's better not to touch
the shrinker memory from shrink_slab_memcg() before it's completely
registered (this also will be useful in the future to make shrink_slab()
completely lockless).

So, this patch introduces better way to detect registering shrinker,
which allows not to dereference shrinker memory. It's just a ~0UL
value, which we insert into the IDR during ID allocation. After
shrinker is ready to be used, we insert actual shrinker pointer
in the IDR, and it becomes available to shrink_slab_memcg().

We can't use NULL instead of this new value for this purpose:
shrink_slab_memcg() already uses NULL to detect unregistered
shrinkers, and we don't want the function sees NULL and
clears the bit, otherwise (a) won't work.

This is the only thing the patch makes: the better way to detect
registering shrinker.

Also this gives a better assembler, but it's minor side of the patch:

Before:
callq  
mov%rax,%r15
test   %rax,%rax
je 
mov0x20(%rax),%rax
lea0x20(%r15),%rdx
cmp%rax,%rdx
je 
mov0x8(%rsp),%edx
mov%r15,%rsi
lea0x10(%rsp),%rdi
callq  

After:
callq  
mov%rax,%r15
lea-0x1(%rax),%rax
cmp$0xfffd,%rax
ja 
mov0x8(%rsp),%edx
mov%r15,%rsi
lea0x10(%rsp),%rdi
callq  810cefd0 

Signed-off-by: Kirill Tkhai 
---
 mm/vmscan.c |   43 

[PATCH 1/2] dt-bindings: arm: amlogic: Add Meson G12A binding

[Jianxin Pan]

Introduce new bindings for the Meson G12A SoC

Signed-off-by: Jianxin Pan 
---
 Documentation/devicetree/bindings/arm/amlogic.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt 
b/Documentation/devicetree/bindings/arm/amlogic.txt
index b5c2b5c..cf4bbc7 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -57,6 +57,10 @@ Boards with the Amlogic Meson AXG A113D SoC shall have the 
following properties:
   Required root node property:
 compatible: "amlogic,a113d", "amlogic,meson-axg";
 
+Boards with the Amlogic Meson G12A S905D2 SoC shall have the following 
properties:
+  Required root node property:
+compatible: "amlogic,g12a";
+
 Board compatible values (alphabetically, grouped by SoC):
 
   - "geniatech,atv1200" (Meson6)
@@ -101,6 +105,8 @@ Board compatible values (alphabetically, grouped by SoC):
 
   - "amlogic,s400" (Meson axg a113d)
 
+  - "amlogic,u200" (Meson g12a s905d2)
+
 Amlogic Meson Firmware registers Interface
 --
 
-- 
1.9.1

[PATCH 2/2] arm64: dts: meson-g12a: add initial g12a s905d2 SoC DT support

[Jianxin Pan]

Try to add basic DT support for the Amlogic's Meson-G12A S905D2 SoC,
which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
Timer, UART. It's capable of booting up into the serial console.

Signed-off-by: Jianxin 
---
 arch/arm64/boot/dts/amlogic/Makefile|   1 +
 arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts |  22 +++
 arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 174 
 3 files changed, 197 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12a.dtsi

diff --git a/arch/arm64/boot/dts/amlogic/Makefile 
b/arch/arm64/boot/dts/amlogic/Makefile
index a97c0e2..c31f29d6 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_ARCH_MESON) += meson-axg-s400.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-nanopi-k2.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-nexbox-a95x.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-odroidc2.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts 
b/arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts
new file mode 100644
index 000..d267a37
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-u200.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "meson-g12a.dtsi"
+
+/ {
+   compatible = "amlogic,u200", "amlogic,g12a";
+   model = "Amlogic Meson G12A U200 Development Board";
+
+   aliases {
+   serial0 = _AO;
+   };
+};
+
+_AO {
+   status = "okay";
+};
+
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
new file mode 100644
index 000..64a0f2e
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "amlogic,g12a";
+
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   /* Alternate 3 MiB reserved for ARM Trusted Firmware (BL31) */
+   secmon_reserved: secmon@500 {
+   reg = <0x0 0x0500 0x0 0x30>;
+   no-map;
+   };
+   };
+
+   cpus {
+   #address-cells = <0x2>;
+   #size-cells = <0x0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   next-level-cache = <>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   next-level-cache = <>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x2>;
+   enable-method = "psci";
+   next-level-cache = <>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x3>;
+   enable-method = "psci";
+   next-level-cache = <>;
+   };
+
+   l2: l2-cache0 {
+   compatible = "cache";
+   };
+   };
+
+   psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupts = ,
+,
+,
+;
+   };
+
+   xtal: xtal-clk {
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   clock-output-names = "xtal";
+   #clock-cells = <0>;
+   };
+
+   soc {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   apb: apb@ffe0 {
+   compatible = "simple-bus";
+   reg = <0x0 0xffe0 0x0 0x20>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges = <0x0 0x0 0x0 

Re: FUSE: write operations trigger balance_dirty_pages when using writeback cache

[Miklos Szeredi]

On Thu, Aug 9, 2018 at 9:31 AM, 刘硕然  wrote:
> Thank you for the prompt reply.
>
> I tried this config, but still can get balance_dirty_pages triggered.

I think it may be due to BDI_CAP_STRICTLIMIT used by fuse.  If you
remove that setting from fuse in the kernel you should not be getting
the balance_dirty_pages() as often.

Not sure if that's the realproblem, though, that depends on how much
time is spent in balance_dirty_pages().  You can try profiling the
kernel to find that out.

My guess is that the real cause of the slowdown is some other place.
There's for example a known issue with selinux related getxattr
thrashing.  Disabling getxattr on your filesystem may significantly
improve performance.

Thanks,
Miklos

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

[Cornelia Huck]

On Wed,  8 Aug 2018 10:44:14 -0400
Tony Krowiak  wrote:

> From: Harald Freudenberger 
> 
> Move all the inline functions from the ap bus header
> file ap_asm.h into the in-kernel api header file
> arch/s390/include/asm/ap.h so that KVM can make use
> of all the low level AP functions.
> 
> Signed-off-by: Harald Freudenberger 
> Signed-off-by: Christian Borntraeger 

You should add your own s-o-b if you are sending on patches written by
others (even if it does not matter in the end, when they are merged
through a different path anyway.)

> ---
>  arch/s390/include/asm/ap.h |  284 
> 
>  drivers/s390/crypto/ap_asm.h   |  261 
>  drivers/s390/crypto/ap_bus.c   |   21 +---
>  drivers/s390/crypto/ap_bus.h   |1 +
>  drivers/s390/crypto/ap_card.c  |1 -
>  drivers/s390/crypto/ap_queue.c |1 -
>  6 files changed, 259 insertions(+), 310 deletions(-)
>  delete mode 100644 drivers/s390/crypto/ap_asm.h
> 
> diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
> index c1bedb4..046e044 100644
> --- a/arch/s390/include/asm/ap.h
> +++ b/arch/s390/include/asm/ap.h
> @@ -47,6 +47,50 @@ struct ap_queue_status {
>  };
>  
>  /**
> + * ap_intructions_available() - Test if AP instructions are available.
> + *
> + * Returns 0 if the AP instructions are installed.

Stumbled over this when I was looking at the usage in patch 7: if I see
a function called '_available' return 0, I'd assume that whatever the
function tests for is *not* available.

Rather call this function ap_instructions_check_availability() (and
keep the return code convention), or switch this to return 0 if not
available and !0 if available?

> + */
> +static inline int ap_instructions_available(void)
> +{
> + register unsigned long reg0 asm ("0") = AP_MKQID(0, 0);
> + register unsigned long reg1 asm ("1") = -ENODEV;
> + register unsigned long reg2 asm ("2");
> +
> + asm volatile(
> + "   .long 0xb2af\n" /* PQAP(TAPQ) */
> + "0: la%0,0\n"
> + "1:\n"
> + EX_TABLE(0b, 1b)
> + : "+d" (reg1), "=d" (reg2)
> + : "d" (reg0)
> + : "cc");
> + return reg1;
> +}

Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping

[Patrick Bellasi]

On 07-Aug 14:35, Juri Lelli wrote:
> On 06/08/18 17:39, Patrick Bellasi wrote:
> 
> [...]
> 
> > @@ -4218,6 +4245,13 @@ static int __sched_setscheduler(struct task_struct 
> > *p,
> > return retval;
> > }
> >  
> > +   /* Configure utilization clamps for the task */
> > +   if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP) {
> > +   retval = __setscheduler_uclamp(p, attr);
> > +   if (retval)
> > +   return retval;
> > +   }
> > +
> 
> IIUC, this is available to root and non-root users. In the latter case,
> how do we cope with the fact that some user might occupy all the
> available clamping groups configured for the system?

That's a very good point, glad you noticed it.

What concern me most is that we set constraints to the cgroups
delegation model. If all clamp groups have been used it could be
not possible for a parent group to shrink resources for its subgroups.

In both cases however, in principle, I think we can live with the idea
that the "System Management Software" (SMS) can pre-allocate all the
required boost groups at boot time;  malicious tasks and dependent
groups will eventually get an -ENOSPC error.

These are the main reason why I did not posted a more "safe" solution:
this series is already big enough, a properly (pre)configured system
is still reasonably functional safe and  this feature can be added in
a second step.

However, I already have a couple of possible extensions/fixes which I
can add on top on the next respin. They are along these lines:
1) make CAP_SYS_NICE protected the clamp groups, with an optional boot
   time parameter to relax this check
2) add discretization support to clamp groups allocation

This second feature specifically, will ensure that clamp values are
always mapped into one of the available clamp groups. While the exact
clamp value can always be used for tasks placement biasing, when it
comes to frequency selection biasing, depending on concurrently
running tasks, you can end up with an effective clamp value which is a
rounded up.

Will likely add a couple of additional patches on v4 posting.
Do you have any other possible idea?

Cheers Patrick

-- 
#include 

Patrick Bellasi

Re: [PATCH v2 1/2] firmware: coreboot: Let OF core populate platform device

[Sudeep Holla]

On Wed, Aug 08, 2018 at 10:24:13AM -0700, Stephen Boyd wrote:
> Now that the /firmware/coreboot node in DT is populated by the core DT
> platform code with commit 3aa0582fdb82 ("of: platform: populate
> /firmware/ node from of_platform_default_populate_init()") we should and
> can remove the platform device creation here. Otherwise, the
> of_platform_device_create() call will fail, the coreboot of driver won't
> be registered, and this driver will never bind. At the same time, we
> should move this driver to use MODULE_DEVICE_TABLE so that module
> auto-load works properly when the coreboot device is auto-populated and
> we should drop the of_node handling that was presumably placed here to
> hold a reference to the DT node created during module init that no
> longer happens.
>
> Cc: Wei-Ning Huang 
> Cc: Julius Werner 
> Cc: Brian Norris 
> Cc: Samuel Holland 
> Cc: Sudeep Holla 

Reviewed-by: Sudeep Holla 

--
Regards,
Sudeep

Re: [PATCH v4 4/4] i2c: Add multi-instantiate pseudo driver

[Hans de Goede]

Hi,

On 08-08-18 19:00, Wolfram Sang wrote:


$subject still says "i2c:"


Ah, good point I will send a v5 with this fixed, I will also
do s/no_clients/num_clients/ for v5 as Andy requested.

Regards,

Hans

Re: [PATCH v5 1/4] ACPI / scan: Initialize status to ACPI_STA_DEFAULT

[Rafael J. Wysocki]

On Thu, Aug 9, 2018 at 11:15 AM, Hans de Goede  wrote:
> Since commit 63347db0affa ("ACPI / scan: Use acpi_bus_get_status() to
> initialize ACPI_TYPE_DEVICE devs") the status field of normal acpi_devices
> gets set to 0 by acpi_bus_type_and_status() and filled with its actual
> value later when acpi_add_single_object() calls acpi_bus_get_status().
>
> This means that any acpi_match_device_ids() calls in between will always
> fail with -ENOENT.
>
> We already have a workaround for this, which temporary forces status to
> ACPI_STA_DEFAULT in drivers/acpi/x86/utils.c: acpi_device_always_present()
> and the next commit in this series adds another acpi_match_device_ids()
> call between status being initialized as 0 and the acpi_bus_get_status()
> call.
>
> Rather then adding another workaround, this commit makes
> acpi_bus_type_and_status() initialize status to ACPI_STA_DEFAULT, this is
> safe to do as the only code looking at status between the initialization
> and the acpi_bus_get_status() call is those acpi_match_device_ids() calls.
>
> Note this does mean that we need to (re)set status to 0 in case the
> acpi_bus_get_status() call fails.
>
> Signed-off-by: Hans de Goede 
> ---
> Changes in v3:
> -New patch in v3 of this patch-set
>
> Changes in v4:
> -This is not a fix for acpi_is_indirect_io_slave() as I thought at first,
>  acpi_is_indirect_io_slave() calls acpi_match_device_ids() on its parent
>  device, where status is already set properly. Rewrite the commit message
>  accordingly.

I've applied the v4 of this patch and I don't think there are any
changes from it here.

As for the rest of the series I'll wait from comments from Wolfram and
the other reviewers.

Thanks,
Rafael

[PATCH] x86, relocs: Add __end_rodata_aligned to S_REL

[Joerg Roedel]

This new symbol needs to be in the workaround-list for buggy
binutils, otherwise the build with gcc-4.6 fails.

Fixes: 39d668e04eda ('x86/mm/pti: Make pti_clone_kernel_text() compile on 32 
bit')
Signed-off-by: Joerg Roedel 
---
 arch/x86/tools/relocs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 220e97841e49..3a6c8ebc8032 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -67,6 +67,7 @@ static const char * const sym_regex_kernel[S_NSYMTYPES] = {
"__tracedata_(start|end)|"
"__(start|stop)_notes|"
"__end_rodata|"
+   "__end_rodata_aligned|"
"__initramfs_start|"
"(jiffies|jiffies_64)|"
 #if ELF_BITS == 64
-- 
2.16.4

Re: [PATCH v5 1/4] ACPI / scan: Initialize status to ACPI_STA_DEFAULT

[Andy Shevchenko]

On Thu, Aug 9, 2018 at 12:39 PM, Hans de Goede  wrote:
> On 09-08-18 11:35, Rafael J. Wysocki wrote:
>> On Thu, Aug 9, 2018 at 11:15 AM, Hans de Goede 
>> wrote:

>> I've applied the v4 of this patch and I don't think there are any
>> changes from it here.
>
>
> Correct, there were only changes to the 4th patch in the series.
>
>> As for the rest of the series I'll wait from comments from Wolfram and
>> the other reviewers.
>
>
> Ok, note if you've taken patch 1 you may also want to take patch 3 which
> is an ACPI code cleanup made possible by patch 1 and otherwise is
> unrelated.

I'm under impression Rafael is going to take entire series (at least
for patch 4 I'm expecting to give an Ack).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 3/4] ACPI / x86-utils: Remove status workaround from acpi_device_always_present()

[Andy Shevchenko]

On Thu, 2018-08-09 at 11:15 +0200, Hans de Goede wrote:
> Now that we init the status field to ACPI_STA_DEFAULT rather then to
> 0,
> the workaround for acpi_match_device_ids() always returning -ENOENT
> when
> status is 0 is no longer needed.
> 

Always good to have only "minus" statistics

Reviewed-by: Andy Shevchenko 

> Signed-off-by: Hans de Goede 
> ---
> Changes in v3:
> -New patch in v3 of this patch-set
> ---
>  drivers/acpi/x86/utils.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
> index ec5b0f190231..a4fb97d64b3b 100644
> --- a/drivers/acpi/x86/utils.c
> +++ b/drivers/acpi/x86/utils.c
> @@ -103,13 +103,9 @@ static const struct always_present_id
> always_present_ids[] = {
>  
>  bool acpi_device_always_present(struct acpi_device *adev)
>  {
> - u32 *status = (u32 *)>status;
> - u32 old_status = *status;
>   bool ret = false;
>   unsigned int i;
>  
> - /* acpi_match_device_ids checks status, so set it to default */
> - *status = ACPI_STA_DEFAULT;
>   for (i = 0; i < ARRAY_SIZE(always_present_ids); i++) {
>   if (acpi_match_device_ids(adev,
> always_present_ids[i].hid))
>   continue;
> @@ -125,15 +121,9 @@ bool acpi_device_always_present(struct
> acpi_device *adev)
>   !dmi_check_system(always_present_ids[i].dmi_ids))
>   continue;
>  
> - if (old_status != ACPI_STA_DEFAULT) /* Log only once */
> - dev_info(>dev,
> -  "Device [%s] is in always present
> list\n",
> -  adev->pnp.bus_id);
> -
>   ret = true;
>   break;
>   }
> - *status = old_status;
>  
>   return ret;
>  }

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v5 2/4] ACPI / scan: Create platform device for fwnodes with multiple i2c devices

[Andy Shevchenko]

On Thu, 2018-08-09 at 11:15 +0200, Hans de Goede wrote:
> Some devices have multiple I2cSerialBus resources and for things to
> work
> an i2c-client must be instantiated for each, each with its own
> i2c_device_id.
> 
> Normally we only instantiate an i2c-client for the first resource,
> using
> the ACPI HID as id.
> 
> This commit adds a list of HIDs of devices, which need multiple i2c-
> clients
> instantiated from a single fwnode, to
> acpi_device_enumeration_by_parent and
> makes acpi_device_enumeration_by_parent return false for these devices
> so
> that a platform device will be instantiated.
> 
> This allows the drivers/platform/x86/i2c-multi-instantiate.c driver,
> which
> knows which i2c_device_id to use for each resource, to bind to the
> fwnode
> and initiate an i2c-client for each resource.
> 

I like this approach

Reviewed-by: Andy Shevchenko 


> Signed-off-by: Hans de Goede 
> ---
> Changes in v3:
> -New patch in v3 of this patch-set
> 
> Changes in v4:
> -Some small code-style fixes
> ---
>  drivers/acpi/scan.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 6799d00dd790..b51913372e21 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1540,6 +1540,18 @@ static bool
> acpi_device_enumeration_by_parent(struct acpi_device *device)
>  {
>   struct list_head resource_list;
>   bool is_serial_bus_slave = false;
> + /*
> +  * These devices have multiple I2cSerialBus resources and an
> i2c-client
> +  * must be instantiated for each, each with its own
> i2c_device_id.
> +  * Normally we only instantiate an i2c-client for the first
> resource,
> +  * using the ACPI HID as id. These special cases are handled by
> the
> +  * drivers/platform/x86/i2c-multi-instantiate.c driver, which
> knows
> +  * which i2c_device_id to use for each resource.
> +  */
> + static const struct acpi_device_id i2c_multi_instantiate_ids[] =
> {
> + {"BSG1160", },
> + {}
> + };
>  
>   if (acpi_is_indirect_io_slave(device))
>   return true;
> @@ -1551,6 +1563,10 @@ static bool
> acpi_device_enumeration_by_parent(struct acpi_device *device)
>fwnode_property_present(>fwnode, "baud")))
>   return true;
>  
> + /* Instantiate a pdev for the i2c-multi-instantiate drv to bind
> to */
> + if (!acpi_match_device_ids(device, i2c_multi_instantiate_ids))
> + return false;
> +
>   INIT_LIST_HEAD(_list);
>   acpi_dev_get_resources(device, _list,
>  acpi_check_serial_bus_slave,

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v5 4/4] platform/x86: Add ACPI i2c-multi-instantiate pseudo driver

[Andy Shevchenko]

On Thu, 2018-08-09 at 11:15 +0200, Hans de Goede wrote:
> On systems with ACPI instantiated i2c-clients, normally there is 1
> fw_node
> per i2c-device and that fw-node contains 1 I2cSerialBus resource for
> that 1
> i2c-device.
> 
> But in some rare cases the manufacturer has decided to describe
> multiple
> i2c-devices in a single ACPI fwnode with multiple I2cSerialBus
> resources.
> 
> An earlier attempt to fix this in the i2c-core resulted in a lot of
> extra
> code to support this corner-case.
> 
> This commit introduces a new i2c-multi-instantiate driver which fixes
> this
> in a different way. This new driver can be built as a module which
> will
> only loaded on affected systems.
> 
> This driver will instantiate a new i2c-client per I2cSerialBus
> resource,
> using the driver_data from the acpi_device_id it is binding to to tell
> it
> which chip-type (and optional irq-resource) to use when instantiating.
> 
> Note this driver depends on a platform device being instantiated for
> the
> ACPI fwnode, see the i2c_multi_instantiate_ids list of ACPI device-ids 
> in
> drivers/acpi/scan.c: acpi_device_enumeration_by_parent().
> 

Acked-by: Andy Shevchenko 

(From PDx86 prospective)

> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Rebase on top of 4.18-rc2
> 
> Changes in v3:
> -Change from an i2c-driver using a hack to allow having multiple i2c
> clients
>  at the same address to a platform-driver
> 
> Changes in v4:
> -Tweak MAINTAINERS entry a bit
> 
> Changes in v5:
> -s/no_clients/num_clients/
> -Change patch Subject prefix to platform/x86
> ---
>  MAINTAINERS  |   6 +
>  drivers/platform/x86/Kconfig |  11 ++
>  drivers/platform/x86/Makefile|   1 +
>  drivers/platform/x86/i2c-multi-instantiate.c | 131
> +++
>  4 files changed, 149 insertions(+)
>  create mode 100644 drivers/platform/x86/i2c-multi-instantiate.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9b377508f24f..dbe7836e4f6b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -367,6 +367,12 @@ L:   linux-a...@vger.kernel.org
>  S:   Maintained
>  F:   drivers/acpi/arm64
>  
> +ACPI I2C MULTI INSTANTIATE DRIVER
> +M:   Hans de Goede 
> +L:   platform-driver-...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/platform/x86/i2c-multi-instantiate.c
> +
>  ACPI PMIC DRIVERS
>  M:   "Rafael J. Wysocki" 
>  M:   Len Brown 
> diff --git a/drivers/platform/x86/Kconfig
> b/drivers/platform/x86/Kconfig
> index 85a93453237c..64c82592d4b6 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -1219,6 +1219,17 @@ config INTEL_CHTDC_TI_PWRBTN
> To compile this driver as a module, choose M here: the module
> will be called intel_chtdc_ti_pwrbtn.
>  
> +config I2C_MULTI_INSTANTIATE
> + tristate "I2C multi instantiate pseudo device driver"
> + depends on I2C && ACPI
> + help
> +   Some ACPI-based systems list multiple i2c-devices in a single
> ACPI
> +   firmware-node. This driver will instantiate separate i2c-
> clients
> +   for each device in the firmware-node.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called i2c-multi-instantiate.
> +
>  endif # X86_PLATFORM_DEVICES
>  
>  config PMC_ATOM
> diff --git a/drivers/platform/x86/Makefile
> b/drivers/platform/x86/Makefile
> index 8d9477114fb5..e6d1becf81ce 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -91,3 +91,4 @@ obj-$(CONFIG_PMC_ATOM)  += pmc_atom.o
>  obj-$(CONFIG_MLX_PLATFORM)   += mlx-platform.o
>  obj-$(CONFIG_INTEL_TURBO_MAX_3) += intel_turbo_max_3.o
>  obj-$(CONFIG_INTEL_CHTDC_TI_PWRBTN)  += intel_chtdc_ti_pwrbtn.o
> +obj-$(CONFIG_I2C_MULTI_INSTANTIATE)  += i2c-multi-instantiate.o
> diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
> b/drivers/platform/x86/i2c-multi-instantiate.c
> new file mode 100644
> index ..75c00630ecde
> --- /dev/null
> +++ b/drivers/platform/x86/i2c-multi-instantiate.c
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * I2C multi-instantiate driver, pseudo driver to instantiate
> multiple
> + * i2c-clients from a single fwnode.
> + *
> + * Copyright 2018 Hans de Goede 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct i2c_inst_data {
> + const char *type;
> + int irq_idx;
> +};
> +
> +struct i2c_multi_inst_data {
> + int num_clients;
> + struct i2c_client *clients[0];
> +};
> +
> +static int i2c_multi_inst_probe(struct platform_device *pdev)
> +{
> + struct i2c_multi_inst_data *multi;
> + const struct acpi_device_id *match;
> + const struct i2c_inst_data *inst_data;
> + struct i2c_board_info board_info = {};
> + struct device *dev = >dev;
> + struct acpi_device *adev;
> + char name[32];
> + int i, ret;
> +
> + match = 

Applied "ASoC: da7219: Add delays to capture path to remove DC offset noise" to the asoc tree

[Mark Brown]

The patch

   ASoC: da7219: Add delays to capture path to remove DC offset noise

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 17c81d2f5a59929c73a2a19fd49fe0b068fda76f Mon Sep 17 00:00:00 2001
From: Adam Thomson 
Date: Thu, 9 Aug 2018 10:48:50 +0100
Subject: [PATCH] ASoC: da7219: Add delays to capture path to remove DC offset
 noise

On some platforms it has been noted that a pop noise can be
witnessed when capturing audio, mainly for first time after a
headset jack has been inserted. This is due to a DC offset in the
Mic PGA and so to avoid this delays are required when powering
up the capture path.

This commit rectifies the problem by adding delays post Mic PGA and
post Mixin PGA. The post Mic PGA delay is determined based on
Mic Bias voltage, and is only applied the first time after a
headset jack is inserted.

Signed-off-by: Adam Thomson 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/da7219-aad.c |  5 
 sound/soc/codecs/da7219.c | 44 ++-
 sound/soc/codecs/da7219.h |  8 +--
 3 files changed, 49 insertions(+), 8 deletions(-)

diff --git a/sound/soc/codecs/da7219-aad.c b/sound/soc/codecs/da7219-aad.c
index a49ab751a036..2c7d5088e6f2 100644
--- a/sound/soc/codecs/da7219-aad.c
+++ b/sound/soc/codecs/da7219-aad.c
@@ -59,6 +59,7 @@ static void da7219_aad_btn_det_work(struct work_struct *work)
container_of(work, struct da7219_aad_priv, btn_det_work);
struct snd_soc_component *component = da7219_aad->component;
struct snd_soc_dapm_context *dapm = 
snd_soc_component_get_dapm(component);
+   struct da7219_priv *da7219 = snd_soc_component_get_drvdata(component);
u8 statusa, micbias_ctrl;
bool micbias_up = false;
int retries = 0;
@@ -86,6 +87,8 @@ static void da7219_aad_btn_det_work(struct work_struct *work)
if (retries >= DA7219_AAD_MICBIAS_CHK_RETRIES)
dev_warn(component->dev, "Mic bias status check timed out");
 
+   da7219->micbias_on_event = true;
+
/*
 * Mic bias pulse required to enable mic, must be done before enabling
 * button detection to prevent erroneous button readings.
@@ -439,6 +442,8 @@ static irqreturn_t da7219_aad_irq_thread(int irq, void 
*data)
snd_soc_component_update_bits(component, 
DA7219_ACCDET_CONFIG_1,
DA7219_BUTTON_CONFIG_MASK, 0);
 
+   da7219->micbias_on_event = false;
+
/* Disable mic bias */
snd_soc_dapm_disable_pin(dapm, "Mic Bias");
snd_soc_dapm_sync(dapm);
diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
index c0144f2f8174..e46e9f4bc994 100644
--- a/sound/soc/codecs/da7219.c
+++ b/sound/soc/codecs/da7219.c
@@ -768,6 +768,30 @@ static const struct snd_kcontrol_new 
da7219_st_out_filtr_mix_controls[] = {
  * DAPM Events
  */
 
+static int da7219_mic_pga_event(struct snd_soc_dapm_widget *w,
+   struct snd_kcontrol *kcontrol, int event)
+{
+   struct snd_soc_component *component = 
snd_soc_dapm_to_component(w->dapm);
+   struct da7219_priv *da7219 = snd_soc_component_get_drvdata(component);
+
+   switch (event) {
+   case SND_SOC_DAPM_POST_PMU:
+   if (da7219->micbias_on_event) {
+   /*
+* Delay only for first capture after bias enabled to
+* avoid possible DC offset related noise.
+*/
+   da7219->micbias_on_event = false;
+   msleep(da7219->mic_pga_delay);
+   }
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
 static int da7219_dai_event(struct snd_soc_dapm_widget *w,
struct snd_kcontrol *kcontrol, int event)
 {
@@ -937,12 +961,12 @@ static const struct snd_soc_dapm_widget 
da7219_dapm_widgets[] = {
SND_SOC_DAPM_INPUT("MIC"),
 
/* Input PGAs */
-   SND_SOC_DAPM_PGA("Mic PGA", DA7219_MIC_1_CTRL,
-

Re: [PATCH v5 3/6] regmap: Add regmap_noinc_read API

[Mark Brown]

On Tue, Aug 07, 2018 at 05:52:17PM +0300, Stefan Popa wrote:
> From: Crestez Dan Leonard 
> 
> The regmap API usually assumes that bulk read operations will read a
> range of registers but some I2C/SPI devices have certain registers for

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 
tags/regmap-noinc-read

for you to fetch changes up to 74fe7b551f3385fa585d92616c85b3a575b2b2cb:

  regmap: Add regmap_noinc_read API (2018-08-09 11:00:15 +0100)


regmap: Support non-incrementing registers

Some devices have individual registers that don't autoincrement the
register address during bulk reads but instead repeatedly read the same
value, for example for monitoring GPIOs or ADCs.  Add support for these.


Crestez Dan Leonard (1):
  regmap: Add regmap_noinc_read API

 drivers/base/regmap/internal.h |  3 ++
 drivers/base/regmap/regmap.c   | 79 +-
 include/linux/regmap.h | 19 ++
 3 files changed, 100 insertions(+), 1 deletion(-)


signature.asc
Description: PGP signature

Re: [PATCH v8 09/26] kernel/cpu_pm: Manage runtime PM in the idle path for CPUs

[Lorenzo Pieralisi]

On Wed, Aug 08, 2018 at 12:02:48PM -0600, Lina Iyer wrote:
> On Wed, Aug 08 2018 at 04:56 -0600, Lorenzo Pieralisi wrote:
> >On Mon, Aug 06, 2018 at 11:37:55AM +0200, Rafael J. Wysocki wrote:
> >>On Fri, Aug 3, 2018 at 1:42 PM, Ulf Hansson  wrote:
> >>> [...]
> >>>
> >
> > Assuming that I have got that right, there are concerns, mostly 
> > regarding
> > patch [07/26], but I will reply to that directly.
> 
>  Well, I haven't got that right, so never mind.
> 
>  There are a few minor things to address, but apart from that the general
>  genpd patches look ready.
> >>>
> >>> Alright, thanks!
> >>>
> >>> I will re-spin the series and post a new version once 4.19 rc1 is out.
> >>> Hopefully we can queue it up early in next cycle to get it tested in
> >>> next for a while.
> >>>
> 
> > The $subject patch is fine by me by itself, but it obviously depends on 
> > the
> > previous ones.  Patches [01-02/26] are fine too, but they don't seem to 
> > be
> > particularly useful without the rest of the series.
> >
> > As far as patches [10-26/26] go, I'd like to see some review comments 
> > and/or
> > tags from the people with vested interest in there, in particular from 
> > Daniel
> > on patch [12/26] and from Sudeep on the PSCI ones.
> 
>  But this still holds.
> >>>
> >>> Actually, patch 10 and patch11 is ready to go as well. I ping Daniel
> >>> on patch 12.
> >>>
> >>> In regards to the rest of the series, some of the PSCI/ARM changes
> >>> have been reviewed by Mark Rutland, however several changes have not
> >>> been acked.
> >>>
> >>> On the other hand, one can also interpret the long silence in regards
> >>> to PSCI/ARM changes as they are good to go. :-)
> >>
> >>Well, in that case giving an ACK to them should not be an issue for
> >>the people with a vested interest I suppose.
> >
> >Apologies to everyone for the delay in replying.
> >
> >Side note: cpu_pm_enter()/exit() are also called through syscore ops in
> >s2RAM/IDLE, you know that but I just wanted to mention it to compound
> >the discussion.
> >
> >As for PSCI patches I do not personally think PSCI OSI enablement is
> >beneficial (and my position has always been the same since PSCI OSI was
> >added to the specification, I am not even talking about this patchset)
> >and Arm Trusted Firmware does not currently support it for the same
> >reason.
> >
> >We (if Mark and Sudeep agree) will enable PSCI OSI if and when we have a
> >definitive and constructive answer to *why* we have to do that that is
> >not a dogmatic "the kernel knows better" but rather a comprehensive
> >power benchmark evaluation - I thought that was the agreement reached
> >at OSPM but apparently I was mistaken.
> >
> I will not speak to any comparison of benchmarks between OSI and PC.
> AFAIK, there are no platforms supporting both.

PSCI specifications, 5.20.1:

"The platform will boot in platform-coordinated mode."

So all platforms implementing OSI have to support both.

> But, the OSI feature is critical for QCOM mobile platforms. The
> last man activities during cpuidle save quite a lot of power.

What I expressed above was that, in PSCI based systems (OSI or PC
alike), it is up to firmware/hardware to detect "the last man" not
the kernel.

I need to understand what you mean by "last man activities" to
provide feedback here.

> Powering off the clocks, busses, regulators and even the oscillator is
> very important to have a reasonable battery life when using the phone.
> Platform coordinated approach falls quite short of the needs of a
> powerful processor with a desired battery efficiency.

I am sorry but if you want us to merge PSCI patches in this series you
will have to back the claim above with a detailed technical explanation
of *why* platform-coordination falls short of QCOM (or whoever else)
needs wrt PSCI OSI.

Thanks,
Lorenzo

Re: [PATCH] sched: idle: Reenable sched tick for cpuidle request

[Peter Zijlstra]

On Thu, Aug 09, 2018 at 01:47:27PM +0800, Leo Yan wrote:
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index 1a3e9bd..802286e 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -190,10 +190,18 @@ static void cpuidle_idle_call(void)
>*/
>   next_state = cpuidle_select(drv, dev, _tick);
>  
> - if (stop_tick)
> + if (stop_tick) {
>   tick_nohz_idle_stop_tick();
> - else
> + } else {
> + /*
> +  * The cpuidle framework says to not stop tick but
> +  * the tick has been stopped yet, so restart it.
> +  */
> + if (tick_nohz_tick_stopped())
> + tick_nohz_idle_restart_tick();
> +

I suspect you want an 'else' here. restart_tick already calls
timer_clear_idle().

>   tick_nohz_idle_retain_tick();
> + }
>  

However, I would rather we stuff all this into retain_tick.

Re: [PATCH v2 3/4] ARM64: dts: meson-gx: add dmcbus and canvas nodes.

[Neil Armstrong]

On 08/08/2018 10:41, Jerome Brunet wrote:
> On Wed, 2018-08-08 at 00:00 +0200, Maxime Jourdan wrote:
>> Wrap the canvas node in a syscon node.
>>
>> Signed-off-by: Maxime Jourdan 
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 17 +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> index b8dc4dbb391b..c98198662ae2 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -423,6 +423,23 @@
>>  };
>>  };
>>  
>> +dmcbus: bus@c8838000 {
>> +compatible = "simple-bus";
>> +reg = <0x0 0xc8838000 0x0 0x1000>;
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +ranges = <0x0 0x0 0x0 0xc8838000 0x0 0x1000>;
>> +
>> +sysctrl_DMC: system-controller@0 {
>> +compatible = "amlogic,gx-dmc-sysctrl", 
>> "syscon", "simple-mfd";
>> +reg = <0x0 0x0 0x0 0x1000>;
>> +
>> +canvas: canvas-provider@0 {
>> +compatible = "amlogic,canvas";
> 
> If there is only one canvas provider under "sysctrl_DMC" and it has no reg
> property , you should not put a unit-address (@0) here. (same for the
> documentation patch)
> 
> You may have seen unit-address without a reg property used elsewhere (ASoC
> simple-card, my recent axg-sound-card), when there is multiple node with the
> same node-name (ex: dai-link).
> 
> As Martin pointed out, the DT spec says we should not use unit-address unless
> there is a reg property. We did not get Rob's view on this and we might have 
> to
> update this later on. In your case, unless I missed something, you should
> definitely not have it
> 
> nitpick regarding the node-name (canvas-provider). If appropriate, we should 
> try
> to stick to one of the generic names proposed in the spec. I wonder if the
> canvas provider could be viewed as a "memory" or "memory-controller"

It's not really a memory or memory-controller, it's a Lookup Table on top of 
the memory controller,
nothing really matches here...

> 
> So, what about this ? Just a proposition, feel free to comment ;)
> 
>   sysctrl_DMC: system-controller@0 {  
> compatib
> le = "amlogic,gx-dmc-sysctrl", "syscon", "simple-mfd";>   reg =
> <0x0 0x0 0x0 0x1000>;
>   
>   canvas: memory-controller {
>   compatible = "amlogic,canvas";
>   }
> 
> [...]
> 
> 
>> +};
>> +};
>> +};
>> +
>>  hiubus: bus@c883c000 {
>>  compatible = "simple-bus";
>>  reg = <0x0 0xc883c000 0x0 0x2000>;
> 
> 

Re: [RFC PATCH 2/3] mm/memory_hotplug: Create __shrink_pages and move it to offline_pages

[Oscar Salvador]

On Thu, Aug 09, 2018 at 09:50:55AM +0200, Oscar Salvador wrote:
> On Wed, Aug 08, 2018 at 11:29:08PM +0200, Oscar Salvador wrote:
> > On Wed, Aug 08, 2018 at 01:55:59PM -0400, Jerome Glisse wrote:
> > > Note that Dan did post patches that already go in that direction (unifying
> > > code between devm and HMM). I think they are in Andrew queue, looks for
> > > 
> > > mm: Rework hmm to use devm_memremap_pages and other fixes
> > 
> > Thanks for pointing that out.
> > I will take a look at that work.
> 
> Ok, I checked the patchset [1] and I think it is nice that those two (devm 
> and HMM)
> get unified.
> I think it will make things easier when we have to change things for the 
> memory-hotplug.
> Actually, I think that after [2], all hot-adding memory will be handled in 
> devm_memremap_pages.

Forgot to include the links:

[1] https://lkml.org/lkml/2018/6/19/108
[2] https://lkml.org/lkml/2018/6/19/110

-- 
Oscar Salvador
SUSE L3

Re: [PATCH v6 5/5] Auto-detect whether a FPU exists

[Christoph Hellwig]

On Thu, Aug 09, 2018 at 03:44:40PM +0800, Alan Kao wrote:
> We expect that a kernel with CONFIG_FPU=y can still support no-FPU
> machines. To do so, the kernel should first examine the existence of a
> FPU, then do nothing if a FPU does exist; otherwise, it should
> disable/bypass all FPU-related functions.
> 
> In this patch, a new global variable, has_fpu, is created and determined
> when parsing the hardware capability from device tree during booting.
> This variable is used in those FPU-related functions.
> 
> Signed-off-by: Alan Kao 
> Cc: Greentime Hu 
> Cc: Vincent Chen 
> Cc: Zong Li 
> Cc: Nick Hu 

Looks good,

Reviewed-by: Christoph Hellwig 

Re: [RFC][PATCH 00/24] tools lib traceevent: Rename pevent to tep for preparation for library

[Jiri Olsa]

On Wed, Aug 08, 2018 at 11:55:48AM -0400, Steven Rostedt wrote:
> Having libtraceevent turn into a proper library has long been asked for.
> I never had time to do it before. Luckily, Tzvetomir was able to spend
> the time to start the preparation. The first thing that needs to be done
> is to handle namespace collisions. "pevent" was the prefix I chose, but
> many people were displeased by it, as it didn't express what the functions
> were used for. After discussing with many people at many conferences
> I've come up with "tep", which means "Trace Event Parser". Please don't
> question this. The bikeshed has been painted and I'm not changing the
> color.

nah... now when I see it 'te' actualy sounds better ; just kidding,
great we finaly got to this.. is there a branch somewhere with this?

thanks,
jirka

Re: [PATCH v8 19/22] KVM: s390: Clear Crypto Control Block when using vSIE

[David Hildenbrand]

On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Pierre Morel 
> 
> When we clear the Crypto Control Block (CRYCB) used by a guest
> level 2, the vSIE shadow CRYCB for guest level 3 must be updated
> before the guest uses it.
> 
> We achieve this by using the KVM_REQ_VSIE_RESTART synchronous
> request for each vCPU belonging to the guest to force the reload
> of the shadow CRYCB before rerunning the guest level 3.
> 
> Signed-off-by: Pierre Morel 
> ---
>  arch/s390/kvm/kvm-s390.c |7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 0d03249..9203f0b 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -1921,6 +1921,9 @@ static void kvm_s390_set_crycb_format(struct kvm *kvm)
>  
>  void kvm_arch_crypto_clear_masks(struct kvm *kvm)
>  {
> + int i;
> + struct kvm_vcpu *vcpu;
> +
>   mutex_lock(>lock);
>   kvm_s390_vcpu_block_all(kvm);
>  
> @@ -1929,6 +1932,10 @@ void kvm_arch_crypto_clear_masks(struct kvm *kvm)
>   memset(>arch.crypto.crycb->apcb1, 0,
>  sizeof(kvm->arch.crypto.crycb->apcb1));
>  
> + /* recreate the shadow crycb for each vcpu */
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + kvm_s390_sync_request(KVM_REQ_VSIE_RESTART, vcpu);

We have kvm_s390_sync_request_broadcast(), which should boil down to a
one-liner

> +
>   kvm_s390_vcpu_unblock_all(kvm);
>   mutex_unlock(>lock);
>  }
> 


-- 

Thanks,

David / dhildenb

Re: [PATCH] arm64: PCI: Remove node-local allocations when initialising host controller

[Punit Agrawal]

Bjorn Helgaas  writes:

> On Wed, Aug 08, 2018 at 03:44:03PM +0100, Punit Agrawal wrote:
>> Bjorn Helgaas  writes:
>> > On Thu, Aug 2, 2018 at 9:33 AM Lorenzo Pieralisi
>> >  wrote:
>> >> On Wed, Aug 01, 2018 at 02:38:51PM -0500, Jeremy Linton wrote:
>> >>
>> >> Jiang Liu does not work on the kernel anymore so we won't know
>> >> anytime soon the reasoning behind commit 965cd0e4a5e5
>> >>
>> >> > On 08/01/2018 12:31 PM, Punit Agrawal wrote:
>> >> > >Memory for host controller data structures is allocated local to the
>> >> > >node to which the controller is associated with. This has been the
>> >> > >behaviour since support for ACPI was added in
>> >> > >commit 0cb0786bac15 ("ARM64: PCI: Support ACPI-based PCI host 
>> >> > >controller").
>> >> >
>> >> > Which was apparently influenced by:
>> >> >
>> >> > 965cd0e4a5e5 x86, PCI, ACPI: Use kmalloc_node() to optimize for 
>> >> > performance
>> >> >
>> >> > Was there an actual use-case behind that change?
>> >> >
>> >> > I think this fixes the immediate boot problem, but if there is any
>> >> > perf advantage it seems wise to keep it... Particularly since x86
>> >> > seems to be doing the node sanitation in pci_acpi_root_get_node().
>> >>
>> >> I am struggling to see the perf advantage of allocating a struct
>> >> that the PCI controller will never read/write from a NUMA node that
>> >> is local to the PCI controller, happy to be corrected if there is
>> >> a sound rationale behind that.
>> >
>> > If there is no reason to use kzalloc_node() here, we shouldn't use it.
>> >
>> > But we should use it (or not use it) consistently across arches.  I do
>> > not believe there is an arch-specific reason to be different.
>> > Currently, pci_acpi_scan_root() uses kzalloc_node() on x86 and arm64,
>> > but kzalloc() on ia64.  They all ought to be the same.
>> 
>> From my understanding, arm64 use of kzalloc_node() was derived from the
>> x86 version. Maybe somebody familiar with behaviour on x86 can provide
>> input here.
>
> If you want to remove use of kzalloc_node(), I'm fine with that as
> long as you do it for x86 at the same time (maybe separate patches,
> but at least in the same series).
>
> I don't see any evidence in 965cd0e4a5e5 ("x86, PCI, ACPI: Use
> kmalloc_node() to optimize for performance") that it actually improves
> performance, so I'd be inclined to just use kzalloc().

Thanks for confirming.

I'm happy to add a patch updating x86 use of kzalloc_node() as
well. I'll post something once the merge window closes.

>
> Bjorn

Re: [PATCH v8 21/22] KVM: s390: CPU model support for AP virtualization

[Harald Freudenberger]

On 09.08.2018 10:17, David Hildenbrand wrote:
> On 08.08.2018 16:44, Tony Krowiak wrote:
>> From: Tony Krowiak 
>>
>> Introduces a new CPU model feature and two CPU model
>> facilities to support AP virtualization for KVM guests.
>>
>> CPU model feature:
>>
>> The KVM_S390_VM_CPU_FEAT_AP feature indicates that
>> AP instructions are available on the guest. This
>> feature will be enabled by the kernel only if the AP
>> instructions are installed on the linux host. This feature
>> must be specifically turned on for the KVM guest from
>> userspace to use the VFIO AP device driver for guest
>> access to AP devices.
>>
>> CPU model facilities:
>>
>> 1. AP Query Configuration Information (QCI) facility is installed.
>>
>>This is indicated by setting facilities bit 12 for
>>the guest. The kernel will not enable this facility
>>for the guest if it is not set on the host. This facility
>>must not be set by userspace if the KVM_S390_VM_CPU_FEAT_AP
>>feature is not installed.
> Could it happen on real HW (not frankenstein CPU models), that
>
> !AP, but STFL 12 or 15  are indicated?
What is your expectation here ? There are no AP instructions
available but if there would be AP instructions available then
there would be the QCI and or the T bit facility within
the PQAP AP instruction valid ?
>>If this facility is not set for the KVM guest, then only
>>APQNs with an APQI less than 16 will be used by a Linux
>>guest regardless of the matrix configuration for the virtual
>>machine. This is a limitation of the Linux AP bus.
>>
>> 2. AP Facilities Test facility (APFT) is installed.
>>
>>This is indicated by setting facilities bit 15 for
>>the guest. The kernel will not enable this facility for
>>the guest if it is not set on the host. This facility
>>must not be set by userspace if the KVM_S390_VM_CPU_FEAT_AP
>>feature is not installed.
>>
>>If this facility is not set for the KVM guest, then no
>>AP devices will be available to the guest regardless of
>>the guest's matrix configuration for the virtual
>>machine. This is a limitation of the Linux AP bus.
>>
>> Signed-off-by: Tony Krowiak 
>> Reviewed-by: Christian Borntraeger 
>> Reviewed-by: Halil Pasic 
>> Tested-by: Michael Mueller 
>> Tested-by: Farhan Ali 
>> Signed-off-by: Christian Borntraeger 
>> ---
>>  arch/s390/kvm/kvm-s390.c |7 +++
>>  arch/s390/tools/gen_facilities.c |2 ++
>>  2 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index 9203f0b..7d4fe9b 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -367,6 +367,13 @@ static void kvm_s390_cpu_feat_init(void)
>>  
>>  if (MACHINE_HAS_ESOP)
>>  allow_cpu_feat(KVM_S390_VM_CPU_FEAT_ESOP);
>> +
>> +/*
>> + * Check if AP instructions installed on host
>> + */
> Make this a one-line comment, please.
>
>> +if (ap_instructions_available() == 0)
>> +allow_cpu_feat(KVM_S390_VM_CPU_FEAT_AP);
>> +
>>  /*
>>   * We need SIE support, ESOP (PROT_READ protection for gmap_shadow),
>>   * 64bit SCAO (SCA passthrough) and IDTE (for gmap_shadow unshadowing).
>> diff --git a/arch/s390/tools/gen_facilities.c 
>> b/arch/s390/tools/gen_facilities.c
>> index 90a8c9e..a52290b 100644
>> --- a/arch/s390/tools/gen_facilities.c
>> +++ b/arch/s390/tools/gen_facilities.c
>> @@ -106,6 +106,8 @@ struct facility_def {
>>  
>>  .name = "FACILITIES_KVM_CPUMODEL",
>>  .bits = (int[]){
>> +12, /* AP Query Configuration Information */
>> +15, /* AP Facilities Test */
>>  -1  /* END */
>>  }
>>  },
>>
>

[PATCH] scripts/gcc-goto.sh: Show stdout and stderr for potential errors

[zhe.he]

From: He Zhe 

The check may fail not only because ${CC} does not support the asm
feature, but also due to potential defects of ${CC} itself like what
we experienced below or even it's missing.

Assembler messages:
Fatal error: The input and output files must be distinct
(introduced by binutils-2.31 "Stop the assembler from overwriting its
output file.")

This patch enables stdout and stderr to give user direct error
information for those cases, while not polluting the output for normal
cases.

Signed-off-by: He Zhe 
---
 scripts/gcc-goto.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
index 083c526..bd7fc8eb 100755
--- a/scripts/gcc-goto.sh
+++ b/scripts/gcc-goto.sh
@@ -3,7 +3,7 @@
 # Test for gcc 'asm goto' support
 # Copyright (C) 2010, Jason Baron 
 
-cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
+cat << "END" | $@ -x c - -c -o /dev/null && echo "y"
 int main(void)
 {
 #if defined(__arm__) || defined(__aarch64__)
-- 
2.7.4

Re: [PATCH v2 2/3] i2c: Add helper to ease DMA handling

[Yingjoe Chen]

On Wed, 2018-08-08 at 22:57 +0200, Wolfram Sang wrote:
> On Sat, Jul 07, 2018 at 05:29:54PM +0800, Jun Gao wrote:
> > From: Jun Gao 
> > 
> > This function is needed by i2c_get_dma_safe_msg_buf() potentially.
> > It is used to free DMA safe buffer when DMA operation fails.
> > 
> > Signed-off-by: Jun Gao 
> 
> Right, we need something like this. This leaks in the sh_mobile driver,
> too :(
> 
> I am still thinking if there is a nice way to put this functionality
> into i2c_release_dma_safe_msg_buf() itself somehow...

Wolfram,

I have second thought on these API now. Recently, we have saw similar
issue for spi device driver.

I believe the reason for these api is because some arch changed to can
not do DMA on stack recently. Maybe we should have dma_mapping to bounce
buffer like it bounce un-dma-able address for those arch? or we should
have a common driver API for this, not just for i2c?

Joe.C

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

[Harald Freudenberger]

On 09.08.2018 11:06, Cornelia Huck wrote:
> On Wed,  8 Aug 2018 10:44:14 -0400
> Tony Krowiak  wrote:
>
>> From: Harald Freudenberger 
>>
>> Move all the inline functions from the ap bus header
>> file ap_asm.h into the in-kernel api header file
>> arch/s390/include/asm/ap.h so that KVM can make use
>> of all the low level AP functions.
>>
>> Signed-off-by: Harald Freudenberger 
>> Signed-off-by: Christian Borntraeger 
> You should add your own s-o-b if you are sending on patches written by
> others (even if it does not matter in the end, when they are merged
> through a different path anyway.)
>
>> ---
>>  arch/s390/include/asm/ap.h |  284 
>> 
>>  drivers/s390/crypto/ap_asm.h   |  261 
>>  drivers/s390/crypto/ap_bus.c   |   21 +---
>>  drivers/s390/crypto/ap_bus.h   |1 +
>>  drivers/s390/crypto/ap_card.c  |1 -
>>  drivers/s390/crypto/ap_queue.c |1 -
>>  6 files changed, 259 insertions(+), 310 deletions(-)
>>  delete mode 100644 drivers/s390/crypto/ap_asm.h
>>
>> diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
>> index c1bedb4..046e044 100644
>> --- a/arch/s390/include/asm/ap.h
>> +++ b/arch/s390/include/asm/ap.h
>> @@ -47,6 +47,50 @@ struct ap_queue_status {
>>  };
>>  
>>  /**
>> + * ap_intructions_available() - Test if AP instructions are available.
>> + *
>> + * Returns 0 if the AP instructions are installed.
> Stumbled over this when I was looking at the usage in patch 7: if I see
> a function called '_available' return 0, I'd assume that whatever the
> function tests for is *not* available.
>
> Rather call this function ap_instructions_check_availability() (and
> keep the return code convention), or switch this to return 0 if not
> available and !0 if available?
Good catch, Cony you are right. I'll fix this to return 1 if AP instructions
are available and 0 if not. However, this patch will come via Martin's pipe
to the Linus Torwald kernel sources.
>
>> + */
>> +static inline int ap_instructions_available(void)
>> +{
>> +register unsigned long reg0 asm ("0") = AP_MKQID(0, 0);
>> +register unsigned long reg1 asm ("1") = -ENODEV;
>> +register unsigned long reg2 asm ("2");
>> +
>> +asm volatile(
>> +"   .long 0xb2af\n" /* PQAP(TAPQ) */
>> +"0: la%0,0\n"
>> +"1:\n"
>> +EX_TABLE(0b, 1b)
>> +: "+d" (reg1), "=d" (reg2)
>> +: "d" (reg0)
>> +: "cc");
>> +return reg1;
>> +}
> --
> To unsubscribe from this list: send the line "unsubscribe linux-s390" 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 2/3] i2c: Add helper to ease DMA handling

[Wolfram Sang]

Hi,

> I believe the reason for these api is because some arch changed to can
> not do DMA on stack recently. Maybe we should have dma_mapping to bounce

It is not only arch dependent. You can enable virtual stacks in Kconfig,
too.

> buffer like it bounce un-dma-able address for those arch? or we should
> have a common driver API for this, not just for i2c?

I gave a talk about this problem recently and everyone in the room
agreed the best thing would be to have annotated buffers which can be
used kernel-wide. Someone mentioned DMABUF could be a candidate, but I
haven't looked further into that.

So, yes, a bigger solution is needed but I don't see that coming soon,
so I implemented the I2C part for better safety now. I'd be happy to
remove all that again once we have the annotated buffers. But it is an
effort...

Regards,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping

[Juri Lelli]

On 09/08/18 10:14, Patrick Bellasi wrote:
> On 07-Aug 14:35, Juri Lelli wrote:
> > On 06/08/18 17:39, Patrick Bellasi wrote:
> > 
> > [...]
> > 
> > > @@ -4218,6 +4245,13 @@ static int __sched_setscheduler(struct task_struct 
> > > *p,
> > >   return retval;
> > >   }
> > >  
> > > + /* Configure utilization clamps for the task */
> > > + if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP) {
> > > + retval = __setscheduler_uclamp(p, attr);
> > > + if (retval)
> > > + return retval;
> > > + }
> > > +
> > 
> > IIUC, this is available to root and non-root users. In the latter case,
> > how do we cope with the fact that some user might occupy all the
> > available clamping groups configured for the system?
> 
> That's a very good point, glad you noticed it.
> 
> What concern me most is that we set constraints to the cgroups
> delegation model. If all clamp groups have been used it could be
> not possible for a parent group to shrink resources for its subgroups.

Right, when groups are in use the problem might actually be even more
serious.

> In both cases however, in principle, I think we can live with the idea
> that the "System Management Software" (SMS) can pre-allocate all the
> required boost groups at boot time;  malicious tasks and dependent
> groups will eventually get an -ENOSPC error.
> 
> These are the main reason why I did not posted a more "safe" solution:
> this series is already big enough, a properly (pre)configured system
> is still reasonably functional safe and  this feature can be added in
> a second step.

I see, but I also fear that there will be times and usages of this new
interface where no SMS is present.

> However, I already have a couple of possible extensions/fixes which I
> can add on top on the next respin. They are along these lines:

These are exactly what I was thinking about as well. :-)

> 1) make CAP_SYS_NICE protected the clamp groups, with an optional boot
>time parameter to relax this check

It seems to me that this might work well with that the intended usage of
the interface that you depict above. SMS only (or any privileged user)
will be in control of how groups are configured, so no problem for
normal users.

> 2) add discretization support to clamp groups allocation

And this might also work well if we feel that we don't want to restrict
usage of the interface to admin only, however...

> This second feature specifically, will ensure that clamp values are
> always mapped into one of the available clamp groups. While the exact
> clamp value can always be used for tasks placement biasing, when it
> comes to frequency selection biasing, depending on concurrently
> running tasks, you can end up with an effective clamp value which is a
> rounded up.

what I'm not so sure about is that we might lose in flexibility if the
number of available discrete clamp groups is too small compared to the
number of available OPP on the platform.

> Will likely add a couple of additional patches on v4 posting.
> Do you have any other possible idea?

As said, I though as well about the two options you mentioned.

Re: [PATCH RFC 01/10] rcu: Make CONFIG_SRCU unconditionally enabled

[Kirill Tkhai]

On 09.08.2018 00:31, Dave Chinner wrote:
> On Wed, Aug 08, 2018 at 12:27:34PM +0200, Michal Hocko wrote:
>> [CC Josh - the whole series is
>> http://lkml.kernel.org/r/153365347929.19074.12509495712735843805.stgit@localhost.localdomain]
>>
>> On Wed 08-08-18 13:17:44, Kirill Tkhai wrote:
>>> On 08.08.2018 10:20, Michal Hocko wrote:
 On Tue 07-08-18 18:37:36, Kirill Tkhai wrote:
> This patch kills all CONFIG_SRCU defines and
> the code under !CONFIG_SRCU.

 The last time somebody tried to do this there was a pushback due to
 kernel tinyfication. So this should really give some numbers about the
 code size increase. Also why can't we make this depend on MMU. Is
 anybody else than the reclaim asking for unconditional SRCU usage?
>>>
>>> I don't know one. The size numbers (sparc64) are:
>>>
>>> $ size image.srcu.disabled 
>>>textdata bss dec hex filename
>>> 5117546 8030506 1968104 15116156 e6a77c image.srcu.disabled
>>> $ size image.srcu.enabled
>>>textdata bss dec hex filename
>>> 5126175 8064346 1968104 15158625 e74d61 image.srcu.enabled
>>> The difference is: 15158625-15116156 = 42469 ~41Kb
>>>
>>> Please, see the measurement details to my answer to Stephen.
>>>
 Btw. I totaly agree with Steven. This is a very poor changelog. It is
 trivial to see what the patch does but it is far from clear why it is
 doing that and why we cannot go other ways.
>>> We possibly can go another way, and there is comment to [2/10] about this.
>>> Percpu rwsem may be used instead, the only thing, it is worse, is it will
>>> make shrink_slab() wait unregistering shrinkers, while srcu-based
>>> implementation does not require this.
>>
>> Well, if unregisterring doesn't do anything subtle - e.g. an allocation
>> or take locks which depend on allocation - and we can guarantee that
>> then blocking shrink_slab shouldn't be a big deal.
> 
> unregister_shrinker() already blocks shrink_slab - taking a rwsem in
> write mode blocks all readers - so using a per-cpu rwsem doesn't
> introduce anything new or unexpected. I'd like to see numbers of the
> different methods before anything else.

The difference is percpu_rw_semaphore makes readers to wait till RCU
grace period is finished. Sometimes this takes unpredictable time on
big machines with many CPUs, which is not good.
 
> IMO, the big deal is that the split unregister mechanism seems to
> imply superblock shrinkers can be called during sb teardown or
> /after/ the filesystem has been torn down in memory (i.e. after
> ->put_super() is called). That's a change of behaviour, but it's
> left to the filesystem to detect and handle that condition. That's
> exceedingly subtle and looks like a recipe for disaster to me. I
> note that XFS hasn't been updated to detect and avoid this landmine.
> 
> And, FWIW, filesystems with multiple shrinkers (e.g. XFS as 3 per
> mount) will take the SCRU penalty multiple times during unmount, and
> potentially be exposed to multiple different "use during/after
> teardown" race conditions.
> 
>> It is subtle though.
>> Maybe subtle enough to make unconditional SRCU worth it. This all should
>> be in the changelog though.
> 
> IMO, we've had enough recent bugs to deal with from shrinkers being
> called before the filesystem is set up and from trying to handle
> allocation errors during setup. Do we really want to make shrinker
> shutdown just as prone to mismanagement and subtle, hard to hit
> bugs? I don't think we do - unmount is simply not a critical
> performance path.

There are possible different situations, people use linux like they want.
Imagine, you want to reboot NFS server, but you want to enter clients
and umount them over ssh, and the time is critical. Something like this.
I believe there are many examples, people need this.

[PATCH v4 2/2] phy: Add driver for Cadence MHDP DisplayPort SD0801 PHY

[Scott Telford]

Add driver for the Cadence SD0801 "Torrent" PHY used with the Cadence MHDP
DisplayPort Tx controller.

Integration with the MHDP driver will be the subject of another commit.

Signed-off-by: Scott Telford 
---
 drivers/phy/Kconfig  |   1 +
 drivers/phy/Makefile |   1 +
 drivers/phy/cadence/Kconfig  |  10 +
 drivers/phy/cadence/Makefile |   1 +
 drivers/phy/cadence/phy-cadence-dp.c | 541 +++
 5 files changed, 554 insertions(+)
 create mode 100644 drivers/phy/cadence/Kconfig
 create mode 100644 drivers/phy/cadence/Makefile
 create mode 100644 drivers/phy/cadence/phy-cadence-dp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5c8d452..cc47f85 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -43,6 +43,7 @@ config PHY_XGENE
 source "drivers/phy/allwinner/Kconfig"
 source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/broadcom/Kconfig"
+source "drivers/phy/cadence/Kconfig"
 source "drivers/phy/hisilicon/Kconfig"
 source "drivers/phy/lantiq/Kconfig"
 source "drivers/phy/marvell/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 84e3bd9..ba48acd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_RENESAS)+= renesas/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
 obj-y  += broadcom/\
+  cadence/ \
   hisilicon/   \
   marvell/ \
   motorola/\
diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
new file mode 100644
index 000..57fff7d
--- /dev/null
+++ b/drivers/phy/cadence/Kconfig
@@ -0,0 +1,10 @@
+#
+# Phy driver for Cadence MHDP DisplayPort controller
+#
+config PHY_CADENCE_DP
+   tristate "Cadence MHDP DisplayPort PHY driver"
+   depends on OF
+   depends on HAS_IOMEM
+   select GENERIC_PHY
+   help
+ Support for Cadence MHDP DisplayPort PHY.
diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
new file mode 100644
index 000..e5b0a11
--- /dev/null
+++ b/drivers/phy/cadence/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PHY_CADENCE_DP)   += phy-cadence-dp.o
diff --git a/drivers/phy/cadence/phy-cadence-dp.c 
b/drivers/phy/cadence/phy-cadence-dp.c
new file mode 100644
index 000..bc10cb2
--- /dev/null
+++ b/drivers/phy/cadence/phy-cadence-dp.c
@@ -0,0 +1,541 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence MHDP DisplayPort SD0801 PHY driver.
+ *
+ * Copyright 2018 Cadence Design Systems, Inc.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_NUM_LANES  2
+#define MAX_NUM_LANES  4
+#define DEFAULT_MAX_BIT_RATE   8100 /* in Mbps */
+
+#define POLL_TIMEOUT_US2000
+#define LANE_MASK  0x7
+
+/*
+ * register offsets from DPTX PHY register block base (i.e MHDP
+ * register base + 0x30a00)
+ */
+#define PHY_AUX_CONFIG 0x00
+#define PHY_AUX_CTRL   0x04
+#define PHY_RESET  0x20
+#define PHY_PMA_XCVR_PLLCLK_EN 0x24
+#define PHY_PMA_XCVR_PLLCLK_EN_ACK 0x28
+#define PHY_PMA_XCVR_POWER_STATE_REQ   0x2c
+#define PHY_POWER_STATE_LN_0   0x
+#define PHY_POWER_STATE_LN_1   0x0008
+#define PHY_POWER_STATE_LN_2   0x0010
+#define PHY_POWER_STATE_LN_3   0x0018
+#define PHY_PMA_XCVR_POWER_STATE_ACK   0x30
+#define PHY_PMA_CMN_READY  0x34
+#define PHY_PMA_XCVR_TX_VMARGIN0x38
+#define PHY_PMA_XCVR_TX_DEEMPH 0x3c
+
+/*
+ * register offsets from SD0801 PHY register block base (i.e MHDP
+ * register base + 0x50)
+ */
+#define CMN_SSM_BANDGAP_TMR0x00084
+#define CMN_SSM_BIAS_TMR   0x00088
+#define CMN_PLLSM0_PLLPRE_TMR  0x000a8
+#define CMN_PLLSM0_PLLLOCK_TMR 0x000b0
+#define CMN_PLLSM1_PLLPRE_TMR  0x000c8
+#define CMN_PLLSM1_PLLLOCK_TMR 0x000d0
+#define CMN_BGCAL_INIT_TMR 0x00190
+#define CMN_BGCAL_ITER_TMR 0x00194
+#define CMN_IBCAL_INIT_TMR 0x001d0
+#define CMN_PLL0_VCOCAL_INIT_TMR   0x00210
+#define CMN_PLL0_VCOCAL_ITER_TMR   0x00214
+#define CMN_PLL0_VCOCAL_REFTIM_START   0x00218
+#define CMN_PLL0_VCOCAL_PLLCNT_START   0x00220
+#define CMN_PLL0_INTDIV_M0 0x00240
+#define CMN_PLL0_FRACDIVL_M0   0x00244
+#define CMN_PLL0_FRACDIVH_M0   0x00248
+#define CMN_PLL0_HIGH_THR_M0   0x0024c
+#define CMN_PLL0_DSM_DIAG_M0   0x00250
+#define CMN_PLL0_LOCK_PLLCNT_START 0x00278
+#define CMN_PLL1_VCOCAL_INIT_TMR   0x00310
+#define CMN_PLL1_VCOCAL_ITER_TMR   0x00314
+#define CMN_PLL1_DSM_DIAG_M0   0x00350
+#define 

[PATCH] staging: gasket: apex: remove unused array cm_mappable_regions

[Colin King]

From: Colin Ian King 

Array cm_mappable_regions is defined but is never used hence it is
redundant and can be removed.

Cleans up clang warning:
warning: 'cm_mappable_regions' defined but not used [-Wunused-const-variable=]

Signed-off-by: Colin Ian King 
---
 drivers/staging/gasket/apex_driver.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/gasket/apex_driver.c 
b/drivers/staging/gasket/apex_driver.c
index c747e9ca4518..6dca3b177863 100644
--- a/drivers/staging/gasket/apex_driver.c
+++ b/drivers/staging/gasket/apex_driver.c
@@ -138,9 +138,6 @@ static const struct gasket_mappable_region 
mappable_regions[NUM_REGIONS] = {
{ 0x48000, 0x1000 },
 };
 
-static const struct gasket_mappable_region cm_mappable_regions[1] = { { 0x0,
-   APEX_CH_MEM_BYTES } };
-
 /* Gasket device interrupts enums must be dense (i.e., no empty slots). */
 enum apex_interrupt {
APEX_INTERRUPT_INSTR_QUEUE = 0,
-- 
2.17.1

Re: [PATCH RFC 01/10] rcu: Make CONFIG_SRCU unconditionally enabled

[Greg KH]

On Wed, Aug 08, 2018 at 05:07:08PM -0700, Matthew Wilcox wrote:
> On Thu, Aug 09, 2018 at 07:31:25AM +1000, Dave Chinner wrote:
> > IMO, we've had enough recent bugs to deal with from shrinkers being
> > called before the filesystem is set up and from trying to handle
> > allocation errors during setup. Do we really want to make shrinker
> > shutdown just as prone to mismanagement and subtle, hard to hit
> > bugs? I don't think we do - unmount is simply not a critical
> > performance path.
> 
> It's never been performance critical for me, but I'm not so sure that
> there aren't container workloads which unmount filesystems multiple
> times per second.

What?  Why would they do that?  Who cares about tear-down speeds?  Start
up speeds I can kind of understand...

[PATCH v6 5/5] Auto-detect whether a FPU exists

[Alan Kao]

We expect that a kernel with CONFIG_FPU=y can still support no-FPU
machines. To do so, the kernel should first examine the existence of a
FPU, then do nothing if a FPU does exist; otherwise, it should
disable/bypass all FPU-related functions.

In this patch, a new global variable, has_fpu, is created and determined
when parsing the hardware capability from device tree during booting.
This variable is used in those FPU-related functions.

Signed-off-by: Alan Kao 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: Zong Li 
Cc: Nick Hu 
---
 arch/riscv/include/asm/switch_to.h | 8 
 arch/riscv/kernel/cpufeature.c | 8 
 arch/riscv/kernel/process.c| 4 +++-
 arch/riscv/kernel/signal.c | 6 --
 4 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/arch/riscv/include/asm/switch_to.h 
b/arch/riscv/include/asm/switch_to.h
index 093050b03543..733559083f24 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -56,13 +56,12 @@ static inline void __switch_to_aux(struct task_struct *prev,
fstate_restore(next, task_pt_regs(next));
 }
 
-#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_INITIAL)
-
+extern bool has_fpu;
 #else
+#define has_fpu false
 #define fstate_save(task, regs) do { } while (0)
 #define fstate_restore(task, regs) do { } while (0)
 #define __switch_to_aux(__prev, __next) do { } while (0)
-#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_OFF)
 #endif
 
 extern struct task_struct *__switch_to(struct task_struct *,
@@ -72,7 +71,8 @@ extern struct task_struct *__switch_to(struct task_struct *,
 do {   \
struct task_struct *__prev = (prev);\
struct task_struct *__next = (next);\
-   __switch_to_aux(__prev, __next);\
+   if (has_fpu)\
+   __switch_to_aux(__prev, __next);\
((last) = __switch_to(__prev, __next)); \
 } while (0)
 
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 17011a870044..46942e635266 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -22,6 +22,9 @@
 #include 
 
 unsigned long elf_hwcap __read_mostly;
+#ifdef CONFIG_FPU
+bool has_fpu __read_mostly;
+#endif
 
 void riscv_fill_hwcap(void)
 {
@@ -58,4 +61,9 @@ void riscv_fill_hwcap(void)
elf_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
 
pr_info("elf_hwcap is 0x%lx", elf_hwcap);
+
+#ifdef CONFIG_FPU
+   if (elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D))
+   has_fpu = true;
+#endif
 }
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 3820d89e2db9..97155aee9e71 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -83,7 +83,9 @@ void show_regs(struct pt_regs *regs)
 void start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
 {
-   regs->sstatus = DEFAULT_SSTATUS;
+   regs->sstatus = SR_SPIE;
+   if (has_fpu)
+   regs->sstatus |= SR_FS_INITIAL;
regs->sepc = pc;
regs->sp = sp;
set_fs(USER_DS);
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 2450b824d799..f9b5e7e352ef 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -98,7 +98,8 @@ static long restore_sigcontext(struct pt_regs *regs,
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_from_user(regs, >sc_regs, sizeof(sc->sc_regs));
/* Restore the floating-point state. */
-   err |= restore_fp_state(regs, >sc_fpregs);
+   if (has_fpu)
+   err |= restore_fp_state(regs, >sc_fpregs);
return err;
 }
 
@@ -150,7 +151,8 @@ static long setup_sigcontext(struct rt_sigframe __user 
*frame,
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_to_user(>sc_regs, regs, sizeof(sc->sc_regs));
/* Save the floating-point state. */
-   err |= save_fp_state(regs, >sc_fpregs);
+   if (has_fpu)
+   err |= save_fp_state(regs, >sc_fpregs);
return err;
 }
 
-- 
2.18.0

[PATCH v4 2/3] dt-bindings: interrupt-controller: SiFive Plaform Level Interrupt Controller

[Christoph Hellwig]

From: Palmer Dabbelt 

Add documentation for the SiFive implementation of the RISC-V Platform
Level Interrupt Controller (PLIC).  The PLIC connects global interrupt
sources to the local interrupt controller on each hart.

Signed-off-by: Palmer Dabbelt 
[hch: various fixes and updates]
Signed-off-by: Christoph Hellwig 
---
 .../interrupt-controller/sifive,plic.txt  | 58 +++
 1 file changed, 58 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/sifive,plic.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic.txt 
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic.txt
new file mode 100644
index ..fe7ccd944c12
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic.txt
@@ -0,0 +1,58 @@
+SiFive Platform-Level Interrupt Controller (PLIC)
+-
+
+SiFive SOCs include an implementation of the Platform-Level Interrupt 
Controller
+(PLIC) high-level specification in the RISC-V Privileged Architecture
+specification.  The PLIC connects all external interrupts in the system to all
+hart contexts in the system, via the external interrupt source in each hart.
+
+A hart context is a privilege mode in a hardware execution thread.  For 
example,
+in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
+privilege modes per hart; machine mode and supervisor mode.
+
+Each interrupt can be enabled on per-context basis.  Any context can claim
+a pending enabled interrupt and then release it once it has been handled.
+
+Each interrupt has a configurable priority.  Higher priority interrupts are
+serviced first.  Each context can specify a priority threshold. Interrupts
+with priority below this threshold will not cause the PLIC to raise its
+interrupt line leading to the context.
+
+While the PLIC supports both edge-triggered and level-triggered interrupts,
+interrupt handlers are oblivious to this distinction and therefore it is not
+specified in the PLIC device-tree binding.
+
+While the RISC-V ISA doesn't specify a memory layout for the PLIC, the
+"sifive,plic" device is a concrete implementation of the PLIC that contains a
+specific memory layout, which is documented in chapter 8 of the SiFive U5
+Coreplex Series Manual .
+
+Required properties:
+- compatible : "sifive,plic" and a string identifying the actual detailed
+  implementation in case that specific bugs need to be worked around.
+- #address-cells : should be <0> or more.
+- #interrupt-cells : should be <1> or more.
+- interrupt-controller : Identifies the node as an interrupt controller.
+- reg : Should contain 1 register range (address and length).
+- interrupts-extended : Specifies which contexts are connected to the PLIC,
+  with "-1" specifying that a context is not present.  Each node pointed
+  to should be a riscv,cpu-intc node, which has a riscv node as parent.
+- riscv,ndev: Specifies how many external interrupts are supported by
+  this controller.
+
+Example:
+
+   plic: interrupt-controller@c00 {
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   compatible = "riscv,plic", "sifive,fu540-c000-plic";
+   interrupt-controller;
+   interrupts-extended = <
+11
+11  9
+11  9
+11  9
+11  9>;
+   reg = <0xc00 0x400>;
+   riscv,ndev = <10>;
+   };
-- 
2.18.0

[PATCH v4 3/3] irqchip: add a SiFive PLIC driver

[Christoph Hellwig]

Add a driver for the SiFive implementation of the RISC-V Platform Level
Interrupt Controller (PLIC).  The PLIC connects global interrupt sources
to the local interrupt controller on each hart.

This driver is based on the driver in the RISC-V tree from Palmer Dabbelt,
but has been almost entirely rewritten since, and includes many fixes
from Atish Patra.

Signed-off-by: Christoph Hellwig 
Acked-by: Thomas Gleixner 
Reviewed-by: Atish Patra 
---
 arch/riscv/configs/defconfig  |   1 +
 drivers/irqchip/Kconfig   |  12 ++
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-sifive-plic.c | 259 ++
 4 files changed, 273 insertions(+)
 create mode 100644 drivers/irqchip/irq-sifive-plic.c

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 07326466871b..36473d7dbaac 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -76,3 +76,4 @@ CONFIG_ROOT_NFS=y
 CONFIG_CRYPTO_USER_API_HASH=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
+CONFIG_SIFIVE_PLIC=y
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e9233db16e03..df345b878ac2 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -372,3 +372,15 @@ config QCOM_PDC
  IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
 
 endmenu
+
+config SIFIVE_PLIC
+   bool "SiFive Platform-Level Interrupt Controller"
+   depends on RISCV
+   help
+  This enables support for the PLIC chip found in SiFive (and
+  potentially other) RISC-V systems.  The PLIC controls devices
+  interrupts and connects them to each core's local interrupt
+  controller.  Aside from timer and software interrupts, all other
+  interrupt sources are subordinate to the PLIC.
+
+  If you don't know what to do here, say Y.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 15f268f646bf..fbd1ec8070ef 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -87,3 +87,4 @@ obj-$(CONFIG_MESON_IRQ_GPIO)  += irq-meson-gpio.o
 obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o
 obj-$(CONFIG_NDS32)+= irq-ativic32.o
 obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
+obj-$(CONFIG_SIFIVE_PLIC)  += irq-sifive-plic.o
diff --git a/drivers/irqchip/irq-sifive-plic.c 
b/drivers/irqchip/irq-sifive-plic.c
new file mode 100644
index ..298685e56676
--- /dev/null
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -0,0 +1,259 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 SiFive
+ * Copyright (C) 2018 Christoph Hellwig
+ */
+#define pr_fmt(fmt) "plic: " fmt
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * This driver implements a version of the RISC-V PLIC with the actual layout
+ * specified in chapter 8 of the SiFive U5 Coreplex Series Manual:
+ *
+ * https://static.dev.sifive.com/U54-MC-RVCoreIP.pdf
+ *
+ * The largest number supported by devices marked as 'riscv,plic0', is 1024, of
+ * which device 0 is defined as non-existent by the RISC-V Privileged Spec.
+ */
+
+#define MAX_DEVICES1024
+#define MAX_CONTEXTS   15872
+
+/*
+ * Each interrupt source has a priority register associated with it.
+ * We always hardwire it to one in Linux.
+ */
+#define PRIORITY_BASE  0
+#define PRIORITY_PER_ID4
+
+/*
+ * Each hart context has a vector of interrupt enable bits associated with it.
+ * There's one bit for each interrupt source.
+ */
+#define ENABLE_BASE0x2000
+#define ENABLE_PER_HART0x80
+
+/*
+ * Each hart context has a set of control registers associated with it.  Right
+ * now there's only two: a source priority threshold over which the hart will
+ * take an interrupt, and a register to claim interrupts.
+ */
+#define CONTEXT_BASE   0x20
+#define CONTEXT_PER_HART   0x1000
+#define CONTEXT_THRESHOLD  0x00
+#define CONTEXT_CLAIM  0x04
+
+static void __iomem *plic_regs;
+
+struct plic_handler {
+   boolpresent;
+   int ctxid;
+};
+static DEFINE_PER_CPU(struct plic_handler, plic_handlers);
+
+static inline void __iomem *plic_hart_offset(int ctxid)
+{
+   return plic_regs + CONTEXT_BASE + ctxid * CONTEXT_PER_HART;
+}
+
+static inline u32 __iomem *plic_enable_base(int ctxid)
+{
+   return plic_regs + ENABLE_BASE + ctxid * ENABLE_PER_HART;
+}
+
+/*
+ * Protect mask operations on the registers given that we can't assume that
+ * atomic memory operations work on them.
+ */
+static DEFINE_RAW_SPINLOCK(plic_toggle_lock);
+
+static inline void plic_toggle(int ctxid, int hwirq, int enable)
+{
+   u32 __iomem *reg = plic_enable_base(ctxid) + (hwirq / 32);
+   u32 hwirq_mask = 1 << (hwirq % 32);
+
+   

simplified RISC-V interrupt and clocksource handling v4

[Christoph Hellwig]

This series tries adds support for interrupt handling and timers
for the RISC-V architecture.

The basic per-hart interrupt handling implemented by the scause
and sie CSRs is extremely simple and implemented directly in
arch/riscv/kernel/irq.c.  In addition there is a irqchip driver
for the PLIC external interrupt controller, which is called through
the set_handle_irq API, and a clocksource driver that gets its
timer interrupt directly from the low-level interrupt handling.

Compared to previous iterations this version does not try to use an
irqchip driver for the low-level interrupt handling.  This saves
a couple indirect calls and an additional read of the scause CSR
in the hot path, makes the code much simpler and last but not least
avoid the dependency on a device tree for a mandatory architectural
feature.

A git tree is available here (contains a few more patches before
the ones in this series).  The series is against the riscv for-next
tree, so using the git tree is advised

git://git.infradead.org/users/hch/riscv.git riscv-irq-simple.4

Gitweb:


http://git.infradead.org/users/hch/riscv.git/shortlog/refs/heads/riscv-irq-simple.4

Changes since v3:
 - more improvements to the DT bindings
 - add back the patch adding the riscv,cpu-intc binding documentation
   as it is referenced from others

Changes since v2:
 - actually use SEIE instead of STIE in the plic driver
 - rename the default compat string for the plic to sifive,u5-plic
 - various spelling fixes
 - drop a superflous derefence in the plic driver that is taken care of
   by the following loop
 - drop the patch to document the enable method - not relevant for the
   rest of the series
 - drop the patches for the per-hart timebase frequency - not relevant
   for the rest of the series.
 - use riscv_of_processor_hart in the timer driver

Changes since v1:
 - rename the plic driver to irq-sifive-plic
 - switch to a default compatible of sifive,plic0 (still supporting the
   riscv,plic0 name for compatibility)
 - add a reference for the SiFive PLIC register layout
 - fix plic_toggle addressing for large numbers of hwirqs
 - remove the call to ack_bad_irq
 - use a raw spinlock for plic_toggle_lock
 - use the irq_desc cpumask in the plic enable/disable methods
 - add back OF contexid parsing in the plic driver
 - don't allow COMPILE_TEST builds of the clocksource driver, as it
   depends on 
 - default the clocksource driver to y
 - clean up naming in the clocksource driver
 - remove the MINDELTA and MAXDELTA #defines
 - various DT binding fixes

[PATCH v4 1/3] dt-bindings: interrupt-controller: RISC-V local interrupt controller

[Christoph Hellwig]

From: Palmer Dabbelt 

Add documentation on the RISC-V local interrupt controller, which is a
per-hart interrupt controller that manages all interrupts entering a
RISC-V hart.  This interrupt controller is present on all RISC-V systems.

Signed-off-by: Palmer Dabbelt 
[hch: minor cleanups]
Signed-off-by: Christoph Hellwig 
---
 .../interrupt-controller/riscv,cpu-intc.txt   | 44 +++
 1 file changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
new file mode 100644
index ..b0a8af51c388
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
@@ -0,0 +1,44 @@
+RISC-V Hart-Level Interrupt Controller (HLIC)
+-
+
+RISC-V cores include Control Status Registers (CSRs) which are local to each
+CPU core (HART in RISC-V terminology) and can be read or written by software.
+Some of these CSRs are used to control local interrupts connected to the core.
+Every interrupt is ultimately routed through a hart's HLIC before it
+interrupts that hart.
+
+The RISC-V supervisor ISA manual specifies three interrupt sources that are
+attached to every HLIC: software interrupts, the timer interrupt, and external
+interrupts.  Software interrupts are used to send IPIs between cores.  The
+timer interrupt comes from an architecturally mandated real-time timer that is
+controller via Supervisor Binary Interface (SBI) calls and CSR reads.  External
+interrupts connect all other device interrupts to the HLIC, which are routed
+via the platform-level interrupt controller (PLIC).
+
+All RISC-V systems that conform to the supervisor ISA specification are
+required to have a HLIC with these three interrupt sources present.  Since the
+interrupt map is defined by the ISA it's not listed in the HLIC's device tree
+entry, though external interrupt controllers (like the PLIC, for example) will
+need to define how their interrupts map to the relevant HLICs.  This means
+a PLIC interrupt property will typically list the HLICs for all present HARTs
+in the system.
+
+Required properties:
+- compatible : "riscv,cpu-intc"
+- #interrupt-cells : should be <1>
+- interrupt-controller : Identifies the node as an interrupt controller
+
+Furthermore, this interrupt-controller MUST be embedded inside the cpu
+definition of the hart whose CSRs control these local interrupts.
+
+An example device tree entry for a HLIC is show below.
+
+   cpu1: cpu@1 {
+   compatible = "riscv";
+   ...
+   cpu1-intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc", 
"sifive,fu540-c000-cpu-intc";
+   interrupt-controller;
+   };
+   };
-- 
2.18.0

linux-next: Tree for Aug 9

[Stephen Rothwell]

Hi all,

Changes since 20180808:

The vfs tree still had its build failure but today I applied a suggested
patch and I have still disabled CONFIG_SAMPLE_STATX.

Non-merge commits (relative to Linus' tree): 11533
 10452 files changed, 491910 insertions(+), 204122 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 286 trees (counting Linus' and 65 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (fedb8da96355 parisc: Define mb() and add memory barriers 
to assembler unlock sequences)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (9d3cce1e8b85 Linux 4.18-rc5)
Merging arc-current/for-curr (7945121f56a2 ARC: [plat-axs*]: Enable SWAP)
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (c7513c2a2714 crypto/arm64: aes-ce-gcm - add 
missing kernel_neon_begin/end pair)
Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs 
for v4.18-rc6)
Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global 
invalidations when removing copro)
Merging sparc/master (c1d61e7fe376 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (b13f9c636437 vhost: reset metadata cache when initializing 
new IOTLB)
Merging bpf/master (bf9bae0ea6ec Merge branch 'sockmap-fixes')
Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for 
new entries)
Merging netfilter/master (16e98cec49a4 ipvs: don't show negative times in 
ip_vs_conn)
Merging ipvs/master (16e98cec49a4 ipvs: don't show negative times in ip_vs_conn)
Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in 
parsing NVRAM for multiple devices)
Merging mac80211/master (e31f6456c01c cfg80211: never ignore user regulatory 
hint)
Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV 
port checks)
Merging sound-current/for-linus (627661ced824 ALSA: dice: fix wrong copy to rx 
parameters for Alesis iO26)
Merging sound-asoc-fixes/for-linus (833504c0a319 Merge branch 'asoc-4.18' into 
asoc-linus)
Merging regmap-fixes/for-linus (d72e90f33aa4 Linux 4.18-rc6)
Merging regulator-fixes/for-linus (685e0249e89c Merge branch 'regulator-4.18' 
into regulator-linus)
Merging spi-fixes/for-linus (a5e97ad82ebf Merge branch 'spi-4.18' into 
spi-linus)
Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race 
condition)
Merging driver-core.current/driver-core-linus (acb1872577b3 Linux 4.18-rc7)
Merging tty.current/tty-linus (021c91791a5e Linux 4.18-rc3)
Merging usb.current/usb-linus (acb1872577b3 Linux 4.18-rc7)
Merging usb-gadget-fixes/fixes (acb1872577b3 Linux 4.18-rc7)
Merging usb-serial-fixes/usb-linus (9d3cce1e8b85 Linux 4.18-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for 
status lines)
Merging staging.current/staging-linus (acb1872577b3 Linux 4.18-rc7)
Merging char-misc.current/char-misc-linus (9d3cce1e8b85 Linux 4.18-rc5)
Merging 

[PATCH v1 1/2] KVM: s390: vsie: simulate VCPU SIE entry/exit

[David Hildenbrand]

VCPU requests and VCPU blocking right now don't take care of the vSIE
(as it was not necessary until now). But we want to have synchronous VCPU
requests that will also be handled before running the vSIE again.

So let's simulate a SIE entry of the VCPU when calling the sie during
vSIE handling and check for PROG_ flags. The existing infrastructure
(e.g. exit_sie()) will then detect that the SIE (in form of the vSIE) is
running and properly kick the vSIE CPU, resulting in it leaving the vSIE
loop and therefore the vSIE interception handler, allowing it to handle
VCPU requests.

E.g. if we want to modify the crycb of the VCPU and make sure that any
masks also get applied to the VSIE crycb shadow (which uses masks from the
VCPU crycb), we will need a way to hinder the vSIE from running and make
sure to process the updated crycb before reentering the vSIE again.

Reviewed-by: Pierre Morel
Reviewed-by: Cornelia Huck 
Reviewed-by: Janosch Frank 
Signed-off-by: David Hildenbrand 
---
 arch/s390/kvm/kvm-s390.c |  9 -
 arch/s390/kvm/kvm-s390.h |  1 +
 arch/s390/kvm/vsie.c | 21 +
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 91ad4a9425c0..c87734a31fdb 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -2766,18 +2766,25 @@ static void kvm_s390_vcpu_request(struct kvm_vcpu *vcpu)
exit_sie(vcpu);
 }
 
+bool kvm_s390_vcpu_sie_inhibited(struct kvm_vcpu *vcpu)
+{
+   return atomic_read(>arch.sie_block->prog20) &
+  (PROG_BLOCK_SIE | PROG_REQUEST);
+}
+
 static void kvm_s390_vcpu_request_handled(struct kvm_vcpu *vcpu)
 {
atomic_andnot(PROG_REQUEST, >arch.sie_block->prog20);
 }
 
 /*
- * Kick a guest cpu out of SIE and wait until SIE is not running.
+ * Kick a guest cpu out of (v)SIE and wait until (v)SIE is not running.
  * If the CPU is not running (e.g. waiting as idle) the function will
  * return immediately. */
 void exit_sie(struct kvm_vcpu *vcpu)
 {
kvm_s390_set_cpuflags(vcpu, CPUSTAT_STOP_INT);
+   kvm_s390_vsie_kick(vcpu);
while (vcpu->arch.sie_block->prog0c & PROG_IN_SIE)
cpu_relax();
 }
diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
index 981e3ba97461..1f6e36cdce0d 100644
--- a/arch/s390/kvm/kvm-s390.h
+++ b/arch/s390/kvm/kvm-s390.h
@@ -290,6 +290,7 @@ void kvm_s390_vcpu_start(struct kvm_vcpu *vcpu);
 void kvm_s390_vcpu_stop(struct kvm_vcpu *vcpu);
 void kvm_s390_vcpu_block(struct kvm_vcpu *vcpu);
 void kvm_s390_vcpu_unblock(struct kvm_vcpu *vcpu);
+bool kvm_s390_vcpu_sie_inhibited(struct kvm_vcpu *vcpu);
 void exit_sie(struct kvm_vcpu *vcpu);
 void kvm_s390_sync_request(int req, struct kvm_vcpu *vcpu);
 int kvm_s390_vcpu_setup_cmma(struct kvm_vcpu *vcpu);
diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
index 63844b95c22c..9175518f79a8 100644
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -829,7 +829,7 @@ static int do_vsie_run(struct kvm_vcpu *vcpu, struct 
vsie_page *vsie_page)
struct kvm_s390_sie_block *scb_s = _page->scb_s;
struct kvm_s390_sie_block *scb_o = vsie_page->scb_o;
int guest_bp_isolation;
-   int rc;
+   int rc = 0;
 
handle_last_fault(vcpu, vsie_page);
 
@@ -857,7 +857,18 @@ static int do_vsie_run(struct kvm_vcpu *vcpu, struct 
vsie_page *vsie_page)
guest_enter_irqoff();
local_irq_enable();
 
-   rc = sie64a(scb_s, vcpu->run->s.regs.gprs);
+   /*
+* Simulate a SIE entry of the VCPU (see sie64a), so VCPU blocking
+* and VCPU requests also hinder the vSIE from running and lead
+* to an immediate exit. kvm_s390_vsie_kick() has to be used to
+* also kick the vSIE.
+*/
+   vcpu->arch.sie_block->prog0c |= PROG_IN_SIE;
+   barrier();
+   if (!kvm_s390_vcpu_sie_inhibited(vcpu))
+   rc = sie64a(scb_s, vcpu->run->s.regs.gprs);
+   barrier();
+   vcpu->arch.sie_block->prog0c &= ~PROG_IN_SIE;
 
local_irq_disable();
guest_exit_irqoff();
@@ -1004,7 +1015,8 @@ static int vsie_run(struct kvm_vcpu *vcpu, struct 
vsie_page *vsie_page)
if (rc == -EAGAIN)
rc = 0;
if (rc || scb_s->icptcode || signal_pending(current) ||
-   kvm_s390_vcpu_has_irq(vcpu, 0))
+   kvm_s390_vcpu_has_irq(vcpu, 0) ||
+   kvm_s390_vcpu_sie_inhibited(vcpu))
break;
}
 
@@ -1121,7 +1133,8 @@ int kvm_s390_handle_vsie(struct kvm_vcpu *vcpu)
if (unlikely(scb_addr & 0x1ffUL))
return kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);
 
-   if (signal_pending(current) || kvm_s390_vcpu_has_irq(vcpu, 0))
+   if (signal_pending(current) || kvm_s390_vcpu_has_irq(vcpu, 0) ||
+   kvm_s390_vcpu_sie_inhibited(vcpu))
return 0;
 
vsie_page = get_vsie_page(vcpu->kvm, scb_addr);
-- 

[PATCH v1 2/2] KVM: s390: introduce and use KVM_REQ_VSIE_RESTART

[David Hildenbrand]

When we change the crycb (or execution controls), we also have to make sure
that the vSIE shadow datastructures properly consider the changed
values before rerunning the vSIE. We can achieve that by simply using a
VCPU request now.

This has to be a synchronous request (== handled before entering the
(v)SIE again).

The request will make sure that the vSIE handler is left, and that the
request will be processed (NOP), therefore forcing a reload of all
vSIE data (including rebuilding the crycb) when re-entering the vSIE
interception handler the next time.

Reviewed-by: Pierre Morel
Reviewed-by: Cornelia Huck 
Reviewed-by: Janosch Frank 
Signed-off-by: David Hildenbrand 
---
 arch/s390/include/asm/kvm_host.h | 1 +
 arch/s390/kvm/kvm-s390.c | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 29c940bf8506..75d39628f21d 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -44,6 +44,7 @@
 #define KVM_REQ_ICPT_OPEREXC   KVM_ARCH_REQ(2)
 #define KVM_REQ_START_MIGRATION KVM_ARCH_REQ(3)
 #define KVM_REQ_STOP_MIGRATION  KVM_ARCH_REQ(4)
+#define KVM_REQ_VSIE_RESTART   KVM_ARCH_REQ(5)
 
 #define SIGP_CTRL_C0x80
 #define SIGP_CTRL_SCN_MASK 0x3f
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index c87734a31fdb..2fdc017d91f0 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -842,8 +842,11 @@ void kvm_s390_vcpu_crypto_reset_all(struct kvm *kvm)
 
kvm_s390_vcpu_block_all(kvm);
 
-   kvm_for_each_vcpu(i, vcpu, kvm)
+   kvm_for_each_vcpu(i, vcpu, kvm) {
kvm_s390_vcpu_crypto_setup(vcpu);
+   /* recreate the shadow crycb by leaving the VSIE handler */
+   kvm_s390_sync_request(KVM_REQ_VSIE_RESTART, vcpu);
+   }
 
kvm_s390_vcpu_unblock_all(kvm);
 }
@@ -3201,6 +3204,8 @@ static int kvm_s390_handle_requests(struct kvm_vcpu *vcpu)
 
/* nothing to do, just clear the request */
kvm_clear_request(KVM_REQ_UNHALT, vcpu);
+   /* we left the vsie handler, nothing to do, just clear the request */
+   kvm_clear_request(KVM_REQ_VSIE_RESTART, vcpu);
 
return 0;
 }
-- 
2.17.1

[PATCH v1 0/2] KVM: s390: vsie: simulate VCPU SIE entry/exit

[David Hildenbrand]

While discussing AP changes, we discovered that we will have to force
a CPU using the vSIE to regenerate/reload shadow data structures. For now,
we have no mechanism for that.

E.g. when clearing AP masks later, we could still have a vSIE CPU making
use of AP adapters as the masks might not be considered yet in the vSIE
data structures. We need a way to block entering the vSIE and regenerate
all shadow data structures once done.

Looks like we can achieve that by simply simulating an ordinary SIE
entry/exit in the VCPU sie control block (when executing sie64 in context
of the vSIE).

This way, we can support blocking and also synchronous CPU requests.

Only compile tested.

RFC -> v1:
- Move entry/exit simulation right to the sie64 code to minimize latency
- Added R-b's, dropped Tested-by.

David Hildenbrand (2):
  KVM: s390: vsie: simulate VCPU SIE entry/exit
  KVM: s390: introduce and use KVM_REQ_VSIE_RESTART

 arch/s390/include/asm/kvm_host.h |  1 +
 arch/s390/kvm/kvm-s390.c | 16 ++--
 arch/s390/kvm/kvm-s390.h |  1 +
 arch/s390/kvm/vsie.c | 21 +
 4 files changed, 33 insertions(+), 6 deletions(-)

-- 
2.17.1

Re: [PATCH v2] perf ordered_events: fix crash in free_dup_event()

[Jiri Olsa]

On Wed, Aug 08, 2018 at 03:33:20PM -0700, Stephane Eranian wrote:
> This patch fixes a bug in ordered_event.c:alloc_event().
> An ordered_event struct was not initialized properly potentially
> causing crashes later on in free_dup_event() depending on the
> content of the memory. If it was NULL, then it would work fine,
> otherwise, it could cause crashes such as:

I'm now little puzzled what do we use this first event for..
I can't see anything special about it, other than it's added
on the list uninitialized ;-)

it seems to work properly when we ditch it.. might be some
prehistoric leftover or I'm terribly missing something

thanks,
jirka


---
diff --cc tools/perf/util/ordered-events.c
index bad9e0296e9a,0e837b0b8582..
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@@ -119,12 -119,8 +119,9 @@@ static struct ordered_event *alloc_even
pr("alloc size %" PRIu64 "B (+%zu), max %" PRIu64 "B\n",
   oe->cur_alloc_size, size, oe->max_alloc_size);
  
 +  oe->cur_alloc_size += size;
-   list_add(>buffer->list, >to_free);
- 
-   /* First entry is abused to maintain the to_free list. */
-   oe->buffer_idx = 2;
-   new = oe->buffer + 1;
+   oe->buffer_idx = 1;
+   new = oe->buffer;
} else {
pr("allocation limit reached %" PRIu64 "B\n", 
oe->max_alloc_size);
}

Re: [PATCH 0/2] fs/lock: show locks info owned by dead/invisible processes

[Konstantin Khorenko]

On 08/09/2018 10:16 AM, Murphy Zhou wrote:

Hi,

Looks like this missed v4.18 ?


Hi Murphy,

yes, Jeff planned to push those patches into 4.19 and they are in "linux-next" 
now,
but not in 4.18 "master" currently.

On 06/14/2018 01:41 PM, Jeff Layton wrote:
> These look fine to me. I'll plan to pick them up for v4.19 unless anyone
> has objections.

linux-next:
1cf8e5de4055 ("fs/lock: show locks taken by processes from another pidns")
826d7bc9f013 ("fs/lock: skip lock owner pid translation in case we are in 
init_pid_ns")

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team


On Fri, Jun 8, 2018 at 10:27 PM, Konstantin Khorenko
 wrote:

The behavior has been changed after 9d5b86ac13c5 ("fs/locks: Remove fl_nspid
and use fs-specific l_pid for remote locks")
and now /proc/$PID/fdinfo/$FD does not show the info about the lock
* if the flock owner process is dead and its pid has been already freed
or
* if the lock owner is not visible in current pidns.

CRIU uses this interface to store locks info during dump and thus can break
on v4.13 and newer.

So let's show info about locks anyway in described cases (like it was before
9d5b86ac13c5), but show pid number saved in file_lock struct if we are in
init_pid_ns (patch 1) or just zero otherwise (patch 2) like we do with SID.

Reproducer:
process A   process A1  process A2
fork()->
exit()  open()
flock()
fork()->
exit()  sleep()

Before the patch:

(root@vz7)/: cat /proc/${PID_A2}/fdinfo/3
pos:4
flags:  0212
mnt_id: 257
lock:   (root@vz7)/:

After the patch:
===
(root@vz7)/:cat /proc/${PID_A2}/fdinfo/3
pos:4
flags:  0212
mnt_id: 295
lock:   1: FLOCK  ADVISORY  WRITE ${PID_A1} b6:f8a61:529946 0 EOF

===
# cat flock1.c

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(void)
{
int fd;
int err;
pid_t child_pid;

child_pid = fork();
if (child_pid == -1)
perror("fork failed");
if (child_pid) {
exit(0);
}

fd = open("/tmp/a", O_CREAT | O_RDWR);
if (fd == -1)
perror("Failed to open the file");

err = flock(fd, LOCK_EX);
if (err == -1)
perror("flock failed");

child_pid = fork();
if (child_pid == -1)
perror("fork failed");
if (child_pid)
exit(0);

sleep(1);

return 0;
}

Konstantin Khorenko (2):
  fs/lock: skip lock owner pid translation in case we are in init_pid_ns
  fs/lock: show locks taken by processes from another pidns

 fs/locks.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

--
2.15.1


.

Re: [PATCH v8 19/22] KVM: s390: Clear Crypto Control Block when using vSIE

[Pierre Morel]

On 09/08/2018 10:10, David Hildenbrand wrote:

On 08.08.2018 16:44, Tony Krowiak wrote:

From: Pierre Morel 

When we clear the Crypto Control Block (CRYCB) used by a guest
level 2, the vSIE shadow CRYCB for guest level 3 must be updated
before the guest uses it.

We achieve this by using the KVM_REQ_VSIE_RESTART synchronous
request for each vCPU belonging to the guest to force the reload
of the shadow CRYCB before rerunning the guest level 3.

Signed-off-by: Pierre Morel 
---
  arch/s390/kvm/kvm-s390.c |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 0d03249..9203f0b 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -1921,6 +1921,9 @@ static void kvm_s390_set_crycb_format(struct kvm *kvm)
  
  void kvm_arch_crypto_clear_masks(struct kvm *kvm)

  {
+   int i;
+   struct kvm_vcpu *vcpu;
+
mutex_lock(>lock);
kvm_s390_vcpu_block_all(kvm);
  
@@ -1929,6 +1932,10 @@ void kvm_arch_crypto_clear_masks(struct kvm *kvm)

memset(>arch.crypto.crycb->apcb1, 0,
   sizeof(kvm->arch.crypto.crycb->apcb1));
  
+	/* recreate the shadow crycb for each vcpu */

+   kvm_for_each_vcpu(i, vcpu, kvm)
+   kvm_s390_sync_request(KVM_REQ_VSIE_RESTART, vcpu);

We have kvm_s390_sync_request_broadcast(), which should boil down to a
one-liner

right, thanks


+
kvm_s390_vcpu_unblock_all(kvm);
mutex_unlock(>lock);
  }





--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany

Re: [PATCH V7 1/2] scsi: ufs: set the device reference clock setting

[Sayali Lokhande]

Hi Evan,

On 8/6/2018 10:56 PM, Evan Green wrote:

Hi Sayali,

On Wed, Aug 1, 2018 at 1:49 AM Sayali Lokhande  wrote:

From: Subhash Jadavani 

UFS host supplies the reference clock to UFS device and UFS device
specification allows host to provide one of the 4 frequencies (19.2 MHz,
26 MHz, 38.4 MHz, 52 MHz) for reference clock. Host should set the
device reference clock frequency setting in the device based on what
frequency it is supplying to UFS device.

Signed-off-by: Subhash Jadavani 
Signed-off-by: Can Guo 
Signed-off-by: Sayali Lokhande 
---
  drivers/scsi/ufs/ufs.h   |  8 
  drivers/scsi/ufs/ufshcd-pltfrm.c |  2 +
  drivers/scsi/ufs/ufshcd.c| 84 
  drivers/scsi/ufs/ufshcd.h|  2 +
  4 files changed, 96 insertions(+)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 14e5bf7..89e0a33 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -378,6 +378,14 @@ enum query_opcode {
 UPIU_QUERY_OPCODE_TOGGLE_FLAG   = 0x8,
  };

+/* bRefClkFreq attribute values */
+enum ref_clk_freq {
+   REF_CLK_FREQ_19_2_MHZ   = 1920,
+   REF_CLK_FREQ_26_MHZ = 2600,
+   REF_CLK_FREQ_38_4_MHZ   = 3840,
+   REF_CLK_FREQ_52_MHZ = 5200,
+};
+
  /* Query response result code */
  enum {
 QUERY_RESULT_SUCCESS= 0x00,
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index e82bde0..0953563 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -343,6 +343,8 @@ int ufshcd_pltfrm_init(struct platform_device *pdev,
 pm_runtime_set_active(>dev);
 pm_runtime_enable(>dev);

+   ufshcd_parse_dev_ref_clk_freq(hba);
+
 ufshcd_init_lanes_per_dir(hba);

 err = ufshcd_init(hba, mmio_base, irq);
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c5b1bf1..619313b 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6296,6 +6296,84 @@ static void ufshcd_def_desc_sizes(struct ufs_hba *hba)
 hba->desc_size.hlth_desc = QUERY_DESC_HEALTH_DEF_SIZE;
  }

+void ufshcd_parse_dev_ref_clk_freq(struct ufs_hba *hba)
+{
+   struct device *dev = hba->dev;
+   struct device_node *np = dev->of_node;
+   struct clk *refclk = NULL;
+
+   if (!np)
+   return;
+
+   refclk = of_clk_get_by_name(np, "ref_clk");
+   if (refclk)
+   hba->dev_ref_clk_freq  = clk_get_rate(refclk);
+   else if (!refclk ||
+   (hba->dev_ref_clk_freq > REF_CLK_FREQ_52_MHZ)) {

What is this logic? The !refclk condition will always be true since
you're in the else case of if (refclk). Also, even if the second part
were executed somehow, you haven't assigned dev_ref_clk_freq yet, so
how can its value be anything other than 0? Maybe that whole
conditional was just not supposed to be an "else" at all, but a
standalone if?

Agree. Will update.

+   dev_err(hba->dev,
+   "%s: invalid ref_clk setting = %u\n",
+   __func__, hba->dev_ref_clk_freq);

There's probably no need to complain if the clock simply couldn't be
found, only if an unexpected value was found.

Agree. Will update.

+   hba->dev_ref_clk_freq = 0;
+   }
+}
+
+static int ufshcd_set_dev_ref_clk(struct ufs_hba *hba)
+{
+   int err = 0;
+   int ref_clk = -1;
+   static const char * const ref_clk_freqs[] = {"19.2 MHz", "26 MHz",
+"38.4 MHz", "52 MHz"};
+
+   err = ufshcd_query_attr_retry(hba, UPIU_QUERY_OPCODE_READ_ATTR,
+   QUERY_ATTR_IDN_REF_CLK_FREQ, 0, 0, _clk);
+
+   if (err) {
+   dev_err(hba->dev, "%s: failed reading bRefClkFreq. err = %d\n",
+__func__, err);
+   goto out;
+   }
+
+   switch (hba->dev_ref_clk_freq) {
+   case REF_CLK_FREQ_19_2_MHZ:
+   hba->dev_ref_clk_freq = 0x0;
+   break;
+   case REF_CLK_FREQ_26_MHZ:
+   hba->dev_ref_clk_freq = 0x1;
+   break;
+   case REF_CLK_FREQ_38_4_MHZ:
+   hba->dev_ref_clk_freq = 0x2;
+   break;
+   case REF_CLK_FREQ_52_MHZ:
+   hba->dev_ref_clk_freq = 0x3;
+   break;
+   default:
+   dev_err(hba->dev,
+   "%s: invalid ref_clk setting = %u\n",
+   __func__, hba->dev_ref_clk_freq);
+   goto out;
+   }

Please don't assign two different things (frequency in Hertz and
bref_clk value) into the same structure member.

I think rather than having this switch statement you should iterate
through a table that contains elements of {freq_hz, bref_clk, string}.
I think you should do this up in ufshcd_parse_dev_ref_clk_freq so that
you don't have to redo that calculation on every rescan. Then store
the final bRefClkFreq value (or -1 if no definitive answer 

Re: [PATCH v3 3/8] mailbox: Add transmit done by blocking option

[Mikko Perttunen]

Here's my current code:

https://github.com/cyndis/linux/commits/wip/t194-tcu-4

"fixup! mailbox: tegra-hsp: Add support for shared mailboxes" splits up 
the controller into two. "tegra-hsp: use polling" changes it to use polling.


There are two lines in the top patch with comments:

- at the end of tegra_hsp_mailbox_send_data, I left a "while 
(!tegra_hsp_mailbox_last_tx_done(chan));". Without it I wasn't able to 
see even a few garbled characters in the output.


- as mentioned, if I enable tx_block on the client side, I get a BUG: 
scheduling while atomic. I assume this gets printed through the earlycon 
as it's printing out correctly.


Thanks,
Mikko

On 08.08.2018 17:46, Mikko Perttunen wrote:

On 08/08/2018 05:39 PM, Jassi Brar wrote:

On Wed, Aug 8, 2018 at 8:04 PM, Mikko Perttunen  wrote:



On 08/08/2018 05:10 PM, Jassi Brar wrote:


On Wed, Aug 8, 2018 at 5:08 PM, Mikko Perttunen  
wrote:




On 04.08.2018 13:45, Mikko Perttunen wrote:



On 08/03/2018 03:54 PM, Jassi Brar wrote:



On Mon, Jul 2, 2018 at 5:10 PM, Mikko Perttunen 


wrote:



Add a new TXDONE option, TXDONE_BY_BLOCK. With this option, the
send_data function of the mailbox driver is expected to block until
the message has been sent. The new option is used with the Tegra
Combined UART driver to minimize unnecessary overhead when
transmitting
data.


1) TXDONE_BY_BLOCK flag :-
   Have you tried setting the flag
mbox_chan->mbox_client->tx_block
?




No - I suppose I should have done that. I'm a bit concerned about
overhead
as send_data may be called thousands of times per second, so I 
tried to

make
it as close as possible to the downstream driver that just pokes the
mailbox
register directly.




I tried using polling in the mailbox framework. Some printing is done
from
atomic context so it seems tx_block cannot be used -
wait_for_completion_timeout understandably does not work in atomic
context.
I also tried without tx_block, in which case I got some horribly 
garbled

output, but "Try increasing MBOX_TX_QUEUE_LEN" was readable there.

Any opinions?


The problems arise because your hardware (SM) supports TXDONE_BY_POLL,
but your client drives it by TXDONE_BY_ACK because the older DB
channels are so.

Please populate SM channels as a separate controller than DB.
The DB controller, as is, run by ACK method.
The SM controller should be run by polling, i.e, set txdone_poll =
true and the poll period small enough. The virtual tty client driver
should be able to safely set tx_block from appropriate context.



Sorry, I should have clarified that I already split up the 
controllers. The

SM controller has txdone_poll = true. I didn't adjust txpoll_period so I
guess it's zero.


Can you please share your code (controller and client) ? Maybe offline
if you wish.



I'll upload a git branch tomorrow -- I'm not at the machine with the 
code now.


Mikko
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] irqchip/bcm7038-l1: hide cpu offline callback when building for !SMP

[Jonas Gorski]

When compiling bmips with SMP disabled, the build fails with:

drivers/irqchip/irq-bcm7038-l1.o: In function `bcm7038_l1_cpu_offline':
drivers/irqchip/irq-bcm7038-l1.c:242: undefined reference to 
`irq_set_affinity_locked'
make[5]: *** [vmlinux] Error 1

Fix this by adding and setting bcm7038_l1_cpu_offline only when actually
compiling for SMP. It wouldn't have been used anyway, as it requires
CPU_HOTPLUG, which in turn requires SMP.

Fixes: 34c535793bcb ("irqchip/bcm7038-l1: Implement irq_cpu_offline() callback")
Signed-off-by: Jonas Gorski 
---
 drivers/irqchip/irq-bcm7038-l1.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/irqchip/irq-bcm7038-l1.c b/drivers/irqchip/irq-bcm7038-l1.c
index faf734ff4cf3..0f6e30e9009d 100644
--- a/drivers/irqchip/irq-bcm7038-l1.c
+++ b/drivers/irqchip/irq-bcm7038-l1.c
@@ -217,6 +217,7 @@ static int bcm7038_l1_set_affinity(struct irq_data *d,
return 0;
 }
 
+#ifdef CONFIG_SMP
 static void bcm7038_l1_cpu_offline(struct irq_data *d)
 {
struct cpumask *mask = irq_data_get_affinity_mask(d);
@@ -241,6 +242,7 @@ static void bcm7038_l1_cpu_offline(struct irq_data *d)
}
irq_set_affinity_locked(d, _affinity, false);
 }
+#endif
 
 static int __init bcm7038_l1_init_one(struct device_node *dn,
  unsigned int idx,
@@ -293,7 +295,9 @@ static struct irq_chip bcm7038_l1_irq_chip = {
.irq_mask   = bcm7038_l1_mask,
.irq_unmask = bcm7038_l1_unmask,
.irq_set_affinity   = bcm7038_l1_set_affinity,
+#ifdef CONFIG_SMP
.irq_cpu_offline= bcm7038_l1_cpu_offline,
+#endif
 };
 
 static int bcm7038_l1_map(struct irq_domain *d, unsigned int virq,
-- 
2.13.2

Re: [PATCH RFC v2 02/10] mm: Make shrink_slab() lockless

[Kirill Tkhai]

On 09.08.2018 10:14, Michal Hocko wrote:
> On Wed 08-08-18 16:20:54, Kirill Tkhai wrote:
>> [Added two more places needed srcu_dereference(). All ->shrinker_map
>>  dereferences must be under SRCU, and this v2 adds missed in previous]
>>
>> The patch makes shrinker list and shrinker_idr SRCU-safe
>> for readers. This requires synchronize_srcu() on finalize
>> stage unregistering stage, which waits till all parallel
>> shrink_slab() are finished
>>
>> Note, that patch removes rwsem_is_contended() checks from
>> the code, and this does not result in delays during
>> registration, since there is no waiting at all. Unregistration
>> case may be optimized by splitting unregister_shrinker()
>> in tho stages, and this is made in next patches.
>> 
>> Also, keep in mind, that in case of SRCU is not allowed
>> to make unconditional (which is done in previous patch),
>> it is possible to use percpu_rw_semaphore instead of it.
>> percpu_down_read() will be used in shrink_slab_memcg()
>> and in shrink_slab(), and consecutive calls
>>
>> percpu_down_write(percpu_rwsem);
>> percpu_up_write(percpu_rwsem);
>>
>> will be used instead of synchronize_srcu().
> 
> An obvious question. Why didn't you go that way? What are pros/cons of
> both approaches?

1)After percpu_rw_semaphore is introduced, shrink_slab() will be not able
  to do successful percpu_down_read_trylock() for longer time in comparison
  to current behavior:

  [cpu0]   [cpu1]
  {un,}register_shrinker();
shrink_slab()
percpu_down_write(); 
percpu_down_read_trylock() -> fail
  synchronize_rcu(); -> in some periods very slow on big SMP   ...
   
shrink_slab()
 
percpu_down_read_trylock() -> fail

  Also, register_shrinker() and unregister_shrinker() will become slower for 
the same reason.
  Unlike unregister_shrinker(); register_shrinker() can't be made 
asynchronous/delayed, so 
  simple mount() performance will be worse.

  It's possible, these both can be solved by using both percpu_rw_semaphore and 
rw_semaphore.
  shrink_slab() may fall back to rw_semaphore in case of percpu_rw_semaphore 
can't be blocked:

  shrink_slab()
  {
bool percpu = true;

if (!percpu_down_read_try_lock()) {
   if(!down_read_trylock())
return 0;
   percpu = false;
}

shrinker = idr_find();
...

if (percpu)
 percpu_up_read();
else
 up_read();
   }

   register_shrinker()
   {
 down_write();
 idr_alloc();
 up_write();
   }

   unregister_shrinker()
   {
 percpu_down_write();
 down_write();
 idr_remove();
 up_write();
 percpu_up_write();
   }

   But a)On big machine this may turn in always down_read_trylock() like we 
have now;
   b)I'm not sure, unlocked idr_find() is safe in parallel with 
idr_alloc(), maybe,
 there is needed something else around it (I just haven't investigated 
this).

   All the above are cons. Pros are not enabling SRCU.

2)SRCU. Pros are there are no the above problems; we will have completely 
unlocked and
  scalable shrink_slab(). We will also have a possibility to avoid 
unregistering delays,
  like I did for superblock shrinker. There will be full scalability.
  Cons is enabling SRCU.

Kirill

[no subject]

[системы администратор]

внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль: 
Подтверждение пароля: 
Адрес электронной почты: 
телефон: 

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: 006524
Почты технической поддержки  2018

спасибо
системы администратор

Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

[Sudeep Holla]

On Wed, Aug 08, 2018 at 02:18:18PM -0700, skan...@codeaurora.org wrote:
> On 2018-08-08 01:47, Sudeep Holla wrote:
> >On Tue, Aug 07, 2018 at 12:37:07PM -0700, skan...@codeaurora.org wrote:
> >>On 2018-08-07 09:41, Rob Herring wrote:
> >>>On Wed, Aug 01, 2018 at 05:57:41PM -0700, Saravana Kannan wrote:
> Many CPU architectures have caches that can scale independent of the
> CPUs.
> Frequency scaling of the caches is necessary to make sure the cache is
> not
> a performance bottleneck that leads to poor performance and power. The
> same
> idea applies for RAM/DDR.
> 
> To achieve this, this patch adds a generic devfreq governor that takes
> the
> current frequency of each CPU frequency domain and then adjusts the
> frequency of the cache (or any devfreq device) based on the frequency of
> the CPUs. It listens to CPU frequency transition notifiers to keep
> itself
> up to date on the current CPU frequency.
> 
> To decide the frequency of the device, the governor does one of the
> following:
> 
> * Uses a CPU frequency to device frequency mapping table
>   - Either one mapping table used for all CPU freq policies (typically
> used
> for system with homogeneous cores/clusters that have the same OPPs).
>   - One mapping table per CPU freq policy (typically used for ASMP
> systems
> with heterogeneous CPUs with different OPPs)
> 
> OR
> 
> * Scales the device frequency in proportion to the CPU frequency. So, if
>   the CPUs are running at their max frequency, the device runs at its
> max
>   frequency.  If the CPUs are running at their min frequency, the device
>   runs at its min frequency. And interpolated for frequencies in
> between.
> 
> Signed-off-by: Saravana Kannan 
> ---
>  .../bindings/devfreq/devfreq-cpufreq-map.txt   |  53 ++
> >>>
> >>>Bindings should be a separate patch.
> >>>
>  drivers/devfreq/Kconfig|   8 +
>  drivers/devfreq/Makefile   |   1 +
>  drivers/devfreq/governor_cpufreq_map.c | 583
> +
>  4 files changed, 645 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt
>  create mode 100644 drivers/devfreq/governor_cpufreq_map.c
> 
> diff --git
> a/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt
> b/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt
> new file mode 100644
> index 000..982a30b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt
> @@ -0,0 +1,53 @@
> +Devfreq CPUfreq governor
> +
> +devfreq-cpufreq-map is a parent device that contains one or more child
> devices.
> +Each child device provides CPU frequency to device frequency mapping
> for a
> +specific device. Examples of devices that could use this are: DDR,
> cache and
> +CCI.
> +
> +Parent device name shall be "devfreq-cpufreq-map".
> +
> +Required child device properties:
> +- cpu-to-dev-map, or cpu-to-dev-map-:
> + A list of tuples where each tuple consists of a
> + CPU frequency (KHz) and the corresponding device
> + frequency. CPU frequencies not listed in the table
> + will use the device frequency that corresponds to the
> + next rounded up CPU frequency.
> + Use "cpu-to-dev-map" if all CPUs in the system should
> + share same mapping.
> + Use cpu-to-dev-map- to describe different
> + mappings for different CPUs. The property should be
> + listed only for the first CPU if multiple CPUs are
> + synchronous.
> +- target-dev:Phandle to device that this mapping applies to.
> +
> +Example:
> + devfreq-cpufreq-map {
> + cpubw-cpufreq {
> + target-dev = <>;
> + cpu-to-dev-map =
> + <  30  1144000 >,
> + <  422400  2288000 >,
> + <  652800  3051000 >,
> + <  883200  5996000 >,
> + < 1190400  8056000 >,
> + < 1497600 10101000 >,
> + < 1728000 12145000 >,
> + < 2649600 1625 >;
> >>>
> >>>Now we have frequencies listed in multiple places, the OPP tables and
> >>>here? Perhaps it is grouping OPPs that should be done.
> >>
> >>This doesn't list all OPPs (it can if necessary). This is listing the
> >>minimum frequency needed to give good performance/power for a
> >>device/product.
> >>
> >
> >Shouldn't the "status" 

Re: [PATCH v5 1/4] ACPI / scan: Initialize status to ACPI_STA_DEFAULT

[Hans de Goede]

Hi,

On 09-08-18 11:51, Andy Shevchenko wrote:

On Thu, Aug 9, 2018 at 12:39 PM, Hans de Goede  wrote:

On 09-08-18 11:35, Rafael J. Wysocki wrote:

On Thu, Aug 9, 2018 at 11:15 AM, Hans de Goede 
wrote:



I've applied the v4 of this patch and I don't think there are any
changes from it here.



Correct, there were only changes to the 4th patch in the series.


As for the rest of the series I'll wait from comments from Wolfram and
the other reviewers.



Ok, note if you've taken patch 1 you may also want to take patch 3 which
is an ACPI code cleanup made possible by patch 1 and otherwise is
unrelated.


I'm under impression Rafael is going to take entire series (at least
for patch 4 I'm expecting to give an Ack).


As I mentioned in the coverletter, my idea was to have Rafael take
patches 1-3 and then merge the 4th patch through the platform/x86
tree. There are only runtime dependencies between the 2 parts and
merging them independently should not cause any issues.

Regards,

Hans

Re: [RFC PATCH 2/3] mm/memory_hotplug: Create __shrink_pages and move it to offline_pages

[Oscar Salvador]

On Wed, Aug 08, 2018 at 11:29:08PM +0200, Oscar Salvador wrote:
> On Wed, Aug 08, 2018 at 01:55:59PM -0400, Jerome Glisse wrote:
> > Note that Dan did post patches that already go in that direction (unifying
> > code between devm and HMM). I think they are in Andrew queue, looks for
> > 
> > mm: Rework hmm to use devm_memremap_pages and other fixes
> 
> Thanks for pointing that out.
> I will take a look at that work.

Ok, I checked the patchset [1] and I think it is nice that those two (devm and 
HMM)
get unified.
I think it will make things easier when we have to change things for the 
memory-hotplug.
Actually, I think that after [2], all hot-adding memory will be handled in 
devm_memremap_pages.

What I do not see is why the patch did not make it to further RCs.

Thanks
-- 
Oscar Salvador
SUSE L3

Re: [PATCH v8 09/26] kernel/cpu_pm: Manage runtime PM in the idle path for CPUs

[Rafael J. Wysocki]

On Wed, Aug 8, 2018 at 8:02 PM, Lina Iyer  wrote:
> On Wed, Aug 08 2018 at 04:56 -0600, Lorenzo Pieralisi wrote:
>>
>> On Mon, Aug 06, 2018 at 11:37:55AM +0200, Rafael J. Wysocki wrote:
>>>
>>> On Fri, Aug 3, 2018 at 1:42 PM, Ulf Hansson 
>>> wrote:
>>> > [...]
>>> >
>>> >>>
>>> >>> Assuming that I have got that right, there are concerns, mostly
>>> >>> regarding
>>> >>> patch [07/26], but I will reply to that directly.
>>> >>
>>> >> Well, I haven't got that right, so never mind.
>>> >>
>>> >> There are a few minor things to address, but apart from that the
>>> >> general
>>> >> genpd patches look ready.
>>> >
>>> > Alright, thanks!
>>> >
>>> > I will re-spin the series and post a new version once 4.19 rc1 is out.
>>> > Hopefully we can queue it up early in next cycle to get it tested in
>>> > next for a while.
>>> >
>>> >>
>>> >>> The $subject patch is fine by me by itself, but it obviously depends
>>> >>> on the
>>> >>> previous ones.  Patches [01-02/26] are fine too, but they don't seem
>>> >>> to be
>>> >>> particularly useful without the rest of the series.
>>> >>>
>>> >>> As far as patches [10-26/26] go, I'd like to see some review comments
>>> >>> and/or
>>> >>> tags from the people with vested interest in there, in particular
>>> >>> from Daniel
>>> >>> on patch [12/26] and from Sudeep on the PSCI ones.
>>> >>
>>> >> But this still holds.
>>> >
>>> > Actually, patch 10 and patch11 is ready to go as well. I ping Daniel
>>> > on patch 12.
>>> >
>>> > In regards to the rest of the series, some of the PSCI/ARM changes
>>> > have been reviewed by Mark Rutland, however several changes have not
>>> > been acked.
>>> >
>>> > On the other hand, one can also interpret the long silence in regards
>>> > to PSCI/ARM changes as they are good to go. :-)
>>>
>>> Well, in that case giving an ACK to them should not be an issue for
>>> the people with a vested interest I suppose.
>>
>>
>> Apologies to everyone for the delay in replying.
>>
>> Side note: cpu_pm_enter()/exit() are also called through syscore ops in
>> s2RAM/IDLE, you know that but I just wanted to mention it to compound
>> the discussion.
>>
>> As for PSCI patches I do not personally think PSCI OSI enablement is
>> beneficial (and my position has always been the same since PSCI OSI was
>> added to the specification, I am not even talking about this patchset)
>> and Arm Trusted Firmware does not currently support it for the same
>> reason.
>>
>> We (if Mark and Sudeep agree) will enable PSCI OSI if and when we have a
>> definitive and constructive answer to *why* we have to do that that is
>> not a dogmatic "the kernel knows better" but rather a comprehensive
>> power benchmark evaluation - I thought that was the agreement reached
>> at OSPM but apparently I was mistaken.
>>
> I will not speak to any comparison of benchmarks between OSI and PC.
> AFAIK, there are no platforms supporting both.
>
> But, the OSI feature is critical for QCOM mobile platforms. The
> last man activities during cpuidle save quite a lot of power. Powering
> off the clocks, busses, regulators and even the oscillator is very
> important to have a reasonable battery life when using the phone.
> Platform coordinated approach falls quite short of the needs of a
> powerful processor with a desired battery efficiency.

Even so, you still need firmware (or hardware) to do the right thing
in the concurrent wakeup via an edge-triggered interrupt case AFAICS.
That is, you need the domain to be prevented from being turned off if
one of the CPUs in it has just been woken up and the interrupt is
still pending.

Re: [PATCH v2 01/15] staging:rtl8192u: Remove macro eqMacAddr - Style

[John Whitmore]

On Wed, Aug 08, 2018 at 03:14:19PM -0700, Joe Perches wrote:
> On Wed, 2018-08-08 at 22:00 +0100, John Whitmore wrote:
> > The macro eqMacAddr implements the same functionality as the
> > ether_addr_equal function defined in etherdevice.h, as a result the
> > macro has been removed from the code, and its use replaced with the
> > function call.
> []
> > diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> > b/drivers/staging/rtl8192u/r8192U_core.c
> []
> > @@ -4460,15 +4460,15 @@ static void TranslateRxSignalStuff819xUsb(struct 
> > sk_buff *skb,
> >  
> > /* Check if the received packet is acceptable. */
> > bpacket_match_bssid = (type != IEEE80211_FTYPE_CTL) &&
> > -  
> > (eqMacAddr(priv->ieee80211->current_network.bssid,  (fc & 
> > IEEE80211_FCTL_TODS) ? hdr->addr1 : (fc & IEEE80211_FCTL_FROMDS) ? 
> > hdr->addr2 : hdr->addr3))
> > +  
> > (ether_addr_equal(priv->ieee80211->current_network.bssid,  (fc & 
> > IEEE80211_FCTL_TODS) ? hdr->addr1 : (fc & IEEE80211_FCTL_FROMDS) ? 
> > hdr->addr2 : hdr->addr3))
> >&& (!pstats->bHwError) && (!pstats->bCRC) && 
> > (!pstats->bICV);
> > bpacket_toself =  bpacket_match_bssid &
> > - (eqMacAddr(praddr, priv->ieee80211->dev->dev_addr));
> > + (ether_addr_equal(praddr, 
> > priv->ieee80211->dev->dev_addr));
> 
> Likely this should be
> 
>   bpacket_match_bssid = bpacket_match_bss &&
> 
> as boolean use with a bitwise & is odd.
> 

Yes have to agree odd. Somebody famous in Computer Science said that
debugging was twice as difficult as writing code, so why would you
write the cleverest code you possibly could, or something like that.
That's what I thought when I now looked at that line of code.

I've been going through this driver cleaning up header files first.
Once those are sorted I was going to turn to the C and try get my
head around the logic. I'll have to look at the functionality of that
bpacket_toself variable but a bitwise operation does look odd.

[PATCH] mm, slub: restore the original intention of prefetch_freepointer()

[Vlastimil Babka]

In SLUB, prefetch_freepointer() is used when allocating an object from cache's
freelist, to make sure the next object in the list is cache-hot, since it's
probable it will be allocated soon.

Commit 2482ddec670f ("mm: add SLUB free list pointer obfuscation") has
unintentionally changed the prefetch in a way where the prefetch is turned to a
real fetch, and only the next->next pointer is prefetched. In case there is not
a stream of allocations that would benefit from prefetching, the extra real
fetch might add a useless cache miss to the allocation. Restore the previous
behavior.

Signed-off-by: Vlastimil Babka 
Cc: Kees Cook 
Cc: Daniel Micay 
Cc: Eric Dumazet 
Cc: Christoph Lameter 
Cc: Pekka Enberg 
Cc: David Rientjes 
Cc: Joonsoo Kim 
---
While I don't expect this to be causing the bug at hand, it's worth fixing.
For the bug it might mean that the page fault moves elsewhere.

 mm/slub.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index 51258eff4178..ce2b9e5cea77 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -271,8 +271,7 @@ static inline void *get_freepointer(struct kmem_cache *s, 
void *object)
 
 static void prefetch_freepointer(const struct kmem_cache *s, void *object)
 {
-   if (object)
-   prefetch(freelist_dereference(s, object + s->offset));
+   prefetch(object + s->offset);
 }
 
 static inline void *get_freepointer_safe(struct kmem_cache *s, void *object)
-- 
2.18.0

Re: [PATCH v3 3/8] mailbox: Add transmit done by blocking option

[Jassi Brar]

[dropping everyone else while we discuss the code]

Thanks. I assume that branch as all the code that there is. Let me
look and get back to you.

On Thu, Aug 9, 2018 at 2:19 PM, Mikko Perttunen  wrote:
> Here's my current code:
>
> https://github.com/cyndis/linux/commits/wip/t194-tcu-4
>
> "fixup! mailbox: tegra-hsp: Add support for shared mailboxes" splits up the
> controller into two. "tegra-hsp: use polling" changes it to use polling.
>
> There are two lines in the top patch with comments:
>
> - at the end of tegra_hsp_mailbox_send_data, I left a "while
> (!tegra_hsp_mailbox_last_tx_done(chan));". Without it I wasn't able to see
> even a few garbled characters in the output.
>
> - as mentioned, if I enable tx_block on the client side, I get a BUG:
> scheduling while atomic. I assume this gets printed through the earlycon as
> it's printing out correctly.
>
> Thanks,
> Mikko
>
>
> On 08.08.2018 17:46, Mikko Perttunen wrote:
>>
>> On 08/08/2018 05:39 PM, Jassi Brar wrote:
>>>
>>> On Wed, Aug 8, 2018 at 8:04 PM, Mikko Perttunen  wrote:



 On 08/08/2018 05:10 PM, Jassi Brar wrote:
>
>
> On Wed, Aug 8, 2018 at 5:08 PM, Mikko Perttunen 
> wrote:
>>
>>
>>
>>
>> On 04.08.2018 13:45, Mikko Perttunen wrote:
>>>
>>>
>>>
>>> On 08/03/2018 03:54 PM, Jassi Brar wrote:



 On Mon, Jul 2, 2018 at 5:10 PM, Mikko Perttunen
 
 wrote:
>
>
>
> Add a new TXDONE option, TXDONE_BY_BLOCK. With this option, the
> send_data function of the mailbox driver is expected to block until
> the message has been sent. The new option is used with the Tegra
> Combined UART driver to minimize unnecessary overhead when
> transmitting
> data.
>
 1) TXDONE_BY_BLOCK flag :-
Have you tried setting the flag
 mbox_chan->mbox_client->tx_block
 ?
>>>
>>>
>>>
>>>
>>> No - I suppose I should have done that. I'm a bit concerned about
>>> overhead
>>> as send_data may be called thousands of times per second, so I tried
>>> to
>>> make
>>> it as close as possible to the downstream driver that just pokes the
>>> mailbox
>>> register directly.
>>
>>
>>
>>
>> I tried using polling in the mailbox framework. Some printing is done
>> from
>> atomic context so it seems tx_block cannot be used -
>> wait_for_completion_timeout understandably does not work in atomic
>> context.
>> I also tried without tx_block, in which case I got some horribly
>> garbled
>> output, but "Try increasing MBOX_TX_QUEUE_LEN" was readable there.
>>
>> Any opinions?
>>
> The problems arise because your hardware (SM) supports TXDONE_BY_POLL,
> but your client drives it by TXDONE_BY_ACK because the older DB
> channels are so.
>
> Please populate SM channels as a separate controller than DB.
> The DB controller, as is, run by ACK method.
> The SM controller should be run by polling, i.e, set txdone_poll =
> true and the poll period small enough. The virtual tty client driver
> should be able to safely set tx_block from appropriate context.
>

 Sorry, I should have clarified that I already split up the controllers.
 The
 SM controller has txdone_poll = true. I didn't adjust txpoll_period so I
 guess it's zero.

>>> Can you please share your code (controller and client) ? Maybe offline
>>> if you wish.
>>>
>>
>> I'll upload a git branch tomorrow -- I'm not at the machine with the code
>> now.
>>
>> Mikko
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" 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 09/14] sched: Add over-utilization/tipping point indicator

[Quentin Perret]

On Thursday 09 Aug 2018 at 11:30:57 (+0200), Vincent Guittot wrote:
> On Tue, 24 Jul 2018 at 14:26, Quentin Perret  wrote:
> >
> > From: Morten Rasmussen 
> >
> > Energy-aware scheduling is only meant to be active while the system is
> > _not_ over-utilized. That is, there are spare cycles available to shift
> > tasks around based on their actual utilization to get a more
> > energy-efficient task distribution without depriving any tasks. When
> > above the tipping point task placement is done the traditional way based
> > on load_avg, spreading the tasks across as many cpus as possible based
> > on priority scaled load to preserve smp_nice. Below the tipping point we
> > want to use util_avg instead. We need to define a criteria for when we
> > make the switch.
> >
> > The util_avg for each cpu converges towards 100% (1024) regardless of
> 
> remove the "(1024)" because util_avg converges to max cpu capacity
> which can be different from 1024

Good point, will be fixed in v6.

Thanks,
Quentin

Re: [PATCH v5 1/4] ACPI / scan: Initialize status to ACPI_STA_DEFAULT

[Hans de Goede]

Hi,

On 09-08-18 11:35, Rafael J. Wysocki wrote:

On Thu, Aug 9, 2018 at 11:15 AM, Hans de Goede  wrote:

Since commit 63347db0affa ("ACPI / scan: Use acpi_bus_get_status() to
initialize ACPI_TYPE_DEVICE devs") the status field of normal acpi_devices
gets set to 0 by acpi_bus_type_and_status() and filled with its actual
value later when acpi_add_single_object() calls acpi_bus_get_status().

This means that any acpi_match_device_ids() calls in between will always
fail with -ENOENT.

We already have a workaround for this, which temporary forces status to
ACPI_STA_DEFAULT in drivers/acpi/x86/utils.c: acpi_device_always_present()
and the next commit in this series adds another acpi_match_device_ids()
call between status being initialized as 0 and the acpi_bus_get_status()
call.

Rather then adding another workaround, this commit makes
acpi_bus_type_and_status() initialize status to ACPI_STA_DEFAULT, this is
safe to do as the only code looking at status between the initialization
and the acpi_bus_get_status() call is those acpi_match_device_ids() calls.

Note this does mean that we need to (re)set status to 0 in case the
acpi_bus_get_status() call fails.

Signed-off-by: Hans de Goede 
---
Changes in v3:
-New patch in v3 of this patch-set

Changes in v4:
-This is not a fix for acpi_is_indirect_io_slave() as I thought at first,
  acpi_is_indirect_io_slave() calls acpi_match_device_ids() on its parent
  device, where status is already set properly. Rewrite the commit message
  accordingly.


I've applied the v4 of this patch and I don't think there are any
changes from it here.


Correct, there were only changes to the 4th patch in the series.


As for the rest of the series I'll wait from comments from Wolfram and
the other reviewers.


Ok, note if you've taken patch 1 you may also want to take patch 3 which
is an ACPI code cleanup made possible by patch 1 and otherwise is
unrelated.

Regards,

Hans

[PATCH] ASoC: da7219: Add delays to capture path to remove DC offset noise

[Adam Thomson]

On some platforms it has been noted that a pop noise can be
witnessed when capturing audio, mainly for first time after a
headset jack has been inserted. This is due to a DC offset in the
Mic PGA and so to avoid this delays are required when powering
up the capture path.

This commit rectifies the problem by adding delays post Mic PGA and
post Mixin PGA. The post Mic PGA delay is determined based on
Mic Bias voltage, and is only applied the first time after a
headset jack is inserted.

Signed-off-by: Adam Thomson 
---
 sound/soc/codecs/da7219-aad.c |  5 +
 sound/soc/codecs/da7219.c | 44 +--
 sound/soc/codecs/da7219.h |  8 ++--
 3 files changed, 49 insertions(+), 8 deletions(-)

diff --git a/sound/soc/codecs/da7219-aad.c b/sound/soc/codecs/da7219-aad.c
index a49ab75..2c7d508 100644
--- a/sound/soc/codecs/da7219-aad.c
+++ b/sound/soc/codecs/da7219-aad.c
@@ -59,6 +59,7 @@ static void da7219_aad_btn_det_work(struct work_struct *work)
container_of(work, struct da7219_aad_priv, btn_det_work);
struct snd_soc_component *component = da7219_aad->component;
struct snd_soc_dapm_context *dapm = 
snd_soc_component_get_dapm(component);
+   struct da7219_priv *da7219 = snd_soc_component_get_drvdata(component);
u8 statusa, micbias_ctrl;
bool micbias_up = false;
int retries = 0;
@@ -86,6 +87,8 @@ static void da7219_aad_btn_det_work(struct work_struct *work)
if (retries >= DA7219_AAD_MICBIAS_CHK_RETRIES)
dev_warn(component->dev, "Mic bias status check timed out");
 
+   da7219->micbias_on_event = true;
+
/*
 * Mic bias pulse required to enable mic, must be done before enabling
 * button detection to prevent erroneous button readings.
@@ -439,6 +442,8 @@ static irqreturn_t da7219_aad_irq_thread(int irq, void 
*data)
snd_soc_component_update_bits(component, 
DA7219_ACCDET_CONFIG_1,
DA7219_BUTTON_CONFIG_MASK, 0);
 
+   da7219->micbias_on_event = false;
+
/* Disable mic bias */
snd_soc_dapm_disable_pin(dapm, "Mic Bias");
snd_soc_dapm_sync(dapm);
diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
index c0144f2..e46e9f4 100644
--- a/sound/soc/codecs/da7219.c
+++ b/sound/soc/codecs/da7219.c
@@ -768,6 +768,30 @@ static int da7219_tonegen_freq_put(struct snd_kcontrol 
*kcontrol,
  * DAPM Events
  */
 
+static int da7219_mic_pga_event(struct snd_soc_dapm_widget *w,
+   struct snd_kcontrol *kcontrol, int event)
+{
+   struct snd_soc_component *component = 
snd_soc_dapm_to_component(w->dapm);
+   struct da7219_priv *da7219 = snd_soc_component_get_drvdata(component);
+
+   switch (event) {
+   case SND_SOC_DAPM_POST_PMU:
+   if (da7219->micbias_on_event) {
+   /*
+* Delay only for first capture after bias enabled to
+* avoid possible DC offset related noise.
+*/
+   da7219->micbias_on_event = false;
+   msleep(da7219->mic_pga_delay);
+   }
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
 static int da7219_dai_event(struct snd_soc_dapm_widget *w,
struct snd_kcontrol *kcontrol, int event)
 {
@@ -937,12 +961,12 @@ static int da7219_gain_ramp_event(struct 
snd_soc_dapm_widget *w,
SND_SOC_DAPM_INPUT("MIC"),
 
/* Input PGAs */
-   SND_SOC_DAPM_PGA("Mic PGA", DA7219_MIC_1_CTRL,
-DA7219_MIC_1_AMP_EN_SHIFT, DA7219_NO_INVERT,
-NULL, 0),
-   SND_SOC_DAPM_PGA("Mixin PGA", DA7219_MIXIN_L_CTRL,
-DA7219_MIXIN_L_AMP_EN_SHIFT, DA7219_NO_INVERT,
-NULL, 0),
+   SND_SOC_DAPM_PGA_E("Mic PGA", DA7219_MIC_1_CTRL,
+  DA7219_MIC_1_AMP_EN_SHIFT, DA7219_NO_INVERT,
+  NULL, 0, da7219_mic_pga_event, 
SND_SOC_DAPM_POST_PMU),
+   SND_SOC_DAPM_PGA_E("Mixin PGA", DA7219_MIXIN_L_CTRL,
+  DA7219_MIXIN_L_AMP_EN_SHIFT, DA7219_NO_INVERT,
+  NULL, 0, da7219_settling_event, 
SND_SOC_DAPM_POST_PMU),
 
/* Input Filters */
SND_SOC_DAPM_ADC("ADC", NULL, DA7219_ADC_L_CTRL, DA7219_ADC_L_EN_SHIFT,
@@ -1847,6 +1871,14 @@ static void da7219_handle_pdata(struct snd_soc_component 
*component)
 
snd_soc_component_write(component, DA7219_MICBIAS_CTRL, 
micbias_lvl);
 
+   /*
+* Calculate delay required to compensate for DC offset in
+* Mic PGA, based on Mic Bias voltage.
+*/
+   da7219->mic_pga_delay =  DA7219_MIC_PGA_BASE_DELAY +
+  

[PATCH 3.18.y 1/5] xattr_handler: pass dentry and inode as separate arguments of ->get()

[Seung-Woo Kim]

From: Al Viro 

commit b296821a7c42fa58baa17513b2b7b30ae66f3336 upstream.

... and do not assume they are already attached to each other

Signed-off-by: Al Viro 

[sw0312.kim: backport to 3.18 including ext3]
Signed-off-by: Seung-Woo Kim 
---
 fs/9p/acl.c  |7 ---
 fs/9p/xattr_security.c   |5 +++--
 fs/9p/xattr_trusted.c|5 +++--
 fs/9p/xattr_user.c   |5 +++--
 fs/ext2/xattr_security.c |6 +++---
 fs/ext2/xattr_trusted.c  |6 +++---
 fs/ext2/xattr_user.c |8 
 fs/ext3/xattr_security.c |6 +++---
 fs/ext3/xattr_trusted.c  |6 +++---
 fs/ext3/xattr_user.c |8 
 fs/ext4/xattr_security.c |6 +++---
 fs/ext4/xattr_trusted.c  |6 +++---
 fs/ext4/xattr_user.c |8 
 fs/f2fs/xattr.c  |   15 +++
 fs/gfs2/xattr.c  |6 +++---
 fs/hfsplus/xattr.c   |7 ---
 fs/hfsplus/xattr.h   |   10 +-
 fs/hfsplus/xattr_security.c  |7 ---
 fs/hfsplus/xattr_trusted.c   |7 ---
 fs/hfsplus/xattr_user.c  |7 ---
 fs/jffs2/security.c  |7 ---
 fs/jffs2/xattr_trusted.c |7 ---
 fs/jffs2/xattr_user.c|7 ---
 fs/nfs/nfs4proc.c|   14 --
 fs/ocfs2/xattr.c |   23 +--
 fs/posix_acl.c   |   10 +-
 fs/reiserfs/xattr.c  |3 ++-
 fs/reiserfs/xattr_security.c |8 
 fs/reiserfs/xattr_trusted.c  |8 
 fs/reiserfs/xattr_user.c |8 
 fs/squashfs/xattr.c  |   22 +-
 fs/xattr.c   |3 ++-
 fs/xfs/xfs_xattr.c   |4 ++--
 include/linux/xattr.h|4 ++--
 34 files changed, 145 insertions(+), 124 deletions(-)

diff --git a/fs/9p/acl.c b/fs/9p/acl.c
index cc67477..938e1a4 100644
--- a/fs/9p/acl.c
+++ b/fs/9p/acl.c
@@ -230,8 +230,9 @@ static int v9fs_remote_get_acl(struct dentry *dentry, const 
char *name,
return v9fs_xattr_get(dentry, full_name, buffer, size);
 }
 
-static int v9fs_xattr_get_acl(struct dentry *dentry, const char *name,
- void *buffer, size_t size, int type)
+static int v9fs_xattr_get_acl(struct dentry *dentry, struct inode *inode,
+ const char *name, void *buffer, size_t size,
+ int type)
 {
struct v9fs_session_info *v9ses;
struct posix_acl *acl;
@@ -247,7 +248,7 @@ static int v9fs_xattr_get_acl(struct dentry *dentry, const 
char *name,
if ((v9ses->flags & V9FS_ACCESS_MASK) != V9FS_ACCESS_CLIENT)
return v9fs_remote_get_acl(dentry, name, buffer, size, type);
 
-   acl = v9fs_get_cached_acl(dentry->d_inode, type);
+   acl = v9fs_get_cached_acl(inode, type);
if (IS_ERR(acl))
return PTR_ERR(acl);
if (acl == NULL)
diff --git a/fs/9p/xattr_security.c b/fs/9p/xattr_security.c
index cb247a1..df692f9 100644
--- a/fs/9p/xattr_security.c
+++ b/fs/9p/xattr_security.c
@@ -19,8 +19,9 @@
 #include 
 #include "xattr.h"
 
-static int v9fs_xattr_security_get(struct dentry *dentry, const char *name,
-   void *buffer, size_t size, int type)
+static int v9fs_xattr_security_get(struct dentry *dentry, struct inode *inode,
+  const char *name, void *buffer, size_t size,
+  int type)
 {
int retval;
char *full_name;
diff --git a/fs/9p/xattr_trusted.c b/fs/9p/xattr_trusted.c
index e30d33b..acfadcf 100644
--- a/fs/9p/xattr_trusted.c
+++ b/fs/9p/xattr_trusted.c
@@ -19,8 +19,9 @@
 #include 
 #include "xattr.h"
 
-static int v9fs_xattr_trusted_get(struct dentry *dentry, const char *name,
-   void *buffer, size_t size, int type)
+static int v9fs_xattr_trusted_get(struct dentry *dentry, struct inode *inode,
+ const char *name, void *buffer, size_t size,
+ int type)
 {
int retval;
char *full_name;
diff --git a/fs/9p/xattr_user.c b/fs/9p/xattr_user.c
index d0b701b..9b37675 100644
--- a/fs/9p/xattr_user.c
+++ b/fs/9p/xattr_user.c
@@ -19,8 +19,9 @@
 #include 
 #include "xattr.h"
 
-static int v9fs_xattr_user_get(struct dentry *dentry, const char *name,
-   void *buffer, size_t size, int type)
+static int v9fs_xattr_user_get(struct dentry *dentry, struct inode *inode,
+  const char *name, void *buffer, size_t size,
+  int type)
 {
int retval;
char *full_name;
diff --git a/fs/ext2/xattr_security.c b/fs/ext2/xattr_security.c
index c0ebc4d..1d53da4 100644
--- a/fs/ext2/xattr_security.c
+++ b/fs/ext2/xattr_security.c
@@ -23,12 +23,12 @@ ext2_xattr_security_list(struct dentry *dentry, char *list, 
size_t list_size,
 }
 
 static int

[PATCH 3.18.y 4/5] switch xattr_handler->set() to passing dentry and inode separately

[Seung-Woo Kim]

From: Al Viro 

preparation for similar switch in ->setxattr() (see the next commit for
rationale).

Signed-off-by: Al Viro 

[sw0312.kim: backport to 3.18 including ext3]
Signed-off-by: Seung-Woo Kim 
---
 fs/9p/acl.c  |7 +++
 fs/9p/xattr_security.c   |5 +++--
 fs/9p/xattr_trusted.c|5 +++--
 fs/9p/xattr_user.c   |5 +++--
 fs/ext2/xattr_security.c |7 ---
 fs/ext2/xattr_trusted.c  |7 ---
 fs/ext2/xattr_user.c |9 +
 fs/ext3/xattr_security.c |7 ---
 fs/ext3/xattr_trusted.c  |7 ---
 fs/ext3/xattr_user.c |9 +
 fs/ext4/xattr_security.c |7 ---
 fs/ext4/xattr_trusted.c  |7 ---
 fs/ext4/xattr_user.c |9 +
 fs/f2fs/xattr.c  |   17 -
 fs/gfs2/xattr.c  |7 ---
 fs/hfsplus/xattr.c   |7 ---
 fs/hfsplus/xattr.h   |4 ++--
 fs/hfsplus/xattr_security.c  |7 ---
 fs/hfsplus/xattr_trusted.c   |7 ---
 fs/hfsplus/xattr_user.c  |7 ---
 fs/jffs2/security.c  |7 ---
 fs/jffs2/xattr_trusted.c |7 ---
 fs/jffs2/xattr_user.c|7 ---
 fs/nfs/nfs4proc.c|   19 +--
 fs/ocfs2/xattr.c |   23 +--
 fs/posix_acl.c   |6 +++---
 fs/reiserfs/xattr.c  |6 --
 fs/reiserfs/xattr_security.c |8 
 fs/reiserfs/xattr_trusted.c  |8 
 fs/reiserfs/xattr_user.c |8 
 fs/xattr.c   |5 +++--
 fs/xfs/xfs_xattr.c   |7 ---
 include/linux/xattr.h|5 +++--
 33 files changed, 144 insertions(+), 119 deletions(-)

diff --git a/fs/9p/acl.c b/fs/9p/acl.c
index 938e1a4..0928d74 100644
--- a/fs/9p/acl.c
+++ b/fs/9p/acl.c
@@ -279,14 +279,13 @@ static int v9fs_remote_set_acl(struct dentry *dentry, 
const char *name,
 }
 
 
-static int v9fs_xattr_set_acl(struct dentry *dentry, const char *name,
- const void *value, size_t size,
- int flags, int type)
+static int v9fs_xattr_set_acl(struct dentry *dentry, struct inode *inode,
+ const char *name, const void *value,
+ size_t size, int flags, int type)
 {
int retval;
struct posix_acl *acl;
struct v9fs_session_info *v9ses;
-   struct inode *inode = dentry->d_inode;
 
if (strcmp(name, "") != 0)
return -EINVAL;
diff --git a/fs/9p/xattr_security.c b/fs/9p/xattr_security.c
index df692f9..242c1f8 100644
--- a/fs/9p/xattr_security.c
+++ b/fs/9p/xattr_security.c
@@ -47,8 +47,9 @@ static int v9fs_xattr_security_get(struct dentry *dentry, 
struct inode *inode,
return retval;
 }
 
-static int v9fs_xattr_security_set(struct dentry *dentry, const char *name,
-   const void *value, size_t size, int flags, int type)
+static int v9fs_xattr_security_set(struct dentry *dentry, struct inode *inode,
+  const char *name, const void *value,
+  size_t size, int flags, int type)
 {
int retval;
char *full_name;
diff --git a/fs/9p/xattr_trusted.c b/fs/9p/xattr_trusted.c
index acfadcf..a1fe7d9 100644
--- a/fs/9p/xattr_trusted.c
+++ b/fs/9p/xattr_trusted.c
@@ -47,8 +47,9 @@ static int v9fs_xattr_trusted_get(struct dentry *dentry, 
struct inode *inode,
return retval;
 }
 
-static int v9fs_xattr_trusted_set(struct dentry *dentry, const char *name,
-   const void *value, size_t size, int flags, int type)
+static int v9fs_xattr_trusted_set(struct dentry *dentry, struct inode *inode,
+ const char *name, const void *value,
+ size_t size, int flags, int type)
 {
int retval;
char *full_name;
diff --git a/fs/9p/xattr_user.c b/fs/9p/xattr_user.c
index 9b37675..7a34aca 100644
--- a/fs/9p/xattr_user.c
+++ b/fs/9p/xattr_user.c
@@ -47,8 +47,9 @@ static int v9fs_xattr_user_get(struct dentry *dentry, struct 
inode *inode,
return retval;
 }
 
-static int v9fs_xattr_user_set(struct dentry *dentry, const char *name,
-   const void *value, size_t size, int flags, int type)
+static int v9fs_xattr_user_set(struct dentry *dentry, struct inode *inode,
+  const char *name, const void *value,
+  size_t size, int flags, int type)
 {
int retval;
char *full_name;
diff --git a/fs/ext2/xattr_security.c b/fs/ext2/xattr_security.c
index 1d53da4..3ece525 100644
--- a/fs/ext2/xattr_security.c
+++ b/fs/ext2/xattr_security.c
@@ -33,12 +33,13 @@ ext2_xattr_security_get(struct dentry *unused, struct inode 
*inode,
 }
 
 static int
-ext2_xattr_security_set(struct dentry *dentry, const char *name,
-   const void 

[PATCH 3.18.y 2/5] ->getxattr(): pass dentry and inode as separate arguments

[Seung-Woo Kim]

From: Al Viro 

commit ce23e640133484eebc20ca7b7668388213e11327 upstream.

Signed-off-by: Al Viro 

[sw0312.kim: backport to 3.18]
Signed-off-by: Seung-Woo Kim 
---
 Documentation/filesystems/porting  |6 +
 .../staging/lustre/lustre/llite/llite_internal.h   |4 +-
 drivers/staging/lustre/lustre/llite/xattr.c|6 +---
 fs/bad_inode.c |4 +-
 fs/btrfs/xattr.c   |8 +++---
 fs/btrfs/xattr.h   |4 +-
 fs/ceph/super.h|3 +-
 fs/ceph/xattr.c|8 +++---
 fs/cifs/cifsfs.h   |2 +-
 fs/cifs/xattr.c|   10 
 fs/ecryptfs/crypto.c   |5 +++-
 fs/ecryptfs/ecryptfs_kernel.h  |4 +-
 fs/ecryptfs/inode.c|   23 ++-
 fs/ecryptfs/mmap.c |3 +-
 fs/fuse/dir.c  |5 +--
 fs/gfs2/inode.c|9 +++
 fs/hfs/attr.c  |5 +--
 fs/hfs/hfs_fs.h|4 +-
 fs/jfs/jfs_xattr.h |2 +-
 fs/jfs/xattr.c |8 +++---
 fs/kernfs/inode.c  |6 ++--
 fs/kernfs/kernfs-internal.h|4 +-
 fs/overlayfs/inode.c   |4 +-
 fs/overlayfs/overlayfs.h   |4 +-
 fs/overlayfs/super.c   |2 +-
 fs/reiserfs/xattr.c|8 +++---
 fs/reiserfs/xattr.h|4 +-
 fs/ubifs/ubifs.h   |4 +-
 fs/ubifs/xattr.c   |6 ++--
 fs/xattr.c |   13 ++-
 include/linux/fs.h |3 +-
 include/linux/xattr.h  |2 +-
 mm/shmem.c |8 +++---
 net/socket.c   |2 +-
 security/commoncap.c   |6 ++--
 security/integrity/evm/evm_main.c  |2 +-
 security/selinux/hooks.c   |9 ---
 security/smack/smack_lsm.c |4 +-
 38 files changed, 112 insertions(+), 102 deletions(-)

diff --git a/Documentation/filesystems/porting 
b/Documentation/filesystems/porting
index 0f3a139..daf9acd 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -463,3 +463,9 @@ in your dentry operations instead.
of the in-tree instances did).  inode_hash_lock is still held,
of course, so they are still serialized wrt removal from inode hash,
as well as wrt set() callback of iget5_locked().
+--
+[mandatory]
+   ->getxattr() and xattr_handler.get() get dentry and inode passed 
separately.
+   dentry might be yet to be attached to inode, so do _not_ use its 
->d_inode
+   in the instances.  Rationale: !@#!@# security_d_instantiate() needs to 
be
+   called before we attach dentry to inode.
diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h 
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index 36aa0fd..442fe5b 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -1070,8 +1070,8 @@ static inline __u64 ll_file_maxbytes(struct inode *inode)
 /* llite/xattr.c */
 int ll_setxattr(struct dentry *dentry, const char *name,
const void *value, size_t size, int flags);
-ssize_t ll_getxattr(struct dentry *dentry, const char *name,
-   void *buffer, size_t size);
+ssize_t ll_getxattr(struct dentry *dentry, struct inode *inode,
+   const char *name, void *buffer, size_t size);
 ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size);
 int ll_removexattr(struct dentry *dentry, const char *name);
 
diff --git a/drivers/staging/lustre/lustre/llite/xattr.c 
b/drivers/staging/lustre/lustre/llite/xattr.c
index 252a619..fc4b95d3 100644
--- a/drivers/staging/lustre/lustre/llite/xattr.c
+++ b/drivers/staging/lustre/lustre/llite/xattr.c
@@ -455,11 +455,9 @@ out:
return rc;
 }
 
-ssize_t ll_getxattr(struct dentry *dentry, const char *name,
-   void *buffer, size_t size)
+ssize_t ll_getxattr(struct dentry *dentry, struct inode *inode,
+   const char *name, void *buffer, size_t size)
 {
-   struct inode *inode = dentry->d_inode;
-
LASSERT(inode);
LASSERT(name);
 
diff --git a/fs/bad_inode.c b/fs/bad_inode.c
index afd2b44..336c284 100644
--- 

[PATCH 3.18.y 5/5] switch ->setxattr() to passing dentry and inode separately

[Seung-Woo Kim]

From: Al Viro 

smack ->d_instantiate() uses ->setxattr(), so to be able to call it before
we'd hashed the new dentry and attached it to inode, we need ->setxattr()
instances getting the inode as an explicit argument rather than obtaining
it from dentry.

Similar change for ->getxattr() had been done in commit ce23e64.  Unlike
->getxattr() (which is used by both selinux and smack instances of
->d_instantiate()) ->setxattr() is used only by smack one and unfortunately
it got missed back then.

Reported-by: Seung-Woo Kim 
Tested-by: Casey Schaufler 
Signed-off-by: Al Viro 

[sw0312.kim: backport to 3.18]
Signed-off-by: Seung-Woo Kim 
---
It is not clear, a26feccaba29 ("ceph: Get rid of d_find_alias in ceph_set_acl")
is required backport for ceph or not.
---
 Documentation/filesystems/porting  |7 +++
 .../staging/lustre/lustre/llite/llite_internal.h   |4 ++--
 drivers/staging/lustre/lustre/llite/xattr.c|6 ++
 fs/bad_inode.c |4 ++--
 fs/btrfs/xattr.c   |   12 +++-
 fs/btrfs/xattr.h   |5 +++--
 fs/ceph/super.h|4 ++--
 fs/ceph/xattr.c|7 ---
 fs/cifs/cifsfs.h   |4 ++--
 fs/cifs/xattr.c|   13 +++--
 fs/ecryptfs/crypto.c   |9 +
 fs/ecryptfs/ecryptfs_kernel.h  |4 ++--
 fs/ecryptfs/inode.c|7 ---
 fs/ecryptfs/mmap.c |3 ++-
 fs/fuse/dir.c  |6 +++---
 fs/gfs2/inode.c|9 +
 fs/hfs/attr.c  |6 +++---
 fs/hfs/hfs_fs.h|2 +-
 fs/jfs/jfs_xattr.h |4 ++--
 fs/jfs/xattr.c |   10 +-
 fs/kernfs/inode.c  |   11 ++-
 fs/kernfs/kernfs-internal.h|3 ++-
 fs/overlayfs/inode.c   |5 +++--
 fs/overlayfs/overlayfs.h   |5 +++--
 fs/reiserfs/xattr.c|8 
 fs/reiserfs/xattr.h|5 +++--
 fs/ubifs/ubifs.h   |2 +-
 fs/ubifs/xattr.c   |4 ++--
 fs/xattr.c |9 +
 include/linux/fs.h |3 ++-
 include/linux/xattr.h  |3 ++-
 mm/shmem.c |   10 ++
 security/smack/smack_lsm.c |2 +-
 33 files changed, 110 insertions(+), 86 deletions(-)

diff --git a/Documentation/filesystems/porting 
b/Documentation/filesystems/porting
index daf9acd..51bdd4a 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -469,3 +469,10 @@ in your dentry operations instead.
dentry might be yet to be attached to inode, so do _not_ use its 
->d_inode
in the instances.  Rationale: !@#!@# security_d_instantiate() needs to 
be
called before we attach dentry to inode.
+--
+[mandatory]
+   ->setxattr() and xattr_handler.set() get dentry and inode passed 
separately.
+   dentry might be yet to be attached to inode, so do _not_ use its 
->d_inode
+   in the instances.  Rationale: !@#!@# security_d_instantiate() needs to 
be
+   called before we attach dentry to inode and !@#!@##!@$!$#!@#$!@$!@$ 
smack
+   ->d_instantiate() uses not just ->getxattr() but ->setxattr() as well.
diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h 
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index 442fe5b..d7ac9bc 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -1068,8 +1068,8 @@ static inline __u64 ll_file_maxbytes(struct inode *inode)
 }
 
 /* llite/xattr.c */
-int ll_setxattr(struct dentry *dentry, const char *name,
-   const void *value, size_t size, int flags);
+int ll_setxattr(struct dentry *dentry, struct inode *inode,
+   const char *name, const void *value, size_t size, int flags);
 ssize_t ll_getxattr(struct dentry *dentry, struct inode *inode,
const char *name, void *buffer, size_t size);
 ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size);
diff --git a/drivers/staging/lustre/lustre/llite/xattr.c 
b/drivers/staging/lustre/lustre/llite/xattr.c
index fc4b95d3..3edbbd2 100644
--- a/drivers/staging/lustre/lustre/llite/xattr.c
+++ b/drivers/staging/lustre/lustre/llite/xattr.c
@@ -212,11 +212,9 @@ int 

[PATCH 3.18.y 3/5] security_d_instantiate(): move to the point prior to attaching dentry to inode

[Seung-Woo Kim]

From: Al Viro 

commit b96809173e94ea2fa8c19c2e40e8545a1821bf57 upstream.

Signed-off-by: Al Viro 

[sw0312.kim: backport to 3.18]
Signed-off-by: Seung-Woo Kim 
---
 fs/dcache.c |   18 +++---
 1 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index a34d401..6a4290a 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1729,12 +1729,12 @@ static void __d_instantiate(struct dentry *dentry, 
struct inode *inode)
 void d_instantiate(struct dentry *entry, struct inode * inode)
 {
BUG_ON(!hlist_unhashed(>d_u.d_alias));
+   security_d_instantiate(entry, inode);
if (inode)
spin_lock(>i_lock);
__d_instantiate(entry, inode);
if (inode)
spin_unlock(>i_lock);
-   security_d_instantiate(entry, inode);
 }
 EXPORT_SYMBOL(d_instantiate);
 
@@ -1795,16 +1795,15 @@ struct dentry *d_instantiate_unique(struct dentry 
*entry, struct inode *inode)
 
BUG_ON(!hlist_unhashed(>d_u.d_alias));
 
+   security_d_instantiate(entry, inode);
if (inode)
spin_lock(>i_lock);
result = __d_instantiate_unique(entry, inode);
if (inode)
spin_unlock(>i_lock);
 
-   if (!result) {
-   security_d_instantiate(entry, inode);
+   if (!result)
return NULL;
-   }
 
BUG_ON(!d_unhashed(result));
iput(inode);
@@ -1826,6 +1825,7 @@ int d_instantiate_no_diralias(struct dentry *entry, 
struct inode *inode)
 {
BUG_ON(!hlist_unhashed(>d_u.d_alias));
 
+   security_d_instantiate(entry, inode);
spin_lock(>i_lock);
if (S_ISDIR(inode->i_mode) && !hlist_empty(>i_dentry)) {
spin_unlock(>i_lock);
@@ -1834,7 +1834,6 @@ int d_instantiate_no_diralias(struct dentry *entry, 
struct inode *inode)
}
__d_instantiate(entry, inode);
spin_unlock(>i_lock);
-   security_d_instantiate(entry, inode);
 
return 0;
 }
@@ -1930,6 +1929,7 @@ static struct dentry *__d_obtain_alias(struct inode 
*inode, int disconnected)
goto out_iput;
}
 
+   security_d_instantiate(tmp, inode);
spin_lock(>i_lock);
res = __d_find_any_alias(inode);
if (res) {
@@ -1953,13 +1953,10 @@ static struct dentry *__d_obtain_alias(struct inode 
*inode, int disconnected)
hlist_bl_unlock(>d_sb->s_anon);
spin_unlock(>d_lock);
spin_unlock(>i_lock);
-   security_d_instantiate(tmp, inode);
 
return tmp;
 
  out_iput:
-   if (res && !IS_ERR(res))
-   security_d_instantiate(res, inode);
iput(inode);
return res;
 }
@@ -2817,6 +2814,7 @@ struct dentry *d_splice_alias(struct inode *inode, struct 
dentry *dentry)
return ERR_CAST(inode);
 
if (inode && S_ISDIR(inode->i_mode)) {
+   security_d_instantiate(dentry, inode);
spin_lock(>i_lock);
new = __d_find_any_alias(inode);
if (new) {
@@ -2836,13 +2834,11 @@ struct dentry *d_splice_alias(struct inode *inode, 
struct dentry *dentry)
__d_move(new, dentry, false);
write_sequnlock(_lock);
spin_unlock(>i_lock);
-   security_d_instantiate(new, inode);
iput(inode);
} else {
/* already taking inode->i_lock, so d_add() by hand */
__d_instantiate(dentry, inode);
spin_unlock(>i_lock);
-   security_d_instantiate(dentry, inode);
d_rehash(dentry);
}
} else {
@@ -2876,6 +2872,7 @@ struct dentry *d_materialise_unique(struct dentry 
*dentry, struct inode *inode)
goto out_nolock;
}
 
+   security_d_instantiate(dentry, inode);
spin_lock(>i_lock);
 
if (S_ISDIR(inode->i_mode)) {
@@ -2927,7 +2924,6 @@ found:
spin_unlock(>i_lock);
 out_nolock:
if (actual == dentry) {
-   security_d_instantiate(dentry, inode);
return NULL;
}
 
-- 
1.7.4.1

Applied "regmap: Add regmap_noinc_read API" to the regmap tree

[Mark Brown]

The patch

   regmap: Add regmap_noinc_read API

has been applied to the regmap tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 74fe7b551f3385fa585d92616c85b3a575b2b2cb Mon Sep 17 00:00:00 2001
From: Crestez Dan Leonard 
Date: Tue, 7 Aug 2018 17:52:17 +0300
Subject: [PATCH] regmap: Add regmap_noinc_read API

The regmap API usually assumes that bulk read operations will read a
range of registers but some I2C/SPI devices have certain registers for
which a such a read operation will return data from an internal FIFO
instead. Add an explicit API to support bulk read without range semantics.

Some linux drivers use regmap_bulk_read or regmap_raw_read for such
registers, for example mpu6050 or bmi150 from IIO. This only happens to
work because when caching is disabled a single regmap read op will map
to a single bus read op (as desired). This breaks if caching is enabled and
reg+1 happens to be a cacheable register.

Without regmap support refactoring a driver to enable regmap caching
requires separate I2C and SPI paths. This is exactly what regmap is
supposed to help avoid.

Suggested-by: Jonathan Cameron 
Signed-off-by: Crestez Dan Leonard 
Signed-off-by: Stefan Popa 
Signed-off-by: Mark Brown 
---
 drivers/base/regmap/internal.h |  3 ++
 drivers/base/regmap/regmap.c   | 79 +-
 include/linux/regmap.h | 19 
 3 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 53785e0e297a..a6bf34d6394e 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -94,10 +94,12 @@ struct regmap {
bool (*readable_reg)(struct device *dev, unsigned int reg);
bool (*volatile_reg)(struct device *dev, unsigned int reg);
bool (*precious_reg)(struct device *dev, unsigned int reg);
+   bool (*readable_noinc_reg)(struct device *dev, unsigned int reg);
const struct regmap_access_table *wr_table;
const struct regmap_access_table *rd_table;
const struct regmap_access_table *volatile_table;
const struct regmap_access_table *precious_table;
+   const struct regmap_access_table *rd_noinc_table;
 
int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
int (*reg_write)(void *context, unsigned int reg, unsigned int val);
@@ -181,6 +183,7 @@ bool regmap_writeable(struct regmap *map, unsigned int reg);
 bool regmap_readable(struct regmap *map, unsigned int reg);
 bool regmap_volatile(struct regmap *map, unsigned int reg);
 bool regmap_precious(struct regmap *map, unsigned int reg);
+bool regmap_readable_noinc(struct regmap *map, unsigned int reg);
 
 int _regmap_write(struct regmap *map, unsigned int reg,
  unsigned int val);
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 3bc84885eb91..0360a90ad6b6 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -168,6 +168,17 @@ bool regmap_precious(struct regmap *map, unsigned int reg)
return false;
 }
 
+bool regmap_readable_noinc(struct regmap *map, unsigned int reg)
+{
+   if (map->readable_noinc_reg)
+   return map->readable_noinc_reg(map->dev, reg);
+
+   if (map->rd_noinc_table)
+   return regmap_check_range_table(map, reg, map->rd_noinc_table);
+
+   return true;
+}
+
 static bool regmap_volatile_range(struct regmap *map, unsigned int reg,
size_t num)
 {
@@ -766,10 +777,12 @@ struct regmap *__regmap_init(struct device *dev,
map->rd_table = config->rd_table;
map->volatile_table = config->volatile_table;
map->precious_table = config->precious_table;
+   map->rd_noinc_table = config->rd_noinc_table;
map->writeable_reg = config->writeable_reg;
map->readable_reg = config->readable_reg;
map->volatile_reg = config->volatile_reg;
map->precious_reg = config->precious_reg;
+   map->readable_noinc_reg = config->readable_noinc_reg;
map->cache_type = config->cache_type;
 
spin_lock_init(>async_lock);
@@ -1285,6 +1298,7 @@ int regmap_reinit_cache(struct regmap *map, const struct 

Re: [PATCH] perf ordered_events: fix crash in free_dup_event()

[Jiri Olsa]

On Wed, Aug 08, 2018 at 02:47:42PM -0700, Stephane Eranian wrote:
> Hi,
> 
> Ok, I found the problem. It still exists upstream , just very tricky to 
> trigger.
> Took me lots of time with gdb + watchpoints to track this down, where
> in fact it was just in front of me.
> 
> From the crashdump:
>   Program received signal SIGSEGV, Segmentation fault.
>   free_dup_event (oe=0x26a39a0, event=0x)
> 
> I was puzzled by the 0x. I tracked down where this
> value was coming from using watchpoints.
> In my case the memory was used before by elfutils to back the struct
> Elf. The -1 in the upper bits came from:
> 
> file_read_elf () at third_party/elfutils/libelf/elf_begin.c:451
> elf->state.elf64.scns.data[cnt].shndx_index = -1;
> 
> And yet the next access to that memory location was in the crash. That
> meant the memory was released by
> elfutils and reused by ordered_events, yet without any initialization.
> But looking at alloc_event(), it was
> not obvious to figure out how a new_event->event could be uninitialized.
> 
> Well, it turns out there is this little hack where the code
> commandeers the first element in the oe->buffer to
> use as a list_head for the oe->to_free freelist. The problem is that
> this entry also gets freed, but its
> event->event field is NEVER initialized. So depending on how the
> memory was previously used, you
> could get a on NULL value and crash in free_dup_event(). This is what
> happened to me. I am glad
> I pursued this further because the bug is still in the upstream
> version. The patch is a one-liner fixing
> the initialization of the event->event = NULL. For the other elements
> in the list, the initialization is
> already done at the end of alloc_event().
> 
> I will send the patch separately.

nice ;-) thanks

jirka

Re: [PATCH v8 21/22] KVM: s390: CPU model support for AP virtualization

[David Hildenbrand]

On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak 
> 
> Introduces a new CPU model feature and two CPU model
> facilities to support AP virtualization for KVM guests.
> 
> CPU model feature:
> 
> The KVM_S390_VM_CPU_FEAT_AP feature indicates that
> AP instructions are available on the guest. This
> feature will be enabled by the kernel only if the AP
> instructions are installed on the linux host. This feature
> must be specifically turned on for the KVM guest from
> userspace to use the VFIO AP device driver for guest
> access to AP devices.
> 
> CPU model facilities:
> 
> 1. AP Query Configuration Information (QCI) facility is installed.
> 
>This is indicated by setting facilities bit 12 for
>the guest. The kernel will not enable this facility
>for the guest if it is not set on the host. This facility
>must not be set by userspace if the KVM_S390_VM_CPU_FEAT_AP
>feature is not installed.

Could it happen on real HW (not frankenstein CPU models), that

!AP, but STFL 12 or 15  are indicated?

> 
>If this facility is not set for the KVM guest, then only
>APQNs with an APQI less than 16 will be used by a Linux
>guest regardless of the matrix configuration for the virtual
>machine. This is a limitation of the Linux AP bus.
> 
> 2. AP Facilities Test facility (APFT) is installed.
> 
>This is indicated by setting facilities bit 15 for
>the guest. The kernel will not enable this facility for
>the guest if it is not set on the host. This facility
>must not be set by userspace if the KVM_S390_VM_CPU_FEAT_AP
>feature is not installed.
> 
>If this facility is not set for the KVM guest, then no
>AP devices will be available to the guest regardless of
>the guest's matrix configuration for the virtual
>machine. This is a limitation of the Linux AP bus.
> 
> Signed-off-by: Tony Krowiak 
> Reviewed-by: Christian Borntraeger 
> Reviewed-by: Halil Pasic 
> Tested-by: Michael Mueller 
> Tested-by: Farhan Ali 
> Signed-off-by: Christian Borntraeger 
> ---
>  arch/s390/kvm/kvm-s390.c |7 +++
>  arch/s390/tools/gen_facilities.c |2 ++
>  2 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 9203f0b..7d4fe9b 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -367,6 +367,13 @@ static void kvm_s390_cpu_feat_init(void)
>  
>   if (MACHINE_HAS_ESOP)
>   allow_cpu_feat(KVM_S390_VM_CPU_FEAT_ESOP);
> +
> + /*
> +  * Check if AP instructions installed on host
> +  */

Make this a one-line comment, please.

> + if (ap_instructions_available() == 0)
> + allow_cpu_feat(KVM_S390_VM_CPU_FEAT_AP);
> +
>   /*
>* We need SIE support, ESOP (PROT_READ protection for gmap_shadow),
>* 64bit SCAO (SCA passthrough) and IDTE (for gmap_shadow unshadowing).
> diff --git a/arch/s390/tools/gen_facilities.c 
> b/arch/s390/tools/gen_facilities.c
> index 90a8c9e..a52290b 100644
> --- a/arch/s390/tools/gen_facilities.c
> +++ b/arch/s390/tools/gen_facilities.c
> @@ -106,6 +106,8 @@ struct facility_def {
>  
>   .name = "FACILITIES_KVM_CPUMODEL",
>   .bits = (int[]){
> + 12, /* AP Query Configuration Information */
> + 15, /* AP Facilities Test */
>   -1  /* END */
>   }
>   },
> 


-- 

Thanks,

David / dhildenb

Re: [PATCH v8 07/22] KVM: s390: refactor crypto initialization

[David Hildenbrand]

On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak 
> 
> This patch refactors the code that initializes and sets up the
> crypto configuration for a guest. The following changes are
> implemented via this patch:
> 
> 1. Prior to the introduction of AP device virtualization, it
>was not necessary to provide guest access to the CRYCB
>unless the MSA extension 3 (MSAX3) facility was installed
>on the host system. With the introduction of AP device
>virtualization, the CRYCB must be made accessible to the
>guest if the AP instructions are installed on the host
>and are to be provided to the guest.
> 
> 2. Introduces a flag indicating AP instructions executed on
>the guest shall be interpreted by the firmware. It is
>initialized to indicate AP instructions are to be
>to be interpreted and is used to set the SIE bit for
>each vcpu during vcpu setup.
> 
> Signed-off-by: Tony Krowiak 
> Reviewed-by: Halil Pasic 
> Acked-by: Christian Borntraeger 
> Tested-by: Michael Mueller 
> Tested-by: Farhan Ali 
> Signed-off-by: Christian Borntraeger 
> ---
>  arch/s390/include/asm/kvm_host.h |3 +
>  arch/s390/include/uapi/asm/kvm.h |1 +
>  arch/s390/kvm/kvm-s390.c |   86 
> --
>  3 files changed, 49 insertions(+), 41 deletions(-)
> 
> diff --git a/arch/s390/include/asm/kvm_host.h 
> b/arch/s390/include/asm/kvm_host.h
> index af39561..0c13f61 100644
> --- a/arch/s390/include/asm/kvm_host.h
> +++ b/arch/s390/include/asm/kvm_host.h
> @@ -187,6 +187,7 @@ struct kvm_s390_sie_block {
>  #define ECA_AIV  0x0020
>  #define ECA_VX   0x0002
>  #define ECA_PROTEXCI 0x2000
> +#define ECA_APIE 0x0008
>  #define ECA_SII  0x0001
>   __u32   eca;/* 0x004c */
>  #define ICPT_INST0x04
> @@ -256,6 +257,7 @@ struct kvm_s390_sie_block {
>   __u8reservede4[4];  /* 0x00e4 */
>   __u64   tecmc;  /* 0x00e8 */
>   __u8reservedf0[12]; /* 0x00f0 */
> +#define CRYCB_FORMAT_MASK 0x0003
>  #define CRYCB_FORMAT1 0x0001
>  #define CRYCB_FORMAT2 0x0003
>   __u32   crycbd; /* 0x00fc */
> @@ -714,6 +716,7 @@ struct kvm_s390_crypto {
>   __u32 crycbd;
>   __u8 aes_kw;
>   __u8 dea_kw;
> + __u8 apie;


This flag is essentially always 1 as far as I can see, so please drop it
for now. (can be introduced when really needed)

>  };
>  
>  #define APCB0_MASK_SIZE 1
> diff --git a/arch/s390/include/uapi/asm/kvm.h 
> b/arch/s390/include/uapi/asm/kvm.h
> index 4cdaa55..a580dec 100644
> --- a/arch/s390/include/uapi/asm/kvm.h
> +++ b/arch/s390/include/uapi/asm/kvm.h
> @@ -130,6 +130,7 @@ struct kvm_s390_vm_cpu_machine {
>  #define KVM_S390_VM_CPU_FEAT_PFMFI   11
>  #define KVM_S390_VM_CPU_FEAT_SIGPIF  12
>  #define KVM_S390_VM_CPU_FEAT_KSS 13
> +#define KVM_S390_VM_CPU_FEAT_AP  14
>  struct kvm_s390_vm_cpu_feat {
>   __u64 feat[16];
>  };
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 19f4f44..f96a443 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "kvm-s390.h"
>  #include "gaccess.h"
>  
> @@ -1881,49 +1882,37 @@ long kvm_arch_vm_ioctl(struct file *filp,
>   return r;
>  }
>  
> -static int kvm_s390_query_ap_config(u8 *config)
> -{
> - u32 fcn_code = 0x0400UL;
> - u32 cc = 0;
> -
> - memset(config, 0, 128);
> - asm volatile(
> - "lgr 0,%1\n"
> - "lgr 2,%2\n"
> - ".long 0xb2af\n"/* PQAP(QCI) */
> - "0: ipm %0\n"
> - "srl %0,28\n"
> - "1:\n"
> - EX_TABLE(0b, 1b)
> - : "+r" (cc)
> - : "r" (fcn_code), "r" (config)
> - : "cc", "0", "2", "memory"
> - );
> -
> - return cc;
> -}
> -
>  static int kvm_s390_apxa_installed(void)
>  {
> - u8 config[128];
> - int cc;
> + struct ap_config_info info;
>  
> - if (test_facility(12)) {
> - cc = kvm_s390_query_ap_config(config);
> -
> - if (cc)
> - pr_err("PQAP(QCI) failed with cc=%d", cc);
> - else
> - return config[0] & 0x40;
> + if (ap_instructions_available() == 0) {
> + if (ap_qci() == 0)
> + return info.apxa;
>   }
>  
>   return 0;
>  }
>  
> +/*
> + * The format of the crypto control block (CRYCB) is specified in the 3 low
> + * order bits of the CRYCB designation (CRYCBD) field as follows:
> + * Format 0: Neither the message security assist extension 3 (MSAX3) nor the
> + *AP extended addressing (APXA) facility are installed.
> + * Format 1: The APXA facility is not installed but the MSAX3 facility is.
> + * Format 2: Both the APXA and MSAX3 facilities are installed
> + */
>  static 

Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping

[Patrick Bellasi]

On 06-Aug 09:50, Randy Dunlap wrote:
> Hi,

Hi Randy,

> On 08/06/2018 09:39 AM, Patrick Bellasi wrote:
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 041f3a022122..1d45a6877d6f 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -583,6 +583,25 @@ config HAVE_UNSTABLE_SCHED_CLOCK
> >  config GENERIC_SCHED_CLOCK
> > bool
> >  
> > +menu "Scheduler features"
> > +
> > +config UCLAMP_TASK
> > +   bool "Enable utilization clamping for RT/FAIR tasks"
> > +   depends on CPU_FREQ_GOV_SCHEDUTIL
> > +   default false
> 
>   default n
> but just omit the line completely since "n" is already the default.


Right, will update for next posting!
Is there a strict rule to omit this line when it's already the
default?
> 
> > +   help
> > + This feature enables the scheduler to track the clamped utilization
> > + of each CPU based on RUNNABLE tasks currently scheduled on that CPU.
> > +
> > + When this option is enabled, the user can specify a min and max CPU
> > +  bandwidth which is allowed for a task.
> > + The max bandwidth allows to clamp the maximum frequency a task can
> > + use, while the min bandwidth allows to define a minimum frequency a
> > +  task will always use.
> 
> Please clean up the indentation above to use one tab + 2 spaces on all lines.

Sure, my bad I did not notice it... although I'm quite sure the patch
passed a checkpatch... will check better next time.

> > +
> > + If in doubt, say N.
> > +
> > +endmenu

Cheers Patrick

-- 
#include 

Patrick Bellasi

Re: [PATCH v3 2/2] tty/serial: atmel: add ISO7816 support

[Richard Genoud]

Hi !

On 07/08/2018 15:00, Ludovic Desroches wrote:
> From: Nicolas Ferre 
> 
> When mode is set in atmel_config_iso7816() we backup last RS232 mode
> for coming back to this mode if requested.
> Also allow setup of T=0 and T=1 parameter and basic support in set_termios
> function as well.
> 
> Signed-off-by: Nicolas Ferre 
> [ludovic.desroc...@microchip.com: rebase, add check on fidi ratio, checkpatch 
> fixes]
> Signed-off-by: Ludovic Desroches 
> ---
>  drivers/tty/serial/atmel_serial.c | 211 
> +++---
>  drivers/tty/serial/atmel_serial.h |   6 +-
>  2 files changed, 201 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/tty/serial/atmel_serial.c 
> b/drivers/tty/serial/atmel_serial.c
> index 8e4428725848..4a7ec44b0ace 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -83,6 +84,11 @@ static void atmel_stop_rx(struct uart_port *port);
>  
>  #define ATMEL_ISR_PASS_LIMIT 256
>  
> +struct atmel_uart_pdata {
> + unsigned intfidi_min;
> + unsigned intfidi_max;
> +};
> +
>  struct atmel_dma_buffer {
>   unsigned char   *buf;
>   dma_addr_t  dma_addr;
> @@ -114,6 +120,7 @@ struct atmel_uart_char {
>   */
>  struct atmel_uart_port {
>   struct uart_portuart;   /* uart */
> + const struct atmel_uart_pdata *pdata;   /* SoC specific parameters */
>   struct clk  *clk;   /* uart clock */
>   int may_wakeup; /* cached value of 
> device_may_wakeup for times we need to disable it */
>   u32 backup_imr; /* IMR saved during suspend */
> @@ -147,6 +154,8 @@ struct atmel_uart_port {
>   struct circ_buf rx_ring;
>  
>   struct mctrl_gpios  *gpios;
> + u32 backup_mode;/* MR saved during iso7816 
> operations */
> + u32 backup_brgr;/* BRGR saved during iso7816 
> operations */
>   unsigned inttx_done_mask;
>   u32 fifo_size;
>   u32 rts_high;
> @@ -192,10 +201,34 @@ static struct console atmel_console;
>  #endif
>  
>  #if defined(CONFIG_OF)
> +static struct atmel_uart_pdata at91rm9200_pdata = {
> + .fidi_min = 1,
> + .fidi_max = 2047,
> +};
> +
> +static struct atmel_uart_pdata at91sam9260_pdata = {
> + .fidi_min = 1,
> + .fidi_max = 2047,
> +};
> +
> +static struct atmel_uart_pdata sama5d3_pdata = {
> + .fidi_min = 3,
> + .fidi_max = 65535,
Are you sure this is for sama5d3 ?
>From the datasheets I have, 65535 is for sama5d4/sama5d2
And also, you'll have to s/atmel,at91sam9260-usart/atmel,sama5d2-usart/g
in sama5d{2,4}.dtsi

But I wonder if it could be detected via ATMEL_US_VERSION instead ?


> +};
> +
>  static const struct of_device_id atmel_serial_dt_ids[] = {
> - { .compatible = "atmel,at91rm9200-usart" },
> - { .compatible = "atmel,at91sam9260-usart" },
> - { /* sentinel */ }
> + {
> + .compatible = "atmel,at91rm9200-usart",
> + .data = _pdata,
> + }, {
> + .compatible = "atmel,at91sam9260-usart",
> + .data = _pdata,
> + }, {
> + .compatible = "atmel,sama5d3-usart",
> + .data = _pdata,
> + }, {
> + /* sentinel */
> + }
>  };
>  #endif
>  
> @@ -362,6 +395,127 @@ static int atmel_config_rs485(struct uart_port *port,
>   return 0;
>  }
>  
> +static unsigned int atmel_calc_cd(struct uart_port *port,
> +   struct serial_iso7816 *iso7816conf)
> +{
> + struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> + unsigned int cd;
> + u64 mck_rate;
> +
> + mck_rate = (u64)clk_get_rate(atmel_port->clk);
> + do_div(mck_rate, iso7816conf->clk);
> + cd = mck_rate;
> + return cd;
> +}
> +
> +static unsigned int atmel_calc_fidi(struct uart_port *port,
> + struct serial_iso7816 *iso7816conf)
> +{
> + u64 fidi = 0;
> +
> + if (iso7816conf->sc_fi && iso7816conf->sc_di) {
> + fidi = (u64)iso7816conf->sc_fi;
> + do_div(fidi, iso7816conf->sc_di);
> + }
> + return (u32)fidi;
> +}
> +
> +/* Enable or disable the iso7816 support */
> +/* Called with interrupts disabled */
> +static int atmel_config_iso7816(struct uart_port *port,
> + struct serial_iso7816 *iso7816conf)
> +{
> + struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> + unsigned int mode;
> + unsigned int cd, fidi;
> + int ret = 0;
> +
> + /* Disable interrupts */
> + atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
> +
> + mode = atmel_uart_readl(port, ATMEL_US_MR);
> +
> + if (iso7816conf->flags & SER_ISO7816_ENABLED) {
> + mode &= ~ATMEL_US_USMODE;
> +
> +  

Re: [PATCH v8 19/22] KVM: s390: Clear Crypto Control Block when using vSIE

[Pierre Morel]

On 09/08/2018 10:10, David Hildenbrand wrote:

On 08.08.2018 16:44, Tony Krowiak wrote:

From: Pierre Morel 

When we clear the Crypto Control Block (CRYCB) used by a guest
level 2, the vSIE shadow CRYCB for guest level 3 must be updated
before the guest uses it.

We achieve this by using the KVM_REQ_VSIE_RESTART synchronous
request for each vCPU belonging to the guest to force the reload
of the shadow CRYCB before rerunning the guest level 3.

Signed-off-by: Pierre Morel 
---
  arch/s390/kvm/kvm-s390.c |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 0d03249..9203f0b 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -1921,6 +1921,9 @@ static void kvm_s390_set_crycb_format(struct kvm *kvm)
  
  void kvm_arch_crypto_clear_masks(struct kvm *kvm)

  {
+   int i;
+   struct kvm_vcpu *vcpu;
+
mutex_lock(>lock);
kvm_s390_vcpu_block_all(kvm);
  
@@ -1929,6 +1932,10 @@ void kvm_arch_crypto_clear_masks(struct kvm *kvm)

memset(>arch.crypto.crycb->apcb1, 0,
   sizeof(kvm->arch.crypto.crycb->apcb1));
  
+	/* recreate the shadow crycb for each vcpu */

+   kvm_for_each_vcpu(i, vcpu, kvm)
+   kvm_s390_sync_request(KVM_REQ_VSIE_RESTART, vcpu);

We have kvm_s390_sync_request_broadcast(), which should boil down to a
one-liner


do you think I should squash this patch with the next one?




+
kvm_s390_vcpu_unblock_all(kvm);
mutex_unlock(>lock);
  }





--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany

Re: [PATCH v3 1/6] i2c: designware: use generic table matching

[Andy Shevchenko]

On Wed, 2018-08-08 at 22:22 +0200, Wolfram Sang wrote:
> On Mon, Aug 06, 2018 at 08:54:07PM +0200, Alexandre Belloni wrote:
> > Switch to device_get_match_data in probe to match the device
> > specific data
> > instead of using the acpi specific function.
> > 
> > Suggested-by: Andy Shevchenko 
> > Signed-off-by: Alexandre Belloni 
> 
> Andy, you happy with this patch?
> 

Yes, yes.
If you need my formal tag, here it is

Acked-by: Andy Shevchenko 

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH] ASoC: adav80x: mark expected switch fall-through

[Mark Brown]

On Wed, Aug 08, 2018 at 02:19:33PM -0500, Gustavo A. R. Silva wrote:

> @@ -648,6 +648,7 @@ static int adav80x_set_pll(struct snd_soc_component 
> *component, int pll_id,
>   pll_ctrl1 |= ADAV80X_PLL_CTRL1_PLLDIV;
>   break;
>   }
> + /* fall through */
>   default:
>   return -EINVAL;
>   }

Are you *positive* this is a deliberate fall through?


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the tip tree

[Joerg Roedel]

Hi Stephen,

On Thu, Aug 09, 2018 at 09:24:20AM +1000, Stephen Rothwell wrote:
> Invalid absolute R_X86_64_32S relocation: __end_rodata_aligned
> /kisskb/src/arch/x86/boot/compressed/Makefile:127: recipe for target 
> 'arch/x86/boot/compressed/vmlinux.relocs' failed
> 
> Caused by commit
> 
>   39d668e04eda ("x86/mm/pti: Make pti_clone_kernel_text() compile on 32 bit")

Thanks for the report! I only built the source with gcc-4.8 and gcc-7.3,
so I didn't catch this earlier. I have a fix now and will send it as a
separate reply in this thread.


Thanks,

Joerg

Re: [PATCH v5 1/4] ACPI / scan: Initialize status to ACPI_STA_DEFAULT

[Wolfram Sang]

> As for the rest of the series I'll wait from comments from Wolfram and
> the other reviewers.

Well, I acked patch 4 now because I like the general approach. I can't
say much about the rest since this is mostly ACPI/FW related.

Thanks Hans, for keeping at it.



signature.asc
Description: PGP signature

[PATCH 2/2] tty: serial: imx: add pinctrl sleep/default mode switch for suspend

[Anson Huang]

On some i.MX SoCs' low power mode, UART iomux settings
may be lost, need to add pinctrl sleep/default mode switch
during suspend/resume to make sure UART iomux settings are
correct after resume.

Signed-off-by: Anson Huang 
---
 drivers/tty/serial/imx.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index a09ccef..c280d43 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2447,6 +2448,8 @@ static int imx_uart_suspend_noirq(struct device *dev)
 
clk_disable(sport->clk_ipg);
 
+   pinctrl_pm_select_sleep_state(dev);
+
return 0;
 }
 
@@ -2455,6 +2458,8 @@ static int imx_uart_resume_noirq(struct device *dev)
struct imx_port *sport = dev_get_drvdata(dev);
int ret;
 
+   pinctrl_pm_select_default_state(dev);
+
ret = clk_enable(sport->clk_ipg);
if (ret)
return ret;
-- 
2.7.4

[PATCH 1/2] tty: serial: imx: add lock for registers save/restore

[Anson Huang]

In noirq suspend/resume stage with no_console_suspend enabled,
.imx_console_write() may be called to print out log_buf
message by .printk(), so there will be race condition between
.imx_console_write() and .serial_imx_save/restore_context(),
need to add lock to protect the registers save/restore operations.

Signed-off-by: Anson Huang 
---
 drivers/tty/serial/imx.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 239c0fa..a09ccef 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2376,9 +2376,12 @@ static int imx_uart_remove(struct platform_device *pdev)
 
 static void imx_uart_restore_context(struct imx_port *sport)
 {
+   unsigned long flags;
+
if (!sport->context_saved)
return;
 
+   spin_lock_irqsave(>port.lock, flags);
imx_uart_writel(sport, sport->saved_reg[4], UFCR);
imx_uart_writel(sport, sport->saved_reg[5], UESC);
imx_uart_writel(sport, sport->saved_reg[6], UTIM);
@@ -2390,11 +2393,15 @@ static void imx_uart_restore_context(struct imx_port 
*sport)
imx_uart_writel(sport, sport->saved_reg[2], UCR3);
imx_uart_writel(sport, sport->saved_reg[3], UCR4);
sport->context_saved = false;
+   spin_unlock_irqrestore(>port.lock, flags);
 }
 
 static void imx_uart_save_context(struct imx_port *sport)
 {
+   unsigned long flags;
+
/* Save necessary regs */
+   spin_lock_irqsave(>port.lock, flags);
sport->saved_reg[0] = imx_uart_readl(sport, UCR1);
sport->saved_reg[1] = imx_uart_readl(sport, UCR2);
sport->saved_reg[2] = imx_uart_readl(sport, UCR3);
@@ -2406,6 +2413,7 @@ static void imx_uart_save_context(struct imx_port *sport)
sport->saved_reg[8] = imx_uart_readl(sport, UBMR);
sport->saved_reg[9] = imx_uart_readl(sport, IMX21_UTS);
sport->context_saved = true;
+   spin_unlock_irqrestore(>port.lock, flags);
 }
 
 static void imx_uart_enable_wakeup(struct imx_port *sport, bool on)
-- 
2.7.4

Re: [PATCH v8 08/22] s390: vfio-ap: base implementation of VFIO AP device driver

[Cornelia Huck]

On Wed,  8 Aug 2018 10:44:18 -0400
Tony Krowiak  wrote:

> diff --git a/drivers/s390/crypto/vfio_ap_drv.c 
> b/drivers/s390/crypto/vfio_ap_drv.c
> new file mode 100644
> index 000..d7e39ad
> --- /dev/null
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * VFIO based AP device driver
> + *
> + * Copyright IBM Corp. 2018
> + *
> + * Author(s): Tony Krowiak 
> + * Halil Pasic 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "vfio_ap_private.h"
> +
> +#define VFIO_AP_ROOT_NAME "vfio_ap"
> +#define VFIO_AP_DEV_TYPE_NAME "ap_matrix"
> +#define VFIO_AP_DEV_NAME "vfio_ap"
> +
> +MODULE_AUTHOR("IBM Corporation");
> +MODULE_DESCRIPTION("VFIO AP device driver, Copyright IBM Corp. 2018");
> +MODULE_LICENSE("GPL v2");
> +
> +static struct ap_driver vfio_ap_drv;
> +
> +static struct device_type vfio_ap_dev_type = {
> + .name = VFIO_AP_DEV_TYPE_NAME,
> +};
> +
> +struct ap_matrix_dev matrix_dev = {
> + /*
> +  * We may add some fops later to implement a more program friendly
> +  * management interface for vfio_ap_mdev devices.
> +  */
> + .misc_dev = {
> + MISC_DYNAMIC_MINOR,
> + VFIO_AP_DEV_NAME,
> + }

Is there any reason why you embed a struct miscdevice and don't just
use it directly?

> +};
> +
> +/* Only type 10 adapters (CEX4 and later) are supported
> + * by the AP matrix device driver
> + */
> +static struct ap_device_id ap_queue_ids[] = {
> + { .dev_type = AP_DEVICE_TYPE_CEX4,
> +   .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
> + { .dev_type = AP_DEVICE_TYPE_CEX5,
> +   .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
> + { .dev_type = AP_DEVICE_TYPE_CEX6,
> +   .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
> + { /* end of sibling */ },
> +};
> +
> +MODULE_DEVICE_TABLE(vfio_ap, ap_queue_ids);
> +
> +static int vfio_ap_queue_dev_probe(struct ap_device *apdev)
> +{
> + return 0;
> +}
> +
> +static void vfio_ap_queue_dev_remove(struct ap_device *apdev)
> +{
> + /* Nothing to do yet */
> +}
> +
> +static int vfio_ap_matrix_dev_create(void)
> +{
> + int ret;
> +
> + ret = misc_register(_dev.misc_dev);
> + if (ret)
> + return ret;
> +
> + to_device(_dev)->type = _ap_dev_type;
> + to_device(_dev)->driver = _ap_drv.driver;

This looks strange. Why would you want to change the driver for a
miscdevice, and that after it already has been registered? This feels
like a miscdevice is not the right choice here.

> +
> + return ret;
> +}
> +
> +static void vfio_ap_matrix_dev_destroy(void)
> +{
> + misc_deregister(_dev.misc_dev);
> +}
> +
> +int __init vfio_ap_init(void)
> +{
> + int ret;
> +
> + ret = vfio_ap_matrix_dev_create();
> + if (ret)
> + return ret;
> +
> + memset(_ap_drv, 0, sizeof(vfio_ap_drv));
> + vfio_ap_drv.probe = vfio_ap_queue_dev_probe;
> + vfio_ap_drv.remove = vfio_ap_queue_dev_remove;
> + vfio_ap_drv.ids = ap_queue_ids;
> +
> + ret = ap_driver_register(_ap_drv, THIS_MODULE, VFIO_AP_DRV_NAME);
> + if (ret) {
> + vfio_ap_matrix_dev_destroy();
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +void __exit vfio_ap_exit(void)
> +{
> + ap_driver_unregister(_ap_drv);
> + vfio_ap_matrix_dev_destroy();
> +}
> +
> +module_init(vfio_ap_init);
> +module_exit(vfio_ap_exit);
> diff --git a/drivers/s390/crypto/vfio_ap_private.h 
> b/drivers/s390/crypto/vfio_ap_private.h
> new file mode 100644
> index 000..02c878c
> --- /dev/null
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Private data and functions for adjunct processor VFIO matrix driver.
> + *
> + * Copyright IBM Corp. 2018
> + */
> +
> +#ifndef _VFIO_AP_PRIVATE_H_
> +#define _VFIO_AP_PRIVATE_H_
> +
> +#include 
> +#include 
> +
> +#include "ap_bus.h"
> +
> +#define VFIO_AP_MODULE_NAME "vfio_ap"
> +#define VFIO_AP_DRV_NAME "vfio_ap"
> +
> +struct ap_matrix_dev {
> + struct miscdevice misc_dev;
> +};
> +
> +extern struct ap_matrix_dev matrix_dev;
> +
> +static inline struct device *to_device(struct ap_matrix_dev *matrix_dev)
> +{
> + return matrix_dev->misc_dev.this_device;
> +}

Even if you keep it as a miscdevice, I don't like that function,
especially the naming. Frankly, I'd simply drop it.

> +
> +#endif /* _VFIO_AP_PRIVATE_H_ */