[RFC] mm: change HIGHMEM_ZONE macro definition

[yalin wang]

Change HIGHMEM_ZONE to be the same as DMA_ZONE macro.

Signed-off-by: yalin wang 
---
 include/linux/vm_event_item.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index 2b1cef8..b3bd7c7 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -14,12 +14,12 @@
 #endif
 
 #ifdef CONFIG_HIGHMEM
-#define HIGHMEM_ZONE(xx) , xx##_HIGH
+#define HIGHMEM_ZONE(xx) xx##_HIGH,
 #else
 #define HIGHMEM_ZONE(xx)
 #endif
 
-#define FOR_ALL_ZONES(xx) DMA_ZONE(xx) DMA32_ZONE(xx) xx##_NORMAL 
HIGHMEM_ZONE(xx) , xx##_MOVABLE
+#define FOR_ALL_ZONES(xx) DMA_ZONE(xx) DMA32_ZONE(xx) xx##_NORMAL, 
HIGHMEM_ZONE(xx) xx##_MOVABLE
 
 enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
FOR_ALL_ZONES(PGALLOC),
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [f2fs] 15bec0ff5a: -7.5% fsmark.files_per_sec

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 15bec0ff5a9ba6d203178fa8772259df6207942a ("f2fs: do not skip dentry 
block writes")


=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/iterations/nr_threads/disk/fs/filesize/test_size/sync_method/nr_directories/nr_files_per_directory:
  
nhm4/fsmark/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/1x/32t/1HDD/f2fs/16MB/60G/NoSync/16d/256fpd

commit: 
  1583667acb21aba71a8ba16a5f1596bba1cdbbfa
  15bec0ff5a9ba6d203178fa8772259df6207942a

1583667acb21aba7 15bec0ff5a9ba6d203178fa877 
 -- 
 %stddev %change %stddev
 \  |\  
  9.60 ±  0%  -7.5%   8.88 ±  2%  fsmark.files_per_sec
 25828 ± 14% +43.3%  37001 ±  9%  
fsmark.time.involuntary_context_switches
346865 ±  1%  +5.1% 364446 ±  2%  
fsmark.time.voluntary_context_switches
149762 ±  1% -10.8% 133532 ±  1%  meminfo.Writeback
 25828 ± 14% +43.3%  37001 ±  9%  time.involuntary_context_switches
 10567 ±  0%  -1.4%  10423 ±  0%  vmstat.system.in
 35272 ±  1% +13.7%  40088 ±  2%  softirqs.BLOCK
 55788 ±  2%  -9.2%  50649 ±  2%  softirqs.RCU
 86.40 ±  0%  +2.9%  88.90 ±  0%  turbostat.Avg_MHz
 15.04 ±  4% +51.2%  22.74 ±  7%  turbostat.CPU%c6
  95420434 ±  2% +11.1%   1.06e+08 ±  3%  cpuidle.C1-NHM.time
  76306793 ±  3% -25.7%   56703791 ±  6%  cpuidle.C1E-NHM.time
136043 ±  3% +10.9% 150901 ±  1%  cpuidle.C6-NHM.usage
 85.60 ± 40%+149.5% 213.60 ± 32%  proc-vmstat.allocstall
761.80 ±114%   +1601.0%  12958 ± 32%  
proc-vmstat.nr_vmscan_immediate_reclaim
 37430 ±  1% -10.8%  33381 ±  1%  proc-vmstat.nr_writeback
  4375 ±  2% +45.5%   6367 ± 10%  proc-vmstat.pgactivate
307.90 ±138%   +4385.4%  13810 ± 25%  proc-vmstat.pgrotated
 11195 ± 43%+150.1%  27994 ± 34%  proc-vmstat.pgsteal_direct_dma32
274804 ±  7% -13.2% 238436 ±  6%  
sched_debug.cfs_rq[1]:/.min_vruntime
  2498 ±  9% +44.4%   3607 ±  5%  sched_debug.cfs_rq[4]:/.exec_clock
  2769 ±  7% +39.7%   3869 ± 16%  sched_debug.cfs_rq[5]:/.exec_clock
  2667 ± 12% +40.3%   3741 ±  6%  sched_debug.cfs_rq[6]:/.exec_clock
  2631 ±  9% +43.1%   3765 ±  7%  sched_debug.cfs_rq[7]:/.exec_clock
-95.80 ±-32% +95.2%-187.00 ±-30%  
sched_debug.cpu#0.nr_uninterruptible
 11444 ±  7% +57.4%  18012 ± 46%  sched_debug.cpu#5.nr_load_updates
 43.30 ± 29%+228.2% 142.10 ± 27%  
sched_debug.cpu#5.nr_uninterruptible
  9204 ± 10%   +3829.2% 361677 ±193%  sched_debug.cpu#5.ttwu_local
  0.00 ± -1%  +Inf% 726873 ± 91%  
latency_stats.avg.get_request.blk_queue_bio.generic_make_request.submit_bio.__submit_merged_bio.[f2fs].f2fs_submit_merged_bio.[f2fs].ra_meta_pages.[f2fs].build_free_nids.[f2fs].alloc_nid.[f2fs].f2fs_new_inode.[f2fs].f2fs_create.[f2fs].vfs_create
  0.00 ± -1%  +Inf% 957001 ± 34%  
latency_stats.avg.get_request.blk_queue_bio.generic_make_request.submit_bio.__submit_merged_bio.[f2fs].f2fs_submit_merged_bio.[f2fs].ra_meta_pages.[f2fs].build_free_nids.[f2fs].alloc_nid.[f2fs].get_dnode_of_data.[f2fs].f2fs_reserve_block.[f2fs].f2fs_get_block.[f2fs]
  0.00 ± -1%  +Inf% 600712 ±106%  
latency_stats.avg.get_request.blk_queue_bio.generic_make_request.submit_bio.f2fs_submit_page_bio.[f2fs].get_read_data_page.[f2fs].find_data_page.[f2fs].f2fs_find_entry.[f2fs].f2fs_lookup.[f2fs].lookup_real.path_openat.do_filp_open
  0.00 ± -1%  +Inf%  60887 ± 77%  
latency_stats.avg.wait_iff_congested.shrink_inactive_list.shrink_lruvec.shrink_zone.do_try_to_free_pages.try_to_free_pages.__alloc_pages_nodemask.alloc_pages_current.__page_cache_alloc.pagecache_get_page.grab_cache_page_write_begin.f2fs_write_begin.[f2fs]
 83681 ± 43%+128.1% 190851 ± 70%  
latency_stats.avg.wait_on_page_bit.f2fs_wait_on_page_writeback.[f2fs].f2fs_wait_on_page_writeback.[f2fs].get_dnode_of_data.[f2fs].f2fs_reserve_block.[f2fs].f2fs_get_block.[f2fs].f2fs_write_begin.[f2fs].generic_perform_write.__generic_file_write_iter.generic_file_write_iter.f2fs_file_write_iter.[f2fs].__vfs_write
  0.00 ± -1%  +Inf% 339404 ±117%  
latency_stats.avg.wait_on_page_bit.find_data_page.[f2fs].f2fs_find_entry.[f2fs].f2fs_lookup.[f2fs].lookup_real.path_openat.do_filp_open.do_sys_open.SyS_open.entry_SYSCALL_64_fastpath
  0.00 ± -1%  +Inf% 765971 ± 90%  
latency_stats.max.get_request.blk_queue_bio.generic_make_request.submit_bio.__submit_merged_bio.[f2fs].f2fs_submit_merged_bio.[f2fs].ra_meta_pages.[f2fs].build_free_nids.[f2fs].alloc_nid.[f2fs].f2fs_new_inode.[f2fs].f2fs_create.[f2fs].vfs_create

[PATCH 4/5] thermal: exynos: Remove unneeded semicolon

[Krzysztof Kozlowski]

Remove semicolons after switch statement.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/thermal/samsung/exynos_tmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index eac6aebf82f3..1af7ea8dda71 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -548,7 +548,7 @@ static int exynos5433_tmu_initialize(struct platform_device 
*pdev)
default:
pdata->cal_type = TYPE_ONE_POINT_TRIMMING;
break;
-   };
+   }
 
dev_info(>dev, "Calibration type is %d-point calibration\n",
cal_type ?  2 : 1);
@@ -1356,7 +1356,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
break;
default:
break;
-   };
+   }
 
/*
 * data->tzd must be registered before calling exynos_tmu_initialize(),
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] thermal: exynos: Fix first temperature read after registering sensor

[Krzysztof Kozlowski]

Thermal core could not read the temperature after registering the
thermal sensor with thermal_zone_of_sensor_register() because the driver
was not yet initialized.

The call trace looked like:
exynos_tmu_probe()
thermal_zone_of_sensor_register()
of_thermal_set_mode()
thermal_zone_device_update()
exynos_get_temp()
if (!data->tmu_read) return -EINVAL;
exynos_map_dt_data()
data->tmu_read = ...

This produced an error in dmesg:
thermal thermal_zone0: failed to read out thermal zone (-22)

Register the thermal_zone_device later, after parsing Device Tree and
enabling necessary clocks, but before calling exynos_tmu_initialize()
which uses the registered thermal_zone_device.

Signed-off-by: Krzysztof Kozlowski 
Fixes: 3b6a1a805f34 ("thermal: samsung: core: Exynos TMU rework to use device 
tree for configuration")
---
 drivers/thermal/samsung/exynos_tmu.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 23f4320f8ef7..bc71a61f0c4a 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1289,13 +1289,6 @@ static int exynos_tmu_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
mutex_init(>lock);
 
-   data->tzd = thermal_zone_of_sensor_register(>dev, 0, data,
-   _sensor_ops);
-   if (IS_ERR(data->tzd)) {
-   pr_err("thermal: tz: %p ERROR\n", data->tzd);
-   return PTR_ERR(data->tzd);
-   }
-
/*
 * Try enabling the regulator if found
 * TODO: Add regulator as an SOC feature, so that regulator enable
@@ -1365,21 +1358,36 @@ static int exynos_tmu_probe(struct platform_device 
*pdev)
break;
};
 
+   /*
+* data->tzd must be registered before calling exynos_tmu_initialize(),
+* requesting irq and calling exynos_tmu_control().
+*/
+   data->tzd = thermal_zone_of_sensor_register(>dev, 0, data,
+   _sensor_ops);
+   if (IS_ERR(data->tzd)) {
+   ret = PTR_ERR(data->tzd);
+   dev_err(>dev, "Failed to register sensor: %d\n", ret);
+   goto err_sclk;
+   }
+
ret = exynos_tmu_initialize(pdev);
if (ret) {
dev_err(>dev, "Failed to initialize TMU\n");
-   goto err_sclk;
+   goto err_thermal;
}
 
ret = devm_request_irq(>dev, data->irq, exynos_tmu_irq,
IRQF_TRIGGER_RISING | IRQF_SHARED, dev_name(>dev), data);
if (ret) {
dev_err(>dev, "Failed to request irq: %d\n", data->irq);
-   goto err_sclk;
+   goto err_thermal;
}
 
exynos_tmu_control(pdev, true);
return 0;
+
+err_thermal:
+   thermal_zone_of_sensor_unregister(>dev, data->tzd);
 err_sclk:
clk_disable_unprepare(data->sclk);
 err_clk:
@@ -1390,7 +1398,6 @@ err_clk_sec:
 err_sensor:
if (!IS_ERR_OR_NULL(data->regulator))
regulator_disable(data->regulator);
-   thermal_zone_of_sensor_unregister(>dev, data->tzd);
 
return ret;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] thermal: exynos: Fix unbalanced regulator disable on probe failure

[Krzysztof Kozlowski]

During probe if the regulator could not be enabled, the error exit path
would still disable it. This could lead to unbalanced counter of
regulator enable/disable.

The patch moves code for getting and enabling the regulator from
exynos_map_dt_data() to probe function because it is really not a part
of getting Device Tree properties.

Signed-off-by: Krzysztof Kozlowski 
Fixes: 5f09a5cbd14a ("thermal: exynos: Disable the regulator on probe failure")
Cc: 
---
 drivers/thermal/samsung/exynos_tmu.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 0bae8cc6c23a..23f4320f8ef7 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1168,27 +1168,10 @@ static int exynos_map_dt_data(struct platform_device 
*pdev)
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
struct exynos_tmu_platform_data *pdata;
struct resource res;
-   int ret;
 
if (!data || !pdev->dev.of_node)
return -ENODEV;
 
-   /*
-* Try enabling the regulator if found
-* TODO: Add regulator as an SOC feature, so that regulator enable
-* is a compulsory call.
-*/
-   data->regulator = devm_regulator_get(>dev, "vtmu");
-   if (!IS_ERR(data->regulator)) {
-   ret = regulator_enable(data->regulator);
-   if (ret) {
-   dev_err(>dev, "failed to enable vtmu\n");
-   return ret;
-   }
-   } else {
-   dev_info(>dev, "Regulator node (vtmu) not found\n");
-   }
-
data->id = of_alias_get_id(pdev->dev.of_node, "tmuctrl");
if (data->id < 0)
data->id = 0;
@@ -1312,6 +1295,23 @@ static int exynos_tmu_probe(struct platform_device *pdev)
pr_err("thermal: tz: %p ERROR\n", data->tzd);
return PTR_ERR(data->tzd);
}
+
+   /*
+* Try enabling the regulator if found
+* TODO: Add regulator as an SOC feature, so that regulator enable
+* is a compulsory call.
+*/
+   data->regulator = devm_regulator_get(>dev, "vtmu");
+   if (!IS_ERR(data->regulator)) {
+   ret = regulator_enable(data->regulator);
+   if (ret) {
+   dev_err(>dev, "failed to enable vtmu\n");
+   return ret;
+   }
+   } else {
+   dev_info(>dev, "Regulator node (vtmu) not found\n");
+   }
+
ret = exynos_map_dt_data(pdev);
if (ret)
goto err_sensor;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] thermal: exynos: Directly return 0 instead of using local ret variable

[Krzysztof Kozlowski]

The 'ret' variable in exynos5440_tmu_initialize() is initialized to 0
and returned as is. Replace it with direct return statement. This also
fixes coccinelle warning:
drivers/thermal/samsung/exynos_tmu.c:611:5-8: Unneeded variable: "ret". Return 
"0" on line 654

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/thermal/samsung/exynos_tmu.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 1af7ea8dda71..f340e6edcb49 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -608,7 +608,7 @@ static int exynos5440_tmu_initialize(struct platform_device 
*pdev)
 {
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
unsigned int trim_info = 0, con, rising_threshold;
-   int ret = 0, threshold_code;
+   int threshold_code;
int crit_temp = 0;
 
/*
@@ -651,7 +651,8 @@ static int exynos5440_tmu_initialize(struct platform_device 
*pdev)
/* Clear the PMIN in the common TMU register */
if (!data->id)
writel(0, data->base_second + EXYNOS5440_TMU_PMIN);
-   return ret;
+
+   return 0;
 }
 
 static int exynos7_tmu_initialize(struct platform_device *pdev)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] thermal: exynos: Use IS_ERR() because regulator cannot be NULL

[Krzysztof Kozlowski]

The NULL check in probe's error path is not needed because in that time
the regulator cannot be NULL (regulator_get() returns valid pointer or
ERR_PTR).

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/thermal/samsung/exynos_tmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index bc71a61f0c4a..eac6aebf82f3 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1396,7 +1396,7 @@ err_clk_sec:
if (!IS_ERR(data->clk_sec))
clk_unprepare(data->clk_sec);
 err_sensor:
-   if (!IS_ERR_OR_NULL(data->regulator))
+   if (!IS_ERR(data->regulator))
regulator_disable(data->regulator);
 
return ret;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support

[Avi Kivity]

On 08/10/15 00:05, Michael S. Tsirkin wrote:

On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:

That's what I thought as well, but apparently adding msix support to the
already insecure uio drivers is even worse.

I'm glad you finally agree what these drivers are doing is insecure.

And basically kernel cares about security, no one wants to maintain insecure 
stuff.

So you guys should think harder whether this code makes any sense upstream.


You simply ignore everything I write, cherry-picking the word "insecure" 
as if it makes your point.  That is very frustrating.


The kernel is not secure against root, even in the restricted "will it 
oops" sense.  You can oops it easily, try dd if=/dev/urandom of=/dev/mem 
(or of=/dev/sda for a more satisfying oops).



Getting support from kernel is probably the biggest reason to put code
upstream, and this driver taints kernel unconditionally so you don't get
that.


The biggest reason is that if a driver gets upstream, in a year or two 
it is universally available.




Alternatively, most of the problem you are trying to solve is for
virtualization - and it is is better addressed at the hypervisor level.
There are enough opensource hypervisors out there - work on IOMMU
support there would be time well spent.


It is not.  The problem we are trying to solve, and please consider the 
following as if written in all caps, is that some configurations do not 
have an iommu or cannot use it for performance reasons.


It is good practice to defend against root oopsing the kernel, but in 
some cases it cannot be achieved.  A trivial example is a nommu kernel, 
this is another.  In these cases we can give up on this goal, because it 
is not the only reason for the kernel's existence, there are others.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v6 4/7] PCI/ACPI: Consolidate common PCI host bridge code into ACPI core

[Jiang Liu]

On 2015/10/7 1:47, Bjorn Helgaas wrote:
> Hi Jiang,
> 
> Strictly speaking, this patch by itself doesn't actually "consolidate"
> anything because it only adds acpi_pci_root_create() (which isn't called by
> anything yet), but doesn't remove the original x86 copy.
> 

>> +struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>> + struct acpi_pci_root_ops *ops,
>> + struct acpi_pci_root_info *info,
>> + void *sysdata)
>> +{
>> +int ret, busnum = root->secondary.start;
>> +struct acpi_device *device = root->device;
>> +int node = acpi_get_node(device->handle);
>> +struct pci_bus *bus;
>> +
>> +info->root = root;
>> +info->bridge = device;
>> +info->ops = ops;
>> +INIT_LIST_HEAD(>resources);
>> +snprintf(info->name, sizeof(info->name), "PCI Bus %04x:%02x",
>> + root->segment, busnum);
>> +
>> +if (ops->init_info && ops->init_info(info))
>> +goto out_release_info;
>> +ret = acpi_pci_probe_root_resources(info);
>> +if (ops->prepare_resources)
>> +ret = ops->prepare_resources(info, ret);
>> +if (ret < 0)
>> +goto out_release_info;
>> +else if (ret > 0)
>> +pci_acpi_root_add_resources(info);
> 
> This is unnecessarily complicated: you set "ret", then overwrite it if
> ops->prepare_resources.  By the time you test "ret", it's messy to
> figure out what it means.
> 
> Both ops->prepare_resources() and pci_acpi_root_add_resources()
> should be able to deal with empty resource lists, so can you do the
> following instead?
> 
> ret = acpi_pci_probe_root_resources(info);
> if (ret < 0)
> goto out_release_info;
Hi Bjorn,
Thanks for review:)
The original code is used to handle a special case for x86,
where acpi_pci_probe_root_resources() fails but ops->prepare_resources()
succeeds. For x86, PCI host bridge resources may probed by means
other than ACPI when pci_use_crs is true (AMD and Broadcom hostbridges).
So we can't return failure when acpi_pci_probe_root_resources() fails.
+   ret = acpi_pci_probe_root_resources(info);
+   if (ops->prepare_resources)
+   ret = ops->prepare_resources(info, ret);
+   if (ret < 0)
+   goto out_release_info;

> if (ops->prepare_resources) {
> ret = ops->prepare_resources(info, ret);
> if (ret < 0)
> goto out_release_info;
> }
> pci_acpi_root_add_resources(info);
I will remove the redundant check of (ret > 0) in:
+   else if (ret > 0)
+   pci_acpi_root_add_resources(info);

> 
>> +pci_add_resource(>resources, >secondary);
>> +
>> +bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
>> +  sysdata, >resources);
>> +if (bus) {
> 
> if (!bus)
> goto out_release_info;
> 
> Then it looks like the other error paths above, and you can un-indent
> the following code, which is the normal path:
Will do this.
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 net-next 3/3] bpf: add unprivileged bpf tests

[Alexei Starovoitov]

Add new tests samples/bpf/test_verifier:

unpriv: return pointer
  checks that pointer cannot be returned from the eBPF program

unpriv: add const to pointer
unpriv: add pointer to pointer
unpriv: neg pointer
  checks that pointer arithmetic is disallowed

unpriv: cmp pointer with const
unpriv: cmp pointer with pointer
  checks that comparison of pointers is disallowed
  Only one case allowed 'void *value = bpf_map_lookup_elem(..); if (value == 0) 
...'

unpriv: check that printk is disallowed
  since bpf_trace_printk is not available to unprivileged

unpriv: pass pointer to helper function
  checks that pointers cannot be passed to functions that expect integers
  If function expects a pointer the verifier allows only that type of pointer.
  Like 1st argument of bpf_map_lookup_elem() must be pointer to map.
  (applies to non-root as well)

unpriv: indirectly pass pointer on stack to helper function
  checks that pointer stored into stack cannot be used as part of key
  passed into bpf_map_lookup_elem()

unpriv: mangle pointer on stack 1
unpriv: mangle pointer on stack 2
  checks that writing into stack slot that already contains a pointer
  is disallowed

unpriv: read pointer from stack in small chunks
  checks that < 8 byte read from stack slot that contains a pointer is
  disallowed

unpriv: write pointer into ctx
  checks that storing pointers into skb->fields is disallowed

unpriv: write pointer into map elem value
  checks that storing pointers into element values is disallowed
  For example:
  int bpf_prog(struct __sk_buff *skb)
  {
u32 key = 0;
u64 *value = bpf_map_lookup_elem(, );
if (value)
   *value = (u64) skb;
  }
  will be rejected.

unpriv: partial copy of pointer
  checks that doing 32-bit register mov from register containing
  a pointer is disallowed

unpriv: pass pointer to tail_call
  checks that passing pointer as an index into bpf_tail_call
  is disallowed

unpriv: cmp map pointer with zero
  checks that comparing map pointer with constant is disallowed

unpriv: write into frame pointer
  checks that frame pointer is read-only (applies to root too)

unpriv: cmp of frame pointer
  checks that R10 cannot be using in comparison

unpriv: cmp of stack pointer
  checks that Rx = R10 - imm is ok, but comparing Rx is not

unpriv: obfuscate stack pointer
  checks that Rx = R10 - imm is ok, but Rx -= imm is not

Signed-off-by: Alexei Starovoitov 
---
v1-v2:
- split tests into separate patch
- add tail_call and other tests and explain tests in commit log
---
 samples/bpf/libbpf.h|8 +
 samples/bpf/test_verifier.c |  357 +--
 2 files changed, 355 insertions(+), 10 deletions(-)

diff --git a/samples/bpf/libbpf.h b/samples/bpf/libbpf.h
index 7235e292a03b..b7f63c70b4a2 100644
--- a/samples/bpf/libbpf.h
+++ b/samples/bpf/libbpf.h
@@ -64,6 +64,14 @@ extern char bpf_log_buf[LOG_BUF_SIZE];
.off   = 0, \
.imm   = 0 })
 
+#define BPF_MOV32_REG(DST, SRC)\
+   ((struct bpf_insn) {\
+   .code  = BPF_ALU | BPF_MOV | BPF_X, \
+   .dst_reg = DST, \
+   .src_reg = SRC, \
+   .off   = 0, \
+   .imm   = 0 })
+
 /* Short form of mov, dst_reg = imm32 */
 
 #define BPF_MOV64_IMM(DST, IMM)\
diff --git a/samples/bpf/test_verifier.c b/samples/bpf/test_verifier.c
index ee0f110c9c54..563c507c0a09 100644
--- a/samples/bpf/test_verifier.c
+++ b/samples/bpf/test_verifier.c
@@ -15,20 +15,27 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "libbpf.h"
 
 #define MAX_INSNS 512
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof(*(x)))
 
+#define MAX_FIXUPS 8
+
 struct bpf_test {
const char *descr;
struct bpf_insn insns[MAX_INSNS];
-   int fixup[32];
+   int fixup[MAX_FIXUPS];
+   int prog_array_fixup[MAX_FIXUPS];
const char *errstr;
+   const char *errstr_unpriv;
enum {
+   UNDEF,
ACCEPT,
REJECT
-   } result;
+   } result, result_unpriv;
enum bpf_prog_type prog_type;
 };
 
@@ -96,6 +103,7 @@ static struct bpf_test tests[] = {
BPF_EXIT_INSN(),
},
.errstr = "invalid BPF_LD_IMM insn",
+   .errstr_unpriv = "R1 pointer comparison",
.result = REJECT,
},
{
@@ -109,6 +117,7 @@ static struct bpf_test tests[] = {
BPF_EXIT_INSN(),
},
.errstr = "invalid BPF_LD_IMM insn",
+   .errstr_unpriv = "R1 pointer comparison",
.result = REJECT,
},
{
@@ -219,6 +228,7 @@ static struct bpf_test tests[] = {
 

[PATCH v2 net-next 0/3] bpf: unprivileged

[Alexei Starovoitov]

v1-v2:
- this set logically depends on cb patch
  "bpf: fix cb access in socket filter programs":
  http://patchwork.ozlabs.org/patch/527391/
  which is must have to allow unprivileged programs.
  Thanks Daniel for finding that issue.
- refactored sysctl to be similar to 'modules_disabled'
- dropped bpf_trace_printk
- split tests into separate patch and added more tests
  based on discussion

v1 cover letter:
I think it is time to liberate eBPF from CAP_SYS_ADMIN.
As was discussed when eBPF was first introduced two years ago
the only piece missing in eBPF verifier is 'pointer leak detection'
to make it available to non-root users.
Patch 1 adds this pointer analysis.
The eBPF programs, obviously, need to see and operate on kernel addresses,
but with these extra checks they won't be able to pass these addresses
to user space.
Patch 2 adds accounting of kernel memory used by programs and maps.
It changes behavoir for existing root users, but I think it needs
to be done consistently for both root and non-root, since today
programs and maps are only limited by number of open FDs (RLIMIT_NOFILE).
Patch 2 accounts program's and map's kernel memory as RLIMIT_MEMLOCK.

Unprivileged eBPF is only meaningful for 'socket filter'-like programs.
eBPF programs for tracing and TC classifiers/actions will stay root only.

In parallel the bpf fuzzing effort is ongoing and so far
we've found only one verifier bug and that was already fixed.
The 'constant blinding' pass also being worked on.
It will obfuscate constant-like values that are part of eBPF ISA
to make jit spraying attacks even harder.

Alexei Starovoitov (3):
  bpf: enable non-root eBPF programs
  bpf: charge user for creation of BPF maps and programs
  bpf: add unprivileged bpf tests

 include/linux/bpf.h |5 +
 include/linux/sched.h   |2 +-
 kernel/bpf/arraymap.c   |2 +-
 kernel/bpf/hashtab.c|4 +
 kernel/bpf/syscall.c|   74 -
 kernel/bpf/verifier.c   |  106 +++--
 kernel/sysctl.c |   13 ++
 net/core/filter.c   |3 +-
 samples/bpf/libbpf.h|8 +
 samples/bpf/test_verifier.c |  357 +--
 10 files changed, 547 insertions(+), 27 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 net-next 1/3] bpf: enable non-root eBPF programs

[Alexei Starovoitov]

In order to let unprivileged users load and execute eBPF programs
teach verifier to prevent pointer leaks.
Verifier will prevent
- any arithmetic on pointers
  (except R10+Imm which is used to compute stack addresses)
- comparison of pointers
  (except if (map_value_ptr == 0) ... )
- passing pointers to helper functions
- indirectly passing pointers in stack to helper functions
- returning pointer from bpf program
- storing pointers into ctx or maps

Spill/fill of pointers into stack is allowed, but mangling
of pointers stored in the stack or reading them byte by byte is not.

Within bpf programs the pointers do exist, since programs need to
be able to access maps, pass skb pointer to LD_ABS insns, etc
but programs cannot pass such pointer values to the outside
or obfuscate them.

Only allow BPF_PROG_TYPE_SOCKET_FILTER unprivileged programs,
so that socket filters (tcpdump), af_packet (quic acceleration)
and future kcm can use it.
tracing and tc cls/act program types still require root permissions,
since tracing actually needs to be able to see all kernel pointers
and tc is for root only.

For example, the following unprivileged socket filter program is allowed:
int bpf_prog1(struct __sk_buff *skb)
{
  u32 index = load_byte(skb, ETH_HLEN + offsetof(struct iphdr, protocol));
  u64 *value = bpf_map_lookup_elem(_map, );

  if (value)
*value += skb->len;
  return 0;
}

but the following program is not:
int bpf_prog1(struct __sk_buff *skb)
{
  u32 index = load_byte(skb, ETH_HLEN + offsetof(struct iphdr, protocol));
  u64 *value = bpf_map_lookup_elem(_map, );

  if (value)
*value += (u64) skb;
  return 0;
}
since it would leak the kernel address into the map.

Unprivileged socket filter bpf programs have access to the
following helper functions:
- map lookup/update/delete (but they cannot store kernel pointers into them)
- get_random (it's already exposed to unprivileged user space)
- get_smp_processor_id
- tail_call into another socket filter program
- ktime_get_ns

The feature is controlled by sysctl kernel.unprivileged_bpf_disabled.
This toggle defaults to off (0), but can be set true (1).  Once true,
bpf programs and maps cannot be accessed from unprivileged process,
and the toggle cannot be set back to false.

Signed-off-by: Alexei Starovoitov 
---
v1->v2:
- sysctl_unprivileged_bpf_disabled
- drop bpf_trace_printk
- split tests into separate patch to ease review
---
 include/linux/bpf.h   |2 +
 kernel/bpf/syscall.c  |   11 ++---
 kernel/bpf/verifier.c |  106 -
 kernel/sysctl.c   |   13 ++
 net/core/filter.c |3 +-
 5 files changed, 120 insertions(+), 15 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 19b8a2081f88..e472b06df138 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -167,6 +167,8 @@ void bpf_prog_put_rcu(struct bpf_prog *prog);
 struct bpf_map *bpf_map_get(struct fd f);
 void bpf_map_put(struct bpf_map *map);
 
+extern int sysctl_unprivileged_bpf_disabled;
+
 /* verify correctness of eBPF program */
 int bpf_check(struct bpf_prog **fp, union bpf_attr *attr);
 #else
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 5f35f420c12f..9f824b0f0f5f 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 
+int sysctl_unprivileged_bpf_disabled __read_mostly;
+
 static LIST_HEAD(bpf_map_types);
 
 static struct bpf_map *find_and_alloc_map(union bpf_attr *attr)
@@ -542,6 +544,9 @@ static int bpf_prog_load(union bpf_attr *attr)
attr->kern_version != LINUX_VERSION_CODE)
return -EINVAL;
 
+   if (type != BPF_PROG_TYPE_SOCKET_FILTER && !capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
/* plain bpf_prog allocation */
prog = bpf_prog_alloc(bpf_prog_size(attr->insn_cnt), GFP_USER);
if (!prog)
@@ -597,11 +602,7 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, 
uattr, unsigned int, siz
union bpf_attr attr = {};
int err;
 
-   /* the syscall is limited to root temporarily. This restriction will be
-* lifted when security audit is clean. Note that eBPF+tracing must have
-* this restriction, since it may pass kernel data to user space
-*/
-   if (!capable(CAP_SYS_ADMIN))
+   if (!capable(CAP_SYS_ADMIN) && sysctl_unprivileged_bpf_disabled)
return -EPERM;
 
if (!access_ok(VERIFY_READ, uattr, 1))
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index f8da034c2258..1d6b97be79e1 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -199,6 +199,7 @@ struct verifier_env {
struct verifier_state_list **explored_states; /* search pruning 
optimization */
struct bpf_map *used_maps[MAX_USED_MAPS]; /* array of map's used by 
eBPF program */
u32 used_map_cnt;   /* number of used maps */
+   bool allow_ptr_leaks;
 };
 
 /* verbose verifier prints 

[PATCH v2 net-next 2/3] bpf: charge user for creation of BPF maps and programs

[Alexei Starovoitov]

since eBPF programs and maps use kernel memory consider it 'locked' memory
from user accounting point of view and charge it against RLIMIT_MEMLOCK limit.
This limit is typically set to 64Kbytes by distros, so almost all
bpf+tracing programs would need to increase it, since they use maps,
but kernel charges maximum map size upfront.
For example the hash map of 1024 elements will be charged as 64Kbyte.
It's inconvenient for current users and changes current behavior for root,
but probably worth doing to be consistent root vs non-root.

Similar accounting logic is done by mmap of perf_event.

Signed-off-by: Alexei Starovoitov 
---
The charging is agressive and even basic test_maps, test_verifier are
hitting memlock limit, so alternatively we can drop charging
for cap_sys_admin.
---
 include/linux/bpf.h   |3 +++
 include/linux/sched.h |2 +-
 kernel/bpf/arraymap.c |2 +-
 kernel/bpf/hashtab.c  |4 
 kernel/bpf/syscall.c  |   63 +
 5 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index e472b06df138..e1c869f8e156 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -36,6 +36,8 @@ struct bpf_map {
u32 key_size;
u32 value_size;
u32 max_entries;
+   u32 pages;
+   struct user_struct *user;
const struct bpf_map_ops *ops;
struct work_struct work;
 };
@@ -128,6 +130,7 @@ struct bpf_prog_aux {
const struct bpf_verifier_ops *ops;
struct bpf_map **used_maps;
struct bpf_prog *prog;
+   struct user_struct *user;
union {
struct work_struct work;
struct rcu_head rcu;
diff --git a/include/linux/sched.h b/include/linux/sched.h
index b7b9501b41af..4817df5fffae 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -840,7 +840,7 @@ struct user_struct {
struct hlist_node uidhash_node;
kuid_t uid;
 
-#ifdef CONFIG_PERF_EVENTS
+#if defined(CONFIG_PERF_EVENTS) || defined(CONFIG_BPF_SYSCALL)
atomic_long_t locked_vm;
 #endif
 };
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 2fecc4aed119..f2d9e698c753 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -49,7 +49,7 @@ static struct bpf_map *array_map_alloc(union bpf_attr *attr)
array->map.key_size = attr->key_size;
array->map.value_size = attr->value_size;
array->map.max_entries = attr->max_entries;
-
+   array->map.pages = round_up(array_size, PAGE_SIZE) >> PAGE_SHIFT;
array->elem_size = elem_size;
 
return >map;
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 83c209d9b17a..28592d79502b 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -88,6 +88,10 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
htab->elem_size = sizeof(struct htab_elem) +
  round_up(htab->map.key_size, 8) +
  htab->map.value_size;
+
+   htab->map.pages = round_up(htab->n_buckets * sizeof(struct hlist_head) +
+  htab->elem_size * htab->map.max_entries,
+  PAGE_SIZE) >> PAGE_SHIFT;
return >map;
 
 free_htab:
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 9f824b0f0f5f..43e8afaee329 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -46,11 +46,38 @@ void bpf_register_map_type(struct bpf_map_type_list *tl)
list_add(>list_node, _map_types);
 }
 
+static int bpf_map_charge_memlock(struct bpf_map *map)
+{
+   struct user_struct *user = get_current_user();
+   unsigned long memlock_limit;
+
+   memlock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+
+   atomic_long_add(map->pages, >locked_vm);
+
+   if (atomic_long_read(>locked_vm) > memlock_limit) {
+   atomic_long_sub(map->pages, >locked_vm);
+   free_uid(user);
+   return -EPERM;
+   }
+   map->user = user;
+   return 0;
+}
+
+static void bpf_map_uncharge_memlock(struct bpf_map *map)
+{
+   struct user_struct *user = map->user;
+
+   atomic_long_sub(map->pages, >locked_vm);
+   free_uid(user);
+}
+
 /* called from workqueue */
 static void bpf_map_free_deferred(struct work_struct *work)
 {
struct bpf_map *map = container_of(work, struct bpf_map, work);
 
+   bpf_map_uncharge_memlock(map);
/* implementation dependent freeing */
map->ops->map_free(map);
 }
@@ -110,6 +137,10 @@ static int map_create(union bpf_attr *attr)
 
atomic_set(>refcnt, 1);
 
+   err = bpf_map_charge_memlock(map);
+   if (err)
+   goto free_map;
+
err = anon_inode_getfd("bpf-map", _map_fops, map, O_RDWR | 
O_CLOEXEC);
 
if (err < 0)
@@ -440,11 +471,37 @@ static void free_used_maps(struct bpf_prog_aux *aux)
kfree(aux->used_maps);
 }
 
+static int bpf_prog_charge_memlock(struct bpf_prog 

linux-next: Tree for Oct 8

[Stephen Rothwell]

Hi all,

Changes since 20151007:

Linus' tree gained a build failure for which I applied a fix patch.

I used the h8300 tree from next-20150828 since the current tree has been
rebased onto linux-next again :-(

The battery tree still had its build failure so I used the version from
next-20150925.

The chrome-platform tree gained a build failure, so I used the version
from next-20151007.

The target-updates tree still had its build failure but I used a supplied
merge fix patch instead of the revert.

Non-merge commits (relative to Linus' tree): 5726
 4604 files changed, 235234 insertions(+), 96969 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 and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final
link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 228 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

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 Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (c6fa8e6de3dc Merge tag 'arm64-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Applying: word-at-a-time.h: powerpc: implement define zero_bytemask
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (868e87ccda24 ARM: make RiscPC depend on MMU)
Merging m68k-current/for-linus (95bc06ef049b m68k/defconfig: Update defconfigs 
for v4.3-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (4108efb02daa cxl: Fix number of allocated pages in 
SPA)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (41747509b437 Merge branch 'ovs-ct-fixes')
Merging ipsec/master (4e077237cfb6 xfrm: Fix state threshold configuration from 
userspace)
Merging ipvs/master (6ece90f9a13e netfilter: fix Kconfig dependencies for 
nf_dup_ipv{4,6})
Merging sound-current/for-linus (601d62959d08 Merge tag 'asoc-fix-v4.3-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (1266963170f5 PCI: Prevent out of bounds access 
in numa_node override)
Merging wireless-drivers/master (de28a05ee28e Merge tag 
'iwlwifi-for-kalle-2015-10-05' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (9ffecb102835 Linux 4.3-rc3)
Merging tty.current/tty-linus (0c5562716787 drivers/tty: require read access 
for controlling terminal)
Merging usb.current/usb-linus (72194739f546 usb: Add device quirk for Logitech 
PTZ cameras)
Merging usb-gadget-fixes/fixes (f5f6afa85aa8 usb: renesas_usbhs: Add support 
for R-Car H3)
Merging usb-serial-fixes/usb-linus (19ab6bc5674a USB: option: add ZTE PIDs)
Merging staging.current/staging-linus (b1d562acc78f staging: speakup: fix 
speakup-r regression)
Merging char-misc.current/char-misc-linus (41ada9df7f34 mcb: Fix error handling 
in mcb_pci_probe())
Merging input-current/for-linus (879f2fea8a5a Input: ads7846 - correct the 
value got from SPI)
Merging crypto-current/master (09185e2756a8 hwrng: xgene - fix handling 
platform_get_irq)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa

Re: [RFC PATCH] Use vAPIC when doing IPI for PVHVM guests.

[Juergen Gross]

On 10/07/2015 10:21 PM, Konrad Rzeszutek Wilk wrote:

Hey,

I was running some tools in which we would heavily do rescheduling
of events - and realized to my surprise that the event channels (and
the hypercall) would slow things down. If I used the vAPIC with its
IPI support (so no VMEXIT) I got much much better performance.

Now this is an RFC because:
  1). I hadn't verified from the xentrace  how much less VMEXITS we get.
 But I remember Boris's patches and they gave at least 10%.
 I think this will get the same performance or even better.

  2). I don't know what to do with migration. That is if the guest
 migrates to older hardware it needs to recheck this I presume?


Same problem applies to many other features. In case you want to
migrate to a machine with less features you'd have to mask those
features in the cpuid data of the domain.


  3). Should this be enabled by default? I did get better performance
but that was synthetic.


Having some benchmark results would help to decide this. :-)

I'd be especially interested in checking "no vcpu over-commitment"
and "heavy vcpu over-commitment" scenarios regarding the effect of
the feature.



Thoughts?


I like the idea.


Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] genirq: Move irq_set_vcpu_affinity out of "#ifdef CONFIG_SMP"

[Wu, Feng]

Hi Thomas & Paolo,

> -Original Message-
> From: Jiang Liu [mailto:jiang@linux.intel.com]
> Sent: Saturday, October 03, 2015 5:11 PM
> To: Wu, Feng; t...@linutronix.de; pbonz...@redhat.com
> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] genirq: Move irq_set_vcpu_affinity out of "#ifdef
> CONFIG_SMP"
> 
> On 2015/10/3 16:20, Feng Wu wrote:
> > irq_set_vcpu_affinity() is needed when CONFIG_SMP=n, so move the
> > definition out of "#ifdef CONFIG_SMP"

What is your option about this patch, Thanks a lot!

Thanks,
Feng

> >
> > Suggested-by: Paolo Bonzini 
> > Signed-off-by: Feng Wu 
> 
> Reviewed-by: Jiang Liu 
> 
> > ---
> >  kernel/irq/manage.c | 62
> ++---
> >  1 file changed, 31 insertions(+), 31 deletions(-)
> >
> > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> > index 1c58655..90b378d 100644
> > --- a/kernel/irq/manage.c
> > +++ b/kernel/irq/manage.c
> > @@ -258,37 +258,6 @@ int irq_set_affinity_hint(unsigned int irq, const
> struct cpumask *m)
> >  }
> >  EXPORT_SYMBOL_GPL(irq_set_affinity_hint);
> >
> > -/**
> > - * irq_set_vcpu_affinity - Set vcpu affinity for the interrupt
> > - * @irq: interrupt number to set affinity
> > - * @vcpu_info: vCPU specific data
> > - *
> > - * This function uses the vCPU specific data to set the vCPU
> > - * affinity for an irq. The vCPU specific data is passed from
> > - * outside, such as KVM. One example code path is as below:
> > - * KVM -> IOMMU -> irq_set_vcpu_affinity().
> > - */
> > -int irq_set_vcpu_affinity(unsigned int irq, void *vcpu_info)
> > -{
> > -   unsigned long flags;
> > -   struct irq_desc *desc = irq_get_desc_lock(irq, , 0);
> > -   struct irq_data *data;
> > -   struct irq_chip *chip;
> > -   int ret = -ENOSYS;
> > -
> > -   if (!desc)
> > -   return -EINVAL;
> > -
> > -   data = irq_desc_get_irq_data(desc);
> > -   chip = irq_data_get_irq_chip(data);
> > -   if (chip && chip->irq_set_vcpu_affinity)
> > -   ret = chip->irq_set_vcpu_affinity(data, vcpu_info);
> > -   irq_put_desc_unlock(desc, flags);
> > -
> > -   return ret;
> > -}
> > -EXPORT_SYMBOL_GPL(irq_set_vcpu_affinity);
> > -
> >  static void irq_affinity_notify(struct work_struct *work)
> >  {
> > struct irq_affinity_notify *notify =
> > @@ -424,6 +393,37 @@ setup_affinity(struct irq_desc *desc, struct
> cpumask *mask)
> >  }
> >  #endif
> >
> > +/**
> > + * irq_set_vcpu_affinity - Set vcpu affinity for the interrupt
> > + * @irq: interrupt number to set affinity
> > + * @vcpu_info: vCPU specific data
> > + *
> > + * This function uses the vCPU specific data to set the vCPU
> > + * affinity for an irq. The vCPU specific data is passed from
> > + * outside, such as KVM. One example code path is as below:
> > + * KVM -> IOMMU -> irq_set_vcpu_affinity().
> > + */
> > +int irq_set_vcpu_affinity(unsigned int irq, void *vcpu_info)
> > +{
> > +   unsigned long flags;
> > +   struct irq_desc *desc = irq_get_desc_lock(irq, , 0);
> > +   struct irq_data *data;
> > +   struct irq_chip *chip;
> > +   int ret = -ENOSYS;
> > +
> > +   if (!desc)
> > +   return -EINVAL;
> > +
> > +   data = irq_desc_get_irq_data(desc);
> > +   chip = irq_data_get_irq_chip(data);
> > +   if (chip && chip->irq_set_vcpu_affinity)
> > +   ret = chip->irq_set_vcpu_affinity(data, vcpu_info);
> > +   irq_put_desc_unlock(desc, flags);
> > +
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(irq_set_vcpu_affinity);
> > +
> >  void __disable_irq(struct irq_desc *desc)
> >  {
> > if (!desc->depth++)
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] regmap: change bool to 1 bit variable in struct regmap

[yalin wang]

This patch change some bool variables in struct regmap {  }
to be u8 v : 1 type, so that we can shrink the sizeof of struct regmap.

Signed-off-by: yalin wang 
---
 drivers/base/regmap/internal.h | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 873ddf9..f4a5f7b 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -67,7 +67,6 @@ struct regmap {
void *bus_context;
const char *name;
 
-   bool async;
spinlock_t async_lock;
wait_queue_head_t async_waitq;
struct list_head async_list;
@@ -99,7 +98,16 @@ struct regmap {
int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
int (*reg_write)(void *context, unsigned int reg, unsigned int val);
 
-   bool defer_caching;
+   u8 async : 1,
+   defer_caching : 1,
+   /* if set, remember to free reg_defaults_raw */
+   cache_free : 1,
+   /* if set, the HW registers are known to match map->reg_defaults */
+   no_sync_defaults : 1,
+   /* if set, converts bulk rw to single rw */
+   use_single_rw : 1,
+   /* if set, the device supports multi write mode */
+   can_multi_write : 1;
 
u8 read_flag_mask;
u8 write_flag_mask;
@@ -125,25 +133,16 @@ struct regmap {
u32 cache_only;
/* if set, only the HW is modified not the cache */
u32 cache_bypass;
-   /* if set, remember to free reg_defaults_raw */
-   bool cache_free;
 
struct reg_default *reg_defaults;
const void *reg_defaults_raw;
void *cache;
/* if set, the cache contains newer data than the HW */
u32 cache_dirty;
-   /* if set, the HW registers are known to match map->reg_defaults */
-   bool no_sync_defaults;
 
struct reg_sequence *patch;
int patch_regs;
 
-   /* if set, converts bulk rw to single rw */
-   bool use_single_rw;
-   /* if set, the device supports multi write mode */
-   bool can_multi_write;
-
struct rb_root range_tree;
void *selector_work_buf;/* Scratch buffer used for selector */
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support

[Gleb Natapov]

On Thu, Oct 08, 2015 at 12:05:11AM +0300, Michael S. Tsirkin wrote:
> On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
> > That's what I thought as well, but apparently adding msix support to the
> > already insecure uio drivers is even worse.
> 
> I'm glad you finally agree what these drivers are doing is insecure.
> 
Michael, please stop this meaningless world play. The above is said in
the contexts of a device that is meant to be accessible by regular users
and obviously for that purpose uio is insecure (in its current state btw).
If you give user access to your root block device this device will be
insecure too, so according to your logic block device is insecure?
Pushing the code from uio to vfio means that vfio will have to implement
access policy by itself - allow iommu mode to regular users, but
no-iommu to root only. Implementing policy in the kernel is bad. Well
the alternative is to add /dev/vfio/nommu like you've said, but what
would be the difference between this and uio eludes me.

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -next] mm/vmacache: inline vmacache_valid_mm()

[Davidlohr Bueso]

This function incurs in very hot paths and merely
does a few loads for validity check. Lets inline it,
such that we can save the function call overhead.

Signed-off-by: Davidlohr Bueso 
---
 mm/vmacache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmacache.c b/mm/vmacache.c
index b6e3662..fd09dc9 100644
--- a/mm/vmacache.c
+++ b/mm/vmacache.c
@@ -52,7 +52,7 @@ void vmacache_flush_all(struct mm_struct *mm)
  * Also handle the case where a kernel thread has adopted this mm via use_mm().
  * That kernel thread's vmacache is not applicable to this mm.
  */
-static bool vmacache_valid_mm(struct mm_struct *mm)
+static inline bool vmacache_valid_mm(struct mm_struct *mm)
 {
return current->mm == mm && !(current->flags & PF_KTHREAD);
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-all] [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

[Michael Ellerman]

On Thu, 2015-10-08 at 09:16 +0800, Fengguang Wu wrote:
> On Thu, Oct 08, 2015 at 09:06:03AM +0800, Fengguang Wu wrote:
> > On Thu, Oct 08, 2015 at 11:11:59AM +1100, Michael Ellerman wrote:
> > > On Wed, 2015-10-07 at 21:56 +0800, Fengguang Wu wrote:
> > > > On Tue, Oct 06, 2015 at 02:39:06PM +1100, Michael Ellerman wrote:
> > > > > On Sat, 2015-10-03 at 04:33 +0800, kbuild test robot wrote:
> > > > > > Hi Nishanth,
> > > > > > 
> > > > > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, 
> > > > > > please ignore]
> > > > > > 
> > > > > > config: powerpc-defconfig (attached as .config)
> > > > > > reproduce:
> > > > > > wget 
> > > > > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > > > > >  -O ~/bin/make.cross
> > > > > > chmod +x ~/bin/make.cross
> > > > > > # save the attached .config to linux build tree
> > > > > > make.cross ARCH=powerpc 
> > > > > > 
> > > > > > All error/warnings (new ones prefixed by >>):
> > > > > > 
> > > > > >arch/powerpc/platforms/pseries/iommu.c: In function 
> > > > > > 'iommu_init_early_pSeries':
> > > > > > >> arch/powerpc/platforms/pseries/iommu.c:1433:9: error: 'struct 
> > > > > > >> machdep_calls' has no member named 'dma_get_page_shift'
> > > > > >   ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
> > > > > 
> > > > > It was added in patch 3/5, so I think this error is bogus. Unless 
> > > > > there's a
> > > > > typo I'm missing?
> > > > 
> > > > Yes sorry, the patchset was not detected correctly in your case,
> > > > ending up the patches being tested as individual ones.
> > > > 
> > > > I'll fixup the robot.
> > > 
> > > Thanks.
> > > 
> > > How did the robot decide to build this series in the first place? Does it 
> > > build
> > > everything sent to one of the lists on CC?
> > 
> > Yes, currently the following mailing lists are subscribed.  Patches
> > sent to them will be tested if they can be git-am to RC or linux-next
> > kernels:
> > 
> > kvm
> > linux-acpi
> > linux-bluetooth
> > linux-btrfs
> > linux-embedded
> > linux-ext4
> > linux-fsdevel
> > linux-media
> > linux-mmc
> > linux-nfs
> > linux-omap
> > linux-pci
> > linux-pm
> > linux-raid
> > linux-rdma
> > linux-scsi
> > linux-usb
> > linux-wireless
> > netdev
> > netfilter-devel
> > linux-mm
> > driverdev-devel
> > intel-gfx
> 
> And of course linux-kernel. More lists could be added in future.

So do you mind adding linuxppc-...@lists.ozlabs.org ? :)

It's pretty low traffic compared to lkml.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [PATCH 1/2] ASoC: rockchip: i2s: add 8 channels capture and lrck-mode support

[sugar]

Only the new design support 8 channels capture now, the others support 2 
channels capture. but all of them support 32bits/sample.


On 10/8/2015 11:19, Caleb Crome wrote:

  That will work!  Do all your cortex-a parts support that?

Thanks, Caleb
Sent from my iPhone


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] kselftest: add kselftest-clean rule

[Michael Ellerman]

On Thu, 2015-10-08 at 02:41 +, Wang Long wrote:
> We use
> 
> $make TARGETS="size timers" kselftest
> 
> to build and run selftests. but there is no rule
> for us to clean the kselftest generated files.
> 
> This patch add the rules, for example:
> 
>   $ make TARGETS="size timers" kselftest-clean
> 
> can clean all kselftest generated files.
> 
> Signed-off-by: Wang Long 
> ---
>  Makefile | 4 
>  1 file changed, 4 insertions(+)

Thanks that's much neater.

Acked-by: Michael Ellerman 

cheers



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

[Michael Ellerman]

On Wed, 2015-10-07 at 08:25 -0700, Paul E. McKenney wrote:
> On Wed, Oct 07, 2015 at 02:23:17PM +0100, Will Deacon wrote:
> > Hi Peter,
> > 
> > Thanks for the headache ;)
> > 
> > On Wed, Oct 07, 2015 at 01:19:15PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 07, 2015 at 11:59:28AM +0100, Will Deacon wrote:
> > > > As much as we'd like to live in a world where RELEASE -> ACQUIRE is
> > > > always cheaply ordered and can be used to construct UNLOCK -> LOCK
> > > > definitions with similar guarantees, the grim reality is that this isn't
> > > > even possible on x86 (thanks to Paul for bringing us crashing down to
> > > > Earth).
> > > > 
> > > > This patch handles the issue by introducing a new barrier macro,
> > > > smp_mb__release_acquire, that can be placed between a RELEASE and a
> > > > subsequent ACQUIRE operation in order to upgrade them to a full memory
> > > > barrier. At the moment, it doesn't have any users, so its existence
> > > > serves mainly as a documentation aid.
> > > 
> > > Does we want to go revert 12d560f4ea87 ("rcu,locking: Privatize
> > > smp_mb__after_unlock_lock()") for that same reason?
> > 
> > I don't think we want a straight revert. smp_mb__after_unlock_lock could
> > largely die if PPC strengthened its locks, whereas smp_mb__release_acquire
> > is needed by quite a few architectures.
> 
> Currently, we do need smp_mb__after_unlock_lock() to be after the
> acquisition on PPC -- putting it between the unlock and the lock
> of course doesn't cut it for the cross-thread unlock/lock case.
> 
> I am with Peter -- we do need the benchmark results for PPC.

Urgh, sorry guys. I have been slowly doing some benchmarks, but time is not
plentiful at the moment.

If we do a straight lwsync -> sync conversion for unlock it looks like that
will cost us ~4.2% on Anton's standard context switch benchmark.

So that's not all that nice. But we also don't want to be the only arch that
has the weird lock semantics and has to find all the bugs.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v8 0/2] Enable capsule loader interface for efi firmware updating

[Kweh, Hock Leong]

> -Original Message-
> From: Bryan O'Donoghue [mailto:pure.lo...@nexus-software.ie]
> Sent: Wednesday, October 07, 2015 11:00 PM
> 
> Wilson.
> 
> Same question as at V7. If you aren't supporting the MFH on Galileo then
> what capsule are you using with 0.75 BIOS ? From memory it won't work
> without the MFH included ...
> 
> --
> BOD

As I mentioned before the Quark Security Header patch will not upstream
to mainline and will be carried by Intel. So to test with Quark Platform, I will
apply that patch into my kernel.

Thanks & Regards,
Wilson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 2/2] ARM: multi_v7_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

[Anand Moon]

Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over
USB 3.0.

Signed-off-by: Anand Moon 
Reviewed-by: Krzysztof Kozlowski 

---
Changes: Fixed the commit message thanks to Krzysztof Kozlowski
 Added reviewed by Krzysztof Kozlowski
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 03deb7f..009d714 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -221,6 +221,7 @@ CONFIG_BROADCOM_PHY=y
 CONFIG_ICPLUS_PHY=y
 CONFIG_MICREL_PHY=y
 CONFIG_USB_PEGASUS=y
+CONFIG_USB_RTL8152=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

[Anand Moon]

Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over
USB 3.0.

Signed-off-by: Anand Moon 
Reviewed-by: Krzysztof Kozlowski 

---
Changes: Fixed the commit message thanks to Krzysztof Kozlowski
 Added reviewed by Krzysztof Kozlowski
---
 arch/arm/configs/exynos_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 1ff2bfa..5d1937b 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y
 CONFIG_DM_CRYPT=m
 CONFIG_NETDEVICES=y
 CONFIG_SMSC911X=y
+CONFIG_USB_RTL8152=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arch/powerpc: provide zero_bytemask() for big-endian

[Michael Ellerman]

On Wed, 2015-10-07 at 10:46 -0400, Chris Metcalf wrote:
> For some reason, only the little-endian flavor of
> powerpc provided the zero_bytemask() implementation.

Because previously it was optional unless DCACHE_WORD_ACCESS was enabled.

> Reported-by: Michal Sojka 
> Signed-off-by: Chris Metcalf 
> ---
>  arch/powerpc/include/asm/word-at-a-time.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/word-at-a-time.h 
> b/arch/powerpc/include/asm/word-at-a-time.h
> index 5b3a903adae6..e4396a7d0f7c 100644
> --- a/arch/powerpc/include/asm/word-at-a-time.h
> +++ b/arch/powerpc/include/asm/word-at-a-time.h
> @@ -40,6 +40,11 @@ static inline bool has_zero(unsigned long val, unsigned 
> long *data, const struct
>   return (val + c->high_bits) & ~rhs;
>  }
>  
> +static inline unsigned long zero_bytemask(unsigned long mask)
> +{
> + return ~1ul << __fls(mask);
> +}
> +
>  #else
>  
>  #ifdef CONFIG_64BIT


This looks right, and I tested it too so have an ack if you want it:

Acked-by: Michael Ellerman 


If you can CC linuxppc-...@lists.ozlabs.org in future on powerpc patches I'll
notice them quicker, I know I was CC'ed on this but because it also went to
LKML it got put in my lkml folder.

cheers



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] rtsx_usb_ms: Use msleep_interruptible() in polling loop

[Roger Tseng]

On Mon, 2015-09-28 at 01:34 +0100, Ben Hutchings wrote:
> rtsx_usb_ms creates a task that mostly sleeps, but tasks in
> uninterruptible sleep still contribute to the load average (for
> bug-compatibility with Unix).  A load average of ~1 on a system that
> should be idle is somewhat alarming.
> 
> Change the sleep to be interruptible, but still ignore signals.
> 
> A better fix might be to replace this loop with a delayed work item.
The change should be OK providing it does the same delay. You can add my
ack.

> References: https://bugs.debian.org/765717
> Signed-off-by: Ben Hutchings 
> ---
> --- a/drivers/memstick/host/rtsx_usb_ms.c
> +++ b/drivers/memstick/host/rtsx_usb_ms.c
> @@ -706,7 +706,8 @@ poll_again:
>   if (host->eject)
>   break;
>  
> - msleep(1000);
> + if (msleep_interruptible(1000))
> + flush_signals(current);
>   }
>  
>   complete(>detect_ms_exit);

-- 
Best regards,
Roger Tseng

Re: unsquashfs not preserving file capabilities

[Prasad Koya]

Hi

Debugged this with traces enabled. Turns out that unsquashfs *is*
setting xattrs with lsetxattr() but soon after returning from
write_xattr(), it calls chown() and that is removing the xattrs on
file.

Please take a look at this patch below, which calls chown() only if
uid/gid of file is different to what is passed in set_attributes().
I'm not that familiar with this code.

thank you

bash% diff -u /bld/squashfs-tools/unsquashfs.c unsquashfs.c

--- /bld/squashfs-tools/unsquashfs.c2015-10-07 20:22:22.657129963 -0700

+++ unsquashfs.c2015-10-07 20:21:06.070143018 -0700

@@ -700,12 +700,21 @@

}



if(root_process) {

-   if(chown(pathname, uid, guid) == -1) {

-   ERROR("set_attributes: failed to change uid and gids "

-   "on %s, because %s\n", pathname,

-   strerror(errno));

+   struct stat sbuf;

+   int x = stat(pathname, );

+   if (x != 0) {

+   ERROR("set_attributes: stat(%s) failed. errno %d\n",

+   pathname, errno);

return FALSE;

}

+   if(uid != sbuf.st_uid || guid != sbuf.st_gid) {

+   if(chown(pathname, uid, guid) == -1) {

+   ERROR("set_attributes: failed to change "

+   "uid and gids on %s, because %s\n", pathname,

+   strerror(errno));

+   return FALSE;

+   }

+   }

} else

mode &= ~07000;



bash%

On Wed, Oct 7, 2015 at 7:28 AM, Prasad Koya  wrote:
> Hi
>
> Not sure if there is a mailing list for squashfs-tools.
>
> I'm not seeing xattrs after unsquashing. This is how we are using:
>
> 1. Install all of our RPMs with some root dir (rpm --root xyz)
>
> 2. mksquashfs of xyz. (-comp xz -Xbcj x86).
>
> 3. To update an rpm in image, we first unsquash  the fs made in step 2
> with unsquashfs. Say this is dir xyz2, then do 'rpm --root xyz2 -U
> changed.rpm'
>
> Right after unsquashing in step 3, I don't see capabilities on, say, ping.
>
>
> after first mksquashfs ie., installing all RPMs fresh:
>
> bash% getfattr -n security.capability rootfs/usr/bin/ping
> # file: usr/bin/ping
> security.capability=0sAQAAAgAwAAA=
>
> bash% getcap rootfs/usr/bin/ping
> usr/bin/ping = cap_net_admin,cap_net_raw+ep
>
>
> after unsquashfs:
>
> bash% getfattr -n security.capability
> /tmp/extracted/unsquashed/usr/bin/ping
> /tmp/extracted/unsquashed/usr/bin/ping: security.capability: No such attribute
>
> bash% getcap /tmp/extracted/unsquashed/usr/bin/ping
> bash%
>
> I explicitly specify '-xattrs' for both mksquashfs and unsquashfs. Is
> this known issue?
>
> thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [nfs] 048883e0b9: No primary result change, -70.4% fsmark.time.involuntary_context_switches

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 048883e0b934d9a5103d40e209cb14b7f33d2933 ("nfs: fix pg_test page count 
calculation")


=
tbox_group/testcase/rootfs/kconfig/compiler/iterations/nr_threads/disk/fs/fs2/filesize/test_size/sync_method/nr_directories/nr_files_per_directory:
  
lkp-ws02/fsmark/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/1x/32t/1HDD/xfs/nfsv4/16MB/60G/fsyncBeforeClose/16d/256fpd

commit: 
  a41cbe86df3afbc82311a1640e20858c0cd7e065
  048883e0b934d9a5103d40e209cb14b7f33d2933

a41cbe86df3afbc8 048883e0b934d9a5103d40e209 
 -- 
 %stddev %change %stddev
 \  |\  
261986 ±  0% -70.4%  77543 ±  0%  
fsmark.time.involuntary_context_switches
272406 ±  0% -17.9% 223687 ±  0%  
fsmark.time.voluntary_context_switches
  5443 ±  0% -38.6%   3342 ±  0%  vmstat.system.cs
475248 ±  0% -50.9% 233285 ±  0%  softirqs.NET_RX
157367 ±  1%  -9.0% 143212 ±  0%  softirqs.SCHED
261986 ±  0% -70.4%  77543 ±  0%  time.involuntary_context_switches
272406 ±  0% -17.9% 223687 ±  0%  time.voluntary_context_switches
248624 ±  1%+294.3% 980340 ±  0%  meminfo.Active
223111 ±  2%+328.0% 954877 ±  0%  meminfo.Active(file)
 65657 ±  0% -13.1%  57050 ±  0%  meminfo.SUnreclaim
  1.34 ±  0%  -5.2%   1.27 ±  0%  turbostat.%Busy
  5.19 ±  1% -28.5%   3.71 ±  3%  turbostat.CPU%c1
 12.41 ±  1% -52.3%   5.91 ±  4%  turbostat.CPU%c3
 14.86 ±  1% -23.3%  11.39 ±  3%  turbostat.Pkg%pc3
 16.35 ±  1% +41.8%  23.19 ±  1%  turbostat.Pkg%pc6
 2.675e+08 ±  4% -12.9%  2.329e+08 ±  7%  cpuidle.C1-NHM.time
165684 ±  4% +12.4% 186205 ±  2%  cpuidle.C1-NHM.usage
 1.446e+08 ±  7% -75.9%   34785128 ± 12%  cpuidle.C1E-NHM.time
 79076 ±  1% -87.7%   9744 ±  3%  cpuidle.C1E-NHM.usage
 1.618e+09 ±  1% -55.5%  7.193e+08 ±  3%  cpuidle.C3-NHM.time
510548 ±  0% -73.4% 135726 ±  1%  cpuidle.C3-NHM.usage
   1532641 ±  0%  -9.8%1382714 ±  1%  cpuidle.C6-NHM.usage
119890 ±  2%+322.8% 506915 ±  5%  numa-meminfo.node0.Active
107993 ±  2%+356.4% 492854 ±  5%  numa-meminfo.node0.Active(file)
 34025 ±  3%  -9.9%  30670 ±  1%  numa-meminfo.node0.SUnreclaim
128802 ±  4%+267.7% 473544 ±  6%  numa-meminfo.node1.Active
115176 ±  4%+301.2% 462134 ±  6%  numa-meminfo.node1.Active(file)
  1217 ±  4% -20.5% 967.25 ± 22%  numa-meminfo.node1.Dirty
  9663 ± 24% -29.4%   6824 ± 35%  numa-meminfo.node1.Mapped
 31637 ±  3% -16.6%  26381 ±  1%  numa-meminfo.node1.SUnreclaim
  11631847 ±  2% +19.8%   13937484 ±  4%  numa-numastat.node0.local_node
   3950957 ±  9% +58.3%6253584 ± 10%  numa-numastat.node0.numa_foreign
  11631855 ±  2% +19.8%   13937495 ±  4%  numa-numastat.node0.numa_hit
   4660337 ±  3% -27.1%3398872 ±  7%  numa-numastat.node0.numa_miss
   4660345 ±  3% -27.1%3398883 ±  7%  numa-numastat.node0.other_node
  13541675 ±  3% -24.6%   10208933 ±  9%  numa-numastat.node1.local_node
   4660333 ±  3% -27.1%3398872 ±  7%  numa-numastat.node1.numa_foreign
  13541683 ±  3% -24.6%   10208939 ±  9%  numa-numastat.node1.numa_hit
   3950957 ±  9% +58.3%6253604 ± 10%  numa-numastat.node1.numa_miss
   3950964 ±  9% +58.3%6253611 ± 10%  numa-numastat.node1.other_node
 55777 ±  2%+328.0% 238719 ±  0%  proc-vmstat.nr_active_file
 16414 ±  0% -13.1%  14262 ±  0%  proc-vmstat.nr_slab_unreclaimable
   8605572 ±  5% +12.1%9648367 ±  6%  proc-vmstat.numa_foreign
   8605590 ±  5% +12.1%9648366 ±  6%  proc-vmstat.numa_miss
   8605606 ±  5% +12.1%9648384 ±  6%  proc-vmstat.numa_other
  1080 ±  8% -14.5% 924.25 ±  5%  proc-vmstat.numa_pages_migrated
 68361 ±  5%+620.8% 492764 ±  2%  proc-vmstat.pgactivate
  1080 ±  8% -14.5% 924.25 ±  5%  proc-vmstat.pgmigrate_success
   4917430 ±  1%  +8.5%5336634 ±  2%  proc-vmstat.pgscan_kswapd_dma32
   2245024 ±  0% -70.9% 653056 ±  0%  proc-vmstat.slabs_scanned
 26997 ±  2%+356.4% 123206 ±  5%  numa-vmstat.node0.nr_active_file
  8505 ±  3%  -9.9%   7667 ±  1%  
numa-vmstat.node0.nr_slab_unreclaimable
   1556010 ± 11% +72.7%2687972 ±  9%  numa-vmstat.node0.numa_foreign
   5466532 ±  2% +17.2%6404739 ±  5%  numa-vmstat.node0.numa_hit
   5466271 ±  2% +17.2%6404584 ±  5%  numa-vmstat.node0.numa_local
   2073926 ±  8% -27.8%1497829 ± 15%  numa-vmstat.node0.numa_miss
   2074187 ±  8% -27.8%1497984 ± 15%  numa-vmstat.node0.numa_other
 28794 ±  4%  

[PATCH v3 3/3] net: unix: optimize wakeups in unix_dgram_recvmsg()

[Jason Baron]

Now that connect() permanently registers a callback routine, we can induce
extra overhead in unix_dgram_recvmsg(), which unconditionally wakes up
its peer_wait queue on every receive. This patch makes the wakeup there
conditional on there being waiters.

Signed-off-by: Jason Baron 
---
 include/net/af_unix.h |  1 +
 net/unix/af_unix.c| 85 ---
 2 files changed, 62 insertions(+), 24 deletions(-)

diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 6a4a345..cf21ffd 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -61,6 +61,7 @@ struct unix_sock {
unsigned long   flags;
 #define UNIX_GC_CANDIDATE  0
 #define UNIX_GC_MAYBE_CYCLE1
+#define UNIX_NOSPACE   2
struct socket_wqpeer_wq;
wait_queue_twait;
 };
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index f789423..66979d4 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -326,7 +326,7 @@ found:
return s;
 }
 
-static inline int unix_writable(struct sock *sk)
+static inline bool unix_writable(struct sock *sk)
 {
return (atomic_read(>sk_wmem_alloc) << 2) <= sk->sk_sndbuf;
 }
@@ -1079,6 +1079,12 @@ static long unix_wait_for_peer(struct sock *other, long 
timeo)
 
prepare_to_wait_exclusive(>peer_wait, , TASK_INTERRUPTIBLE);
 
+   set_bit(UNIX_NOSPACE, >flags);
+   /* Ensure that we either see space in the peer sk_receive_queue via the
+* unix_recvq_full() check below, or we receive a wakeup when it
+* empties. Pairs with the mb in unix_dgram_recvmsg().
+*/
+   smp_mb__after_atomic();
sched = !sock_flag(other, SOCK_DEAD) &&
!(other->sk_shutdown & RCV_SHUTDOWN) &&
unix_recvq_full(other);
@@ -1623,17 +1629,27 @@ restart:
 
if (unix_peer(other) != sk && unix_recvq_full(other)) {
if (!timeo) {
-   err = -EAGAIN;
-   goto out_unlock;
-   }
+   set_bit(UNIX_NOSPACE, _sk(other)->flags);
+   /* Ensure that we either see space in the peer
+* sk_receive_queue via the unix_recvq_full() check
+* below, or we receive a wakeup when it empties. This
+* makes sure that epoll ET triggers correctly. Pairs
+* with the mb in unix_dgram_recvmsg().
+*/
+   smp_mb__after_atomic();
+   if (unix_recvq_full(other)) {
+   err = -EAGAIN;
+   goto out_unlock;
+   }
+   } else {
+   timeo = unix_wait_for_peer(other, timeo);
 
-   timeo = unix_wait_for_peer(other, timeo);
+   err = sock_intr_errno(timeo);
+   if (signal_pending(current))
+   goto out_free;
 
-   err = sock_intr_errno(timeo);
-   if (signal_pending(current))
-   goto out_free;
-
-   goto restart;
+   goto restart;
+   }
}
 
if (sock_flag(other, SOCK_RCVTSTAMP))
@@ -1939,8 +1955,19 @@ static int unix_dgram_recvmsg(struct socket *sock, 
struct msghdr *msg,
goto out_unlock;
}
 
-   wake_up_interruptible_sync_poll(>peer_wait,
-   POLLOUT | POLLWRNORM | POLLWRBAND);
+   /* Ensure that waiters on our sk->sk_receive_queue draining that check
+* via unix_recvq_full() either see space in the queue or get a wakeup
+* below. sk->sk_receive_queue is reduece by the __skb_recv_datagram()
+* call above. Pairs with the mb in unix_dgram_sendmsg(),
+*unix_dgram_poll(), and unix_wait_for_peer().
+*/
+   smp_mb();
+   if (test_bit(UNIX_NOSPACE, >flags)) {
+   clear_bit(UNIX_NOSPACE, >flags);
+   wake_up_interruptible_sync_poll(>peer_wait,
+   POLLOUT | POLLWRNORM |
+   POLLWRBAND);
+   }
 
if (msg->msg_name)
unix_copy_addr(msg, skb->sk);
@@ -2432,11 +2459,19 @@ static unsigned int unix_poll(struct file *file, struct 
socket *sock, poll_table
return mask;
 }
 
+static bool unix_dgram_writable(struct sock *sk, struct sock *other)
+{
+   if (other && unix_peer(other) != sk && unix_recvq_full(other))
+   return false;
+
+   return unix_writable(sk);
+}
+
 static unsigned int unix_dgram_poll(struct file *file, struct socket *sock,
poll_table *wait)
 {
struct sock *sk = sock->sk, *other;
-   unsigned int mask, writable;
+   unsigned int mask;
 
sock_poll_wait(file, sk_sleep(sk), wait);
mask = 

[PATCH v3 0/3] net: unix: fix use-after-free

[Jason Baron]

Hi,

These patches are against mainline, I can re-base to net-next, just
let me know.

They have been tested against: https://lkml.org/lkml/2015/9/13/195,
which causes the use-after-free quite quickly and here:
https://lkml.org/lkml/2015/10/2/693.

Thanks,

-Jason

v3:
-beef up memory barrier comments in 3/3 (Peter Zijlstra)
-clean up unix_dgram_writable() function in 3/3 (Joe Perches)

Jason Baron (3):
  net: unix: fix use-after-free in unix_dgram_poll()
  net: unix: Convert gc_flags to flags
  net: unix: optimize wakeups in unix_dgram_recvmsg()

 include/net/af_unix.h |   4 +-
 net/unix/af_unix.c| 117 +++---
 net/unix/garbage.c|  12 +++---
 3 files changed, 101 insertions(+), 32 deletions(-)

-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/3] net: unix: fix use-after-free in unix_dgram_poll()

[Jason Baron]

The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
queue associated with the socket s that we are poll'ing against, but also calls
sock_poll_wait() for a remote peer socket p, if it is connected. Thus,
if we call poll()/select()/epoll() for the socket s, there are then
a couple of code paths in which the remote peer socket p and its associated
peer_wait queue can be freed before poll()/select()/epoll() have a chance
to remove themselves from the remote peer socket.

The way that remote peer socket can be freed are:

1. If s calls connect() to a connect to a new socket other than p, it will
drop its reference on p, and thus a close() on p will free it.

2. If we call close on p(), then a subsequent sendmsg() from s, will drop
the final reference to p, allowing it to be freed.

Address this issue, by reverting unix_dgram_poll() to only register with
the wait queue associated with s and register a callback with the remote peer
socket on connect() that will wake up the wait queue associated with s. If
scenarios 1 or 2 occur above we then simply remove the callback from the
remote peer. This then presents the expected semantics to poll()/select()/
epoll().

I've implemented this for sock-type, SOCK_RAW, SOCK_DGRAM, and SOCK_SEQPACKET
but not for SOCK_STREAM, since SOCK_STREAM does not use unix_dgram_poll().

Introduced in commit ec0d215f9420 ("af_unix: fix 'poll for write'/connected
DGRAM sockets").

Tested-by: Mathias Krause 
Signed-off-by: Jason Baron 
---
 include/net/af_unix.h |  1 +
 net/unix/af_unix.c| 32 +++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 4a167b3..9698aff 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -62,6 +62,7 @@ struct unix_sock {
 #define UNIX_GC_CANDIDATE  0
 #define UNIX_GC_MAYBE_CYCLE1
struct socket_wqpeer_wq;
+   wait_queue_twait;
 };
 #define unix_sk(__sk) ((struct unix_sock *)__sk)
 
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 03ee4d3..f789423 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -420,6 +420,9 @@ static void unix_release_sock(struct sock *sk, int embrion)
skpair = unix_peer(sk);
 
if (skpair != NULL) {
+   if (sk->sk_type != SOCK_STREAM)
+   remove_wait_queue(_sk(skpair)->peer_wait,
+ >wait);
if (sk->sk_type == SOCK_STREAM || sk->sk_type == 
SOCK_SEQPACKET) {
unix_state_lock(skpair);
/* No more writes */
@@ -636,6 +639,16 @@ static struct proto unix_proto = {
  */
 static struct lock_class_key af_unix_sk_receive_queue_lock_key;
 
+static int peer_wake(wait_queue_t *wait, unsigned mode, int sync, void *key)
+{
+   struct unix_sock *u;
+
+   u = container_of(wait, struct unix_sock, wait);
+   wake_up_interruptible_sync_poll(sk_sleep(>sk), key);
+
+   return 0;
+}
+
 static struct sock *unix_create1(struct net *net, struct socket *sock, int 
kern)
 {
struct sock *sk = NULL;
@@ -664,6 +677,7 @@ static struct sock *unix_create1(struct net *net, struct 
socket *sock, int kern)
INIT_LIST_HEAD(>link);
mutex_init(>readlock); /* single task reading lock */
init_waitqueue_head(>peer_wait);
+   init_waitqueue_func_entry(>wait, peer_wake);
unix_insert_socket(unix_sockets_unbound(sk), sk);
 out:
if (sk == NULL)
@@ -1030,7 +1044,11 @@ restart:
 */
if (unix_peer(sk)) {
struct sock *old_peer = unix_peer(sk);
+
+   remove_wait_queue(_sk(old_peer)->peer_wait,
+ _sk(sk)->wait);
unix_peer(sk) = other;
+   add_wait_queue(_sk(other)->peer_wait, _sk(sk)->wait);
unix_state_double_unlock(sk, other);
 
if (other != old_peer)
@@ -1038,8 +1056,12 @@ restart:
sock_put(old_peer);
} else {
unix_peer(sk) = other;
+   add_wait_queue(_sk(other)->peer_wait, _sk(sk)->wait);
unix_state_double_unlock(sk, other);
}
+   /* New remote may have created write space for us */
+   wake_up_interruptible_sync_poll(sk_sleep(sk),
+   POLLOUT | POLLWRNORM | POLLWRBAND);
return 0;
 
 out_unlock:
@@ -1194,6 +1216,8 @@ restart:
 
sock_hold(sk);
unix_peer(newsk)= sk;
+   if (sk->sk_type == SOCK_SEQPACKET)
+   add_wait_queue(_sk(sk)->peer_wait, _sk(newsk)->wait);
newsk->sk_state = TCP_ESTABLISHED;
newsk->sk_type  = sk->sk_type;
init_peercred(newsk);
@@ -1220,6 +1244,8 @@ restart:
 
smp_mb__after_atomic(); /* sock_hold() does an atomic_inc() */
unix_peer(sk)   = newsk;
+   if (sk->sk_type == SOCK_SEQPACKET)
+   

[PATCH v3 2/3] net: unix: Convert gc_flags to flags

[Jason Baron]

Convert gc_flags to flags in perparation for the subsequent patch, which will
make use of a flag bit for a non-gc purpose.

Signed-off-by: Jason Baron 
---
 include/net/af_unix.h |  2 +-
 net/unix/garbage.c| 12 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 9698aff..6a4a345 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -58,7 +58,7 @@ struct unix_sock {
atomic_long_t   inflight;
spinlock_t  lock;
unsigned char   recursion_level;
-   unsigned long   gc_flags;
+   unsigned long   flags;
 #define UNIX_GC_CANDIDATE  0
 #define UNIX_GC_MAYBE_CYCLE1
struct socket_wqpeer_wq;
diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index a73a226..39794d9 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -179,7 +179,7 @@ static void scan_inflight(struct sock *x, void 
(*func)(struct unix_sock *),
 * have been added to the queues after
 * starting the garbage collection
 */
-   if (test_bit(UNIX_GC_CANDIDATE, 
>gc_flags)) {
+   if (test_bit(UNIX_GC_CANDIDATE, 
>flags)) {
hit = true;
 
func(u);
@@ -246,7 +246,7 @@ static void inc_inflight_move_tail(struct unix_sock *u)
 * of the list, so that it's checked even if it was already
 * passed over
 */
-   if (test_bit(UNIX_GC_MAYBE_CYCLE, >gc_flags))
+   if (test_bit(UNIX_GC_MAYBE_CYCLE, >flags))
list_move_tail(>link, _candidates);
 }
 
@@ -305,8 +305,8 @@ void unix_gc(void)
BUG_ON(total_refs < inflight_refs);
if (total_refs == inflight_refs) {
list_move_tail(>link, _candidates);
-   __set_bit(UNIX_GC_CANDIDATE, >gc_flags);
-   __set_bit(UNIX_GC_MAYBE_CYCLE, >gc_flags);
+   __set_bit(UNIX_GC_CANDIDATE, >flags);
+   __set_bit(UNIX_GC_MAYBE_CYCLE, >flags);
}
}
 
@@ -332,7 +332,7 @@ void unix_gc(void)
 
if (atomic_long_read(>inflight) > 0) {
list_move_tail(>link, _cycle_list);
-   __clear_bit(UNIX_GC_MAYBE_CYCLE, >gc_flags);
+   __clear_bit(UNIX_GC_MAYBE_CYCLE, >flags);
scan_children(>sk, inc_inflight_move_tail, NULL);
}
}
@@ -343,7 +343,7 @@ void unix_gc(void)
 */
while (!list_empty(_cycle_list)) {
u = list_entry(not_cycle_list.next, struct unix_sock, link);
-   __clear_bit(UNIX_GC_CANDIDATE, >gc_flags);
+   __clear_bit(UNIX_GC_CANDIDATE, >flags);
list_move_tail(>link, _inflight_list);
}
 
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [PATCH 1/2] ASoC: rockchip: i2s: add 8 channels capture and lrck-mode support

[Caleb Crome]

 That will work!  Do all your cortex-a parts support that?

Thanks, Caleb 
Sent from my iPhone

> On Oct 7, 2015, at 7:44 PM, sugar  wrote:
> 
> Yes, we can support 8 channels with 32bits/sample, thanks.
> 
>> 在 10/8/2015 10:36, Caleb Crome 写道:
>> We make microphone arrays with lots of microphones.  Some as few as 2, many 
>> with 7 channels, and a few with 14 or more.
>> 
>> Can you support 8 channels with 32 bits/sample?  That would work, we can 
>> just set the codecs for 16-bit samples, which would be 256 bits/frame.
>> 
>> Hope you had a great golden week holiday!
>> 
>> Thanks,
>> Caleb Crome
>> 
>> 
>> 
>> 
>> Sent from my iPhone
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] ASoC: Codec: wm8962: declare ALC Coefficients as 4 separate registers

[Jiada Wang]

Hi


On 10/06/2015 08:01 PM, Mark Brown wrote:

On Tue, Oct 06, 2015 at 04:06:55PM +0900, Jiada Wang wrote:


As ALC2 register is volatile, declare it as one of ALC Coefficients
register together with other non-volatile registers will cause issue,
in case wm8962 has enter suspend mode, and cache_only flag is set,
any attempt to read from ALC2 will fail.



Instead of declaring one ALC Coefficients register which contains
ALC1 ~ ALC3 and Noise Gate, this patch declares 4 separate registers,
so that regmap can handle these registers differently based on their
classification.


I don't understand this commit log.  Why does regmap care how these
registers are presented to userspace, and how does splitting the
controls up address the problem with one of the registers being volatile?
Surely that register still has the same problem?


.get callback function will call regmap_raw_read() to read register
value from these registers, when these 4 regsters are declared as one
"ALC coefficient" register, condition check of regmap_volatile_range()
will return false, thus regmap will go word by word for the cache from
each register of "ALC Coefficient", the failure scenario is, when
wm8962 is in suspend mode (cache_only flag is set), as ALC2 doesn't
have cached value, then any attempt to read from it fails,

By splitting these registers, regmap can handle ALC2 as a single
volatile register, and always read from HW

Thanks,
Jiada

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bugfix v4 1/2] eata: Convert eata driver as normal PCI and platform device drivers

[Jiang Liu]

On 2015/10/8 10:51, Jiang Liu wrote:
> Previously the eata driver just grabs and accesses eata PCI devices
> without implementing a PCI device driver, that causes troubles with
> latest IRQ related
> 
> Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
> pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
> for PCI devices on x86 platforms. Instead of allocating PCI legacy
> IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq()
> will be called by pci_device_probe() to allocate PCI legacy IRQs
> when binding PCI drivers to PCI devices.
> 
> But the eata driver directly accesses PCI devices without implementing
> corresponding PCI drivers, so pcibios_alloc_irq() won't be called for
> those PCI devices and wrong IRQ number may be used to manage the PCI
> device.
> 
> This patch implements a PCI device driver to manage eata PCI devices,
> so eata driver could properly cooperate with the PCI core. It also
> provides headroom for PCI hotplug with eata driver.
> 
> It also represents non-PCI eata devices as platform devices, so it could
> be managed as normal devices.
> 

Hi all,
Sorry, should add:
Reported-and-tested-by: Arthur Marsh 

> Signed-off-by: Jiang Liu 
> Cc: Hannes Reinecke 
> Cc: Ballabio, Dario 
> Cc: Christoph Hellwig 
> ---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [iommu/vt] c1b9a54b6f:

[Baoquan He]

Hi,

On 10/08/15 at 10:47am, kernel test robot wrote:
> FYI, we noticed the below changes on
> 
> git://internal_mailing_list_patch_tree 
> Baoquan-He/iommu-vt-d-break-the-for-loop-if-an-empty-ir_ioapic-entry-found
> commit c1b9a54b6f21f22bb5fba5cb981da0be06011476 ("iommu/vt-d: Adjsut the 
> return value of the parse_ioapics_under_ir")

> 
> The following new message in kernel log may make end user confusing.
> The test was done without hibernation.
> 
> [0.241752] DMAR-IR: Failed to copy IR table for dmar0 from previous kernel
> 
> To reproduce:
> 
> git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml

The first patch need be dropped since the original code is reasonable.
Only patch 2/2 is good, I will repost patch 2/2 alone according to
Joerg's comment.

[PATCH 1/2] iommu/vt-d: break the for loop if an empty ir_ioapic entry
found


Thanks
Baoquan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Bugfix v4 1/2] eata: Convert eata driver as normal PCI and platform device drivers

[Jiang Liu]

Previously the eata driver just grabs and accesses eata PCI devices
without implementing a PCI device driver, that causes troubles with
latest IRQ related

Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq()
will be called by pci_device_probe() to allocate PCI legacy IRQs
when binding PCI drivers to PCI devices.

But the eata driver directly accesses PCI devices without implementing
corresponding PCI drivers, so pcibios_alloc_irq() won't be called for
those PCI devices and wrong IRQ number may be used to manage the PCI
device.

This patch implements a PCI device driver to manage eata PCI devices,
so eata driver could properly cooperate with the PCI core. It also
provides headroom for PCI hotplug with eata driver.

It also represents non-PCI eata devices as platform devices, so it could
be managed as normal devices.

Signed-off-by: Jiang Liu 
Cc: Hannes Reinecke 
Cc: Ballabio, Dario 
Cc: Christoph Hellwig 
---
Hi all,
With this patch applied, we still have issues when doing kexec,
but I think we could treat the kexec failure independently. So it would
be great if we could merge this patch first and then continue on solving
the kexec issues.

v3->v4:
1) refine log messages according to James' suggestion

Thanks!
Gerry
---
 drivers/scsi/eata.c |  619 ---
 1 file changed, 337 insertions(+), 282 deletions(-)

diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 227dd2c2ec2f..7315f8adcf65 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -486,6 +486,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -503,8 +504,6 @@
 #include 
 #include 
 
-static int eata2x_detect(struct scsi_host_template *);
-static int eata2x_release(struct Scsi_Host *);
 static int eata2x_queuecommand(struct Scsi_Host *, struct scsi_cmnd *);
 static int eata2x_eh_abort(struct scsi_cmnd *);
 static int eata2x_eh_host_reset(struct scsi_cmnd *);
@@ -513,9 +512,9 @@ static int eata2x_bios_param(struct scsi_device *, struct 
block_device *,
 static int eata2x_slave_configure(struct scsi_device *);
 
 static struct scsi_host_template driver_template = {
+   .module = THIS_MODULE,
+   .proc_name = "eata2x",
.name = "EATA/DMA 2.0x rev. 8.10.00 ",
-   .detect = eata2x_detect,
-   .release = eata2x_release,
.queuecommand = eata2x_queuecommand,
.eh_abort_handler = eata2x_eh_abort,
.eh_host_reset_handler = eata2x_eh_host_reset,
@@ -818,7 +817,6 @@ struct hostdata {
unsigned int cp_stat[MAX_MAILBOXES];/* FREE, IN_USE, LOCKED, 
IN_RESET */
unsigned int last_cp_used;  /* Index of last mailbox used */
unsigned int iocount;   /* Total i/o done for this board */
-   int board_number;   /* Number of this board */
char board_name[16];/* Name of this board */
int in_reset;   /* True if board is doing a reset */
int target_to[MAX_TARGET][MAX_CHANNEL]; /* N. of timeout errors on 
target */
@@ -834,12 +832,9 @@ struct hostdata {
struct mssp sp; /* Local copy of sp buffer */
 };
 
-static struct Scsi_Host *sh[MAX_BOARDS];
 static const char *driver_name = "EATA";
-static char sha[MAX_BOARDS];
-
-/* Initialize num_boards so that ihdlr can work while detect is in progress */
-static unsigned int num_boards = MAX_BOARDS;
+static struct platform_device *eata2x_platform_devs[MAX_BOARDS];
+static bool eata2x_platform_driver_registered;
 
 static unsigned long io_port[] = {
 
@@ -850,10 +845,6 @@ static unsigned long io_port[] = {
/* First ISA */
0x1f0,
 
-   /* Space for MAX_PCI ports possibly reported by PCI_BIOS */
-   SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP,
-   SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP,
-
/* MAX_EISA ports */
0x1c88, 0x2c88, 0x3c88, 0x4c88, 0x5c88, 0x6c88, 0x7c88, 0x8c88,
0x9c88, 0xac88, 0xbc88, 0xcc88, 0xdc88, 0xec88, 0xfc88,
@@ -870,6 +861,13 @@ static unsigned long io_port[] = {
 #define DEV2H(x)   be32_to_cpu(x)
 #define H2DEV16(x) cpu_to_be16(x)
 #define DEV2H16(x) be16_to_cpu(x)
+#define dev_warn_on(dev, cond, fmt, ...)   \
+do {   \
+   if (cond)   \
+   dev_warn(dev, fmt, ##__VA_ARGS__);  \
+} while (0)
+#define dev_info_on(dev, cond, fmt, ...)   \
+   if ((cond)) dev_info((dev), (fmt), ##__VA_ARGS__)
 
 /* But transfer orientation from the 16 bit data register is Little Endian */
 #define REG2H(x)   le16_to_cpu(x)
@@ -1024,90 +1022,43 @@ static int read_pio(unsigned long iobase, ushort * 
start, ushort * end)
return 0;
 }
 

[Bugfix v4 2/2] eata: Ask for help to reset eata controllers for kexec

[Jiang Liu]

Arthur Marsh  reported that with the first
patch applied, he still encountered troubles when doing kexec with eata
devices. Quote Arthur's report:
To clarify, if the eata driver gets loaded once and stays loaded, at a
kexec reboot attempt the "Synchronising SCSI cache" message is missing
for the SCSI disk attached to the controller using the eata driver and
eventually other error messages appear as seen in screen images that
I have previously posted at
http://www.users.on.net/~arthur.marsh/20150915547.jpg.

If the eata driver is loaded, unloaded via modprobe -r, then reloaded,
a kexec reboot shows 2 "Synchronising SCSI cache" messages for the SCSI
disk attached to the controller using the eata driver and the kexec
reboot is successful.

For more details, please refer to thread at:
http://www.gossamer-threads.com/lists/linux/kernel/2251833
https://lkml.org/lkml/2015/9/6/165

First I thought we could solve this issue by implementing a shutdown
callback to reset eata controllers when rebooting, but it turns out
that this patch doesn't really help. And due to limited knowledge about
eata controllers and lack of hardware for tests, helps from eata experts
are really welcomed!

Signed-off-by: Jiang Liu 
---
 drivers/scsi/eata.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 7315f8adcf65..b83abe283744 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -1519,6 +1519,11 @@ static void eata2x_pci_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
 }
 
+static void eata2x_pci_shutdown(struct pci_dev *pdev)
+{
+   port_remove(>dev);
+}
+
 static struct pci_device_id eata2x_tbl[] = {
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SCSI << 8, PCI_ANY_ID) },
{ },
@@ -1530,6 +1535,7 @@ static struct pci_driver eata2x_pci_driver = {
.id_table   = eata2x_tbl,
.probe  = eata2x_pci_probe,
.remove = eata2x_pci_remove,
+   .shutdown   = eata2x_pci_shutdown,
 };
 
 static int eata2x_register_pci_driver(void)
@@ -1571,8 +1577,14 @@ static int __exit eata2x_platform_remove(struct 
platform_device *pdev)
return 0;
 }
 
+static void eata2x_platform_shutdown(struct platform_device *pdev)
+{
+   port_remove(>dev);
+}
+
 static struct platform_driver eata2x_platform_driver = {
.remove = __exit_p(eata2x_platform_remove),
+   .shutdown = eata2x_platform_shutdown,
.driver = {
.name   = "eata_plat",
.owner  = THIS_MODULE,
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [PATCH 1/2] ASoC: rockchip: i2s: add 8 channels capture and lrck-mode support

[sugar]

Yes, we can support 8 channels with 32bits/sample, thanks.

在 10/8/2015 10:36, Caleb Crome 写道:

We make microphone arrays with lots of microphones.  Some as few as 2, many 
with 7 channels, and a few with 14 or more.

Can you support 8 channels with 32 bits/sample?  That would work, we can just 
set the codecs for 16-bit samples, which would be 256 bits/frame.

Hope you had a great golden week holiday!

Thanks,
 Caleb Crome




Sent from my iPhone


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] kselftest: add kselftest-clean rule

[Wang Long]

We use

$make TARGETS="size timers" kselftest

to build and run selftests. but there is no rule
for us to clean the kselftest generated files.

This patch add the rules, for example:

$ make TARGETS="size timers" kselftest-clean

can clean all kselftest generated files.

Signed-off-by: Wang Long 
---
 Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/Makefile b/Makefile
index 1d341eb..3edd7b3 100644
--- a/Makefile
+++ b/Makefile
@@ -1075,6 +1075,9 @@ PHONY += kselftest
 kselftest:
$(Q)$(MAKE) -C tools/testing/selftests run_tests
 
+kselftest-clean:
+   $(Q)$(MAKE) -C tools/testing/selftests clean
+
 # ---
 # Modules
 
@@ -1282,6 +1285,7 @@ help:
@echo  '  kselftest   - Build and run kernel selftest (run as root)'
@echo  'Build, install, and boot kernel before'
@echo  'running kselftest on it'
+   @echo  '  kselftest-clean - Remove all generated kselftest files'
@echo  ''
@echo  'Kernel packaging:'
@$(MAKE) $(build)=$(package-dir) help
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kselftest: add cleankselftest rule

[long.wanglong]

On 2015/10/2 22:18, Shuah Khan wrote:
> On 09/30/2015 07:17 PM, Michael Ellerman wrote:
>> On Wed, 2015-09-23 at 09:33 +, Wang Long wrote:
>>> We use
>>>
>>> $make TARGETS="size timers" kselftest
>>>
>>> to build and run selftests. but there is no rule
>>> for us to clean the kselftest generated files.
>>>
>>> This patch add the rules, for example:
>>>
>>> $ make TARGETS="size timers" cleankselftest
>>
>> I think 'kselftest-clean' would be neater.
>>
>> That way all the kselftests targets start with 'kselftest'.
>>
> 
> Good suggestion. Wang! Could you please send me updated patch
> with this suggested change.

OK.

Since the National Day holiday, I am sorry so late reply.

I will send the updated patch.

Thanks.
> 
> thanks,
> -- Shuah
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [mm] 81c72584a4: -4.3% will-it-scale.per_process_ops

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git master
commit 81c72584a480c5a4b7eede527d0b990c83c2dcc9 ("mm: gup: make 
get_user_pages_fast and __get_user_pages_fast latency conscious")


=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/test:
  
ivb42/will-it-scale/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/futex1

commit: 
  4ae904c494e475048050994f669137c12274da85
  81c72584a480c5a4b7eede527d0b990c83c2dcc9

4ae904c494e47504 81c72584a480c5a4b7eede527d 
 -- 
 %stddev %change %stddev
 \  |\  
   5375911 ±  0%  -4.3%5146855 ±  0%  will-it-scale.per_process_ops
   1605249 ±  1%  -3.1%1555950 ±  0%  will-it-scale.per_thread_ops
  0.60 ±  1%  -4.2%   0.58 ±  0%  will-it-scale.scalability
  9957 ± 27% -28.6%   7114 ±  0%  numa-meminfo.node0.Mapped
  1933 ± 17% +16.0%   2243 ±  6%  numa-meminfo.node1.PageTables
  2488 ± 27% -28.6%   1777 ±  0%  numa-vmstat.node0.nr_mapped
483.00 ± 17% +16.0% 560.50 ±  6%  
numa-vmstat.node1.nr_page_table_pages
 42.00 ± 12% -31.5%  28.75 ± 11%  sched_debug.cfs_rq[0]:/.load
   2032736 ±  5% -12.5%1779371 ±  7%  
sched_debug.cfs_rq[0]:/.min_vruntime
   -300090 ±-69%-103.1%   9378 ±1396%  sched_debug.cfs_rq[10]:/.spread0
   -235906 ±-47%-103.2%   7486 ±1760%  sched_debug.cfs_rq[11]:/.spread0
   -885383 ±-11% -29.4%-625333 ±-21%  sched_debug.cfs_rq[13]:/.spread0
   -883477 ±-12% -28.4%-632137 ±-19%  sched_debug.cfs_rq[14]:/.spread0
   -881069 ±-12% -28.6%-629181 ±-20%  sched_debug.cfs_rq[15]:/.spread0
   -888493 ±-12% -29.9%-622785 ±-19%  sched_debug.cfs_rq[16]:/.spread0
   -883314 ±-13% -28.9%-627753 ±-20%  sched_debug.cfs_rq[17]:/.spread0
  -1037778 ±-20% -39.9%-623972 ±-21%  sched_debug.cfs_rq[18]:/.spread0
   -882564 ±-12% -29.3%-623573 ±-20%  sched_debug.cfs_rq[19]:/.spread0
   -237868 ±-46%-106.0%  14369 ±854%  sched_debug.cfs_rq[1]:/.spread0
   -870685 ±-11% -29.7%-612118 ±-18%  sched_debug.cfs_rq[20]:/.spread0
   -879689 ±-12% -29.5%-620241 ±-20%  sched_debug.cfs_rq[21]:/.spread0
   -872185 ±-13% -27.7%-630771 ±-21%  sched_debug.cfs_rq[22]:/.spread0
   -882721 ±-12% -28.3%-633288 ±-21%  sched_debug.cfs_rq[23]:/.spread0
 13.25 ± 47% +98.1%  26.25 ± 29%  
sched_debug.cfs_rq[24]:/.tg_load_avg_contrib
   -198518 ±-57%-127.2%  53978 ±241%  sched_debug.cfs_rq[25]:/.spread0
 15.00 ± 33% -53.3%   7.00 ±  0%  sched_debug.cfs_rq[26]:/.load_avg
   -166551 ±-60%-135.2%  58649 ±214%  sched_debug.cfs_rq[26]:/.spread0
 15.25 ± 34% -54.1%   7.00 ±  0%  
sched_debug.cfs_rq[26]:/.tg_load_avg_contrib
   -195491 ±-57%-128.4%  55586 ±227%  sched_debug.cfs_rq[27]:/.spread0
   -189456 ±-56%-130.0%  56778 ±222%  sched_debug.cfs_rq[28]:/.spread0
   -198122 ±-56%-131.1%  61555 ±202%  sched_debug.cfs_rq[29]:/.spread0
   -267573 ±-52%-105.6%  14934 ±816%  sched_debug.cfs_rq[2]:/.spread0
   -196299 ±-56%-129.7%  58206 ±217%  sched_debug.cfs_rq[30]:/.spread0
   -188828 ±-53%-130.7%  57930 ±219%  sched_debug.cfs_rq[31]:/.spread0
   -197148 ±-54%-131.1%  61392 ±204%  sched_debug.cfs_rq[32]:/.spread0
   -191912 ±-55%-130.1%  57741 ±218%  sched_debug.cfs_rq[33]:/.spread0
   -196722 ±-57%-129.5%  58104 ±215%  sched_debug.cfs_rq[35]:/.spread0
   -802782 ±-14% -31.0%-554283 ±-22%  sched_debug.cfs_rq[37]:/.spread0
183.25 ±  7%  -7.9% 168.75 ±  0%  sched_debug.cfs_rq[37]:/.util_avg
   -798974 ±-14% -31.3%-548870 ±-24%  sched_debug.cfs_rq[38]:/.spread0
   -804061 ±-13% -31.9%-547569 ±-23%  sched_debug.cfs_rq[39]:/.spread0
   -241212 ±-46%-104.2%  10110 ±1225%  sched_debug.cfs_rq[3]:/.spread0
   -804833 ±-13% -32.5%-542990 ±-24%  sched_debug.cfs_rq[40]:/.spread0
   -802162 ±-13% -31.6%-548407 ±-23%  sched_debug.cfs_rq[41]:/.spread0
   -804352 ±-13% -33.8%-532778 ±-26%  sched_debug.cfs_rq[43]:/.spread0
   -803450 ±-13% -31.6%-549859 ±-22%  sched_debug.cfs_rq[44]:/.spread0
   -804660 ±-13% -32.2%-545711 ±-22%  sched_debug.cfs_rq[45]:/.spread0
   -803171 ±-14% -32.8%-540079 ±-22%  sched_debug.cfs_rq[46]:/.spread0
   -798603 ±-14% -32.2%-541575 ±-23%  sched_debug.cfs_rq[47]:/.spread0
   -236187 ±-45%-106.5%  15418 ±808%  sched_debug.cfs_rq[4]:/.spread0
   -240043 ±-46%-105.8%  13821 ±907%  sched_debug.cfs_rq[5]:/.spread0
   -241134 ±-45%-105.5%  13348 ±932%  sched_debug.cfs_rq[6]:/.spread0
   -232614 ±-43%-104.6%  10696 ±1210%  sched_debug.cfs_rq[7]:/.spread0
   -238112 ±-49%-104.9%  11721 

Re: [alsa-devel] [PATCH 1/2] ASoC: rockchip: i2s: add 8 channels capture and lrck-mode support

[Caleb Crome]

We make microphone arrays with lots of microphones.  Some as few as 2, many 
with 7 channels, and a few with 14 or more.  

Can you support 8 channels with 32 bits/sample?  That would work, we can just 
set the codecs for 16-bit samples, which would be 256 bits/frame.

Hope you had a great golden week holiday!

Thanks,  
Caleb Crome




Sent from my iPhone

> On Oct 7, 2015, at 6:47 PM, sugar  wrote:
> 
> Hi Caleb,
> 
> we haven't support 16 channels capture and playback yet, would you mind to 
> detail the use case? if must, we may support this feature on next generation 
> chip.
> 
>> 在 10/7/2015 21:04, Caleb Crome 写道:
>> Hi sugar,
>>Can the rockchip support more than 8 channels?  Ideally, we would like to 
>> capture 16 channels and playback 16 channels simultaneously.
>> 
>> Thanks,  Caleb
>> 
>> Sent from my iPhone
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the chrome-platform tree

[Stephen Rothwell]

Hi Olof,

After merging the chrome-platform tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/platform/chrome/cros_ec_vbc.c:136:2: error: unknown field 
'is_bin_visible' specified in initializer
  .is_bin_visible = cros_ec_vbc_is_visible,
  ^

Caused by commit

  01e7e432df74 ("platform/chrome: Support reading/writing the vboot context")

I have used the chrome-platform tree from next-20151007 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs

[Alexei Starovoitov]

On 10/5/15 1:48 PM, Alexei Starovoitov wrote:

Unprivileged socket filter bpf programs have access to the
following helper functions:
- map lookup/update/delete (but they cannot store kernel pointers into them)
- get_random (it's already exposed to unprivileged user space)
- get_smp_processor_id
- tail_call into another socket filter program
- ktime_get_ns
- bpf_trace_printk (for debugging)


while reviewing everything for Nth time realized that
bpf_trace_printk is useless for unprivileged users, since
trace_pipe is root only.
So going to drop it in V2.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm: skip if required_kernelcore is larger than totalpages

[Xishi Qiu]

If kernelcore was not specified, or the kernelcore size is zero
(required_movablecore >= totalpages), or the kernelcore size is larger
than totalpages, there is no ZONE_MOVABLE. We should fill the zone
with both kernel memory and movable memory.

Signed-off-by: Xishi Qiu 
---
 mm/page_alloc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index af3c9bd..6a6da0d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5674,8 +5674,11 @@ static void __init find_zone_movable_pfns_for_nodes(void)
required_kernelcore = max(required_kernelcore, corepages);
}
 
-   /* If kernelcore was not specified, there is no ZONE_MOVABLE */
-   if (!required_kernelcore)
+   /*
+* If kernelcore was not specified or kernelcore size is larger
+* than totalpages, there is no ZONE_MOVABLE.
+*/
+   if (!required_kernelcore || required_kernelcore >= totalpages)
goto out;
 
/* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at */
-- 
2.0.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/5] PCI: Add pci_bus_fixup_irqs().

[Matthew Minter]

On Wednesday 07 October 2015 18:08:47 Bjorn Helgaas wrote:
> [+cc Matthew]
> 
> On Wed, Oct 07, 2015 at 01:08:40PM -0700, David Daney wrote:
> > On 10/07/2015 12:44 PM, Bjorn Helgaas wrote:
> > >Hi David,
> > >
> > >On Fri, Oct 02, 2015 at 11:43:59AM -0700, David Daney wrote:
> > >>From: David Daney 
> > >>
> > >>pci_bus_fixup_irqs() works like pci_fixup_irqs(), except it only does
> > >>the fixups for devices on the specified bus.
> > >>
> > >>Follow-on patch will use the new function.
> > >>
> > >>Signed-off-by: David Daney 
> > >>---
> > >>No change from v2.
> > >>
> > >>  drivers/pci/setup-irq.c | 30 ++
> > >>  include/linux/pci.h |  4 
> > >>  2 files changed, 34 insertions(+)
> > >>
> > >>diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
> > >>index 95c225b..189ad17 100644
> > >>--- a/drivers/pci/setup-irq.c
> > >>+++ b/drivers/pci/setup-irq.c
> > >>@@ -66,3 +66,33 @@ void pci_fixup_irqs(u8 (*swizzle)(struct pci_dev *,
> > >>u8 *),> >>
> > >>  pdev_fixup_irq(dev, swizzle, map_irq);
> > >>  
> > >>  }
> > >>  EXPORT_SYMBOL_GPL(pci_fixup_irqs);
> > >>
> > >>+
> > >>+struct pci_bus_fixup_cb_info {
> > >>+ u8 (*swizzle)(struct pci_dev *, u8 *);
> > >>+ int (*map_irq)(const struct pci_dev *, u8, u8);
> > >>+};
> > >>+
> > >>+static int pci_bus_fixup_irq_cb(struct pci_dev *dev, void *arg)
> > >>+{
> > >>+ struct pci_bus_fixup_cb_info *info = arg;
> > >>+
> > >>+ pdev_fixup_irq(dev, info->swizzle, info->map_irq);
> > >>+ return 0;
> > >>+}
> > >>+
> > >>+/*
> > >>+ * Fixup the irqs only for devices on the given bus using supplied
> > >>+ * swizzle and map_irq function pointers
> > >>+ */
> > >>+void pci_bus_fixup_irqs(struct pci_bus *bus,
> > >>+ u8 (*swizzle)(struct pci_dev *, u8 *),
> > >>+ int (*map_irq)(const struct pci_dev *, u8, u8))
> > >>+{
> > >>+ struct pci_bus_fixup_cb_info info;
> > >>+
> > >>+ info.swizzle = swizzle;
> > >>+ info.map_irq = map_irq;
> > >>+ pci_walk_bus(bus, pci_bus_fixup_irq_cb, );
> > >
> > >I don't like the existing pci_fixup_irqs(), so by transitivity, I
> > >don't like pci_bus_fixup_irqs() either.
> > 
> > We are in agreement with respect to this point.
> > 
> > > The problem is that in both
> > >
> > >cases this is a one-time pass over the tree, so we don't handle
> > >hot-added devices correctly.
> > >
> > >I think we need to get rid of pci_fixup_irqs() and somehow integrate
> > >it into the pci_device_add() path, where it would be done once for
> > >every device we enumerate.
> > 
> > I also agree with this point.
> > 
> > > If we did that, I don't think you would
> > >
> > >need to add pci_bus_fixup_irqs(), would you?
> > 
> > Nope.
> > 
> > However, such a change is essentially untestable by me.  So, I
> > didn't attempt it.   pci_fixup_irqs() is used by alpha, arm, m68k,
> > mips, sh, sparc, tile, unicore32 and other things as well.  If the
> > core pci_device_add() code were to suddenly start doing the fixup,
> > there would be the potential to break all these things I cannot
> > test.
> 
> Yep, that's certainly a risk.  I can't test all those arches either,
> but I think it's a risk worth taking because the end result is more
> maintainable.
> 
> Matthew Minter did some really nice work on this last year, but it got
> stalled somehow.  I wonder if we can resurrect it?  It seems like it
> was pretty close to being ready.  Here's a pointer to the last posting
> I saw:
> 
> http://lkml.kernel.org/r/141866-21068-1-git-send-email-m...@masarand.com
> 
> Bjorn

Thanks for adding me into the loop,

Yes, I had been working on this last year, and got a patchset that was tested 
on arm, x86 (and amd64), and slightly tested on powerpc. However I was not 
able to test other architectures as they were not available in the software 
lab I work in but should in theory work on all arches the kernel runs on.

I can say that that patchset is being used by several projects out of tree 
currently but unfortunately due to a shift in priorities in the lab I was 
working for I lost access to the resources to develop and test the patch 
easily.

I have done some additional work personally on it but so far have not got 
anything that I am happy to submit for inclusion in tree. (due to a number of 
issues in structure and  a complication relating to weak functions where 
multiple variations of the same arch exist.

You can see in thread that is linked above 
(http://lkml.kernel.org/r/141866-21068-1-git-send-email-m...@masarand.com)
some feedback on the issues that need to be solved.

I also expect that the patchset needs to be pulled forward to a newer kernel 
as I have been working in a frozen tree without rebasing to reduce test 
complexity.

I would be happy to put some time this weekend if possible into reviewing the 
state of this and seeing if I can at least put together a version running on a 
recent kernel. I can also go over the issues again which were proving 
problematic and 

RE: [PATCH 0/9] drivers:mtd:UBI: add bakvol module for MLC NAND paired page issue

[beanhuo]

> Am 30.09.2015 um 08:55 schrieb Richard Weinberger:
> >> By the way, Do you review my patches series ? I don't backup duplicated
> data in OOB .
> >> Can you specify which sector codes ? so that I can explain it in detail.
> >
> > Okay. Maybe both Boris and I misread your code, can you please explain
> > in detail what functions like check_original_data() or
> mtd_write_dual_plane_oob() do?
> 
> Care to explain?
> Maybe we can find a solution without OOB.
> Boris proposed already some very promising ideas:
> http://comments.gmane.org/gmane.linux.drivers.mtd/61658

> BTW: Will you be at Embedded Linuxcon Europe in Dublin?
> Many MTD guys, including me, will be there.
> Maybe we can discuss the problem in a nice pub, first round is on me. :-)

Richard, thanks for your care about this patch. We are all very happy to do 
this job.
I think ,any comments or suggests welcome. we now in China, so maybe it is not 
convenient for us
to discuss the problem in a nice pub. can we create a topic or main project 
about this issue, then we can 
work on it together. It is easy to trace and review.

This year, we ever attended Embedded Linux conference that held at San Jose 
Marriott,
and met Brain, Brain. We had a short discussion about paired page issue.
One of concerns is patent, you know , there are so many patents on how to solve 
paired page issue.
Linux seems that not very like to one accept patch based on certain patent.

I want to say, my this series patch is also based on a Micron patent, this is 
also one of my key concerns.
I don't know, how do you think about this.

For my this patch, another key concern is that memory overhead, maybe you have 
found that 
Reserved 20 PEBs for backup log volume, but these 20 PEBs will be soon quickly 
used up, because of dual plane program
Page address special requirement.



> Thanks,
> //richard
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

RE: [PATCH] vf610_adc: Fix internal temperature calculation

[Duan Andy]

From: Jonathan Cameron  Sent: Sunday, September 27, 2015 
11:53 PM
> To: Bhuvanchandra DV; linux-...@vger.kernel.org
> Cc: ste...@agner.ch; maitysancha...@gmail.com; Duan Fugang-B38611;
> knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; shawn@linaro.org;
> linux-kernel@vger.kernel.org; Duan Fugang-B38611
> Subject: Re: [PATCH] vf610_adc: Fix internal temperature calculation
> 
> On 23/09/15 14:43, Bhuvanchandra DV wrote:
> > There is an observed temperature difference of ~20°C with the internal
> > temperature reading and the temperature measured on SoC package.
> > Existing calculations consider the typical values provided in
> > datasheet. Those typical values are valid for VREFH_ADC at 3.0V.
> > Voltage at 25°C is different for different VREFH_ADC voltages. With
> > VREFH_ADC at 3.3V, voltage at 25°C is 0.699V. Hence update the VTEMP25
> > to 0.699V which gives ADCR@Temp25 as 867 and the final temperature
> > readings differs with ~5°C from the external readings.
> >
> > Formula for finding ADCR@Temp25:
> > ADCR@Temp25 = (ADCR@Vdd * V@TEMP25 * 10) / VDDconv
> >
> > ADCR@Vdd for 12-Bit ADC = 4095
> > VDDconv = VREFH_ADC * 10
> >
> > VREFH_ADC@3.3V
> > ADCR@Temp25 = (4095 * .699 * 10) / 33
> > ADCR@Temp25 ~= 867
> >
> > | VREFH_ADC | V@TEMP25 | VDDconv | ADCR@Temp25 |
> > |   3.0V| 0.696mV  |30   | 950 |
> > |   3.3V| 0.699mV  |33   | 867 |
> >
> > Signed-off-by: Bhuvanchandra DV 
> Looks fine to me, but I'll need an Ack from Fugang on this one as I don't
> know or have the part I'm afraid.
> 
> Jonathan

The patch is fine for me. Sorry for the late response due to vacation.

Acked-by: Fugang Duan 

> > ---
> >  drivers/iio/adc/vf610_adc.c | 19 ++-
> >  1 file changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
> > index f4df2a7..e7abc13 100644
> > --- a/drivers/iio/adc/vf610_adc.c
> > +++ b/drivers/iio/adc/vf610_adc.c
> > @@ -103,6 +103,13 @@
> >
> >  #define DEFAULT_SAMPLE_TIME1000
> >
> > +/* V at 25°C of 696 mV */
> > +#define VF610_VTEMP25_3V0  950
> > +/* V at 25°C of 699 mV */
> > +#define VF610_VTEMP25_3V3  867
> > +/* Typical sensor slope coefficient at all temperatures */
> > +#define VF610_TEMP_SLOPE_COEFF 1840
> > +
> >  enum clk_sel {
> > VF610_ADCIOC_BUSCLK_SET,
> > VF610_ADCIOC_ALTCLK_SET,
> > @@ -636,11 +643,13 @@ static int vf610_read_raw(struct iio_dev
> *indio_dev,
> > break;
> > case IIO_TEMP:
> > /*
> > -   * Calculate in degree Celsius times 1000
> > -   * Using sensor slope of 1.84 mV/°C and
> > -   * V at 25°C of 696 mV
> > -   */
> > -   *val = 25000 - ((int)info->value - 864) * 100 /
> 1840;
> > +* Calculate in degree Celsius times 1000
> > +* Using the typical sensor slope of 1.84 mV/°C
> > +* and VREFH_ADC at 3.3V, V at 25°C of 699 mV
> > +*/
> > +   *val = 25000 - ((int)info->value - VF610_VTEMP25_3V3) *
> > +   100 / VF610_TEMP_SLOPE_COEFF;
> > +
> > break;
> > default:
> > mutex_unlock(_dev->mlock);
> >
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [alsa-devel] [PATCH 1/2] ASoC: rockchip: i2s: add 8 channels capture and lrck-mode support

[sugar]

Hi Caleb,

we haven't support 16 channels capture and playback yet, would you mind 
to detail the use case? if must, we may support this feature on next 
generation chip.


在 10/7/2015 21:04, Caleb Crome 写道:

Hi sugar,
Can the rockchip support more than 8 channels?  Ideally, we would like to 
capture 16 channels and playback 16 channels simultaneously.

Thanks,  Caleb

Sent from my iPhone


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/7/15 11:36 AM, Rob Herring wrote:

On Wed, Oct 7, 2015 at 5:36 AM, Andrew  wrote:

On 2015-10-07 02:01, Laura Abbott wrote:


On 10/6/15 3:35 PM, Rob Herring wrote:


On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
wrote:


From: Laura Abbott 


This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic set of heaps and
their properties.

Signed-off-by: Laura Abbott 
Signed-off-by: Andrew Andrianov 
---
   drivers/staging/android/ion/devicetree.txt | 53
++



I have no issue with this going in here, but I do have lots of issues
with this binding.


   1 file changed, 53 insertions(+)
   create mode 100644 drivers/staging/android/ion/devicetree.txt

diff --git a/drivers/staging/android/ion/devicetree.txt
b/drivers/staging/android/ion/devicetree.txt
new file mode 100644
index 000..4a0c941
--- /dev/null
+++ b/drivers/staging/android/ion/devicetree.txt
@@ -0,0 +1,53 @@
+Ion Memory Manager
+
+Ion is a memory manager that allows for sharing of buffers via dma-buf.
+Ion allows for different types of allocation via an abstraction called
+a 'heap'. A heap represents a specific type of memory. Each heap has
+a different type. There can be multiple instances of the same heap
+type.
+
+Required properties for Ion
+
+- compatible: "linux,ion"
+
+All child nodes of a linux,ion node are interpreted as heaps
+
+required properties for heaps
+
+- linux,ion-heap-id: The Ion heap id used for allocation selection
+- linux,ion-heap-type: Ion heap type defined in ion.h
+- linux,ion-heap-name: Human readble name of the heap
+
+
+Optional properties
+- memory-region: A phandle to a memory region. Required for DMA heap
type
+(see reserved-memory.txt for details on the reservation)
+- linux,ion-heap-align: Alignment for the heap.
+
+Example:
+
+   ion {
+   compatbile = "linux,ion";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ion-system-heap {
+   linux,ion-heap-id = <0>;
+   linux,ion-heap-type = ;
+   linux,ion-heap-name = "system";



How does this vary across platforms? Is all of this being pushed down
to DT, because there is no coordination of this at the kernel ABI
level across platforms. In other words, why can't heap 0 be hardcoded
as system heap in the driver. It seems to me any 1 of these 3
properties could be used to derive the other 2.



Right now there is no guarantee heap IDs will be the same across
platforms. The heap IDs are currently part of the userspace ABI
as well since userspace clients must pass in a mask of the heap
IDs to allocate from. If we assume all existing clients could change,
heaps such as the system heap could be mandated to have the same
heap ID but we'd still run into problems if you have multiple
heaps of the same type (e.g. multiple carveouts)


Vendors largely ignore the kernel-userspace ABI and anything in
staging is not a ABI. So arguments about what the ABI is currently is
pointless IMO.

Pushing an inconsistent kernel ABI to DT is not the answer.



I'm not sure I agree it's inconsistent because it varies across
platforms. IRQs vary across platforms (yes I know something something
hardware description). Vendors really should be caring about ABIs
and it's kind of a chicken and egg problem about when staging
driver ABIs should be considered stable. Perhaps it should be
"Pushing bad kernel ABIs to DT is not the answer" which is a
fair objection to Ion.



I don't really like the idea of enforcing any IDs here. As of now
heap ids are generally something VERY platform-specific
(or even product-specific). Personally I'd prefer something like this
for userspace apps:

int id1 = ion_get_heap_id("camera");
if (id1 < 0) {
   fprintf(stderr, "Invalid heap id");
   exit(1);
}

int id2 = ion_get_heap_id("backup-heap");
if (id2 < 0) {
   fprintf(stderr, "Invalid heap id");
   exit(1);
}


We've learned that creating number spaces like this are bad (irqs,
gpios, /dev nodes). We should move away from that. Why should
userspace care about IDs or what the IDs are? An ID is just encoding
certain implicit requirements. So are the strings here. Users should
express what capabilities, restrictions, etc. they have, and then the
kernel can find the best heap.



I'd argue that the heap IDs are expressing capabilities and
restrictions. A heap ID for camera could be contiguous on
one system and discontiguous on another based on the system.
The user only gives the ID, not the type so it's ultimately
up to the kernel to decide what that heap ID means on a particular
system. Ion allows or'ing of heap IDs together and the kernel
selects them currently based on priority. What's your idea for
expressing the capabilities without resorting IDs?

I'm going to give some more thought to this but I think I
might look into just having each heap be a compatible
string. This might fit in better with 

Re: [PATCH 1/2] ASoC: WM8962: mark cache_dirty flag after software reset in pm_resume

[Jiada Wang]

Hi

On 10/06/2015 07:59 PM, Mark Brown wrote:

On Tue, Oct 06, 2015 at 04:06:54PM +0900, Jiada Wang wrote:


+   /* All registers have been reset to default value without calling
+* to regmap interface, even if reset fails, some registers
+* maybe in intermediate status, so we need to mark regmap
+* cache_dirty flag.
+*/
+   regcache_mark_dirty(wm8962->regmap);


This is a standard thing that applies to almost all devices, there
should be no need for such an extensive comment (which would normally
flag up that there's something weird and surprising going on).



Will remove the comment in next update
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-all] [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

[Fengguang Wu]

On Thu, Oct 08, 2015 at 09:06:03AM +0800, Fengguang Wu wrote:
> On Thu, Oct 08, 2015 at 11:11:59AM +1100, Michael Ellerman wrote:
> > On Wed, 2015-10-07 at 21:56 +0800, Fengguang Wu wrote:
> > > On Tue, Oct 06, 2015 at 02:39:06PM +1100, Michael Ellerman wrote:
> > > > On Sat, 2015-10-03 at 04:33 +0800, kbuild test robot wrote:
> > > > > Hi Nishanth,
> > > > > 
> > > > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, 
> > > > > please ignore]
> > > > > 
> > > > > config: powerpc-defconfig (attached as .config)
> > > > > reproduce:
> > > > > wget 
> > > > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > > > >  -O ~/bin/make.cross
> > > > > chmod +x ~/bin/make.cross
> > > > > # save the attached .config to linux build tree
> > > > > make.cross ARCH=powerpc 
> > > > > 
> > > > > All error/warnings (new ones prefixed by >>):
> > > > > 
> > > > >arch/powerpc/platforms/pseries/iommu.c: In function 
> > > > > 'iommu_init_early_pSeries':
> > > > > >> arch/powerpc/platforms/pseries/iommu.c:1433:9: error: 'struct 
> > > > > >> machdep_calls' has no member named 'dma_get_page_shift'
> > > > >   ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
> > > > 
> > > > It was added in patch 3/5, so I think this error is bogus. Unless 
> > > > there's a
> > > > typo I'm missing?
> > > 
> > > Yes sorry, the patchset was not detected correctly in your case,
> > > ending up the patches being tested as individual ones.
> > > 
> > > I'll fixup the robot.
> > 
> > Thanks.
> > 
> > How did the robot decide to build this series in the first place? Does it 
> > build
> > everything sent to one of the lists on CC?
> 
> Yes, currently the following mailing lists are subscribed.  Patches
> sent to them will be tested if they can be git-am to RC or linux-next
> kernels:
> 
> kvm
> linux-acpi
> linux-bluetooth
> linux-btrfs
> linux-embedded
> linux-ext4
> linux-fsdevel
> linux-media
> linux-mmc
> linux-nfs
> linux-omap
> linux-pci
> linux-pm
> linux-raid
> linux-rdma
> linux-scsi
> linux-usb
> linux-wireless
> netdev
> netfilter-devel
> linux-mm
> driverdev-devel
> intel-gfx

And of course linux-kernel. More lists could be added in future.

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] HID: multitouch: Fetch feature reports on demand for Win8 devices

[Andrew Duggan]

On 10/07/2015 08:56 AM, Seth Forshee wrote:

On Wed, Oct 07, 2015 at 09:34:10AM -0400, Benjamin Tissoires wrote:

[sorry for the late answer Jiri, I was on vacations last week]

On Oct 07 2015 or thereabouts, Mika Westerberg wrote:

Some newer Intel Skylake based Dell laptops with Win8 precision touchpad
fail when initial feature reports are fetched from it. Below is an example
output with some additional debug included:

  i2c_hid i2c-DLL0704:01: Fetching the HID descriptor
  i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00
  i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ...
  ...
  i2c_hid i2c-DLL0704:01: i2c_hid_get_report
  i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00
  i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05
  i2c_hid i2c-DLL0704:01: report id 13
  i2c_hid i2c-DLL0704:01: i2c_hid_get_report
  i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00
  i2c_hid i2c-DLL0704:01: failed to retrieve report from device.
  i2c_hid i2c-DLL0704:01: report id 7
  i2c_hid i2c-DLL0704:01: i2c_hid_get_report
  i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00
  i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ...
  i2c_hid i2c-DLL0704:01: report id 4
  i2c_hid i2c-DLL0704:01: i2c_hid_get_report
  i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00

We manage to fetch few reports but then the touchpad dies:

  i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration
  i2c_hid i2c-DLL0704:01: failed to retrieve report from device.

it eventually pulls the whole I2C bus low:

  i2c_designware i2c_designware.1: controller timed out
  i2c_hid i2c-DLL0704:01: failed to set a report to device.

Fix this by preventing initial feature report retrieval for Win8 devices.
Instead we fetch reports as needed in mt_feature_mapping(). This prevents
fetching reports which might cause problems with the device in question.

Suggested-by: Benjamin Tissoires 
Signed-off-by: Mika Westerberg 
---
Added check for MT_CLS_WIN_8 so that the fix is only done for real Win8
devices.

I think we are good now. I would just like to have Seth or Andrew giving
a tested-by for Windows precision touchpads that can be found on the Dell
laptops.

If the buttonpad property is set correctly, this is:
Reviewed-by: Benjamin Tissoires 

This is working fine on my XPS 13 9343.

Tested-by: Seth Forshee 
I can confirm that it is working on the Dell XPS 13 and the buttonpad 
property is set correctly. However, I also tried it on an older non 
production precision touchpad and it didn't work. It reports that it 
fails to fetch feature 8 and then doesn't report any input. I'm 
concerned that some of the early PTPs in some Dell and Acer systems 
might not work with this change. I'll test this tomorrow on a few more 
systems to see if the problem is isolated to just this one non 
production touchpad.


[ 2969.222125] usb 1-1: New USB device found, idVendor=06cb, idProduct=2393
[ 2969.222128] usb 1-1: New USB device strings: Mfr=0, Product=2, 
SerialNumber=0

[ 2969.222130] usb 1-1: Product: Synaptics T Pad V 01.31
[ 2974.223578] hid-multitouch 0003:06CB:2393.0008: failed to fetch feature 8
[ 2979.226037] hid-multitouch 0003:06CB:2393.0008: failed to fetch feature 8
[ 2979.226137] input: Synaptics T Pad V 01.31 UNKNOWN as 
/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.0/0003:06CB:2393.0008/input/input34
[ 2979.226431] hid-multitouch 0003:06CB:2393.0008: 
input,hiddev0,hidraw2: USB HID v1.11 Mouse [Synaptics T Pad V 01.31] on 
usb-:00:14.0-1/input0


Feature 8 looks like this:
  FEATURE(8)[FEATURE]
Field(0)
  Application(Digitizers.TouchPad)
  Usage(2)
Digitizers.ContactMaximumNumber
Digitizers.ButtonType
  Logical Minimum(0)
  Logical Maximum(15)
  Physical Minimum(0)
  Physical Maximum(65535)
  Unit Exponent(-4)
  Unit(SI Linear : Seconds)
  Report Size(4)
  Report Count(2)
  Report Offset(0)
  Flags( Variable Absolute )

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()

[Tejun Heo]

Hello, Dave.

On Thu, Oct 08, 2015 at 12:02:18PM +1100, Dave Chinner wrote:
> > percpu cmpxchg is no different from sub or any other operations
> > regarding cross-CPU synchronization.  They're safe iff the operations
> > are on the local CPU.  They have to be made atomics if they need to be
> > manipulated from remote CPUs.
> 
> Again, another trivially solvable problem, but still irrelevant
> because we don't have the data that tells us whether changing the
> counter behaviour solves the problem

Dude, it isn't trivially solvable.  You either can't do it or have to
pay the overhead during local access to get around it.

> > That said, while we can't manipulate the percpu counters directly, we
> > can add a separate global counter to cache sum result from the
> > previous run which gets automatically invalidated when any percpu
> > counter overflows.
> >
> > That should give better and in case of
> > back-to-back invocations pretty good precision compared to just
> > returning the global overflow counter.  Interface-wise, that'd be a
> > lot easier to deal with although I have no idea whether it'd fit this
> > particular use case or whether this use case even exists.
> 
> No, it doesn't help - it's effectively what Waiman's original patch
> did by returning the count from the initial comparison and using
> that for ENOSPC detection instead of doing a second comparison...

Just chipping in purely from percpu side.  If what Waiman suggested is
something useable, caching the result inside percpu_counter would be a
better interface.  If not, no idea.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-all] [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

[Fengguang Wu]

On Thu, Oct 08, 2015 at 11:11:59AM +1100, Michael Ellerman wrote:
> On Wed, 2015-10-07 at 21:56 +0800, Fengguang Wu wrote:
> > On Tue, Oct 06, 2015 at 02:39:06PM +1100, Michael Ellerman wrote:
> > > On Sat, 2015-10-03 at 04:33 +0800, kbuild test robot wrote:
> > > > Hi Nishanth,
> > > > 
> > > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, 
> > > > please ignore]
> > > > 
> > > > config: powerpc-defconfig (attached as .config)
> > > > reproduce:
> > > > wget 
> > > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > > >  -O ~/bin/make.cross
> > > > chmod +x ~/bin/make.cross
> > > > # save the attached .config to linux build tree
> > > > make.cross ARCH=powerpc 
> > > > 
> > > > All error/warnings (new ones prefixed by >>):
> > > > 
> > > >arch/powerpc/platforms/pseries/iommu.c: In function 
> > > > 'iommu_init_early_pSeries':
> > > > >> arch/powerpc/platforms/pseries/iommu.c:1433:9: error: 'struct 
> > > > >> machdep_calls' has no member named 'dma_get_page_shift'
> > > >   ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
> > > 
> > > It was added in patch 3/5, so I think this error is bogus. Unless there's 
> > > a
> > > typo I'm missing?
> > 
> > Yes sorry, the patchset was not detected correctly in your case,
> > ending up the patches being tested as individual ones.
> > 
> > I'll fixup the robot.
> 
> Thanks.
> 
> How did the robot decide to build this series in the first place? Does it 
> build
> everything sent to one of the lists on CC?

Yes, currently the following mailing lists are subscribed.  Patches
sent to them will be tested if they can be git-am to RC or linux-next
kernels:

kvm
linux-acpi
linux-bluetooth
linux-btrfs
linux-embedded
linux-ext4
linux-fsdevel
linux-media
linux-mmc
linux-nfs
linux-omap
linux-pci
linux-pm
linux-raid
linux-rdma
linux-scsi
linux-usb
linux-wireless
netdev
netfilter-devel
linux-mm
driverdev-devel
intel-gfx

Thanks,
Fengguang

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Sebastian,

On Fri, 2 Oct 2015 11:49:32 +1000 Stephen Rothwell  
wrote:
>
> On Tue, 29 Sep 2015 11:45:31 +1000 Stephen Rothwell  
> wrote:
> >
> > After merging the battery tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> > 
> > ERROR (phandle_references): Reference to non-existent node or label 
> > "twl4030_madc"
> > ERROR: Input tree has errors, aborting (use -f to force output)
> > scripts/Makefile.lib:293: recipe for target 
> > 'arch/arm/boot/dts/omap3-beagle-xm-ab.dtb' failed
> > 
> > and many more ...
> > 
> > Caused by commit
> > 
> >   af19161aaed7 ("ARM: dts: twl4030: Add iio properties for bci subnode")
> > 
> > Presumably some updates to other files were missed.
> > 
> > I have used the battery tree from next-20150925 fot today.
> 
> I am still getting this error.

Ping?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()

[Dave Chinner]

On Wed, Oct 07, 2015 at 04:20:10PM -0700, Tejun Heo wrote:
> Hello, Dave.
> 
> On Thu, Oct 08, 2015 at 10:04:42AM +1100, Dave Chinner wrote:
> ...
> > As it is, the update race you pointed out is easy to solve with
> > __this_cpu_cmpxchg rather than _this_cpu_sub (similar to mod_state()
> > in the MM percpu counter stats code, perhaps).
> 
> percpu cmpxchg is no different from sub or any other operations
> regarding cross-CPU synchronization.  They're safe iff the operations
> are on the local CPU.  They have to be made atomics if they need to be
> manipulated from remote CPUs.

Again, another trivially solvable problem, but still irrelevant
because we don't have the data that tells us whether changing the
counter behaviour solves the problem

> That said, while we can't manipulate the percpu counters directly, we
> can add a separate global counter to cache sum result from the
> previous run which gets automatically invalidated when any percpu
> counter overflows.
>
> That should give better and in case of
> back-to-back invocations pretty good precision compared to just
> returning the global overflow counter.  Interface-wise, that'd be a
> lot easier to deal with although I have no idea whether it'd fit this
> particular use case or whether this use case even exists.

No, it doesn't help - it's effectively what Waiman's original patch
did by returning the count from the initial comparison and using
that for ENOSPC detection instead of doing a second comparison...

FWIW, XFS has done an expensive per-cpu counter sum in this ENOSPC
situation since 2006, but in 2007 ENOSPC was wrapped in a mutex to
prevent spinlock contention on the aggregated global counter:

commit 20b642858b6bb413976ff13ae6a35cc596967bab
Author: David Chinner 
Date:   Sat Feb 10 18:35:09 2007 +1100

[XFS] Reduction global superblock lock contention near ENOSPC.

The existing per-cpu superblock counter code uses the global superblock
spin lock when we approach ENOSPC for global synchronisation. On larger
machines than this code was originally tested on this can still get
catastrophic spinlock contention due increasing rebalance frequency near
ENOSPC.

By introducing a sleeping lock that is used to serialise balances and
modifications near ENOSPC we prevent contention from needlessly from
wasting the CPU time of potentially hundreds of CPUs.

To reduce the number of balances occuring, we separate the need rebalance
case from the slow allocate case. Now, a counter running dry will trigger
a rebalance during which counters are disabled. Any thread that sees a
disabled counter enters a different path where it waits on the new mutex.
When it gets the new mutex, it checks if the counter is disabled. If the
counter is disabled, then we _know_ that we have to use the global counter
and lock and it is safe to do so immediately. Otherwise, we drop the mutex
and go back to trying the per-cpu counters which we know were re-enabled.

SGI-PV: 952227
SGI-Modid: xfs-linux-melb:xfs-kern:27612a

Signed-off-by: David Chinner 
Signed-off-by: Lachlan McIlroy 
Signed-off-by: Tim Shimmin 

This is effectively the same symptoms that what we are seeing with
the new "lockless" generic percpu counteri algorithm, which is why
I'm trying to find out if it an issue with the counter
implementation before I do anything else...

FWIW, the first comparison doesn't need to be that precise as it
just changes the batch passed to percpu_counter_add() to get the
value folded back into the global counter immediately near ENOSPC.
This is done so percpu_counter_read() becomes more accurate as
ENOSPC is approached as that is used for monitoring and reporting
(e.g. via vfsstat). If we want to avoid a counter sum, then this
is the comparison we will need to modify in XFS.

However, the second comparison needs to be precise as that's the one
that does the ENOSPC detection. That sum needs to be done after the
counter add that "uses" the space and so there is no avoiding having
an expensive counter sum as we near ENOSPC

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 22/25] powerpc32: move xxxxx_dcache_range() functions inline

[Christophe Leroy]

Le 29/09/2015 02:29, Scott Wood a écrit :

On Tue, Sep 22, 2015 at 06:51:13PM +0200, Christophe Leroy wrote:

flush/clean/invalidate _dcache_range() functions are all very
similar and are quite short. They are mainly used in __dma_sync()
perf_event locate them in the top 3 consumming functions during
heavy ethernet activity

They are good candidate for inlining, as __dma_sync() does
almost nothing but calling them

Signed-off-by: Christophe Leroy 
---
New in v2

  arch/powerpc/include/asm/cacheflush.h | 55 +++--
  arch/powerpc/kernel/misc_32.S | 65 ---
  arch/powerpc/kernel/ppc_ksyms.c   |  2 ++
  3 files changed, 54 insertions(+), 68 deletions(-)

diff --git a/arch/powerpc/include/asm/cacheflush.h 
b/arch/powerpc/include/asm/cacheflush.h
index 6229e6b..6169604 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -47,12 +47,61 @@ static inline void __flush_dcache_icache_phys(unsigned long 
physaddr)
  }
  #endif
  
-extern void flush_dcache_range(unsigned long start, unsigned long stop);

  #ifdef CONFIG_PPC32
-extern void clean_dcache_range(unsigned long start, unsigned long stop);
-extern void invalidate_dcache_range(unsigned long start, unsigned long stop);
+/*
+ * Write any modified data cache blocks out to memory and invalidate them.
+ * Does not invalidate the corresponding instruction cache blocks.
+ */
+static inline void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+   void *addr = (void *)(start & ~(L1_CACHE_BYTES - 1));
+   unsigned int size = stop - (unsigned long)addr + (L1_CACHE_BYTES - 1);
+   unsigned int i;
+
+   for (i = 0; i < size >> L1_CACHE_SHIFT; i++, addr += L1_CACHE_BYTES)
+   dcbf(addr);
+   if (i)
+   mb();   /* sync */
+}

I know this is 32-bit-specific code, but it's still bad practice to use
"unsigned int" for addresses or sizes thereof.


Ok, I can fix size, but what about start and stop ? If I change that, it 
means I also have to fix all caller. Do you expect me to do that ?


And it is very unlykely, but what if for some reason someone wants to 
invalidate the entire user address space which is 3Gbytes size ? A 
signed size would be negative here.


Christophe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-all] [PATCH 2/2] mfd: rtsx: fix build warning

[Fengguang Wu]

On Wed, Oct 07, 2015 at 09:11:25PM +0530, Sudip Mukherjee wrote:
> On Wed, Oct 07, 2015 at 09:48:16PM +0800, Fengguang Wu wrote:
> > On Wed, Oct 07, 2015 at 06:16:52PM +0530, Sudip Mukherjee wrote:
> > > On Wed, Oct 07, 2015 at 08:40:37PM +0800, kbuild test robot wrote:
> > > > Hi Sudip,
> > > > 
> > > > [auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, 
> > > > please ignore]
> > > v4.3-rc4 is not appropriate base. Please use next-20151007 for both.
> > 
> > OK. FYI, if you use [PATCH (next|-next|linux-next)] next time,
> > the robot will select linux-next/master as the base tree.
> Ok. Great. And for staging should it be [PATCH staging-testing] ?

It looks some patches already use the form [PATCH staging], I wonder
which branch Greg typically apply them to, staging-testing or staging-next?

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] clk: bcm2835: Add support for programming the audio domain clocks.

[Stephen Boyd]

On 10/06, Eric Anholt wrote:
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index dd295e4..b4d4421 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -17,10 +17,273 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
> +#include 
> +#include 

Please include slab.h for the kzalloc usage

> +
> +
> +static struct clk *bcm2835_register_pll(struct bcm2835_cprman *cprman,
> + const struct bcm2835_pll_data *data)
> +{
> + struct bcm2835_pll *pll;
> + struct clk_init_data init;
> +
> + memset(, 0, sizeof(init));
> +
> + /* All of the PLLs derive from the external oscillator. */
> + init.parent_names = >osc_name;
> + init.num_parents = 1;
> + init.name = data->name;
> + init.ops = _pll_clk_ops;
> + init.flags = CLK_IGNORE_UNUSED;
> +
> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> + if (!pll)
> + return NULL;
> +
> + pll->cprman = cprman;
> + pll->data = data;
> + pll->hw.init = 
> +
> + return clk_register(cprman->dev, >hw);

devm_clk_register?

> +}
> +
> +static struct clk *
> +bcm2835_register_pll_divider(struct bcm2835_cprman *cprman,
> +  const struct bcm2835_pll_divider_data *data)
> +{
> + struct bcm2835_pll_divider *divider;
> + struct clk_init_data init;
> + struct clk *clk;
> + const char *divider_name;
> +
> + if (data->fixed_divider != 1) {
> + divider_name = devm_kasprintf(cprman->dev, GFP_KERNEL,
> +   "%s_prediv", data->name);
> + if (!divider_name)
> + return NULL;
> + } else {
> + divider_name = data->name;
> + }
> +
> + memset(, 0, sizeof(init));
> +
> + init.parent_names = >source_pll->name;
> + init.num_parents = 1;
> + init.name = divider_name;
> + init.ops = _pll_divider_clk_ops;
> + init.flags = (CLK_SET_RATE_PARENT |
> +   CLK_IGNORE_UNUSED);

Drop () and put on one line.

> +
> + divider = kzalloc(sizeof(*divider), GFP_KERNEL);

Use devm_kzalloc() to auto free on errors?

> + if (!divider)
> + return NULL;
> +
> + divider->div.reg = cprman->regs + data->a2w_reg;
> + divider->div.shift = A2W_PLL_DIV_SHIFT;
> + divider->div.width = A2W_PLL_DIV_BITS;
> + divider->div.flags = 0;
> + divider->div.lock = >regs_lock;
> + divider->div.hw.init = 
> + divider->div.table = NULL;
> +
> + divider->cprman = cprman;
> + divider->data = data;
> +
> + clk = clk_register(cprman->dev, >div.hw);

devm_clk_register?

> + if (IS_ERR(clk))
> + return clk;
> +
> + /*
> +  * PLLH's channels have a fixed divide by 10 afterwards, which
> +  * is what our consumers are actually using.
> +  */
> + if (data->fixed_divider != 1) {
> + return clk_register_fixed_factor(cprman->dev, data->name,
> +  divider_name,
> +  CLK_SET_RATE_PARENT,
> +  1,
> +  data->fixed_divider);
> + }
> +
> + return clk;
> +}
> +
> +static struct clk *bcm2835_register_clock(struct bcm2835_cprman *cprman,
> +   const struct bcm2835_clock_data *data)
> +{
[..]
> +
> + memset(, 0, sizeof(init));
> + init.parent_names = 
> + init.num_parents = 1;
> + init.name = data->name;
> + init.flags = CLK_IGNORE_UNUSED;
> +
> + if (data->is_vpu_clock) {
> + init.ops = _vpu_clock_clk_ops;
> + } else {
> + init.ops = _clock_clk_ops;
> + init.flags |= CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE;
> + }
> +
> + clock = kzalloc(sizeof(*clock), GFP_KERNEL);

devm_kzalloc()?

> + if (!clock)
> + return NULL;
> +
> + clock->cprman = cprman;
> + clock->data = data;
> + clock->hw.init = 
> +
> + return clk_register(cprman->dev, >hw);

devm_clk_register()?

> +}
> +
> +static int bcm2835_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct clk **clks;
> + struct bcm2835_cprman *cprman;
> +
> + cprman = devm_kzalloc(dev, sizeof(*cprman), GFP_KERNEL);
> + if (!cprman)
> + return -ENOMEM;
> +
> + spin_lock_init(>regs_lock);
> + cprman->dev = >dev;

Just use dev?

> + cprman->regs = of_iomap(dev->of_node, 0);

Please use platform driver APIs:

platform_get_resource()
devm_ioremap_resource()

> + if (!cprman->regs)
> + return -ENODEV;
> +
> + cprman->osc_name = of_clk_get_parent_name(dev->of_node, 0);
> + if (!cprman->osc_name) {
> + iounmap(cprman->regs);
> + return -ENODEV;
> + }
[...]
> +
> + /*
> +  * CM_PERIICTL 

[PATCH 2/5] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()

[Douglas Anderson]

From: Yunzhi Li 

We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should
be called before dwc2_get_hwparams() to reset core registers to
default value. Without this the FIFO setting might be incorrect
because calculating FIFO size need power-on value of
GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers.

This patch could avoid warnning massage like in rk3288 platform:
[2.074764] dwc2 ff58.usb: 256 invalid for
host_perio_tx_fifo_size. Check HW configuration.

Signed-off-by: Yunzhi Li 
Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/core.c | 2 +-
 drivers/usb/dwc2/core.h | 1 +
 drivers/usb/dwc2/platform.c | 6 ++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 43c8bf4..f2002d2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -481,7 +481,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg 
*hsotg)
  * Do core a soft reset of the core.  Be careful with this because it
  * resets all the internal state machines of the core.
  */
-static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset(struct dwc2_hsotg *hsotg)
 {
u32 greset;
int count = 0;
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index ebf2504..c258d19 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -862,6 +862,7 @@ enum dwc2_halt_status {
  * The following functions support initialization of the core driver component
  * and the DWC_otg controller
  */
+extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
 extern void dwc2_core_host_init(struct dwc2_hsotg *hsotg);
 extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
 extern int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index b920e43..d27521c 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -254,6 +254,12 @@ static int dwc2_driver_probe(struct platform_device *dev)
spin_lock_init(>lock);
mutex_init(>init_mutex);
 
+   /*
+* Reset before dwc2_get_hwparams() then it could get power-on real
+* reset value form registers.
+*/
+   dwc2_core_reset(hsotg);
+
/* Detect config values from hardware */
retval = dwc2_get_hwparams(hsotg);
if (retval)
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()

[Doug Anderson]

John,

On Mon, Oct 5, 2015 at 3:02 PM, John Youn  wrote:
> On 10/1/2015 1:50 PM, Doug Anderson wrote:
>> John,
>>
>> On Tue, Aug 18, 2015 at 5:19 PM, John Youn  wrote:
>>> Hi Yunzhi,
>>>
>>> My concern is with the delays due to calling the dwc2_core_reset
>>> during probe. You could factor out the assertion of the core
>>> soft reset from the dwc2_core_reset and just use that before
>>> calling dwc2_get_hwparams().
>>>
>>> You had previously addressed the lengthy probe time issue here:
>>> http://marc.info/?l=linux-usb=142357721304377
>>>
>>> This reducing delays patch looks reasonable to me and I think it
>>> should get merged also. I'll do some testing with it later this
>>> week.
>>
>> Note: you can also avoid the extra reset during probe with something
>> like .  I'm
>> happy to post that up if you want, though it depends on lyz's patch.
>>
>> ...in Chrome OS we've also just landed lyz's patch to reduce delays.
>> If there's any fallout I'll report on the list.
>>
>> -Doug
>>
>
>
> Yes, I appreciate if you could submit that. I'd like to merge lyz's
> reduce delays, lyz's bug fix for hwparams, and your fix for double
> reset.

OK, I've posted things up.  Let me know what you think.  Note that I
took v2 of lyz's patch (not v3) since I liked it better.


> The gadget side will also need something similar which I can do if
> needed. Do you guys run gadget mode?

I don't personally run in gadget mode.  I think it's possible to get
rk3288 to do it on one of the two ports, but I don't have it setup.


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 0/9] drivers:mtd:UBI: add bakvol module for MLC NAND paired page issue

[beanhuo]

> > > As stated before, using OOB in UBI is not going to happen unless
> > > proven that there is absolutely no other way to solve the paired pages
> problem.
> > >
> > > Nacked-by: Richard Weinberger 
> > >
> > > Sorry,
> > > //Richard
> >
> > Hi, Richard
> > Thanks for your concern. I am a new patch submitter.
> > Can you tell me Nacked-by means?
> >
> > By the way, Do you review my patches series ? I don't backup duplicated
> >data in OOB .
> 
> That's not what Richard said, he just pointed that you were using the OOB
> area, and you're actually using it to store the information about which page
> you're backuping.
> 
> > Can you specify which sector codes ? so that I can explain it in detail.
> 
> And as answered by Richard, check_original_data() and
> mtd_write_dual_plane_oob() are filling the OOB buf with the original page
> offset, so you're definitely using the OOB area to store metadata.

Yes ,currently I only use 4 bytes OOB area to store backup page address.

> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH 4/5] usb: dwc2: Speed dwc2_get_hwparams() on some host-only ports

[Douglas Anderson]

On some host-only DWC2 ports (like the one in rk3288) when we set
GUSBCFG_FORCEHOSTMODE in GUSBCFG and then read back, we don't see the
bit set.  Presumably that's because the port is always forced to HOST
mode so there's no reason to implement these status bits.

Since we know dwc2_core_reset() is always called before
dwc2_get_hwparams() and we know dwc2_core_reset() should have set
GUSBCFG_FORCEHOSTMODE whenever hsotg->dr_mode == USB_DR_MODE_HOST, we
can just check hsotg->dr_mode to decide that we can skip the delays in
dwc2_get_hwparams().

Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/core.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 9f1c438..27ade0c 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -3070,7 +3070,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
unsigned width;
u32 hwcfg1, hwcfg2, hwcfg3, hwcfg4;
u32 hptxfsiz, grxfsiz, gnptxfsiz;
-   u32 gusbcfg;
+   u32 gusbcfg = 0;
 
/*
 * Attempt to ensure this device is really a DWC_otg Controller.
@@ -3103,8 +3103,8 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
dev_dbg(hsotg->dev, "grxfsiz=%08x\n", grxfsiz);
 
/* Force host mode to get HPTXFSIZ / GNPTXFSIZ exact power on value */
-   gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
-   if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+   if (hsotg->dr_mode != USB_DR_MODE_HOST) {
+   gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
dwc2_writel(gusbcfg | GUSBCFG_FORCEHOSTMODE,
hsotg->regs + GUSBCFG);
usleep_range(10, 15);
@@ -3114,7 +3114,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
hptxfsiz = dwc2_readl(hsotg->regs + HPTXFSIZ);
dev_dbg(hsotg->dev, "gnptxfsiz=%08x\n", gnptxfsiz);
dev_dbg(hsotg->dev, "hptxfsiz=%08x\n", hptxfsiz);
-   if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+   if (hsotg->dr_mode != USB_DR_MODE_HOST) {
dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
usleep_range(10, 15);
}
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] usb: dwc2: reduce dwc2 driver probe time

[Douglas Anderson]

From: Yunzhi Li 

I found that the probe function of dwc2 driver takes much time
when kernel boot up. There are many long delays in the probe
function these take almost 1 second.

This patch trying to reduce unnecessary delay time.

In dwc2_core_reset() I see it use two at least 20ms delays to
wait AHB idle and core soft reset, but dwc2 data book said that
dwc2 core soft reset and AHB idle just need a few clocks (I think
it refers to AHB clock, and AHB clock run at 150MHz in my RK3288
board), so 20ms is too long, delay 1us for wait AHB idle and soft
reset is enough.

And in dwc2_get_hwparams() it takes 150ms to wait ForceHostMode
and ForceDeviceMode valid but in data book it said software must
wait at least 25ms before the change to take effect, so I reduce
this time to 25ms~50ms. By the way, is there any state bit show
that the force mode take effect ? Could we poll curmod bit for
figuring out if the change take effect ?

It seems that usleep_range() at boot time will pick the longest
value in the range. In dwc2_core_reset() there is a very long
delay takes 200ms, and this function run twice when probe, could
any one tell me is this delay time resonable ?

I have tried this patch in my RK3288-evb board. It works well.

Signed-off-by: Yunzhi Li 
Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 27ade0c..59fe48f 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -491,7 +491,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
 
/* Wait for AHB master IDLE state */
do {
-   usleep_range(2, 4);
+   udelay(1);
greset = dwc2_readl(hsotg->regs + GRSTCTL);
if (++count > 50) {
dev_warn(hsotg->dev,
@@ -506,7 +506,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
greset |= GRSTCTL_CSFTRST;
dwc2_writel(greset, hsotg->regs + GRSTCTL);
do {
-   usleep_range(2, 4);
+   udelay(1);
greset = dwc2_readl(hsotg->regs + GRSTCTL);
if (++count > 50) {
dev_warn(hsotg->dev,
@@ -537,7 +537,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
 * NOTE: This long sleep is _very_ important, otherwise the core will
 * not stay in host mode after a connector ID change!
 */
-   usleep_range(15, 20);
+   usleep_range(15, 16);
 
return 0;
 }
@@ -3107,7 +3107,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
dwc2_writel(gusbcfg | GUSBCFG_FORCEHOSTMODE,
hsotg->regs + GUSBCFG);
-   usleep_range(10, 15);
+   usleep_range(25000, 5);
}
 
gnptxfsiz = dwc2_readl(hsotg->regs + GNPTXFSIZ);
@@ -3116,7 +3116,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
dev_dbg(hsotg->dev, "hptxfsiz=%08x\n", hptxfsiz);
if (hsotg->dr_mode != USB_DR_MODE_HOST) {
dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
-   usleep_range(10, 15);
+   usleep_range(25000, 5);
}
 
/* hwcfg2 */
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] usb: dwc2: Restore GUSBCFG in dwc2_get_hwparams()

[Douglas Anderson]

Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make sure dwc2_get_hwparams() isn't messing with things in a
permanent way.

Since we're now looking at GUSBCFG, it's obvious that we shouldn't need
all the extra delays if FORCEHOSTMODE was already set.  This will avoid
some delays for any ports that have forced host mode.

Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/core.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index bf5e951..43c8bf4 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -3097,18 +3097,20 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
 
/* Force host mode to get HPTXFSIZ / GNPTXFSIZ exact power on value */
gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
-   gusbcfg |= GUSBCFG_FORCEHOSTMODE;
-   dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
-   usleep_range(10, 15);
+   if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+   dwc2_writel(gusbcfg | GUSBCFG_FORCEHOSTMODE,
+   hsotg->regs + GUSBCFG);
+   usleep_range(10, 15);
+   }
 
gnptxfsiz = dwc2_readl(hsotg->regs + GNPTXFSIZ);
hptxfsiz = dwc2_readl(hsotg->regs + HPTXFSIZ);
dev_dbg(hsotg->dev, "gnptxfsiz=%08x\n", gnptxfsiz);
dev_dbg(hsotg->dev, "hptxfsiz=%08x\n", hptxfsiz);
-   gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
-   gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
-   dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
-   usleep_range(10, 15);
+   if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+   dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
+   usleep_range(10, 15);
+   }
 
/* hwcfg2 */
hw->op_mode = (hwcfg2 & GHWCFG2_OP_MODE_MASK) >>
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] CHROMIUM: usb: dwc2: Avoid double-reset at boot time

[Douglas Anderson]

In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an
extra reset to the probe path for the dwc2 USB controllers.  This
allowed proper detection of parameters even if the firmware had already
used the USB part.

Unfortunately, this extra reset is quite slow and is affecting boot
speed.  We can avoid the double-reset by skipping the extra reset that
would happen just after the one we added.  Logic that explains why this
is safe:

* As of the CL mentioned above, we now always call dwc2_core_reset() in
  dwc2_driver_probe() before dwc2_hcd_init().

* The only caller of dwc2_hcd_init() is dwc2_driver_probe(), so we're
  guaranteed that dwc2_core_reset() was called before dwc2_hdc_init().

* dwc2_hdc_init() is the only caller that passes an irq other than -1 to
  dwc2_core_init().  Thus if dwc2_core_init() is called with an irq
  other than -1 we're guaranteed that dwc2_core_reset was called before
  dwc2_core_init().

...this allows us to remove the dwc2_core_reset() in dwc2_core_init() if
irq is not < 0.

Note that since "irq" wasn't used in the function dwc2_core_init()
anyway and since select_phy was always set at exactly the same times we
could avoid the reset, we remove "irq" and rename "select_phy" to
"initial_setup" and adjust the callers accordingly.

Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/core.c | 29 ++---
 drivers/usb/dwc2/core.h |  2 +-
 drivers/usb/dwc2/hcd.c  |  6 +++---
 3 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index f2002d2..9f1c438 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -765,11 +765,10 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
  * dwc2_core_init() - Initializes the DWC_otg controller registers and
  * prepares the core for device mode or host mode operation
  *
- * @hsotg:  Programming view of the DWC_otg controller
- * @select_phy: If true then also set the Phy type
- * @irq:If >= 0, the irq to register
+ * @hsotg: Programming view of the DWC_otg controller
+ * @initial_setup: If true then this is the first init for this instance.
  */
-int dwc2_core_init(struct dwc2_hsotg *hsotg, bool select_phy, int irq)
+int dwc2_core_init(struct dwc2_hsotg *hsotg, bool initial_setup)
 {
u32 usbcfg, otgctl;
int retval;
@@ -791,18 +790,26 @@ int dwc2_core_init(struct dwc2_hsotg *hsotg, bool 
select_phy, int irq)
 
dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
 
-   /* Reset the Controller */
-   retval = dwc2_core_reset(hsotg);
-   if (retval) {
-   dev_err(hsotg->dev, "%s(): Reset failed, aborting\n",
-   __func__);
-   return retval;
+   /*
+* Reset the Controller
+*
+* We only need to reset the controller if this is a re-init.
+* For the first init we know for sure that earlier code reset us (it
+* needed to in order to properly detect various parameters).
+*/
+   if (!initial_setup) {
+   retval = dwc2_core_reset(hsotg);
+   if (retval) {
+   dev_err(hsotg->dev, "%s(): Reset failed, aborting\n",
+   __func__);
+   return retval;
+   }
}
 
/*
 * This needs to happen in FS mode before any other programming occurs
 */
-   retval = dwc2_phy_init(hsotg, select_phy);
+   retval = dwc2_phy_init(hsotg, initial_setup);
if (retval)
return retval;
 
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index c258d19..d707a7b 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -900,7 +900,7 @@ extern void dwc2_read_packet(struct dwc2_hsotg *hsotg, u8 
*dest, u16 bytes);
 extern void dwc2_flush_tx_fifo(struct dwc2_hsotg *hsotg, const int num);
 extern void dwc2_flush_rx_fifo(struct dwc2_hsotg *hsotg);
 
-extern int dwc2_core_init(struct dwc2_hsotg *hsotg, bool select_phy, int irq);
+extern int dwc2_core_init(struct dwc2_hsotg *hsotg, bool initial_setup);
 extern void dwc2_enable_global_interrupts(struct dwc2_hsotg *hcd);
 extern void dwc2_disable_global_interrupts(struct dwc2_hsotg *hcd);
 
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index af4e4a2..e2286cf 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1381,7 +1381,7 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
dev_err(hsotg->dev,
"Connection id status change timed out\n");
hsotg->op_state = OTG_STATE_B_PERIPHERAL;
-   dwc2_core_init(hsotg, false, -1);
+   dwc2_core_init(hsotg, false);
dwc2_enable_global_interrupts(hsotg);
spin_lock_irqsave(>lock, flags);
dwc2_hsotg_core_init_disconnected(hsotg, false);
@@ -1404,7 +1404,7 @@ 

[PATCH 0/5] usb: dwc2: fix dwc2_get_hwparams() + optimize probe time a bit

[Douglas Anderson]

This is a collection of patches, some by Yunzhi Li at Rockchip and some
by me, that fix dwc2_get_hwparams() on some boards (depending on how the
bootloader left things) and then attempt to optimize DWC2's probe
time (since fixing dwc2_get_hwparams() made probe even slower than it
was).  Note that even after these changes probe time is still not super
fast (we still call dwc2_core_reset() twice per probe and each call
still takes a minimum of 160ms right now), but this at least picks the
low hanging fruit.

Note that this picks patch "v2" of "usb: dwc2: reset dwc2 core before
dwc2_get_hwparams()" from Yunzhi Li rather than v3 because I think it's
a better way to go.

These patches are all rebased atop linuxnext.  Since linuxnext wasn't
booting on my board, they were tested against Heiko Stuebner's "somewhat
stable" github tree (based on v4.3-rc1) with a few linuxnext dwc2
patches pulled in to avoid conflicts.

These patches have either landed or are planned to land on the
chromeos-3.14 branch for use in several Chromebooks that use rk3288.


Douglas Anderson (3):
  usb: dwc2: Restore GUSBCFG in dwc2_get_hwparams()
  CHROMIUM: usb: dwc2: Avoid double-reset at boot time
  usb: dwc2: Speed dwc2_get_hwparams() on some host-only ports

Yunzhi Li (2):
  usb: dwc2: reset dwc2 core before dwc2_get_hwparams()
  usb: dwc2: reduce dwc2 driver probe time

 drivers/usb/dwc2/core.c | 57 ++---
 drivers/usb/dwc2/core.h |  3 ++-
 drivers/usb/dwc2/hcd.c  |  6 ++---
 drivers/usb/dwc2/platform.c |  6 +
 4 files changed, 44 insertions(+), 28 deletions(-)

-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Javier,

On 10/07/2015 07:25 PM, Javier Martinez Canillas wrote:

Hello Yakir,

On 10/07/2015 01:05 PM, Yakir Yang wrote:

Hi Javier,

On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote:

Hello Yakir,

On 10/07/2015 11:02 AM, Yakir Yang wrote:

Hi Javier,

On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:

Hello Yakir,

On 10/07/2015 08:25 AM, Yakir Yang wrote:

Hi all,

Friendly ping.   :)


Best regards,
- Yakir



Do you have a tree that I can use to test these patches?

Wow, thanks a lot, I do have a tree on github 
[https://github.com/yakir-Yang/linux/tree/analogix_dp],
crossing my finger, wish things works..;)


I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
but the machine didn't boot. Unfortunately I need to do some soldering
to have a serial console on this board so don't have a kernel boot log.

I'll let you know if I can get more info about this issue.

Whoops, sorry for the failed, much appreciated for your works.

Besides, I thought maybe I can find a Peach Pit Chromebook in my side,
I remember that some of our guys have brought one, but previously I
thought that mainline kernel wouldn't run on Peach Pit directly.


Great, mainline works correctly on all Exynos based Chromebooks.


Maybe you can email me the method the run mainline kernel on Peach
Pit, so I can debug the analogix_dp driver at the same time, that would
be great.

I wrote a little blog post explaining how to run mainline on these boards:

http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/

That explains the simplest setup though so if you need a different one
(i.e: chain loading a non verified u-boot) or if you have any questions,
feel free to contact me in private and I can help you with the setup.



Ah, thanks, gonna to step-by-step.

- Yakir


Also, there is Kconfig recursive dependency that you may want to fix:

$ make exynos_defconfig
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_ANALOGIX_DP
drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected 
by DRM_EXYNOS_DP
drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on 
DRM_EXYNOS_FIMD
drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
   

Yeah, recursive dependency detected, guess I should remove the
"DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks
for your remind.

--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,4 +1,3 @@
  config DRM_ANALOGIX_DP
 tristate
 depends on DRM
-   select DRM_KMS_HELPER



That fixes the recursive dependency issue indeed. Thanks.


Thanks,
- Yakir

Best regards,



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing operand for tlbie instruction on Power7

[Michael Ellerman]

On Wed, 2015-10-07 at 20:15 -0400, Josh Boyer wrote:
> On Wed, Oct 7, 2015 at 8:10 PM, Michael Ellerman  wrote:
> > On Wed, 2015-10-07 at 10:31 -0400, Josh Boyer wrote:
> >> On Wed, Oct 7, 2015 at 5:13 AM, Michael Ellerman  
> >> wrote:
> >> > On Wed, 2015-10-07 at 02:19 -0500, Segher Boessenkool wrote:
> >> >> On Wed, Oct 07, 2015 at 05:00:49PM +1100, Michael Ellerman wrote:
> >> >> > > It's also worth noting that the __flush_power7 uses tlbiel instead 
> >> >> > > of tlbie.
> >> >> >
> >> >> > Yeah that's a good point. It's not clear if the swsusp code wants to 
> >> >> > a local or
> >> >> > a global invalidate.
> >> >>
> >> >> If I read the code right, this is called on the boot CPU when all the
> >> >> non-boot CPUs are still (potentially) down, so if you would do a global
> >> >> invalidate the non-boot CPUs might not even notice, so those need to do
> >> >> a (local) invalidate after being brought up anyway?  Or they probably
> >> >> need it before being brought down at all?  You figure it out, it makes
> >> >> my brain hurt :-)
> >> >
> >> > A good rule would be that every cpu does a local invalidate before 
> >> > turning on
> >> > the MMU. That would work for this case and also for kexec, kdump, junk 
> >> > left by
> >> > firmare etc. But I don't think we do that consistently in a way that 
> >> > works for
> >> > this code at the moment.
> >> >
> >> >> > As an alternative, can you try adding a .machine push / .machine 
> >> >> > "power4" /
> >> >> > .machine pop, around the tlbie. That should tell the assembler to 
> >> >> > drop back to
> >> >> > power4 mode for that instruction, which should then do the right 
> >> >> > thing. There
> >> >> > are some examples in that file.
> >> >>
> >> >> That will get the assembler to not complain, but it will assemble the 
> >> >> wrong
> >> >> instruction: the power7 instruction has the same opcode (but different
> >> >> semantics).  So if you assemble a "tlbie r4" in power4 mode, a newer CPU
> >> >> will see it as a "tlbie r4,r0" and do the wrong thing.
> >> >
> >> > Yeah, it would basically maintain the existing behaviour which is wrong 
> >> > but a
> >> > known quantity. I suspect no one has ever run this on Power7 or in fact
> >> > anything other than G5 or Book3E.
> >>
> >> Likely not, but leaving it broken just because it is known behavior
> >> seems pretty weird to me.
> >
> > In a universe where I have infinite time to fix random things we would
> > obviously do a proper fix :)
> >
> >> I think Fedora will look at simply disabling hibernation on ppc64 so the 
> >> file
> >> isn't built at all.  Seems to be a safer option.
> >
> > It's safer for sure. Though you might have some G5 users who are using it 
> > and
> > notice it being disabled.
> 
> The 5 of them will notice it being disabled and then they'll realize
> they either get a working kernel minus hibernation, or they get no
> kernel at all because it doesn't compile.

Sure. But if we do the machine push thing they'll get both :)

And I doubt it's 5, 2 is more likely.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/10] tools: hv: report ENOSPC errors in hv_fcopy_daemon

[K. Y. Srinivasan]

From: Olaf Hering 

Currently some "Unspecified error 0x80004005" is reported on the Windows
side if something fails. Handle the ENOSPC case and return
ERROR_DISK_FULL, which allows at least Copy-VMFile to report a meaning
full error.

Signed-off-by: Olaf Hering 
Signed-off-by: K. Y. Srinivasan 
---
 include/uapi/linux/hyperv.h |1 +
 tools/hv/hv_fcopy_daemon.c  |   20 +---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/hyperv.h b/include/uapi/linux/hyperv.h
index e4c0a35..e347b24 100644
--- a/include/uapi/linux/hyperv.h
+++ b/include/uapi/linux/hyperv.h
@@ -313,6 +313,7 @@ enum hv_kvp_exchg_pool {
 #define HV_INVALIDARG  0x80070057
 #define HV_GUID_NOTFOUND   0x80041002
 #define HV_ERROR_ALREADY_EXISTS0x80070050
+#define HV_ERROR_DISK_FULL 0x80070070
 
 #define ADDR_FAMILY_NONE   0x00
 #define ADDR_FAMILY_IPV4   0x01
diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index 5480e4e..f1d7426 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -37,12 +37,14 @@
 
 static int target_fd;
 static char target_fname[W_MAX_PATH];
+static unsigned long long filesize;
 
 static int hv_start_fcopy(struct hv_start_fcopy *smsg)
 {
int error = HV_E_FAIL;
char *q, *p;
 
+   filesize = 0;
p = (char *)smsg->path_name;
snprintf(target_fname, sizeof(target_fname), "%s/%s",
 (char *)smsg->path_name, (char *)smsg->file_name);
@@ -98,14 +100,26 @@ done:
 static int hv_copy_data(struct hv_do_fcopy *cpmsg)
 {
ssize_t bytes_written;
+   int ret = 0;
 
bytes_written = pwrite(target_fd, cpmsg->data, cpmsg->size,
cpmsg->offset);
 
-   if (bytes_written != cpmsg->size)
-   return HV_E_FAIL;
+   filesize += cpmsg->size;
+   if (bytes_written != cpmsg->size) {
+   switch (errno) {
+   case ENOSPC:
+   ret = HV_ERROR_DISK_FULL;
+   break;
+   default:
+   ret = HV_E_FAIL;
+   break;
+   }
+   syslog(LOG_ERR, "pwrite failed to write %llu bytes: %ld (%s)",
+  filesize, (long)bytes_written, strerror(errno));
+   }
 
-   return 0;
+   return ret;
 }
 
 static int hv_copy_finished(void)
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/10] tools: hv: remove repeated HV_FCOPY string

[K. Y. Srinivasan]

From: Olaf Hering 

HV_FCOPY is already used as identifier in syslog.

Signed-off-by: Olaf Hering 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_fcopy_daemon.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index f1d7426..fdc9ca4 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -179,7 +179,7 @@ int main(int argc, char *argv[])
}
 
openlog("HV_FCOPY", 0, LOG_USER);
-   syslog(LOG_INFO, "HV_FCOPY starting; pid is:%d", getpid());
+   syslog(LOG_INFO, "starting; pid is:%d", getpid());
 
fcopy_fd = open("/dev/vmbus/hv_fcopy", O_RDWR);
 
@@ -215,7 +215,7 @@ int main(int argc, char *argv[])
}
kernel_modver = *(__u32 *)buffer;
in_handshake = 0;
-   syslog(LOG_INFO, "HV_FCOPY: kernel module version: %d",
+   syslog(LOG_INFO, "kernel module version: %d",
   kernel_modver);
continue;
}
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/10] Drivers: hv: utils: use memdup_user in hvt_op_write

[K. Y. Srinivasan]

From: Olaf Hering 

Use memdup_user to handle OOM.

Fixes: 14b50f80c32d ('Drivers: hv: util: introduce hv_utils_transport 
abstraction')

Signed-off-by: Olaf Hering 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_utils_transport.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
index 1505ee6..24b2766 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -80,11 +80,10 @@ static ssize_t hvt_op_write(struct file *file, const char 
__user *buf,
 
hvt = container_of(file->f_op, struct hvutil_transport, fops);
 
-   inmsg = kzalloc(count, GFP_KERNEL);
-   if (copy_from_user(inmsg, buf, count)) {
-   kfree(inmsg);
-   return -EFAULT;
-   }
+   inmsg = memdup_user(buf, count);
+   if (IS_ERR(inmsg))
+   return PTR_ERR(inmsg);
+
if (hvt->on_msg(inmsg, count))
return -EFAULT;
kfree(inmsg);
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 05/11] task_isolation: add debug boot flag

[Chris Metcalf]

On 10/5/2015 1:07 PM, Luiz Capitulino wrote:

On Mon, 28 Sep 2015 11:17:20 -0400
Chris Metcalf  wrote:


The new "task_isolation_debug" flag simplifies debugging
of TASK_ISOLATION kernels when processes are running in
PR_TASK_ISOLATION_ENABLE mode.  Such processes should get no
interrupts from the kernel, and if they do, when this boot flag is
specified a kernel stack dump on the console is generated.

It's possible to use ftrace to simply detect whether a task_isolation
core has unexpectedly entered the kernel.  But what this boot flag
does is allow the kernel to provide better diagnostics, e.g. by
reporting in the IPI-generating code what remote core and context
is preparing to deliver an interrupt to a task_isolation core.

It may be worth considering other ways to generate useful debugging
output rather than console spew, but for now that is simple and direct.

Honest question: does any of the task_isolation_debug() calls added
by this patch take care of the case where vmstat_shepherd() may
schedule vmstat_update() to run because a TASK_ISOLATION process is
changing memory stats?


The task_isolation_debug() calls don't "take care of" any cases - they are
really just there to generate console dumps when the kernel unexpectedly
interrupts a task_isolated task.

The idea with vmstat is that before a task_isolated task returns to
userspace, it quiesces the vmstat thread (does a final sweep to collect
the stats and turns off the scheduled work item).  As a result, the vmstat
shepherd won't run while the task is in userspace.  When and if it returns
to the kernel, it will again sweep up the stats before returning to userspace.

The usual shepherd mechanism on a housekeeping core might notice
that the task had entered the kernel and started changing stats, and
might then asynchronously restart the scheduled work, but it should be
quiesced again regardless on the way back out to userspace.


If that's not taken care of yet, should we? I just don't know if we
should call task_isolation_exception() or task_isolation_debug().


task_isolation_exception() is called when an exception (page fault or
similar) is generated synchronously by the running task and we want
to make sure to notify the task with a signal if it has set up STRICT mode
to indicate that it is not planning to enter the kernel.


In the case of the latter, wouldn't it be interesting to add it to
__queue_work() then?


Well, queuing remote work involves sending an IPI, and we already tag
both the SMP send side AND the client side IRQ side with a 
task_isolation_debug(),
so I expect in practice it would be detected.

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 02/10] Drivers: hv: utils: run polling callback always in interrupt context

[K. Y. Srinivasan]

From: Olaf Hering 

All channel interrupts are bound to specific VCPUs in the guest
at the point channel is created. While currently, we invoke the
polling function on the correct CPU (the CPU to which the channel
is bound to) in some cases we may run the polling function in
a non-interrupt context. This  potentially can cause an issue as the
polling function can be interrupted by the channel callback function.
Fix the issue by running the polling function on the appropriate CPU
at interrupt level. Additional details of the issue being addressed by
this patch are given below:

Currently hv_fcopy_onchannelcallback is called from interrupts and also
via the ->write function of hv_utils. Since the used global variables to
maintain state are not thread safe the state can get out of sync.
This affects the variable state as well as the channel inbound buffer.

As suggested by KY adjust hv_poll_channel to always run the given
callback on the cpu which the channel is bound to. This avoids the need
for locking because all the util services are single threaded and only
one transaction is active at any given point in time.

Additionally, remove the context variable, they will always be the same as
recv_channel.

Signed-off-by: Olaf Hering 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_fcopy.c |   37 +
 drivers/hv/hv_kvp.c   |   28 ++--
 drivers/hv/hv_snapshot.c  |   29 +++--
 drivers/hv/hyperv_vmbus.h |6 +-
 4 files changed, 35 insertions(+), 65 deletions(-)

diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index bbdec50..4eab465 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -51,7 +51,6 @@ static struct {
struct hv_fcopy_hdr  *fcopy_msg; /* current message */
struct vmbus_channel *recv_channel; /* chn we got the request */
u64 recv_req_id; /* request ID. */
-   void *fcopy_context; /* for the channel callback */
 } fcopy_transaction;
 
 static void fcopy_respond_to_host(int error);
@@ -67,6 +66,13 @@ static struct hvutil_transport *hvt;
  */
 static int dm_reg_value;
 
+static void fcopy_poll_wrapper(void *channel)
+{
+   /* Transaction is finished, reset the state here to avoid races. */
+   fcopy_transaction.state = HVUTIL_READY;
+   hv_fcopy_onchannelcallback(channel);
+}
+
 static void fcopy_timeout_func(struct work_struct *dummy)
 {
/*
@@ -74,13 +80,7 @@ static void fcopy_timeout_func(struct work_struct *dummy)
 * process the pending transaction.
 */
fcopy_respond_to_host(HV_E_FAIL);
-
-   /* Transaction is finished, reset the state. */
-   if (fcopy_transaction.state > HVUTIL_READY)
-   fcopy_transaction.state = HVUTIL_READY;
-
-   hv_poll_channel(fcopy_transaction.fcopy_context,
-   hv_fcopy_onchannelcallback);
+   hv_poll_channel(fcopy_transaction.recv_channel, fcopy_poll_wrapper);
 }
 
 static int fcopy_handle_handshake(u32 version)
@@ -108,9 +108,9 @@ static int fcopy_handle_handshake(u32 version)
return -EINVAL;
}
pr_debug("FCP: userspace daemon ver. %d registered\n", version);
+   /* Forward state for hv_fcopy_onchannelcallback */
fcopy_transaction.state = HVUTIL_READY;
-   hv_poll_channel(fcopy_transaction.fcopy_context,
-   hv_fcopy_onchannelcallback);
+   hv_poll_channel(fcopy_transaction.recv_channel, fcopy_poll_wrapper);
return 0;
 }
 
@@ -227,15 +227,8 @@ void hv_fcopy_onchannelcallback(void *context)
int util_fw_version;
int fcopy_srv_version;
 
-   if (fcopy_transaction.state > HVUTIL_READY) {
-   /*
-* We will defer processing this callback once
-* the current transaction is complete.
-*/
-   fcopy_transaction.fcopy_context = context;
+   if (fcopy_transaction.state > HVUTIL_READY)
return;
-   }
-   fcopy_transaction.fcopy_context = NULL;
 
vmbus_recvpacket(channel, recv_buffer, PAGE_SIZE * 2, ,
 );
@@ -295,9 +288,6 @@ static int fcopy_on_msg(void *msg, int len)
if (fcopy_transaction.state == HVUTIL_DEVICE_INIT)
return fcopy_handle_handshake(*val);
 
-   if (fcopy_transaction.state != HVUTIL_USERSPACE_REQ)
-   return -EINVAL;
-
/*
 * Complete the transaction by forwarding the result
 * to the host. But first, cancel the timeout.
@@ -305,9 +295,8 @@ static int fcopy_on_msg(void *msg, int len)
if (cancel_delayed_work_sync(_timeout_work)) {
fcopy_transaction.state = HVUTIL_USERSPACE_RECV;
fcopy_respond_to_host(*val);
-   fcopy_transaction.state = HVUTIL_READY;
-   hv_poll_channel(fcopy_transaction.fcopy_context,
-   hv_fcopy_onchannelcallback);
+   

[PATCH 01/10] Drivers: hv: util: Increase the timeout for util services

[K. Y. Srinivasan]

Util services such as KVP and FCOPY need assistance from daemon's running
in user space. Increase the timeout so we don't prematurely terminate
the transaction in the kernel.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_fcopy.c |3 ++-
 drivers/hv/hv_kvp.c   |3 ++-
 drivers/hv/hyperv_vmbus.h |5 +
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index db4b887..bbdec50 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -275,7 +275,8 @@ void hv_fcopy_onchannelcallback(void *context)
 * Send the information to the user-level daemon.
 */
schedule_work(_send_work);
-   schedule_delayed_work(_timeout_work, 5*HZ);
+   schedule_delayed_work(_timeout_work,
+ HV_UTIL_TIMEOUT * HZ);
return;
}
icmsghdr->icflags = ICMSGHDRFLAG_TRANSACTION | ICMSGHDRFLAG_RESPONSE;
diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index 74c38a9..e6aa33a 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -668,7 +668,8 @@ void hv_kvp_onchannelcallback(void *context)
 * user-mode not responding.
 */
schedule_work(_sendkey_work);
-   schedule_delayed_work(_timeout_work, 5*HZ);
+   schedule_delayed_work(_timeout_work,
+ HV_UTIL_TIMEOUT * HZ);
 
return;
 
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 3d70e36..f26599b 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -31,6 +31,11 @@
 #include 
 
 /*
+ * Timeout for services such as KVP and fcopy.
+ */
+#define HV_UTIL_TIMEOUT 30
+
+/*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
  * is set by CPUID(HVCPUID_VERSION_FEATURES).
  */
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/10] drivers:hv: Export a function that maps Linux CPU num onto Hyper-V proc num

[K. Y. Srinivasan]

From: Jake Oshins 

This patch exposes the mapping between Linux CPU number and Hyper-V virtual
processor number.  This is necessary because the hypervisor needs to know which
virtual processors to target when making a mapping in the Interrupt Redirection
Table in the I/O MMU.

Signed-off-by: Jake Oshins 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/vmbus_drv.c |   17 +
 include/linux/hyperv.h |2 ++
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 3297731..c01b689 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1193,6 +1193,23 @@ int vmbus_allocate_mmio(struct resource **new, struct 
hv_device *device_obj,
 }
 EXPORT_SYMBOL_GPL(vmbus_allocate_mmio);
 
+/**
+ * vmbus_cpu_number_to_vp_number() - Map CPU to VP.
+ * @cpu_number: CPU number in Linux terms
+ *
+ * This function returns the mapping between the Linux processor
+ * number and the hypervisor's virtual processor number, useful
+ * in making hypercalls and such that talk about specific
+ * processors.
+ *
+ * Return: Virtual processor number in Hyper-V terms
+ */
+int vmbus_cpu_number_to_vp_number(int cpu_number)
+{
+   return hv_context.vp_index[cpu_number];
+}
+EXPORT_SYMBOL_GPL(vmbus_cpu_number_to_vp_number);
+
 static int vmbus_acpi_add(struct acpi_device *device)
 {
acpi_status result;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 54733d5..02393b6 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -982,6 +982,8 @@ int vmbus_allocate_mmio(struct resource **new, struct 
hv_device *device_obj,
resource_size_t size, resource_size_t align,
bool fb_overlap_ok);
 
+int vmbus_cpu_number_to_vp_number(int cpu_number);
+
 /**
  * VMBUS_DEVICE - macro used to describe a specific hyperv vmbus device
  *
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 10/10] drivers:hv: Define the channel type for Hyper-V PCI Express pass-through

[K. Y. Srinivasan]

From: Jake Oshins 

This defines the channel type for PCI front-ends in Hyper-V VMs.

Signed-off-by: Jake Oshins 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/channel_mgmt.c |3 +++
 include/linux/hyperv.h|   11 +++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 652afd1..1ae615b 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -358,6 +358,7 @@ enum {
SCSI,
NIC,
ND_NIC,
+   HV_PCIE,
MAX_PERF_CHN,
 };
 
@@ -375,6 +376,8 @@ static const struct hv_vmbus_device_id hp_devs[] = {
{ HV_NIC_GUID, },
/* NetworkDirect Guest RDMA */
{ HV_ND_GUID, },
+   /* PCI Express Pass Through */
+   { HV_PCIE_GUID, },
 };
 
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index ea0a0e3..5587899 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1140,6 +1140,17 @@ u64 hv_do_hypercall(u64 control, void *input, void 
*output);
}
 
 /*
+ * PCI Express Pass Through
+ * {44C4F61D--4400-9D52-802E27EDE19F}
+ */
+
+#define HV_PCIE_GUID \
+   .guid = { \
+   0x1D, 0xF6, 0xC4, 0x44, 0x44, 0x44, 0x00, 0x44, \
+   0x9D, 0x52, 0x80, 0x2E, 0x27, 0xED, 0xE1, 0x9F \
+   }
+
+/*
  * Common header for Hyper-V ICs
  */
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/10] Drivers: hv: util: catch allocation errors

[K. Y. Srinivasan]

From: Olaf Hering 

Catch allocation errors in hvutil_transport_send.

Fixes: 14b50f80c32d ('Drivers: hv: util: introduce hv_utils_transport 
abstraction')

Signed-off-by: Olaf Hering 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_utils_transport.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
index 6a9d80a..1505ee6 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -204,9 +204,12 @@ int hvutil_transport_send(struct hvutil_transport *hvt, 
void *msg, int len)
goto out_unlock;
}
hvt->outmsg = kzalloc(len, GFP_KERNEL);
-   memcpy(hvt->outmsg, msg, len);
-   hvt->outmsg_len = len;
-   wake_up_interruptible(>outmsg_q);
+   if (hvt->outmsg) {
+   memcpy(hvt->outmsg, msg, len);
+   hvt->outmsg_len = len;
+   wake_up_interruptible(>outmsg_q);
+   } else
+   ret = -ENOMEM;
 out_unlock:
mutex_unlock(>outmsg_lock);
return ret;
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 07/10] drivers/hv: cleanup synic msrs if vmbus connect failed

[K. Y. Srinivasan]

From: Denis V. Lunev 

Before vmbus_connect() synic is setup per vcpu - this means
hypervisor receives writes at synic msr's and probably allocate
hypervisor resources per synic setup.

If vmbus_connect() failed for some reason it's neccessary to cleanup
synic setup by call hv_synic_cleanup() at each vcpu to get a chance
to free allocated resources by hypervisor per synic.

This patch does appropriate cleanup in case of vmbus_connect() failure.

Signed-off-by: Andrey Smetanin 
Signed-off-by: Denis V. Lunev 
Reviewed-by: Vitaly Kuznetsov 
CC: "K. Y. Srinivasan" 
CC: Haiyang Zhang 
CC: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/vmbus_drv.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index f19b6f7..3297731 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -867,7 +867,7 @@ static int vmbus_bus_init(int irq)
on_each_cpu(hv_synic_init, NULL, 1);
ret = vmbus_connect();
if (ret)
-   goto err_alloc;
+   goto err_connect;
 
if (vmbus_proto_version > VERSION_WIN7)
cpu_hotplug_disable();
@@ -885,6 +885,8 @@ static int vmbus_bus_init(int irq)
 
return 0;
 
+err_connect:
+   on_each_cpu(hv_synic_cleanup, NULL, 1);
 err_alloc:
hv_synic_free();
hv_remove_vmbus_irq();
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/10] drivers:hv: Export the API to invoke a hypercall on Hyper-V

[K. Y. Srinivasan]

From: Jake Oshins 

This patch exposes the function that hv_vmbus.ko uses to make hypercalls.  This
is necessary for retargeting an interrupt when it is given a new affinity.

Since we are exporting this API, rename the API as it will be visible outside
the hv.c file.

Signed-off-by: Jake Oshins 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv.c   |   20 ++--
 drivers/hv/hyperv_vmbus.h |2 +-
 include/linux/hyperv.h|1 +
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 6341be8..7a06933 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -89,9 +89,9 @@ static int query_hypervisor_info(void)
 }
 
 /*
- * do_hypercall- Invoke the specified hypercall
+ * hv_do_hypercall- Invoke the specified hypercall
  */
-static u64 do_hypercall(u64 control, void *input, void *output)
+u64 hv_do_hypercall(u64 control, void *input, void *output)
 {
u64 input_address = (input) ? virt_to_phys(input) : 0;
u64 output_address = (output) ? virt_to_phys(output) : 0;
@@ -132,6 +132,7 @@ static u64 do_hypercall(u64 control, void *input, void 
*output)
return hv_status_lo | ((u64)hv_status_hi << 32);
 #endif /* !x86_64 */
 }
+EXPORT_SYMBOL_GPL(hv_do_hypercall);
 
 #ifdef CONFIG_X86_64
 static cycle_t read_hv_clock_tsc(struct clocksource *arg)
@@ -315,7 +316,7 @@ int hv_post_message(union hv_connection_id connection_id,
 {
 
struct hv_input_post_message *aligned_msg;
-   u16 status;
+   u64 status;
 
if (payload_size > HV_MESSAGE_PAYLOAD_BYTE_COUNT)
return -EMSGSIZE;
@@ -329,11 +330,10 @@ int hv_post_message(union hv_connection_id connection_id,
aligned_msg->payload_size = payload_size;
memcpy((void *)aligned_msg->payload, payload, payload_size);
 
-   status = do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL)
-   & 0x;
+   status = hv_do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL);
 
put_cpu();
-   return status;
+   return status & 0x;
 }
 
 
@@ -343,13 +343,13 @@ int hv_post_message(union hv_connection_id connection_id,
  *
  * This involves a hypercall.
  */
-u16 hv_signal_event(void *con_id)
+int hv_signal_event(void *con_id)
 {
-   u16 status;
+   u64 status;
 
-   status = (do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL) & 0x);
+   status = hv_do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL);
 
-   return status;
+   return status & 0x;
 }
 
 static int hv_ce_set_next_event(unsigned long delta,
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 40c0c855..64950d8 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -592,7 +592,7 @@ extern int hv_post_message(union hv_connection_id 
connection_id,
 enum hv_message_type message_type,
 void *payload, size_t payload_size);
 
-extern u16 hv_signal_event(void *con_id);
+extern int hv_signal_event(void *con_id);
 
 extern int hv_synic_alloc(void);
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 02393b6..ea0a0e3 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -983,6 +983,7 @@ int vmbus_allocate_mmio(struct resource **new, struct 
hv_device *device_obj,
bool fb_overlap_ok);
 
 int vmbus_cpu_number_to_vp_number(int cpu_number);
+u64 hv_do_hypercall(u64 control, void *input, void *output);
 
 /**
  * VMBUS_DEVICE - macro used to describe a specific hyperv vmbus device
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] perf: Correctly identify anon_hugepage when generating map

[Yannick Brosseau]

When parsing /proc/xxx/maps, the sscanf in perf_event__synthesize_mmap_events
truncate the map name at the space in "/anon_hugepage (deleted)".
is_anon_memory then only receive the string "/anon_hugepage" and do not detect 
it.
We change is_anon_memory to only compare the first part of the string
effectively ignoring if the (deleted) part is there or not.

Signed-off-by: Yannick Brosseau 
---
 tools/perf/util/map.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b1c475d..9f7face 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -26,8 +26,8 @@ const char *map_type__name[MAP__NR_TYPES] = {
 static inline int is_anon_memory(const char *filename)
 {
return !strcmp(filename, "//anon") ||
-  !strcmp(filename, "/dev/zero (deleted)") ||
-  !strcmp(filename, "/anon_hugepage (deleted)");
+  !strncmp(filename, "/dev/zero", sizeof("/dev/zero")) ||
+  !strncmp(filename, "/anon_hugepage", sizeof("/anon_hugepage"));
 }
 
 static inline int is_no_dso_memory(const char *filename)
-- 
2.6.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/10] Drivers: hv: Miscellaneous fixes.

[K. Y. Srinivasan]

Miscellaneous fixes.

Denis V. Lunev (1):
  drivers/hv: cleanup synic msrs if vmbus connect failed

Jake Oshins (3):
  drivers:hv: Export a function that maps Linux CPU num onto Hyper-V
proc num
  drivers:hv: Export the API to invoke a hypercall on Hyper-V
  drivers:hv: Define the channel type for Hyper-V PCI Express
pass-through

K. Y. Srinivasan (1):
  Drivers: hv: util: Increase the timeout for util services

Olaf Hering (5):
  Drivers: hv: utils: run polling callback always in interrupt context
  tools: hv: report ENOSPC errors in hv_fcopy_daemon
  tools: hv: remove repeated HV_FCOPY string
  Drivers: hv: util: catch allocation errors
  Drivers: hv: utils: use memdup_user in hvt_op_write

 drivers/hv/channel_mgmt.c   |3 ++
 drivers/hv/hv.c |   20 +-
 drivers/hv/hv_fcopy.c   |   40 ++
 drivers/hv/hv_kvp.c |   31 +++--
 drivers/hv/hv_snapshot.c|   29 ++-
 drivers/hv/hv_utils_transport.c |   18 +---
 drivers/hv/hyperv_vmbus.h   |   13 ++-
 drivers/hv/vmbus_drv.c  |   21 +++-
 include/linux/hyperv.h  |   14 +
 include/uapi/linux/hyperv.h |1 +
 tools/hv/hv_fcopy_daemon.c  |   24 ++
 11 files changed, 122 insertions(+), 92 deletions(-)

-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 0/9] drivers:mtd:UBI: add bakvol module for MLC NAND paired page issue

[beanhuo]

> > Hi, Richard
> > Thanks for your concern. I am a new patch submitter.
> > Can you tell me Nacked-by means?
> 
> I basically means that I'm (as maintainer) really unhappy with this patches 
> and
> don't see a way to get them merged as the whole concept is not acceptable.
> 
> > By the way, Do you review my patches series ? I don't backup duplicated
> data in OOB .
> > Can you specify which sector codes ? so that I can explain it in detail.
> 
> Okay. Maybe both Boris and I misread your code, can you please explain in
> detail what functions like check_original_data() or
> mtd_write_dual_plane_oob() do?

OK, Next version patch, I will add more comments for some important function.

> Thanks,
> //richard

[GIT PULL] strscpy powerpc fix for 3.4

[Chris Metcalf]

On 10/7/2015 6:44 PM, Stephen Rothwell wrote:

Hi Linus,

After merging Linus' tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

lib/string.c: In function 'strscpy':
lib/string.c:209:4: error: implicit declaration of function 'zero_bytemask' 
[-Werror=implicit-function-declaration]
 *(unsigned long *)(dest+res) = c & zero_bytemask(data);
 ^

Caused by commit

   30035e45753b ("string: provide strscpy()")


I posted a change equivalent to yours earlier today:

http://lkml.kernel.org/r/1444229188-19640-1-git-send-email-cmetc...@ezchip.com

I also did no testing, but since the rest of the PPC code is similar to the
asm-generic version, I believe the zero_bytemask() definition should be OK.

It probably should go through Linus' tree, like the previous set of patches.
I just pushed it up to the linux-tile tree for Linus to grab as:

git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git strscpy

Chris Metcalf (1):
  arch/powerpc: provide zero_bytemask() for big-endian

 arch/powerpc/include/asm/word-at-a-time.h | 5 +
 1 file changed, 5 insertions(+)

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next 4/6] net: dsa: add port_fdb_prepare

[Andrew Lunn]

On Wed, Oct 07, 2015 at 07:48:29PM -0400, Vivien Didelot wrote:
> Push the prepare phase for FDB operations down to the DSA drivers, with
> a new port_fdb_prepare function. Currently only mv88e6xxx is affected.
> 
> Signed-off-by: Vivien Didelot 
> ---
>  drivers/net/dsa/mv88e6171.c |  1 +
>  drivers/net/dsa/mv88e6352.c |  1 +
>  drivers/net/dsa/mv88e6xxx.c | 10 ++
>  drivers/net/dsa/mv88e6xxx.h |  3 +++
>  include/net/dsa.h   |  4 
>  net/dsa/slave.c |  7 +--
>  6 files changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
> index c95cfab..ca3330a 100644
> --- a/drivers/net/dsa/mv88e6171.c
> +++ b/drivers/net/dsa/mv88e6171.c
> @@ -121,6 +121,7 @@ struct dsa_switch_driver mv88e6171_switch_driver = {
>   .port_vlan_add  = mv88e6xxx_port_vlan_add,
>   .port_vlan_del  = mv88e6xxx_port_vlan_del,
>   .vlan_getnext   = mv88e6xxx_vlan_getnext,
> + .port_fdb_prepare   = mv88e6xxx_port_fdb_prepare,

Hi Vivien

Bike shedding a bit, but i would call this
mv88e6xxx_port_fdb_prepare_add.

>   .port_fdb_add   = mv88e6xxx_port_fdb_add,
>   .port_fdb_del   = mv88e6xxx_port_fdb_del,
>   .port_fdb_getnext   = mv88e6xxx_port_fdb_getnext,

Taking a theoretical example, say mv88e6xxx_port_fdb_getnext needed a
prepare call to allocate memory to put the returned ATU into. What
would you call that?

mv88e6xxx_port_fdb_prepare_add and mv88e6xxx_port_fdb_prepare_getnext
just seems unambiguous and future proof.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing operand for tlbie instruction on Power7

[Josh Boyer]

On Wed, Oct 7, 2015 at 8:10 PM, Michael Ellerman  wrote:
> On Wed, 2015-10-07 at 10:31 -0400, Josh Boyer wrote:
>> On Wed, Oct 7, 2015 at 5:13 AM, Michael Ellerman  wrote:
>> > On Wed, 2015-10-07 at 02:19 -0500, Segher Boessenkool wrote:
>> >> On Wed, Oct 07, 2015 at 05:00:49PM +1100, Michael Ellerman wrote:
>> >> > > It's also worth noting that the __flush_power7 uses tlbiel instead of 
>> >> > > tlbie.
>> >> >
>> >> > Yeah that's a good point. It's not clear if the swsusp code wants to a 
>> >> > local or
>> >> > a global invalidate.
>> >>
>> >> If I read the code right, this is called on the boot CPU when all the
>> >> non-boot CPUs are still (potentially) down, so if you would do a global
>> >> invalidate the non-boot CPUs might not even notice, so those need to do
>> >> a (local) invalidate after being brought up anyway?  Or they probably
>> >> need it before being brought down at all?  You figure it out, it makes
>> >> my brain hurt :-)
>> >
>> > A good rule would be that every cpu does a local invalidate before turning 
>> > on
>> > the MMU. That would work for this case and also for kexec, kdump, junk 
>> > left by
>> > firmare etc. But I don't think we do that consistently in a way that works 
>> > for
>> > this code at the moment.
>> >
>> >> > As an alternative, can you try adding a .machine push / .machine 
>> >> > "power4" /
>> >> > .machine pop, around the tlbie. That should tell the assembler to drop 
>> >> > back to
>> >> > power4 mode for that instruction, which should then do the right thing. 
>> >> > There
>> >> > are some examples in that file.
>> >>
>> >> That will get the assembler to not complain, but it will assemble the 
>> >> wrong
>> >> instruction: the power7 instruction has the same opcode (but different
>> >> semantics).  So if you assemble a "tlbie r4" in power4 mode, a newer CPU
>> >> will see it as a "tlbie r4,r0" and do the wrong thing.
>> >
>> > Yeah, it would basically maintain the existing behaviour which is wrong 
>> > but a
>> > known quantity. I suspect no one has ever run this on Power7 or in fact
>> > anything other than G5 or Book3E.
>>
>> Likely not, but leaving it broken just because it is known behavior
>> seems pretty weird to me.
>
> In a universe where I have infinite time to fix random things we would
> obviously do a proper fix :)
>
>> I think Fedora will look at simply disabling hibernation on ppc64 so the file
>> isn't built at all.  Seems to be a safer option.
>
> It's safer for sure. Though you might have some G5 users who are using it and
> notice it being disabled.

The 5 of them will notice it being disabled and then they'll realize
they either get a working kernel minus hibernation, or they get no
kernel at all because it doesn't compile.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 38/46] sched: scheduler-driven cpu frequency selection

[Steve Muckle]

On 08/25/2015 03:45 AM, Juri Lelli wrote:
> But, it is true that if the above events happened the other way around
> (we trigger an update after load balancing and a new task arrives), we
> may miss the opportunity to jump to max with the new task. In my mind
> this is probably not a big deal, as we'll have a tick pretty soon that
> will fix things anyway (saving us some complexity in the backend).
> 
> What you think?

I fear that waiting up to a full tick to resolve a shortfall in CPU
bandwidth will cause complaints.

Thinking about how this would be implemented raises a couple questions
for me though.

1. To avoid issuing a frequency change request while one is already in
flight, the current code uses the stated cpufreq driver transition
latency to throttle. Wouldn't it be more accurate to block further
requests until the CPUFREQ_POSTCHANGE notifier has run? In addition to
removing the requirement of supplying a latency value, frequency
transitions may take different amounts of time depending on system state
so a single latency value may often be incorrect.

2. The decision of whether or not to call into the low level cpufreq
driver in the scheduler hot paths currently hinges on whether or not the
low level cpufreq driver will sleep. Even if the cpufreq driver does not
sleep however, the latency to enqueue a frequency change (and complete
it if the low level driver is not asynchronous) may still be high,
making it unsuitable to run in a scheduler hot path. Should the
semantics of the flag be changed to indicate whether a cpufreq driver is
fast enough to run in this context? Sleeping would still of course mean
that it is not.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cpufreq, intel_pstate, set max_sysfs_pct and min_sysfs_pct on governor switch

[Prarit Bhargava]

On 10/07/2015 06:26 PM, Doug Smythies wrote:
> On 2015.10.07 15:06 Rafael J. Wysocki wrote:
>> On Wednesday, October 07, 2015 05:31:25 PM Prarit Bhargava wrote:
>>> On 10/07/2015 02:52 PM, Doug Smythies wrote:
 On 2015.10.07 08:46 Prarit Bhargava wrote:
> On 10/07/2015 11:40 AM, Doug Smythies wrote:
>>
>> Do we agree or disagree that the root issue seems to be (from your 
>> test)?:
>>
>> \#  echo 100 > /sys/devices/system/cpu/intel_pstate/min_perf_pct
>>
>> [   21.483436] store_min_perf_pct[453] min_sysfs_pct = 100
>> [   21.489373] store_min_perf_pct[456] min_perf_pct = 100
>> [   21.495203] store_min_perf_pct[459] min_perf_pct = 100
>> [   21.501050] store_min_perf_pct[462] min_perf_pct = 100
>
> Yep, and it appears to be done by default in Fedora & RHEL :/ ... the 
> issue is
> still the same IMO that min_sysfs_pct & max_sysfs_pct are not cleared on a
> governor switch.

 Clearing them will break some other things. For example, and as
 shown in my original reply, resume from suspend.

 Why? Because, at least on my computer, the governor is changed to
 "performance" during suspend, and the "powersave" governor is
 restored sometime during resume. The users wants the settings they had
 before the suspend.

>>> Looking at this in more detail after having tested on a Intel(R) Core(TM)
>>> i7-2600 CPU @ 3.40GHz in Fedora and RHEL.
>>>
>>> I have a feeling that the switch you're seeing (poweersave->performance, 
>>> suspend
>>> ... resume, performance->powersave) is occurring in userspace, and not as a
>>> result of the kernel.
> Agreed. It is pm-suspend doing it.
> 
>>>  IMO if userspace changes the governor, all bets are off
>>> on maintaining max_sysfs_pct and min_sysfs_pct.
>>>
>>> Here's something I cannot figure out (because I do not have an Ubuntu 
>>> install).
>>>  *Why* is Ubuntu making the governor switch during suspend/resume?  Is it
>>> because of archaic brokeness they were trying to paper over?
> 
>>> That's not limited to Ubuntu, pm-utils has been doing that forever.
> 
> Agreed. This in pm-utils, and not limited to Ubuntu.
> We can ignore this issue if everyone wants, but I can envision bug reports.
> 
>> I have no idea why has it been doing that, though.  I guess the reason
>> was to "speed up" PM transitions (in case it started when you were in a
>> low-frequency P-state and then there was no time to bump it up before
>> things got too far).
> 
> I have no idea either, but the stated theory seems sound.

Doug, can you also apply (sorry for the cut-and-paste)

diff --git a/pm/sleep.d/94cpufreq b/pm/sleep.d/94cpufreq
index 6807681..2c83e8e 100755
--- a/pm/sleep.d/94cpufreq
+++ b/pm/sleep.d/94cpufreq
@@ -16,6 +16,8 @@ hibernate_cpufreq()
gov="$x/cpufreq/scaling_governor"
# if we do not have a scaling_governor file, skip.
[ -f "$gov" ] || continue
+   # Is the governor known to work?
+   [ "$gov" == "intel_pstate" ] && continue
# if our temporary governor is not available, skip.
grep -q "$TEMPORARY_CPUFREQ_GOVERNOR" \
"$x/cpufreq/scaling_available_governors" || continue

and re-test?

Thanks,

P.
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/3] vTPM: reformat event log to be byte-aligned

[Hon Ching(Vicky) Lo]

The event log generated by OpenFirmware in PowerPC is 4-byte aligned.
This patch reformats the log to be byte-aligned for the Linux client.

Signed-off-by: Hon Ching(Vicky) Lo 
---
 arch/powerpc/kernel/prom_init.c |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index b9b6bb1..8a5c248 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1417,8 +1417,9 @@ static void __init prom_instantiate_sml(void)
 {
phandle ibmvtpm_node;
ihandle ibmvtpm_inst;
-   u32 entry = 0, size = 0;
+   u32 entry = 0, size = 0, succ = 0;
u64 base;
+   __be32 val;
 
prom_debug("prom_instantiate_sml: start...\n");
 
@@ -1433,6 +1434,16 @@ static void __init prom_instantiate_sml(void)
return;
}
 
+   if (prom_getprop(ibmvtpm_node, "ibm,sml-efi-reformat-supported",
+, sizeof(val)) != PROM_ERROR) {
+   if (call_prom_ret("call-method", 2, 2, ,
+ ADDR("reformat-sml-to-efi-alignment"),
+ ibmvtpm_inst) != 0 || succ == 0) {
+   prom_printf("Reformat SML to EFI alignment failed\n");
+   return;
+   }
+   }
+
if (call_prom_ret("call-method", 2, 2, ,
  ADDR("sml-get-handover-size"),
  ibmvtpm_inst) != 0 || size == 0) {
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/3] vTPM: fix searching for the right vTPM node in device tree

[Hon Ching(Vicky) Lo]

Replace all occurrences of '/ibm,vtpm' with '/vdevice/vtpm',
as only the latter is ganranteed to be available for the client OS.
The '/ibm,vtpm' node should only be used by Open Firmware, which
is susceptible to changes.

Signed-off-by: Hon Ching(Vicky) Lo 
---
 arch/powerpc/kernel/prom_init.c |8 
 drivers/char/tpm/tpm_of.c   |2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1a85d8f..b9b6bb1 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1422,12 +1422,12 @@ static void __init prom_instantiate_sml(void)
 
prom_debug("prom_instantiate_sml: start...\n");
 
-   ibmvtpm_node = call_prom("finddevice", 1, 1, ADDR("/ibm,vtpm"));
+   ibmvtpm_node = call_prom("finddevice", 1, 1, ADDR("/vdevice/vtpm"));
prom_debug("ibmvtpm_node: %x\n", ibmvtpm_node);
if (!PHANDLE_VALID(ibmvtpm_node))
return;
 
-   ibmvtpm_inst = call_prom("open", 1, 1, ADDR("/ibm,vtpm"));
+   ibmvtpm_inst = call_prom("open", 1, 1, ADDR("/vdevice/vtpm"));
if (!IHANDLE_VALID(ibmvtpm_inst)) {
prom_printf("opening vtpm package failed (%x)\n", ibmvtpm_inst);
return;
@@ -1456,9 +1456,9 @@ static void __init prom_instantiate_sml(void)
 
reserve_mem(base, size);
 
-   prom_setprop(ibmvtpm_node, "/ibm,vtpm", "linux,sml-base",
+   prom_setprop(ibmvtpm_node, "/vdevice/vtpm", "linux,sml-base",
 , sizeof(base));
-   prom_setprop(ibmvtpm_node, "/ibm,vtpm", "linux,sml-size",
+   prom_setprop(ibmvtpm_node, "/vdevice/vtpm", "linux,sml-size",
 , sizeof(size));
 
prom_debug("sml base = 0x%x\n", base);
diff --git a/drivers/char/tpm/tpm_of.c b/drivers/char/tpm/tpm_of.c
index 62a22ce..6c73199 100644
--- a/drivers/char/tpm/tpm_of.c
+++ b/drivers/char/tpm/tpm_of.c
@@ -31,7 +31,7 @@ int read_log(struct tpm_bios_log *log)
return -EFAULT;
}
 
-   np = of_find_node_by_name(NULL, "ibm,vtpm");
+   np = of_find_node_by_name(NULL, "vtpm");
if (!np) {
pr_err("%s: ERROR - IBMVTPM not supported\n", __func__);
return -ENODEV;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/3] vTPM: get the buffer allocated for event log instead of the actual log

[Hon Ching(Vicky) Lo]

The OS should ask Power Firmware (PFW) for the size of the buffer
allocated for the event log, instead of the size of the actual
event log.  It then passes the buffer adddress and size to PFW in
the handover process, into which PFW copies the log.

Signed-off-by: Hon Ching(Vicky) Lo 
---
 arch/powerpc/kernel/prom_init.c |   21 +++--
 1 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 8a5c248..08fe5e7 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1442,13 +1442,20 @@ static void __init prom_instantiate_sml(void)
prom_printf("Reformat SML to EFI alignment failed\n");
return;
}
-   }
 
-   if (call_prom_ret("call-method", 2, 2, ,
- ADDR("sml-get-handover-size"),
- ibmvtpm_inst) != 0 || size == 0) {
-   prom_printf("SML get handover size failed\n");
-   return;
+   if (call_prom_ret("call-method", 2, 2, ,
+ ADDR("sml-get-allocated-size"),
+ ibmvtpm_inst) != 0 || size == 0) {
+   prom_printf("SML get allocated size failed\n");
+   return;
+   }
+   } else {
+   if (call_prom_ret("call-method", 2, 2, ,
+ ADDR("sml-get-handover-size"),
+ ibmvtpm_inst) != 0 || size == 0) {
+   prom_printf("SML get handover size failed\n");
+   return;
+   }
}
 
base = alloc_down(size, PAGE_SIZE, 0);
@@ -1457,6 +1464,8 @@ static void __init prom_instantiate_sml(void)
 
prom_printf("instantiating sml at 0x%x...", base);
 
+   memset((void *)base, 0, size);
+
if (call_prom_ret("call-method", 4, 2, ,
  ADDR("sml-handover"),
  ibmvtpm_inst, size, base) != 0 || entry == 0) {
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] vTPM: fix memory allocation flag for rtce buffer at kernel boot

[Hon Ching(Vicky) Lo]

At ibm vtpm initialzation, tpm_ibmvtpm_probe() registers its interrupt
handler, ibmvtpm_interrupt, which calls ibmvtpm_crq_process to allocate
memory for rtce buffer.  The current code uses 'GFP_KERNEL' as the
type of kernel memory allocation, which resulted a warning at
kernel/lockdep.c.  This patch uses 'GFP_ATOMIC' instead so that the
allocation is high-priority and does not sleep.

Signed-off-by: Hon Ching(Vicky) Lo 
---
 drivers/char/tpm/tpm_ibmvtpm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 27ebf95..3e6a226 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -491,7 +491,7 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
}
ibmvtpm->rtce_size = be16_to_cpu(crq->len);
ibmvtpm->rtce_buf = kmalloc(ibmvtpm->rtce_size,
-   GFP_KERNEL);
+   GFP_ATOMIC);
if (!ibmvtpm->rtce_buf) {
dev_err(ibmvtpm->dev, "Failed to allocate 
memory for rtce buffer\n");
return;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-all] [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

[Michael Ellerman]

On Wed, 2015-10-07 at 21:56 +0800, Fengguang Wu wrote:
> On Tue, Oct 06, 2015 at 02:39:06PM +1100, Michael Ellerman wrote:
> > On Sat, 2015-10-03 at 04:33 +0800, kbuild test robot wrote:
> > > Hi Nishanth,
> > > 
> > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, 
> > > please ignore]
> > > 
> > > config: powerpc-defconfig (attached as .config)
> > > reproduce:
> > > wget 
> > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > >  -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > # save the attached .config to linux build tree
> > > make.cross ARCH=powerpc 
> > > 
> > > All error/warnings (new ones prefixed by >>):
> > > 
> > >arch/powerpc/platforms/pseries/iommu.c: In function 
> > > 'iommu_init_early_pSeries':
> > > >> arch/powerpc/platforms/pseries/iommu.c:1433:9: error: 'struct 
> > > >> machdep_calls' has no member named 'dma_get_page_shift'
> > >   ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
> > 
> > It was added in patch 3/5, so I think this error is bogus. Unless there's a
> > typo I'm missing?
> 
> Yes sorry, the patchset was not detected correctly in your case,
> ending up the patches being tested as individual ones.
> 
> I'll fixup the robot.

Thanks.

How did the robot decide to build this series in the first place? Does it build
everything sent to one of the lists on CC?

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/3] vTPM: fix searching for the right vTPM node in device tree

[Hon Ching(Vicky) Lo]

Replace all occurrences of '/ibm,vtpm' with '/vdevice/vtpm',
as only the latter is ganranteed to be available for the client OS.
The '/ibm,vtpm' node should only be used by Open Firmware, which
is susceptible to changes.

Signed-off-by: Hon Ching(Vicky) Lo 
---
 arch/powerpc/kernel/prom_init.c |8 
 drivers/char/tpm/tpm_of.c   |2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1a85d8f..b9b6bb1 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1422,12 +1422,12 @@ static void __init prom_instantiate_sml(void)
 
prom_debug("prom_instantiate_sml: start...\n");
 
-   ibmvtpm_node = call_prom("finddevice", 1, 1, ADDR("/ibm,vtpm"));
+   ibmvtpm_node = call_prom("finddevice", 1, 1, ADDR("/vdevice/vtpm"));
prom_debug("ibmvtpm_node: %x\n", ibmvtpm_node);
if (!PHANDLE_VALID(ibmvtpm_node))
return;
 
-   ibmvtpm_inst = call_prom("open", 1, 1, ADDR("/ibm,vtpm"));
+   ibmvtpm_inst = call_prom("open", 1, 1, ADDR("/vdevice/vtpm"));
if (!IHANDLE_VALID(ibmvtpm_inst)) {
prom_printf("opening vtpm package failed (%x)\n", ibmvtpm_inst);
return;
@@ -1456,9 +1456,9 @@ static void __init prom_instantiate_sml(void)
 
reserve_mem(base, size);
 
-   prom_setprop(ibmvtpm_node, "/ibm,vtpm", "linux,sml-base",
+   prom_setprop(ibmvtpm_node, "/vdevice/vtpm", "linux,sml-base",
 , sizeof(base));
-   prom_setprop(ibmvtpm_node, "/ibm,vtpm", "linux,sml-size",
+   prom_setprop(ibmvtpm_node, "/vdevice/vtpm", "linux,sml-size",
 , sizeof(size));
 
prom_debug("sml base = 0x%x\n", base);
diff --git a/drivers/char/tpm/tpm_of.c b/drivers/char/tpm/tpm_of.c
index 62a22ce..6c73199 100644
--- a/drivers/char/tpm/tpm_of.c
+++ b/drivers/char/tpm/tpm_of.c
@@ -31,7 +31,7 @@ int read_log(struct tpm_bios_log *log)
return -EFAULT;
}
 
-   np = of_find_node_by_name(NULL, "ibm,vtpm");
+   np = of_find_node_by_name(NULL, "vtpm");
if (!np) {
pr_err("%s: ERROR - IBMVTPM not supported\n", __func__);
return -ENODEV;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/3] vTPM: get the buffer allocated for event log instead of the actual log

[Hon Ching(Vicky) Lo]

The OS should ask Power Firmware (PFW) for the size of the buffer
allocated for the event log, instead of the size of the actual
event log.  It then passes the buffer adddress and size to PFW in
the handover process, into which PFW copies the log.

Signed-off-by: Hon Ching(Vicky) Lo 
---
 arch/powerpc/kernel/prom_init.c |   21 +++--
 1 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 8a5c248..08fe5e7 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1442,13 +1442,20 @@ static void __init prom_instantiate_sml(void)
prom_printf("Reformat SML to EFI alignment failed\n");
return;
}
-   }
 
-   if (call_prom_ret("call-method", 2, 2, ,
- ADDR("sml-get-handover-size"),
- ibmvtpm_inst) != 0 || size == 0) {
-   prom_printf("SML get handover size failed\n");
-   return;
+   if (call_prom_ret("call-method", 2, 2, ,
+ ADDR("sml-get-allocated-size"),
+ ibmvtpm_inst) != 0 || size == 0) {
+   prom_printf("SML get allocated size failed\n");
+   return;
+   }
+   } else {
+   if (call_prom_ret("call-method", 2, 2, ,
+ ADDR("sml-get-handover-size"),
+ ibmvtpm_inst) != 0 || size == 0) {
+   prom_printf("SML get handover size failed\n");
+   return;
+   }
}
 
base = alloc_down(size, PAGE_SIZE, 0);
@@ -1457,6 +1464,8 @@ static void __init prom_instantiate_sml(void)
 
prom_printf("instantiating sml at 0x%x...", base);
 
+   memset((void *)base, 0, size);
+
if (call_prom_ret("call-method", 4, 2, ,
  ADDR("sml-handover"),
  ibmvtpm_inst, size, base) != 0 || entry == 0) {
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] vTPM: fix memory allocation flag for rtce buffer at kernel boot

[Hon Ching(Vicky) Lo]

At ibm vtpm initialzation, tpm_ibmvtpm_probe() registers its interrupt
handler, ibmvtpm_interrupt, which calls ibmvtpm_crq_process to allocate
memory for rtce buffer.  The current code uses 'GFP_KERNEL' as the
type of kernel memory allocation, which resulted a warning at
kernel/lockdep.c.  This patch uses 'GFP_ATOMIC' instead so that the
allocation is high-priority and does not sleep.

Signed-off-by: Hon Ching(Vicky) Lo 
---
 drivers/char/tpm/tpm_ibmvtpm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 27ebf95..3e6a226 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -491,7 +491,7 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
}
ibmvtpm->rtce_size = be16_to_cpu(crq->len);
ibmvtpm->rtce_buf = kmalloc(ibmvtpm->rtce_size,
-   GFP_KERNEL);
+   GFP_ATOMIC);
if (!ibmvtpm->rtce_buf) {
dev_err(ibmvtpm->dev, "Failed to allocate 
memory for rtce buffer\n");
return;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/