Re: [RESEND 2/2] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks

[Peter Ujfalusi]

Hi Javier,

On 06/27/2014 09:23 PM, Javier Martinez Canillas wrote:
> Hello Peter,
> 
> On Fri, Jun 27, 2014 at 8:01 AM, Peter Ujfalusi  wrote:
>> Palmas class of devices can provide 32K clock(s) to be used by other devices
>> on the board. Depending on the actual device the provided clocks can be:
>> CLK32K_KG and CLK32K_KGAUDIO
>> or only one:
>> CLK32K_KG (TPS659039 for example)
>>
>> Use separate compatible flags for the two 32K clock.
>> A system which needs or have only one of the 32k clock from
>> Palmas will need to add node(s) for each clock as separate section
>> in the dts file.
>> The two compatible property is:
>> "ti,palmas-clk32kg" for clk32kg clock
>> "ti,palmas-clk32kgaudio" for clk32kgaudio clock
>>
>> Apart from the register control of the clocks - which is done via
>> the clock API there is a posibility to enable the external sleep
>> control. In this way the clock can be enabled/disabled on demand by the
>> user of the clock.
>>
>> See the documentation for more details.
>>
>> Signed-off-by: Peter Ujfalusi 
>> Reviewed-by: Nishanth Menon 

>> +static unsigned long palmas_clks_recalc_rate(struct clk_hw *hw,
>> +unsigned long parent_rate)
>> +{
>> +   return 32768;
>> +}
> 
> I see that other clock drivers using a constant rate return 0 if the
> clock has not been enabled.

and there are examples when similar fixed clock drivers returns only the clock
value, like clk-max77686. I can not find clear guidelines neither in the
documentation or around the header/c files for this.
Mike, what is the appropriate way of handling the recalc_rate?

> So maybe is more correct to have something
> like the following?
> 
> if (__clk_is_enabled(hw->clk))
> return 32768;
> else
> return 0;
> 
> Best regards,
> Javier
> 


-- 
Péter
--
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/4] uprobes: Change unregister/apply to WARN() if uprobe/consumer is gone

[Namhyung Kim]

On Fri, 27 Jun 2014 19:01:40 +0200, Oleg Nesterov wrote:
> Add WARN_ON's into uprobe_unregister() and uprobe_apply() to ensure
> that nobody tries to play with the dead uprobe/consumer. This helps
> to catch the bugs like the one fixed by the previous patch.
>
> In the longer term we should fix this poorly designed interface.
> uprobe_register() should return "struct uprobe *" which should be
> passed to apply/unregister. Plus other semantic changes, see the
> changelog in commit 41ccba029e94.
>
> Signed-off-by: Oleg Nesterov 

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  kernel/events/uprobes.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index c445e39..6f3254e 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -846,7 +846,7 @@ static void __uprobe_unregister(struct uprobe *uprobe, 
> struct uprobe_consumer *u
>  {
>   int err;
>  
> - if (!consumer_del(uprobe, uc))  /* WARN? */
> + if (WARN_ON(!consumer_del(uprobe, uc)))
>   return;
>  
>   err = register_for_each_vma(uprobe, NULL);
> @@ -927,7 +927,7 @@ int uprobe_apply(struct inode *inode, loff_t offset,
>   int ret = -ENOENT;
>  
>   uprobe = find_uprobe(inode, offset);
> - if (!uprobe)
> + if (WARN_ON(!uprobe))
>   return ret;
>  
>   down_write(>register_rwsem);
> @@ -952,7 +952,7 @@ void uprobe_unregister(struct inode *inode, loff_t 
> offset, struct uprobe_consume
>   struct uprobe *uprobe;
>  
>   uprobe = find_uprobe(inode, offset);
> - if (!uprobe)
> + if (WARN_ON(!uprobe))
>   return;
>  
>   down_write(>register_rwsem);
--
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/3] staging: cxt1e1: count fragmented packet properly.

[DaeSeok Youn]

2014-06-30 6:22 GMT+09:00 Greg KH :
> On Fri, Jun 27, 2014 at 06:56:08PM +0900, Daeseok Youn wrote:
>> OS_mem_token_tlen() is same return value as OS_mem_token_len().
>> That means packet count is always 1. So OS_mem_token_tlen()
>> must be total length of packet and OS_mem_token_len() has a
>> length of fragmented packet. And then it can count total
>> count of fragmented packets properly.
>>
>> And OS_mem_token_next() returns NULL, it will be dereferencing
>> a NULL pointer. So it must return next fragmented packet buffer as
>> sk_buff.
>>
>> Signed-off-by: Daeseok Youn 
>> ---
>> I'm not sure of this patch and not tested.(just only build test).
>> Please review for this.
>> Thanks.
>
> Please refresh these last two based on the changes in the first one you
> should do.
OK. I will sent these again after fixing 1/3.

thanks.

Daeseok Youn.
>
> thanks,
>
> greg k-h
--
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] regmap: Fix debugfs-file 'registers' mode

[Uwe Kleine-König]

Hi Markus,

On Sat, Jun 28, 2014 at 03:23:11PM +0200, Markus Pargmann wrote:
> The macro "REGMAP_ALLOW_WRITE_DEBUGFS" can be used to enable write
minor nit: I'd not call it "macro", but "cpp symbol" because macro
sounds more function-like. (There is another "macro" at the end of the
commit log.)

> support on the registers file in the debugfs. The mode of the file is
> fixed to 0400 so it is not possible to write the file ever.
> 
> This patch fixes the mode by setting it to the correct value depending
> on the macro.
> 
> Cc: Dimitris Papastamos 
> Signed-off-by: Markus Pargmann 
> ---
> 
> Hi,
> 
> as the kconfig option will probably not be merged, I extracted the mode fix of
> my previous patch.
> 
> Regards,
> 
> Markus
> 
>  drivers/base/regmap/regmap-debugfs.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/regmap/regmap-debugfs.c 
> b/drivers/base/regmap/regmap-debugfs.c
> index 45d812c0ea77..f45a0a0e0371 100644
> --- a/drivers/base/regmap/regmap-debugfs.c
> +++ b/drivers/base/regmap/regmap-debugfs.c
> @@ -512,7 +512,14 @@ void regmap_debugfs_init(struct regmap *map, const char 
> *name)
>   map, _reg_ranges_fops);
>  
>   if (map->max_register || regmap_readable(map, 0)) {
> - debugfs_create_file("registers", 0400, map->debugfs,
> + unsigned int registers_mode;
> +
> + if (IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS))
> + registers_mode = 0600;
> + else
> + registers_mode = 0400;
> +
> + debugfs_create_file("registers", registers_mode, map->debugfs,
>   map, _map_fops);
debugfs_create_file takes an umode_t as 2nd parameter. Maybe you should
pick that type for registers_mode here, too?

Best regards
Uwe

>   debugfs_create_file("access", 0400, map->debugfs,
>   map, _access_fops);

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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 1/3] staging: cxt1e1: Remove useless OS_phystov() and OS_vtophys()

[DaeSeok Youn]

Hi, Greg.

2014-06-30 6:21 GMT+09:00 Greg KH :
> On Fri, Jun 27, 2014 at 06:52:26PM +0900, Daeseok Youn wrote:
>> OS_phystov()/OS_vtophys() are replaced with __va()/__pa().
>
> No, you should use virt_to_phys() and phys_to_virt() instead of these
> internal macros which might not be correct for all architectures.
OK, I will send this again after changing __pa/__va.
Thanks.

regards,
Daeseok Youn
>
> thanks,
>
> greg k-h
--
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] udf: avoid redundant memcpy when writing data in ICB

[Chao Yu]

We have already copied the changed data of page to extent area in ICB when call
->write_end() of adinicb aops, so we do not need to copy them another time in
->writepage() of adinicb aops. SetPageUptodate is redundant too, so it's better
to remove these redundant codes.

Also it looks more reasonable to set inode dirty after extent area are modified,
we'd better move mark_inode_dirty() from ->writepage() to ->write_end().

Signed-off-by: Chao Yu 
---
 fs/udf/file.c |   12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/fs/udf/file.c b/fs/udf/file.c
index d80738f..3cd0a50 100644
--- a/fs/udf/file.c
+++ b/fs/udf/file.c
@@ -65,17 +65,7 @@ static int udf_adinicb_readpage(struct file *file, struct 
page *page)
 static int udf_adinicb_writepage(struct page *page,
 struct writeback_control *wbc)
 {
-   struct inode *inode = page->mapping->host;
-   char *kaddr;
-   struct udf_inode_info *iinfo = UDF_I(inode);
-
BUG_ON(!PageLocked(page));
-
-   kaddr = kmap(page);
-   memcpy(iinfo->i_ext.i_data + iinfo->i_lenEAttr, kaddr, inode->i_size);
-   mark_inode_dirty(inode);
-   SetPageUptodate(page);
-   kunmap(page);
unlock_page(page);
 
return 0;
@@ -115,6 +105,8 @@ static int udf_adinicb_write_end(struct file *file,
kaddr + offset, copied);
kunmap_atomic(kaddr);
 
+   mark_inode_dirty(inode);
+
return simple_write_end(file, mapping, pos, len, copied, page, fsdata);
 }
 
-- 
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/

Re: [crypto] BUG: unable to handle kernel paging request at ffff88000bb88000

[Fengguang Wu]

Hi Stephan,

On Sun, Jun 29, 2014 at 09:45:48PM +0200, Stephan Mueller wrote:
> Am Sonntag, 29. Juni 2014, 22:52:46 schrieb Fengguang Wu:
> 
> Hi Fengguang,
> 
> > Greetings,
> > 
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> 
> May I ask whether there is anything special in your kernel config?

It's an x86_64 randconfig. You may find it in the attachment of the
original report email.

> This very bug should have been triggered already in all previous code levels! 
> I am seriously wondering why this bug was not triggered before -- does kalloc 
> somehow allocates more memory than you requested? And only your specific 
> kernel config made kalloc to allocate the exact amount of memory that was 
> requested?

Yeah the bug may have been triggered in other places. If you see
anything valuable from this bisect result, it would be great. Judging
from the comparison of 64d1cdfbe2 and its parent commit 3332ee2a17,
it's pretty reproducible, so easy to verify the possible fixes.

++++
|| 
3332ee2a17 | 64d1cdfbe2 |
++++
| boot_successes | 
81 | 3  |
| boot_failures  | 
0  | 23 |
| BUG:unable_to_handle_kernel_paging_request | 
0  | 20 |
| Oops   | 
0  | 19 |
| RIP:kzfree | 
0  | 15 |
| WARNING:CPU:PID:at_kernel/rcu/tree.c:rcu_do_batch()| 
0  | 9  |
| backtrace:cryptomgr_test   | 
0  | 18 |
| backtrace:cpu_startup_entry| 
0  | 3  |
| kernel_BUG_at_include/linux/mm.h   | 
0  | 1  |
...

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 3/6] mmu_notifier: add event information to address invalidation v2

[John Hubbard]

On Fri, 27 Jun 2014, Jérôme Glisse wrote:

> From: Jérôme Glisse 
> 
> The event information will be usefull for new user of mmu_notifier API.
> The event argument differentiate between a vma disappearing, a page
> being write protected or simply a page being unmaped. This allow new
> user to take different path for different event for instance on unmap
> the resource used to track a vma are still valid and should stay around.
> While if the event is saying that a vma is being destroy it means that any
> resources used to track this vma can be free.
> 
> Changed since v1:
>   - renamed action into event (updated commit message too).
>   - simplified the event names and clarified their intented usage
> also documenting what exceptation the listener can have in
> respect to each event.
> 
> Signed-off-by: Jérôme Glisse 
> ---
>  drivers/gpu/drm/i915/i915_gem_userptr.c |   3 +-
>  drivers/iommu/amd_iommu_v2.c|  14 ++--
>  drivers/misc/sgi-gru/grutlbpurge.c  |   9 ++-
>  drivers/xen/gntdev.c|   9 ++-
>  fs/proc/task_mmu.c  |   6 +-
>  include/linux/hugetlb.h |   7 +-
>  include/linux/mmu_notifier.h| 117 
> ++--
>  kernel/events/uprobes.c |  10 ++-
>  mm/filemap_xip.c|   2 +-
>  mm/huge_memory.c|  51 --
>  mm/hugetlb.c|  25 ---
>  mm/ksm.c|  18 +++--
>  mm/memory.c |  27 +---
>  mm/migrate.c|   9 ++-
>  mm/mmu_notifier.c   |  28 +---
>  mm/mprotect.c   |  33 ++---
>  mm/mremap.c |   6 +-
>  mm/rmap.c   |  24 +--
>  virt/kvm/kvm_main.c |  12 ++--
>  19 files changed, 291 insertions(+), 119 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 21ea928..ed6f35e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -56,7 +56,8 @@ struct i915_mmu_object {
>  static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier 
> *_mn,
>  struct mm_struct *mm,
>  unsigned long start,
> -unsigned long end)
> +unsigned long end,
> +enum mmu_event event)
>  {
>   struct i915_mmu_notifier *mn = container_of(_mn, struct 
> i915_mmu_notifier, mn);
>   struct interval_tree_node *it = NULL;
> diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2.c
> index 499b436..2bb9771 100644
> --- a/drivers/iommu/amd_iommu_v2.c
> +++ b/drivers/iommu/amd_iommu_v2.c
> @@ -414,21 +414,25 @@ static int mn_clear_flush_young(struct mmu_notifier *mn,
>  static void mn_change_pte(struct mmu_notifier *mn,
> struct mm_struct *mm,
> unsigned long address,
> -   pte_t pte)
> +   pte_t pte,
> +   enum mmu_event event)
>  {
>   __mn_flush_page(mn, address);
>  }
>  
>  static void mn_invalidate_page(struct mmu_notifier *mn,
>  struct mm_struct *mm,
> -unsigned long address)
> +unsigned long address,
> +enum mmu_event event)
>  {
>   __mn_flush_page(mn, address);
>  }
>  
>  static void mn_invalidate_range_start(struct mmu_notifier *mn,
> struct mm_struct *mm,
> -   unsigned long start, unsigned long end)
> +   unsigned long start,
> +   unsigned long end,
> +   enum mmu_event event)
>  {
>   struct pasid_state *pasid_state;
>   struct device_state *dev_state;
> @@ -449,7 +453,9 @@ static void mn_invalidate_range_start(struct mmu_notifier 
> *mn,
>  
>  static void mn_invalidate_range_end(struct mmu_notifier *mn,
>   struct mm_struct *mm,
> - unsigned long start, unsigned long end)
> + unsigned long start,
> + unsigned long end,
> + enum mmu_event event)
>  {
>   struct pasid_state *pasid_state;
>   struct device_state *dev_state;
> diff --git a/drivers/misc/sgi-gru/grutlbpurge.c 
> b/drivers/misc/sgi-gru/grutlbpurge.c
> index 2129274..e67fed1 100644
> --- a/drivers/misc/sgi-gru/grutlbpurge.c
> +++ b/drivers/misc/sgi-gru/grutlbpurge.c
> @@ 

Re: [PATCH 1/1] ARM: dts: zynq: Add Parallella device tree

[Olof Johansson]

Hi,

On Sun, Jun 29, 2014 at 1:50 PM, Andreas Färber  wrote:
> This allows to boot the Adapteva Parallella board to serial console.
>
> Cc: Andreas Olofsson 
> Signed-off-by: Andreas Färber 

Nice and clean DTS, just a couple of comments below.

> diff --git a/arch/arm/boot/dts/zynq-parallella.dts 
> b/arch/arm/boot/dts/zynq-parallella.dts
> new file mode 100644
> index 000..98df66c
> --- /dev/null
> +++ b/arch/arm/boot/dts/zynq-parallella.dts
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright (c) 2014 SUSE LINUX Products GmbH
> + *
> + * Derived from zynq-zed.dts:
> + *
> + *  Copyright (C) 2011 Xilinx
> + *  Copyright (C) 2012 National Instruments Corp.
> + *  Copyright (C) 2013 Xilinx
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +/dts-v1/;
> +/include/ "zynq-7000.dtsi"
> +
> +/ {
> +   model = "Parallella Board";
> +   compatible = "xlnx,zynq-7000";

This should have a more specific compatible as the first one. Probably
something like:
   compatible = "adapteva,parallella", "xlnx,zynq-7000";

> +
> +   memory {
> +   device_type = "memory";
> +   reg = <0 0x2000>;

Does the bootloader update this entry, or is it truly static? If it's
updated then it's become recent habit to leave the memory size empty
in the static file.

> +   };
> +
> +   chosen {
> +   bootargs = "console=ttyPS0,115200 earlyprintk 
> root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait";
> +   };
> +};

A bit more torn on this one, I'm OK with it staying in even if
firmware overrides for all practical purposes since it's good to keep
around for reference w.r.t. console. Note that we're starting to move
over to using /chosen/stdout-path, so you might want to add that now
instead of later.


-Olof
--
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] regulator: tps65917: Fix SMPS enable/disable/is_enable

[Keerthy]

Hi Nishanth,

On Friday 27 June 2014 10:45 PM, Nishanth Menon wrote:

On 14:48-20140627, Keerthy wrote:

Hello Nishanth,

On Friday 27 June 2014 12:01 AM, Nishanth Menon wrote:

We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend on valid
enable_reg, enable_mask and enable_value in regulator descriptor.

So, similar to fix we did in commit 318dbb02b50c
("regulator: palmas: Fix SMPS enable/disable/is_enabled"), populate the
same for TPS65917 SMPS registration. LDO definitions are already in place.

Fixes: d6f83370ed97 ("regulator: palmas: Add tps65917 PMIC support")
Signed-off-by: Nishanth Menon 
---

Applies on:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
branch: topic/palmas (4c0c9ca Merge remote-tracking branch 
'regulator/fix/palmas' into regulator-palmas)

Note: Ignored the minor style check from checkpatch --strict as fixing
it would create an 80 char warning

  drivers/regulator/palmas-regulator.c |8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/regulator/palmas-regulator.c 
b/drivers/regulator/palmas-regulator.c
index 7c8b441..c7aa1b1 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1333,6 +1333,14 @@ static int tps65917_smps_registration(struct palmas_pmic 
*pmic,
pmic->current_reg_mode[id] = reg &
PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
+   pmic->desc[id].enable_reg =
+   PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
+   palmas_regs_info[id].ctrl_addr);

This is wrong. Please change palmas_regs_info[id].ctrl_addr to
ddata->palmas_regs_info[id].ctrl_addr. The palmas_regs_info
should come from the driver data for specific instances as the regmap
is different for the different PMICs we support.

Once you make the above changes please feel free to add

Uggh.. just realized... since I was testing CPUFREQ with SMPS1 never
realized it. and searched elsewhere on topic/palmas branch as well..
Looks like we should make the following changes? since the register data
is now a parameter and it so happened that palmas_reg_info was mapping
back to a valid variable and the error is easily missed - so rename the
variable as well - I can break this up as proper series of patches for
topic/palmas - let me know what you think..


diff --git a/drivers/regulator/palmas-regulator.c 
b/drivers/regulator/palmas-regulator.c
index 7c8b441..86fefdfb 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -41,7 +41,7 @@ static const struct regulator_linear_range smps_high_ranges[] 
= {
REGULATOR_LINEAR_RANGE(330, 0x7A, 0x7f, 0),
  };
  
-static struct regs_info palmas_regs_info[] = {

+static struct regs_info palmas_generic_regs_info[] = {



Good renaming but You need to make one more change i guess. Otherwise
there is a compilation break.

@@ -643,7 +643,8 @@
static int palmas_regulator_config_external(struct palmas *palmas, int id,
 struct palmas_reg_init *reg_init)
{
-int sleep_id = palmas_regs_info[id].sleep_id;
+struct palmas_pmic_driver_data *ddata = palmas->pmic_ddata;
+int sleep_id = ddata->palmas_regs_info[id].sleep_id;
 int ret;

Including the above change.
Tested-by: Keerthy .


{
.name   = "SMPS12",
.sname  = "smps1-in",
@@ -1165,18 +1165,18 @@ static int palmas_smps_registration(struct palmas_pmic 
*pmic,
pmic->desc[id].ops = _ops_smps10;
pmic->desc[id].vsel_reg =
PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
-   PALMAS_SMPS10_CTRL);
+   
ddata->palmas_regs_info[id].ctrl_addr);
pmic->desc[id].vsel_mask = SMPS10_VSEL;
pmic->desc[id].enable_reg =
PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
-   PALMAS_SMPS10_CTRL);
+   
ddata->palmas_regs_info[id].ctrl_addr);
if (id == PALMAS_REG_SMPS10_OUT1)
pmic->desc[id].enable_mask = SMPS10_SWITCH_EN;
else
pmic->desc[id].enable_mask = SMPS10_BOOST_EN;
pmic->desc[id].bypass_reg =
PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
-   PALMAS_SMPS10_CTRL);
+   
ddata->palmas_regs_info[id].ctrl_addr);
pmic->desc[id].bypass_mask = SMPS10_BYPASS_EN;
pmic->desc[id].min_uV = 375;
pmic->desc[id].uV_step = 

RE: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error reporting driver

[bharat.bhus...@freescale.com]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, June 04, 2014 10:38 PM
> To: Bhushan Bharat-R65777
> Cc: Greg Kroah-Hartman; linuxppc-...@lists.ozlabs.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error
> reporting driver
> 
> On Wed, 2014-06-04 at 12:04 -0500, Bhushan Bharat-R65777 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, June 04, 2014 10:12 PM
> > > To: Bhushan Bharat-R65777
> > > Cc: Greg Kroah-Hartman; linuxppc-...@lists.ozlabs.org; linux-
> > > ker...@vger.kernel.org
> > > Subject: Re: [RESEND PATCH] memory: Freescale CoreNet Coherency
> > > Fabric error reporting driver
> > >
> > > On Wed, 2014-06-04 at 03:17 -0500, Bhushan Bharat-R65777 wrote:
> > > > > +static int ccf_remove(struct platform_device *pdev) {
> > > > > + struct ccf_private *ccf = dev_get_drvdata(>dev);
> > > > > +
> > > > > + switch (ccf->info->version) {
> > > > > + case CCF1:
> > > > > + iowrite32be(0, >err_regs->errdis);
> > > > > + break;
> > > > > +
> > > > > + case CCF2:
> > > > > + iowrite32be(0, >err_regs->errinten);
> > > >
> > > > Do you think it is same to disable detection bits in ccf->err_regs-
> >errdis?
> > >
> > > Disabling the interrupt is what we're aiming for here, but ccf1
> > > doesn't provide a way to do that separate from disabling detection.
> >
> > What I wanted to say that do we also need to disable detection (set
> > ERRDET_LAE | ERRDET_CV bits in errdis) apart from clearing errinten on
> > ccf2 ?
> 
> I don't think we "need" to.  You could argue that we should for consistency,
> though I think there's value in errors continuing to be detected even without
> the driver (e.g. can dump the registers in a debugger).

Yes this comment was for consistency. Also IIUC, the state which is left when 
the driver is removed is not default reset behavior.
If we want errors to be detected then should not we have a sysfs interface?

Thanks
-Bharat

> 
> -Scott
> 

Re: [PATCH] cpufreq: make table sentinal macros unsigned to match use

[Viresh Kumar]

On 28 June 2014 02:39, Brian W Hart  wrote:
> Commit 5eeaf1f18973 (cpufreq: Fix build error on some platforms that
> use cpufreq_for_each_*) moved function cpufreq_next_valid() to a public
> header.  Warnings are now generated when objects including that header
> are built with -Wsign-compare (as an out-of-tree module might be):
>
> .../include/linux/cpufreq.h: In function ‘cpufreq_next_valid’:
> .../include/linux/cpufreq.h:519:27: warning: comparison between signed
> and unsigned integer expressions [-Wsign-compare]
>   while ((*pos)->frequency != CPUFREQ_TABLE_END)
>^
> .../include/linux/cpufreq.h:520:25: warning: comparison between signed
> and unsigned integer expressions [-Wsign-compare]
>if ((*pos)->frequency != CPUFREQ_ENTRY_INVALID)
>  ^
>
> Constants CPUFREQ_ENTRY_INVALID and CPUFREQ_TABLE_END are signed, but
> are used with unsigned member 'frequency' of cpufreq_frequency_table.
> Update the macro definitions to be explicitly unsigned to match their
> use.
>
> This also corrects potentially wrong behavior of clk_rate_table_iter()
> if unsigned long is wider than usigned int.
>
> Signed-off-by: Brian W Hart 
> ---
> These macros are fairly broadly used in the kernel so I was bit leery
> of changing them, but after inspection I think it's fine.  I found 102
> uses of the macros, of which:
>
> 99 are uses with cpufreq_frequency_table.frequency (95) or with local
>variables of the same type as frequency (4).  These should be just
>fine with this change--we're just making explicit a conversion that
>was previously implicit.
>
>  2 are uses with a local variable of different type (unsigned long) than
>'frequency' (in drivers/sh/clk/core.c).  One of these uses is safe;
>the other (in clk_rate_table_iter()) is broken if unsigned long
>is wider than unsigned int.  As a side-effect, this patch corrects
>the potential misbehavior there.
>
>  1 is a use in macro cpufreq_for_each_entry() with what _should_ be the
>frequency member of a cpufreq_frequency_table, provided the caller it
>well-behaved.  There are 18 callers of this macro; all are well-behaved.
>So these should also be safe.

I would have moved some of it to logs, they look good.

>  include/linux/cpufreq.h |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index ec4112d..8f8ae95 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -482,8 +482,8 @@ extern struct cpufreq_governor cpufreq_gov_conservative;
>   */
>
>  /* Special Values of .frequency field */
> -#define CPUFREQ_ENTRY_INVALID  ~0
> -#define CPUFREQ_TABLE_END  ~1
> +#define CPUFREQ_ENTRY_INVALID  ~0u
> +#define CPUFREQ_TABLE_END  ~1u
>  /* Special Values of .flags field */
>  #define CPUFREQ_BOOST_FREQ (1 << 0)

Thanks.

Acked-by: Viresh Kumar 
--
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] cpufreq: cpu0: Extend support beyond CPU0

[Viresh Kumar]

On 28 June 2014 20:22, Shawn Guo  wrote:
> Thanks for all the effort on maintaining and improving cpufreq-cpu0
> driver.

You're welcome..

> Your patch rewrote the most part of the driver, so I'd like to
> hand over the driver to you.  Please add yourself as the primary person
> for MODULE_AUTHOR.

I don't think a complete handover would be right, and so still keeping
you as author :)

Author: Viresh Kumar 
Date:   Mon Jun 30 10:15:22 2014 +0530

cpufreq: cpu0: Add Module Author

Two people are maintaining it now, Viresh and Shawn. Add Viresh's details in
MODULE_AUTHOR() and copyright section.

Suggested-by: Shawn Guo 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq-generic.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/cpufreq/cpufreq-generic.c
b/drivers/cpufreq/cpufreq-generic.c
index 4da3f2f..5656dd1 100644
--- a/drivers/cpufreq/cpufreq-generic.c
+++ b/drivers/cpufreq/cpufreq-generic.c
@@ -1,6 +1,9 @@
 /*
  * Copyright (C) 2012 Freescale Semiconductor, Inc.
  *
+ * Copyright (C) 2014 Linaro.
+ * Viresh Kumar 
+ *
  * The OPP code in function set_target() is reused from
  * drivers/cpufreq/omap-cpufreq.c
  *
@@ -402,6 +405,7 @@ static struct platform_driver generic_cpufreq_platdrv = {
 };
 module_platform_driver(generic_cpufreq_platdrv);

+MODULE_AUTHOR("Viresh Kumar ");
 MODULE_AUTHOR("Shawn Guo ");
 MODULE_DESCRIPTION("Generic cpufreq driver");
 MODULE_LICENSE("GPL");
--
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] Fixes return issues in uic_init_one

[Nicholas Krause]

This patch fixes the FIXME messages for returning a ENOMEM error
if uic is not allocated and if uic->irqhost is not allocated a
IRQ domain that is linear returns EIO.

Signed-off-by: Nicholas Krause 
---
 arch/powerpc/sysdev/uic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index 9203393..f95010a 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -239,7 +239,7 @@ static struct uic * __init uic_init_one(struct device_node 
*node)
 
uic = kzalloc(sizeof(*uic), GFP_KERNEL);
if (! uic)
-   return NULL; /* FIXME: panic? */
+   return -ENOMEM; 
 
raw_spin_lock_init(>lock);
indexp = of_get_property(node, "cell-index", );
@@ -261,7 +261,7 @@ static struct uic * __init uic_init_one(struct device_node 
*node)
uic->irqhost = irq_domain_add_linear(node, NR_UIC_INTS, _host_ops,
 uic);
if (! uic->irqhost)
-   return NULL; /* FIXME: panic? */
+   return -EIO; 
 
/* Start with all interrupts disabled, level and non-critical */
mtdcr(uic->dcrbase + UIC_ER, 0);
-- 
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 v5 05/14] clk: Add generic driver for Maxim PMIC clocks

[Yadwinder Singh Brar]

Hi Javier,

On Thu, Jun 26, 2014 at 11:45 PM, Javier Martinez Canillas
 wrote:
> Maxim Integrated Power Management ICs are very similar with
> regard to their clock outputs. Most of the clock drivers for
> these chips are duplicating code and are simpler enough that
> can be converted to use a generic driver to consolidate code
> and avoid duplication.
>
> Signed-off-by: Javier Martinez Canillas 
> Reviewed-by: Krzysztof Kozlowski 
> ---
>
> Changes since v4:
>  - Return recalc 0 if clock isn't enabled in Suggested by Yadwinder Singh 
> Brar.
>

It seems you didn't implement or posted same patch again :) .

> Changes since v3:
>  - Add current copyright information. Suggested by Krzysztof Kozlowski
>  - Do a single allocation for struct max_gen_clk. Suggested by Krzysztof 
> Kozlowski
>  - Add EXPORT_SYMBOL() for exported symbols. Suggested by Krzysztof Kozlowski
>
>  drivers/clk/Kconfig   |   3 +
>  drivers/clk/Makefile  |   1 +
>  drivers/clk/clk-max-gen.c | 195 
> ++
>  drivers/clk/clk-max-gen.h |  32 
>  4 files changed, 231 insertions(+)
>  create mode 100644 drivers/clk/clk-max-gen.c
>  create mode 100644 drivers/clk/clk-max-gen.h
>

[ .. ]

> +
> +static unsigned long max_gen_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> +   return 32768;
> +}

Its still same here.

> +
> +struct clk_ops max_gen_clk_ops = {
> +   .prepare= max_gen_clk_prepare,
> +   .unprepare  = max_gen_clk_unprepare,
> +   .is_prepared= max_gen_clk_is_prepared,
> +   .recalc_rate= max_gen_recalc_rate,
> +};
> +EXPORT_SYMBOL_GPL(max_gen_clk_ops);
> +
> +static struct clk *max_gen_clk_register(struct device *dev,
> +   struct max_gen_clk *max_gen)
> +{
> +   struct clk *clk;
> +   struct clk_hw *hw = _gen->hw;
> +
> +   clk = clk_register(dev, hw);
> +   if (IS_ERR(clk))
> +   return clk;
> +
> +   max_gen->lookup = kzalloc(sizeof(struct clk_lookup), GFP_KERNEL);

As I suggested in other patch[1] also, its better to use
clkdev_alloc() instead of kzalloc() here.

> +   if (!max_gen->lookup)
> +   return ERR_PTR(-ENOMEM);
> +
> +   max_gen->lookup->con_id = hw->init->name;

Also IMO,  init->name should be over-written if name is provided in DT,
otherwise generic "clock-output-names" property will go futile,
perhaps it should be done before clk_register.

Regards,
Yadwinder

[1] : https://lkml.org/lkml/2014/6/27/197

> +   max_gen->lookup->clk = clk;
> +
> +   clkdev_add(max_gen->lookup);
> +
> +   return clk;
> +}
> +
> +int max_gen_clk_probe(struct platform_device *pdev, struct regmap *regmap,
> + u32 reg, struct clk_init_data *clks_init, int num_init)
> +{
> +   int i, ret;
> +   struct max_gen_clk *max_gen_clks;
> +   struct clk **clocks;
> +   struct device *dev = >dev;
> +
> +   clocks = devm_kzalloc(dev, sizeof(struct clk *) * num_init, 
> GFP_KERNEL);
> +   if (!clocks)
> +   return -ENOMEM;
> +
> +   max_gen_clks = devm_kzalloc(dev, sizeof(struct max_gen_clk)
> +   * num_init, GFP_KERNEL);
> +   if (!max_gen_clks)
> +   return -ENOMEM;
> +
> +   for (i = 0; i < num_init; i++) {
> +   max_gen_clks[i].regmap = regmap;
> +   max_gen_clks[i].mask = 1 << i;
> +   max_gen_clks[i].reg = reg;
> +   max_gen_clks[i].hw.init = _init[i];
> +
> +   clocks[i] = max_gen_clk_register(dev, _gen_clks[i]);
> +   if (IS_ERR(clocks[i])) {
> +   ret = PTR_ERR(clocks[i]);
> +   dev_err(dev, "failed to register %s\n",
> +   max_gen_clks[i].hw.init->name);
> +   goto err_clocks;
> +   }
> +   }
> +
> +   platform_set_drvdata(pdev, clocks);
> +
> +   if (dev->of_node) {
> +   struct clk_onecell_data *of_data;
> +
> +   of_data = devm_kzalloc(dev, sizeof(*of_data), GFP_KERNEL);
> +   if (!of_data) {
> +   ret = -ENOMEM;
> +   goto err_clocks;
> +   }
> +
> +   of_data->clks = clocks;
> +   of_data->clk_num = num_init;
> +   ret = of_clk_add_provider(dev->of_node, 
> of_clk_src_onecell_get,
> + of_data);
> +
> +   if (ret) {
> +   dev_err(dev, "failed to register OF clock 
> provider\n");
> +   goto err_clocks;
> +   }
> +   }
> +
> +   return 0;
> +
> +err_clocks:
> +   for (--i; i >= 0; --i) {
> +   clkdev_drop(max_gen_clks[i].lookup);
> +   clk_unregister(max_gen_clks[i].hw.clk);
> +   }
> +
> +   return ret;
> +}
> 

Re: [PATCH 2/6] mm: differentiate unmap for vmscan from other unmap.

[John Hubbard]

On Fri, 27 Jun 2014, Jérôme Glisse wrote:

> From: Jérôme Glisse 
> 
> New code will need to be able to differentiate between a regular unmap and
> an unmap trigger by vmscan in which case we want to be as quick as possible.
> 
> Signed-off-by: Jérôme Glisse 
> ---
>  include/linux/rmap.h | 15 ---
>  mm/memory-failure.c  |  2 +-
>  mm/vmscan.c  |  4 ++--
>  3 files changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> index be57450..eddbc07 100644
> --- a/include/linux/rmap.h
> +++ b/include/linux/rmap.h
> @@ -72,13 +72,14 @@ struct anon_vma_chain {
>  };
>  
>  enum ttu_flags {
> - TTU_UNMAP = 1,  /* unmap mode */
> - TTU_MIGRATION = 2,  /* migration mode */
> - TTU_MUNLOCK = 4,/* munlock mode */
> -
> - TTU_IGNORE_MLOCK = (1 << 8),/* ignore mlock */
> - TTU_IGNORE_ACCESS = (1 << 9),   /* don't age */
> - TTU_IGNORE_HWPOISON = (1 << 10),/* corrupted page is recoverable */
> + TTU_VMSCAN = 1, /* unmap for vmscan */
> + TTU_POISON = 2, /* unmap for poison */
> + TTU_MIGRATION = 4,  /* migration mode */
> + TTU_MUNLOCK = 8,/* munlock mode */
> +
> + TTU_IGNORE_MLOCK = (1 << 9),/* ignore mlock */
> + TTU_IGNORE_ACCESS = (1 << 10),  /* don't age */
> + TTU_IGNORE_HWPOISON = (1 << 11),/* corrupted page is recoverable */

Unless there is a deeper purpose that I am overlooking, I think it would 
be better to leave the _MLOCK, _ACCESS, and _HWPOISON at their original 
values. I just can't quite see why they would need to start at bit 9 
instead of bit 8...

>  };
>  
>  #ifdef CONFIG_MMU
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index a7a89eb..ba176c4 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -887,7 +887,7 @@ static int page_action(struct page_state *ps, struct page 
> *p,
>  static int hwpoison_user_mappings(struct page *p, unsigned long pfn,
> int trapno, int flags, struct page **hpagep)
>  {
> - enum ttu_flags ttu = TTU_UNMAP | TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS;
> + enum ttu_flags ttu = TTU_POISON | TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS;
>   struct address_space *mapping;
>   LIST_HEAD(tokill);
>   int ret;
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 6d24fd6..5a7d286 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1163,7 +1163,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone 
> *zone,
>   }
>  
>   ret = shrink_page_list(_pages, zone, ,
> - TTU_UNMAP|TTU_IGNORE_ACCESS,
> + TTU_VMSCAN|TTU_IGNORE_ACCESS,
>   , , , , , true);
>   list_splice(_pages, page_list);
>   mod_zone_page_state(zone, NR_ISOLATED_FILE, -ret);
> @@ -1518,7 +1518,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
> lruvec *lruvec,
>   if (nr_taken == 0)
>   return 0;
>  
> - nr_reclaimed = shrink_page_list(_list, zone, sc, TTU_UNMAP,
> + nr_reclaimed = shrink_page_list(_list, zone, sc, TTU_VMSCAN,
>   _dirty, _unqueued_dirty, _congested,
>   _writeback, _immediate,
>   false);
> -- 
> 1.9.0
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> 

Other than that, looks good.

Reviewed-by: John Hubbard 

thanks,
John H.

[PATCH v3 3/3] cgroup: fix a race between cgroup_mount() and cgroup_kill_sb()

[Li Zefan]

We've converted cgroup to kernfs so cgroup won't be intertwined with
vfs objects and locking, but there are dark areas.

Run two instances of this script concurrently:

for ((; ;))
{
mount -t cgroup -o cpuacct xxx /cgroup
umount /cgroup
}

After a while, I saw two mount processes were stuck at retrying, because
they were waiting for a subsystem to become free, but the root associated
with this subsystem never got freed.

This can happen, if thread A is in the process of killing superblock but
hasn't called percpu_ref_kill(), and at this time thread B is mounting
the same cgroup root and finds the root in the root list and performs
percpu_ref_try_get().

To fix this, we try to increase both the refcnt of the superblock and the
percpu refcnt of cgroup root.

v2:
- we should try to get both the superblock refcnt and cgroup_root refcnt,
  because cgroup_root may have no superblock assosiated with it.
- adjust/add comments.

Cc:  # 3.15
Signed-off-by: Li Zefan 
---
 kernel/cgroup.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index d3662ac..11e40cf 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1655,6 +1655,7 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
int ret;
int i;
bool new_sb;
+   struct super_block *sb = NULL;
 
/*
 * The first time anyone tries to mount a cgroup, enable the list
@@ -1739,14 +1740,18 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
 
/*
 * A root's lifetime is governed by its root cgroup.
-* tryget_live failure indicate that the root is being
-* destroyed.  Wait for destruction to complete so that the
-* subsystems are free.  We can use wait_queue for the wait
-* but this path is super cold.  Let's just sleep for a bit
-* and retry.
+* pin_sb and tryget_live failure indicate that the root is
+* being destroyed.  Wait for destruction to complete so that
+* the subsystems are free.  We can use wait_queue for the
+* wait but this path is super cold.  Let's just sleep for
+* a bit and retry.
 */
-   if (!percpu_ref_tryget_live(>cgrp.self.refcnt)) {
+   sb = kernfs_pin_sb(root->kf_root, NULL);
+   if (IS_ERR(sb) ||
+   !percpu_ref_tryget_live(>cgrp.self.refcnt)) {
mutex_unlock(_mutex);
+   if (!IS_ERR_OR_NULL(sb))
+   deactivate_super(sb);
msleep(10);
ret = restart_syscall();
goto out_free;
@@ -1790,6 +1795,17 @@ out_free:
dentry = kernfs_mount(fs_type, flags, root->kf_root, _sb);
if (IS_ERR(dentry) || !new_sb)
cgroup_put(>cgrp);
+
+   if (sb) {
+   /*
+* On success kernfs_mount() returns with sb->s_umount held,
+* but kernfs_mount() also increases the superblock's refcnt,
+* so calling deactivate_super() to drop the refcnt we got when
+* looking up cgroup root won't acquire sb->s_umount again.
+*/
+   WARN_ON(new_sb);
+   deactivate_super(sb);
+   }
return dentry;
 }
 
-- 
1.8.0.2

--
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] bio-integrity: add "bip_max_vcnt" into struct bio_integrity_payload

[Gu Zheng]

Hi Martin,
On 06/30/2014 07:15 AM, Martin K. Petersen wrote:

>> "Gu" == Gu Zheng  writes:
> 
> [Sorry about the delay. I'm on vacation right now.]
> 
> Gu> But it seems that bip_integrity_vecs() will return the wrong number
> Gu> if the bio is not based on any bio_set for some reason(bio->bi_pool
> Gu> == NULL), because in that case, the bip_inline_vecs[0] is malloced
> Gu> directly.  So here we add the bip_max_vcnt to record the count of
> Gu> vector slots, and cleanup the function bip_integrity_vecs().
> 
> I'm in agreement with your fix.

Thanks.

> 
> However, I'm still not sure what the use case is for bios without an
> associated bioset. I do not see any callers that pass in a NULL bioset.

Please refer to bio_kmalloc()--alloc bio via kmalloc.
And IMO, the API(e.g. bio_alloc_bioset) is EXPORT, any guys(including
some out of mainline code, some special drivers) can alloc a bio via
kmalloc without based on associated bioset.

Regards,
Gu

> 


--
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 2/3] kernfs: introduce kernfs_pin_sb()

[Li Zefan]

kernfs_pin_sb() tries to get a refcnt of the superblock.

This will be used by cgroupfs.

v2:
- make kernfs_pin_sb() return the superblock.
- drop kernfs_drop_sb().

[ This is a prerequisite for a bugfix. ]
Cc:  # 3.15
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Li Zefan 
---
 fs/kernfs/mount.c  | 27 +++
 include/linux/kernfs.h |  1 +
 2 files changed, 28 insertions(+)

diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c
index f25a7c0..616c5c4 100644
--- a/fs/kernfs/mount.c
+++ b/fs/kernfs/mount.c
@@ -210,6 +210,33 @@ void kernfs_kill_sb(struct super_block *sb)
kernfs_put(root_kn);
 }
 
+/**
+ * kernfs_pin_sb: try to pin the superblock associated with a kernfs_root
+ * @kernfs_root: the kernfs_root in question
+ * @ns: the namespace tag
+ *
+ * Pin the superblock so the superblock won't be destroyed in subsequent
+ * operations. Return NULL if there's no superblock associated to this
+ * kernfs_root, or -EINVAL if the superblock is being freed.
+ */
+struct super_block *kernfs_pin_sb(struct kernfs_root *root, const void *ns)
+{
+   struct kernfs_super_info *info;
+   struct super_block *sb = NULL;
+
+   mutex_lock(_mutex);
+   list_for_each_entry(info, >supers, node) {
+   if (info->ns == ns) {
+   sb = info->sb;
+   if (!atomic_inc_not_zero(>sb->s_active))
+   sb = ERR_PTR(-EINVAL);
+   break;
+   }
+   }
+   mutex_unlock(_mutex);
+   return sb;
+}
+
 void __init kernfs_init(void)
 {
kernfs_node_cache = kmem_cache_create("kernfs_node_cache",
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 589318b..9096296 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -287,6 +287,7 @@ struct dentry *kernfs_mount_ns(struct file_system_type 
*fs_type, int flags,
   struct kernfs_root *root, bool *new_sb_created,
   const void *ns);
 void kernfs_kill_sb(struct super_block *sb);
+struct super_block *kernfs_pin_sb(struct kernfs_root *root, const void *ns);
 
 void kernfs_init(void);
 
-- 
1.8.0.2

--
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] cgroup: fix mount failure in a corner case

[Li Zefan]

  # cat test.sh
  #! /bin/bash

  mount -t cgroup -o cpu xxx /cgroup
  umount /cgroup

  mount -t cgroup -o cpu,cpuacct xxx /cgroup
  umount /cgroup
  # ./test.sh
  mount: xxx already mounted or /cgroup busy
  mount: according to mtab, xxx is already mounted on /cgroup

It's because the cgroupfs_root of the first mount was under destruction
asynchronously.

Fix this by delaying and then retrying mount for this case.

v3:
- put the refcnt immediately after getting it. (Tejun)

v2:
- use percpu_ref_tryget_live() rather that introducing
  percpu_ref_alive(). (Tejun)
- adjust comment.

Cc:  # 3.15
Signed-off-by: Li Zefan 
---
 kernel/cgroup.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 1c65f24..d3662ac 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1648,10 +1648,12 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
 int flags, const char *unused_dev_name,
 void *data)
 {
+   struct cgroup_subsys *ss;
struct cgroup_root *root;
struct cgroup_sb_opts opts;
struct dentry *dentry;
int ret;
+   int i;
bool new_sb;
 
/*
@@ -1677,6 +1679,25 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
goto out_unlock;
}
 
+   /*
+* Destruction of cgroup root is asynchronous, so we may fail to
+* mount a cgroupfs if it immediately follows a umount. Let's wait
+* a little bit and retry.
+*/
+   for_each_subsys(ss, i) {
+   if (!(opts.subsys_mask & (1 << i)) ||
+   ss->root == _dfl_root)
+   continue;
+
+   if (!percpu_ref_tryget_live(>root->cgrp.self.refcnt)) {
+   mutex_unlock(_mutex);
+   msleep(10);
+   ret = restart_syscall();
+   goto out_free;
+   }
+   cgroup_put(>root->cgrp);
+   }
+
for_each_root(root) {
bool name_match = false;
 
-- 
1.8.0.2

--
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 1/6] mmput: use notifier chain to call subsystem exit handler.

[John Hubbard]

On Fri, 27 Jun 2014, Jérôme Glisse wrote:

> From: Jérôme Glisse 
> 
> Several subsystem require a callback when a mm struct is being destroy
> so that they can cleanup there respective per mm struct. Instead of
> having each subsystem add its callback to mmput use a notifier chain
> to call each of the subsystem.
> 
> This will allow new subsystem to register callback even if they are
> module. There should be no contention on the rw semaphore protecting
> the call chain and the impact on the code path should be low and
> burried in the noise.
> 
> Note that this patch also move the call to cleanup functions after
> exit_mmap so that new call back can assume that mmu_notifier_release
> have already been call. This does not impact existing cleanup functions
> as they do not rely on anything that exit_mmap is freeing. Also moved
> khugepaged_exit to exit_mmap so that ordering is preserved for that
> function.
> 
> Signed-off-by: Jérôme Glisse 
> ---
>  fs/aio.c| 29 ++---
>  include/linux/aio.h |  2 --
>  include/linux/ksm.h | 11 ---
>  include/linux/sched.h   |  5 +
>  include/linux/uprobes.h |  1 -
>  kernel/events/uprobes.c | 19 ---
>  kernel/fork.c   | 22 ++
>  mm/ksm.c| 26 +-
>  mm/mmap.c   |  3 +++
>  9 files changed, 85 insertions(+), 33 deletions(-)
> 
> diff --git a/fs/aio.c b/fs/aio.c
> index c1d8c48..1d06e92 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -774,20 +775,22 @@ ssize_t wait_on_sync_kiocb(struct kiocb *req)
>  EXPORT_SYMBOL(wait_on_sync_kiocb);
>  
>  /*
> - * exit_aio: called when the last user of mm goes away.  At this point, 
> there is
> + * aio_exit: called when the last user of mm goes away.  At this point, 
> there is
>   * no way for any new requests to be submited or any of the io_* syscalls to 
> be
>   * called on the context.
>   *
>   * There may be outstanding kiocbs, but free_ioctx() will explicitly wait on
>   * them.
>   */
> -void exit_aio(struct mm_struct *mm)
> +static int aio_exit(struct notifier_block *nb,
> + unsigned long action, void *data)
>  {
> + struct mm_struct *mm = data;
>   struct kioctx_table *table = rcu_dereference_raw(mm->ioctx_table);
>   int i;
>  
>   if (!table)
> - return;
> + return 0;
>  
>   for (i = 0; i < table->nr; ++i) {
>   struct kioctx *ctx = table->table[i];
> @@ -796,10 +799,10 @@ void exit_aio(struct mm_struct *mm)
>   continue;
>   /*
>* We don't need to bother with munmap() here - exit_mmap(mm)
> -  * is coming and it'll unmap everything. And we simply can't,
> -  * this is not necessarily our ->mm.
> -  * Since kill_ioctx() uses non-zero ->mmap_size as indicator
> -  * that it needs to unmap the area, just set it to 0.
> +  * have already been call and everything is unmap by now. But
> +  * to be safe set ->mmap_size to 0 since aio_free_ring() uses
> +  * non-zero ->mmap_size as indicator that it needs to unmap the
> +  * area.
>*/

Actually, I think the original part of the comment about kill_ioctx
was accurate, but the new reference to aio_free_ring looks like a typo 
(?).  I'd write the entire comment as follows (I've dropped the leading 
whitespace, for email):

/*
 * We don't need to bother with munmap() here - exit_mmap(mm)
 * has already been called and everything is unmapped by now.
 * But to be safe, set ->mmap_size to 0 since kill_ioctx() uses a
 * non-zero >mmap_size as an indicator that it needs to unmap the
 * area.
 */


>   ctx->mmap_size = 0;
>   kill_ioctx(mm, ctx, NULL);
> @@ -807,6 +810,7 @@ void exit_aio(struct mm_struct *mm)
>  
>   RCU_INIT_POINTER(mm->ioctx_table, NULL);
>   kfree(table);
> + return 0;
>  }
>  
>  static void put_reqs_available(struct kioctx *ctx, unsigned nr)
> @@ -1629,3 +1633,14 @@ SYSCALL_DEFINE5(io_getevents, aio_context_t, ctx_id,
>   }
>   return ret;
>  }
> +
> +static struct notifier_block aio_mmput_nb = {
> + .notifier_call  = aio_exit,
> + .priority   = 1,
> +};
> +
> +static int __init aio_init(void)
> +{
> + return mmput_register_notifier(_mmput_nb);
> +}
> +subsys_initcall(aio_init);
> diff --git a/include/linux/aio.h b/include/linux/aio.h
> index d9c92da..6308fac 100644
> --- a/include/linux/aio.h
> +++ b/include/linux/aio.h
> @@ -73,7 +73,6 @@ static inline void init_sync_kiocb(struct kiocb *kiocb, 
> struct file *filp)
>  extern ssize_t wait_on_sync_kiocb(struct kiocb *iocb);
>  extern void aio_complete(struct kiocb *iocb, long res, long res2);
>  struct mm_struct;
> -extern void 

[BUG] cpuset: lockdep warning

[Li Zefan]

Hi Tejun,

In this lockdep warning kernfs and workqueue are involved, so I'm not sure 
what's
happening here.

This was triggered when tasks were being moved to parent cpuset due to hotplug.
The kernel is 3.16-rc1, with no modification.

localhost:/ # mount -t cgroup -o cpuset xxx /cpuset
localhost:/ # mkdir /cpuset/tmp
localhost:/ # echo 1 > /cpuset/tmp/cpuset.cpus
localhost:/ # echo 0 > cpuset/tmp/cpuset.mems
localhost:/ # echo $$ > /cpuset/tmp/tasks
localhost:/ # echo 0 > /sys/devices/system/cpu/cpu1/online


[ 1810.292243] ==
[ 1810.292251] [ INFO: possible circular locking dependency detected ]
[ 1810.292259] 3.16.0-rc1-0.1-default+ #7 Not tainted
[ 1810.292266] ---
[ 1810.292273] kworker/1:0/32649 is trying to acquire lock:
[ 1810.292280]  (cgroup_mutex){+.+.+.}, at: [] 
cgroup_transfer_tasks+0x37/0x150
[ 1810.292300]
[ 1810.292300] but task is already holding lock:
[ 1810.292309]  (cpuset_hotplug_work){+.+...}, at: [] 
process_one_work+0x192/0x520
[ 1810.292327]
[ 1810.292327] which lock already depends on the new lock.
[ 1810.292327]
[ 1810.292339]
[ 1810.292339] the existing dependency chain (in reverse order) is:
[ 1810.292348]
[ 1810.292348] -> #2 (cpuset_hotplug_work){+.+...}:
[ 1810.292360][] validate_chain+0x656/0x7c0
[ 1810.292371][] __lock_acquire+0x382/0x660
[ 1810.292380][] lock_acquire+0xf9/0x170
[ 1810.292389][] flush_work+0x39/0x90
[ 1810.292398][] cpuset_write_resmask+0x51/0x120
[ 1810.292409][] cgroup_file_write+0x49/0x1f0
[ 1810.292419][] kernfs_fop_write+0xfd/0x190
[ 1810.292431][] vfs_write+0xe5/0x190
[ 1810.292443][] SyS_write+0x5c/0xc0
[ 1810.292452][] system_call_fastpath+0x16/0x1b
[ 1810.292464]
[ 1810.292464] -> #1 (s_active#175){.+}:
[ 1810.292476][] validate_chain+0x656/0x7c0
[ 1810.292486][] __lock_acquire+0x382/0x660
[ 1810.292495][] lock_acquire+0xf9/0x170
[ 1810.292504][] kernfs_drain+0x13b/0x1c0
[ 1810.292513][] __kernfs_remove+0xc8/0x220
[ 1810.292523][] kernfs_remove_by_name_ns+0x50/0xb0
[ 1810.292533][] cgroup_addrm_files+0x16e/0x290
[ 1810.292543][] cgroup_clear_dir+0x6d/0xa0
[ 1810.292552][] rebind_subsystems+0x10f/0x350
[ 1810.292562][] cgroup_setup_root+0x1bf/0x290
[ 1810.292571][] cgroup_mount+0x123/0x3d0
[ 1810.292581][] mount_fs+0x4d/0x1a0
[ 1810.292591][] vfs_kern_mount+0x79/0x160
[ 1810.292602][] do_new_mount+0xd9/0x200
[ 1810.292611][] do_mount+0x1dc/0x220
[ 1810.292621][] SyS_mount+0xbc/0xe0
[ 1810.292630][] system_call_fastpath+0x16/0x1b
[ 1810.292640]
[ 1810.292640] -> #0 (cgroup_mutex){+.+.+.}:
[ 1810.292651][] check_prev_add+0x43e/0x4b0
[ 1810.292660][] validate_chain+0x656/0x7c0
[ 1810.292669][] __lock_acquire+0x382/0x660
[ 1810.292678][] lock_acquire+0xf9/0x170
[ 1810.292687][] mutex_lock_nested+0x6f/0x380
[ 1810.292697][] cgroup_transfer_tasks+0x37/0x150
[ 1810.292707][] 
hotplug_update_tasks_insane+0x110/0x1d0
[ 1810.292718][] 
cpuset_hotplug_update_tasks+0x13d/0x180
[ 1810.292729][] cpuset_hotplug_workfn+0x18c/0x630
[ 1810.292739][] process_one_work+0x254/0x520
[ 1810.292748][] worker_thread+0x13d/0x3d0
[ 1810.292758][] kthread+0xf8/0x100
[ 1810.292768][] ret_from_fork+0x7c/0xb0
[ 1810.292778]
[ 1810.292778] other info that might help us debug this:
[ 1810.292778]
[ 1810.292789] Chain exists of:
[ 1810.292789]   cgroup_mutex --> s_active#175 --> cpuset_hotplug_work
[ 1810.292789]
[ 1810.292807]  Possible unsafe locking scenario:
[ 1810.292807]
[ 1810.292816]CPU0CPU1
[ 1810.292822]
[ 1810.292827]   lock(cpuset_hotplug_work);
[ 1810.292835]lock(s_active#175);
[ 1810.292845]lock(cpuset_hotplug_work);
[ 1810.292855]   lock(cgroup_mutex);
[ 1810.292862]
[ 1810.292862]  *** DEADLOCK ***
[ 1810.292862]
[ 1810.292872] 2 locks held by kworker/1:0/32649:
[ 1810.292878]  #0:  ("events"){.+.+.+}, at: [] 
process_one_work+0x192/0x520
[ 1810.292895]  #1:  (cpuset_hotplug_work){+.+...}, at: [] 
process_one_work+0x192/0x520
[ 1810.292911]
[ 1810.292911] stack backtrace:
[ 1810.292920] CPU: 1 PID: 32649 Comm: kworker/1:0 Not tainted 
3.16.0-rc1-0.1-default+ #7
[ 1810.292929] Hardware name: Huawei Technologies Co., Ltd. Tecal RH2285
  /BC11BTSA  , BIOS CTSAV036 04/27/2011
[ 1810.292943] Workqueue: events cpuset_hotplug_workfn
[ 1810.292951]  824b01e0 8800afdd3918 815a5f78 
8800afdd3958
[ 1810.292964]  810c263f 1d1fa490 8800afdd3978 
88061d1fa490
[ 1810.292976]   88061d1fad08 88061d1fad40 
8800afdd39f8
[ 1810.292989] Call 

Re: [PATCH v2 2/2] usb: chipidea: Add support for zynq usb host and device controller

[punnaiah choudary kalluri]

On Sat, Jun 28, 2014 at 11:16 AM, Peter Chen  wrote:
> On Fri, Jun 27, 2014 at 02:55:15PM +0200, Michael Grzeschik wrote:
>> Hi,
>>
>> On Fri, Jun 27, 2014 at 04:53:53PM +0530, Punnaiah Choudary Kalluri wrote:
>> > Zynq soc uses Chipidea/Synopsys usb IP core(CI13612). This patch adds
>> > necessary glue to allow the chipidea driver to work on zynq soc.
>> >
>>
>> Did you see the currently discussed patches for the generic chipidea
>> glue?
>>
>> http://www.spinics.net/lists/linux-usb/msg109576.html
>>
>> Try to improve that code instead writing another version
>> of this simple gluecode.
>>
>
> +1 if you think your version can be covered by generic one.

Ok. I will check this possibility.

Thanks,
Punnaiah
>
> --
>
> Best Regards,
> Peter Chen
--
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] clk: s2mps11: Fix double free corruption during driver unbind

[Yadwinder Singh Brar]

On Fri, Jun 27, 2014 at 5:51 PM, Krzysztof Kozlowski
 wrote:
> After unbinding the driver memory was corrupted by double free of
> clk_lookup structure. This lead to OOPS when re-binding the driver
> again.
>
> The driver allocated memory for 'clk_lookup' with devm_kzalloc. During
> driver removal this memory was freed twice: once by clkdev_drop() and
> second by devm code.
>
> Kernel panic log:
> [   30.839284] Unable to handle kernel paging request at virtual address 
> 5f343173
> [   30.846476] pgd = dee14000
> [   30.849165] [5f343173] *pgd=
> [   30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
> [   30.858166] Modules linked in:
> [   30.861208] CPU: 0 PID: 1 Comm: bash Not tainted 
> 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
> [   30.869364] task: df478000 ti: df48 task.ti: df48
> [   30.874752] PC is at clkdev_add+0x2c/0x38
> [   30.878738] LR is at clkdev_add+0x18/0x38
> [   30.882732] pc : []lr : []psr: 6013
> [   30.882732] sp : df481e78  ip : 0001  fp : c0700ed8
> [   30.894187] r10: 000c  r9 :   r8 : c07b0e3c
> [   30.899396] r7 : 0002  r6 : df45f9d0  r5 : df421390  r4 : c0700d6c
> [   30.905906] r3 : 5f343173  r2 : c0700d84  r1 : 6013  r0 : c0700d6c
> [   30.912417] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> user
> [   30.919534] Control: 10c53c7d  Table: 5ee1406a  DAC: 0015
> [   30.925262] Process bash (pid: 1, stack limit = 0xdf480240)
> [   30.930817] Stack: (0xdf481e78 to 0xdf482000)
> [   30.935159] 1e60:   
> 1000 df6de610
> [   30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510 
> dec9d69c 0014
> [   30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518  c0700e30 
> dec9d69c 0006
> [   30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420 
> c06fb150 c047cc20
> [   30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 000c 
> dec9d690 c02bef90
> [   30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 000c c02be73c 
> 000c c016ca8c
> [   30.984116] 1f20: c016ca48   c016c1f4   
> b6f18000 df481f80
> [   30.992276] 1f40: df7f66c0 000c df48 df48 b6f18000 c011094c 
> df47839c 6013
> [   31.000435] 1f60:   df7f66c0 df7f66c0 000c df48 
> b6f18000 c0110dd4
> [   31.008594] 1f80:   000c b6ec05d8 000c b6f18000 
> 0004 c000f2a8
> [   31.016753] 1fa0: 1000 c000f0e0 b6ec05d8 000c 0001 b6f18000 
> 000c 
> [   31.024912] 1fc0: b6ec05d8 000c b6f18000 0004 000c 0001 
>  00167b48
> [   31.033071] 1fe0:  bed83a80 b6e004f0 b6e5122c 6010 0001 
>  
> [   31.041248] [] (clkdev_add) from [] 
> (s2mps11_clk_probe+0x2b4/0x3b4)
> [   31.049223] [] (s2mps11_clk_probe) from [] 
> (platform_drv_probe+0x18/0x48)
> [   31.057728] [] (platform_drv_probe) from [] 
> (driver_probe_device+0x13c/0x384)
> [   31.066579] [] (driver_probe_device) from [] 
> (bind_store+0x88/0xd8)
> [   31.074564] [] (bind_store) from [] 
> (drv_attr_store+0x20/0x2c)
> [   31.082118] [] (drv_attr_store) from [] 
> (sysfs_kf_write+0x44/0x48)
> [   31.090016] [] (sysfs_kf_write) from [] 
> (kernfs_fop_write+0xc0/0x17c)
> [   31.098176] [] (kernfs_fop_write) from [] 
> (vfs_write+0xa0/0x1c4)
> [   31.105899] [] (vfs_write) from [] 
> (SyS_write+0x40/0x8c)
> [   31.112931] [] (SyS_write) from [] 
> (ret_fast_syscall+0x0/0x3c)
> [   31.120481] Code: e2842018 e584501c e1a4 e885000c (e5835000)
> [   31.126596] ---[ end trace efad45bfa3a61b05 ]---
> [   31.131181] Kernel panic - not syncing: Fatal exception
> [   31.136368] CPU1: stopping
> [   31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G  D   
> 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
> [   31.148697] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [   31.156419] [] (show_stack) from [] 
> (dump_stack+0x80/0xcc)
> [   31.163622] [] (dump_stack) from [] 
> (handle_IPI+0x130/0x15c)
> [   31.170998] [] (handle_IPI) from [] 
> (gic_handle_irq+0x60/0x68)
> [   31.178549] [] (gic_handle_irq) from [] 
> (__irq_svc+0x40/0x70)
> [   31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0)
> [   31.191046] df80:   ffed    
> df4bc000 c06d042c
> [   31.199207] dfa0:  ffed c06d03c0  c070c288  
>  df4bdfd0
> [   31.207363] dfc0: c0010324 c0010328 6013 
> [   31.212402] [] (__irq_svc) from [] 
> (arch_cpu_idle+0x28/0x30)
> [   31.219783] [] (arch_cpu_idle) from [] 
> (cpu_startup_entry+0x2c4/0x3f0)
> [   31.228027] [] (cpu_startup_entry) from [<400086c4>] (0x400086c4)
> [   31.234968] ---[ end Kernel panic - not syncing: Fatal exception
>
> Fixes: 7cc560dea415 ("clk: s2mps11: Add support for s2mps11")
> Cc: 
> Signed-off-by: Krzysztof Kozlowski 
>
> ---
>
> Changes since v1:
> 1. Allocate memory for 

Re: [PATCH v2 2/2] usb: chipidea: Add support for zynq usb host and device controller

[punnaiah choudary kalluri]

On Fri, Jun 27, 2014 at 6:25 PM, Michael Grzeschik  wrote:
> Hi,
>
> On Fri, Jun 27, 2014 at 04:53:53PM +0530, Punnaiah Choudary Kalluri wrote:
>> Zynq soc uses Chipidea/Synopsys usb IP core(CI13612). This patch adds
>> necessary glue to allow the chipidea driver to work on zynq soc.
>>
>
> Did you see the currently discussed patches for the generic chipidea
> glue?
>
> http://www.spinics.net/lists/linux-usb/msg109576.html

I have not seen this patch and thanks for pointing this

>
> Try to improve that code instead writing another version
> of this simple gluecode.

Sure.  i will check this patch and see if anything to be added for zynq
in a generic way.

Thanks,
Punnaiah

>
>
> Thanks,
> Michael
>
>
> --
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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 4/6] mmu_notifier: pass through vma to invalidate_range and invalidate_page

[John Hubbard]

On Fri, 27 Jun 2014, Jérôme Glisse wrote:

> From: Jérôme Glisse 
> 
> New user of the mmu_notifier interface need to lookup vma in order to
> perform the invalidation operation. Instead of redoing a vma lookup
> inside the callback just pass through the vma from the call site where
> it is already available.
> 
> This needs small refactoring in memory.c to call invalidate_range on
> vma boundary the overhead should be low enough.
> 
> Signed-off-by: Jérôme Glisse 
> ---
>  drivers/gpu/drm/i915/i915_gem_userptr.c |  1 +
>  drivers/iommu/amd_iommu_v2.c|  3 +++
>  drivers/misc/sgi-gru/grutlbpurge.c  |  6 -
>  drivers/xen/gntdev.c|  4 +++-
>  fs/proc/task_mmu.c  | 16 -
>  include/linux/mmu_notifier.h| 19 ---
>  kernel/events/uprobes.c |  4 ++--
>  mm/filemap_xip.c|  3 ++-
>  mm/huge_memory.c| 26 ++--
>  mm/hugetlb.c| 16 ++---
>  mm/ksm.c|  8 +++
>  mm/memory.c | 42 
> +
>  mm/migrate.c|  6 ++---
>  mm/mmu_notifier.c   |  9 ---
>  mm/mprotect.c   |  5 ++--
>  mm/mremap.c |  4 ++--
>  mm/rmap.c   |  9 +++
>  virt/kvm/kvm_main.c |  3 +++
>  18 files changed, 116 insertions(+), 68 deletions(-)
> 

Hi Jerome, considering that you have to change every call site already, it 
seems to me that it would be ideal to just delete the mm argument from all 
of these invalidate_range* callbacks. In other words, replace the mm 
argument with the new vma argument.  I don't see much point in passing 
them both around, and while it would make the patch a *bit* larger, it's 
mostly just an extra line or two per call site:

  mm = vma->vm_mm;

Also, passing the vma around really does seem like a good approach, but it 
does cause a bunch of additional calls to the invalidate_range* routines,
because we generate a call per vma, instead of just one for the entire mm.
So that brings up a couple questions:

1) Is there any chance that this could cause measurable performance 
regressions?

2) Should you put a little note in the commit message, mentioning this 
point?

> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index ed6f35e..191ac71 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -55,6 +55,7 @@ struct i915_mmu_object {
>  
>  static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier 
> *_mn,
>  struct mm_struct *mm,
> +struct vm_area_struct 
> *vma,
>  unsigned long start,
>  unsigned long end,
>  enum mmu_event event)

That routine has a local variable named vma, so it might be polite to 
rename the local variable, to make it more obvious to the reader that they 
are different. Of course, since the compiler knows which is which, feel 
free to ignore this comment.

> diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2.c
> index 2bb9771..9f9e706 100644
> --- a/drivers/iommu/amd_iommu_v2.c
> +++ b/drivers/iommu/amd_iommu_v2.c
> @@ -422,6 +422,7 @@ static void mn_change_pte(struct mmu_notifier *mn,
>  
>  static void mn_invalidate_page(struct mmu_notifier *mn,
>  struct mm_struct *mm,
> +struct vm_area_struct *vma,
>  unsigned long address,
>  enum mmu_event event)
>  {
> @@ -430,6 +431,7 @@ static void mn_invalidate_page(struct mmu_notifier *mn,
>  
>  static void mn_invalidate_range_start(struct mmu_notifier *mn,
> struct mm_struct *mm,
> +   struct vm_area_struct *vma,
> unsigned long start,
> unsigned long end,
> enum mmu_event event)
> @@ -453,6 +455,7 @@ static void mn_invalidate_range_start(struct mmu_notifier 
> *mn,
>  
>  static void mn_invalidate_range_end(struct mmu_notifier *mn,
>   struct mm_struct *mm,
> + struct vm_area_struct *vma,
>   unsigned long start,
>   unsigned long end,
>   enum mmu_event event)
> diff --git a/drivers/misc/sgi-gru/grutlbpurge.c 
> b/drivers/misc/sgi-gru/grutlbpurge.c
> index e67fed1..d02e4c7 

Re: [PATCH v2 1/2] usb: chipidea: zynq: Add device tree binding information

[punnaiah choudary kalluri]

On Fri, Jun 27, 2014 at 5:53 PM, Sergei Shtylyov
 wrote:
> Hello.
>
>
> On 06/27/2014 03:23 PM, Punnaiah Choudary Kalluri wrote:
>
>> Document device tree binding information as required by
>> the ZYNQ USB controller.
>
>
>> Signed-off-by: Punnaiah Choudary Kalluri 
>
> [...]
>
>
>> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt
>> b/Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt
>> new file mode 100644
>> index 000..54bb3b4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt
>> @@ -0,0 +1,23 @@
>> +Xilinx Zynq usb controller based on synopsys usb IP(v2.20a)
>
>
>s/usb/USB/.

OK

>
>
>> +
>> +Required properties:
>> +- compatible:   should contain "xlnx,zynq-usb-2.20a"
>> +- clocks:   clock provider specifier
>> +- reg:  offset and length of the register set in the memory map
>> +- interrupt-parent: the phandle for the interrupt controller that
>> services
>> +interrupts for this device.
>
>
>This property has never been required -- it can be inherited from the
> upper level node.

OK. i will correct it.

Thanks,
Punnaiah

>
> WBR, Sergei
>
>
--
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 1/1] staging: media: msi3101: sdr-msi3101.c - replace with time_before_eq()

[Anil Shashikumar Belur]

On Monday 30 June 2014 12:47 AM, Antti Palosaari wrote:
> Moikka!
> That is already fixed by someone else and patch is somewhere Mauro or
> Hans queue.
>
> regards
> Antti
>
Moikka :)

Ah no worries - I could not find the changes with the latest updates.

Thanks
--
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/1] script/kconfig: remove a warning for menucofig

[Li, Zhen-Hua]

There is a warning when run "make menuconfig".

scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:591:18: warning: ‘jump’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
 jump->offset = strlen(r->s);
  ^
scripts/kconfig/menu.c:551:19: note: ‘jump’ was declared here
  struct jump_key *jump;
   ^

It is because the compiler think "jump" is not initialized, though in fact
it is already initialized.

Signed-off-by: Li, Zhen-Hua 
---
 scripts/kconfig/menu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index a26cc5d..584e0fc 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -548,7 +548,7 @@ static void get_prompt_str(struct gstr *r, struct property 
*prop,
 {
int i, j;
struct menu *submenu[8], *menu, *location = NULL;
-   struct jump_key *jump;
+   struct jump_key *jump = NULL;
 
str_printf(r, _("Prompt: %s\n"), _(prop->text));
menu = prop->menu->parent;
-- 
2.0.0-rc0

--
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] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64

[Masami Hiramatsu]

Ping? :)

(2014/06/20 11:23), Masami Hiramatsu wrote:
> On ia64 and ppc64, the function pointer does not point the
> entry address of the function, but the address of function
> discriptor (which contains the entry address and misc
> data.) Since the kprobes passes the function pointer stored
> by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
> initalizing its blacklist, it fails and reports many errors
> as below.
> 
>   Failed to find blacklist 000101316830
>   Failed to find blacklist 0001013000f0a000
>   Failed to find blacklist 000101315f70a000
>   Failed to find blacklist 000101324c80a000
>   Failed to find blacklist 0001013063f0a000
>   Failed to find blacklist 000101327800a000
>   Failed to find blacklist 0001013277f0a000
>   Failed to find blacklist 000101315a70a000
>   Failed to find blacklist 0001013277e0a000
>   Failed to find blacklist 000101305a20a000
>   Failed to find blacklist 0001013277d0a000
>   Failed to find blacklist 00010130bdc0a000
>   Failed to find blacklist 00010130dc20a000
>   Failed to find blacklist 000101309a00a000
>   Failed to find blacklist 0001013277c0a000
>   Failed to find blacklist 0001013277b0a000
>   Failed to find blacklist 0001013277a0a000
>   Failed to find blacklist 000101327790a000
>   Failed to find blacklist 000101303140a000
>   Failed to find blacklist 0001013a3280a000
> 
> To fix this bug, this introduces function_entry() macro to
> retrieve the entry address from the given function pointer,
> and uses for kallsyms_lookup_size_offset() while initializing
> blacklist.
> 
> Changes in v4:
>  - Add kernel_text_address() check for verifying the address.
>  - Moved on the latest linus tree.
> 
> Changes in v3:
>  - Fix a bug to get blacklist address based on function entry
>instead of function descriptor. (Suzuki's work, Thanks!)
> 
> Changes in V2:
>  - Use function_entry() macro when lookin up symbols instead
>of storing it.
>  - Update for the latest -next.
> 
> Signed-off-by: Masami Hiramatsu 
> Reported-by: Tony Luck 
> Tested-by: Tony Luck 
> Cc: Michael Ellerman 
> Cc: Suzuki K. Poulose 
> Cc: Tony Luck 
> Cc: Fenghua Yu 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Ananth N Mavinakayanahalli 
> Cc: Kevin Hao 
> Cc: linux-i...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> ---
>  arch/ia64/include/asm/types.h|2 ++
>  arch/powerpc/include/asm/types.h |   11 +++
>  include/linux/types.h|4 
>  kernel/kprobes.c |   15 ++-
>  4 files changed, 27 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h
> index 4c351b1..95279dd 100644
> --- a/arch/ia64/include/asm/types.h
> +++ b/arch/ia64/include/asm/types.h
> @@ -27,5 +27,7 @@ struct fnptr {
>   unsigned long gp;
>  };
>  
> +#define function_entry(fn) (((struct fnptr *)(fn))->ip)
> +
>  #endif /* !__ASSEMBLY__ */
>  #endif /* _ASM_IA64_TYPES_H */
> diff --git a/arch/powerpc/include/asm/types.h 
> b/arch/powerpc/include/asm/types.h
> index bfb6ded..8b89d65 100644
> --- a/arch/powerpc/include/asm/types.h
> +++ b/arch/powerpc/include/asm/types.h
> @@ -25,6 +25,17 @@ typedef struct {
>   unsigned long env;
>  } func_descr_t;
>  
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> +/*
> + * On PPC64 ABIv1 the function pointer actually points to the
> + * function's descriptor. The first entry in the descriptor is the
> + * address of the function text.
> + */
> +#define function_entry(fn)   (((func_descr_t *)(fn))->entry)
> +#else
> +#define function_entry(fn)   ((unsigned long)(fn))
> +#endif
> +
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* _ASM_POWERPC_TYPES_H */
> diff --git a/include/linux/types.h b/include/linux/types.h
> index a0bb704..3b95369 100644
> --- a/include/linux/types.h
> +++ b/include/linux/types.h
> @@ -213,5 +213,9 @@ struct callback_head {
>  };
>  #define rcu_head callback_head
>  
> +#ifndef function_entry
> +#define function_entry(fn)   ((unsigned long)(fn))
> +#endif
> +
>  #endif /*  __ASSEMBLY__ */
>  #endif /* _LINUX_TYPES_H */
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 3214289..7412535 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -32,6 +32,7 @@
>   *added function-return probes.
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2037,19 +2038,23 @@ static int __init populate_kprobe_blacklist(unsigned 
> long *start,
>  {
>   unsigned long *iter;
>   struct kprobe_blacklist_entry *ent;
> - unsigned long offset = 0, size = 0;
> + unsigned long entry, offset = 0, size = 0;
>  
>   for (iter = start; iter < end; iter++) {
> - if (!kallsyms_lookup_size_offset(*iter, , )) {
> - pr_err("Failed to find blacklist %p\n", (void *)*iter);
> + entry = function_entry(*iter);
> +
> + if (!kernel_text_address(entry) ||
> +

Re: [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Chen, Tiejun]

On 2014/6/25 15:55, Paolo Bonzini wrote:

Il 25/06/2014 09:34, Chen, Tiejun ha scritto:

On 2014/6/25 14:48, Paolo Bonzini wrote:

Second problem.  Your IGD passthrough code currently works with QEMU's
PIIX4-based machine.  But what happens if you try to extend it, so that


Yes, current xen machine, xenpv, is based on pii4, and also I don't
known if we will plan to migrate to q35 or others. So its hard to
further say more now.


it works with QEMU's ICH9-based machine?  That's a more modern machine
that has a PCIe chipset and hence has its ISA bridge at 00:1f.0.  Now


But even in this case, could we set the real vendor/device ids for that
ISA bridge at 00:1f.0? If not, what's broken?


The config space layout changes for different vendor/device ids, so the
guest firmware only works if you have the right vendor/device id.


Paolo,

After I discuss internal, we think even we just set the real 
vendor/device ids to this ISA bridge at 00:1f.0, guest firmware should 
still work well with these pair of real vendor/device ids.


So if you think something would conflict or be broken, could you tell us 
what's exactly that? Then we will double check.


Thanks
Tiejun




It is only slightly better, but the right solution is to fix the driver.
  There is absolutely zero reason why a graphics driver should know
about the vendor/device ids of the PCH.


This means we have to fix this both on Linux and Windows but I'm not
sure if this is feasible to us.


You have to do it if you want this feature in QEMU in a future-proof way.

You _can_ provide the ugly PIIX4-specific hack as a compatibility
fallback (and this patch is okay to make the compatibility fallback less
hacky).  However, I don't think QEMU should accept the patch for IGD
passthrough unless Intel is willing to make drivers
virtualization-friendly.  Once you assign the IGD, it is not that
integrated anymore and the drivers must take that into account.

It is worthwhile pointing out that neither AMD nor nVidia need any of this.


The right way could be to make QEMU add a vendor-specific capability to
the video device. The driver can probe for that capability before


Do you mean we can pick two unused offsets in the configuration space of
the video device as a vendor-specific capability to hold the
vendor/device ids of the PCH?


Yes, either that or add a new capability (which lets you choose the
offsets more freely).

If the IGD driver needs config space fields of the MCH, those fields
could also be mirrored in the new capability.  QEMU would forward them
automatically.

It could even be a new BAR, which gives even more freedom to allocate
the fields.


looking at the PCI bus.  QEMU can add the capability to the list, it is
easy because all accesses to the video device's configuration space trap
to QEMU.  Then you do not need to add fake devices to the machine.

In fact, it would be nice if Intel added such a capability on the next
generation of integrated graphics, too.  On real hardware, ACPI or some


Maybe, but even this would be implemented, shouldn't we need to be
compatible with those old generations?


Yes.

- old generation / old driver: use 00:1f.0 hack, only guaranteed to work
on PIIX4-based virtual guest

- old generation / new driver: use 00:1f.0 hack on real hardware, use
capability on 00:02.0 on virtual guest, can work on PCIe virtual guest

- new generation / old driver: doesn't exist

- new generation / new driver: always use capability on 00:02.0, can
work on PCIe virtual guest.

Paolo



--
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: [RFA][PATCH 00/27] ftrace: Remove ftrace_start/stop() and friends

[Masami Hiramatsu]

(2014/06/27 1:52), Steven Rostedt wrote:
> * Request for Acks *
> 
>>From the time I created the use of function_trace_stop, I hated it.
> There was two reasons to create this, one was to try to lower the
> function tracing overhead when debugfs file tracing_enable was set to zero
> (note, tracing_enable no longer exists), the other was a way to stop
> function tracing when going down into suspend and resume.
> 
> Some function was causing suspend and resume to reboot the kernel. In
> debugging this I found that an empty callback from mcount would work.
> That is, instead of running the tracing code, I would just have the
> function trace callback be a nop:
> 
>  void function_trace_call(unsigned long ip, unsigned long parent_ip)
>  {
>  }
> 
> This worked. That means the code in mcount wasn't an issue. I started
> bisecting the contents of the function_trace_call and found that this
> would cause the system to reboot!
> 
>  void function_trace_call(unsigned long ip, unsigned long parent_ip)
>  {
>   smp_processor_id();
>  }
> 
> That is, just calling smp_processor_id() was enough to trigger a triple
> fault on resume of the system.
> 
> Today, this big hammer approach of disabling the function tracer is starting
> to show its issues. It can't help out in debugging suspend and resume,
> and there's other function trace callbacks that should still work.
> 
> I also have learned ways to bisect functions that cause bugs in function
> tracing. I finally got some time to do so with a box that would reboot
> on suspend and resume. This led me down to a single function:
> 
>  restore_processor_state()
> 
> This made perfect sense, as this function is called from assembly on a
> CPU startup. One of the jobs of this function was to set up the GS register.
> That register is also the register that is used by smp_processor_id()
> to find what CPU the task is running on. With it not set up it will offset
> into some random location and fault. As the fault handlers can also be
> traced, those will fault too and finally the system will reset due to a
> triple fault.

Uh, from the same reason, I must list it in the kprobe blacklist too...

BTW, as far as I can review, x86 and generic parts of the series seems
OK to me. :)

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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] Fixes q40_irq_startup to return -ENXIO

[Nicholas Krause]

Fixes q40_irq_startup to return -ENXIO for cases 11-13 in the switch
statement of this function to handle these failure cases.

Signed-off-by: Nicholas Krause 
---
 arch/m68k/q40/q40ints.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index 513f9bb..9dfa1ea 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -49,7 +49,7 @@ static unsigned int q40_irq_startup(struct irq_data *data)
case 1: case 2: case 8: case 9:
case 11: case 12: case 13:
printk("%s: ISA IRQ %d not implemented by HW\n", __func__, irq);
-   /* FIXME return -ENXIO; */
+   return -ENXIO;
}
return 0;
 }
-- 
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 v4 4/4] iio: hid-sensor-magn-3d: Add support for rotation from north

[Reyad Attiyat]

Add the HID usage attribute ID's and IIO channel info for rotation
from north support.

Signed-off-by: Reyad Attiyat 
---
 drivers/iio/magnetometer/hid-sensor-magn-3d.c | 58 ++-
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c 
b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 070d20e..69f8ac9 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -35,6 +35,10 @@ enum magn_3d_channel {
CHANNEL_SCAN_INDEX_X,
CHANNEL_SCAN_INDEX_Y,
CHANNEL_SCAN_INDEX_Z,
+   CHANNEL_SCAN_INDEX_NORTH_MAGN_TILT_COMP,
+   CHANNEL_SCAN_INDEX_NORTH_TRUE_TILT_COMP,
+   CHANNEL_SCAN_INDEX_NORTH_MAGN,
+   CHANNEL_SCAN_INDEX_NORTH_TRUE,
MAGN_3D_CHANNEL_MAX,
 };
 
@@ -53,7 +57,11 @@ struct magn_3d_state {
 static const u32 magn_3d_addresses[MAGN_3D_CHANNEL_MAX] = {
HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS,
HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS,
-   HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS
+   HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS,
+   HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH,
+   HID_USAGE_SENSOR_ORIENT_COMP_TRUE_NORTH,
+   HID_USAGE_SENSOR_ORIENT_MAGN_NORTH,
+   HID_USAGE_SENSOR_ORIENT_TRUE_NORTH,
 };
 
 /* Channel definitions */
@@ -88,6 +96,46 @@ static const struct iio_chan_spec magn_3d_channels[] = {
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
.scan_index = CHANNEL_SCAN_INDEX_Z,
+   }, {
+   .type = IIO_ROT,
+   .modified = 1,
+   .channel2 = IIO_MOD_NORTH_MAGN_TILT_COMP,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+   BIT(IIO_CHAN_INFO_SCALE) |
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS),
+   .scan_index = CHANNEL_SCAN_INDEX_NORTH_MAGN_TILT_COMP,
+   }, {
+   .type = IIO_ROT,
+   .modified = 1,
+   .channel2 = IIO_MOD_NORTH_TRUE_TILT_COMP,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+   BIT(IIO_CHAN_INFO_SCALE) |
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS),
+   .scan_index = CHANNEL_SCAN_INDEX_NORTH_TRUE_TILT_COMP,
+   }, {
+   .type = IIO_ROT,
+   .modified = 1,
+   .channel2 = IIO_MOD_NORTH_MAGN,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+   BIT(IIO_CHAN_INFO_SCALE) |
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS),
+   .scan_index = CHANNEL_SCAN_INDEX_NORTH_TRUE,
+   }, {
+   .type = IIO_ROT,
+   .modified = 1,
+   .channel2 = IIO_MOD_NORTH_TRUE,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+   BIT(IIO_CHAN_INFO_SCALE) |
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS),
+   .scan_index = CHANNEL_SCAN_INDEX_NORTH_TRUE,
}
 };
 
@@ -248,6 +296,14 @@ static int magn_3d_capture_sample(struct 
hid_sensor_hub_device *hsdev,
iio_val = magn_state->magn_val_addr[CHANNEL_SCAN_INDEX_X + 
offset];
 
break;
+   case HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH:
+   case HID_USAGE_SENSOR_ORIENT_COMP_TRUE_NORTH:
+   case HID_USAGE_SENSOR_ORIENT_MAGN_NORTH:
+   case HID_USAGE_SENSOR_ORIENT_TRUE_NORTH:
+   offset = usage_id - HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH;
+   iio_val = 
magn_state->magn_val_addr[CHANNEL_SCAN_INDEX_NORTH_MAGN_TILT_COMP + offset];
+
+   break;
default:
return -EINVAL;
}
-- 
1.9.3

--
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 v4 3/4] iio: hid-sensor-magn-3d: Scan for usage attributes before setting up iio channels

[Reyad Attiyat]

Scan for and count the HID usage attributes supported by the driver.
This allows for the driver to only setup the IIO channels for the
sensor usages present in the HID USB reports.

Signed-off-by: Reyad Attiyat 
---
 drivers/iio/magnetometer/hid-sensor-magn-3d.c | 111 +-
 1 file changed, 75 insertions(+), 36 deletions(-)

diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c 
b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 41cf29e..070d20e 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -42,7 +42,8 @@ struct magn_3d_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX];
-   u32 magn_val[MAGN_3D_CHANNEL_MAX];
+   u32 *magn_val_addr[MAGN_3D_CHANNEL_MAX];
+   u32 *iio_val;
int scale_pre_decml;
int scale_post_decml;
int scale_precision;
@@ -221,8 +222,8 @@ static int magn_3d_proc_event(struct hid_sensor_hub_device 
*hsdev,
dev_dbg(_dev->dev, "magn_3d_proc_event\n");
if (atomic_read(_state->common_attributes.data_ready))
hid_sensor_push_data(indio_dev,
-   magn_state->magn_val,
-   sizeof(magn_state->magn_val));
+   magn_state->iio_val,
+   sizeof(magn_state->iio_val));
 
return 0;
 }
@@ -236,52 +237,99 @@ static int magn_3d_capture_sample(struct 
hid_sensor_hub_device *hsdev,
struct iio_dev *indio_dev = platform_get_drvdata(priv);
struct magn_3d_state *magn_state = iio_priv(indio_dev);
int offset;
-   int ret = -EINVAL;
+   int ret = 0;
+   u32 *iio_val = NULL;
 
switch (usage_id) {
case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS:
case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS:
case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS:
offset = usage_id - HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS;
-   magn_state->magn_val[CHANNEL_SCAN_INDEX_X + offset] =
-   *(u32 *)raw_data;
-   ret = 0;
+   iio_val = magn_state->magn_val_addr[CHANNEL_SCAN_INDEX_X + 
offset];
+
break;
default:
-   break;
+   return -EINVAL;
}
 
+   if(iio_val)
+   *iio_val = *(u32 *)raw_data;
+   else
+   ret = -EINVAL;
+
return ret;
 }
 
 /* Parse report which is specific to an usage id*/
 static int magn_3d_parse_report(struct platform_device *pdev,
struct hid_sensor_hub_device *hsdev,
-   struct iio_chan_spec *channels,
+   struct iio_chan_spec **channels,
+   int *chan_count,
unsigned usage_id,
struct magn_3d_state *st)
 {
-   int ret;
+   int ret = 0;
int i;
+   int attr_count = 0;
+
+   /* Scan for each usage attribute supported */
+   for (i = 0; i < MAGN_3D_CHANNEL_MAX; i++) {
+   u32 address = magn_3d_addresses[i];
 
-   for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
+   /* Check if usage attribute exists in the sensor hub device */
ret = sensor_hub_input_get_attribute_info(hsdev,
-   HID_INPUT_REPORT,
-   usage_id,
-   HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS + i,
-   >magn[CHANNEL_SCAN_INDEX_X + i]);
-   if (ret < 0)
-   break;
-   magn_3d_adjust_channel_bit_mask(channels,
-   CHANNEL_SCAN_INDEX_X + i,
-   st->magn[CHANNEL_SCAN_INDEX_X + i].size);
+   HID_INPUT_REPORT,
+   usage_id,
+   address,
+   &(st->magn[i]));
+   if (!ret)
+   attr_count++;
}
-   dev_dbg(>dev, "magn_3d %x:%x, %x:%x, %x:%x\n",
+
+   dev_dbg(>dev, "magn_3d Found %d usage attributes\n",
+   attr_count);
+   dev_dbg(>dev, "magn_3d X: %x:%x Y: %x:%x Z: %x:%x\n",
st->magn[0].index,
st->magn[0].report_id,
st->magn[1].index, st->magn[1].report_id,
st->magn[2].index, st->magn[2].report_id);
 
+   if (attr_count > 0)
+   ret = 0;
+   else
+   return  -EINVAL;
+
+   /* Setup IIO channel array */
+   *channels = devm_kcalloc(>dev, attr_count,
+   sizeof(struct 
iio_chan_spec),
+ 

[PATCH v4 2/4] iio: types: Added support for rotation from north usage attributes

[Reyad Attiyat]

Added the rotation from north usage attributes to the iio modifier enum and to 
the iio modifier names array.

Signed-off-by: Reyad Attiyat 
---
 drivers/iio/industrialio-core.c | 4 
 include/linux/iio/types.h   | 4 
 2 files changed, 8 insertions(+)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 4b1f375..af3e76d 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -87,6 +87,10 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_QUATERNION] = "quaternion",
[IIO_MOD_TEMP_AMBIENT] = "ambient",
[IIO_MOD_TEMP_OBJECT] = "object",
+   [IIO_MOD_NORTH_MAGN] = "from_north_magnetic",
+   [IIO_MOD_NORTH_TRUE] = "from_north_true",
+   [IIO_MOD_NORTH_MAGN_TILT_COMP] = "from_north_magnetic_tilt_comp",
+   [IIO_MOD_NORTH_TRUE_TILT_COMP] = "from_north_true_tilt_comp",
 };
 
 /* relies on pairs of these shared then separate */
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index d480631..d09c40d 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -56,6 +56,10 @@ enum iio_modifier {
IIO_MOD_QUATERNION,
IIO_MOD_TEMP_AMBIENT,
IIO_MOD_TEMP_OBJECT,
+   IIO_MOD_NORTH_MAGN,
+   IIO_MOD_NORTH_TRUE,
+   IIO_MOD_NORTH_MAGN_TILT_COMP,
+   IIO_MOD_NORTH_TRUE_TILT_COMP
 };
 
 enum iio_event_type {
-- 
1.9.3

--
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 v4 1/4] iio: Documentation: Add documentation for rotation from north sensor usage attributes

[Reyad Attiyat]

Added documentation for the sysfs attributes supported by the rotation from 
north
sensor.

Signed-off-by: Reyad Attiyat 
---
 Documentation/ABI/testing/sysfs-bus-iio | 82 +
 1 file changed, 82 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index a9757dc..e88833d 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -260,6 +260,10 @@ What:  
/sys/bus/iio/devices/iio:deviceX/in_magn_scale
 What:  /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
 What:  /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
 What:  /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale
+What:  
/sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_scale
+What:  /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_scale
+What:  
/sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_scale
+What:  
/sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale
 What:  /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
 What:  /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
 KernelVersion: 2.6.35
@@ -447,6 +451,14 @@ What:  
/sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en
 What:  /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_falling_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
@@ -492,6 +504,14 @@ What:  
/sys/.../iio:deviceX/events/in_magn_y_roc_rising_en
 What:  /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en
 What:  /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en
 What:  /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_falling_en
+What:  /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_roc_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_falling_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en
@@ -538,6 +558,14 @@ What:  
/sys/.../events/in_magn_y_raw_thresh_rising_value
 What:  /sys/.../events/in_magn_y_raw_thresh_falling_value
 What:  /sys/.../events/in_magn_z_raw_thresh_rising_value
 What:  /sys/.../events/in_magn_z_raw_thresh_falling_value
+What:  
/sys/.../events/in_rot_from_north_magnetic_raw_thresh_rising_value
+What:  
/sys/.../events/in_rot_from_north_magnetic_raw_thresh_falling_value
+What:  /sys/.../events/in_rot_from_north_true_raw_thresh_rising_value
+What:  /sys/.../events/in_rot_from_north_true_raw_thresh_falling_value
+What:  
/sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_rising_value
+What:  
/sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_falling_value
+What:  
/sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_rising_value
+What:  
/sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_falling_value
 What:  /sys/.../events/in_voltageY_supply_raw_thresh_rising_value
 What:  /sys/.../events/in_voltageY_supply_raw_thresh_falling_value
 What:  /sys/.../events/in_voltageY_raw_thresh_rising_value
@@ -588,6 +616,18 @@ 

[PATCH v4 0/4] Add support for rotation from north to the hid-sensor-magn-3d driver

[Reyad Attiyat]

This version of patches tries to make smaller changes to the magn-3d driver. It
scans for usages present in the magn_3d_addresses array. It then allocates
memory for the IIO channel structs and value arrays that are used in the IIO 
subsystem.
It sets-up each IIO channel struct by copying the values from the static array 
of
IIO configurations. There is also an array used to store each channel IIO value
pointer for each HID usage attribute.



Reyad Attiyat (4):
  iio: Documentation: Add documentation for rotation from north sensor
usage attributes
  iio: types: Added support for rotation from north usage attributes
  iio: hid-sensor-magn-3d: Scan for usage attributes before setting up
iio channels
  iio: hid-sensor-magn-3d: Add support for rotation from north

 Documentation/ABI/testing/sysfs-bus-iio   |  82 +
 drivers/iio/industrialio-core.c   |   4 +
 drivers/iio/magnetometer/hid-sensor-magn-3d.c | 167 --
 include/linux/iio/types.h |   4 +
 4 files changed, 220 insertions(+), 37 deletions(-)

-- 
1.9.3

--
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 3/3] x86/pmc_atom: expose PMC device state and platform sleep state

[Li, Aubrey]

Add the following interfaces to exposes PMC device state and sleep
state residency via debugfs:
/sys/kernel/debugfs/pmc_atom/dev_state
/sys/kernel/debugfs/pmc_atom/sleep_state

Signed-off-by: Aubrey Li 
Signed-off-by: Kasagar, Srinidhi 
Reviewed-by: Rudramuni, Vishwesh M 
Reviewed-by: Joe Perches 
---
 arch/x86/include/asm/pmc_atom.h |   55 
 arch/x86/kernel/pmc_atom.c  |  175 +++
 2 files changed, 230 insertions(+)

diff --git a/arch/x86/include/asm/pmc_atom.h b/arch/x86/include/asm/pmc_atom.h
index 8e47e5d..fc7a17c 100644
--- a/arch/x86/include/asm/pmc_atom.h
+++ b/arch/x86/include/asm/pmc_atom.h
@@ -25,6 +25,10 @@
 #definePMC_MMIO_REG_LEN0x100
 #definePMC_REG_BIT_WIDTH   32
 +/* BIOS uses FUNC_DIS to disable specific function */
+#definePMC_FUNC_DIS0x34
+#definePMC_FUNC_DIS_2  0x38
+
 /* S0ix wake event control */
 #definePMC_S0IX_WAKE_EN0x3C
 @@ -40,6 +44,57 @@
BIT_ORED_DEDICATED_IRQ_GPSC | \
BIT_SHARED_IRQ_GPSS)
 +/* The timers acumulate time spent in sleep state */
+#definePMC_S0IR_TMR0x80
+#definePMC_S0I1_TMR0x84
+#definePMC_S0I2_TMR0x88
+#definePMC_S0I3_TMR0x8C
+#definePMC_S0_TMR  0x90
+/* Sleep state counter is in units of of 32us */
+#definePMC_TMR_SHIFT   5
+
+/* These registers reflect D3 status of functions */
+#definePMC_D3_STS_00xA0
+
+#defineBIT_LPSS1_F0_DMABIT(0)
+#defineBIT_LPSS1_F1_PWM1   BIT(1)
+#defineBIT_LPSS1_F2_PWM2   BIT(2)
+#defineBIT_LPSS1_F3_HSUART1BIT(3)
+#defineBIT_LPSS1_F4_HSUART2BIT(4)
+#defineBIT_LPSS1_F5_SPIBIT(5)
+#defineBIT_LPSS1_F6_XXXBIT(6)
+#defineBIT_LPSS1_F7_XXXBIT(7)
+#defineBIT_SCC_EMMCBIT(8)
+#defineBIT_SCC_SDIOBIT(9)
+#defineBIT_SCC_SDCARD  BIT(10)
+#defineBIT_SCC_MIPIBIT(11)
+#defineBIT_HDA BIT(12)
+#defineBIT_LPE BIT(13)
+#defineBIT_OTG BIT(14)
+#defineBIT_USH BIT(15)
+#defineBIT_GBE BIT(16)
+#defineBIT_SATABIT(17)
+#defineBIT_USB_EHCIBIT(18)
+#defineBIT_SEC BIT(19)
+#defineBIT_PCIE_PORT0  BIT(20)
+#defineBIT_PCIE_PORT1  BIT(21)
+#defineBIT_PCIE_PORT2  BIT(22)
+#defineBIT_PCIE_PORT3  BIT(23)
+#defineBIT_LPSS2_F0_DMABIT(24)
+#defineBIT_LPSS2_F1_I2C1   BIT(25)
+#defineBIT_LPSS2_F2_I2C2   BIT(26)
+#defineBIT_LPSS2_F3_I2C3   BIT(27)
+#defineBIT_LPSS2_F4_I2C4   BIT(28)
+#defineBIT_LPSS2_F5_I2C5   BIT(29)
+#defineBIT_LPSS2_F6_I2C6   BIT(30)
+#defineBIT_LPSS2_F7_I2C7   BIT(31)
+
+#definePMC_D3_STS_10xA4
+#defineBIT_SMB BIT(0)
+#defineBIT_OTG_SS_PHY  BIT(1)
+#defineBIT_USH_SS_PHY  BIT(2)
+#defineBIT_DFX BIT(3)
+
 /* PMC I/O Registers */
 #defineACPI_BASE_ADDR_OFFSET   0x40
 #defineACPI_BASE_ADDR_MASK 0xFE00
diff --git a/arch/x86/kernel/pmc_atom.c b/arch/x86/kernel/pmc_atom.c
index d6cc0e9..0d92ef6 100644
--- a/arch/x86/kernel/pmc_atom.c
+++ b/arch/x86/kernel/pmc_atom.c
@@ -19,18 +19,69 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
  #include 
 +#define   DRIVER_NAME KBUILD_MODNAME
+
 struct pmc_dev {
u32 base_addr;
void __iomem *regmap;
+#ifdef CONFIG_DEBUG_FS
+   struct dentry *dbgfs_dir;
+#endif /* CONFIG_DEBUG_FS */
 };
  static struct pmc_dev pmc_device;
 static u32 acpi_base_addr;
 +struct pmc_dev_map {
+   const char *name;
+   u32 bit_mask;
+};
+
+static const struct pmc_dev_map dev_map[] = {
+   {"0  - LPSS1_F0_DMA",   BIT_LPSS1_F0_DMA},
+   {"1  - LPSS1_F1_PWM1",  BIT_LPSS1_F1_PWM1},
+   {"2  - LPSS1_F2_PWM2",  BIT_LPSS1_F2_PWM2},
+   {"3  - LPSS1_F3_HSUART1",   BIT_LPSS1_F3_HSUART1},
+   {"4  - LPSS1_F4_HSUART2",   BIT_LPSS1_F4_HSUART2},
+   {"5  - LPSS1_F5_SPI",   BIT_LPSS1_F5_SPI},
+   {"6  - LPSS1_F6_Reserved",  BIT_LPSS1_F6_XXX},
+   {"7  - LPSS1_F7_Reserved",  BIT_LPSS1_F7_XXX},
+   {"8  - SCC_EMMC",   BIT_SCC_EMMC},
+   {"9  - SCC_SDIO",   BIT_SCC_SDIO},
+   {"10 - SCC_SDCARD", BIT_SCC_SDCARD},
+   {"11 - SCC_MIPI",   BIT_SCC_MIPI},
+   {"12 - HDA",BIT_HDA},
+   {"13 - LPE",BIT_LPE},
+   {"14 - OTG",  

[PATCH 1/2] zram: use size_t instead of u16

[Minchan Kim]

Some of arch(ex, hexagon and PowerPC) could use PAGE_SHIFT
as 16 above. In the case, u16 is is lack of representing
compressed page's size so use size_t.

Reported-by: Weijie Yang 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 089e72cd37be..3233bccd6361 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -337,7 +337,7 @@ static int zram_decompress_page(struct zram *zram, char 
*mem, u32 index)
unsigned char *cmem;
struct zram_meta *meta = zram->meta;
unsigned long handle;
-   u16 size;
+   size_t size;
 
read_lock(>tb_lock);
handle = meta->table[index].handle;
-- 
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/

[PATCHv3 2/3] x86/pmc_atom: disable a few S0ix wake up events for S0ix, residency

[Li, Aubrey]

Disable PMC S0IX_WAKE_EN events coming from LPC block(unused) and
also from GPIO_SUS ored dedicated IRQs (must be disabled as per PMC
programming rule), GPIOSCORE ored dedicated IRQs (must be disabled
as per PMC programming rule), GPIO_SUS shared IRQ (not necessary
since the IOAPIC_DS wake event will still work), GPIO_SCORE shared
IRQ (not necessary since the IOAPIC_DS wake event will still work).

Signed-off-by: Aubrey Li 
Signed-off-by: Olivier Leveque 
---
 arch/x86/include/asm/pmc_atom.h |   21 
 arch/x86/kernel/pmc_atom.c  |   42 +++
 2 files changed, 63 insertions(+)

diff --git a/arch/x86/include/asm/pmc_atom.h b/arch/x86/include/asm/pmc_atom.h
index 03a2769..8e47e5d 100644
--- a/arch/x86/include/asm/pmc_atom.h
+++ b/arch/x86/include/asm/pmc_atom.h
@@ -19,6 +19,27 @@
 /* ValleyView Power Control Unit PCI Device ID */
 #definePCI_DEVICE_ID_VLV_PMC   0x0F1C
 +/* PMC Memory mapped IO registers */
+#definePMC_BASE_ADDR_OFFSET0x44
+#definePMC_BASE_ADDR_MASK  0xFE00
+#definePMC_MMIO_REG_LEN0x100
+#definePMC_REG_BIT_WIDTH   32
+
+/* S0ix wake event control */
+#definePMC_S0IX_WAKE_EN0x3C
+
+#defineBIT_LPC_CLOCK_RUN   BIT(4)
+#defineBIT_SHARED_IRQ_GPSC BIT(5)
+#defineBIT_ORED_DEDICATED_IRQ_GPSS BIT(18)
+#defineBIT_ORED_DEDICATED_IRQ_GPSC BIT(19)
+#defineBIT_SHARED_IRQ_GPSS BIT(20)
+
+#definePMC_WAKE_EN_SETTING ~(BIT_LPC_CLOCK_RUN | \
+   BIT_SHARED_IRQ_GPSC | \
+   BIT_ORED_DEDICATED_IRQ_GPSS | \
+   BIT_ORED_DEDICATED_IRQ_GPSC | \
+   BIT_SHARED_IRQ_GPSS)
+
 /* PMC I/O Registers */
 #defineACPI_BASE_ADDR_OFFSET   0x40
 #defineACPI_BASE_ADDR_MASK 0xFE00
diff --git a/arch/x86/kernel/pmc_atom.c b/arch/x86/kernel/pmc_atom.c
index 9eb79f6..d6cc0e9 100644
--- a/arch/x86/kernel/pmc_atom.c
+++ b/arch/x86/kernel/pmc_atom.c
@@ -23,8 +23,24 @@
  #include 
 +struct pmc_dev {
+   u32 base_addr;
+   void __iomem *regmap;
+};
+
+static struct pmc_dev pmc_device;
 static u32 acpi_base_addr;
 +static inline u32 pmc_reg_read(struct pmc_dev *pmc, int reg_offset)
+{
+   return readl(pmc->regmap + reg_offset);
+}
+
+static inline void pmc_reg_write(struct pmc_dev *pmc, int reg_offset, u32 val)
+{
+   writel(val, pmc->regmap + reg_offset);
+}
+
 static void pmc_power_off(void)
 {
u16 pm1_cnt_port;
@@ -42,8 +58,23 @@ static void pmc_power_off(void)
outl(pm1_cnt_value, pm1_cnt_port);
 }
 +static void pmc_hw_reg_setup(struct pmc_dev *pmc)
+{
+   /*
+* Disable PMC S0IX_WAKE_EN events coming from:
+* - LPC clock run
+* - GPIO_SUS ored dedicated IRQs
+* - GPIO_SCORE ored dedicated IRQs
+* - GPIO_SUS shared IRQ
+* - GPIO_SCORE shared IRQ
+*/
+   pmc_reg_write(pmc, PMC_S0IX_WAKE_EN, (u32)PMC_WAKE_EN_SETTING);
+}
+
 static int pmc_setup_dev(struct pci_dev *pdev)
 {
+   struct pmc_dev *pmc = _device;
+
/* Obtain ACPI base address */
pci_read_config_dword(pdev, ACPI_BASE_ADDR_OFFSET, _base_addr);
acpi_base_addr &= ACPI_BASE_ADDR_MASK;
@@ -52,6 +83,17 @@ static int pmc_setup_dev(struct pci_dev *pdev)
if (acpi_base_addr != 0 && pm_power_off == NULL)
pm_power_off = pmc_power_off;
 +  pci_read_config_dword(pdev, PMC_BASE_ADDR_OFFSET, >base_addr);
+   pmc->base_addr &= PMC_BASE_ADDR_MASK;
+
+   pmc->regmap = ioremap_nocache(pmc->base_addr, PMC_MMIO_REG_LEN);
+   if (!pmc->regmap) {
+   dev_err(>dev, "error: ioremap failed\n");
+   return -ENOMEM;
+   }
+
+   /* PMC hardware registers setup */
+   pmc_hw_reg_setup(pmc);
return 0;
 }
 -- 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/

[PATCHv3 1/3] X86 platform: New Intel Atom SOC power management, controller driver

[Li, Aubrey]

The Power Management Controller (PMC) controls many of the power
management features present in the Atom SoC. This driver provides
a native power off function via PMC PCI IO port.

On some ACPI hardware-reduced platforms(e.g. ASUS-T100), ACPI sleep
registers are not valid so that (*pm_power_off)() is not hooked by
acpi_power_off(). The power off function in this driver is installed
only when pm_power_off is NULL.

Signed-off-by: Aubrey Li 
Signed-off-by: Lejun Zhu 
---
 arch/x86/Kconfig|4 ++
 arch/x86/include/asm/pmc_atom.h |   31 
 arch/x86/kernel/Makefile|1 +
 arch/x86/kernel/pmc_atom.c  |  104 +++
 4 files changed, 140 insertions(+)
 create mode 100644 arch/x86/include/asm/pmc_atom.h
 create mode 100644 arch/x86/kernel/pmc_atom.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a8f749e..6295a21 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2403,6 +2403,10 @@ config IOSF_MBI
default m
depends on PCI
 +config PMC_ATOM
+   def_bool y
+depends on PCI
+
 source "net/Kconfig"
  source "drivers/Kconfig"
diff --git a/arch/x86/include/asm/pmc_atom.h b/arch/x86/include/asm/pmc_atom.h
new file mode 100644
index 000..03a2769
--- /dev/null
+++ b/arch/x86/include/asm/pmc_atom.h
@@ -0,0 +1,31 @@
+/*
+ * Intel Atom SOC Power Management Controller Header File
+ * Copyright (c) 2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#ifndef PMC_ATOM_H
+#define PMC_ATOM_H
+
+/* ValleyView Power Control Unit PCI Device ID */
+#definePCI_DEVICE_ID_VLV_PMC   0x0F1C
+
+/* PMC I/O Registers */
+#defineACPI_BASE_ADDR_OFFSET   0x40
+#defineACPI_BASE_ADDR_MASK 0xFE00
+#defineACPI_MMIO_REG_LEN   0x100
+
+#definePM1_CNT 0x4
+#defineSLEEP_TYPE_MASK 0xECFF
+#defineSLEEP_TYPE_S5   0x1C00
+#defineSLEEP_ENABLE0x2000
+#endif /* PMC_ATOM_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 047f9ff..bde3993 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_EFI)   += sysfb_efi.o
 obj-$(CONFIG_PERF_EVENTS)  += perf_regs.o
 obj-$(CONFIG_TRACING)  += tracepoint.o
 obj-$(CONFIG_IOSF_MBI) += iosf_mbi.o
+obj-$(CONFIG_PMC_ATOM) += pmc_atom.o
  ###
 # 64 bit specific files
diff --git a/arch/x86/kernel/pmc_atom.c b/arch/x86/kernel/pmc_atom.c
new file mode 100644
index 000..9eb79f6
--- /dev/null
+++ b/arch/x86/kernel/pmc_atom.c
@@ -0,0 +1,104 @@
+/*
+ * Intel Atom SOC Power Management Controller Driver
+ * Copyright (c) 2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static u32 acpi_base_addr;
+
+static void pmc_power_off(void)
+{
+   u16 pm1_cnt_port;
+   u32 pm1_cnt_value;
+
+   pr_info("Preparing to enter system sleep state S5\n");
+
+   pm1_cnt_port = acpi_base_addr + PM1_CNT;
+
+   pm1_cnt_value = inl(pm1_cnt_port);
+   pm1_cnt_value &= SLEEP_TYPE_MASK;
+   pm1_cnt_value |= SLEEP_TYPE_S5;
+   pm1_cnt_value |= SLEEP_ENABLE;
+
+   outl(pm1_cnt_value, pm1_cnt_port);
+}
+
+static int pmc_setup_dev(struct pci_dev *pdev)
+{
+   /* Obtain ACPI base address */
+   pci_read_config_dword(pdev, ACPI_BASE_ADDR_OFFSET, _base_addr);
+   acpi_base_addr &= ACPI_BASE_ADDR_MASK;
+
+   /* Install power off function */
+   if (acpi_base_addr != 0 && pm_power_off == NULL)
+   pm_power_off = pmc_power_off;
+
+   return 0;
+}
+
+/*
+ * Data for PCI driver interface
+ *
+ * This data only exists for exporting the supported
+ * PCI ids via MODULE_DEVICE_TABLE.  We do not actually
+ * register a pci_driver, because lpc_ich will register
+ * a driver on the same PCI id.
+ */
+static const struct pci_device_id pmc_pci_ids[] = {
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_VLV_PMC) },
+  

[PATCH 2/2] zram: remove global tb_lock with fine grain lock

[Minchan Kim]

From: Weijie Yang 

Currently, we use a rwlock tb_lock to protect concurrent access to
the whole zram meta table. However, according to the actual access model,
there is only a small chance for upper user to access the same table[index],
so the current lock granularity is too big.

The idea of optimization is to change the lock granularity from whole
meta table to per table entry (table -> table[index]), so that we can
protect concurrent access to the same table[index], meanwhile allow
the maximum concurrency.
With this in mind, several kinds of locks which could be used as a
per-entry lock were tested and compared:

Test environment:
x86-64 Intel Core2 Q8400, system memory 4GB, Ubuntu 12.04,
kernel v3.15.0-rc3 as base, zram with 4 max_comp_streams LZO.

iozone test:
iozone -t 4 -R -r 16K -s 200M -I +Z
(1GB zram with ext4 filesystem, take the average of 10 tests, KB/s)

  Test   base  CASspinlockrwlock   bit_spinlock
---
 Initial write  1381094   1425435   1422860   1423075   1421521
   Rewrite  1529479   1641199   1668762   1672855   1654910
  Read  8468009  11324979  11305569  7273  10997202
   Re-read  8467476  11260914  11248059  11145336  10906486
  Reverse Read  6821393   8106334   8282174   8279195   8109186
   Stride read  7191093   8994306   9153982   8961224   9004434
   Random read  7156353   8957932   9167098   8980465   8940476
Mixed workload  4172747   5680814   5927825   5489578   5972253
  Random write  1483044   1605588   1594329   1600453   1596010
Pwrite  1276644   1303108   1311612   1314228   1300960
 Pread  4324337   4632869   4618386   4457870   4500166

To enhance the possibility of access the same table[index] concurrently,
set zram a small disksize(10MB) and let threads run with large loop count.

fio test:
fio --bs=32k --randrepeat=1 --randseed=100 --refill_buffers
--scramble_buffers=1 --direct=1 --loops=3000 --numjobs=4
--filename=/dev/zram0 --name=seq-write --rw=write --stonewall
--name=seq-read --rw=read --stonewall --name=seq-readwrite
--rw=rw --stonewall --name=rand-readwrite --rw=randrw --stonewall
(10MB zram raw block device, take the average of 10 tests, KB/s)

Test base CASspinlockrwlock  bit_spinlock
-
seq-write   933789   999357   1003298995961   1001958
 seq-read  5634130  6577930   6380861   6243912   6230006
   seq-rw  1405687  1638117   1640256   1633903   1634459
  rand-rw  1386119  1614664   1617211   1609267   1612471

All the optimization methods show a higher performance than the base,
however, it is hard to say which method is the most appropriate.

On the other hand, zram is mostly used on small embedded system, so we
don't want to increase any memory footprint.

This patch pick the bit_spinlock method, pack object size and page_flag
into an unsigned long table.value, so as to not increase any memory
overhead on both 32-bit and 64-bit system.

On the third hand, even though different kinds of locks have different
performances, we can ignore this difference, because:
if zram is used as zram swapfile, the swap subsystem can prevent concurrent
access to the same swapslot;
if zram is used as zram-blk for set up filesystem on it, the upper filesystem
and the page cache also prevent concurrent access of the same block mostly.
So we can ignore the different performances among locks.

Changes since v1: https://lkml.org/lkml/2014/5/5/1
  - replace CAS method with bit_spinlock method
  - rename zram_test_flag() to zram_test_zero()
  - add some comments

Changes since v2: https://lkml.org/lkml/2014/5/15/113
  - change size type from int to size_t in zram_set_obj_size()
  - refactor zram_set_obj_size() to make it readable
  - add comments

Changes since v3: https://lkml.org/lkml/2014/6/3/146
  - drop stack footprint stuff
  - drop zram-zero specific functions
  - change some comments
  - drop discard bio lock comment

Acked-by: Sergey Senozhatsky 
Reviewed-by: Davidlohr Bueso 
Signed-off-by: Weijie Yang 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 69 ++-
 drivers/block/zram/zram_drv.h | 24 +++
 2 files changed, 60 insertions(+), 33 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 3233bccd6361..6a4634b54207 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -183,19 +183,32 @@ static ssize_t comp_algorithm_store(struct device *dev,
 static int zram_test_flag(struct zram_meta *meta, u32 index,
enum zram_pageflags flag)
 {
-   return meta->table[index].flags & BIT(flag);
+   return meta->table[index].value & BIT(flag);
 }
 
 static void zram_set_flag(struct zram_meta *meta, u32 index,
enum zram_pageflags flag)
 {
-   meta->table[index].flags |= BIT(flag);
+   

[PATCH] Fixes gemmi_idle in file idle.c

[Nicholas Krause]

disables the IRQ line in gemmi_idle before calling cpu_do_idle.
In addition, according to the Fixme message in this file fixes
races that may occur due to not disabling the IRQ before calling
cpu_do_idle.

Signed-off-by: Nicholas Krause 
---
 arch/arm/mach-gemini/idle.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-gemini/idle.c b/arch/arm/mach-gemini/idle.c
index ddf8ec9..2880f5a 100644
--- a/arch/arm/mach-gemini/idle.c
+++ b/arch/arm/mach-gemini/idle.c
@@ -17,8 +17,7 @@ static void gemini_idle(void)
 * disabled.
 */
 
-   /* FIXME: Enabling interrupts here is racy! */
-   local_irq_enable();
+   local_irq_disable();
cpu_do_idle();
 }
 
-- 
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/

[PATCHv3 0/3] x86: new Intel atom SOC power management controller driver

[Li, Aubrey]

From: Aubrey Li 

The Power Management Controller (PMC) controls many of the power
management features present in the SoC. This driver provides the power
off functionality and s0ix residency control, also provides the SOC
device state and platform sleep state observation via debugfs.

v3:
- split the driver into tree pieces: the power off functionality, the
s0ix residency control, and the debugfs exports.

v2:
- allow pmc_atom and lpc_ich to work at the same time.

Aubrey Li (3):
  X86 platform: New Intel Atom SOC power management controller driver
  x86/pmc_atom: disable a few S0ix wake up events for S0ix residency
  x86/pmc_atom: expose PMC device state and platform sleep state

 arch/x86/Kconfig|4 +
 arch/x86/include/asm/pmc_atom.h |  107 +
 arch/x86/kernel/Makefile|1 +
 arch/x86/kernel/pmc_atom.c  |  321
+++
 4 files changed, 433 insertions(+)
 create mode 100644 arch/x86/include/asm/pmc_atom.h
 create mode 100644 arch/x86/kernel/pmc_atom.c

-- 
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: [PATCH 1/3] staging: cxt1e1: Remove useless OS_phystov() and OS_vtophys()

[Greg KH]

On Fri, Jun 27, 2014 at 06:52:26PM +0900, Daeseok Youn wrote:
> OS_phystov()/OS_vtophys() are replaced with __va()/__pa().

No, you should use virt_to_phys() and phys_to_virt() instead of these
internal macros which might not be correct for all architectures.

thanks,

greg k-h
--
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 TRIVIAL] thermal: cpu_cooling: fix typo highjack -> hijack

[Zhang Rui]

On Wed, 2014-06-25 at 18:11 +0100, Javi Merino wrote:
> Cc: Eduardo Valentin 
> Cc: Zhang Rui 
> Signed-off-by: Javi Merino 

applied, thanks!

-rui
> ---
>  drivers/thermal/cpu_cooling.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 84a75f89bf74..1ab0018271c5 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -305,7 +305,7 @@ static int cpufreq_apply_cooling(struct 
> cpufreq_cooling_device *cpufreq_device,
>   * @event: value showing cpufreq event for which this function invoked.
>   * @data: callback-specific data
>   *
> - * Callback to highjack the notification on cpufreq policy transition.
> + * Callback to hijack the notification on cpufreq policy transition.
>   * Every time there is a change in policy, we will intercept and
>   * update the cpufreq policy with thermal constraints.
>   *


--
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/3] staging: cxt1e1: count fragmented packet properly.

[Greg KH]

On Fri, Jun 27, 2014 at 06:56:08PM +0900, Daeseok Youn wrote:
> OS_mem_token_tlen() is same return value as OS_mem_token_len().
> That means packet count is always 1. So OS_mem_token_tlen()
> must be total length of packet and OS_mem_token_len() has a
> length of fragmented packet. And then it can count total
> count of fragmented packets properly.
> 
> And OS_mem_token_next() returns NULL, it will be dereferencing
> a NULL pointer. So it must return next fragmented packet buffer as
> sk_buff.
> 
> Signed-off-by: Daeseok Youn 
> ---
> I'm not sure of this patch and not tested.(just only build test).
> Please review for this.
> Thanks.

Please refresh these last two based on the changes in the first one you
should do.

thanks,

greg k-h
--
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 net-next tree

[Stephen Rothwell]

Hi all,

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

In file included from include/net/inet_connection_sock.h:23:0,
 from include/linux/tcp.h:24,
 from include/net/tcp.h:24,
 from net/ipv4/tcp_input.c:72:
net/ipv4/tcp_input.c: In function 'pr_drop_req':
include/net/inet_sock.h:77:41: error: 'struct sock_common' has no member named 
'skc_v6_daddr'
 #define ir_v6_rmt_addr  req.__req_common.skc_v6_daddr
 ^
include/net/sock.h:2273:57: note: in expansion of macro 'ir_v6_rmt_addr'
  do { if (net_msg_warn && net_ratelimit()) printk(fmt,##args); } while(0)
 ^
net/ipv4/tcp_input.c:5889:3: note: in expansion of macro 'LIMIT_NETDEBUG'
   LIMIT_NETDEBUG(KERN_DEBUG pr_fmt("drop open request from %pI6/%u\n"),
   ^

Caused by commit 1fb6f159fd21 ("tcp: add tcp_conn_request").  This
build has CONFIG_IPV6 unset.

I have used the net-next tree from next-20140627 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH 2/2] workqueue: stronger test in process_one_work()

[Lai Jiangshan]

Ping.

Thanks,
Lai

On 06/26/2014 07:27 PM, Lai Jiangshan wrote:
> On 06/20/2014 03:44 AM, Tejun Heo wrote:
>> On Tue, Jun 03, 2014 at 03:33:28PM +0800, Lai Jiangshan wrote:
>>> When POOL_DISASSOCIATED is cleared, the running worker's local CPU should
>>> be the same as pool->cpu without any exception even during cpu-hotplug.
>>>
>>> This fix changes "(proposition_A && proposition_B && proposition_C)"
>>> to "(proposition_B && proposition_C)", so if the old compound proposition
>>> is true, the new one must be true too. so this fix will not hide any
>>> possible bug which can be hit by old test.
>>>
>>> CC: Jason J. Herne 
>>> CC: Sasha Levin 
>>> Signed-off-by: Lai Jiangshan 
>>
>> Applied to wq/for-3.17 with minor updates.
>>
>> Nice set of cleanups.  Thanks!
>>
> 
> Hi,Tejun
> 
> I found the slight earlier 6 patches are in wq/for-3.17.
> But these two patches (in this email thread) are not in wq/for-3.17 yet.
> 
> workqueue: clear POOL_DISASSOCIATED in rebind_workers()
> workqueue: stronger test in process_one_work()
> 
> Thanks,
> Lai
> --
> 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/
> 

--
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: Cleanup of Kernel Bugzilla

[Nick Krause]

If that is true , it may be a good idea to get me or someone to write
a text file like maintainers that
is used to keep track of open bugs by subsystem in the main kernel directory.
Cheers Nick

On Sun, Jun 29, 2014 at 5:32 PM, Theodore Ts'o  wrote:
> On Sun, Jun 29, 2014 at 09:21:46AM +0200, Levente Kurusa wrote:
>>
>> I think that is because they are relatively young and they are generally
>> used for one direct purpose. The kernel has to make sure it works in a lot
>> of different situations and hence a lot of different bugs arise.
>
> There are a huge number of bugs which are hardware specific --- and
> worse, fixing it for one hardware device can often cause problems for
> others.
>
>> >With the linux kernel not only doesn't anything exist, the project
>> >itself is so bloody hard right, kernel programming, most of the
>> >bugzilla bugs I can barely understand let alone even begin to deduce
>> >what is going on. Now given that the list itself isn't maintained
>> >makes things extremely hard.
>>
>> There are still methods to extract various unresolved bugs from the
>> bugzilla though. Look in any subsystem you find delicious and then
>> just sort the bugs by the date they were modified. This will yield
>> a list of nice fresh bugs along with some recently fixed bugs.
>
> Or, try to find your own bugs.  Grab the development kernel, and see
> if it breaks on your system.  If it does, and it was working on the
> last stable kernel, then you can use "git bisect" to try to find the
> point where things broke, and report the problem, and perhaps try to
> figure out why it didn't work.  This can be a huge benefit for
> developers who can't test their changes on every single hardware
> configuration out there, so this sort of early testing of either daily
> linux-next, or the mainline linux tree right after the merge window,
> is a great way to learn about kernel programming.
>
> Because of the focus on "no new regressions", testing the bleeding
> edge development kernels so we can fix problems before they get
> released to civilians is not only important, but often means that the
> bugs that are still open are the ones which are incredibly hard to
> reproduce, or which require very specialized hardware.  So it's very
> likely that they won't be the bugs that are best suited for people who
> are just getting started on kernel development.  Basically, for the
> most part, if they were easy, they would have been fixed already.  :-)
>
>> I brought this up as well on the Kernel Summit list. There wasn't any
>> feedback on this :-), I guess there are some maintainers who care about
>> bugzilla, but the rest (and the majority probably) does not care.
>
> If you ("you" being the generic you) are someone who likes grooming
> the bug tracking systems, you can certainly start to try to figure out
> which bugs are no longer relevant, and then work with someone like
> Alan so they can get closed out.  Over time, as you become trusted to
> have good judgement over bugs, various subsystem maintainers may be
> willing to give you admin bits to close bugs directly.  (And by the
> way, that's something else important to note --- it's good to
> specialize; the kernel is huge, so focusing on a single subsystem is a
> good way to more quickly build up expertise, and for developers for
> that subsystem to get to know you and to trust your judgement and your
> skills.)
>
> However, you may find that unless you're someone who tends to be a bit
> obsessive-compulsive, that grooming the bugzilla doesn't really
> provide much in the way of real benefit to kernel development, and so
> don't provide you with much satisfaction.
>
> After all, we don't have any direct management oversight over
> developers for the upstream kernel.  So tracking things so that
> policies such as "all P1 bugs must be updated every day" can be
> enforced, or to keep lists of which bugs have been opened for the
> longest time so that people can have long interminable meetings about
> why a short-staffed team has so many bugs open, are things which are
> much more applicable for pointy-haired engineering managers who can
> boss engineers around and tell them to work on a particular bugs or
> else they will get a bad rating at the next performance review.  But
> for a volunteer project, keeping track of bugs is something that has
> benefits which are much more indirect.  If as a result, you don't find
> bug grooming to be very satisfying, there's no shame in moving on to
> some other form of kernel contributions that *do* give you more
> satisfaction.
>
> Best regards,
>
> - Ted
--
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: [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec

[Hui Wang]

On 06/29/2014 07:33 PM, Jan Kiszka wrote:

On 2013-11-27 07:47, Hui Wang wrote:

Most Thinkpad Edge series laptops use conexant codec, so far although
the codecs have different minor Vendor Id and minor Subsystem Id,
they all belong to the cxt5066 family, this change can make the
mute/mic-mute LEDs support more generic among cxt_5066 family.

This design refers to the similar solution for the realtek codec
ALC269 family in the patch_realtek.c.

Cc: Alex Hung 
Cc: David Henningsson 
Signed-off-by: Hui Wang 
---
  sound/pci/hda/patch_conexant.c | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index c205bb1..1f2717f 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -3244,9 +3244,29 @@ enum {
  #if IS_ENABLED(CONFIG_THINKPAD_ACPI)
  
  #include 

+#include 
  
  static int (*led_set_func)(int, bool);
  
+static acpi_status acpi_check_cb(acpi_handle handle, u32 lvl, void *context,

+void **rv)
+{
+   bool *found = context;
+   *found = true;
+   return AE_OK;
+}
+
+static bool is_thinkpad(struct hda_codec *codec)
+{
+   bool found = false;
+   if (codec->subsystem_id >> 16 != 0x17aa)
+   return false;
+   if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb, , NULL)) 
&& found)
+   return true;
+   found = false;
+   return ACPI_SUCCESS(acpi_get_devices("IBM0068", acpi_check_cb, , NULL)) 
&& found;
+}
+
  static void update_tpacpi_mute_led(void *private_data, int enabled)
  {
struct hda_codec *codec = private_data;
@@ -3279,6 +3299,8 @@ static void cxt_fixup_thinkpad_acpi(struct hda_codec 
*codec,
bool removefunc = false;
  
  	if (action == HDA_FIXUP_ACT_PROBE) {

+   if (!is_thinkpad(codec))
+   return;
if (!led_set_func)
led_set_func = symbol_request(tpacpi_led_set);
if (!led_set_func) {
@@ -3494,6 +3516,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = {
SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", 
CXT_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x17aa, 0x397b, "Lenovo S205", CXT_FIXUP_STEREO_DMIC),
+   SND_PCI_QUIRK_VENDOR(0x17aa, "Thinkpad", CXT_FIXUP_THINKPAD_ACPI),
SND_PCI_QUIRK(0x1c06, 0x2011, "Lemote A1004", CXT_PINCFG_LEMOTE_A1004),
SND_PCI_QUIRK(0x1c06, 0x2012, "Lemote A1205", CXT_PINCFG_LEMOTE_A1205),
{}


Starting with this patch, my Lenovo Thinkpad X121e netbook (it's without
any mute LEDs, BTW, there is only a power LED) considers the power
button as hard reset. I have to exclude my machine from that ACPI fixup
(this is on top of current Linus master):
It seems more like a firmware issue, in the acpi code, the "SSMS" is for 
mute led, and the "MMTS" is for micmute led, I don't know why your 
machine can pass "SSMS" or "MMTS" scanning even without mute LEDs.





diff --git a/sound/pci/hda/thinkpad_helper.c b/sound/pci/hda/thinkpad_helper.c
index 6ba0b55..7e1a179 100644
--- a/sound/pci/hda/thinkpad_helper.c
+++ b/sound/pci/hda/thinkpad_helper.c
@@ -21,7 +21,8 @@ static acpi_status acpi_check_cb(acpi_handle handle, u32 lvl, 
void *context,
  static bool is_thinkpad(struct hda_codec *codec)
  {
bool found = false;
-   if (codec->subsystem_id >> 16 != 0x17aa)
+   if (codec->subsystem_id >> 16 != 0x17aa ||
+   codec->subsystem_id == 0x17aa21ec)
return false;
if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb, , NULL)) 
&& found)
return true;


Is that the way to address it? Then I can send a proper patch. Any hints
regarding the "why" will be incorporated into its description.

Thanks,
Jan



--
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] FIXME of file toploogy.h for alpha cpus

[Nick Krause]

Sorry Sasha ,
I will rewrite and test this patch before I send it in.
Cheers Nick

On Sun, Jun 29, 2014 at 4:24 PM, Sasha Levin  wrote:
> On 06/28/2014 11:03 PM, Nick Krause wrote:
>> I thought I compiled tested it maybe not. I thought M= would work for
>> alpha directory but maybe I have to enable in on x86.
>> I don't known if there is a way to do this.
>> Cheers Nick
>>
>> On Sat, Jun 28, 2014 at 3:53 PM, Sasha Levin  wrote:
>>> On 06/28/2014 12:07 AM, Nicholas Krause wrote:
 This patch fixs the FIXME message in the function *cpumask_of_node
 for using this function multiple times and the issue with recaluting
 the cpu node mask when reusing this function.

 Signed-off-by: Nicholas Krause 
 ---
  arch/alpha/include/asm/topology.h | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/arch/alpha/include/asm/topology.h 
 b/arch/alpha/include/asm/topology.h
 index 9251e13..d301f66 100644
 --- a/arch/alpha/include/asm/topology.h
 +++ b/arch/alpha/include/asm/topology.h
 @@ -31,6 +31,9 @@ static const struct cpumask *cpumask_of_node(int node)
   if (node == -1)
   return cpu_all_mask;

 + else if (node == _to_cpumask_map[node])
 + return _to_cpumask_map[node];
 +
   cpumask_clear(_to_cpumask_map[node]);

   for_each_online_cpu(cpu) {

>>>
>>> Since this patch doesn't even compile, care to tell us how you tested it?
>>>
>>>
>>> Thanks,
>>> Sasha
>
> Please stop top posting.
>
> Your explanation is missing the part about actually making sure that your 
> patch
> works is missing, how did you intend to make sure that your patch doesn't
> break things?
>
>
> Thanks,
> Sasha
--
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: [PATCHv5 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean

[Chanwoo Choi]

Dear Kukjin,

On 06/29/2014 08:50 PM, Jonathan Cameron wrote:
> On 27/06/14 05:30, Chanwoo Choi wrote:
>> Changes from v4:
>> - Use 'exynos_adc_data' structure instead of 'exynos_adc_ops' structure
>>and remove enum variable of ADC version
>> - Fix wrong name of special clock (sclk_tsadc -> sclk_adc)
>> - Add reviewed message by Naveen Krishna Chatradhi
>> - Add functions for ADC clock control
>>
>> Changes from v3:
>> - Add new 'exynos_adc_ops' structure to improve readability according to
>>   Tomasz Figa comment[1]
>>   [1] https://lkml.org/lkml/2014/4/16/238
>> - Add new 'exynos3250-adc-v2' compatible string to support Exynos3250 ADC
>> - Fix wrong compaitlbe string of ADC in Exynos3250 dtsi file
>>
>> Changes from v2:
>> - Check return value of clock function to deal with error exception
>> - Fix minor coding style to improve readability
>>
>> Changes from v1:
>> - Add new "samsung,exynos-adc-v3" compatible to support Exynos3250 ADC
>> - Add a patch about DT binding documentation
>>
>> Chanwoo Choi (4):
>>iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability
>>iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 
>> ADC
>>iio: devicetree: Add DT binding documentation for Exynos3250 ADC
>>ARM: dts: Fix wrong compatible string for Exynos3250 ADC
>>
>>   .../devicetree/bindings/arm/samsung/exynos-adc.txt |  26 +-
>>   arch/arm/boot/dts/exynos3250.dtsi  |   4 +-
>>   drivers/iio/adc/exynos_adc.c   | 326 
>> +++--
>>   3 files changed, 268 insertions(+), 88 deletions(-)
>>
> I am happy with this series, but given it touches some exynos bindings, I 
> would
> like an ack from Kukjin Kim (or according to MAINTAINERS Ben Dooks) before 
> taking it
> all through IIO.

Could you please review this patchset about exynos dtsi and bindings?

Best Regards,
Chanwoo Choi



--
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/1] Move two pinned pages to non-movable node in kvm.

[Tang Chen]

On 06/21/2014 04:39 AM, Marcelo Tosatti wrote:

On Fri, Jun 20, 2014 at 05:31:46PM -0300, Marcelo Tosatti wrote:

IIRC your shadow page pinning patch series support flushing of ptes
by mmu notifier by forcing MMU reload and, as a result, faulting in of
pinned pages during next entry.  Your patch series does not pin pages
by elevating their page count.


No but PEBS series does and its required to stop swap-out
of the page.


Well actually no because of mmu notifiers.

Tang, can you implement mmu notifiers for the other breaker of
mem hotplug ?


Hi Marcelo,

I made a patch to update ept and apic pages when finding them in the
next ept violation. And I also updated the APIC_ACCESS_ADDR phys_addr.
The pages can be migrated, but the guest crached.

How do I stop guest from access apic pages in mmu_notifier when the
page migration starts ?  Do I need to stop all the vcpus by set vcpu
state to KVM_MP_STATE_HALTED ?  If so, the vcpu will not able to go
to the next ept violation.

So, may I write any specific value into APIC_ACCESS_ADDR to stop guest
from access to apic page ?

Thanks.
--
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/score/include/uapi/asm/ptrace.h: Add prefix 'SCORE_' for related macros

[Chen Gang]

On 06/27/2014 06:12 PM, Chen Gang wrote:
> On 06/25/2014 08:28 AM, Chen Gang wrote:
>> On 06/24/2014 10:44 PM, Guenter Roeck wrote:
>>> On 06/24/2014 06:24 AM, Chen Gang wrote:
 On 06/23/2014 11:03 AM, Chen Gang wrote:
> On 06/22/2014 11:02 PM, Guenter Roeck wrote:
>> On 06/22/2014 07:53 AM, Guenter Roeck wrote:
>>> I did that, and managed to build gcc.
>>>
>>> However, when trying to compile score defconfig, I get internal
>>> compiler errors in cc1
>>> when compiling drivers/tty/tty_mutex.o and block/elevator.o.
>>>
>>>CC  block/elevator.o
>>> score-elf-gcc: internal compiler error: Segmentation fault (program
>>> cc1)
>>> 0x40c073 execute
>>>   ../../gcc/gcc/gcc.c:2848
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> Please include the complete backtrace with any bug report.
>>> See  for instructions.
>>> make[1]: *** [block/elevator.o] Error 4
>>> make: *** [block/elevator.o] Error 2
>>>
>>> Do you see that as well ?
>>>
>>> This is with
>>>
>>> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU
>>> Binutils) 2.24.51.20140622
>>>
>>> and gcc configured with:
>>>
>>> Configured with: ../gcc/configure --prefix=/opt/kernel/score
>>> --program-prefix=score-elf- \
>>> --target=score-elf --without-header --disable-nls --enable-languages=c
>>> --disable-threads \
>>> --disable-shared --enable-werror=no
>>> target_configargs=enable_vtable_verify=yes \
>>> --enable-obsolete --disable-libssp --disable-libquadmath
>>>
>>> Tip of gcc source is commit d8686b0aa945a, tip of binutils source is
>>> commit d17c74c1d41.
>>> Your assembler fix is included in this version of binutils.
>>>

 Can we repeated this issue, or it is random?  I have try it use my
 current gcc version, it has no issue.

 If it can be repeated in the latest version, I shall use version compine
 (and try step by step) to fix it.

 If real random issue, if possible, please help repeated and generate
 coredump file, and put it to a place to let me get back for analysing.

>>> I got the same error each time. You should be able to reproduce it by
>>> checking out the latest gcc. If that doesn't produce the error, try
>>> checking out sha d8686b0aa945a. I didn't keep that compiler after the tip
>>> of the gcc 4.9 branch worked, so I'd have to rebuild it myself
>>> to reproduce it myself.
>>>
>>> Note that compilation of libssp failed with d8686b0aa945a, which is why
>>> I disabled it. I didn't try to build it with 4.9.
>>>

gcc members response quickly, and confirm it, the related fix patch
which is made by a gcc member and I, have applied into latest gcc source
code.

So... I finished it within this month (this thread will be end)!  :-)


Thanks.
> 
> And I guess, I have found the root cause, and sent related information
> to gcc mailing list (also cc to you). And one temporary fix below (can
> cross compile score defconfig successfully for latest gcc):
> 
>   diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
>   index def10a2..af49601 100644
>   --- a/gcc/c/c-decl.c
>   +++ b/gcc/c/c-decl.c
>   @@ -2300,15 +2300,6 @@ merge_decls (tree newdecl, tree olddecl, tree 
> newtype, tree oldtype)
>
>  if (CODE_CONTAINS_STRUCT (TREE_CODE (olddecl), TS_DECL_WITH_VIS))
>{
>   -  /* Merge the section attribute.
>   -We want to issue an error if the sections conflict but that
>   -must be done later in decl_attributes since we are called
>   -before attributes are assigned.  */
>   -  if ((DECL_EXTERNAL (olddecl) || TREE_PUBLIC (olddecl) || TREE_STATIC 
> (olddecl))
>   - && DECL_SECTION_NAME (newdecl) == NULL
>   - && DECL_SECTION_NAME (olddecl))
>   -   set_decl_section_name (newdecl, DECL_SECTION_NAME (olddecl));
>   -
>  /* Copy the assembler name.
>Currently, it can only be defined in the prototype.  */
>  COPY_DECL_ASSEMBLER_NAME (olddecl, newdecl);
> 
> I shall continue for it, and provide the final property fix for it.
> 
> Thanks.
> 
>>
>> Thank you very much for your work.
>>
>> It is my chance to fix gcc issues which I have planed, I shall continue
>> based on it, hope I can finish within this month (within 2014-06-30).
>>
>>
>> Thanks.
>>
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
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 1/3] cgroup: fix mount failure in a corner case

[Li Zefan]

On 2014/6/28 19:58, Tejun Heo wrote:
> Hello, Li.
> 
> On Fri, Jun 27, 2014 at 05:13:12PM +0800, Li Zefan wrote:
>> +for_each_subsys(ss, i) {
>> +if (!(opts.subsys_mask & (1 << i)) ||
>> +ss->root == _dfl_root)
>> +continue;
>> +
>> +if (!percpu_ref_tryget_live(>root->cgrp.self.refcnt)) {
>> +mutex_unlock(_mutex);
>> +msleep(10);
>> +ret = restart_syscall();
>> +goto out_free;
>> +}
> 
> Why not just put it immediately?  We know that it's not gonna be
> destroyed while holding cgroup_mutex.  It may look a bit weird but
> this is a pretty special case anyway and deferring put doesn't buy
> anything.
> 

Yeah, this is better. :)

--
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 5/5] I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI config

[Lan Tianyu]

On 2014年06月27日 19:03, Wolfram Sang wrote:
> On Tue, May 20, 2014 at 08:59:24PM +0800, Lan Tianyu wrote:
>> Clean up ACPI related code in the i2c core and add CONFIG_I2C_ACPI
>> to enable I2C ACPI code.
>>
>> Current there is a race between removing I2C ACPI operation region
>> and ACPI AML code accessing. So make i2c core built-in if CONFIG_I2C_ACPI
>> is set.
>>
>> Reviewed-by: Mika Westerberg 
>> Signed-off-by: Lan Tianyu 
> 
> Applied to for-next, thanks!
> 

Great. Thanks :)


-- 
Best regards
Tianyu Lan
--
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] Fix backlight control for Acer TravelMate B113

[Aaron Lu]

On 06/29/2014 04:42 PM, Martin Kepplinger wrote:
> Am 2014-06-23 22:30, schrieb Martin Kepplinger:
>> Fix backlight control for Acer TravelMate B113 Laptop by adding
>> it to the video_dmi_table.
>>
>> A workaround before that was to use acpi_osi=Linux or
>> acpi_backlight=vendor on boot but even then, only the function-
>> keys worked.
>>
>> With this change there is no need for boot parameters and DE's
>> controls work as well.
>>
>> Signed-off-by: Martin Kepplinger 
>> Tested-by: Martin Kepplinger 
>> ---
>>  drivers/acpi/video.c |8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
>> index f8bc5a7..acb0670 100644
>> --- a/drivers/acpi/video.c
>> +++ b/drivers/acpi/video.c
>> @@ -528,6 +528,14 @@ static struct dmi_system_id video_dmi_table[] 
>> __initdata = {
>>  },
>>  },
>>  {
>> + .callback = video_set_use_native_backlight,
>> + .ident = "Acer TravelMate B113",
>> + .matches = {
>> +DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
>> +DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate B113"),
>> +},
>> +},
>> +{
>>  .callback = video_set_use_native_backlight,
>>  .ident = "HP ProBook 4340s",
>>  .matches = {
>>
> 
> are there objections or advice on this? this would be really good to
> have, even if for 3.17.

For v3.16, we already have this commit to make use_native_backlight
equal to 1 by default:

commit 751109aad5834375ca9ed0dcfcd85a00cbf872b5
Author: Rafael J. Wysocki 
Date:   Thu Jun 5 22:47:35 2014 +0200

ACPI / video: Change the default for video.use_native_backlight to 1


Thanks,
Aaron

> 
> thanks.
> martin
> --
> 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/
> 

--
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] [sched] Don't account time after deadline twice

[Zhihui Zhang]

Unless we want to double-penalize an overrun task, the time after the deadline
and before the current time is already accounted in the negative dl_se->runtime
value. So we can leave it as is in the case of dmiss && rorun.

Signed-off-by: Zhihui Zhang 
---
 kernel/sched/deadline.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..67df0d6 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -579,10 +579,8 @@ int dl_runtime_exceeded(struct rq *rq, struct 
sched_dl_entity *dl_se)
 * the next instance. Thus, if we do not account that, we are
 * stealing bandwidth from the system at each deadline miss!
 */
-   if (dmiss) {
-   dl_se->runtime = rorun ? dl_se->runtime : 0;
-   dl_se->runtime -= rq_clock(rq) - dl_se->deadline;
-   }
+   if (dmiss && !rorun)
+   dl_se->runtime = dl_se->deadline - rq_clock(rq);
 
return 1;
 }
-- 
1.8.1.2

--
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] usb: usb3503: return correct error return on failure

[Jingoo Han]

On Monday, June 30, 2014 6:43 AM, Colin King wrote:
> 
> From: Colin Ian King 
> 
> Fix warning: drivers/usb/misc/usb3503.c:195:11: warning: 'err'
>   may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> err is not initialized, the error return should be PTR_ERR(clk)
> 
> Signed-off-by: Colin Ian King 

It looks good!

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/usb/misc/usb3503.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
> index f43c619..c0c898d 100644
> --- a/drivers/usb/misc/usb3503.c
> +++ b/drivers/usb/misc/usb3503.c
> @@ -192,7 +192,8 @@ static int usb3503_probe(struct usb3503 *hub)
> 
>   clk = devm_clk_get(dev, "refclk");
>   if (IS_ERR(clk) && PTR_ERR(clk) != -ENOENT) {
> - dev_err(dev, "unable to request refclk (%d)\n", err);
> + dev_err(dev, "unable to request refclk (%ld)\n",
> + PTR_ERR(clk));
>   return PTR_ERR(clk);
>   }
> 
> --
> 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] KVM: x86: Fix lapic.c debug prints

[Nadav Amit]

On 6/30/14, 3:48 AM, Bandan Das wrote:

Nadav Amit  writes:


In two cases lapic.c does not use the apic_debug macro correctly. This patch
fixes them.

Signed-off-by: Nadav Amit 
---
  arch/x86/kvm/lapic.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0069118..3855103 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1451,7 +1451,7 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu)
vcpu->arch.apic_arb_prio = 0;
vcpu->arch.apic_attention = 0;

-   apic_debug(KERN_INFO "%s: vcpu=%p, id=%d, base_msr="
+   apic_debug("%s: vcpu=%p, id=%d, base_msr="
   "0x%016" PRIx64 ", base_address=0x%0lx.\n", __func__,
   vcpu, kvm_apic_id(apic),
   vcpu->arch.apic_base, apic->base_address);
@@ -1895,7 +1895,7 @@ void kvm_apic_accept_events(struct kvm_vcpu *vcpu)
/* evaluate pending_events before reading the vector */
smp_rmb();
sipi_vector = apic->sipi_vector;
-   pr_debug("vcpu %d received sipi with vector # %x\n",
+   apic_debug("vcpu %d received sipi with vector # %x\n",


Why don't we just use pr_debug all throughout ?

I don't know. I just tried to make it consistent, since it really bugged 
me while I was debugging the local-apic.
If you prefer the other way around (which does seem to be better), I can 
do the search-and-replace.


Nadav
--
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] KVM: x86: Fix lapic.c debug prints

[Bandan Das]

Nadav Amit  writes:

> In two cases lapic.c does not use the apic_debug macro correctly. This patch
> fixes them.
>
> Signed-off-by: Nadav Amit 
> ---
>  arch/x86/kvm/lapic.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 0069118..3855103 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -1451,7 +1451,7 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu)
>   vcpu->arch.apic_arb_prio = 0;
>   vcpu->arch.apic_attention = 0;
>  
> - apic_debug(KERN_INFO "%s: vcpu=%p, id=%d, base_msr="
> + apic_debug("%s: vcpu=%p, id=%d, base_msr="
>  "0x%016" PRIx64 ", base_address=0x%0lx.\n", __func__,
>  vcpu, kvm_apic_id(apic),
>  vcpu->arch.apic_base, apic->base_address);
> @@ -1895,7 +1895,7 @@ void kvm_apic_accept_events(struct kvm_vcpu *vcpu)
>   /* evaluate pending_events before reading the vector */
>   smp_rmb();
>   sipi_vector = apic->sipi_vector;
> - pr_debug("vcpu %d received sipi with vector # %x\n",
> + apic_debug("vcpu %d received sipi with vector # %x\n",

Why don't we just use pr_debug all throughout ?

>vcpu->vcpu_id, sipi_vector);
>   kvm_vcpu_deliver_sipi_vector(vcpu, sipi_vector);
>   vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
--
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/

[GIT PULL] ext4 bug fixes for 3.16

[Theodore Ts'o]

The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:

  Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
tags/ext4_for_linus_stable

for you to fetch changes up to a93cd4cf86466caa49cfe64607bea7f0bde3f916:

  ext4: Fix hole punching for files with indirect blocks (2014-06-26 12:30:54 
-0400)


Fix a regression when trying to compile ext4 on older versions gcc.

Fix a number of miscellaneous bugs for punch hole as well as a
long-standing potential double buffer head release when failing a
block allocation for an indirect-mapped file.


Jan Kara (3):
  ext4: Fix buffer double free in ext4_alloc_branch()
  ext4: Fix block zeroing when punching holes in indirect block files
  ext4: Fix hole punching for files with indirect blocks

Namjae Jeon (1):
  ext4: decrement free clusters/inodes counters when block group declared 
bad

T Makphaibulchoke (1):
  fs/mbcache: replace __builtin_log2() with ilog2()

 fs/ext4/balloc.c   | 16 
 fs/ext4/ialloc.c   | 23 +++
 fs/ext4/indirect.c | 24 +++-
 fs/ext4/mballoc.c  |  8 
 fs/mbcache.c   |  3 ++-
 5 files changed, 68 insertions(+), 6 deletions(-)
--
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] i2c: busses: i2c-pxa.c: Fix for possible null pointer dereferenc

[Jingoo Han]

On Monday, June 30, 2014 8:29 AM, Rickard Strandqvist wrote:
> 
> Fix for possible null pointer dereferenc, and there is a risk for memory leak 
> in when something
> unexpected happens and the function returns.

Would you split the patch into two patches?

  [PATCH 1/2] i2c: pxa: Fix for possible null pointer dereference
  [PATCH 2/2] i2c: pxa: Use devm_* functions

> 
> Signed-off-by: Rickard Strandqvist 
> ---
>  drivers/i2c/busses/i2c-pxa.c |   37 -
>  1 file changed, 16 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index be671f7..886877a 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -1141,10 +1141,10 @@ static int i2c_pxa_probe(struct platform_device *dev)
>   struct resource *res = NULL;
>   int ret, irq;
> 
> - i2c = kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
> + i2c = devm_kzalloc(>dev, sizeof(struct pxa_i2c), GFP_KERNEL);
>   if (!i2c) {
>   ret = -ENOMEM;
> - goto emalloc;
> + goto err_nothing_to_release;
>   }
> 
>   /* Default adapter num to device id; i2c_pxa_probe_dt can override. */
> @@ -1154,18 +1154,19 @@ static int i2c_pxa_probe(struct platform_device *dev)
>   if (ret > 0)
>   ret = i2c_pxa_probe_pdata(dev, i2c, _type);
>   if (ret < 0)
> - goto eclk;
> + goto err_nothing_to_release;
> 
>   res = platform_get_resource(dev, IORESOURCE_MEM, 0);
>   irq = platform_get_irq(dev, 0);
>   if (res == NULL || irq < 0) {
>   ret = -ENODEV;
> - goto eclk;
> + goto err_nothing_to_release;
>   }
> 
> - if (!request_mem_region(res->start, resource_size(res), res->name)) {
> + if (!devm_request_mem_region(>dev, res->start,
> + resource_size(res), res->name)) {
>   ret = -ENOMEM;
> - goto eclk;
> + goto emalloc;
>   }
> 
>   i2c->adap.owner   = THIS_MODULE;
> @@ -1176,16 +1177,16 @@ static int i2c_pxa_probe(struct platform_device *dev)
> 
>   strlcpy(i2c->adap.name, "pxa_i2c-i2c", sizeof(i2c->adap.name));
> 
> - i2c->clk = clk_get(>dev, NULL);
> + i2c->clk = devm_clk_get(>dev, NULL);
>   if (IS_ERR(i2c->clk)) {
>   ret = PTR_ERR(i2c->clk);
> - goto eclk;
> + goto emalloc;
>   }
> 
> - i2c->reg_base = ioremap(res->start, resource_size(res));
> - if (!i2c->reg_base) {
> + i2c->reg_base = devm_ioremap(>dev, res->start, resource_size(res));
> + if (IS_ERR(i2c->reg_base)) {

Did you check what devm_ioremap() returns?
It returns 'valid addr value' Or NULL as below.
So, IS_ERR() should NOT be used.

./lib/devres.c

void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
   unsigned long size)
{
void __iomem **ptr, *addr;

ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
if (!ptr)
return NULL;

addr = ioremap(offset, size);
if (addr) {
*ptr = addr;
devres_add(dev, ptr);
} else
devres_free(ptr);

return addr;
}
EXPORT_SYMBOL(devm_ioremap);

Best regards,
Jingoo Han

>   ret = -EIO;
> - goto eremap;
> + goto emalloc;
>   }
> 
>   i2c->reg_ibmr = i2c->reg_base + pxa_reg_layout[i2c_type].ibmr;
> @@ -1227,10 +1228,10 @@ static int i2c_pxa_probe(struct platform_device *dev)
>   i2c->adap.algo = _pxa_pio_algorithm;
>   } else {
>   i2c->adap.algo = _pxa_algorithm;
> - ret = request_irq(irq, i2c_pxa_handler, IRQF_SHARED,
> -   dev_name(>dev), i2c);
> + ret = devm_request_irq(>dev, irq, i2c_pxa_handler,
> +  IRQF_SHARED, dev_name(>dev), i2c);
>   if (ret)
> - goto ereqirq;
> + goto emalloc;
>   }
> 
>   i2c_pxa_reset(i2c);
> @@ -1261,15 +1262,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
>  eadapt:
>   if (!i2c->use_pio)
>   free_irq(irq, i2c);
> -ereqirq:
> - clk_disable_unprepare(i2c->clk);
> - iounmap(i2c->reg_base);
> -eremap:
> - clk_put(i2c->clk);
> -eclk:
> - kfree(i2c);
>  emalloc:
>   release_mem_region(res->start, resource_size(res));
> +err_nothing_to_release:
>   return ret;
>  }
> 
> --
> 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: [PATCH] power: ab8500_fg.c: Cleaning up uninitialized variables

[Rickard Strandqvist]

Hi

Can someone please check on this!

This will cause an error, and is one of the most obvious ones I've found.
So give it one minute please.

Kind regards
Rickard Strandqvist


2014-06-01 22:03 GMT+02:00 Rickard Strandqvist
:
> In this case the wrong variable is used, which has never been initialized.
> This will lead to a serious error.
>
> This was largely found by using a static code analysis program called 
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist 
> ---
>  drivers/power/ab8500_fg.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
> index 3cb4178..019e33f 100644
> --- a/drivers/power/ab8500_fg.c
> +++ b/drivers/power/ab8500_fg.c
> @@ -2969,7 +2969,7 @@ static struct device_attribute 
> ab8505_fg_sysfs_psy_attrs[] = {
>
>  static int ab8500_fg_sysfs_psy_create_attrs(struct device *dev)
>  {
> -   unsigned int i, j;
> +   unsigned int j;
> struct power_supply *psy = dev_get_drvdata(dev);
> struct ab8500_fg *di;
>
> @@ -2986,7 +2986,7 @@ static int ab8500_fg_sysfs_psy_create_attrs(struct 
> device *dev)
>  sysfs_psy_create_attrs_failed_ab8505:
> dev_err(dev, "Failed creating sysfs psy attrs for ab8505.\n");
> while (j--)
> -   device_remove_file(dev, _fg_sysfs_psy_attrs[i]);
> +   device_remove_file(dev, _fg_sysfs_psy_attrs[j]);
>
> return -EIO;
>  }
> --
> 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: [PATCHv5 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean

[Chanwoo Choi]

Hi Tomasz,

On 06/27/2014 08:26 PM, Tomasz Figa wrote:
> Hi Chanwoo,
> 
> On 27.06.2014 06:30, Chanwoo Choi wrote:
>> Changes from v4:
>> - Use 'exynos_adc_data' structure instead of 'exynos_adc_ops' structure
>>   and remove enum variable of ADC version
>> - Fix wrong name of special clock (sclk_tsadc -> sclk_adc)
>> - Add reviewed message by Naveen Krishna Chatradhi
>> - Add functions for ADC clock control
>>
>> Changes from v3:
>> - Add new 'exynos_adc_ops' structure to improve readability according to
>>  Tomasz Figa comment[1]
>>  [1] https://lkml.org/lkml/2014/4/16/238
>> - Add new 'exynos3250-adc-v2' compatible string to support Exynos3250 ADC
>> - Fix wrong compaitlbe string of ADC in Exynos3250 dtsi file
>>
>> Changes from v2:
>> - Check return value of clock function to deal with error exception
>> - Fix minor coding style to improve readability
>>
>> Changes from v1:
>> - Add new "samsung,exynos-adc-v3" compatible to support Exynos3250 ADC
>> - Add a patch about DT binding documentation
>>
>> Chanwoo Choi (4):
>>   iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability
>>   iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 
>> ADC
>>   iio: devicetree: Add DT binding documentation for Exynos3250 ADC
>>   ARM: dts: Fix wrong compatible string for Exynos3250 ADC
>>
>>  .../devicetree/bindings/arm/samsung/exynos-adc.txt |  26 +-
>>  arch/arm/boot/dts/exynos3250.dtsi  |   4 +-
>>  drivers/iio/adc/exynos_adc.c   | 326 
>> +++--
>>  3 files changed, 268 insertions(+), 88 deletions(-)
>>
> 
> For the whole series:
> 
> Reviewed-by: Tomasz Figa 

Thanks for your review.

Best Regards,
Chanwoo Choi

--
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] i2c: busses: i2c-pxa.c: Fix for possible null pointer dereferenc

[Rickard Strandqvist]

After discussion with especially Wolfram it was decided to convert the code to 
use the Managed Device Resource.
I have now tried to create a patch with Devres, hope it is correct.
But a code review is probably more relevant than usual.
I also lack this kind of hardware so preferably should someone do a HW test.

Rickard Strandqvist (1):
  i2c: busses: i2c-pxa.c:  Fix for possible null pointer dereferenc

 drivers/i2c/busses/i2c-pxa.c |   37 -
 1 file changed, 16 insertions(+), 21 deletions(-)

-- 
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/

[PATCH v2] i2c: busses: i2c-pxa.c: Fix for possible null pointer dereferenc

[Rickard Strandqvist]

Fix for possible null pointer dereferenc, and there is a risk for memory leak 
in when something unexpected happens and the function returns.

Signed-off-by: Rickard Strandqvist 
---
 drivers/i2c/busses/i2c-pxa.c |   37 -
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index be671f7..886877a 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1141,10 +1141,10 @@ static int i2c_pxa_probe(struct platform_device *dev)
struct resource *res = NULL;
int ret, irq;
 
-   i2c = kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
+   i2c = devm_kzalloc(>dev, sizeof(struct pxa_i2c), GFP_KERNEL);
if (!i2c) {
ret = -ENOMEM;
-   goto emalloc;
+   goto err_nothing_to_release;
}
 
/* Default adapter num to device id; i2c_pxa_probe_dt can override. */
@@ -1154,18 +1154,19 @@ static int i2c_pxa_probe(struct platform_device *dev)
if (ret > 0)
ret = i2c_pxa_probe_pdata(dev, i2c, _type);
if (ret < 0)
-   goto eclk;
+   goto err_nothing_to_release;
 
res = platform_get_resource(dev, IORESOURCE_MEM, 0);
irq = platform_get_irq(dev, 0);
if (res == NULL || irq < 0) {
ret = -ENODEV;
-   goto eclk;
+   goto err_nothing_to_release;
}
 
-   if (!request_mem_region(res->start, resource_size(res), res->name)) {
+   if (!devm_request_mem_region(>dev, res->start,
+   resource_size(res), res->name)) {
ret = -ENOMEM;
-   goto eclk;
+   goto emalloc;
}
 
i2c->adap.owner   = THIS_MODULE;
@@ -1176,16 +1177,16 @@ static int i2c_pxa_probe(struct platform_device *dev)
 
strlcpy(i2c->adap.name, "pxa_i2c-i2c", sizeof(i2c->adap.name));
 
-   i2c->clk = clk_get(>dev, NULL);
+   i2c->clk = devm_clk_get(>dev, NULL);
if (IS_ERR(i2c->clk)) {
ret = PTR_ERR(i2c->clk);
-   goto eclk;
+   goto emalloc;
}
 
-   i2c->reg_base = ioremap(res->start, resource_size(res));
-   if (!i2c->reg_base) {
+   i2c->reg_base = devm_ioremap(>dev, res->start, resource_size(res));
+   if (IS_ERR(i2c->reg_base)) {
ret = -EIO;
-   goto eremap;
+   goto emalloc;
}
 
i2c->reg_ibmr = i2c->reg_base + pxa_reg_layout[i2c_type].ibmr;
@@ -1227,10 +1228,10 @@ static int i2c_pxa_probe(struct platform_device *dev)
i2c->adap.algo = _pxa_pio_algorithm;
} else {
i2c->adap.algo = _pxa_algorithm;
-   ret = request_irq(irq, i2c_pxa_handler, IRQF_SHARED,
- dev_name(>dev), i2c);
+   ret = devm_request_irq(>dev, irq, i2c_pxa_handler,
+IRQF_SHARED, dev_name(>dev), i2c);
if (ret)
-   goto ereqirq;
+   goto emalloc;
}
 
i2c_pxa_reset(i2c);
@@ -1261,15 +1262,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
 eadapt:
if (!i2c->use_pio)
free_irq(irq, i2c);
-ereqirq:
-   clk_disable_unprepare(i2c->clk);
-   iounmap(i2c->reg_base);
-eremap:
-   clk_put(i2c->clk);
-eclk:
-   kfree(i2c);
 emalloc:
release_mem_region(res->start, resource_size(res));
+err_nothing_to_release:
return ret;
 }
 
-- 
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: [RFC PATCH] bio-integrity: add "bip_max_vcnt" into struct bio_integrity_payload

[Martin K. Petersen]

> "Gu" == Gu Zheng  writes:

[Sorry about the delay. I'm on vacation right now.]

Gu> But it seems that bip_integrity_vecs() will return the wrong number
Gu> if the bio is not based on any bio_set for some reason(bio->bi_pool
Gu> == NULL), because in that case, the bip_inline_vecs[0] is malloced
Gu> directly.  So here we add the bip_max_vcnt to record the count of
Gu> vector slots, and cleanup the function bip_integrity_vecs().

I'm in agreement with your fix.

However, I'm still not sure what the use case is for bios without an
associated bioset. I do not see any callers that pass in a NULL bioset.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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: [rcu] 2d033d5c0d4: +225.2% iperf.tcp.sender.bps

[Paul E. McKenney]

On Sun, Jun 29, 2014 at 11:15:44PM +0800, Fengguang Wu wrote:
> Hi Paul,
> 
> FYI, we noticed the below changes on
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
> commit 2d033d5c0d424b7029abd0fc82e940ebc318fd89 ("rcu: Bind grace-period 
> kthreads to non-NO_HZ_FULL CPUs")

Nice!  Clearly outlines the hazards of providing too few housekeeping CPUs,
I would guess.

Thanx, Paul

> test case: bens/iperf/300s-tcp
> 
> e17adc3f20bc9a1  2d033d5c0d424b7029abd0fc8  
> ---  -  
>  7.011e+09 ~ 1%+225.2%   2.28e+10 ~ 2%  TOTAL iperf.tcp.sender.bps
>  7.011e+09 ~ 1%+225.2%   2.28e+10 ~ 2%  TOTAL iperf.tcp.receiver.bps
>   15620691 ~ 1%+224.3%   50663012 ~ 2%  TOTAL proc-vmstat.pgalloc_normal
>   62969722 ~ 1%+224.3%  2.042e+08 ~ 2%  TOTAL proc-vmstat.pgfree
>   47347349 ~ 1%+224.3%  1.535e+08 ~ 2%  TOTAL proc-vmstat.pgalloc_dma32
>4996590 ~ 1%+218.9%   15933563 ~ 3%  TOTAL softirqs.NET_RX
>8084072 ~ 1%+218.4%   25739055 ~ 2%  TOTAL proc-vmstat.numa_hit
>8084072 ~ 1%+218.4%   25739055 ~ 2%  TOTAL proc-vmstat.numa_local
>  28676 ~ 2% -47.5%  15059 ~11%  TOTAL softirqs.RCU
>  99756 ~ 2% +76.0% 175606 ~ 2%  TOTAL softirqs.SCHED
>562 ~11% +50.9%848 ~17%  TOTAL 
> slabinfo.proc_inode_cache.active_objs
>620 ~ 8% +38.7%860 ~15%  TOTAL 
> slabinfo.proc_inode_cache.num_objs
> 271905 ~ 4% +17.4% 319216 ~ 0%  TOTAL softirqs.TIMER
>   1117 ~ 1%  -9.1%   1015 ~ 2%  TOTAL proc-vmstat.pgactivate
>   9049 ~11% -94.6%485 ~26%  TOTAL 
> time.involuntary_context_switches
>  23233 ~ 1% +72.1%  39979 ~ 2%  TOTAL vmstat.system.cs
>  13078 ~ 1% +69.1%  22117 ~ 1%  TOTAL vmstat.system.in
> 
> Legend:
>   ~XX%- stddev percent
>   [+-]XX% - change percent
> 
> 
>  iperf.tcp.sender.bps
> 
>   2.4e+10 ++O-O---O--O-OO-O-+
>   |O O  O  O O  OO   O  |
>   2.2e+10 O+ O O   O|
> 2e+10 ++  O |
>   | |
>   1.8e+10 ++|
>   1.6e+10 ++O O |
>   | |
>   1.4e+10 ++|
>   1.2e+10 ++|
>   | |
> 1e+10 ++|
> 8e+09 ++|
>   *..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
> 6e+09 +++
> 
> 
> iperf.tcp.receiver.bps
> 
>   2.4e+10 ++O-O---O--O-OO-O-+
>   |O O  O  O O  OO   O  |
>   2.2e+10 O+ O O   O|
> 2e+10 ++  O |
>   | |
>   1.8e+10 ++|
>   1.6e+10 ++O O |
>   | |
>   1.4e+10 ++|
>   1.2e+10 ++|
>   | |
> 1e+10 ++|
> 8e+09 ++|
>   *..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
> 6e+09 +++
> 
> 
>   time.involuntary_context_switches
> 
>   14000 ++--+
> |   |
>   12000 *+..*..  ..*..*..  .*.. |
> |.*..*.*.*. |
>   1 ++ *.  *..*..  .*..*..*..  ..*..*.. *
> |  

[PATCH v2] arch,locking: Ciao arch_mutex_cpu_relax()

[Davidlohr Bueso]

From: Davidlohr Bueso 

The arch_mutex_cpu_relax() function, introduced by 34b133f, is
hacky and ugly. It was added a few years ago to address the fact
that common cpu_relax() calls include yielding on s390, and thus
impact the optimistic spinning functionality of mutexes. Nowadays
we use this function well beyond mutexes: rwsem, qrwlock, mcs and
lockref. Since the macro that defines the call is in the mutex header,
any users must include mutex.h and the naming is misleading as well.

This patch (i) renames the call to cpu_relax_lowlatency  ("relax, but
only if you can do it with very low latency") and (ii) defines it in
each arch's asm/processor.h local header, just like for regular cpu_relax
functions. On all archs, except s390, cpu_relax_lowlatency is simply cpu_relax,
and thus we can take it out of mutex.h. While this can seem redundant,
I believe it is a good choice as it allows us to move out arch specific
logic from generic locking primitives and enables future(?) archs to
transparently define it, similarly to System Z.

Please note that these changes are only tested on x86-64.

Signed-off-by: Davidlohr Bueso 
---
Changes from v1: Rename arch_cpu_relax to cpu_relax_lowlatency,
based on the purpose of the function, as suggested by Linus.

 arch/alpha/include/asm/processor.h | 1 +
 arch/arc/include/asm/processor.h   | 2 ++
 arch/arm/include/asm/processor.h   | 2 ++
 arch/arm64/include/asm/processor.h | 1 +
 arch/avr32/include/asm/processor.h | 1 +
 arch/blackfin/include/asm/processor.h  | 2 +-
 arch/c6x/include/asm/processor.h   | 1 +
 arch/cris/include/asm/processor.h  | 1 +
 arch/hexagon/include/asm/processor.h   | 1 +
 arch/ia64/include/asm/processor.h  | 1 +
 arch/m32r/include/asm/processor.h  | 1 +
 arch/m68k/include/asm/processor.h  | 1 +
 arch/metag/include/asm/processor.h | 1 +
 arch/mips/include/asm/processor.h  | 1 +
 arch/mn10300/include/asm/processor.h   | 2 ++
 arch/openrisc/include/asm/processor.h  | 1 +
 arch/parisc/include/asm/processor.h| 1 +
 arch/powerpc/include/asm/processor.h   | 2 ++
 arch/s390/include/asm/processor.h  | 2 +-
 arch/score/include/asm/processor.h | 1 +
 arch/sh/include/asm/processor.h| 1 +
 arch/sparc/include/asm/processor_32.h  | 2 ++
 arch/sparc/include/asm/processor_64.h  | 1 +
 arch/tile/include/asm/processor.h  | 2 ++
 arch/unicore32/include/asm/processor.h | 1 +
 arch/x86/include/asm/processor.h   | 2 ++
 arch/xtensa/include/asm/processor.h| 1 +
 include/linux/mutex.h  | 4 
 kernel/locking/mcs_spinlock.c  | 8 +++-
 kernel/locking/mcs_spinlock.h  | 4 ++--
 kernel/locking/mutex.c | 4 ++--
 kernel/locking/qrwlock.c   | 9 -
 kernel/locking/rwsem-xadd.c| 4 ++--
 lib/lockref.c  | 3 +--
 34 files changed, 48 insertions(+), 24 deletions(-)

diff --git a/arch/alpha/include/asm/processor.h 
b/arch/alpha/include/asm/processor.h
index 6cb7fe8..b4cf036 100644
--- a/arch/alpha/include/asm/processor.h
+++ b/arch/alpha/include/asm/processor.h
@@ -57,6 +57,7 @@ unsigned long get_wchan(struct task_struct *p);
   ((tsk) == current ? rdusp() : task_thread_info(tsk)->pcb.usp)
 
 #define cpu_relax()barrier()
+#define cpu_relax_lowlatency() cpu_relax()
 
 #define ARCH_HAS_PREFETCH
 #define ARCH_HAS_PREFETCHW
diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h
index d99f9b3..82588f3 100644
--- a/arch/arc/include/asm/processor.h
+++ b/arch/arc/include/asm/processor.h
@@ -62,6 +62,8 @@ unsigned long thread_saved_pc(struct task_struct *t);
 #define cpu_relax()do { } while (0)
 #endif
 
+#define cpu_relax_lowlatency() cpu_relax()
+
 #define copy_segments(tsk, mm)  do { } while (0)
 #define release_segments(mm)do { } while (0)
 
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index c3d5fc1..8a1e8e9 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -82,6 +82,8 @@ unsigned long get_wchan(struct task_struct *p);
 #define cpu_relax()barrier()
 #endif
 
+#define cpu_relax_lowlatency()cpu_relax()
+
 #define task_pt_regs(p) \
((struct pt_regs *)(THREAD_START_SP + task_stack_page(p)) - 1)
 
diff --git a/arch/arm64/include/asm/processor.h 
b/arch/arm64/include/asm/processor.h
index 34de2a8..4610b0d 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -129,6 +129,7 @@ extern void release_thread(struct task_struct *);
 unsigned long get_wchan(struct task_struct *p);
 
 #define cpu_relax()barrier()
+#define cpu_relax_lowlatency()cpu_relax()
 
 /* Thread switching */
 extern struct task_struct *cpu_switch_to(struct task_struct *prev,
diff --git a/arch/avr32/include/asm/processor.h 
b/arch/avr32/include/asm/processor.h
index 972adcc..941593c 100644
--- 

Linux 3.16-rc3

[Linus Torvalds]

We're back on a Sunday release schedule, and things are looking
reasonably normal.

There's perhaps relatively less driver updates than usual, with most
of them being pretty small, but that is probably just a timing thing
(ie Greg didn't send his USB/staging changes this week, so driver
changes are mostly gpu, networking and sound).

As a result misc architecture updates (mips, powerpc, x86, arm)
dominate the diff, and there are various random other updates. We've
got filesystem updates (aio, nfs and ocfs2), a small batch of mm fixes
from Andrew, some networking stuff.etc.

The shortlog gives a feel for the changes. The most noticeable to
actual users are probably the unbreaking of direct block device read
accesses on 32-bit targets, and some x86 vdso regression fixes that
caused problems. The rest probably didn't end up affecting very many
people, but it's all proper fixes..

 Linus

---

Aaron Tomlin (2):
  nmi: provide the option to issue an NMI back trace to every cpu
but current
  kernel/watchdog.c: print traces for all cpus on lockup detection

Abhilash Kesavan (1):
  ARM: EXYNOS: fix pm code to check for cortex A9 rather than the SoC

Al Viro (1):
  Fix 32-bit regression in block device read(2)

Alex Smith (1):
  recordmcount/MIPS: Fix possible incorrect mcount_loc table
entries in modules

Alexandre Belloni (5):
  ARM: at91/dt: sam9x5: correct PLLA ICPLL and OUT values
  ARM: at91/dt: sam9n12: correct PLLA ICPLL and OUT values
  ARM: at91/dt: sam9261: correctly define mainck
  ARM: at91/dt: define sam9261ek slow crystal frequency
  ARM: at91/dt: sam9261: remove slow RC osc

Andrea Adami (2):
  ARM: 8084/1: sa1100: collie: revert back to cfi_probe
  ARM: 8085/1: sa1100: collie: add top boot mtd partition

Andrew Morton (1):
  ia64: arch/ia64/include/uapi/asm/fcntl.h needs personality.h

Andrzej Hajda (1):
  drm/exynos: disable unused windows on apply

Andrzej Zaborowski (1):
  efi-pstore: Fix an overflow on 32-bit builds

Andy Adamson (3):
  NFS check the return of nfs4_negotiate_security in nfs4_submount
  NFS Return -EPERM if no supported or matching SECINFO flavor
  NFSv4: test SECINFO RPC_AUTH_GSS pseudoflavors for support

Andy Gross (2):
  spi: qup: Fix order of spi_register_master
  spi: qup: Remove chip select function

Andy Lutomirski (9):
  x86/vdso: Discard the __bug_table section
  x86/vdso2c: Use better macros for ELF bitness
  x86/vdso: Improve the fake section headers
  x86/vdso: Remove some redundant in-memory section headers
  x86/vdso: Create .build-id links for unstripped vdso files
  x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)
  x86_32, signal: Fix vdso rt_sigreturn
  x86/vdso: Move DISABLE_BRANCH_PROFILING into the vdso makefile
  x86/vdso: Error out in vdso2c if DT_RELA is present

Anton Kolesov (1):
  ARC: Implement ptrace(PTRACE_GET_THREAD_AREA)

Arnd Bergmann (3):
  mfd: UCB1x00: Enable modular build
  mfd: STw481x: Allow modular build
  mfd: davinci: Voicecodec needs regmap_mmio

Axel Lin (1):
  hwmon: (w83l786ng) Report correct minimum fan speed

Benjamin Herrenschmidt (1):
  powerpc: Remove __arch_swab*

Benjamin LaHaise (2):
  aio: fix aio request leak when events are reaped by userspace
  aio: fix kernel memory disclosure in io_getevents() introduced in v3.10

Björn Baumbach (1):
  fs/cifs: fix regression in cifs_create_mf_symlink()

Bjørn Mork (1):
  net: huawei_cdc_ncm: increase command buffer size

Catalin Marinas (2):
  efi: Fix compiler warnings (unused, const, type)
  powerpc/kmemleak: Do not scan the DART table

Chen Gang (1):
  lib/Kconfig.debug: let FRAME_POINTER exclude SCORE, just like
exclude most of other architectures

Chew, Chiau Ee (1):
  spi/pxa2xx: fix incorrect SW mode chipselect setting for BayTrail LPSS SPI

Chin-Ran Lo (1):
  mwifiex: fix tx_info/rx_info overlap with PCIe dma_mapping

Chirantan Ekbote (1):
  clocksource: exynos_mct: Don't reset the counter during boot and resume

Chris Metcalf (1):
  net: tile: fix unused variable warning

Chris Wilson (2):
  drm/i915: Only mark the ctx as initialised after a SET_CONTEXT operation
  drm/i915: Hold the table lock whilst walking the file's idr and
counting the objects in debugfs

Christian Riesch (1):
  ptp: In the testptp utility, use clock_adjtime from glibc when available

Christoph Lameter (1):
  MAINTAINERS: SLAB maintainer update

Dan Carpenter (2):
  drm/exynos: change zero to NULL for sparse
  Documentation: add section about git to email-clients.txt

Daniel Borkmann (3):
  net: sctp: propagate sysctl errors from proc_do* properly
  net: sctp: check proc_dointvec result in proc_sctp_do_auth
  MIPS: BPF JIT: Fix build error.

Daniel Mack (3):
  net: phylib: add link_change_notify callback to phy device
  net: phy: at803x: use 

[PATCH] usb: usb3503: return correct error return on failure

[Colin King]

From: Colin Ian King 

Fix warning: drivers/usb/misc/usb3503.c:195:11: warning: 'err'
  may be used uninitialized in this function [-Wmaybe-uninitialized]

err is not initialized, the error return should be PTR_ERR(clk)

Signed-off-by: Colin Ian King 
---
 drivers/usb/misc/usb3503.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index f43c619..c0c898d 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -192,7 +192,8 @@ static int usb3503_probe(struct usb3503 *hub)
 
clk = devm_clk_get(dev, "refclk");
if (IS_ERR(clk) && PTR_ERR(clk) != -ENOENT) {
-   dev_err(dev, "unable to request refclk (%d)\n", err);
+   dev_err(dev, "unable to request refclk (%ld)\n",
+   PTR_ERR(clk));
return PTR_ERR(clk);
}
 
-- 
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: Cleanup of Kernel Bugzilla

[Theodore Ts'o]

On Sun, Jun 29, 2014 at 09:21:46AM +0200, Levente Kurusa wrote:
> 
> I think that is because they are relatively young and they are generally
> used for one direct purpose. The kernel has to make sure it works in a lot
> of different situations and hence a lot of different bugs arise.

There are a huge number of bugs which are hardware specific --- and
worse, fixing it for one hardware device can often cause problems for
others.

> >With the linux kernel not only doesn't anything exist, the project
> >itself is so bloody hard right, kernel programming, most of the
> >bugzilla bugs I can barely understand let alone even begin to deduce
> >what is going on. Now given that the list itself isn't maintained
> >makes things extremely hard.
> 
> There are still methods to extract various unresolved bugs from the
> bugzilla though. Look in any subsystem you find delicious and then
> just sort the bugs by the date they were modified. This will yield
> a list of nice fresh bugs along with some recently fixed bugs.

Or, try to find your own bugs.  Grab the development kernel, and see
if it breaks on your system.  If it does, and it was working on the
last stable kernel, then you can use "git bisect" to try to find the
point where things broke, and report the problem, and perhaps try to
figure out why it didn't work.  This can be a huge benefit for
developers who can't test their changes on every single hardware
configuration out there, so this sort of early testing of either daily
linux-next, or the mainline linux tree right after the merge window,
is a great way to learn about kernel programming.

Because of the focus on "no new regressions", testing the bleeding
edge development kernels so we can fix problems before they get
released to civilians is not only important, but often means that the
bugs that are still open are the ones which are incredibly hard to
reproduce, or which require very specialized hardware.  So it's very
likely that they won't be the bugs that are best suited for people who
are just getting started on kernel development.  Basically, for the
most part, if they were easy, they would have been fixed already.  :-)

> I brought this up as well on the Kernel Summit list. There wasn't any
> feedback on this :-), I guess there are some maintainers who care about
> bugzilla, but the rest (and the majority probably) does not care.

If you ("you" being the generic you) are someone who likes grooming
the bug tracking systems, you can certainly start to try to figure out
which bugs are no longer relevant, and then work with someone like
Alan so they can get closed out.  Over time, as you become trusted to
have good judgement over bugs, various subsystem maintainers may be
willing to give you admin bits to close bugs directly.  (And by the
way, that's something else important to note --- it's good to
specialize; the kernel is huge, so focusing on a single subsystem is a
good way to more quickly build up expertise, and for developers for
that subsystem to get to know you and to trust your judgement and your
skills.)

However, you may find that unless you're someone who tends to be a bit
obsessive-compulsive, that grooming the bugzilla doesn't really
provide much in the way of real benefit to kernel development, and so
don't provide you with much satisfaction.

After all, we don't have any direct management oversight over
developers for the upstream kernel.  So tracking things so that
policies such as "all P1 bugs must be updated every day" can be
enforced, or to keep lists of which bugs have been opened for the
longest time so that people can have long interminable meetings about
why a short-staffed team has so many bugs open, are things which are
much more applicable for pointy-haired engineering managers who can
boss engineers around and tell them to work on a particular bugs or
else they will get a bad rating at the next performance review.  But
for a volunteer project, keeping track of bugs is something that has
benefits which are much more indirect.  If as a result, you don't find
bug grooming to be very satisfying, there's no shame in moving on to
some other form of kernel contributions that *do* give you more
satisfaction.

Best regards,

- Ted
--
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: 3.15.2 build error on AMD64

[Borislav Petkov]

On Sun, Jun 29, 2014 at 10:05:29PM +0100, Nick Warne wrote:
> Thanks Boris, but unfortunately I had to trash GCC 4.2.4 to build the
> new 4.7.4 version - so I can't test the patch :(
>
> At least this issue is now on record so others will not need to go to
> penalties.

I hope so.

Btw, I thought you had that gcc 4.2.x from some distro or so. Because if
it is in some ancient distro, one could install it in kvm and test and
play with it.

Maybe I should go dig some old distro and play with it nevertheless -
issues like that tend to pop up off and on.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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: [RFA][PATCH 20/27] parisc: ftrace: Remove check of obsolete variable function_trace_stop

[Helge Deller]

Hi Steven,

On 06/26/2014 07:35 PM, Steven Rostedt wrote:
> On Thu, 26 Jun 2014 12:52:41 -0400
> Steven Rostedt  wrote:
> 
>> From: "Steven Rostedt (Red Hat)" 
>>
>> Nothing sets function_trace_stop to disable function tracing anymore.
>> Remove the check for it in the arch code.
> 
> From the cover letter, you were not Cc'd on.
> 
> Anyway, as there is no more reason to set function_trace_stop it is time
> to remove it. Unfortunately it's in several archs in assembly. Most of
> the assembly looks rather straight forward and I removed them myself.
> But I was only able to compile test them (for archs: arm64, metag, and
> microblaze I do not have my cross tools set up for them and did not
> even compile test it). But I would really love it if people can
> download their patch and test it out. You only need the patches that go
> against your arch and to really test it, also include the patch titled: 
> 
>  ftrace: Remove check for HAVE_FUNCTION_TRACE_MCOUNT_TEST
> 
> Otherwise your arch patch will call the list op that still does the
> check. That is, if you want to test suspend and resume on your arch.
> 
> As you may see, there are patches to the ftrace infrastructure that
> depend on the arch patches being implemented. I removed the
> functionality from the infrastructure, then removed it from the archs,
> and then finally removed the existence of the function_trace_stop
> variable, which would cause the archs to fail to compile if that were
> to go first.
> 
> If you can test your arch and give me your acked-by, I would appreciate
> it. Otherwise, if you need this to go through your tree, I would ask you
> to set up a dedicated branch that I can pull from to keep this order
> intact.

Sadly the arch-related tracing code in parisc is really broken.
It doesn't even compile cleanly on parisc (at least on 64bit), and as I wrote 
you in another mail
I really need to fix this soon (which I already started on).

But your patches look clean, so to get the basics right, I'm happy to give a 
Acked-by: Helge Deller 
for the two patches which affect parisc, which are:
[PATCH 08/27] parisc: ftrace: Add call to ftrace_graph_is_dead() in function 
graph code
[PATCH 20/27] parisc: ftrace: Remove check of obsolete variable 
function_trace_stop

It would be good if you can push them through your tree.
I assume your tree is: 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
with branch ftrace/next. 
Is this correct?
If yes, I can build my patches upon this tree...

Thanks!
Helge

--
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: 3.15.2 build error on AMD64

[Nick Warne]

On 29/06/14 20:44, Borislav Petkov wrote:

This then is an old(er) version of GCC issue (but I dunno what).


Right, so the error points at

__spin_lock_mb_cache_entry(struct mb_cache_entry *ce)
{
  spin_lock(bgl_lock_ptr(mb_cache_bg_lock,  <---
   (hash_64((unsigned long)ce, __builtin_log2(8);
}

somewhere here and I'd guess that old gcc is issuing some lib function
which uses SSE. And after we disabled all FPU stuff in the kernel with
b399fe355b30 ("x86: Disable generation of traditional x87 instructions")
that would issue such an error.

And I was about to point at that __builtin_log2 thing which looked
suspicious and found this by chance:

http://lkml.kernel.org/r/1401471304-37479-1-git-send-email-t...@hp.com

You could test this patch with that old gcc 4.2.x as it looks like a
good candidate for a fix for your issue.


Thanks Boris, but unfortunately I had to trash GCC 4.2.4 to build the 
new 4.7.4 version - so I can't test the patch :(


At least this issue is now on record so others will not need to go to 
penalties.


Many thanks,

Nick
--
"A bug in the code is worth two in the documentation."
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
--
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: ext4: total breakdown on USB hdd, 3.0 kernel

[Theodore Ts'o]

On Sun, Jun 29, 2014 at 10:25:16PM +0200, Pavel Machek wrote:
> 
> One more thing that I noticed: fsck notices bad checksum on inode, and
> then offers to fix the checksum with 'y' being the default. If there's
> trash in the inode, that will just induce more errors. (Including
> potentially doubly-linked blocks?) Would it make more sense to clear
> the inodes with bad checksums?

Metadata checksums aren't in e2fsprogs 1.41 or 1.42.  It will be in
the to-be-released e2fsprogs 1.43, and yes, we need to change things
so that the default answer is to zero the inode.  We didn't do that
initially because we were more suspicious of the new metadata checksum
code in the kernel and e2fsprogs than we were of hardware faults.  :-)

Cheers,

- Ted
--
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: virt_blk BUG: sleeping function called from invalid context

[Jens Axboe]

On 06/29/2014 02:47 PM, Michael S. Tsirkin wrote:
> On Sun, Jun 29, 2014 at 09:32:22PM +0200, Christoph Hellwig wrote:
>> On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote:
>>> On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote:
 Hi All,

 We've had a report[1] of the virt_blk driver causing a lot of spew
 because it's calling a sleeping function from an invalid context.  The
 backtrace is below.  This is with kernel v3.16-rc2-69-gd91d66e88ea9.
>>>
>>> Hi Jens, pls see below - it looks like the call to blk_mq_end_io
>>> from IRQ context is causing the issue.
>>> IIUC you switched virtio to this from __blk_end_request_all in
>>>
>>> commit 1cf7e9c68fe84248174e998922b39e508375e7c1
>>> virtio_blk: blk-mq support
>>>
>>> Is this always safe?
>>> I note that at least one other driver is doing this:
>>> drivers/block/mtip32xx/mtip32xx.c
>>
>> Just like __blk_end_request_all blk_mq_end_io is supposed to be called
>> from irq context.  The problem is that the MD bio end_io handler is calling
>> a sleeping function.  Not sure if that's a bug in MD though given the
>> kernfs symbols in the all trace and the recent churn in that area.
> 
> My understanding is this:
> 
> bitmap_endwrite -> calls sysfs_notify_dirent_safe under spinlock
>  -> calls kernfs_notify which takes a mutex.
> 
> So I am guessing it is this commit:
> 
> commit d911d98748018f7c8facc035ba39c30f5cce6f9c
> Author: Tejun Heo 
> Date:   Wed Apr 9 11:07:31 2014 -0400
> 
> kernfs: make kernfs_notify() trigger inotify events too
> 
> Tejun, what do you think?
> 
> Josh, Brian, could you try reverting that commit to see if it helps?

That definitely be a bug. If you need to block off ->bi_end_io(), just
must punt to a worker thread.

-- 
Jens Axboe

--
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 0/1] ARM: dts: zynq: Prepare Parallella

[Andreas Färber]

Hello,

This patch adds an initial device tree for the Parallella board.
UART, SD card, Ethernet are enabled.
Not yet enabled are HDMI (FPGA, ADV7513), QSPI and 2x USB.

Where I'm a bit unsure is the PHY placement; placement as subnode of the 
GEM corresponds to what was in the downstream 3.12 based device tree. It 
is a separate chip on the board though, whereas GEM is on the SoC.

Regards,
Andreas

Andreas Färber (1):
  ARM: dts: zynq: Add Parallella device tree

 arch/arm/boot/dts/Makefile|  4 ++-
 arch/arm/boot/dts/zynq-parallella.dts | 63 +++
 2 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/zynq-parallella.dts

-- 
1.9.3

--
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/1] ARM: dts: zynq: Add Parallella device tree

[Andreas Färber]

This allows to boot the Adapteva Parallella board to serial console.

Cc: Andreas Olofsson 
Signed-off-by: Andreas Färber 
---
 arch/arm/boot/dts/Makefile|  4 ++-
 arch/arm/boot/dts/zynq-parallella.dts | 63 +++
 2 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/zynq-parallella.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5986ff6..2a536f6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -419,7 +419,9 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
wm8650-mid.dtb \
wm8750-apc8750.dtb \
wm8850-w70v2.dtb
-dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
+dtb-$(CONFIG_ARCH_ZYNQ) += \
+   zynq-parallella.dtb \
+   zynq-zc702.dtb \
zynq-zc706.dtb \
zynq-zed.dtb
 dtb-$(CONFIG_MACH_ARMADA_370) += \
diff --git a/arch/arm/boot/dts/zynq-parallella.dts 
b/arch/arm/boot/dts/zynq-parallella.dts
new file mode 100644
index 000..98df66c
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -0,0 +1,63 @@
+/*
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * Derived from zynq-zed.dts:
+ *
+ *  Copyright (C) 2011 Xilinx
+ *  Copyright (C) 2012 National Instruments Corp.
+ *  Copyright (C) 2013 Xilinx
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+/dts-v1/;
+/include/ "zynq-7000.dtsi"
+
+/ {
+   model = "Parallella Board";
+   compatible = "xlnx,zynq-7000";
+
+   memory {
+   device_type = "memory";
+   reg = <0 0x2000>;
+   };
+
+   chosen {
+   bootargs = "console=ttyPS0,115200 earlyprintk 
root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait";
+   };
+};
+
+ {
+   status = "okay";
+   phy-mode = "rgmii-id";
+   phy-handle = <_phy>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ethernet_phy: ethernet-phy@0 {
+   /* Marvell 88E1318 */
+   compatible = "ethernet-phy-id0141.0e90",
+"ethernet-phy-ieee802.3-c22";
+   reg = <0>;
+   marvell,reg-init = <0x3 0x10 0xff00 0x1e>,
+  <0x3 0x11 0xfff0 0xa>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
1.9.3

--
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: virt_blk BUG: sleeping function called from invalid context

[Michael S. Tsirkin]

On Sun, Jun 29, 2014 at 09:32:22PM +0200, Christoph Hellwig wrote:
> On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote:
> > On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote:
> > > Hi All,
> > > 
> > > We've had a report[1] of the virt_blk driver causing a lot of spew
> > > because it's calling a sleeping function from an invalid context.  The
> > > backtrace is below.  This is with kernel v3.16-rc2-69-gd91d66e88ea9.
> > 
> > Hi Jens, pls see below - it looks like the call to blk_mq_end_io
> > from IRQ context is causing the issue.
> > IIUC you switched virtio to this from __blk_end_request_all in
> > 
> > commit 1cf7e9c68fe84248174e998922b39e508375e7c1
> > virtio_blk: blk-mq support
> > 
> > Is this always safe?
> > I note that at least one other driver is doing this:
> > drivers/block/mtip32xx/mtip32xx.c
> 
> Just like __blk_end_request_all blk_mq_end_io is supposed to be called
> from irq context.  The problem is that the MD bio end_io handler is calling
> a sleeping function.  Not sure if that's a bug in MD though given the
> kernfs symbols in the all trace and the recent churn in that area.

My understanding is this:

bitmap_endwrite -> calls sysfs_notify_dirent_safe under spinlock
 -> calls kernfs_notify which takes a mutex.

So I am guessing it is this commit:

commit d911d98748018f7c8facc035ba39c30f5cce6f9c
Author: Tejun Heo 
Date:   Wed Apr 9 11:07:31 2014 -0400

kernfs: make kernfs_notify() trigger inotify events too

Tejun, what do you think?

Josh, Brian, could you try reverting that commit to see if it helps?

-- 
MST
--
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: [BUG] User process tainting in linux-next tree

[Borislav Petkov]

Hi,

first of all, please do not top-post. Here's why:

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

> Yes booted by increase the buffer length, but the ignore_loglevel is
> running continously for 5 minutes.

Huh, what? I can't parse that sentence above.

ignore_loglevel is another kernel cmdline parameter:

ignore_loglevel [KNL]
Ignore loglevel setting - this will print /all/
kernel messages to the console. Useful for debugging.
We also add it as printk module parameter, so users
could change it dynamically, usually by
/sys/module/printk/parameters/ignore_loglevel.


> So I ignored that and ran with
> log_buf_len=500M ( because 10M also filled) only.
> 
> When I copied the dmesg, the size was 76M, so I attached only first
> 1500 lines. Please find in below link.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=79171

Ok, that's better. The warnings start spewing pretty early with the one
below. Let's CC linux-mm.

[1.062658] registered taskstats version 1
[1.063400] [ cut here ]
[1.063455] WARNING: CPU: 0 PID: 55 at kernel/res_counter.c:28 
res_counter_uncharge_until+0x84/0x110()
[1.063513] Modules linked in:
[1.063516] CPU: 0 PID: 55 Comm: modprobe Not tainted 
3.16.0-rc1-next-20140620+ #4
[1.063518] Hardware name: Dell Inc. Studio 1555/0C234M, BIOS A11 03/29/2010
[1.063520]    d34d7de4 c1648de3  d34d7e14 c105b74e 
c1822e40
[1.063524]   0037 c183384f 001c c10dab24 c10dab24 d3c048c8 

[1.063529]   d34d7e24 c105b812 0009  d34d7e58 c10dab24 
0282
[1.063534] Call Trace:
[1.063538]  [] dump_stack+0x41/0x52
[1.063541]  [] warn_slowpath_common+0x7e/0xa0
[1.063543]  [] ? res_counter_uncharge_until+0x84/0x110
[1.063546]  [] ? res_counter_uncharge_until+0x84/0x110
[1.063548]  [] warn_slowpath_null+0x22/0x30
[1.063551]  [] res_counter_uncharge_until+0x84/0x110
[1.063553]  [] res_counter_uncharge+0x11/0x20
[1.063557]  [] mem_cgroup_uncharge_end+0x85/0xa0
[1.063560]  [] release_pages+0x71/0x1c0
[1.063563]  [] free_pages_and_swap_cache+0x92/0xb0
[1.063567]  [] tlb_flush_mmu_free+0x23/0x40
[1.063570]  [] tlb_flush_mmu+0x1d/0x30
[1.063572]  [] tlb_finish_mmu+0x11/0x40
[1.063575]  [] unmap_region+0x97/0xc0
[1.063577]  [] ? vma_rb_erase+0xe2/0x1b0
[1.063580]  [] do_munmap+0x1c3/0x2d0
[1.063582]  [] vm_munmap+0x37/0x50
[1.063584]  [] SyS_munmap+0x20/0x30
[1.063588]  [] sysenter_do_call+0x12/0x28
[1.063590] ---[ end trace 812035dd9a004e6c ]---

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] vt: disable console blanking by default

[Pavel Machek]

On Wed 2014-06-25 13:41:09, Tomasz Torcz wrote:
> On Sun, Jun 22, 2014 at 06:37:29PM +0200, Pavel Machek wrote:
> > On Wed 2014-06-18 11:27:31, Tomasz Torcz wrote:
> > > 
> > > >From ea7cf47e3230eda63aa6c46092719437f9bbae8e Mon Sep 17 00:00:00 2001
> > > From: Tomasz Torcz 
> > > Date: Wed, 18 Jun 2014 11:18:06 +0200
> > > Subject: [PATCH] vt: disable console blanking by default
> > > 
> > >   Remove default 10 minute blank interval. Instead: never blank by
> > >   default.
> > >   "Screensaving" is no longer useful.  Today it only provides
> > >   obstacle when interacting with text console, especially through
> > >   remote lights-out management solutions.
> > > 
> > > Signed-off-by: Tomasz Torcz 
> > 
> > Dunno. You'll kill an LCD if you let same image there for too
> > long. Make it 10hours?
> 
>   There is no practical difference between 10 minutes and 10 hours.  Both
> are more than none.  This means that If I need to access console, it
> will probably be blanked.  For some servers, console access is needed
> less than once per year, if ever.  But IF the console need to be accessed,
> there's a strong reason to it (some kind of fault), and having to press
> anything to unblank may be invasive.
> 
>  I would prefer to fix the issue at the source, instead of sticking 
> "consoleblank=0"
> in grub2.cfg on houndreds of boxes.  BTW, kernel already contains 
> "consoleblank=0" in 
> arch/arc/boot/dts/nsimosci.dts and arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
> 
>   Is LCD damage for currently produced LCDs real issue, still?

Probably yes. Plus, people are still running CRTs and blanked screen
still eats significantly less power. So "consoleblank=0" seems right
solution for you, and current default still sounds right.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: [BUG] User process tainting in linux-next tree

[Jeshwanth Kumar N K]

Hello Borislav,

Yes booted by increase the buffer length, but the ignore_loglevel is
running continously for 5 minutes. So I ignored that and ran with
log_buf_len=500M ( because 10M also filled) only.

When I copied the dmesg, the size was 76M, so I attached only first
1500 lines. Please find in below link.

https://bugzilla.kernel.org/show_bug.cgi?id=79171


On Mon, Jun 30, 2014 at 12:42 AM, Borislav Petkov  wrote:
> On Sun, Jun 29, 2014 at 11:48:02PM +0530, Jeshwanth Kumar N K wrote:
>> Hello,
>>
>>  I have created a bug in bugzilla
>> https://bugzilla.kernel.org/show_bug.cgi?id=79171 , The native built
>> Linux-next kernel is giving tainted Error. Can you please give me a
>> pointer to solve this?
>
> All those dmesg log files you've uploaded are incomplete and truncated
> from the beginning and we want to see them from the beginning because
> there is the first warning which is almost always the most important
> one.
>
> For that, boot your kernel with "log_buf_len=10M ignore_loglevel" and
> then collect full dmesg by doing
>
> dmesg > dmesg.log
>
> which you can then upload to the bugzilla again.
>
> Also, please try a newer linux-next tree or Linus' tree.
>
> HTH.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --



-- 
Regards
Jeshwanth Kumar N K
Bangalore, India
--
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: ext4: total breakdown on USB hdd, 3.0 kernel

[Pavel Machek]

Hi!

> > It looks like the filesystem contains _way_ too many 0x's:
> 
> That sounds like it's a hardware issue.  It may be that the controller
> did something insane while trying to do a write at the point when the
> disk drive was disconnected (and so the drive suffered a power
> drop).

Interesting. I tried to compare damaged image with the original, and
yes, way too many 0x. But they are not even block aligned? And
they start from byte 0... that area is not normally written, IIRC?

000        
*
030  07ff      
040        
*
3f0        
400       3e28 002d
410 fd57 000c      
420        
*
550        
560        
570     4ddb 0055  
580        
590   007e     
5a0        
*
5c0       682e 53ac
5d0 3a29 000a 0515  d144 002e  
5e0 7865 3474 6d5f 7061 625f 6f6c 6b63 0073
5f0        
600        
*
0001000 41c0 03e9 1000  6133 53ac 6133 53ac

> > And for every bug in kernel, there's one in fsck: I did not expect it, but 
> > fsck actually
> > suceeded, and marked fs as clean. But second fsck had issues with   
> > /lost+found...
>  
> I'd need the previous fsck transcript to have any idea what might have
> happened.  I'll note though you are using an ancient version of e2fsck
> (1.41.12, and there have been a huge number of bug fixes since
> May 2010)

Sorry for picking at fsck. No, it did quite a good job given
circumstances... and it probably does not make sense to debug old
version.

One more thing that I noticed: fsck notices bad checksum on inode, and
then offers to fix the checksum with 'y' being the default. If there's
trash in the inode, that will just induce more errors. (Including
potentially doubly-linked blocks?) Would it make more sense to clear
the inodes with bad checksums?

Thanks and best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] FIXME of file toploogy.h for alpha cpus

[Sasha Levin]

On 06/28/2014 11:03 PM, Nick Krause wrote:
> I thought I compiled tested it maybe not. I thought M= would work for
> alpha directory but maybe I have to enable in on x86.
> I don't known if there is a way to do this.
> Cheers Nick
> 
> On Sat, Jun 28, 2014 at 3:53 PM, Sasha Levin  wrote:
>> On 06/28/2014 12:07 AM, Nicholas Krause wrote:
>>> This patch fixs the FIXME message in the function *cpumask_of_node
>>> for using this function multiple times and the issue with recaluting
>>> the cpu node mask when reusing this function.
>>>
>>> Signed-off-by: Nicholas Krause 
>>> ---
>>>  arch/alpha/include/asm/topology.h | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/arch/alpha/include/asm/topology.h 
>>> b/arch/alpha/include/asm/topology.h
>>> index 9251e13..d301f66 100644
>>> --- a/arch/alpha/include/asm/topology.h
>>> +++ b/arch/alpha/include/asm/topology.h
>>> @@ -31,6 +31,9 @@ static const struct cpumask *cpumask_of_node(int node)
>>>   if (node == -1)
>>>   return cpu_all_mask;
>>>
>>> + else if (node == _to_cpumask_map[node])
>>> + return _to_cpumask_map[node];
>>> +
>>>   cpumask_clear(_to_cpumask_map[node]);
>>>
>>>   for_each_online_cpu(cpu) {
>>>
>>
>> Since this patch doesn't even compile, care to tell us how you tested it?
>>
>>
>> Thanks,
>> Sasha

Please stop top posting.

Your explanation is missing the part about actually making sure that your patch
works is missing, how did you intend to make sure that your patch doesn't
break things?


Thanks,
Sasha
--
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: 3d3d6b847420 ("kbuild: LLVMLinux: Adapt warnings for compilation with clang")

[Borislav Petkov]

Hi,

On Mon, Jun 16, 2014 at 05:48:01PM +0200, Jan-Simon Möller wrote:
> Ok, let's wrap this case with 
> 
> ifeq ($(COMPILER),clang)
> ...
> endif
> 
> And we'll update the stale entries.
> 
> Patch to follow after some testing.

any progress with the testing or should we simply revert?

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] CMA page migration failure due to buffers on bh_lru

[Laura Abbott]

(cc-ing Hugh since he had comments on the patch before)

On 6/26/2014 4:23 PM, Gioh Kim wrote:
> 
> 
> 2014-06-27 오전 12:57, Michal Nazarewicz 쓴 글:
>> On Tue, Jun 24 2014, Gioh Kim  wrote:
>>> Hello,
>>>
>>> I am trying to apply CMA feature for my platform.
>>> My kernel version, 3.10.x, is not allocating memory from CMA area so that I 
>>> applied
>>> a Joonsoo Kim's patch (https://lkml.org/lkml/2014/5/28/64).
>>> Now my platform can use CMA area effectively.
>>>
>>> But I have many failures to allocate memory from CMA area.
>>> I found the same situation to Laura Abbott's patch descrbing,
>>> https://lkml.org/lkml/2012/8/31/313,
>>> that releases buffer-heads attached at CPU's LRU list.
>>>
>>> If Joonsoo's patch is applied and/or CMA feature is applied more and more,
>>> buffer-heads problem is going to be serious definitely.
>>>
>>> Please look into the Laura's patch again.
>>> I think it must be applied with Joonsoo's patch.
>>
>> Just to make sure I understood you correctly, you're saying Laura's
>> patch at  fixes your issue?
>>
> 
> Yes, it is.

I submitted this before and it was suggested that this was more
related to filesystems

http://marc.info/?l=linaro-mm-sig=137645770708817=2

I never saw more discussion and pushed this into the 'CMA hacks' pile. 
So far we've been keeping the patch out of tree and it's useful to know
that others have found the same problem. I'm willing to resubmit the
patch for further discussion.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: [crypto] BUG: unable to handle kernel paging request at ffff88000bb88000

[Stephan Mueller]

Am Sonntag, 29. Juni 2014, 22:52:46 schrieb Fengguang Wu:

Hi Fengguang,

> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is

May I ask whether there is anything special in your kernel config?

This very bug should have been triggered already in all previous code levels! 
I am seriously wondering why this bug was not triggered before -- does kalloc 
somehow allocates more memory than you requested? And only your specific 
kernel config made kalloc to allocate the exact amount of memory that was 
requested?

The background can be summarized by the following: the scratchpad->temp buffer 
(i.e. the memory location immediately before the tfm variable upon which the 
kernel crashed) is the buffer that the BCC function operates on. BCC operates 
blockwise. drbg_statelen(drbg) is sufficient when the DRBG state length is a 
multiple of the block size. For AES192 (and maybe other ciphers) this is not 
correct and the length for temp is insufficient (yes, that also means for such 
ciphers, the final output of all BCC rounds are truncated before used to 
update the state of the DRBG!!).

The DRBG code that triggered the bug defined the buffer to be drbg_statelen() 
in size. As described, the bug therefore triggered with the AES192 cipher. The 
patch is simply to enlarge the buffer by blocklen. This ensures that we have 
no memory corruption.

An official patch is created and released shortly.

More and more I look into and work with SP800-90A, I feel that at least the 
CTR DRBG and to a lesser degree the Hash DRBG have severe shortcomings. 
Throwing away information derived from the seed by the aforementioned 
truncation is definitely not wise. This truncation is in addition to other 
very odd operations on the seed definitely result in a loss of entropy IMHO.

Though, thanks a lot for the bug report and your testing.

-- 
Ciao
Stephan
--
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: 3.15.2 build error on AMD64

[Borislav Petkov]

On Sun, Jun 29, 2014 at 08:06:36PM +0100, Nick Warne wrote:
> OK, I just spent three months building GCC 4.7.4 today (thank god the
> world cup is on to watch instead)

Yep, the world cup helps a lot with tedious debugging work. :-)

> and 3.15.2 built fine, and server is up and
> running great.
> 
> This then is an old(er) version of GCC issue (but I dunno what).

Right, so the error points at 

__spin_lock_mb_cache_entry(struct mb_cache_entry *ce)
{
 spin_lock(bgl_lock_ptr(mb_cache_bg_lock,   <---
  (hash_64((unsigned long)ce, __builtin_log2(8);
}

somewhere here and I'd guess that old gcc is issuing some lib function
which uses SSE. And after we disabled all FPU stuff in the kernel with
b399fe355b30 ("x86: Disable generation of traditional x87 instructions")
that would issue such an error.

And I was about to point at that __builtin_log2 thing which looked
suspicious and found this by chance:

http://lkml.kernel.org/r/1401471304-37479-1-git-send-email-t...@hp.com

You could test this patch with that old gcc 4.2.x as it looks like a
good candidate for a fix for your issue.

:-)

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
-- 
--
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: [PATCHv3 2/5] lib/genalloc.c: Add genpool range check function

[Laura Abbott]

On 6/20/2014 2:38 AM, Will Deacon wrote:
> On Tue, Jun 17, 2014 at 02:39:22AM +0100, Laura Abbott wrote:
>> After allocating an address from a particular genpool,
>> there is no good way to verify if that address actually
>> belongs to a genpool. Introduce addr_in_gen_pool which
>> will return if an address plus size falls completely
>> within the genpool range.
>>
>> Signed-off-by: Laura Abbott 
>> ---
>>  include/linux/genalloc.h |  3 +++
>>  lib/genalloc.c   | 29 +
>>  2 files changed, 32 insertions(+)
>>
>> diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
>> index 3cd0934..1ccaab4 100644
>> --- a/include/linux/genalloc.h
>> +++ b/include/linux/genalloc.h
>> @@ -121,6 +121,9 @@ extern struct gen_pool *devm_gen_pool_create(struct 
>> device *dev,
>>  int min_alloc_order, int nid);
>>  extern struct gen_pool *dev_get_gen_pool(struct device *dev);
>>  
>> +bool addr_in_gen_pool(struct gen_pool *pool, unsigned long start,
>> +size_t size);
>> +
>>  #ifdef CONFIG_OF
>>  extern struct gen_pool *of_get_named_gen_pool(struct device_node *np,
>>  const char *propname, int index);
>> diff --git a/lib/genalloc.c b/lib/genalloc.c
>> index 9758529..66edf93 100644
>> --- a/lib/genalloc.c
>> +++ b/lib/genalloc.c
>> @@ -403,6 +403,35 @@ void gen_pool_for_each_chunk(struct gen_pool *pool,
>>  EXPORT_SYMBOL(gen_pool_for_each_chunk);
>>  
>>  /**
>> + * addr_in_gen_pool - checks if an address falls within the range of a pool
>> + * @pool:   the generic memory pool
>> + * @start:  start address
>> + * @size:   size of the region
>> + *
>> + * Check if the range of addresses falls within the specified pool. Takes
>> + * the rcu_read_lock for the duration of the check.
>> + */
>> +bool addr_in_gen_pool(struct gen_pool *pool, unsigned long start,
>> +size_t size)
>> +{
>> +bool found = false;
>> +unsigned long end = start + size;
>> +struct gen_pool_chunk *chunk;
>> +
>> +rcu_read_lock();
>> +list_for_each_entry_rcu(chunk, &(pool)->chunks, next_chunk) {
>> +if (start >= chunk->start_addr && start <= chunk->end_addr) {
> 
> Why do you need to check start against the end of the chunk? Is that in case
> of overflow?
> 

Yes, this provides an extra check for overflow and also matches similar logic 
for
gen_pool_virt_to_phys.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: [PATCHv3 1/5] lib/genalloc.c: Add power aligned algorithm

[Laura Abbott]

On 6/20/2014 2:33 AM, Will Deacon wrote:
> Hi Laura,
> 
> On Tue, Jun 17, 2014 at 02:39:21AM +0100, Laura Abbott wrote:
>> One of the more common algorithms used for allocation
>> is to align the start address of the allocation to
>> the order of size requested. Add this as an algorithm
>> option for genalloc.
> 
> Good idea, I didn't know this even existed!
> 
>> Signed-off-by: Laura Abbott 
>> ---
>>  include/linux/genalloc.h |  4 
>>  lib/genalloc.c   | 21 +
>>  2 files changed, 25 insertions(+)
>>
>> diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
>> index 1c2fdaa..3cd0934 100644
>> --- a/include/linux/genalloc.h
>> +++ b/include/linux/genalloc.h
>> @@ -110,6 +110,10 @@ extern void gen_pool_set_algo(struct gen_pool *pool, 
>> genpool_algo_t algo,
>>  extern unsigned long gen_pool_first_fit(unsigned long *map, unsigned long 
>> size,
>>  unsigned long start, unsigned int nr, void *data);
>>  
>> +extern unsigned long gen_pool_first_fit_order_align(unsigned long *map,
>> +unsigned long size, unsigned long start, unsigned int nr,
>> +void *data);
>> +
>>  extern unsigned long gen_pool_best_fit(unsigned long *map, unsigned long 
>> size,
>>  unsigned long start, unsigned int nr, void *data);
>>  
>> diff --git a/lib/genalloc.c b/lib/genalloc.c
>> index bdb9a45..9758529 100644
>> --- a/lib/genalloc.c
>> +++ b/lib/genalloc.c
>> @@ -481,6 +481,27 @@ unsigned long gen_pool_first_fit(unsigned long *map, 
>> unsigned long size,
>>  EXPORT_SYMBOL(gen_pool_first_fit);
>>  
>>  /**
>> + * gen_pool_first_fit_order_align - find the first available region
>> + * of memory matching the size requirement. The region will be aligned
>> + * to the order of the size specified.
>> + * @map: The address to base the search on
>> + * @size: The bitmap size in bits
>> + * @start: The bitnumber to start searching at
>> + * @nr: The number of zeroed bits we're looking for
>> + * @data: additional data - unused
> 
> It doesn't look unused to me.
> 
>> + */
>> +unsigned long gen_pool_first_fit_order_align(unsigned long *map,
>> +unsigned long size, unsigned long start,
>> +unsigned int nr, void *data)
>> +{
>> +unsigned long order = (unsigned long) data;
>> +unsigned long align_mask = (1 << get_order(nr << order)) - 1;
> 
> Why isn't the order just order?
> 

I did some bad math somewhere. All we really need is 

unsigned long align_mask = roundup_pow_of_two(nr) - 1;

Which means the data would actually be unused. I'll fix it in the next
version.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: virt_blk BUG: sleeping function called from invalid context

[Christoph Hellwig]

On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote:
> > Hi All,
> > 
> > We've had a report[1] of the virt_blk driver causing a lot of spew
> > because it's calling a sleeping function from an invalid context.  The
> > backtrace is below.  This is with kernel v3.16-rc2-69-gd91d66e88ea9.
> 
> Hi Jens, pls see below - it looks like the call to blk_mq_end_io
> from IRQ context is causing the issue.
> IIUC you switched virtio to this from __blk_end_request_all in
> 
> commit 1cf7e9c68fe84248174e998922b39e508375e7c1
> virtio_blk: blk-mq support
> 
> Is this always safe?
> I note that at least one other driver is doing this:
> drivers/block/mtip32xx/mtip32xx.c

Just like __blk_end_request_all blk_mq_end_io is supposed to be called
from irq context.  The problem is that the MD bio end_io handler is calling
a sleeping function.  Not sure if that's a bug in MD though given the
kernfs symbols in the all trace and the recent churn in that area.

--
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 1/1] staging: media: msi3101: sdr-msi3101.c - replace with time_before_eq()

[Antti Palosaari]

Moikka!
That is already fixed by someone else and patch is somewhere Mauro or 
Hans queue.


regards
Antti

On 06/29/2014 08:20 AM, Anil Belur wrote:

From: Anil Belur 

- this fix replaces jiffies interval comparision with safer function to
   avoid any overflow and wrap around ?

Signed-off-by: Anil Belur 
---
  drivers/staging/media/msi3101/sdr-msi3101.c | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/msi3101/sdr-msi3101.c 
b/drivers/staging/media/msi3101/sdr-msi3101.c
index 08d0d09..b828857 100644
--- a/drivers/staging/media/msi3101/sdr-msi3101.c
+++ b/drivers/staging/media/msi3101/sdr-msi3101.c
@@ -180,6 +180,7 @@ static int msi3101_convert_stream_504(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -208,7 +209,8 @@ static int msi3101_convert_stream_504(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   expires = s->jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
@@ -332,6 +334,7 @@ static int msi3101_convert_stream_384(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -360,7 +363,8 @@ static int msi3101_convert_stream_384(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   expires = s->jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
@@ -397,6 +401,7 @@ static int msi3101_convert_stream_336(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -425,7 +430,8 @@ static int msi3101_convert_stream_336(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   expires = s->jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
@@ -460,6 +466,7 @@ static int msi3101_convert_stream_252(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -488,7 +495,8 @@ static int msi3101_convert_stream_252(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   expires = s->jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;



--
http://palosaari.fi/
--
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: [BUG] User process tainting in linux-next tree

[Borislav Petkov]

On Sun, Jun 29, 2014 at 11:48:02PM +0530, Jeshwanth Kumar N K wrote:
> Hello,
> 
>  I have created a bug in bugzilla
> https://bugzilla.kernel.org/show_bug.cgi?id=79171 , The native built
> Linux-next kernel is giving tainted Error. Can you please give me a
> pointer to solve this?

All those dmesg log files you've uploaded are incomplete and truncated
from the beginning and we want to see them from the beginning because
there is the first warning which is almost always the most important
one.

For that, boot your kernel with "log_buf_len=10M ignore_loglevel" and
then collect full dmesg by doing

dmesg > dmesg.log

which you can then upload to the bugzilla again.

Also, please try a newer linux-next tree or Linus' tree.

HTH.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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: 3.15.2 build error on AMD64

[Nick Warne]

On 28/06/14 14:09, Nick Warne wrote:



On 28/06/14 13:23, Borislav Petkov wrote:

On Sat, Jun 28, 2014 at 11:55:07AM +0100, Nick Warne wrote:

Whoops - that is WRONG (too many ssh terminals)

gcc version 4.2.4


That's some old compiler. Anyway, I can't trigger it here with gcc 4.6
and 4.9.

Can you do

$ make clean
$ make V=1 fs/mbcache.i >>w.log 2>&1
$ make V=1 fs/mbcache.s >>w.log 2>&1

and zip and send me fs/mbcache.i, fs/mbcache.s and w.log.


OK, fs/mbcache.s didn't appear.

logs attached.


OK, I just spent three months building GCC 4.7.4 today (thank god the 
world cup is on to watch instead) and 3.15.2 built fine, and server is 
up and running great.


This then is an old(er) version of GCC issue (but I dunno what).

Sorry for the noise and thanks.

Nick
--
"A bug in the code is worth two in the documentation."
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
--
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 2/2] lib.c: skip --param parameters

[Christopher Li]

On Sun, Jun 29, 2014 at 12:19 AM, Christopher Li  wrote:
>
> If no objections, I will push the change.
>

Change pushed.

Chris
--
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] HID: roccat: Drop cast

[Joe Perches]

On Sun, 2014-06-29 at 18:34 +0200, Julia Lawall wrote:
> On Thu, 26 Jun 2014, Joe Perches wrote:
> > void func(const void * const p)
> > {
> > char *p2 = p;
> > 
> > p2[0] = 1;
> > }
> 
> Is this a real example?

No, it's not.

I think I've seen code in the kernel like
char *p2 = (void *)p;
where p is const and p2 is dereferenced and set.


--
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/