[PATCH] gpiolib: fix warning about iterator

[Sudip Mukherjee]

We were getting build warning about "iterator" being used uninitialized.
Use iterator properly to fix the build warning and in the process remove
the variable "pos" which is not required now.

Signed-off-by: Sudip Mukherjee 
---
 drivers/gpio/gpiolib.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d72ac1f..3619ce4 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -189,23 +189,21 @@ EXPORT_SYMBOL_GPL(gpiod_get_direction);
  */
 static int gpiochip_add_to_list(struct gpio_chip *chip)
 {
-   struct list_head *pos;
struct gpio_chip *iterator;
struct gpio_chip *previous = NULL;
 
if (list_empty(_chips)) {
-   pos = gpio_chips.next;
-   goto found;
+   list_add_tail(>list, _chips);
+   return 0;
}
 
-   list_for_each(pos, _chips) {
-   iterator = list_entry(pos, struct gpio_chip, list);
+   list_for_each_entry(iterator, _chips, list) {
if (iterator->base >= chip->base + chip->ngpio) {
/*
 * Iterator is the first GPIO chip so there is no
 * previous one
 */
-   if (previous == NULL) {
+   if (!previous) {
goto found;
} else {
/*
@@ -230,7 +228,7 @@ static int gpiochip_add_to_list(struct gpio_chip *chip)
return -EBUSY;
 
 found:
-   list_add_tail(>list, pos);
+   list_add_tail(>list, >list);
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/

Re: [PATCH v2] i2c-core: One function call less in acpi_i2c_space_handler() after error detection

[Wolfram Sang]

> The kfree() function was called in one case by the
> acpi_i2c_space_handler() function during error handling
> even if the passed variable "client" contained a null pointer.

This is OK. kfree() is known to be NULL-tolerant and we rely on it in
various places to keep the code simpler.



signature.asc
Description: PGP signature

[PATCH v2] i2c-core: One function call less in acpi_i2c_space_handler() after error detection

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 26 Dec 2015 08:00:52 +0100

The kfree() function was called in one case by the
acpi_i2c_space_handler() function during error handling
even if the passed variable "client" contained a null pointer.

Implementation details could be improved by the adjustment of jump targets
according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/i2c/i2c-core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 7349b00..9996531 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -313,18 +313,18 @@ acpi_i2c_space_handler(u32 function, 
acpi_physical_address command,
client = kzalloc(sizeof(*client), GFP_KERNEL);
if (!client) {
ret = AE_NO_MEMORY;
-   goto err;
+   goto free_ares;
}
 
if (!value64 || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS) {
ret = AE_BAD_PARAMETER;
-   goto err;
+   goto free_client;
}
 
sb = >data.i2c_serial_bus;
if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C) {
ret = AE_BAD_PARAMETER;
-   goto err;
+   goto free_client;
}
 
client->adapter = adapter;
@@ -401,13 +401,13 @@ acpi_i2c_space_handler(u32 function, 
acpi_physical_address command,
default:
pr_info("protocol(0x%02x) is not supported.\n", accessor_type);
ret = AE_BAD_PARAMETER;
-   goto err;
+   goto free_client;
}
 
gsb->status = status;
-
- err:
+free_client:
kfree(client);
+free_ares:
ACPI_FREE(ares);
return ret;
 }
-- 
2.6.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/

[GIT PULL] ARC fixes for 4.4-rc7

[Vineet Gupta]

Hi Linus,

Sorry for this late pull request, but these are all important fixes for code
introduced/updated in this release which we will otherwise end up back porting.

Please pull and wish you happy holidays !

Thx,
-Vineet
--->
The following changes since commit 4ef7675344d687a0ef5b0d7c0cee12da005870c0:

  Linux 4.4-rc6 (2015-12-20 16:06:09 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ 
tags/arc-4.4-rc7-fixes

for you to fetch changes up to 6b538db7c6b091960c57b23feae5431fc82286e7:

  ARC: dw2 unwind: Catch Dwarf SNAFUs early (2015-12-21 14:01:49 +0530)


ARC fixes for
 - Unwinder rework (A revert followed by better fix)
 - Build errors: MMUv2, modules with -Os
 - highmem section mismatch build splat


Alexey Brodkin (1):
  ARC: mm: fix building for MMU v2

Vineet Gupta (5):
  ARC: mm: HIGHMEM: Fix section mismatch splat
  ARC: Fix linking errors with CONFIG_MODULE + CONFIG_CC_OPTIMIZE_FOR_SIZE
  Revert "ARC: dw2 unwind: Ignore CIE version !=1 gracefully instead of 
bailing"
  ARC: dw2 unwind: Don't bail for CIE.version != 1
  ARC: dw2 unwind: Catch Dwarf SNAFUs early

 arch/arc/Makefile|  2 +-
 arch/arc/include/asm/cache.h |  2 --
 arch/arc/kernel/unwind.c | 28 +++-
 arch/arc/mm/highmem.c|  4 ++--
 4 files changed, 14 insertions(+), 22 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] i2c-core: One function call less in acpi_i2c_space_handler() after error detection

[kbuild test robot]

[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]
Hi Markus,

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.4-rc6 next-20151223]

url:
https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/i2c-core-One-function-call-less-in-acpi_i2c_space_handler-after-error-detection/20151226-143820
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux i2c/for-next
config: x86_64-randconfig-x010-12251849 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/i2c/i2c-core.c: In function 'acpi_i2c_space_handler':
>> drivers/i2c/i2c-core.c:404:3: error: label 'err' used but not defined
  goto err;
  ^

vim +/err +404 drivers/i2c/i2c-core.c

17f4a5c4 Wolfram Sang 2014-09-22  398   }
17f4a5c4 Wolfram Sang 2014-09-22  399   break;
17f4a5c4 Wolfram Sang 2014-09-22  400  
17f4a5c4 Wolfram Sang 2014-09-22  401   default:
17f4a5c4 Wolfram Sang 2014-09-22  402   pr_info("protocol(0x%02x) is 
not supported.\n", accessor_type);
17f4a5c4 Wolfram Sang 2014-09-22  403   ret = AE_BAD_PARAMETER;
17f4a5c4 Wolfram Sang 2014-09-22 @404   goto err;
17f4a5c4 Wolfram Sang 2014-09-22  405   }
17f4a5c4 Wolfram Sang 2014-09-22  406  
17f4a5c4 Wolfram Sang 2014-09-22  407   gsb->status = status;

:: The code at line 404 was first introduced by commit
:: 17f4a5c47f28de9ea59182f48d07f8c44ee5dcc9 i2c: move acpi code back into 
the core

:: TO: Wolfram Sang 
:: CC: Wolfram Sang 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] i2c-core: One function call less in acpi_i2c_space_handler() after error detection

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 26 Dec 2015 07:30:35 +0100

The kfree() function was called in one case by the
acpi_i2c_space_handler() function during error handling
even if the passed variable "client" contained a null pointer.

Implementation details could be improved by the adjustment of jump targets.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/i2c/i2c-core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 7349b00..a24e06c 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -313,18 +313,18 @@ acpi_i2c_space_handler(u32 function, 
acpi_physical_address command,
client = kzalloc(sizeof(*client), GFP_KERNEL);
if (!client) {
ret = AE_NO_MEMORY;
-   goto err;
+   goto free_ares;
}
 
if (!value64 || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS) {
ret = AE_BAD_PARAMETER;
-   goto err;
+   goto free_client;
}
 
sb = >data.i2c_serial_bus;
if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C) {
ret = AE_BAD_PARAMETER;
-   goto err;
+   goto free_client;
}
 
client->adapter = adapter;
@@ -405,9 +405,9 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address 
command,
}
 
gsb->status = status;
-
- err:
+free_client:
kfree(client);
+free_ares:
ACPI_FREE(ares);
return ret;
 }
-- 
2.6.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] arm64: entry.S: add missing trace_hardirqs_off

[Zhi-zhou Zhang]

Before calling schedule, we should trace hardirqs correctly. If not,
we get following warning message when enabled CONFIG_DEBUG_LOCKDEP:

[9.243073] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
[ ... ]
[9.262681] possible reason: unannotated irqs-off.
[9.263018] irq event stamp: 256209
[9.263266] hardirqs last  enabled at (256209): [] 
el0_irq_naked+0x1c/0x24
[9.263820] hardirqs last disabled at (256207): [] 
__do_softirq+0x170/0x28c
[9.264419] softirqs last  enabled at (256208): [] 
__do_softirq+0x1ec/0x28c
[9.264976] softirqs last disabled at (256189): [] 
irq_exit+0x9c/0xec

Signed-off-by: Zhi-zhou Zhang 
---
 arch/arm64/kernel/entry.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 7ed3d75..4769190 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -634,6 +634,9 @@ work_pending:
bl  do_notify_resume
b   ret_to_user
 work_resched:
+#ifdef CONFIG_TRACE_IRQFLAGS
+   bl  trace_hardirqs_off
+#endif
bl  schedule
 
 /*
-- 
2.1.4

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

Hi

[hi]

merry christmas 
dj,brand watch,doll,phone,tv,bike...
the shipping is free,iphone6s, 368euro
s ite: poazzlo. com

Re: [PATCH 3.2 46/77] drm: Fix an unwanted master inheritance v2

[Ben Hutchings]

On Fri, 2015-12-25 at 15:13 +0100, Thomas Hellstrom wrote:
> On 12/24/2015 04:37 PM, Ben Hutchings wrote:
> > 3.2.75-rc1 review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Thomas Hellstrom 
> > 
> > commit a0af2e538c80f3e47f1d6ddf120a153ad909e8ad upstream.
[...]
> >  /**
> > + * drm_new_set_master - Allocate a new master object and become master for 
> > the
> > + * associated master realm.
> > + *
> > + * @dev: The associated device.
> > + * @fpriv: File private identifying the client.
> > + *
> > + * This function must be called with dev::struct_mutex held.
> > + * Returns negative error code on failure. Zero on success.
> > + */
> > +int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
> > +{
> > +   struct drm_master *old_master;
> > +   int ret;
> > +
> > +   lockdep_assert_held_once(>struct_mutex);
> > +
> 
> Is lockdep_assert_held_once() backported into the 3.2 series?

Patch 45/77 in this series adds it.

Ben.

> If not,
> this line could probably be replaced by lockdep_assert_held() for stable
> kernels or removed entirely.


-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v3] um: Fix build error and kconfig for i386

[Josh Triplett]

On Fri, Dec 25, 2015 at 07:45:41PM +0100, Mickaël Salaün wrote:
> 
> On 25/12/2015 02:34, Josh Triplett wrote:
> > On Thu, Dec 24, 2015 at 01:12:11PM +0100, Mickaël Salaün wrote:
> >> Fix build error by generating elfcore.o only when ELF_CORE (depending on
> >> COREDUMP) is selected:
> >>
> >> arch/x86/um/built-in.o: In function `elf_core_write_extra_phdrs':
> >> (.text+0x3e62): undefined reference to `dump_emit'
> >> arch/x86/um/built-in.o: In function `elf_core_write_extra_data':
> >> (.text+0x3eef): undefined reference to `dump_emit'
> >>
> >> Fixes: 5d2acfc7b974 ("kconfig: make allnoconfig disable options behind 
> >> EMBEDDED and EXPERT")
> >> Signed-off-by: Mickaël Salaün 
> >> Cc: Jeff Dike 
> >> Cc: Richard Weinberger 
> >> Cc: Josh Triplett 
> >> Cc: Paul E. McKenney 
> >> Cc: Michal Marek 
> >> Cc: Andrew Morton 
> >> Cc: Linus Torvalds 
> > 
> > It looks like ELF_CORE depends on COREDUMP, but not on BINFMT_ELF.
> > Should it?  What happens if you build this with ELF_CORE=y and
> > BINFMT_ELF=n?  Does that configuration even make sense?
> 
> It build fine with ELF_CORE=y and BINFMT_ELF=n but does not seem
> useful. Nevertheless, it's the same for all architectures (cf.
> init/Kconfig): ELF_CORE only depends on COREDUMP.

As long as that builds, then this patch doesn't introduce an
un-buildable Kconfig configuration, so it seems reasonable.  Thanks
again for producing a new version.

Reviewed-by: Josh Triplett 
--
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] usb: gadget: acm: set notify_req to NULL after freed to avoid double free

[changbin . du]

From: "Du, Changbin" 

If acm_bind fails before allocate notification and acm->notify_req is
not set to NULL after freed last time, double free will happen.

kernel BUG at mm/slub.c:3392!
invalid opcode:  [#1] PREEMPT SMP
EIP is at kfree+0x172/0x180
Call Trace:
[<80c0e3b6>] ? usb_ep_autoconfig_ss+0x86/0x170
[<80c13345>] gs_free_req+0x15/0x30
[<80c12df1>] acm_bind+0x1c1/0x2d0
[<80c0e9be>] usb_add_function+0x6e/0x120
[<80c213cb>] acm_function_bind_config+0x2b/0x90

Signed-off-by: Du, Changbin 
---
 drivers/usb/gadget/function/f_acm.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_acm.c 
b/drivers/usb/gadget/function/f_acm.c
index 2fa1e80..e10c8d4 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -699,8 +699,10 @@ acm_bind(struct usb_configuration *c, struct usb_function 
*f)
return 0;
 
 fail:
-   if (acm->notify_req)
+   if (acm->notify_req) {
gs_free_req(acm->notify, acm->notify_req);
+   acm->notify_req = NULL;
+   }
 
ERROR(cdev, "%s/%p: can't bind, err %d\n", f->name, f, status);
 
@@ -713,8 +715,10 @@ static void acm_unbind(struct usb_configuration *c, struct 
usb_function *f)
 
acm_string_defs[0].id = 0;
usb_free_all_descriptors(f);
-   if (acm->notify_req)
+   if (acm->notify_req) {
gs_free_req(acm->notify, acm->notify_req);
+   acm->notify_req = NULL;
+   }
 }
 
 static void acm_free_func(struct usb_function *f)
-- 
2.5.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] null_blk: don't enable irqs when in irq

[Jens Axboe]

On 12/25/2015 07:26 AM, Rabin Vincent wrote:

When using irq_mode=NULL_IRQ_TIMER, blk_start_queue() is called from the
hrtimer interrupt.  null_request_fn() calls spin_unlock_irq() and this
causes the following splat from lockdep since interrupts are being
enabled while we're in an interrupt handler.

When we're in null_request_fn() we can't know the status of the flags
saved before blk_start_queue() was called, but we can use in_irq() to
conditionally enable interrupts only if we're not in a hard interrupt in
order to handle this case.


Using in_irq() to check for this is... nasty. You have two choices here. 
Either you don't enable interrupts ever. That's safe from the 
perspective of the driver, since we don't block in handling the command. 
That means just unconditionally using spin_unlock() in the request_fn. 
Or you punt queue running to process context, by manually clearing the 
queue stopped flag and using blk_run_queue_async() instead.


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

Re: [PATCH v4] pci: Limit VPD length for megaraid_sas adapter

[Babu Moger]

Hi Bjorn, Checking again. 
How about adding some messages in the logs to let user know that vpd has been 
disabled on this device in case if there is an attempt to access vpd.
What do you think?. Thanks
Babu

On 12/7/2015 5:07 PM, Babu Moger wrote:
> Hi Bjorn,
>   My old logs were lost. So, I had to recreate the issue again. So it took 
> sometime.
> 
> On 12/7/2015 11:29 AM, Bjorn Helgaas wrote:
>> Hi Babu,
>>
>> On Thu, Dec 03, 2015 at 12:25:19PM -0800, Babu Moger wrote:
>>> Reading or Writing of PCI VPD data causes system panic.
>>> We saw this problem by running "lspci -vvv" in the beginning.
>>> However this can be easily reproduced by running
>>>  cat /sys/bus/devices/XX../vpd
>>
>> What sort of panic is this?
>  
>   Actual panic stack showed total different area.  It looked like this.
> 
>   TSTATE: 80e01601 TPC: 007945c8 TNPC: 007945cc Y: 
> Not tainted
> TPC: 
> g0: 4000 g1: 084001604020 g2: 084001604024 g3: 
> 0acb
> g4: 800fe42d0340 g5: 8000291ce000 g6: 800fe42f4000 g7: 
> 03114000
> o0: 800fe085d99c o1: 800fe42f4008 o2: 4000 o3: 
> 0001
> o4:  o5: 0012 sp: 80002047b2b1 ret_pc: 
> 00794540
> RPC: 
> l0: 800fe085d980 l1: c001 l2: 000b l3: 
> 008e7058
> l4: 00bd19a8 l5: 00bd6a88 l6:  l7: 
> 
> i0: 800fe085d800 i1: 0016 i2: 800c20c007c3 i3: 
> f0265f78
> i4: feff4748 i5: feff2ff8 i6: 80002047b3d1 i7: 
> 0077adf0
> I7: 
> Call Trace:
>  [0077adf0] usb_hcd_irq+0x38/0xa0
>  [004d122c] handle_irq_event_percpu+0x8c/0x204
>  [004d13d8] handle_irq_event+0x34/0x60
>  [004d3998] handle_fasteoi_irq+0xdc/0x164
>  [004d1178] generic_handle_irq+0x24/0x38
>  [008dce68] handler_irq+0xb8/0xec
>  [004208b4] tl0_irq5+0x14/0x20
>  [0042cfac] cpu_idle+0x9c/0x18c
>  [008d2ad0] after_lock_tlb+0x1b4/0x1cc
>  []   (null)
> 
> 
> While analyzing it from kdump, I saw  it stuck in  here below.
> 
>  PID: 5274   TASK: 800fe1198680  CPU: 0   COMMAND: "cat"
> #0 [800fe25f6f81] switch_to_pc at 8d725c
> #1 [800fe25f70e1] pci_user_read_config_word at 6c4698
> #2 [800fe25f71a1] pci_vpd_pci22_wait at 6c4710
> #3 [800fe25f7261] pci_vpd_pci22_read at 6c4994
> #4 [800fe25f7321] pci_read_vpd at 6c3e90
> #5 [800fe25f73d1] read_vpd_attr at 6ccc78
> #6 [800fe25f7481] read at 5be478
> #7 [800fe25f7531] vfs_read at 54fdb0
> #8 [800fe25f75e1] sys_read at 54ff10
> #9 [800fe25f76a1] linux_sparc_syscall at 4060f4
> TSTATE=0x8082000223 TT=0x16d TPC=0xfc0100295e28 TNPC=0xfc0100295e2c
>  r0=0x  r1=0x0003  r2=0x0020aec0
>  r3=0x0020aec4  r4=0x0b00  r5=0x033f
>  r6=0x0001  r7=0xfc0106f0 r24=0x0003
> r25=0x0020e000 r26=0x8000 r27=0x
> r28=0x r29=0x r30=0x07feffb468d1
> r31=0x00105d94
> 
>  
> 
>>
>> This seems like a defect in the megaraid hardware or firmware.  If the
>> VPD ROM contains junk, there's no hope that software can read the data
>> and figure out how much is safe to read.
> 
> Yes this looks like problem with megaraid hardware. 
> 
> Other day,  Myron stowe(myron.st...@gmail.com) reported similar problem with 
> his setup.
> 
>  $ lspci -vvv -s 02:00.0
>   02:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208
>   [Thunderbolt] (rev 05)
> Capabilities: [d0] Vital Product Data
> Unknown small resource type 00, will not decode more.
> 
>   $ cat /sys/devices/pci:00/:00:02.2/:02:00.0/vpd |
>  od -A x -t x1z -v
>   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ><
>   *
>   007ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ><
>   008000
> 
> 
>>
>> I assume VPD is useful for somebody, and I hate to silently disable
>> the whole thing.  We might want to at least log a note about what
>> we're doing.
> 
> Sure. Let me know what you think.
> 
> 
>>
>> Bjorn
>>
>>> VPD length has been set as 32768 by default. Accessing vpd
>>> will trigger read/write of 32k. This causes problem as we
>>> could read data beyond the VPD end tag. Behaviour is un-
>>> predictable when this happens. I see some other adapter doing
>>> similar quirks(commit bffadffd43d4 ("PCI: fix VPD limit quirk
>>> for Broadcom 5708S"))
>>>
>>> I see there is an attempt to fix this right way.
>>> https://patchwork.ozlabs.org/patch/534843/ or
>>> https://lkml.org/lkml/2015/10/23/97
>>>
>>> Tried to fix it this way, but problem is I dont see the proper
>>> start/end TAGs(at least for this adapter) at all. The data is
>>> mostly junk or zeros. This patch fixes the 

linux-kernel antiblue protect eye for distributor

[lcdaccessory]

Dear linux-kernel  MD,

New LCD/LED TV defender blocker for year 2016.
huge profits reserve for first distributor there, a lots request from end-users 
especial for antiblue protector.
New and hottest model refer to  http://www.emetal.tw/protect/p1-blue.htm 

inquire email to Eric from eMetal Technology
www.lcdaccessory.com i...@emetal.tw 

 7459




































































--
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] ptrace: being capable wrt a process requires mapped uids/gids

[Jann Horn]

ptrace_has_cap() checks whether the current process should be
treated as having a certain capability for ptrace checks
against another process. Until now, this was equivalent to
has_ns_capability(current, target_ns, CAP_SYS_PTRACE).

However, if a root-owned process wants to enter a user
namespace for some reason without knowing who owns it and
therefore can't change to the namespace owner's uid and gid
before entering, as soon as it has entered the namespace,
the namespace owner can attach to it via ptrace and thereby
gain access to its uid and gid.

While it is possible for the entering process to switch to
the uid of a claimed namespace owner before entering,
causing the attempt to enter to fail if the claimed uid is
wrong, this doesn't solve the problem of determining an
appropriate gid.

With this change, the entering process can first enter the
namespace and then safely inspect the namespace's
properties, e.g. through /proc/self/{uid_map,gid_map},
assuming that the namespace owner doesn't have access to
uid 0.

Changed in v2: The caller needs to be capable in the
namespace into which tcred's uids/gids can be mapped.

Signed-off-by: Jann Horn 
---
 kernel/ptrace.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index b760bae..260a08d 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -207,12 +208,34 @@ static int ptrace_check_attach(struct task_struct *child, 
bool ignore_state)
return ret;
 }
 
-static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
+static bool ptrace_has_cap(const struct cred *tcred, unsigned int mode)
 {
+   struct user_namespace *tns = tcred->user_ns;
+
+   /* When a root-owned process enters a user namespace created by a
+* malicious user, the user shouldn't be able to execute code under
+* uid 0 by attaching to the root-owned process via ptrace.
+* Therefore, similar to the capable_wrt_inode_uidgid() check,
+* verify that all the uids and gids of the target process are
+* mapped into a namespace below the current one in which the caller
+* is capable.
+* No fsuid/fsgid check because __ptrace_may_access doesn't do it
+* either.
+*/
+   while (
+   !kuid_has_mapping(tns, tcred->euid) ||
+   !kuid_has_mapping(tns, tcred->suid) ||
+   !kuid_has_mapping(tns, tcred->uid)  ||
+   !kgid_has_mapping(tns, tcred->egid) ||
+   !kgid_has_mapping(tns, tcred->sgid) ||
+   !kgid_has_mapping(tns, tcred->gid)) {
+   tns = tns->parent;
+   }
+
if (mode & PTRACE_MODE_NOAUDIT)
-   return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
+   return has_ns_capability_noaudit(current, tns, CAP_SYS_PTRACE);
else
-   return has_ns_capability(current, ns, CAP_SYS_PTRACE);
+   return has_ns_capability(current, tns, CAP_SYS_PTRACE);
 }
 
 /* Returns 0 on success, -errno on denial. */
@@ -241,7 +264,7 @@ static int __ptrace_may_access(struct task_struct *task, 
unsigned int mode)
gid_eq(cred->gid, tcred->sgid) &&
gid_eq(cred->gid, tcred->gid))
goto ok;
-   if (ptrace_has_cap(tcred->user_ns, mode))
+   if (ptrace_has_cap(tcred, mode))
goto ok;
rcu_read_unlock();
return -EPERM;
@@ -252,7 +275,7 @@ ok:
dumpable = get_dumpable(task->mm);
rcu_read_lock();
if (dumpable != SUID_DUMP_USER &&
-   !ptrace_has_cap(__task_cred(task)->user_ns, mode)) {
+   !ptrace_has_cap(__task_cred(task), mode)) {
rcu_read_unlock();
return -EPERM;
}
-- 
2.1.4

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

[PATCH V2 1/1] Drivers: hv: vmbus: Add vendor and device atttributes

[K. Y. Srinivasan]

Add vendor and device attributes to VMBUS devices. These will be used
by Hyper-V tools as well user-level RDMA libraries that will use the
vendor/device tuple to discover the RDMA device.

Signed-off-by: K. Y. Srinivasan 
---
V2: Addressed comments from Greg KH

 Documentation/ABI/stable/sysfs-bus-vmbus |   14 +++
 drivers/hv/channel_mgmt.c|  166 ++
 drivers/hv/vmbus_drv.c   |   21 
 include/linux/hyperv.h   |   28 +
 4 files changed, 186 insertions(+), 43 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus 
b/Documentation/ABI/stable/sysfs-bus-vmbus
index 636e938..5d0125f 100644
--- a/Documentation/ABI/stable/sysfs-bus-vmbus
+++ b/Documentation/ABI/stable/sysfs-bus-vmbus
@@ -27,3 +27,17 @@ Description: The mapping of which primary/sub channels are 
bound to which
Virtual Processors.
Format: 
 Users: tools/hv/lsvmbus
+
+What:  /sys/bus/vmbus/devices/vmbus_*/device
+Date:  Dec. 2015
+KernelVersion: 4.5
+Contact:   K. Y. Srinivasan 
+Description:   The 16 bit device ID of the device
+Users: tools/hv/lsvmbus and user level RDMA libraries
+
+What:  /sys/bus/vmbus/devices/vmbus_*/vendor
+Date:  Dec. 2015
+KernelVersion: 4.5
+Contact:   K. Y. Srinivasan 
+Description:   The 16 bit vendor ID of the device
+Users: tools/hv/lsvmbus and user level RDMA libraries
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 1c1ad47..107d72f 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -32,8 +32,122 @@
 
 #include "hyperv_vmbus.h"
 
-static void init_vp_index(struct vmbus_channel *channel,
- const uuid_le *type_guid);
+static void init_vp_index(struct vmbus_channel *channel, u16 dev_type);
+
+static const struct vmbus_device vmbus_devs[] = {
+   /* IDE */
+   { .dev_type = HV_IDE,
+ HV_IDE_GUID,
+ .perf_device = true,
+   },
+
+   /* SCSI */
+   { .dev_type = HV_SCSI,
+ HV_SCSI_GUID,
+ .perf_device = true,
+   },
+
+   /* Fibre Channel */
+   { .dev_type = HV_FC,
+ HV_SYNTHFC_GUID,
+ .perf_device = true,
+   },
+
+   /* Synthetic NIC */
+   { .dev_type = HV_NIC,
+ HV_NIC_GUID,
+ .perf_device = true,
+   },
+
+   /* Network Direct */
+   { .dev_type = HV_ND,
+ HV_ND_GUID,
+ .perf_device = true,
+   },
+
+   /* PCIE */
+   { .dev_type = HV_PCIE,
+ HV_PCIE_GUID,
+ .perf_device = true,
+   },
+
+   /* Synthetic Frame Buffer */
+   { .dev_type = HV_FB,
+ HV_SYNTHVID_GUID,
+ .perf_device = false,
+   },
+
+   /* Synthetic Keyboard */
+   { .dev_type = HV_KBD,
+ HV_KBD_GUID,
+ .perf_device = false,
+   },
+
+   /* Synthetic MOUSE */
+   { .dev_type = HV_MOUSE,
+ HV_MOUSE_GUID,
+ .perf_device = false,
+   },
+
+   /* KVP */
+   { .dev_type = HV_KVP,
+ HV_KVP_GUID,
+ .perf_device = false,
+   },
+
+   /* Time Synch */
+   { .dev_type = HV_TS,
+ HV_TS_GUID,
+ .perf_device = false,
+   },
+
+   /* Heartbeat */
+   { .dev_type = HV_HB,
+ HV_HEART_BEAT_GUID,
+ .perf_device = false,
+   },
+
+   /* Shutdown */
+   { .dev_type = HV_SHUTDOWN,
+ HV_SHUTDOWN_GUID,
+ .perf_device = false,
+   },
+
+   /* File copy */
+   { .dev_type = HV_FCOPY,
+ HV_FCOPY_GUID,
+ .perf_device = false,
+   },
+
+   /* Backup */
+   { .dev_type = HV_BACKUP,
+ HV_VSS_GUID,
+ .perf_device = false,
+   },
+
+   /* Dynamic Memory */
+   { .dev_type = HV_DM,
+ HV_DM_GUID,
+ .perf_device = false,
+   },
+
+   /* Unknown GUID */
+   { .dev_type = HV_UNKOWN,
+ .perf_device = false,
+   },
+};
+
+static u16 hv_get_dev_type(const uuid_le *guid)
+{
+   u16 i;
+
+   for (i = HV_IDE; i < HV_UNKOWN; i++) {
+   if (!uuid_le_cmp(*guid, vmbus_devs[i].guid))
+   return i;
+   }
+   pr_info("Unknown GUID: %pUl\n", guid);
+   return i;
+}
 
 /**
  * vmbus_prep_negotiate_resp() - Create default response for Hyper-V Negotiate 
message
@@ -251,6 +365,7 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
struct vmbus_channel *channel;
bool fnew = true;
unsigned long flags;
+   u16 dev_type;
 
/* Make sure this is a new offer */
mutex_lock(_connection.channel_mutex);
@@ -288,7 +403,9 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
goto err_free_chan;
}
 
-   init_vp_index(newchannel, >offermsg.offer.if_type);
+   dev_type = hv_get_dev_type(>offermsg.offer.if_type);
+
+   

Re: [PATCH] ptrace: being capable wrt a process requires mapped uids/gids

[Jann Horn]

On Sat, Dec 12, 2015 at 09:12:41PM +0100, Jann Horn wrote:
> With this change, the entering process can first enter the
> namespace and then safely inspect the namespace's
> properties, e.g. through /proc/self/{uid_map,gid_map},
> assuming that the namespace owner doesn't have access to
> uid 0.

Actually, I think I missed something there. Well, at least it
should not directly lead to a container escape.


> -static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
> +static bool ptrace_has_cap(const struct cred *tcred, unsigned int mode)
>  {
> + struct user_namespace *tns = tcred->user_ns;
> + struct user_namespace *curns = current_cred()->user_ns;
> +
> + /* When a root-owned process enters a user namespace created by a
> +  * malicious user, the user shouldn't be able to execute code under
> +  * uid 0 by attaching to the root-owned process via ptrace.
> +  * Therefore, similar to the capable_wrt_inode_uidgid() check,
> +  * verify that all the uids and gids of the target process are
> +  * mapped into the current namespace.
> +  * No fsuid/fsgid check because __ptrace_may_access doesn't do it
> +  * either.
> +  */
> + if (!kuid_has_mapping(curns, tcred->euid) ||
> + !kuid_has_mapping(curns, tcred->suid) ||
> + !kuid_has_mapping(curns, tcred->uid)  ||
> + !kgid_has_mapping(curns, tcred->egid) ||
> + !kgid_has_mapping(curns, tcred->sgid) ||
> + !kgid_has_mapping(curns, tcred->gid))
> + return false;
> +
>   if (mode & PTRACE_MODE_NOAUDIT)
> - return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
> + return has_ns_capability_noaudit(current, tns, CAP_SYS_PTRACE);
>   else
> - return has_ns_capability(current, ns, CAP_SYS_PTRACE);
> + return has_ns_capability(current, tns, CAP_SYS_PTRACE);
>  }

If the namespace owner can run code in the init namespace, the kuids are
mapped into curns but he is still capable wrt the target namespace.

I think a proper fix should first determine the highest parent of
tcred->user_ns in which the caller still has privs, then do the
kxid_has_mapping() checks in there.


signature.asc
Description: Digital signature

Re: [PATCH v2 15/16] checkpatch: Add warning on deprecated walk_iomem_res

[Joe Perches]

On Fri, 2015-12-25 at 15:09 -0700, Toshi Kani wrote:
> Use of walk_iomem_res() is deprecated in new code.  Change
> checkpatch.pl to check new use of walk_iomem_res() and suggest
> to use walk_iomem_res_desc() instead.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3424,6 +3424,12 @@ sub process {
>   }
>   }
>  
> +# check for uses of walk_iomem_res()
> + if ($line =~ /\bwalk_iomem_res\(/) {
> + WARN("walk_iomem_res",
> +  "Use of walk_iomem_res is deprecated, please use 
> walk_iomem_res_desc instead\n" . $herecurr)
> + }
> +
>  # check for new typedefs, only function parameters and sparse annotations
>  # make sense.
>   if ($line =~ /\btypedef\s/ &&

There are 6 uses of this function in the entire kernel tree.
Why not just change them, remove the function and avoid this?

--
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 5/6] watchdog: da9055_wdt: Drop reference counting

[Guenter Roeck]

Reference counting is now implemented in the watchdog core and no longer
required in watchdog drivers.

Since it was implememented a no-op, and since the local memory is allocated
with devm_kzalloc(), the reference counting code in the driver really did
not really work anyway, and this patch effectively fixes a bug which could
cause a crash on unloading if the watchdog device was still open.

Signed-off-by: Guenter Roeck 
---
v2: Add note that the patch also fixes a bug.

 drivers/watchdog/da9055_wdt.c | 24 
 1 file changed, 24 deletions(-)

diff --git a/drivers/watchdog/da9055_wdt.c b/drivers/watchdog/da9055_wdt.c
index 04d1430d93d2..8377c43f3f20 100644
--- a/drivers/watchdog/da9055_wdt.c
+++ b/drivers/watchdog/da9055_wdt.c
@@ -35,7 +35,6 @@ MODULE_PARM_DESC(nowayout,
 struct da9055_wdt_data {
struct watchdog_device wdt;
struct da9055 *da9055;
-   struct kref kref;
 };
 
 static const struct {
@@ -99,24 +98,6 @@ static int da9055_wdt_ping(struct watchdog_device *wdt_dev)
 DA9055_WATCHDOG_MASK, 1);
 }
 
-static void da9055_wdt_release_resources(struct kref *r)
-{
-}
-
-static void da9055_wdt_ref(struct watchdog_device *wdt_dev)
-{
-   struct da9055_wdt_data *driver_data = watchdog_get_drvdata(wdt_dev);
-
-   kref_get(_data->kref);
-}
-
-static void da9055_wdt_unref(struct watchdog_device *wdt_dev)
-{
-   struct da9055_wdt_data *driver_data = watchdog_get_drvdata(wdt_dev);
-
-   kref_put(_data->kref, da9055_wdt_release_resources);
-}
-
 static int da9055_wdt_start(struct watchdog_device *wdt_dev)
 {
return da9055_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
@@ -138,8 +119,6 @@ static const struct watchdog_ops da9055_wdt_ops = {
.stop = da9055_wdt_stop,
.ping = da9055_wdt_ping,
.set_timeout = da9055_wdt_set_timeout,
-   .ref = da9055_wdt_ref,
-   .unref = da9055_wdt_unref,
 };
 
 static int da9055_wdt_probe(struct platform_device *pdev)
@@ -165,8 +144,6 @@ static int da9055_wdt_probe(struct platform_device *pdev)
watchdog_set_nowayout(da9055_wdt, nowayout);
watchdog_set_drvdata(da9055_wdt, driver_data);
 
-   kref_init(_data->kref);
-
ret = da9055_wdt_stop(da9055_wdt);
if (ret < 0) {
dev_err(>dev, "Failed to stop watchdog, %d\n", ret);
@@ -189,7 +166,6 @@ static int da9055_wdt_remove(struct platform_device *pdev)
struct da9055_wdt_data *driver_data = platform_get_drvdata(pdev);
 
watchdog_unregister_device(_data->wdt);
-   kref_put(_data->kref, da9055_wdt_release_resources);
 
return 0;
 }
-- 
2.1.4

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

[PATCH v2 4/6] watchdog: da9052_wdt: Drop reference counting

[Guenter Roeck]

Reference counting is now implemented in the watchdog core and no longer
required in watchdog drivers.

Since it was implememented a no-op, and since the local memory is allocated
with devm_kzalloc(), the reference counting code in the driver really did
not really work anyway, and this patch effectively fixes a bug which could
cause a crash on unloading if the watchdog device was still open.

Signed-off-by: Guenter Roeck 
---
v4: Add note that this patch also fixes a bug.

 drivers/watchdog/da9052_wdt.c | 24 
 1 file changed, 24 deletions(-)

diff --git a/drivers/watchdog/da9052_wdt.c b/drivers/watchdog/da9052_wdt.c
index 67e67977bd29..2fc19a32a320 100644
--- a/drivers/watchdog/da9052_wdt.c
+++ b/drivers/watchdog/da9052_wdt.c
@@ -31,7 +31,6 @@
 struct da9052_wdt_data {
struct watchdog_device wdt;
struct da9052 *da9052;
-   struct kref kref;
unsigned long jpast;
 };
 
@@ -51,10 +50,6 @@ static const struct {
 };
 
 
-static void da9052_wdt_release_resources(struct kref *r)
-{
-}
-
 static int da9052_wdt_set_timeout(struct watchdog_device *wdt_dev,
  unsigned int timeout)
 {
@@ -104,20 +99,6 @@ static int da9052_wdt_set_timeout(struct watchdog_device 
*wdt_dev,
return 0;
 }
 
-static void da9052_wdt_ref(struct watchdog_device *wdt_dev)
-{
-   struct da9052_wdt_data *driver_data = watchdog_get_drvdata(wdt_dev);
-
-   kref_get(_data->kref);
-}
-
-static void da9052_wdt_unref(struct watchdog_device *wdt_dev)
-{
-   struct da9052_wdt_data *driver_data = watchdog_get_drvdata(wdt_dev);
-
-   kref_put(_data->kref, da9052_wdt_release_resources);
-}
-
 static int da9052_wdt_start(struct watchdog_device *wdt_dev)
 {
return da9052_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
@@ -170,8 +151,6 @@ static const struct watchdog_ops da9052_wdt_ops = {
.stop = da9052_wdt_stop,
.ping = da9052_wdt_ping,
.set_timeout = da9052_wdt_set_timeout,
-   .ref = da9052_wdt_ref,
-   .unref = da9052_wdt_unref,
 };
 
 
@@ -198,8 +177,6 @@ static int da9052_wdt_probe(struct platform_device *pdev)
da9052_wdt->parent = >dev;
watchdog_set_drvdata(da9052_wdt, driver_data);
 
-   kref_init(_data->kref);
-
ret = da9052_reg_update(da9052, DA9052_CONTROL_D_REG,
DA9052_CONTROLD_TWDSCALE, 0);
if (ret < 0) {
@@ -225,7 +202,6 @@ static int da9052_wdt_remove(struct platform_device *pdev)
struct da9052_wdt_data *driver_data = platform_get_drvdata(pdev);
 
watchdog_unregister_device(_data->wdt);
-   kref_put(_data->kref, da9052_wdt_release_resources);
 
return 0;
 }
-- 
2.1.4

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

[PATCH v2 3/6] watchdog: Separate and maintain variables based on variable lifetime

[Guenter Roeck]

All variables required by the watchdog core to manage a watchdog are
currently stored in struct watchdog_device. The lifetime of those
variables is determined by the watchdog driver. However, the lifetime
of variables used by the watchdog core differs from the lifetime of
struct watchdog_device. To remedy this situation, watchdog drivers
can implement ref and unref callbacks, to be used by the watchdog
core to lock struct watchdog_device in memory.

While this solves the immediate problem, it depends on watchdog drivers
to actually implement the ref/unref callbacks. This is error prone,
often not implemented in the first place, or not implemented correctly.

To solve the problem without requiring driver support, split the variables
in struct watchdog_device into two data structures - one for variables
associated with the watchdog driver, one for variables associated with
the watchdog core. With this approach, the watchdog core can keep track
of its variable lifetime and no longer depends on ref/unref callbacks
in the driver. As a side effect, some of the variables originally in
struct watchdog_driver are now private to the watchdog core and no longer
visible in watchdog drivers.

As a side effect of the changes made, an ioctl will now always fail
with -ENODEV after a watchdog device was unregistered with the character
device still open. Previously, it would only fail with -ENODEV in some
situations. Also, ioctl operations are now atomic from driver perspective.
With this change, it is now guaranteed that the driver will not unregister
a watchdog between a timeout change and the subsequent ping.

The 'ref' and 'unref' callbacks in struct watchdog_driver are no longer
used and marked as deprecated.

Signed-off-by: Guenter Roeck 
---
v2: More detailed description
Rename internal data structure to watchdog_core_data, and the variable
pointing to it to wd_data. Move its declaration into watchdog_dev.c.
Reorder include files in watchdog_dev.c to alphabetic order.
Remove _watchdog_ping helper function and call watchdog_ping()
directly. Handle locks in the calling code.
Drop locking from watchdog_open(). It is already protected against
parallel device removal in the driver core code, and file access
functions won't be called before the function returns.
Remove previously added message "watchdog still running". It wasn't
there before, and we should avoid user visible changes.

 Documentation/watchdog/watchdog-kernel-api.txt |  45 +--
 drivers/watchdog/watchdog_core.c   |   2 -
 drivers/watchdog/watchdog_dev.c| 383 +
 include/linux/watchdog.h   |  22 +-
 4 files changed, 218 insertions(+), 234 deletions(-)

diff --git a/Documentation/watchdog/watchdog-kernel-api.txt 
b/Documentation/watchdog/watchdog-kernel-api.txt
index 0a37da76acef..72a009478b15 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -44,7 +44,6 @@ The watchdog device structure looks like this:
 
 struct watchdog_device {
int id;
-   struct cdev cdev;
struct device *dev;
struct device *parent;
const struct watchdog_info *info;
@@ -56,7 +55,7 @@ struct watchdog_device {
struct notifier_block reboot_nb;
struct notifier_block restart_nb;
void *driver_data;
-   struct mutex lock;
+   struct watchdog_core_data *wd_data;
unsigned long status;
struct list_head deferred;
 };
@@ -66,8 +65,6 @@ It contains following fields:
   /dev/watchdog0 cdev (dynamic major, minor 0) as well as the old
   /dev/watchdog miscdev. The id is set automatically when calling
   watchdog_register_device.
-* cdev: cdev for the dynamic /dev/watchdog device nodes. This
-  field is also populated by watchdog_register_device.
 * dev: device under the watchdog class (created by watchdog_register_device).
 * parent: set this to the parent device (or NULL) before calling
   watchdog_register_device.
@@ -89,11 +86,10 @@ It contains following fields:
 * driver_data: a pointer to the drivers private data of a watchdog device.
   This data should only be accessed via the watchdog_set_drvdata and
   watchdog_get_drvdata routines.
-* lock: Mutex for WatchDog Timer Driver Core internal use only.
+* wd_data: a pointer to watchdog core internal data.
 * status: this field contains a number of status bits that give extra
   information about the status of the device (Like: is the watchdog timer
-  running/active, is the nowayout bit set, is the device opened via
-  the /dev/watchdog interface or not, ...).
+  running/active, or is the nowayout bit set).
 * deferred: entry in wtd_deferred_reg_list which is used to
   register early initialized watchdogs.
 
@@ -110,8 +106,8 @@ struct watchdog_ops {
int (*set_timeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
int 

[PATCH v2 0/6] watchdog: Replace driver based refcounting

[Guenter Roeck]

All variables required by the watchdog core to manage a watchdog are
currently stored in struct watchdog_device. The lifetime of those
variables is determined by the watchdog driver. However, the lifetime
of variables used by the watchdog core differs from the lifetime of
struct watchdog_device. To remedy this situation, watchdog drivers
can implement ref and unref callbacks, to be used by the watchdog
core to lock struct watchdog_device in memory. This mechanism was
introduced with commit e907df327252 ("watchdog: Add support for
dynamically allocated watchdog_device structs").

While this solves the immediate problem, it depends on watchdog drivers
to actually implement the ref/unref callbacks. This is error prone,
often not implemented in the first place, or not implemented correctly.

To solve the problem without requiring driver support, split the variables
in struct watchdog_device into two data structures - one for variables
associated with the watchdog driver, one for variables associated with
the watchdog core. With this approach, the watchdog core can keep track
of the variables it uses and no longer depends on ref/unref callbacks
in the driver. As a side effect, some of the variables originally in struct
watchdog_driver are now private to the watchdog core and no longer visible
in watchdog drivers.

The 'ref' and 'unref' callbacks in struct watchdog_driver are no longer
used and marked as deprecated for the time being.

Patch 1/6 moves watchdog device creation from watchdog_core.c to
watchdog_dev.c to simplify watchdog device handling.

Patch 2/6 modifies the diag288 watchdog to no longer use and overload
watchdog core internal flags.

Patch 3/6 separates variables in watchdog_device based on variable
lifetime.

Patch 4/6 to 6/6 remove existing ref/unref functions from the drivers
implementing it. Two of those patches (for da9052 and da9055) fix a
previously introduced bug as side effect.

The series applies on top of the current watchdog-next as well as the
pending patches introducing sysfs support ("watchdog: Use static struct
class watchdog_class in stead of pointer" and "watchdog: Read device
status through sysfs attributes") by Pratyush Anand.

---
v2: Add patch 2/6.
Add more detailed description to patch 3/6.
Rename internal data structure to watchdog_core_data, and the variable
pointing to it to wd_data. Move its declaration into watchdog_dev.c.
Reorder include files in watchdog_dev.c to alphabetic order.
Remove _watchdog_ping helper function and call watchdog_ping()
directly. Handle locks in the calling code.
Drop locking from watchdog_open(). It is already protected against
parallel device removal in the driver core code, and file access
functions won't be called before the function returns.
Remove previously added message "watchdog still running". It wasn't
there before, and we should avoid user visible changes.
Add missing kfree() to the sch56xx patch.
Add comments to da9052 and da9055 patches indicating that the
patches fix a bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/6] watchdog: Create watchdog device in watchdog_dev.c

[Guenter Roeck]

The watchdog character device is currently created in watchdog_dev.c,
and the watchdog device in watchdog_core.c. This results in
cross-dependencies, since device creation needs to know the watchdog
character device number as well as the watchdog class, both of which
reside in watchdog_dev.c.

Create the watchdog device in watchdog_dev.c to simplify the code.

Inspired by earlier patch set from Damien Riegel.

Cc: Damien Riegel 
Signed-off-by: Guenter Roeck 
---
v2: No change

 drivers/watchdog/watchdog_core.c | 33 --
 drivers/watchdog/watchdog_core.h |  4 +--
 drivers/watchdog/watchdog_dev.c  | 73 +---
 3 files changed, 69 insertions(+), 41 deletions(-)

diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 551af042867c..f0293f7d2b80 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -42,7 +42,6 @@
 #include "watchdog_core.h" /* For watchdog_dev_register/... */
 
 static DEFINE_IDA(watchdog_ida);
-static struct class *watchdog_class;
 
 /*
  * Deferred Registration infrastructure.
@@ -194,7 +193,7 @@ EXPORT_SYMBOL_GPL(watchdog_set_restart_priority);
 
 static int __watchdog_register_device(struct watchdog_device *wdd)
 {
-   int ret, id = -1, devno;
+   int ret, id = -1;
 
if (wdd == NULL || wdd->info == NULL || wdd->ops == NULL)
return -EINVAL;
@@ -247,16 +246,6 @@ static int __watchdog_register_device(struct 
watchdog_device *wdd)
}
}
 
-   devno = wdd->cdev.dev;
-   wdd->dev = device_create(watchdog_class, wdd->parent, devno,
-   wdd, "watchdog%d", wdd->id);
-   if (IS_ERR(wdd->dev)) {
-   watchdog_dev_unregister(wdd);
-   ida_simple_remove(_ida, id);
-   ret = PTR_ERR(wdd->dev);
-   return ret;
-   }
-
if (test_bit(WDOG_STOP_ON_REBOOT, >status)) {
wdd->reboot_nb.notifier_call = watchdog_reboot_notifier;
 
@@ -265,9 +254,7 @@ static int __watchdog_register_device(struct 
watchdog_device *wdd)
dev_err(wdd->dev, "Cannot register reboot notifier 
(%d)\n",
ret);
watchdog_dev_unregister(wdd);
-   device_destroy(watchdog_class, devno);
ida_simple_remove(_ida, wdd->id);
-   wdd->dev = NULL;
return ret;
}
}
@@ -311,9 +298,6 @@ EXPORT_SYMBOL_GPL(watchdog_register_device);
 
 static void __watchdog_unregister_device(struct watchdog_device *wdd)
 {
-   int ret;
-   int devno;
-
if (wdd == NULL)
return;
 
@@ -323,13 +307,8 @@ static void __watchdog_unregister_device(struct 
watchdog_device *wdd)
if (test_bit(WDOG_STOP_ON_REBOOT, >status))
unregister_reboot_notifier(>reboot_nb);
 
-   devno = wdd->cdev.dev;
-   ret = watchdog_dev_unregister(wdd);
-   if (ret)
-   pr_err("error unregistering /dev/watchdog (err=%d)\n", ret);
-   device_destroy(watchdog_class, devno);
+   watchdog_dev_unregister(wdd);
ida_simple_remove(_ida, wdd->id);
-   wdd->dev = NULL;
 }
 
 /**
@@ -370,9 +349,11 @@ static int __init watchdog_deferred_registration(void)
 
 static int __init watchdog_init(void)
 {
-   watchdog_class = watchdog_dev_init();
-   if (IS_ERR(watchdog_class))
-   return PTR_ERR(watchdog_class);
+   int err;
+
+   err = watchdog_dev_init();
+   if (err < 0)
+   return err;
 
watchdog_deferred_registration();
return 0;
diff --git a/drivers/watchdog/watchdog_core.h b/drivers/watchdog/watchdog_core.h
index 1c8d6b0e68c7..86ff962d1e15 100644
--- a/drivers/watchdog/watchdog_core.h
+++ b/drivers/watchdog/watchdog_core.h
@@ -32,6 +32,6 @@
  * Functions/procedures to be called by the core
  */
 extern int watchdog_dev_register(struct watchdog_device *);
-extern int watchdog_dev_unregister(struct watchdog_device *);
-extern struct class * __init watchdog_dev_init(void);
+extern void watchdog_dev_unregister(struct watchdog_device *);
+extern int __init watchdog_dev_init(void);
 extern void __exit watchdog_dev_exit(void);
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index d93118e97d11..c24392623e98 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -626,17 +626,18 @@ static struct miscdevice watchdog_miscdev = {
 };
 
 /*
- * watchdog_dev_register: register a watchdog device
+ * watchdog_cdev_register: register watchdog character device
  * @wdd: watchdog device
+ * @devno: character device number
  *
- * Register a watchdog device including handling the legacy
+ * Register a watchdog character device including handling the legacy
  * /dev/watchdog node. /dev/watchdog is actually a 

[PATCH v2 6/6] hwmon: (sch56xx) Drop watchdog driver data reference count callbacks

[Guenter Roeck]

Reference counting is now implemented in the watchdog core and no longer
required in watchdog drivers.

Signed-off-by: Guenter Roeck 
---
v2: Add missing kfree().

 drivers/hwmon/sch56xx-common.c | 31 +--
 1 file changed, 1 insertion(+), 30 deletions(-)

diff --git a/drivers/hwmon/sch56xx-common.c b/drivers/hwmon/sch56xx-common.c
index 738681983284..68c350c704fb 100644
--- a/drivers/hwmon/sch56xx-common.c
+++ b/drivers/hwmon/sch56xx-common.c
@@ -30,7 +30,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include "sch56xx-common.h"
 
@@ -67,7 +66,6 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once 
started (default="
 struct sch56xx_watchdog_data {
u16 addr;
struct mutex *io_lock;
-   struct kref kref;
struct watchdog_info wdinfo;
struct watchdog_device wddev;
u8 watchdog_preset;
@@ -258,15 +256,6 @@ EXPORT_SYMBOL(sch56xx_read_virtual_reg12);
  * Watchdog routines
  */
 
-/* Release our data struct when we're unregistered *and*
-   all references to our watchdog device are released */
-static void watchdog_release_resources(struct kref *r)
-{
-   struct sch56xx_watchdog_data *data =
-   container_of(r, struct sch56xx_watchdog_data, kref);
-   kfree(data);
-}
-
 static int watchdog_set_timeout(struct watchdog_device *wddev,
unsigned int timeout)
 {
@@ -395,28 +384,12 @@ static int watchdog_stop(struct watchdog_device *wddev)
return 0;
 }
 
-static void watchdog_ref(struct watchdog_device *wddev)
-{
-   struct sch56xx_watchdog_data *data = watchdog_get_drvdata(wddev);
-
-   kref_get(>kref);
-}
-
-static void watchdog_unref(struct watchdog_device *wddev)
-{
-   struct sch56xx_watchdog_data *data = watchdog_get_drvdata(wddev);
-
-   kref_put(>kref, watchdog_release_resources);
-}
-
 static const struct watchdog_ops watchdog_ops = {
.owner  = THIS_MODULE,
.start  = watchdog_start,
.stop   = watchdog_stop,
.ping   = watchdog_trigger,
.set_timeout= watchdog_set_timeout,
-   .ref= watchdog_ref,
-   .unref  = watchdog_unref,
 };
 
 struct sch56xx_watchdog_data *sch56xx_watchdog_register(struct device *parent,
@@ -448,7 +421,6 @@ struct sch56xx_watchdog_data 
*sch56xx_watchdog_register(struct device *parent,
 
data->addr = addr;
data->io_lock = io_lock;
-   kref_init(>kref);
 
strlcpy(data->wdinfo.identity, "sch56xx watchdog",
sizeof(data->wdinfo.identity));
@@ -494,8 +466,7 @@ EXPORT_SYMBOL(sch56xx_watchdog_register);
 void sch56xx_watchdog_unregister(struct sch56xx_watchdog_data *data)
 {
watchdog_unregister_device(>wddev);
-   kref_put(>kref, watchdog_release_resources);
-   /* Don't touch data after this it may have been free-ed! */
+   kfree(data);
 }
 EXPORT_SYMBOL(sch56xx_watchdog_unregister);
 
-- 
2.1.4

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

[PATCH v2 2/6] watchdog: diag288: Stop re-using watchdog core internal flags

[Guenter Roeck]

A watchdog driver should not use watchdog subsystem internal flags.
Use a driver variable and flag instead to maintain the watchdog state
and to determine if a suspend operation is possible or not.

Signed-off-by: Guenter Roeck 
---
v2: Added patch

 drivers/watchdog/diag288_wdt.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/watchdog/diag288_wdt.c b/drivers/watchdog/diag288_wdt.c
index 3db9d0e0673d..861d3d3133f8 100644
--- a/drivers/watchdog/diag288_wdt.c
+++ b/drivers/watchdog/diag288_wdt.c
@@ -106,6 +106,10 @@ static int __diag288_lpar(unsigned int func, unsigned int 
timeout,
return __diag288(func, timeout, action, 0);
 }
 
+static unsigned long wdt_status;
+
+#define DIAG_WDOG_BUSY 0
+
 static int wdt_start(struct watchdog_device *dev)
 {
char *ebc_cmd;
@@ -113,12 +117,17 @@ static int wdt_start(struct watchdog_device *dev)
int ret;
unsigned int func;
 
+   if (test_and_set_bit(DIAG_WDOG_BUSY, _status))
+   return -EBUSY;
+
ret = -ENODEV;
 
if (MACHINE_IS_VM) {
ebc_cmd = kmalloc(MAX_CMDLEN, GFP_KERNEL);
-   if (!ebc_cmd)
+   if (!ebc_cmd) {
+   clear_bit(DIAG_WDOG_BUSY, _status);
return -ENOMEM;
+   }
len = strlcpy(ebc_cmd, wdt_cmd, MAX_CMDLEN);
ASCEBC(ebc_cmd, MAX_CMDLEN);
EBC_TOUPPER(ebc_cmd, MAX_CMDLEN);
@@ -135,6 +144,7 @@ static int wdt_start(struct watchdog_device *dev)
 
if (ret) {
pr_err("The watchdog cannot be activated\n");
+   clear_bit(DIAG_WDOG_BUSY, _status);
return ret;
}
return 0;
@@ -146,6 +156,9 @@ static int wdt_stop(struct watchdog_device *dev)
 
diag_stat_inc(DIAG_STAT_X288);
ret = __diag288(WDT_FUNC_CANCEL, 0, 0, 0);
+
+   clear_bit(DIAG_WDOG_BUSY, _status);
+
return ret;
 }
 
@@ -220,17 +233,10 @@ static struct watchdog_device wdt_dev = {
  * It makes no sense to go into suspend while the watchdog is running.
  * Depending on the memory size, the watchdog might trigger, while we
  * are still saving the memory.
- * We reuse the open flag to ensure that suspend and watchdog open are
- * exclusive operations
  */
 static int wdt_suspend(void)
 {
-   if (test_and_set_bit(WDOG_DEV_OPEN, _dev.status)) {
-   pr_err("Linux cannot be suspended while the watchdog is in 
use\n");
-   return notifier_from_errno(-EBUSY);
-   }
-   if (test_bit(WDOG_ACTIVE, _dev.status)) {
-   clear_bit(WDOG_DEV_OPEN, _dev.status);
+   if (test_and_set_bit(DIAG_WDOG_BUSY, _status)) {
pr_err("Linux cannot be suspended while the watchdog is in 
use\n");
return notifier_from_errno(-EBUSY);
}
@@ -239,7 +245,7 @@ static int wdt_suspend(void)
 
 static int wdt_resume(void)
 {
-   clear_bit(WDOG_DEV_OPEN, _dev.status);
+   clear_bit(DIAG_WDOG_BUSY, _status);
return NOTIFY_DONE;
 }
 
-- 
2.1.4

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

[PATCH] ARM: dts: n900: Include adp1653 device

[Pali Rohár]

This patch adds adp1653 device into n900 DT structure. DT support in
adp1653 driver is there since v4.2-rc1 version.

Signed-off-by: Pali Rohár 
---
 arch/arm/boot/dts/omap3-n900.dts |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 5f5e0f3..ba93642 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -522,6 +522,21 @@
amstaos,cover-comp-gain = <16>;
};
 
+   adp1653: led-controller@30 {
+   compatible = "adi,adp1653";
+   reg = <0x30>;
+   enable-gpios = < 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+   flash {
+   flash-timeout-us = <50>;
+   flash-max-microamp = <32>;
+   led-max-microamp = <5>;
+   };
+   indicator {
+   led-max-microamp = <17500>;
+   };
+   };
+
lp5523: lp5523@32 {
compatible = "national,lp5523";
reg = <0x32>;
-- 
1.7.9.5

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

[PATCH] Fix documentation for adp1653 DT

[Pali Rohár]

Property names do not match real names needed by driver itself.
This patch fix this problem.

Signed-off-by: Pali Rohár 
---
 .../devicetree/bindings/media/i2c/adp1653.txt  |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt 
b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
index 5ce66f2..4cce0de 100644
--- a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
@@ -12,12 +12,13 @@ There are two LED outputs available - flash and indicator. 
One LED is
 represented by one child node, nodes need to be named "flash" and "indicator".
 
 Required properties of the LED child node:
-- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+- led-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
 
 Required properties of the flash LED child node:
 
 - flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
 - flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
+- led-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
 
 Example:
 
@@ -29,9 +30,9 @@ Example:
flash {
flash-timeout-us = <50>;
flash-max-microamp = <32>;
-   max-microamp = <5>;
+   led-max-microamp = <5>;
};
indicator {
-   max-microamp = <17500>;
+   led-max-microamp = <17500>;
};
};
-- 
1.7.9.5

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

[PATCH] ARM: dts: omap3: Include missing bandgap data for ti-soc-thermal driver

[Pali Rohár]

Driver for omap3 with documentation is there since v4.4-rc1.

Signed-off-by: Pali Rohár 
---
 arch/arm/boot/dts/omap34xx.dtsi |5 +
 arch/arm/boot/dts/omap36xx.dtsi |5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 4f6b2d5..c3f488f 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -54,6 +54,11 @@
#size-cells = <0>;
};
};
+
+   bandgap {
+   reg = <0x48002524 0x4>;
+   compatible = "ti,omap34xx-bandgap";
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 86253de..00f98c1 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -86,6 +86,11 @@
#size-cells = <0>;
};
};
+
+   bandgap {
+   reg = <0x48002524 0x4>;
+   compatible = "ti,omap36xx-bandgap";
+   };
};
 };
 
-- 
1.7.9.5

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

[PATCH] prism54: fix checks for dma mapping errors

[Alexey Khoroshilov]

prism54 checks for dma mapping errors by comparison returned address
with zero, while pci_dma_mapping_error() should be used.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/net/wireless/prism54/islpci_dev.c | 4 +++-
 drivers/net/wireless/prism54/islpci_eth.c | 5 +++--
 drivers/net/wireless/prism54/islpci_mgt.c | 4 ++--
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/prism54/islpci_dev.c 
b/drivers/net/wireless/prism54/islpci_dev.c
index 931cf440ff18..84a42012aeae 100644
--- a/drivers/net/wireless/prism54/islpci_dev.c
+++ b/drivers/net/wireless/prism54/islpci_dev.c
@@ -707,7 +707,9 @@ islpci_alloc_memory(islpci_private *priv)
pci_map_single(priv->pdev, (void *) skb->data,
   MAX_FRAGMENT_SIZE_RX + 2,
   PCI_DMA_FROMDEVICE);
-   if (!priv->pci_map_rx_address[counter]) {
+   if (pci_dma_mapping_error(priv->pdev,
+ priv->pci_map_rx_address[counter])) {
+   priv->pci_map_rx_address[counter] = 0;
/* error mapping the buffer to device
   accessible memory address */
printk(KERN_ERR "failed to map skb DMA'able\n");
diff --git a/drivers/net/wireless/prism54/islpci_eth.c 
b/drivers/net/wireless/prism54/islpci_eth.c
index 674658f2e6ef..d83f6332019e 100644
--- a/drivers/net/wireless/prism54/islpci_eth.c
+++ b/drivers/net/wireless/prism54/islpci_eth.c
@@ -190,7 +190,7 @@ islpci_eth_transmit(struct sk_buff *skb, struct net_device 
*ndev)
pci_map_address = pci_map_single(priv->pdev,
 (void *) skb->data, skb->len,
 PCI_DMA_TODEVICE);
-   if (unlikely(pci_map_address == 0)) {
+   if (pci_dma_mapping_error(priv->pdev, pci_map_address)) {
printk(KERN_WARNING "%s: cannot map buffer to PCI\n",
   ndev->name);
goto drop_free;
@@ -448,7 +448,8 @@ islpci_eth_receive(islpci_private *priv)
pci_map_single(priv->pdev, (void *) skb->data,
   MAX_FRAGMENT_SIZE_RX + 2,
   PCI_DMA_FROMDEVICE);
-   if (unlikely(!priv->pci_map_rx_address[index])) {
+   if (pci_dma_mapping_error(priv->pdev,
+ priv->pci_map_rx_address[index])) {
/* error mapping the buffer to device accessible memory 
address */
DEBUG(SHOW_ERROR_MESSAGES,
  "Error mapping DMA address\n");
diff --git a/drivers/net/wireless/prism54/islpci_mgt.c 
b/drivers/net/wireless/prism54/islpci_mgt.c
index 0de14dfa68cc..53d7a1705e8e 100644
--- a/drivers/net/wireless/prism54/islpci_mgt.c
+++ b/drivers/net/wireless/prism54/islpci_mgt.c
@@ -130,7 +130,7 @@ islpci_mgmt_rx_fill(struct net_device *ndev)
buf->pci_addr = pci_map_single(priv->pdev, buf->mem,
   MGMT_FRAME_SIZE,
   PCI_DMA_FROMDEVICE);
-   if (!buf->pci_addr) {
+   if (pci_dma_mapping_error(priv->pdev, buf->pci_addr)) {
printk(KERN_WARNING
   "Failed to make memory DMA'able.\n");
return -ENOMEM;
@@ -217,7 +217,7 @@ islpci_mgt_transmit(struct net_device *ndev, int operation, 
unsigned long oid,
err = -ENOMEM;
buf.pci_addr = pci_map_single(priv->pdev, buf.mem, frag_len,
  PCI_DMA_TODEVICE);
-   if (!buf.pci_addr) {
+   if (pci_dma_mapping_error(priv->pdev, buf.pci_addr)) {
printk(KERN_WARNING "%s: cannot map PCI memory for mgmt\n",
   ndev->name);
goto error_free;
-- 
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 v2 01/16] resource: Add System RAM resource type

[Toshi Kani]

I/O resource type, IORESOURCE_MEM, is used for all types of
memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
reserved, and so on.  This requires walk_system_ram_range(),
walk_system_ram_res(), and region_intersects() to use strcmp()
against string "System RAM" to search for System RAM ranges in
the iomem table, which is inefficient.  __ioremap_caller() and
reserve_memtype() on x86, for instance, call walk_system_ram_range()
for every request to check if a given range is in System RAM ranges.

However, adding a new I/O resource type for System RAM is not
a viable option [1].  There are approx. 3800 references to
IORESOURCE_MEM in the kernel/drivers, which make it very
difficult to distinguish their usages between new type and
IORESOURCE_MEM.  The I/O resource types are also used by the
PNP subsystem.  Therefore, this patch introduces an extended
I/O resource type, IORESOURCE_SYSTEM_RAM, which consists of
IORESOURCE_MEM and a new modifier flag IORESOURCE_SYSRAM [2].

To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
work continuously for System RAM, resource_ext_type() is added
for extracting extended type bit(s).

Link[1]: http://lkml.kernel.org/r/<1449168859.9855.54.ca...@hpe.com>
Link[2]: 
http://lkml.kernel.org/r/
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Rafael J. Wysocki 
Cc: Dan Williams 
Signed-off-by: Toshi Kani 
---
 include/linux/ioport.h |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 24bea08..4b65d94 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -49,12 +49,19 @@ struct resource {
 #define IORESOURCE_WINDOW  0x0020  /* forwarded by bridge */
 #define IORESOURCE_MUXED   0x0040  /* Resource is software muxed */
 
+#define IORESOURCE_EXT_TYPE_BITS 0x0100/* Resource extended types */
+#define IORESOURCE_SYSRAM  0x0100  /* System RAM (modifier) */
+
 #define IORESOURCE_EXCLUSIVE   0x0800  /* Userland may not map this 
resource */
+
 #define IORESOURCE_DISABLED0x1000
 #define IORESOURCE_UNSET   0x2000  /* No address assigned yet */
 #define IORESOURCE_AUTO0x4000
 #define IORESOURCE_BUSY0x8000  /* Driver has marked 
this resource busy */
 
+/* I/O resource extended types */
+#define IORESOURCE_SYSTEM_RAM  (IORESOURCE_MEM|IORESOURCE_SYSRAM)
+
 /* PnP IRQ specific bits (IORESOURCE_BITS) */
 #define IORESOURCE_IRQ_HIGHEDGE(1<<0)
 #define IORESOURCE_IRQ_LOWEDGE (1<<1)
@@ -170,6 +177,10 @@ static inline unsigned long resource_type(const struct 
resource *res)
 {
return res->flags & IORESOURCE_TYPE_BITS;
 }
+static inline unsigned long resource_ext_type(const struct resource *res)
+{
+   return res->flags & IORESOURCE_EXT_TYPE_BITS;
+}
 /* True iff r1 completely contains r2 */
 static inline bool resource_contains(struct resource *r1, struct resource *r2)
 {
--
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 16/16] ACPI/EINJ: Allow memory error injection to NVDIMM

[Toshi Kani]

In the case of memory error injection, einj_error_inject() checks
if a target address is System RAM.  Change this check to allow
injecting a memory error to NVDIMM by calling region_intersects()
with IORES_DESC_PERSISTENT_MEMORY.  This enables memory error
testing on both System RAM and NVDIMM.

In addition, page_is_ram() is replaced with region_intersects()
with IORESOURCE_SYSTEM_RAM, so that it can verify a target address
range with the requested size.

Cc: Rafael J. Wysocki 
Cc: Borislav Petkov 
Cc: Vishal Verma 
Cc: Tony Luck 
Cc: Dan Williams 
Cc: linux-nvd...@lists.01.org
Cc: linux-a...@vger.kernel.org
Acked-by: Tony Luck 
Reviewed-by: Dan Williams 
Signed-off-by: Toshi Kani 
---
 drivers/acpi/apei/einj.c |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index 0431883..16cae66 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -519,7 +519,7 @@ static int einj_error_inject(u32 type, u32 flags, u64 
param1, u64 param2,
 u64 param3, u64 param4)
 {
int rc;
-   unsigned long pfn;
+   u64 base_addr, size;
 
/* If user manually set "flags", make sure it is legal */
if (flags && (flags &
@@ -545,10 +545,17 @@ static int einj_error_inject(u32 type, u32 flags, u64 
param1, u64 param2,
/*
 * Disallow crazy address masks that give BIOS leeway to pick
 * injection address almost anywhere. Insist on page or
-* better granularity and that target address is normal RAM.
+* better granularity and that target address is normal RAM or
+* NVDIMM.
 */
-   pfn = PFN_DOWN(param1 & param2);
-   if (!page_is_ram(pfn) || ((param2 & PAGE_MASK) != PAGE_MASK))
+   base_addr = param1 & param2;
+   size = ~param2 + 1;
+
+   if (((param2 & PAGE_MASK) != PAGE_MASK) ||
+   ((region_intersects(base_addr, size, IORESOURCE_SYSTEM_RAM,
+   IORES_DESC_NONE) != REGION_INTERSECTS) &&
+(region_intersects(base_addr, size, IORESOURCE_MEM,
+   IORES_DESC_PERSISTENT_MEMORY) != REGION_INTERSECTS)))
return -EINVAL;
 
 inject:
--
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 02/16] resource: make resource flags handled properly

[Toshi Kani]

I/O resource flags consist of I/O resource types and modifier
bits.  Therefore, checking an I/O resource type in 'flags' must
be performed with a bitwise operation.

Fix find_next_iomem_res() and region_intersects() that simply
compare 'flags' against a given value.

Also change __request_region() to set 'res->flags' from
resource_type() and resource_ext_type() of the parent, so that
children nodes will inherit the extended I/O resource type.

Link: 
http://lkml.kernel.org/r/
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Dan Williams 
Cc: Rafael J. Wysocki 
Signed-off-by: Toshi Kani 
---
 kernel/resource.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index f150dbb..d30a175 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -358,7 +358,7 @@ static int find_next_iomem_res(struct resource *res, char 
*name,
read_lock(_lock);
 
for (p = iomem_resource.child; p; p = next_resource(p, sibling_only)) {
-   if (p->flags != res->flags)
+   if ((p->flags & res->flags) != res->flags)
continue;
if (name && strcmp(p->name, name))
continue;
@@ -519,7 +519,8 @@ int region_intersects(resource_size_t start, size_t size, 
const char *name)
 
read_lock(_lock);
for (p = iomem_resource.child; p ; p = p->sibling) {
-   bool is_type = strcmp(p->name, name) == 0 && p->flags == flags;
+   bool is_type = strcmp(p->name, name) == 0 &&
+   ((p->flags & flags) == flags);
 
if (start >= p->start && start <= p->end)
is_type ? type++ : other++;
@@ -1071,7 +1072,7 @@ struct resource * __request_region(struct resource 
*parent,
res->name = name;
res->start = start;
res->end = start + n - 1;
-   res->flags = resource_type(parent);
+   res->flags = resource_type(parent) | resource_ext_type(parent);
res->flags |= IORESOURCE_BUSY | flags;
 
write_lock(_lock);
--
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 05/16] ia64: Set System RAM type and descriptor

[Toshi Kani]

Change efi_initialize_iomem_resources() to set 'flags' and 'desc'
from EFI memory types.  IORESOURCE_SYSRAM, a modifier bit, is
set to 'flags' for System RAM as IORESOURCE_MEM is already set.
IORESOURCE_SYSTEM_RAM is defined as (IORESOURCE_MEM|IORESOURCE_SYSRAM).
I/O resource descritor is set to 'desc' for "ACPI Non-volatile
Storage" and "Persistent Memory".

Also set IORESOURCE_SYSTEM_RAM to 'flags' for "Kernel code",
"Kernel data", and "Kernel bss".

Cc: Tony Luck 
Cc: linux-i...@vger.kernel.org
Signed-off-by: Toshi Kani 
---
 arch/ia64/kernel/efi.c   |   13 ++---
 arch/ia64/kernel/setup.c |6 +++---
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index caae3f4..300dac3 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -1178,7 +1178,7 @@ efi_initialize_iomem_resources(struct resource 
*code_resource,
efi_memory_desc_t *md;
u64 efi_desc_size;
char *name;
-   unsigned long flags;
+   unsigned long flags, desc;
 
efi_map_start = __va(ia64_boot_param->efi_memmap);
efi_map_end   = efi_map_start + ia64_boot_param->efi_memmap_size;
@@ -1193,6 +1193,8 @@ efi_initialize_iomem_resources(struct resource 
*code_resource,
continue;
 
flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   desc = IORES_DESC_NONE;
+
switch (md->type) {
 
case EFI_MEMORY_MAPPED_IO:
@@ -1207,14 +1209,17 @@ efi_initialize_iomem_resources(struct resource 
*code_resource,
if (md->attribute & EFI_MEMORY_WP) {
name = "System ROM";
flags |= IORESOURCE_READONLY;
-   } else if (md->attribute == EFI_MEMORY_UC)
+   } else if (md->attribute == EFI_MEMORY_UC) {
name = "Uncached RAM";
-   else
+   } else {
name = "System RAM";
+   flags |= IORESOURCE_SYSRAM;
+   }
break;
 
case EFI_ACPI_MEMORY_NVS:
name = "ACPI Non-volatile Storage";
+   desc = IORES_DESC_ACPI_NV_STORAGE;
break;
 
case EFI_UNUSABLE_MEMORY:
@@ -1224,6 +1229,7 @@ efi_initialize_iomem_resources(struct resource 
*code_resource,
 
case EFI_PERSISTENT_MEMORY:
name = "Persistent Memory";
+   desc = IORES_DESC_PERSISTENT_MEMORY;
break;
 
case EFI_RESERVED_TYPE:
@@ -1246,6 +1252,7 @@ efi_initialize_iomem_resources(struct resource 
*code_resource,
res->start = md->phys_addr;
res->end = md->phys_addr + efi_md_size(md) - 1;
res->flags = flags;
+   res->desc = desc;
 
if (insert_resource(_resource, res) < 0)
kfree(res);
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index 4f118b0..2029a38 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -80,17 +80,17 @@ unsigned long vga_console_membase;
 
 static struct resource data_resource = {
.name   = "Kernel data",
-   .flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+   .flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
.name   = "Kernel code",
-   .flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+   .flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
.name   = "Kernel bss",
-   .flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+   .flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 unsigned long ia64_max_cacheline_size;
--
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 03/16] resource: Add I/O resource descriptor

[Toshi Kani]

walk_iomem_res() and region_intersects() still need to use
strcmp() for searching a resource entry by @name in the
iomem table.

This patch introduces I/O resource descriptor, 'desc' in
struct resoruce, for the iomem search interfaces.  Drivers
can assign their unique descritor to a range when they
support the search interfaces.  Otherwise, 'desc' is set to
IORES_DESC_NONE (0).  This avoids changing most of the drivers
as they typically allocate resource entries statically, or
by calling alloc_resource(), kzalloc(), or alloc_bootmem_low(),
which set the field to zero by default.  A later patch will
address some drivers that use kmalloc() without zero'ing
the field.

Also change release_mem_region_adjustable() to set 'desc'
when its resource entry gets separated.  Other resource
interfaces are also changed to initialize 'desc' explicitly
although alloc_resource() sets it to 0.

Link: http://lkml.kernel.org/r/<20151216181712.gj29...@pd.tnic>
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Dan Williams 
Signed-off-by: Toshi Kani 
---
 include/linux/ioport.h |   19 +++
 kernel/resource.c  |5 +
 2 files changed, 24 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 4b65d94..b7350c0 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -20,6 +20,7 @@ struct resource {
resource_size_t end;
const char *name;
unsigned long flags;
+   unsigned long desc;
struct resource *parent, *sibling, *child;
 };
 
@@ -112,6 +113,23 @@ struct resource {
 /* PCI control bits.  Shares IORESOURCE_BITS with above PCI ROM.  */
 #define IORESOURCE_PCI_FIXED   (1<<4)  /* Do not move resource */
 
+/*
+ * I/O Resource Descriptors
+ *
+ * Descriptors are used by walk_iomem_res_desc() and region_intersects()
+ * for searching a specific resource range in the iomem table.  Assign
+ * a new descriptor when a resource range supports the search interfaces.
+ * Otherwise, resource.desc must be set to IORES_DESC_NONE (0).
+ */
+enum {
+   IORES_DESC_NONE = 0,
+   IORES_DESC_CRASH_KERNEL = 1,
+   IORES_DESC_ACPI_TABLES  = 2,
+   IORES_DESC_ACPI_NV_STORAGE  = 3,
+   IORES_DESC_GART = 4,
+   IORES_DESC_PERSISTENT_MEMORY= 5,
+   IORES_DESC_PERSISTENT_MEMORY_LEGACY = 6,
+};
 
 /* helpers to define resources */
 #define DEFINE_RES_NAMED(_start, _size, _name, _flags) \
@@ -120,6 +138,7 @@ struct resource {
.end = (_start) + (_size) - 1,  \
.name = (_name),\
.flags = (_flags),  \
+   .desc = IORES_DESC_NONE,\
}
 
 #define DEFINE_RES_IO_NAMED(_start, _size, _name)  \
diff --git a/kernel/resource.c b/kernel/resource.c
index d30a175..65eca4d 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -949,6 +949,7 @@ static void __init __reserve_region_with_split(struct 
resource *root,
res->start = start;
res->end = end;
res->flags = IORESOURCE_BUSY;
+   res->desc = IORES_DESC_NONE;
 
while (1) {
 
@@ -983,6 +984,7 @@ static void __init __reserve_region_with_split(struct 
resource *root,
next_res->start = conflict->end + 1;
next_res->end = end;
next_res->flags = IORESOURCE_BUSY;
+   next_res->desc = IORES_DESC_NONE;
}
} else {
res->start = conflict->end + 1;
@@ -1074,6 +1076,7 @@ struct resource * __request_region(struct resource 
*parent,
res->end = start + n - 1;
res->flags = resource_type(parent) | resource_ext_type(parent);
res->flags |= IORESOURCE_BUSY | flags;
+   res->desc = IORES_DESC_NONE;
 
write_lock(_lock);
 
@@ -1238,6 +1241,7 @@ int release_mem_region_adjustable(struct resource *parent,
new_res->start = end + 1;
new_res->end = res->end;
new_res->flags = res->flags;
+   new_res->desc = res->desc;
new_res->parent = res->parent;
new_res->sibling = res->sibling;
new_res->child = NULL;
@@ -1413,6 +1417,7 @@ static int __init reserve_setup(char *str)
res->start = io_start;
res->end = io_start + io_num - 1;
res->flags = IORESOURCE_BUSY;
+   res->desc = IORES_DESC_NONE;
res->child = NULL;
if (request_resource(res->start >= 0x1 ? 
_resource : _resource, res) == 0)

[PATCH v2 06/16] arch: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to 'flags' of resource ranges with
"System RAM", "Kernel code", "Kernel data", and "Kernel bss".

Note that:
 - IORESOURCE_SYSRAM (i.e. modifier bit) is set to 'flags'
   when IORESOURCE_MEM is already set.  IORESOURCE_SYSTEM_RAM
   is defined as (IORESOURCE_MEM|IORESOURCE_SYSRAM).
 - Some archs do not set 'flags' for children nodes, such as
   "Kernel code".  This patch does not change 'flags' in this
   case.

Cc: linux-a...@vger.kernel.org
Signed-off-by: Toshi Kani 
---
 arch/arm/kernel/setup.c   |6 +++---
 arch/arm64/kernel/setup.c |6 +++---
 arch/avr32/kernel/setup.c |6 +++---
 arch/m32r/kernel/setup.c  |4 ++--
 arch/mips/kernel/setup.c  |   10 ++
 arch/parisc/mm/init.c |6 +++---
 arch/powerpc/mm/mem.c |2 +-
 arch/s390/kernel/setup.c  |8 
 arch/score/kernel/setup.c |2 +-
 arch/sh/kernel/setup.c|8 
 arch/sparc/mm/init_64.c   |8 
 arch/tile/kernel/setup.c  |   11 ---
 arch/unicore32/kernel/setup.c |6 +++---
 13 files changed, 45 insertions(+), 38 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 20edd34..ae44e09 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -173,13 +173,13 @@ static struct resource mem_res[] = {
.name = "Kernel code",
.start = 0,
.end = 0,
-   .flags = IORESOURCE_MEM
+   .flags = IORESOURCE_SYSTEM_RAM
},
{
.name = "Kernel data",
.start = 0,
.end = 0,
-   .flags = IORESOURCE_MEM
+   .flags = IORESOURCE_SYSTEM_RAM
}
 };
 
@@ -781,7 +781,7 @@ static void __init request_standard_resources(const struct 
machine_desc *mdesc)
res->name  = "System RAM";
res->start = 
__pfn_to_phys(memblock_region_memory_base_pfn(region));
res->end = 
__pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
-   res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
request_resource(_resource, res);
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..450987d 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -73,13 +73,13 @@ static struct resource mem_res[] = {
.name = "Kernel code",
.start = 0,
.end = 0,
-   .flags = IORESOURCE_MEM
+   .flags = IORESOURCE_SYSTEM_RAM
},
{
.name = "Kernel data",
.start = 0,
.end = 0,
-   .flags = IORESOURCE_MEM
+   .flags = IORESOURCE_SYSTEM_RAM
}
 };
 
@@ -210,7 +210,7 @@ static void __init request_standard_resources(void)
res->name  = "System RAM";
res->start = 
__pfn_to_phys(memblock_region_memory_base_pfn(region));
res->end = 
__pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
-   res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
request_resource(_resource, res);
 
diff --git a/arch/avr32/kernel/setup.c b/arch/avr32/kernel/setup.c
index 209ae5a..e692889 100644
--- a/arch/avr32/kernel/setup.c
+++ b/arch/avr32/kernel/setup.c
@@ -49,13 +49,13 @@ static struct resource __initdata kernel_data = {
.name   = "Kernel data",
.start  = 0,
.end= 0,
-   .flags  = IORESOURCE_MEM,
+   .flags  = IORESOURCE_SYSTEM_RAM,
 };
 static struct resource __initdata kernel_code = {
.name   = "Kernel code",
.start  = 0,
.end= 0,
-   .flags  = IORESOURCE_MEM,
+   .flags  = IORESOURCE_SYSTEM_RAM,
.sibling = _data,
 };
 
@@ -134,7 +134,7 @@ add_physical_memory(resource_size_t start, resource_size_t 
end)
new->start = start;
new->end = end;
new->name = "System RAM";
-   new->flags = IORESOURCE_MEM;
+   new->flags = IORESOURCE_SYSTEM_RAM;
 
*pprev = new;
 }
diff --git a/arch/m32r/kernel/setup.c b/arch/m32r/kernel/setup.c
index 0392112..5f62ff0 100644
--- a/arch/m32r/kernel/setup.c
+++ b/arch/m32r/kernel/setup.c
@@ -70,14 +70,14 @@ static struct resource data_resource = {
.name   = "Kernel data",
.start  = 0,
.end= 0,
-   .flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+   .flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
.name   = "Kernel code",
.start  = 0,
.end= 0,
-   .flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+   .flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 unsigned long memory_start;
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 

[PATCH v2 09/16] drivers: Initialize resource entry to zero

[Toshi Kani]

I/O resource descriptor, 'desc' added to struct resource, needs
to be initialized to zero by default.  Some drivers call kmalloc()
to allocate a resource entry, but does not initialize it to zero
by memset().  Change these drivers to call kzalloc(), instead.

Cc: linux-a...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Toshi Kani 
---
 drivers/acpi/acpi_platform.c   |2 +-
 drivers/parisc/eisa_enumerator.c   |4 ++--
 drivers/rapidio/rio.c  |8 
 drivers/sh/superhyway/superhyway.c |2 +-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 296b7a1..b6f7fa3 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -62,7 +62,7 @@ struct platform_device *acpi_create_platform_device(struct 
acpi_device *adev)
if (count < 0) {
return NULL;
} else if (count > 0) {
-   resources = kmalloc(count * sizeof(struct resource),
+   resources = kzalloc(count * sizeof(struct resource),
GFP_KERNEL);
if (!resources) {
dev_err(>dev, "No memory for resources\n");
diff --git a/drivers/parisc/eisa_enumerator.c b/drivers/parisc/eisa_enumerator.c
index a656d9e..21905fe 100644
--- a/drivers/parisc/eisa_enumerator.c
+++ b/drivers/parisc/eisa_enumerator.c
@@ -91,7 +91,7 @@ static int configure_memory(const unsigned char *buf,
for (i=0;iname = name;
@@ -183,7 +183,7 @@ static int configure_port(const unsigned char *buf, struct 
resource *io_parent,
for (i=0;iname = board;
res->start = get_16(buf+len+1);
res->end = get_16(buf+len+1)+(c_PORT_SIZE_MASK)+1;
diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
index d7b87c6..e220edc 100644
--- a/drivers/rapidio/rio.c
+++ b/drivers/rapidio/rio.c
@@ -117,7 +117,7 @@ int rio_request_inb_mbox(struct rio_mport *mport,
if (mport->ops->open_inb_mbox == NULL)
goto out;
 
-   res = kmalloc(sizeof(struct resource), GFP_KERNEL);
+   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
 
if (res) {
rio_init_mbox_res(res, mbox, mbox);
@@ -185,7 +185,7 @@ int rio_request_outb_mbox(struct rio_mport *mport,
if (mport->ops->open_outb_mbox == NULL)
goto out;
 
-   res = kmalloc(sizeof(struct resource), GFP_KERNEL);
+   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
 
if (res) {
rio_init_mbox_res(res, mbox, mbox);
@@ -285,7 +285,7 @@ int rio_request_inb_dbell(struct rio_mport *mport,
 {
int rc = 0;
 
-   struct resource *res = kmalloc(sizeof(struct resource), GFP_KERNEL);
+   struct resource *res = kzalloc(sizeof(struct resource), GFP_KERNEL);
 
if (res) {
rio_init_dbell_res(res, start, end);
@@ -360,7 +360,7 @@ int rio_release_inb_dbell(struct rio_mport *mport, u16 
start, u16 end)
 struct resource *rio_request_outb_dbell(struct rio_dev *rdev, u16 start,
u16 end)
 {
-   struct resource *res = kmalloc(sizeof(struct resource), GFP_KERNEL);
+   struct resource *res = kzalloc(sizeof(struct resource), GFP_KERNEL);
 
if (res) {
rio_init_dbell_res(res, start, end);
diff --git a/drivers/sh/superhyway/superhyway.c 
b/drivers/sh/superhyway/superhyway.c
index 2d9e7f3..bb1fb771 100644
--- a/drivers/sh/superhyway/superhyway.c
+++ b/drivers/sh/superhyway/superhyway.c
@@ -66,7 +66,7 @@ int superhyway_add_device(unsigned long base, struct 
superhyway_device *sdev,
superhyway_read_vcr(dev, base, >vcr);
 
if (!dev->resource) {
-   dev->resource = kmalloc(sizeof(struct resource), GFP_KERNEL);
+   dev->resource = kzalloc(sizeof(struct resource), GFP_KERNEL);
if (!dev->resource) {
kfree(dev);
return -ENOMEM;
--
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 08/16] xen, mm: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to 'flags' of struct resource entries
with "System RAM".

Cc: Andrew Morton 
Cc: Konrad Rzeszutek Wilk 
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Toshi Kani 
---
 drivers/xen/balloon.c |2 +-
 mm/memory_hotplug.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 12eab50..dc4305b 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -257,7 +257,7 @@ static struct resource 
*additional_memory_resource(phys_addr_t size)
return NULL;
 
res->name = "System RAM";
-   res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
ret = allocate_resource(_resource, res,
size, 0, -1,
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 67d488a..9458423 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -136,7 +136,7 @@ static struct resource *register_memory_resource(u64 start, 
u64 size)
res->name = "System RAM";
res->start = start;
res->end = start + size - 1;
-   res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
if (request_resource(_resource, res) < 0) {
pr_debug("System RAM resource %pR cannot be added\n", res);
kfree(res);
--
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 07/16] kexec: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to 'flags' and IORES_DESC_CRASH_KERNEL
to 'desc' of "Crash kernel" resource ranges, which are child
nodes of System RAM.

Change crash_shrink_memory() to set IORESOURCE_SYSTEM_RAM for
a System RAM range.

Change kexec_add_buffer() to call walk_iomem_res() with
IORESOURCE_SYSTEM_RAM type for "Crash kernel".

Cc: Andrew Morton 
Cc: Dave Young 
Signed-off-by: Toshi Kani 
---
 kernel/kexec_core.c |8 +---
 kernel/kexec_file.c |2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 11b64a6..80bff05 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -66,13 +66,15 @@ struct resource crashk_res = {
.name  = "Crash kernel",
.start = 0,
.end   = 0,
-   .flags = IORESOURCE_BUSY | IORESOURCE_MEM
+   .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+   .desc  = IORES_DESC_CRASH_KERNEL
 };
 struct resource crashk_low_res = {
.name  = "Crash kernel",
.start = 0,
.end   = 0,
-   .flags = IORESOURCE_BUSY | IORESOURCE_MEM
+   .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+   .desc  = IORES_DESC_CRASH_KERNEL
 };
 
 int kexec_should_crash(struct task_struct *p)
@@ -934,7 +936,7 @@ int crash_shrink_memory(unsigned long new_size)
 
ram_res->start = end;
ram_res->end = crashk_res.end;
-   ram_res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+   ram_res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
ram_res->name = "System RAM";
 
crashk_res.end = end - 1;
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b70ada0..c245085 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -523,7 +523,7 @@ int kexec_add_buffer(struct kimage *image, char *buffer, 
unsigned long bufsz,
/* Walk the RAM ranges and allocate a suitable range for the buffer */
if (image->type == KEXEC_TYPE_CRASH)
ret = walk_iomem_res("Crash kernel",
-IORESOURCE_MEM | IORESOURCE_BUSY,
+IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
 crashk_res.start, crashk_res.end, kbuf,
 locate_mem_hole_callback);
else
--
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 10/16] resource: Change walk_system_ram to use System RAM type

[Toshi Kani]

Now that all System RAM resource entries have been initialized
to IORESOURCE_SYSTEM_RAM type, change walk_system_ram_res() and
walk_system_ram_range() to call find_next_iomem_res() by setting
IORESOURCE_SYSTEM_RAM to @res.flags and NULL to @name.  With
this change, they walk through the iomem table to find System
RAM ranges without using strcmp().

No functional change is made to the interfaces.

Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Dan Williams 
Signed-off-by: Toshi Kani 
---
 kernel/resource.c |   22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 65eca4d..1d3ea50 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -415,9 +415,9 @@ int walk_iomem_res(char *name, unsigned long flags, u64 
start, u64 end,
 }
 
 /*
- * This function calls callback against all memory range of "System RAM"
- * which are marked as IORESOURCE_MEM and IORESOUCE_BUSY.
- * Now, this function is only for "System RAM". This function deals with
+ * This function calls callback against all memory range of System RAM
+ * which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY.
+ * Now, this function is only for System RAM. This function deals with
  * full ranges and not pfn. If resources are not pfn aligned, dealing
  * with pfn can truncate ranges.
  */
@@ -430,10 +430,10 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
 
res.start = start;
res.end = end;
-   res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
orig_end = res.end;
while ((res.start < res.end) &&
-   (!find_next_iomem_res(, "System RAM", true))) {
+   (!find_next_iomem_res(, NULL, true))) {
ret = (*func)(res.start, res.end, arg);
if (ret)
break;
@@ -446,9 +446,9 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
 #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
 
 /*
- * This function calls callback against all memory range of "System RAM"
- * which are marked as IORESOURCE_MEM and IORESOUCE_BUSY.
- * Now, this function is only for "System RAM".
+ * This function calls callback against all memory range of System RAM
+ * which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY.
+ * Now, this function is only for System RAM.
  */
 int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
void *arg, int (*func)(unsigned long, unsigned long, void *))
@@ -460,10 +460,10 @@ int walk_system_ram_range(unsigned long start_pfn, 
unsigned long nr_pages,
 
res.start = (u64) start_pfn << PAGE_SHIFT;
res.end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
-   res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
orig_end = res.end;
while ((res.start < res.end) &&
-   (find_next_iomem_res(, "System RAM", true) >= 0)) {
+   (find_next_iomem_res(, NULL, true) >= 0)) {
pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT;
end_pfn = (res.end + 1) >> PAGE_SHIFT;
if (end_pfn > pfn)
@@ -484,7 +484,7 @@ static int __is_ram(unsigned long pfn, unsigned long 
nr_pages, void *arg)
 }
 /*
  * This generic page_is_ram() returns true if specified address is
- * registered as "System RAM" in iomem_resource list.
+ * registered as System RAM in iomem_resource list.
  */
 int __weak page_is_ram(unsigned long pfn)
 {
--
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 12/16] memremap: Change region_intersects() to take @flags and @desc

[Toshi Kani]

Change region_intersects() to identify a target with @flags
and @desc, instead of @name with strcmp().

Change the callers of region_intersects(), memremap() and
devm_memremap(), to set IORESOURCE_SYSTEM_RAM to @flags and
IORES_DESC_NONE to @desc for searching System RAM.

Also, export region_intersects() so that the EINJ driver can
call this function in a later patch.

Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Dan Williams 
Signed-off-by: Toshi Kani 
---
 include/linux/mm.h |3 ++-
 kernel/memremap.c  |   13 +++--
 kernel/resource.c  |   26 +++---
 3 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 00bad77..82f6ca9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -362,7 +362,8 @@ enum {
REGION_MIXED,
 };
 
-int region_intersects(resource_size_t offset, size_t size, const char *type);
+int region_intersects(resource_size_t offset, size_t size, unsigned long flags,
+   unsigned long desc);
 
 /* Support for virtually mapped pages */
 struct page *vmalloc_to_page(const void *addr);
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 7658d32..47f3436 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -44,7 +44,7 @@ static void *try_ram_remap(resource_size_t offset, size_t 
size)
  * being mapped does not have i/o side effects and the __iomem
  * annotation is not applicable.
  *
- * MEMREMAP_WB - matches the default mapping for "System RAM" on
+ * MEMREMAP_WB - matches the default mapping for System RAM on
  * the architecture.  This is usually a read-allocate write-back cache.
  * Morever, if MEMREMAP_WB is specified and the requested remap region is RAM
  * memremap() will bypass establishing a new mapping and instead return
@@ -53,11 +53,12 @@ static void *try_ram_remap(resource_size_t offset, size_t 
size)
  * MEMREMAP_WT - establish a mapping whereby writes either bypass the
  * cache or are written through to memory and never exist in a
  * cache-dirty state with respect to program visibility.  Attempts to
- * map "System RAM" with this mapping type will fail.
+ * map System RAM with this mapping type will fail.
  */
 void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 {
-   int is_ram = region_intersects(offset, size, "System RAM");
+   int is_ram = region_intersects(offset, size,
+   IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE);
void *addr = NULL;
 
if (is_ram == REGION_MIXED) {
@@ -73,7 +74,7 @@ void *memremap(resource_size_t offset, size_t size, unsigned 
long flags)
 * MEMREMAP_WB is special in that it can be satisifed
 * from the direct map.  Some archs depend on the
 * capability of memremap() to autodetect cases where
-* the requested range is potentially in "System RAM"
+* the requested range is potentially in System RAM.
 */
if (is_ram == REGION_INTERSECTS)
addr = try_ram_remap(offset, size);
@@ -85,7 +86,7 @@ void *memremap(resource_size_t offset, size_t size, unsigned 
long flags)
 * If we don't have a mapping yet and more request flags are
 * pending then we will be attempting to establish a new virtual
 * address mapping.  Enforce that this mapping is not aliasing
-* "System RAM"
+* System RAM.
 */
if (!addr && is_ram == REGION_INTERSECTS && flags) {
WARN_ONCE(1, "memremap attempted on ram %pa size: %#lx\n",
@@ -163,7 +164,7 @@ static void devm_memremap_pages_release(struct device *dev, 
void *res)
 void *devm_memremap_pages(struct device *dev, struct resource *res)
 {
int is_ram = region_intersects(res->start, resource_size(res),
-   "System RAM");
+   IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE);
struct page_map *page_map;
int error, nid;
 
diff --git a/kernel/resource.c b/kernel/resource.c
index 1d3ea50..52e6380 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -496,31 +496,34 @@ EXPORT_SYMBOL_GPL(page_is_ram);
  * region_intersects() - determine intersection of region with known resources
  * @start: region start address
  * @size: size of region
- * @name: name of resource (in iomem_resource)
+ * @flags: flags of resource (in iomem_resource)
+ * @desc: descriptor of resource (in iomem_resource) or IORES_DESC_NONE
  *
  * Check if the specified region partially overlaps or fully eclipses a
- * resource identified by @name.  Return REGION_DISJOINT if the region
- * does not overlap @name, return REGION_MIXED if the region overlaps
- * @type and another resource, and return REGION_INTERSECTS if the
- * region overlaps @type and no other defined resource. Note, that
- * REGION_INTERSECTS is also returned in the case when the specified
- * region overlaps RAM and undefined memory holes.

[PATCH v2 13/16] resource: Add walk_iomem_res_desc()

[Toshi Kani]

Add a new interface, walk_iomem_res_desc(), which walks through
the iomem table by identifying a target with @flags and @desc.
This interface provides the same functionality as walk_iomem_res(),
but does not use strcmp() to @name for better efficiency.

walk_iomem_res() is deprecated, but is maintained for backward
compatibility since walk_iomem_res_desc() requires 'desc' of
a target resource entry be initialized with its descriptor ID.

Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: Dan Williams 
Signed-off-by: Toshi Kani 
---
 include/linux/ioport.h |3 ++
 kernel/resource.c  |   58 ++--
 2 files changed, 54 insertions(+), 7 deletions(-)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index b7350c0..c4cd43a 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -269,6 +269,9 @@ extern int
 walk_system_ram_res(u64 start, u64 end, void *arg,
int (*func)(u64, u64, void *));
 extern int
+walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 
end,
+   void *arg, int (*func)(u64, u64, void *));
+extern int
 walk_iomem_res(char *name, unsigned long flags, u64 start, u64 end, void *arg,
   int (*func)(u64, u64, void *));
 
diff --git a/kernel/resource.c b/kernel/resource.c
index 52e6380..579b0e1 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -334,13 +334,14 @@ EXPORT_SYMBOL(release_resource);
 
 /*
  * Finds the lowest iomem reosurce exists with-in [res->start.res->end)
- * the caller must specify res->start, res->end, res->flags and "name".
- * If found, returns 0, res is overwritten, if not found, returns -1.
+ * the caller must specify res->start, res->end, res->flags, and optionally
+ * desc and "name".  If found, returns 0, res is overwritten, if not found,
+ * returns -1.
  * This walks through whole tree and not just first level children
  * until and unless first_level_children_only is true.
  */
-static int find_next_iomem_res(struct resource *res, char *name,
-  bool first_level_children_only)
+static int find_next_iomem_res(struct resource *res, unsigned long desc,
+   char *name, bool first_level_children_only)
 {
resource_size_t start, end;
struct resource *p;
@@ -360,6 +361,8 @@ static int find_next_iomem_res(struct resource *res, char 
*name,
for (p = iomem_resource.child; p; p = next_resource(p, sibling_only)) {
if ((p->flags & res->flags) != res->flags)
continue;
+   if ((desc != IORES_DESC_NONE) && (desc != p->desc))
+   continue;
if (name && strcmp(p->name, name))
continue;
if (p->start > end) {
@@ -387,10 +390,51 @@ static int find_next_iomem_res(struct resource *res, char 
*name,
  * All the memory ranges which overlap start,end and also match flags and
  * name are valid candidates.
  *
+ * @desc: I/O resource descriptor. Use IORES_DESC_NONE to skip this check.
+ * @flags: I/O resource flags
+ * @start: start addr
+ * @end: end addr
+ *
+ * NOTE: For a new descriptor search, define a new IORES_DESC in
+ *  and set it to 'desc' of a target resource entry.
+ */
+int walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start,
+   u64 end, void *arg, int (*func)(u64, u64, void *))
+{
+   struct resource res;
+   u64 orig_end;
+   int ret = -1;
+
+   res.start = start;
+   res.end = end;
+   res.flags = flags;
+   orig_end = res.end;
+
+   while ((res.start < res.end) &&
+   (!find_next_iomem_res(, desc, NULL, false))) {
+   ret = (*func)(res.start, res.end, arg);
+   if (ret)
+   break;
+   res.start = res.end + 1;
+   res.end = orig_end;
+   }
+
+   return ret;
+}
+
+/*
+ * Walks through iomem resources and calls func() with matching resource
+ * ranges. This walks through whole tree and not just first level children.
+ * All the memory ranges which overlap start,end and also match flags and
+ * name are valid candidates.
+ *
  * @name: name of resource
  * @flags: resource flags
  * @start: start addr
  * @end: end addr
+ *
+ * NOTE: This function is deprecated and should not be used in new code.
+ *   Use walk_iomem_res_desc(), instead.
  */
 int walk_iomem_res(char *name, unsigned long flags, u64 start, u64 end,
void *arg, int (*func)(u64, u64, void *))
@@ -404,7 +448,7 @@ int walk_iomem_res(char *name, unsigned long flags, u64 
start, u64 end,
res.flags = flags;
orig_end = res.end;
while ((res.start < res.end) &&
-   (!find_next_iomem_res(, name, false))) {
+   (!find_next_iomem_res(, IORES_DESC_NONE, name, false))) {
ret = (*func)(res.start, res.end, arg);
if (ret)

[PATCH v2 14/16] x86,nvdimm,kexec: Use walk_iomem_res_desc() for iomem search

[Toshi Kani]

Change to call walk_iomem_res_desc() for searching resource entries
with the following names:
 "ACPI Tables"
 "ACPI Non-volatile Storage"
 "Persistent Memory (legacy)"
 "Crash kernel"

Note, the caller of walk_iomem_res() with "GART" is left unchanged
because this entry may be initialized by out-of-tree drivers, which
do not have 'desc' set to IORES_DESC_GART.

Cc: Borislav Petkov 
Cc: Dan Williams 
Cc: Dave Young 
Cc: x...@kernel.org
Cc: linux-nvd...@lists.01.org
Signed-off-by: Toshi Kani 
---
 arch/x86/kernel/crash.c |4 ++--
 arch/x86/kernel/pmem.c  |4 ++--
 drivers/nvdimm/e820.c   |2 +-
 kernel/kexec_file.c |8 
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 2c1910f..082373b 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -588,12 +588,12 @@ int crash_setup_memmap_entries(struct kimage *image, 
struct boot_params *params)
/* Add ACPI tables */
cmd.type = E820_ACPI;
flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-   walk_iomem_res("ACPI Tables", flags, 0, -1, ,
+   walk_iomem_res_desc(IORES_DESC_ACPI_TABLES, flags, 0, -1, ,
   memmap_entry_callback);
 
/* Add ACPI Non-volatile Storage */
cmd.type = E820_NVS;
-   walk_iomem_res("ACPI Non-volatile Storage", flags, 0, -1, ,
+   walk_iomem_res_desc(IORES_DESC_ACPI_NV_STORAGE, flags, 0, -1, ,
memmap_entry_callback);
 
/* Add crashk_low_res region */
diff --git a/arch/x86/kernel/pmem.c b/arch/x86/kernel/pmem.c
index 14415af..92f7014 100644
--- a/arch/x86/kernel/pmem.c
+++ b/arch/x86/kernel/pmem.c
@@ -13,11 +13,11 @@ static int found(u64 start, u64 end, void *data)
 
 static __init int register_e820_pmem(void)
 {
-   char *pmem = "Persistent Memory (legacy)";
struct platform_device *pdev;
int rc;
 
-   rc = walk_iomem_res(pmem, IORESOURCE_MEM, 0, -1, NULL, found);
+   rc = walk_iomem_res_desc(IORES_DESC_PERSISTENT_MEMORY_LEGACY,
+IORESOURCE_MEM, 0, -1, NULL, found);
if (rc <= 0)
return 0;
 
diff --git a/drivers/nvdimm/e820.c b/drivers/nvdimm/e820.c
index b0045a5..95825b3 100644
--- a/drivers/nvdimm/e820.c
+++ b/drivers/nvdimm/e820.c
@@ -55,7 +55,7 @@ static int e820_pmem_probe(struct platform_device *pdev)
for (p = iomem_resource.child; p ; p = p->sibling) {
struct nd_region_desc ndr_desc;
 
-   if (strncmp(p->name, "Persistent Memory (legacy)", 26) != 0)
+   if (p->desc != IORES_DESC_PERSISTENT_MEMORY_LEGACY)
continue;
 
memset(_desc, 0, sizeof(ndr_desc));
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index c245085..e2bd737 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -522,10 +522,10 @@ int kexec_add_buffer(struct kimage *image, char *buffer, 
unsigned long bufsz,
 
/* Walk the RAM ranges and allocate a suitable range for the buffer */
if (image->type == KEXEC_TYPE_CRASH)
-   ret = walk_iomem_res("Crash kernel",
-IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
-crashk_res.start, crashk_res.end, kbuf,
-locate_mem_hole_callback);
+   ret = walk_iomem_res_desc(IORES_DESC_CRASH_KERNEL,
+   IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
+   crashk_res.start, crashk_res.end, kbuf,
+   locate_mem_hole_callback);
else
ret = walk_system_ram_res(0, -1, kbuf,
  locate_mem_hole_callback);
--
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 15/16] checkpatch: Add warning on deprecated walk_iomem_res

[Toshi Kani]

Use of walk_iomem_res() is deprecated in new code.  Change
checkpatch.pl to check new use of walk_iomem_res() and suggest
to use walk_iomem_res_desc() instead.

Cc: Andy Whitcroft 
Cc: Joe Perches 
Cc: Borislav Petkov 
Signed-off-by: Toshi Kani 
---
 scripts/checkpatch.pl |6 ++
 1 file changed, 6 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 2b3c228..07a2dbe 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3424,6 +3424,12 @@ sub process {
}
}
 
+# check for uses of walk_iomem_res()
+   if ($line =~ /\bwalk_iomem_res\(/) {
+   WARN("walk_iomem_res",
+"Use of walk_iomem_res is deprecated, please use 
walk_iomem_res_desc instead\n" . $herecurr)
+   }
+
 # check for new typedefs, only function parameters and sparse annotations
 # make sense.
if ($line =~ /\btypedef\s/ &&
--
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 04/16] x86/e820: Set System RAM type and descriptor

[Toshi Kani]

Change e820_reserve_resources() to set 'flags' and 'desc' from
e820 types.

IORESOURCE_SYSTEM_RAM is set to 'flags' for System RAM, which
are E820_RESERVED_KERN and E820_RAM.  IORESOURCE_SYSTEM_RAM is
also set to "Kernel data", "Kernel code", and "Kernel bss",
which are children nodes of System RAM.

I/O resource descriptor is set to 'desc' for entries that are
(and will be) target ranges of walk_iomem_res() and
region_intersects().

Cc: Borislav Petkov 
Cc: x...@kernel.org
Signed-off-by: Toshi Kani 
---
 arch/x86/kernel/e820.c  |   38 +-
 arch/x86/kernel/setup.c |6 +++---
 2 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 569c1e4..837365f 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -925,6 +925,41 @@ static const char *e820_type_to_string(int e820_type)
}
 }
 
+static unsigned long e820_type_to_iomem_type(int e820_type)
+{
+   switch (e820_type) {
+   case E820_RESERVED_KERN:
+   case E820_RAM:
+   return IORESOURCE_SYSTEM_RAM;
+   case E820_ACPI:
+   case E820_NVS:
+   case E820_UNUSABLE:
+   case E820_PRAM:
+   case E820_PMEM:
+   default:
+   return IORESOURCE_MEM;
+   }
+}
+
+static unsigned long e820_type_to_iores_desc(int e820_type)
+{
+   switch (e820_type) {
+   case E820_ACPI:
+   return IORES_DESC_ACPI_TABLES;
+   case E820_NVS:
+   return IORES_DESC_ACPI_NV_STORAGE;
+   case E820_PMEM:
+   return IORES_DESC_PERSISTENT_MEMORY;
+   case E820_PRAM:
+   return IORES_DESC_PERSISTENT_MEMORY_LEGACY;
+   case E820_RESERVED_KERN:
+   case E820_RAM:
+   case E820_UNUSABLE:
+   default:
+   return IORES_DESC_NONE;
+   }
+}
+
 static bool do_mark_busy(u32 type, struct resource *res)
 {
/* this is the legacy bios/dos rom-shadow + mmio region */
@@ -967,7 +1002,8 @@ void __init e820_reserve_resources(void)
res->start = e820.map[i].addr;
res->end = end;
 
-   res->flags = IORESOURCE_MEM;
+   res->flags = e820_type_to_iomem_type(e820.map[i].type);
+   res->desc = e820_type_to_iores_desc(e820.map[i].type);
 
/*
 * don't register the region that could be conflicted with
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d2bbe34..a492c30 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -152,21 +152,21 @@ static struct resource data_resource = {
.name   = "Kernel data",
.start  = 0,
.end= 0,
-   .flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+   .flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
.name   = "Kernel code",
.start  = 0,
.end= 0,
-   .flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+   .flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
.name   = "Kernel bss",
.start  = 0,
.end= 0,
-   .flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+   .flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 
--
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 11/16] arm/samsung: Change s3c_pm_run_res() to use System RAM type

[Toshi Kani]

Change s3c_pm_run_res() to check with IORESOURCE_SYSTEM_RAM,
instead of strcmp() with "System RAM", to walk through
System RAM ranges in the iomem table.

No functional change is made to the interface.

Cc: Krzysztof Kozlowski 
Cc: linux-samsung-...@vger.kernel.org
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Toshi Kani 
---
 arch/arm/plat-samsung/pm-check.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/pm-check.c b/arch/arm/plat-samsung/pm-check.c
index 04aff2c..70f2f69 100644
--- a/arch/arm/plat-samsung/pm-check.c
+++ b/arch/arm/plat-samsung/pm-check.c
@@ -53,8 +53,8 @@ static void s3c_pm_run_res(struct resource *ptr, run_fn_t fn, 
u32 *arg)
if (ptr->child != NULL)
s3c_pm_run_res(ptr->child, fn, arg);
 
-   if ((ptr->flags & IORESOURCE_MEM) &&
-   strcmp(ptr->name, "System RAM") == 0) {
+   if ((ptr->flags & IORESOURCE_SYSTEM_RAM)
+   == IORESOURCE_SYSTEM_RAM) {
S3C_PMDBG("Found system RAM at %08lx..%08lx\n",
  (unsigned long)ptr->start,
  (unsigned long)ptr->end);
--
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 00/16] Enhance iomem search interfaces and support EINJ to NVDIMM

[Toshi Kani]

This patch-set enhances the iomem table and its search interfacs, and
then changes EINJ to support NVDIMM.

 - Patches 1-2 add a new System RAM type, IORESOURCE_SYSTEM_RAM, and
   make the iomem search interfaces work with resource flags with
   modifier bits set.  IORESOURCE_SYSTEM_RAM has IORESOURCE_MEM bit set
   for backward compatibility.

 - Patch 3 adds a new field, I/O resource descriptor, in struct resource.
   Drivers can assign their unique descritor to a range when they
   support the iomem search interfaces.

 - Patches 4-9 changes initializations of resource entries.  They set
   the System RAM type to System RAM ranges, set I/O resource descriptors
   to the regions targeted by the iomem search interfaces, and change
   to call kzalloc() where kmalloc() is used to allocate struct resource
   ranges.

 - Patches 10-14 extend the iomem interfaces to check System RAM ranges
   with the System RAM type and the I/O resource descriptor.

 - Patch 15 adds a check to checkpatch.pl to warn on new use of
   walk_iomem_res().

 - Patch 16 changes the EINJ driver to allow injecting a memory error
   to NVDIMM.

---
v2:
 - Add 'desc' to struct resource, and add a new iomem interface to
   search with the desc. (Borislav Petkov)
 - Add a check to checkpatch.pl to warn on new use of walk_iomem_res().
   (Borislav Petkov)

v1:
 - Searching for System RAM in the resource table should not require
   strcmp(). (Borislav Petkov)
 - Add a new System RAM type as a modifier to IORESOURCE_MEM.
   (Linus Torvalds)
 - NVDIMM check needs to be able to distinguish legacy and NFIT pmem
   ranges. (Dan Williams)

---
Toshi Kani (16):
 01/16 resource: Add System RAM resource type
 02/16 resource: make resource flags handled properly
 03/16 resource: Add I/O resource descriptor
 04/16 x86/e820: Set System RAM type and descriptor
 05/16 ia64: Set System RAM type and descriptor
 06/16 arch: Set IORESOURCE_SYSTEM_RAM to System RAM
 07/16 kexec: Set IORESOURCE_SYSTEM_RAM to System RAM
 08/16 xen, mm: Set IORESOURCE_SYSTEM_RAM to System RAM
 09/16 drivers: Initialize resource entry to zero
 10/16 resource: Change walk_system_ram to use System RAM type
 11/16 arm/samsung: Change s3c_pm_run_res() to use System RAM type
 12/16 memremap: Change region_intersects() to take @flags and @desc
 13/16 resource: Add walk_iomem_res_desc()
 14/16 x86,nvdimm,kexec: Use walk_iomem_res_desc() for iomem search
 15/16 checkpatch: Add warning on deprecated walk_iomem_res
 16/16 ACPI/EINJ: Allow memory error injection to NVDIMM

---
 arch/arm/kernel/setup.c|   6 +-
 arch/arm/plat-samsung/pm-check.c   |   4 +-
 arch/arm64/kernel/setup.c  |   6 +-
 arch/avr32/kernel/setup.c  |   6 +-
 arch/ia64/kernel/efi.c |  13 -
 arch/ia64/kernel/setup.c   |   6 +-
 arch/m32r/kernel/setup.c   |   4 +-
 arch/mips/kernel/setup.c   |  10 ++--
 arch/parisc/mm/init.c  |   6 +-
 arch/powerpc/mm/mem.c  |   2 +-
 arch/s390/kernel/setup.c   |   8 +--
 arch/score/kernel/setup.c  |   2 +-
 arch/sh/kernel/setup.c |   8 +--
 arch/sparc/mm/init_64.c|   8 +--
 arch/tile/kernel/setup.c   |  11 +++-
 arch/unicore32/kernel/setup.c  |   6 +-
 arch/x86/kernel/crash.c|   4 +-
 arch/x86/kernel/e820.c |  38 -
 arch/x86/kernel/pmem.c |   4 +-
 arch/x86/kernel/setup.c|   6 +-
 drivers/acpi/acpi_platform.c   |   2 +-
 drivers/acpi/apei/einj.c   |  15 +++--
 drivers/nvdimm/e820.c  |   2 +-
 drivers/parisc/eisa_enumerator.c   |   4 +-
 drivers/rapidio/rio.c  |   8 +--
 drivers/sh/superhyway/superhyway.c |   2 +-
 drivers/xen/balloon.c  |   2 +-
 include/linux/ioport.h |  33 +++
 include/linux/mm.h |   3 +-
 kernel/kexec_core.c|   8 ++-
 kernel/kexec_file.c|   8 +--
 kernel/memremap.c  |  13 +++--
 kernel/resource.c  | 110 +++--
 mm/memory_hotplug.c|   2 +-
 scripts/checkpatch.pl  |   6 ++
 35 files changed, 265 insertions(+), 111 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: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks

[Luck, Tony]

mce_in_kernel_recov() should check whether we have a fix up entry for the 
specific IP that hit the machine check before rating the severity as kernel 
recoverable.

If we add more functions (for different cache behaviour, or to optimize for 
specific processor model) we can make sure to put them all together inside 
begin/end labels.

We would run into trouble if we want to have some in-line macros for use from 
arbitrary C-code like we have for the page fault case.

I might make the arbitrary %rax value be #PF and #MC to reflect the h/w fault 
that got us here rather than -EINVAL/-EFAULT. But that's just bike shedding.

But now we are back to having the fault handler poke %rax again, which made 
Andy twitch before. 

Sent from my iPhone

> On Dec 25, 2015, at 03:49, Borislav Petkov  wrote:
> 
>> On Tue, Dec 15, 2015 at 05:30:49PM -0800, Tony Luck wrote:
>> Using __copy_user_nocache() as inspiration create a memory copy
>> routine for use by kernel code with annotations to allow for
>> recovery from machine checks.
>> 
>> Notes:
>> 1) We align the source address rather than the destination. This
>>   means we never have to deal with a memory read that spans two
>>   cache lines ... so we can provide a precise indication of
>>   where the error occurred without having to re-execute at
>>   a byte-by-byte level to find the exact spot like the original
>>   did.
>> 2) We 'or' BIT(63) into the return if the copy failed because of
>>   a machine check. If we failed during a copy from user space
>>   because the user provided a bad address, then we just return
>>   then number of bytes not copied like other copy_from_user
>>   functions.
>> 3) This code doesn't play any cache games. Future functions can
>>   use non-temporal loads/stores to meet needs of different callers.
>> 4) Provide helpful macros to decode the return value.
>> 
>> Signed-off-by: Tony Luck 
>> ---
>> Boris: This version has all the return options coded.
>>return 0; /* SUCCESS */
>>return remain_bytes | (1ul << 63); /* failed because of machine check */
>>return remain_bytes; /* failed because of invalid source address */
> 
> Ok, how about a much simpler approach and finally getting rid of that
> bit 63? :-)
> 
> Here's what we could do, it is totally untested but at least it builds
> here (full patch below).
> 
> So first we define __mcsafe_copy to return two u64 values, or two
> int values or whatever... Bottomline is, we return 2 values with
> remain_bytes in %rdx and the actual error in %rax.
> 
> +struct mcsafe_ret {
> +   u64 ret;
> +   u64 remain;
> +};
> +
> +struct mcsafe_ret __mcsafe_copy(void *dst, const void __user *src, unsigned 
> size);
> 
> Then, in fixup_exception()/fixup_mcexception(), we set the *respective*
> regs->ax (which is mcsafe_ret.ret) depending on which function is fixing
> up the exception. I've made it return -EINVAL and -EFAULT respectively
> but those are arbitrary.
> 
> We detect that we're in __mcsafe_copy() by using its start and a
> previously defined end label. I've done this in order to get rid of the
> mce-specific exception tables. Mind you, this is still precise enough
> since we're using the _ASM_EXTABLE entries from __mcsafe_copy.
> 
> And this approach gets rid of those mce-specific exception tables, bit
> 63, makes __mcsafe_copy simpler, you name it... :-)
> 
> Thoughts?
> 
> ---
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index adb28a2dab44..efef4d72674c 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1021,6 +1021,16 @@ config X86_MCE_INJECT
>  If you don't know what a machine check is and you don't do kernel
>  QA it is safe to say n.
> 
> +config MCE_KERNEL_RECOVERY
> +bool "Recovery from machine checks in special kernel memory copy 
> functions"
> +default n
> +depends on X86_MCE && X86_64
> +---help---
> +  This option provides a new memory copy function mcsafe_memcpy()
> +  that is annotated to allow the machine check handler to return
> +  to an alternate code path to return an error to the caller instead
> +  of crashing the system. Say yes if you have a driver that uses this.
> +
> config X86_THERMAL_VECTOR
>def_bool y
>depends on X86_MCE_INTEL
> diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
> index 2ea4527e462f..9c5371d1069b 100644
> --- a/arch/x86/include/asm/mce.h
> +++ b/arch/x86/include/asm/mce.h
> @@ -287,4 +287,13 @@ struct cper_sec_mem_err;
> extern void apei_mce_report_mem_error(int corrected,
>  struct cper_sec_mem_err *mem_err);
> 
> +#ifdef CONFIG_MCE_KERNEL_RECOVERY
> +int fixup_mcexception(struct pt_regs *regs);
> +#else
> +static inline int fixup_mcexception(struct pt_regs *regs)
> +{
> +return 0;
> +}
> +#endif
> +
> #endif /* _ASM_X86_MCE_H */
> diff --git a/arch/x86/include/asm/string_64.h 
> b/arch/x86/include/asm/string_64.h
> index ff8b9a17dc4b..6b6431797749 100644
> --- a/arch/x86/include/asm/string_64.h
> +++ 

Re: [PATCH v3] um: Fix build error and kconfig for i386

[Mickaël Salaün]

On 25/12/2015 02:34, Josh Triplett wrote:
> On Thu, Dec 24, 2015 at 01:12:11PM +0100, Mickaël Salaün wrote:
>> Fix build error by generating elfcore.o only when ELF_CORE (depending on
>> COREDUMP) is selected:
>>
>> arch/x86/um/built-in.o: In function `elf_core_write_extra_phdrs':
>> (.text+0x3e62): undefined reference to `dump_emit'
>> arch/x86/um/built-in.o: In function `elf_core_write_extra_data':
>> (.text+0x3eef): undefined reference to `dump_emit'
>>
>> Fixes: 5d2acfc7b974 ("kconfig: make allnoconfig disable options behind 
>> EMBEDDED and EXPERT")
>> Signed-off-by: Mickaël Salaün 
>> Cc: Jeff Dike 
>> Cc: Richard Weinberger 
>> Cc: Josh Triplett 
>> Cc: Paul E. McKenney 
>> Cc: Michal Marek 
>> Cc: Andrew Morton 
>> Cc: Linus Torvalds 
> 
> It looks like ELF_CORE depends on COREDUMP, but not on BINFMT_ELF.
> Should it?  What happens if you build this with ELF_CORE=y and
> BINFMT_ELF=n?  Does that configuration even make sense?

It build fine with ELF_CORE=y and BINFMT_ELF=n but does not seem useful. 
Nevertheless, it's the same for all architectures (cf. init/Kconfig): ELF_CORE 
only depends on COREDUMP.

 Mickaël



signature.asc
Description: OpenPGP digital signature

[PATCH] gpio-ucb1400: Delete an unnecessary variable initialisation in ucb1400_gpio_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 25 Dec 2015 19:36:20 +0100

The variable "err" will eventually be set to an appropriate value
from a call of the gpiochip_add() function.
Thus let us omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/gpio/gpio-ucb1400.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-ucb1400.c b/drivers/gpio/gpio-ucb1400.c
index d502825..c963517 100644
--- a/drivers/gpio/gpio-ucb1400.c
+++ b/drivers/gpio/gpio-ucb1400.c
@@ -46,7 +46,7 @@ static void ucb1400_gpio_set(struct gpio_chip *gc, unsigned 
off, int val)
 static int ucb1400_gpio_probe(struct platform_device *dev)
 {
struct ucb1400_gpio *ucb = dev_get_platdata(>dev);
-   int err = 0;
+   int err;
 
if (!(ucb && ucb->gpio_offset)) {
err = -EINVAL;
-- 
2.6.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/

sata_mv: Another source code review around exception handling?

[SF Markus Elfring]

Hello,

I have looked at the source file for the Marvell SATA support driver once more.
I would appreciate if a specific implementation detail can be clarified there.

Static source code analysis can point out that functions like the following
are called by the mv_platform_probe() function.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/ata/sata_mv.c?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n4055

* ata_host_alloc_pinfo
  http://lxr.free-electrons.com/source/drivers/ata/libata-core.c?v=4.3#L5768

* devm_kzalloc
  http://lxr.free-electrons.com/source/include/linux/device.h?v=4.3#L645


The value "-ENOMEM" will be returned if one of these function calls failed.
Can it be that any system resources (like memory) are not appropriately
released if any calls of this sequence succeeded before the failure?


Is the use of the single jump label "err" also suspicious here?

Regards,
Markus
--
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] um: Fix build error and kconfig for i386

[Richard Weinberger]

Am 25.12.2015 um 02:26 schrieb Josh Triplett:
> On Thu, Dec 24, 2015 at 01:09:45PM +0100, Mickaël Salaün wrote:
>>
>> On 23/12/2015 22:42, Josh Triplett wrote:
>>> On Wed, Dec 23, 2015 at 01:59:13PM +0100, Mickaël Salaün wrote:
 Fix build error by selecting COREDUMP when X86_32 is selected:

 arch/x86/um/built-in.o: In function `elf_core_write_extra_phdrs':
 (.text+0x3e62): undefined reference to `dump_emit'
 arch/x86/um/built-in.o: In function `elf_core_write_extra_data':
 (.text+0x3eef): undefined reference to `dump_emit'

 Fixes: 5d2acfc7b974 ("kconfig: make allnoconfig disable options behind 
 EMBEDDED and EXPERT")
 Signed-off-by: Mickaël Salaün 
 Cc: Jeff Dike 
 Cc: Richard Weinberger 
 Cc: Josh Triplett 
 Cc: Paul E. McKenney 
 Cc: Michal Marek 
 Cc: Andrew Morton 
 Cc: Linus Torvalds 
>>>
>>> I suppose um doesn't care deeply about binary size, but ideally I would
>>> suggest changing arch/x86/um/Makefile to make elfcore.c compiled in when
>>> CONFIG_ELF_CORE rather than CONFIG_BINFMT_ELF.
>>
>> That looks better! Since the first patch has been added to the mmots tree 
>> (but not yet in mmotm) I'll send a patch update instead of a new one 
>> reverting the first. I hope this is OK.
> 
> -mm regularly replaces patches with newer versions, so that ought to be
> fine.

Usually non-trivial UML stuff goes thought me.
As Josh noted, just post an updated version of the patch.
Either me or Andrew will pick it up.

Thanks,
//richard

--
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] null_blk: don't enable irqs when in irq

[Rabin Vincent]

When using irq_mode=NULL_IRQ_TIMER, blk_start_queue() is called from the
hrtimer interrupt.  null_request_fn() calls spin_unlock_irq() and this
causes the following splat from lockdep since interrupts are being
enabled while we're in an interrupt handler.

When we're in null_request_fn() we can't know the status of the flags
saved before blk_start_queue() was called, but we can use in_irq() to
conditionally enable interrupts only if we're not in a hard interrupt in
order to handle this case.

 [ cut here ]
 WARNING: CPU: 0 PID: 398 at kernel/locking/lockdep.c:2608 
trace_hardirqs_on_caller+0x11a/0x1b0()
 DEBUG_LOCKS_WARN_ON(current->hardirq_context)
 CPU: 0 PID: 398 Comm: mkfs.ext4 Not tainted 4.4.0-rc6+ #77
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 
04/01/2014
 Call Trace:
[] dump_stack+0x4e/0x82
  [] warn_slowpath_common+0x82/0xc0
  [] ? _raw_spin_unlock_irq+0x2c/0x60
  [] ? null_softirq_done_fn+0x30/0x30
  [] warn_slowpath_fmt+0x4c/0x50
  [] trace_hardirqs_on_caller+0x11a/0x1b0
  [] trace_hardirqs_on+0xd/0x10
  [] _raw_spin_unlock_irq+0x2c/0x60
  [] null_request_fn+0x4e/0xb0
  [] __blk_run_queue+0x33/0x40
  [] blk_start_queue+0x3f/0x80
  [] end_cmd+0x117/0x120
  [] null_cmd_timer_expired+0x12/0x20
  [] __hrtimer_run_queues+0x12b/0x4b0
  [] hrtimer_interrupt+0xaf/0x1b0
  [] local_apic_timer_interrupt+0x36/0x60
  [] smp_apic_timer_interrupt+0x3d/0x50
  [] apic_timer_interrupt+0x8c/0xa0
[] ? fprop_fraction_percpu+0xeb/0x110
  [] ? __wb_calc_thresh+0x2f/0xc0
  [] __wb_calc_thresh+0x2f/0xc0
  [] ? domain_dirty_limits+0x1bc/0x1f0
  [] balance_dirty_pages_ratelimited+0x6d5/0xfb0
  [] ? rcu_read_lock_sched_held+0x77/0x90
  [] ? __block_commit_write.isra.1+0x7a/0xb0
  [] generic_perform_write+0x14c/0x1c0
  [] __generic_file_write_iter+0x190/0x1f0
  [] blkdev_write_iter+0x7b/0x100
  [] __vfs_write+0xaa/0xe0
  [] vfs_write+0x95/0x100
  [] ? __fget_light+0x6f/0x90
  [] SyS_pwrite64+0x77/0x90
  [] entry_SYSCALL_64_fastpath+0x12/0x76
 ---[ end trace 39b7df36fb237be1 ]---

Signed-off-by: Rabin Vincent 
---
 drivers/block/null_blk.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index a428e4e..d16c5dc 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -342,13 +342,20 @@ static int null_rq_prep_fn(struct request_queue *q, 
struct request *req)
 static void null_request_fn(struct request_queue *q)
 {
struct request *rq;
+   bool irq = in_irq();
 
while ((rq = blk_fetch_request(q)) != NULL) {
struct nullb_cmd *cmd = rq->special;
 
-   spin_unlock_irq(q->queue_lock);
+   if (irq)
+   spin_unlock(q->queue_lock);
+   else
+   spin_unlock_irq(q->queue_lock);
null_handle_cmd(cmd);
-   spin_lock_irq(q->queue_lock);
+   if (irq)
+   spin_lock(q->queue_lock);
+   else
+   spin_lock_irq(q->queue_lock);
}
 }
 
-- 
2.6.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 3.2 46/77] drm: Fix an unwanted master inheritance v2

[Thomas Hellstrom]

On 12/24/2015 04:37 PM, Ben Hutchings wrote:
> 3.2.75-rc1 review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Thomas Hellstrom 
>
> commit a0af2e538c80f3e47f1d6ddf120a153ad909e8ad upstream.
>
> A client calling drmSetMaster() using a file descriptor that was opened
> when another client was master would inherit the latter client's master
> object and all its authenticated clients.
>
> This is unwanted behaviour, and when this happens, instead allocate a
> brand new master object for the client calling drmSetMaster().
>
> Fixes a BUG() throw in vmw_master_set().
>
> Signed-off-by: Thomas Hellstrom 
> Signed-off-by: Dave Airlie 
> [bwh: Backported to 3.2:
>  - s/master_mutex/struct_mutex/
>  - drm_new_set_master() must drop struct_mutex while calling
>drm_driver::master_create
>  - Adjust filename, context, indentation]
> Signed-off-by: Ben Hutchings 
> ---
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -225,6 +225,10 @@ int drm_setmaster_ioctl(struct drm_devic
>   if (!file_priv->minor->master &&
>   file_priv->minor->master != file_priv->master) {
>   mutex_lock(>struct_mutex);
> + if (!file_priv->allowed_master) {
> + ret = drm_new_set_master(dev, file_priv);
> + goto out_unlock;
> + }
>   file_priv->minor->master = drm_master_get(file_priv->master);
>   file_priv->is_master = 1;
>   if (dev->driver->master_set) {
> @@ -234,10 +238,11 @@ int drm_setmaster_ioctl(struct drm_devic
>   drm_master_put(_priv->minor->master);
>   }
>   }
> + out_unlock:
>   mutex_unlock(>struct_mutex);
>   }
>  
> - return 0;
> + return ret;
>  }
>  
>  int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -219,6 +219,62 @@ static int drm_cpu_valid(void)
>  }
>  
>  /**
> + * drm_new_set_master - Allocate a new master object and become master for 
> the
> + * associated master realm.
> + *
> + * @dev: The associated device.
> + * @fpriv: File private identifying the client.
> + *
> + * This function must be called with dev::struct_mutex held.
> + * Returns negative error code on failure. Zero on success.
> + */
> +int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
> +{
> + struct drm_master *old_master;
> + int ret;
> +
> + lockdep_assert_held_once(>struct_mutex);
> +

Is lockdep_assert_held_once() backported into the 3.2 series? If not,
this line could probably be replaced by lockdep_assert_held() for stable
kernels or removed entirely.

Thanks,
Thomas

--
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] crypto: ccp - use to_pci_dev and to_platform_device

[Herbert Xu]

On Wed, Dec 23, 2015 at 08:49:01PM +0800, Geliang Tang wrote:
> Use to_pci_dev() and to_platform_device() instead of open-coding.
> 
> Signed-off-by: Geliang Tang 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] ARM: omapfb: Add early framebuffer memory allocator

[Ivaylo Dimitrov]

On 26.12.2013 01:12, Ivaylo Dimitrov wrote:

From: Ivaylo Dimitrov 

On memory limited devices, CMA fails easily when asked to allocate big
chunks of memory like framebuffer memory needed for video playback.

Add boot parameter "omapfb_memsize" which allocates memory to be used
as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator when
trying to allocate memory for the framebuffers

Signed-off-by: Ivaylo Dimitrov 
---
  arch/arm/mach-omap2/common.c |1 +
  arch/arm/mach-omap2/common.h |2 +
  arch/arm/mach-omap2/fb.c |   46 +-
  3 files changed, 48 insertions(+), 1 deletions(-)



ping
--
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] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

[Ivaylo Dimitrov]

Hi Tomi,

On 13.01.2014 12:20, Tomi Valkeinen wrote:

On 2014-01-11 11:39, Ivaylo Dimitrov wrote:


The patch does not apply cleanly on top of rc7, however I applied it by
hand. So far it seems it fixes the issue brought by
c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if
mutex_lock/mutex_unlock are complementary in every code path (at least
not explicitly, I guess maemo is doing it for us anyway :) ).


Ok, thanks.


So, shall I send a patch incorporating your code changes, or you will do
it?


I can handle it.

  Tomi




I still don't see those fixes in mainline, shall I send a patch?

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

Re: [PATCH 0/2] two fixes for new bq27000/10 and bq27500 driver

[Pali Rohár]

On Thursday 24 December 2015 14:57:56 Andrew F. Davis wrote: 
> > Also I wonder if you would be available as official reviewer for
> > the driver.
> 
> Sure, what's the normal procedure for this, should I submit a
> patch adding myself to that driver in MAINTAINERS?

Yes, send patch.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] power:bq27xxx: fix reading for bq27000 and bq27010

[Pali Rohár]

On Thursday 17 December 2015 11:12:53 H. Nikolaus Schaller wrote:
> bug: the driver reports funny capacity values:
> 
> root@letux:/sys/class/power_supply/bq27000-battery# cat uevent
> POWER_SUPPLY_NAME=bq27000-battery
> POWER_SUPPLY_STATUS=Charging
> POWER_SUPPLY_PRESENT=1
> POWER_SUPPLY_VOLTAGE_NOW=3702000
> POWER_SUPPLY_CURRENT_NOW=-464635
> POWER_SUPPLY_CAPACITY=1536<- over 100% is magic
> POWER_SUPPLY_CAPACITY_LEVEL=Normal
> POWER_SUPPLY_TEMP=311
> POWER_SUPPLY_TIME_TO_FULL_NOW=10440
> POWER_SUPPLY_TECHNOLOGY=Li-ion
> POWER_SUPPLY_CHARGE_FULL=805450
> POWER_SUPPLY_CHARGE_NOW=1068
> POWER_SUPPLY_CHARGE_FULL_DESIGN=8844998   <- battery has just 1200 mAh
> POWER_SUPPLY_CYCLE_COUNT=21
> POWER_SUPPLY_ENERGY_NOW=0
> POWER_SUPPLY_POWER_AVG=0
> POWER_SUPPLY_HEALTH=Good
> POWER_SUPPLY_MANUFACTURER=Texas Instruments
> 
> reason: the state of charge and the design capacity register are
> single byte only. The design capacity returns the higer order byte.
> 
> tested: GTA04 with Openmoko/FIC HF08x battery (using hdq)
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  drivers/power/bq27xxx_battery.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/power/bq27xxx_battery.c
> b/drivers/power/bq27xxx_battery.c index 880233c..e54a125 100644
> --- a/drivers/power/bq27xxx_battery.c
> +++ b/drivers/power/bq27xxx_battery.c
> @@ -471,7 +471,10 @@ static int bq27xxx_battery_read_soc(struct
> bq27xxx_device_info *di) {
>   int soc;
> 
> - soc = bq27xxx_read(di, BQ27XXX_REG_SOC, false);
> + if (di->chip == BQ27000 || di->chip == BQ27010)
> + soc = bq27xxx_read(di, BQ27XXX_REG_SOC, true);
> + else
> + soc = bq27xxx_read(di, BQ27XXX_REG_SOC, false);
> 
>   if (soc < 0)
>   dev_dbg(di->dev, "error reading State-of-Charge\n");
> @@ -536,7 +539,10 @@ static int bq27xxx_battery_read_dcap(struct
> bq27xxx_device_info *di) {
>   int dcap;
> 
> - dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, false);
> + if (di->chip == BQ27000 || di->chip == BQ27010)
> + dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, true);
> + else
> + dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, false);
> 
>   if (dcap < 0) {
>   dev_dbg(di->dev, "error reading initial last measured
> discharge\n"); @@ -544,7 +550,7 @@ static int
> bq27xxx_battery_read_dcap(struct bq27xxx_device_info *di) }
> 
>   if (di->chip == BQ27000 || di->chip == BQ27010)
> - dcap *= BQ27XXX_CURRENT_CONSTANT / BQ27XXX_RS;
> + dcap = (dcap << 8) * BQ27XXX_CURRENT_CONSTANT / BQ27XXX_RS;
>   else
>   dcap *= 1000;

Hi!

This patch fixes commit d74534c27775857cb09abd0f92ed9539dc8d0a93 (power: 
bq27xxx_battery: Add support for additional bq27xxx family devices) in 
which this bug (all 3 patch chunks) were introduced.

Before that commit code was very similar after applying this patch. So:

Reviewed-by: Pali Rohár 

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] dell-wmi: Check if Dell WMI descriptor structure is valid

[Pali Rohár]

On Friday 25 December 2015 02:23:04 Andy Lutomirski wrote:
> On Thu, Dec 24, 2015 at 1:18 PM, Pali Rohár 
> wrote:
> > According to Dell WMI document mentioned in ML dicussion archived
> > at http://www.spinics.net/lists/platform-driver-x86/msg07220.html
> > OS should check Dell WMI descriptor structure. Structure also
> > provide Dell WMI interface version which is used later.
> 
> I will rebase my big series on top of this.  It'll give me a good
> excuse to test that I got the probe ordering right.  (The code is
> explicitly intended to support use cases like this, and now I'll have
> a real-world test for it.)  I'll also test this in a bit.

Ok!

> > +MODULE_ALIAS("wmi:"DELL_DESCRIPTOR_GUID);
> 
> I don't think this is necessary.  The driver will only work if both
> wmi devices and, hence, modaliases are present, so there's no need to
> cause just one or the other to trigger dell-wmi autoloading.

Maybe now when you are working on big WMI patch series is time to change 
modalias support in WMI to support AND-conjunction (&&) on WMI aliases, 
not just OR (one alias match).

Something like: load dell-wmi.ko driver if system provides both WMI 
GUIDs.

> > +/**
> 
> > + * Descriptor buffer is 128 byte long and contains:
> This isn't kerneldoc format, so I think this should just be "/*".
> 

Ok, I will fix this in next version.

> > +   if (obj->buffer.length != 128) {
> > +   pr_err("Dell descriptor buffer has invalid length
> > (%d)\n", +   obj->buffer.length);
> > +   kfree(obj);
> > +   return -EINVAL;
> > +   }
> 
> I would advocate for being more permissive: a buffer that is actually
> too short for the fields we need would result in -EINVAL, but a
> buffer that isn't 128 bytes would just be a warning and not cause
> module load to fail.
> 
> --Andy

Sounds good, I will change this part.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag

[Jingoo Han]

On Thursday, December 24, 2015 10:23 AM, Yakir Yang wrote:
> 
> Hi Jingoo,
> 
> Okay, fine, I would drop this patch, until I found the the root cause.

OK, I see.

Best regards,
Jingoo Han

> 
> - Yakir
> 
> On 12/23/2015 11:10 PM, Jingoo Han wrote:
> > On Wednesday, December 23, 2015 9:51 PM, Yakir Yang wrote:
> >> On Rockchip platform, sometimes driver would failed at reading EDID
> >> message, and it's caused by the AUX reply flag wouldn't received under
> >> the 100*10us wait time.
> > The problem is specific for Rockchip platform.
> > Also, 1 ms is long time.
> > The best way is that your hardware engineers find the root cause.
> > I cannot understand why your engineers cannot find the root cause. :-(
> >
> >> But after expand the wait time a little, the AUX reply flag would be
> >> set, so maybe the wait time is a little critical. Besides the analogix
> >> dp book haven't reminded the standard wait for looking AUX reply flag,
> >> so I thought it's okay to expand the wait time.
> >>
> >> And the external wait time won't hurt Exynos DP too much, cause they
> >> wouldn't meet this problem, then driver would received the reply command
> >> very soon, so no more additional wait time would bring to Exynos platform.
> > Then, when loop time happens on Exynos platform, it will take long time
> > to return error.
> >
> >> Signed-off-by: Yakir Yang 
> >> ---
> >> Changes in v12:
> >> - Using another way to expand the AUX reply wait time (Jingoo)
> >>
> >> Changes in v11: None
> >> Changes in v10: None
> >> Changes in v9: None
> >> Changes in v8: None
> >> Changes in v7: None
> >> Changes in v6: None
> >> Changes in v5: None
> >> Changes in v4: None
> >> Changes in v3: None
> >> Changes in v2: None
> >>
> >>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
> >>   1 file changed, 4 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> index cba3ffd..8687eea 100644
> >> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> @@ -471,7 +471,7 @@ int analogix_dp_start_aux_transaction(struct 
> >> analogix_dp_device *dp)
> >>   {
> >>int reg;
> >>int retval = 0;
> >> -  int timeout_loop = 0;
> >> +  unsigned long timeout;
> >>
> >>/* Enable AUX CH operation */
> >>reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
> >> @@ -479,14 +479,12 @@ int analogix_dp_start_aux_transaction(struct 
> >> analogix_dp_device *dp)
> >>writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
> >>
> >>/* Is AUX CH command reply received? */
> >> -  reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> >> -  while (!(reg & RPLY_RECEIV)) {
> >> -  timeout_loop++;
> >> -  if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> >> +  timeout = jiffies + msecs_to_jiffies(5);
> >> +  while ((readl(dp->reg_base + ANALOGIX_DP_INT_STA) & RPLY_RECEIV) == 0) {
> >> +  if (time_after(jiffies, timeout)) {
> >>dev_err(dp->dev, "AUX CH command reply failed!\n");
> >>return -ETIMEDOUT;
> >>}
> >> -  reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> > Sorry, I don't like your patch.
> >
> > The problem happens because of Rockchip platform.
> > So, you need to add workaround for only Rockchip platform.
> >
> > Just add new DT property and new variable for the value for wait time.
> > When, the probe is called, new wait time value is read from Rockchip DT 
> > file.
> > Then, the new wait time value can be written to the new variable.
> >
> >  new DT property: wait-time-aux
> >  new variable: wait_time_aux
> >
> >
> > If ( ) // New DT
> >  wait_time_aux = New DT;
> > else
> >  wait_time_aux = 10;
> >
> >
> >>usleep_range(10, 11);
> > If there is NO  new wait time value from DT file, the default value '10' is
> > used for sleep.
> >
> > But, if there is new wait time value from DT file, new wait time value
> > can be used for sleep.
> >
> >   usleep_range(dp->wait_time_aux, dp->wait_time_aux + 1);
> >
> > What I want to say is that there should be NO effect on Exynos platform,
> > because of the hardware bug of Rockchip platform.
> >
> > Best regards,
> > Jingoo Han
> >
> >>}
> >>
> >> --
> >> 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: mmc does not work in qemu n900

[Pali Rohár]

On Monday 26 January 2015 22:04:59 Pali Rohár wrote:
> Hello,
> 
> for unknown reason kernel in qemu n900 machine is not able to
> detect internal eMMC memory. External SD card is detected without
> problem.
> 
> If I apply this one-line patch eMMC in qemu start working:
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 9584bff..0d4461c 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -2337,6 +2337,9 @@ static int mmc_rescan_try_freq(
>   return 0;
>   if (!mmc_attach_sd(host))
>   return 0;
> +
> + mmc_go_idle(host);
> +
>   if (!mmc_attach_mmc(host))
>   return 0;
> 
> I played with mmc and qemu n900 a bit and also this simple patch
> (without first) fix problem (that mmc is not detected by kernel):
> 
> diff --git a/drivers/mmc/core/mmc_ops.c
> b/drivers/mmc/core/mmc_ops.c
> index 3b044c5..0c93a2c 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -157,6 +157,10 @@ int mmc_send_op_cond(
> 
>   BUG_ON(!host);
> 
> + /* reset mmc before calling op_cond */
> + memset(, 0, sizeof(struct mmc_command));
> + mmc_wait_for_cmd(host, , MMC_CMD_RETRIES);
> +
>   cmd.opcode = MMC_SEND_OP_COND;
>   cmd.arg = mmc_host_is_spi(host) ? 0 : ocr;
>   cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R3 | MMC_CMD_BCR;
> 
> 
> I have no idea where is problem. I also do not understand mmc
> kernel code, but second patch I have on my HDD since 2.6.37.
> 
> Can somebody with knowledge of mmc subsystem look at this
> problem? Why any of these two patches fix problem when mmc is not
> detected by kernel in qemu (machine n900)? Detection of mmc fails
> because function mmc_send_op_cond() without one of above patches
> fails.

I will bring this tread to front again as mmc without one of provided 
patches does not work with 4.4-rc6 kernel in N900 qemu.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Pali Rohár]

On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > * Arnd Bergmann  [150515 14:26]:
> > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > If setting up the generic binding is expected to take a while,
> > you can naturally pass it in pdata while waiting for the generic
> > binding to get merged.
> 
> Yes, good idea. So the n900 machine can use auxdata to pass this for
> the time being, while the binding and generic implementation is
> being worked out.
> 
>   Arnd

Ok, so what is needed to finish this patch series?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

[PATCH] pinctrl: qcom: make PMIC drivers bool

[Linus Walleij]

commit ab4256cfeab91569e1d96e7f0014538fe0845259
"pinctrl: qcom: pmic-gpio/mpp: of_irq_count() == npins"
made the Qualcomm PMIC pin control drivers make use of
of_irq_count() which is not an exported function, making
modular builds fail.

Fix this by marking the drivers as compiled-in/bool.

Cc: Stephen Boyd 
Cc: Andy Gross 
Cc: Mark Brown 
Signed-off-by: Linus Walleij 
---
 drivers/pinctrl/qcom/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index eeac8cba8a21..c658d9bce285 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -80,7 +80,7 @@ config PINCTRL_QDF2XXX
  Qualcomm Technologies QDF2xxx SOCs.
 
 config PINCTRL_QCOM_SPMI_PMIC
-   tristate "Qualcomm SPMI PMIC pin controller driver"
+   bool "Qualcomm SPMI PMIC pin controller driver"
depends on GPIOLIB && OF && SPMI
select REGMAP_SPMI
select PINMUX
@@ -93,7 +93,7 @@ config PINCTRL_QCOM_SPMI_PMIC
  devices are pm8841, pm8941 and pma8084.
 
 config PINCTRL_QCOM_SSBI_PMIC
-   tristate "Qualcomm SSBI PMIC pin controller driver"
+   bool "Qualcomm SSBI PMIC pin controller driver"
depends on GPIOLIB && OF
select PINMUX
select PINCONF
-- 
2.4.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/

[GIT PULL] parisc syscall restart fix for v4.4

[Helge Deller]

Hi Linus,

please pull one late patch for the parisc architecture for kernel v4.4 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
parisc-4.4-4

The architectural design of parisc always uses two instructions to call kernel
syscalls (delayed branch feature). This means that the instruction following
the branch (located in the delay slot of the branch instruction) is executed
before control passes to the branch destination.
Depending on which assembler instruction and how it is used in usersapce in
the delay slot, this sometimes made restarted syscalls like futex() and poll()
failing with -ENOSYS.

Thanks,
Helge


Helge Deller (1):
  parisc: Fix syscall restarts

 arch/parisc/kernel/signal.c | 64 -
 1 file changed, 52 insertions(+), 12 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: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks

[Borislav Petkov]

On Tue, Dec 15, 2015 at 05:30:49PM -0800, Tony Luck wrote:
> Using __copy_user_nocache() as inspiration create a memory copy
> routine for use by kernel code with annotations to allow for
> recovery from machine checks.
> 
> Notes:
> 1) We align the source address rather than the destination. This
>means we never have to deal with a memory read that spans two
>cache lines ... so we can provide a precise indication of
>where the error occurred without having to re-execute at
>a byte-by-byte level to find the exact spot like the original
>did.
> 2) We 'or' BIT(63) into the return if the copy failed because of
>a machine check. If we failed during a copy from user space
>because the user provided a bad address, then we just return
>then number of bytes not copied like other copy_from_user
>functions.
> 3) This code doesn't play any cache games. Future functions can
>use non-temporal loads/stores to meet needs of different callers.
> 4) Provide helpful macros to decode the return value.
> 
> Signed-off-by: Tony Luck 
> ---
> Boris: This version has all the return options coded.
>   return 0; /* SUCCESS */
>   return remain_bytes | (1ul << 63); /* failed because of machine check */
>   return remain_bytes; /* failed because of invalid source address */

Ok, how about a much simpler approach and finally getting rid of that
bit 63? :-)

Here's what we could do, it is totally untested but at least it builds
here (full patch below).

So first we define __mcsafe_copy to return two u64 values, or two
int values or whatever... Bottomline is, we return 2 values with
remain_bytes in %rdx and the actual error in %rax.

+struct mcsafe_ret {
+   u64 ret;
+   u64 remain;
+};
+
+struct mcsafe_ret __mcsafe_copy(void *dst, const void __user *src, unsigned 
size);

Then, in fixup_exception()/fixup_mcexception(), we set the *respective*
regs->ax (which is mcsafe_ret.ret) depending on which function is fixing
up the exception. I've made it return -EINVAL and -EFAULT respectively
but those are arbitrary.

We detect that we're in __mcsafe_copy() by using its start and a
previously defined end label. I've done this in order to get rid of the
mce-specific exception tables. Mind you, this is still precise enough
since we're using the _ASM_EXTABLE entries from __mcsafe_copy.

And this approach gets rid of those mce-specific exception tables, bit
63, makes __mcsafe_copy simpler, you name it... :-)

Thoughts?

---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index adb28a2dab44..efef4d72674c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1021,6 +1021,16 @@ config X86_MCE_INJECT
  If you don't know what a machine check is and you don't do kernel
  QA it is safe to say n.
 
+config MCE_KERNEL_RECOVERY
+   bool "Recovery from machine checks in special kernel memory copy 
functions"
+   default n
+   depends on X86_MCE && X86_64
+   ---help---
+ This option provides a new memory copy function mcsafe_memcpy()
+ that is annotated to allow the machine check handler to return
+ to an alternate code path to return an error to the caller instead
+ of crashing the system. Say yes if you have a driver that uses this.
+
 config X86_THERMAL_VECTOR
def_bool y
depends on X86_MCE_INTEL
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 2ea4527e462f..9c5371d1069b 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -287,4 +287,13 @@ struct cper_sec_mem_err;
 extern void apei_mce_report_mem_error(int corrected,
  struct cper_sec_mem_err *mem_err);
 
+#ifdef CONFIG_MCE_KERNEL_RECOVERY
+int fixup_mcexception(struct pt_regs *regs);
+#else
+static inline int fixup_mcexception(struct pt_regs *regs)
+{
+   return 0;
+}
+#endif
+
 #endif /* _ASM_X86_MCE_H */
diff --git a/arch/x86/include/asm/string_64.h b/arch/x86/include/asm/string_64.h
index ff8b9a17dc4b..6b6431797749 100644
--- a/arch/x86/include/asm/string_64.h
+++ b/arch/x86/include/asm/string_64.h
@@ -78,6 +78,16 @@ int strcmp(const char *cs, const char *ct);
 #define memset(s, c, n) __memset(s, c, n)
 #endif
 
+#ifdef CONFIG_MCE_KERNEL_RECOVERY
+struct mcsafe_ret {
+   u64 ret;
+   u64 remain;
+};
+
+struct mcsafe_ret __mcsafe_copy(void *dst, const void __user *src, unsigned 
size);
+extern void __mcsafe_copy_end(void);
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif /* _ASM_X86_STRING_64_H */
diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h 
b/arch/x86/kernel/cpu/mcheck/mce-internal.h
index 547720efd923..e8a2c8067fcb 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-internal.h
+++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h
@@ -80,4 +80,12 @@ static inline int apei_clear_mce(u64 record_id)
 }
 #endif
 
+#ifdef CONFIG_MCE_KERNEL_RECOVERY
+static inline bool mce_in_kernel_recov(unsigned long addr)
+{
+   return (addr >= (unsigned long)__mcsafe_copy &&
+  

Re: [PATCH 1/2] mm, oom: introduce oom reaper

[Michal Hocko]

On Fri 25-12-15 12:35:37, Michal Hocko wrote:
[...]
> Thanks I will try to reproduce early next year. But so far I think this
> is just a general issue of MADV_DONTNEED vs. truncate and oom_reaper is
> just lucky to trigger it. There shouldn't be anything oom_reaper
> specific here. Maybe there is some additional locking missing?

Hmm, scratch that. I think Tetsuo has nailed it. It seems like
the missing initialization of details structure during unmap
is the culprit. So there most probably was on OOM killing
invoked. It is just a side effect of the patch and missing
http://marc.info/?l=linux-mm=145068666428057 follow up fix.
-- 
Michal Hocko
SUSE Labs
--
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/2] mm, oom: introduce oom reaper

[Michal Hocko]

On Thu 24-12-15 20:06:50, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > This is VM_BUG_ON_PAGE(page_mapped(page), page), right? Could you attach
> > the full kernel log? It all smells like a race when OOM reaper tears
> > down the mapping and there is a truncate still in progress. But hitting
> > the BUG_ON just because of that doesn't make much sense to me. OOM
> > reaper is essentially MADV_DONTNEED. I have to think about this some
> > more, though, but I am in a holiday mode until early next year so please
> > bear with me.
> 
> I don't know whether the OOM killer was invoked just before this
> VM_BUG_ON_PAGE().
> 
> > Is this somehow DAX related?
> 
> 4.4.0-rc6-next-20151223_new_fsync_v6+ suggests that this kernel
> has "[PATCH v6 0/7] DAX fsync/msync support" applied. But I think
> http://marc.info/?l=linux-mm=145068666428057 should be applied
> when retesting. (20151223 does not have this fix.)

Hmm, I think you are right! Very well spotted! If ignore_dirty ends up
being true then we would simply skip over dirty page and wouldn't end up
doing page_remove_rmap. I can see that the truncation code can later trip
over this page.

Thanks!
-- 
Michal Hocko
SUSE Labs
--
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/2] mm, oom: introduce oom reaper

[Michal Hocko]

On Thu 24-12-15 13:44:03, Ross Zwisler wrote:
> On Thu, Dec 24, 2015 at 2:47 AM, Michal Hocko  wrote:
> > On Wed 23-12-15 16:00:09, Ross Zwisler wrote:
> > [...]
> >> While running xfstests on next-20151223 I hit a pair of kernel BUGs
> >> that bisected to this commit:
> >>
> >> 1eb3a80d8239 ("mm, oom: introduce oom reaper")
> >
> > Thank you for the report and the bisection.
> >
> >> Here is a BUG produced by generic/029 when run against XFS:
> >>
> >> [  235.751723] [ cut here ]
> >> [  235.752194] kernel BUG at mm/filemap.c:208!
> >
> > This is VM_BUG_ON_PAGE(page_mapped(page), page), right? Could you attach
> > the full kernel log? It all smells like a race when OOM reaper tears
> > down the mapping and there is a truncate still in progress. But hitting
> > the BUG_ON just because of that doesn't make much sense to me. OOM
> > reaper is essentially MADV_DONTNEED. I have to think about this some
> > more, though, but I am in a holiday mode until early next year so please
> > bear with me.
> 
> The two stack traces were gathered with next-20151223, so the line numbers
> may have moved around a bit when compared to the actual "mm, oom: introduce
> oom reaper" commit.

I was looking at the same next tree, I believe
$ git describe
next-20151223

[...]
> > There was a warning before this triggered. The full kernel log would be
> > helpful as well.
> 
> Sure, I can gather full kernel logs, but it'll probably after the new year.

OK, I will wait for the logs. It is really interesting to see what was
the timing between OOM killer invocation and this trace.

> > [...]
> >> [  609.425325] Call Trace:
> >> [  609.425797]  [] invalidate_inode_pages2+0x17/0x20
> >> [  609.426971]  [] xfs_file_read_iter+0x297/0x300
> >> [  609.428097]  [] __vfs_read+0xc9/0x100
> >> [  609.429073]  [] vfs_read+0x89/0x130
> >> [  609.430010]  [] SyS_read+0x58/0xd0
> >> [  609.430943]  [] entry_SYSCALL_64_fastpath+0x12/0x76
> >> [  609.432139] Code: 85 d8 fe ff ff 01 00 00 00 f6 c4 40 0f 84 59 ff
> >> ff ff 49 8b 47 20 48 8d 78 ff a8 01 49 0f 44 ff 8b 47 48 85 c0 0f 88
> >> bd 01 00 00 <0f> 0b 4d 3b 67 08 0f 85 70 ff ff ff 49 f7 07 00 18 00 00
> >> 74 15
> > [...]
> >> My test setup is a qemu guest machine with a pair of 4 GiB PMEM
> >> ramdisk test devices, one for the xfstest test disk and one for the
> >> scratch disk.
> >
> > Is this just a plain ramdisk device or it needs a special configuration?
> 
> Just a plain PMEM ram disk with DAX turned off.  Configuration instructions
> for PMEM can be found here:
> 
> https://nvdimm.wiki.kernel.org/

Thanks I will try to reproduce early next year. But so far I think this
is just a general issue of MADV_DONTNEED vs. truncate and oom_reaper is
just lucky to trigger it. There shouldn't be anything oom_reaper
specific here. Maybe there is some additional locking missing?

-- 
Michal Hocko
SUSE Labs
--
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/

ACPI-fan: Another source code review around null pointer handling?

[SF Markus Elfring]

Hello,

I have looked at the source file for the ACPI fan driver once more.
I would appreciate if a specific implementation detail can be clarified there.

Static source code analysis can point out that functions like the following
share an approach for error detection and corresponding exception handling.
* acpi_fan_get_fif
* acpi_fan_get_fps
* fan_get_state_acpi4
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/acpi/fan.c?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n107

Can it matter eventually to handle a detected null pointer differently from
further checks for an attribute like "obj->type" or "obj->package"?

Regards,
Markus
--
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/

平时最多也就联系了三千家，全球还有十几万客户在哪里？

[iSayor]

您好:
您还在用ali平台开发外贸客户?
   还在使用展会宣传企业和产品?
 你out了!!!
 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 
 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？
 加QQ1286754208给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。
 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。
--
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 0/2] Improve drm_of_component_probe() and move rockchip to use it

[Jean-Francois Moine]

On Thu, 24 Dec 2015 12:36:10 +
Russell King - ARM Linux  wrote:

> It seems that you're trying to work around a limitation in Linux by
> modifying the hardware representation...

Sorry to come back to this topic, but I think you are wrong.

Looking at the imx6 DTs, the problem comes from the display-subsystem
node which is a pure Linux specific software entity.

If you want to describe only the hardware in the DT, everything is
simple.

A IPU is a image controller with its sub-devices. Seen from the system, it
is like a 'board' with its devices (LCDs, camera...).

When 2 IPUs, there are 2 independant boards.

Here is what could be a pure hardware DT:

/* no display-subsystem */

ipu1: ipu@0240 {/* image controller / board 1 */
compatible = "fsl,imx6q-ipu";
...
ports = <_di0>, <_di1>;
};
ipu1_di0: di@0 {/* display interface / crtc 1 */
compatible = "fsl,imx6q-di";
...
ipu1_di0_hdmi: endpoint@1 {
remote-endpoint = <_mux_0>;
};
ipu1_di0_mipi: endpoint@2 {
remote-endpoint = <_mux_0>;
}
...
};
ipu1_di1: di@1 {/* display interface / crtc 2 */
compatible = "fsl,imx6q-di";
...
ipu1_di1_hdmi: endpoint@1 {
remote-endpoint = <_mux_1>;
};
ipu1_di1_mipi: endpoint@2 {
remote-endpoint = <_mux_1>;
}
...
};

ipu2: ipu@0280 {/* image controller / board 2 */
compatible = "fsl,imx6q-ipu";
...
ports = <_di0>, <_di1>;
};
ipu2_di0: di@0 {/* display interface / crtc 1 */
compatible = "fsl,imx6q-di";
...
ipu2_di0_hdmi: endpoint@1 {
remote-endpoint = <_mux_2>;
};
ipu2_di0_mipi: endpoint@2 {
remote-endpoint = <_mux_2>;
}
...
};
ipu2_di1: di@1 {/* display interface / crtc 2 */
compatible = "fsl,imx6q-di";
...
ipu2_di1_hdmi: endpoint@1 {
remote-endpoint = <_mux_3>;
};
ipu2_di1_mipi: endpoint@2 {
remote-endpoint = <_mux_3>;
}
...
};

Then, a standard component binding (port->parent) works fine...

(you may note that the same problem exists with audio: the
'simple-card' is also a pure Linux specific software entity)

-- 
Merry Christmas | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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: algif_skcipher - Require setkey before accept(2)

[Julia Lawall]

On Fri, 25 Dec 2015, Herbert Xu wrote:

> On Fri, Dec 25, 2015 at 07:54:48AM +0100, Julia Lawall wrote:
> > Lines 766, 767 don't look correct at all.
> 
> Thanks Julia.  I have sent an updated patch in the original thread.
> I wonder why I haven't received the original kbuild test robot
> email though.

I goes to me to check for false positives first.

julia
--
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] usb: gadget: f_midi: added spinlock on transmit function

[Peter Chen]

On Tue, Dec 22, 2015 at 04:08:06PM +, Felipe F. Tonello wrote:
> Since f_midi_transmit is called by both ALSA and USB frameworks, it can
> potentially cause a race condition between both calls. This is bad because the
> way f_midi_transmit is implemented can't handle concurrent calls. This is due
> to the fact that the usb request fifo looks for the next element and only if
> it has data to process it enqueues the request, otherwise re-uses it. If both
> (ALSA and USB) frameworks calls this function at the same time, the
> kfifo_seek() will return the same usb_request, which will cause a race
> condition.
> 
> To solve this problem a syncronization mechanism is necessary. In this case it
> is used a spinlock since f_midi_transmit is also called by 
> usb_request->complete
> callback in interrupt context.
> 
> On benchmarks realized by me, spinlocks were more efficient then scheduling
> the f_midi_transmit tasklet in process context and using a mutex to
> synchronize. Also it performs better then previous implementation that

%s/then/than/

> allocated a usb_request for every new transmit made.
> 
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/function/f_midi.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index b70a830..00a15e9 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -97,6 +98,7 @@ struct f_midi {
>   /* This fifo is used as a buffer ring for pre-allocated IN usb_requests 
> */
>   DECLARE_KFIFO_PTR(in_req_fifo, struct usb_request *);
>   unsigned int in_last_port;
> + spinlock_t transmit_lock;
>  };
>  
>  static inline struct f_midi *func_to_midi(struct usb_function *f)
> @@ -574,12 +576,15 @@ static void f_midi_drop_out_substreams(struct f_midi 
> *midi)
>  static void f_midi_transmit(struct f_midi *midi)
>  {
>   struct usb_ep *ep = midi->in_ep;
> + unsigned long flags;
>   bool active;
>  
>   /* We only care about USB requests if IN endpoint is enabled */
>   if (!ep || !ep->enabled)
>   goto drop_out;
>  
> + spin_lock_irqsave(>transmit_lock, flags);
> +
>   do {
>   struct usb_request *req = NULL;
>   unsigned int len, i;
> @@ -591,14 +596,17 @@ static void f_midi_transmit(struct f_midi *midi)
>   len = kfifo_peek(>in_req_fifo, );
>   if (len != 1) {
>   ERROR(midi, "%s: Couldn't get usb request\n", __func__);
> + spin_unlock_irqrestore(>transmit_lock, flags);
>   goto drop_out;
>   }
>  
>   /* If buffer overrun, then we ignore this transmission.
>* IMPORTANT: This will cause the user-space rawmidi device to 
> block until a) usb
>* requests have been completed or b) snd_rawmidi_write() times 
> out. */
> - if (req->length > 0)
> + if (req->length > 0) {
> + spin_unlock_irqrestore(>transmit_lock, flags);
>   return;
> + }
>  
>   for (i = midi->in_last_port; i < MAX_PORTS; i++) {
>   struct gmidi_in_port *port = midi->in_port[i];
> @@ -650,6 +658,8 @@ static void f_midi_transmit(struct f_midi *midi)
>   }
>   } while (active);
>  
> + spin_unlock_irqrestore(>transmit_lock, flags);
> +
>   return;
>  
>  drop_out:
> @@ -1255,6 +1265,8 @@ static struct usb_function *f_midi_alloc(struct 
> usb_function_instance *fi)
>   if (status)
>   goto setup_fail;
>  
> + spin_lock_init(>transmit_lock);
> +
>   ++opts->refcnt;
>   mutex_unlock(>lock);
>  
> -- 
> 2.5.0
> 
> --

-- 

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 2/2] usb: gadget: f_midi: added spinlock on transmit function

[Peter Chen]

On Tue, Dec 22, 2015 at 04:08:06PM +, Felipe F. Tonello wrote:
> Since f_midi_transmit is called by both ALSA and USB frameworks, it can
> potentially cause a race condition between both calls. This is bad because the
> way f_midi_transmit is implemented can't handle concurrent calls. This is due
> to the fact that the usb request fifo looks for the next element and only if
> it has data to process it enqueues the request, otherwise re-uses it. If both
> (ALSA and USB) frameworks calls this function at the same time, the
> kfifo_seek() will return the same usb_request, which will cause a race
> condition.
> 
> To solve this problem a syncronization mechanism is necessary. In this case it
> is used a spinlock since f_midi_transmit is also called by 
> usb_request->complete
> callback in interrupt context.
> 
> On benchmarks realized by me, spinlocks were more efficient then scheduling
> the f_midi_transmit tasklet in process context and using a mutex to
> synchronize. Also it performs better then previous implementation that

%s/then/than/

> allocated a usb_request for every new transmit made.
> 
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/function/f_midi.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index b70a830..00a15e9 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -97,6 +98,7 @@ struct f_midi {
>   /* This fifo is used as a buffer ring for pre-allocated IN usb_requests 
> */
>   DECLARE_KFIFO_PTR(in_req_fifo, struct usb_request *);
>   unsigned int in_last_port;
> + spinlock_t transmit_lock;
>  };
>  
>  static inline struct f_midi *func_to_midi(struct usb_function *f)
> @@ -574,12 +576,15 @@ static void f_midi_drop_out_substreams(struct f_midi 
> *midi)
>  static void f_midi_transmit(struct f_midi *midi)
>  {
>   struct usb_ep *ep = midi->in_ep;
> + unsigned long flags;
>   bool active;
>  
>   /* We only care about USB requests if IN endpoint is enabled */
>   if (!ep || !ep->enabled)
>   goto drop_out;
>  
> + spin_lock_irqsave(>transmit_lock, flags);
> +
>   do {
>   struct usb_request *req = NULL;
>   unsigned int len, i;
> @@ -591,14 +596,17 @@ static void f_midi_transmit(struct f_midi *midi)
>   len = kfifo_peek(>in_req_fifo, );
>   if (len != 1) {
>   ERROR(midi, "%s: Couldn't get usb request\n", __func__);
> + spin_unlock_irqrestore(>transmit_lock, flags);
>   goto drop_out;
>   }
>  
>   /* If buffer overrun, then we ignore this transmission.
>* IMPORTANT: This will cause the user-space rawmidi device to 
> block until a) usb
>* requests have been completed or b) snd_rawmidi_write() times 
> out. */
> - if (req->length > 0)
> + if (req->length > 0) {
> + spin_unlock_irqrestore(>transmit_lock, flags);
>   return;
> + }
>  
>   for (i = midi->in_last_port; i < MAX_PORTS; i++) {
>   struct gmidi_in_port *port = midi->in_port[i];
> @@ -650,6 +658,8 @@ static void f_midi_transmit(struct f_midi *midi)
>   }
>   } while (active);
>  
> + spin_unlock_irqrestore(>transmit_lock, flags);
> +
>   return;
>  
>  drop_out:
> @@ -1255,6 +1265,8 @@ static struct usb_function *f_midi_alloc(struct 
> usb_function_instance *fi)
>   if (status)
>   goto setup_fail;
>  
> + spin_lock_init(>transmit_lock);
> +
>   ++opts->refcnt;
>   mutex_unlock(>lock);
>  
> -- 
> 2.5.0
> 
> --

-- 

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/

ACPI-fan: Another source code review around null pointer handling?

[SF Markus Elfring]

Hello,

I have looked at the source file for the ACPI fan driver once more.
I would appreciate if a specific implementation detail can be clarified there.

Static source code analysis can point out that functions like the following
share an approach for error detection and corresponding exception handling.
* acpi_fan_get_fif
* acpi_fan_get_fps
* fan_get_state_acpi4
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/acpi/fan.c?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n107

Can it matter eventually to handle a detected null pointer differently from
further checks for an attribute like "obj->type" or "obj->package"?

Regards,
Markus
--
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: algif_skcipher - Require setkey before accept(2)

[Julia Lawall]

On Fri, 25 Dec 2015, Herbert Xu wrote:

> On Fri, Dec 25, 2015 at 07:54:48AM +0100, Julia Lawall wrote:
> > Lines 766, 767 don't look correct at all.
> 
> Thanks Julia.  I have sent an updated patch in the original thread.
> I wonder why I haven't received the original kbuild test robot
> email though.

I goes to me to check for false positives first.

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

平时最多也就联系了三千家，全球还有十几万客户在哪里？

[iSayor]

您好:
您还在用ali平台开发外贸客户?
   还在使用展会宣传企业和产品?
 你out了!!!
 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 
 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？
 加QQ1286754208给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。
 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。
--
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 0/2] Improve drm_of_component_probe() and move rockchip to use it

[Jean-Francois Moine]

On Thu, 24 Dec 2015 12:36:10 +
Russell King - ARM Linux  wrote:

> It seems that you're trying to work around a limitation in Linux by
> modifying the hardware representation...

Sorry to come back to this topic, but I think you are wrong.

Looking at the imx6 DTs, the problem comes from the display-subsystem
node which is a pure Linux specific software entity.

If you want to describe only the hardware in the DT, everything is
simple.

A IPU is a image controller with its sub-devices. Seen from the system, it
is like a 'board' with its devices (LCDs, camera...).

When 2 IPUs, there are 2 independant boards.

Here is what could be a pure hardware DT:

/* no display-subsystem */

ipu1: ipu@0240 {/* image controller / board 1 */
compatible = "fsl,imx6q-ipu";
...
ports = <_di0>, <_di1>;
};
ipu1_di0: di@0 {/* display interface / crtc 1 */
compatible = "fsl,imx6q-di";
...
ipu1_di0_hdmi: endpoint@1 {
remote-endpoint = <_mux_0>;
};
ipu1_di0_mipi: endpoint@2 {
remote-endpoint = <_mux_0>;
}
...
};
ipu1_di1: di@1 {/* display interface / crtc 2 */
compatible = "fsl,imx6q-di";
...
ipu1_di1_hdmi: endpoint@1 {
remote-endpoint = <_mux_1>;
};
ipu1_di1_mipi: endpoint@2 {
remote-endpoint = <_mux_1>;
}
...
};

ipu2: ipu@0280 {/* image controller / board 2 */
compatible = "fsl,imx6q-ipu";
...
ports = <_di0>, <_di1>;
};
ipu2_di0: di@0 {/* display interface / crtc 1 */
compatible = "fsl,imx6q-di";
...
ipu2_di0_hdmi: endpoint@1 {
remote-endpoint = <_mux_2>;
};
ipu2_di0_mipi: endpoint@2 {
remote-endpoint = <_mux_2>;
}
...
};
ipu2_di1: di@1 {/* display interface / crtc 2 */
compatible = "fsl,imx6q-di";
...
ipu2_di1_hdmi: endpoint@1 {
remote-endpoint = <_mux_3>;
};
ipu2_di1_mipi: endpoint@2 {
remote-endpoint = <_mux_3>;
}
...
};

Then, a standard component binding (port->parent) works fine...

(you may note that the same problem exists with audio: the
'simple-card' is also a pure Linux specific software entity)

-- 
Merry Christmas | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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] ARM: omapfb: Add early framebuffer memory allocator

[Ivaylo Dimitrov]

On 26.12.2013 01:12, Ivaylo Dimitrov wrote:

From: Ivaylo Dimitrov 

On memory limited devices, CMA fails easily when asked to allocate big
chunks of memory like framebuffer memory needed for video playback.

Add boot parameter "omapfb_memsize" which allocates memory to be used
as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator when
trying to allocate memory for the framebuffers

Signed-off-by: Ivaylo Dimitrov 
---
  arch/arm/mach-omap2/common.c |1 +
  arch/arm/mach-omap2/common.h |2 +
  arch/arm/mach-omap2/fb.c |   46 +-
  3 files changed, 48 insertions(+), 1 deletions(-)



ping
--
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] gpio-ucb1400: Delete an unnecessary variable initialisation in ucb1400_gpio_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 25 Dec 2015 19:36:20 +0100

The variable "err" will eventually be set to an appropriate value
from a call of the gpiochip_add() function.
Thus let us omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/gpio/gpio-ucb1400.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-ucb1400.c b/drivers/gpio/gpio-ucb1400.c
index d502825..c963517 100644
--- a/drivers/gpio/gpio-ucb1400.c
+++ b/drivers/gpio/gpio-ucb1400.c
@@ -46,7 +46,7 @@ static void ucb1400_gpio_set(struct gpio_chip *gc, unsigned 
off, int val)
 static int ucb1400_gpio_probe(struct platform_device *dev)
 {
struct ucb1400_gpio *ucb = dev_get_platdata(>dev);
-   int err = 0;
+   int err;
 
if (!(ucb && ucb->gpio_offset)) {
err = -EINVAL;
-- 
2.6.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: [PATCH 3.2 46/77] drm: Fix an unwanted master inheritance v2

[Thomas Hellstrom]

On 12/24/2015 04:37 PM, Ben Hutchings wrote:
> 3.2.75-rc1 review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Thomas Hellstrom 
>
> commit a0af2e538c80f3e47f1d6ddf120a153ad909e8ad upstream.
>
> A client calling drmSetMaster() using a file descriptor that was opened
> when another client was master would inherit the latter client's master
> object and all its authenticated clients.
>
> This is unwanted behaviour, and when this happens, instead allocate a
> brand new master object for the client calling drmSetMaster().
>
> Fixes a BUG() throw in vmw_master_set().
>
> Signed-off-by: Thomas Hellstrom 
> Signed-off-by: Dave Airlie 
> [bwh: Backported to 3.2:
>  - s/master_mutex/struct_mutex/
>  - drm_new_set_master() must drop struct_mutex while calling
>drm_driver::master_create
>  - Adjust filename, context, indentation]
> Signed-off-by: Ben Hutchings 
> ---
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -225,6 +225,10 @@ int drm_setmaster_ioctl(struct drm_devic
>   if (!file_priv->minor->master &&
>   file_priv->minor->master != file_priv->master) {
>   mutex_lock(>struct_mutex);
> + if (!file_priv->allowed_master) {
> + ret = drm_new_set_master(dev, file_priv);
> + goto out_unlock;
> + }
>   file_priv->minor->master = drm_master_get(file_priv->master);
>   file_priv->is_master = 1;
>   if (dev->driver->master_set) {
> @@ -234,10 +238,11 @@ int drm_setmaster_ioctl(struct drm_devic
>   drm_master_put(_priv->minor->master);
>   }
>   }
> + out_unlock:
>   mutex_unlock(>struct_mutex);
>   }
>  
> - return 0;
> + return ret;
>  }
>  
>  int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -219,6 +219,62 @@ static int drm_cpu_valid(void)
>  }
>  
>  /**
> + * drm_new_set_master - Allocate a new master object and become master for 
> the
> + * associated master realm.
> + *
> + * @dev: The associated device.
> + * @fpriv: File private identifying the client.
> + *
> + * This function must be called with dev::struct_mutex held.
> + * Returns negative error code on failure. Zero on success.
> + */
> +int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
> +{
> + struct drm_master *old_master;
> + int ret;
> +
> + lockdep_assert_held_once(>struct_mutex);
> +

Is lockdep_assert_held_once() backported into the 3.2 series? If not,
this line could probably be replaced by lockdep_assert_held() for stable
kernels or removed entirely.

Thanks,
Thomas

--
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] um: Fix build error and kconfig for i386

[Richard Weinberger]

Am 25.12.2015 um 02:26 schrieb Josh Triplett:
> On Thu, Dec 24, 2015 at 01:09:45PM +0100, Mickaël Salaün wrote:
>>
>> On 23/12/2015 22:42, Josh Triplett wrote:
>>> On Wed, Dec 23, 2015 at 01:59:13PM +0100, Mickaël Salaün wrote:
 Fix build error by selecting COREDUMP when X86_32 is selected:

 arch/x86/um/built-in.o: In function `elf_core_write_extra_phdrs':
 (.text+0x3e62): undefined reference to `dump_emit'
 arch/x86/um/built-in.o: In function `elf_core_write_extra_data':
 (.text+0x3eef): undefined reference to `dump_emit'

 Fixes: 5d2acfc7b974 ("kconfig: make allnoconfig disable options behind 
 EMBEDDED and EXPERT")
 Signed-off-by: Mickaël Salaün 
 Cc: Jeff Dike 
 Cc: Richard Weinberger 
 Cc: Josh Triplett 
 Cc: Paul E. McKenney 
 Cc: Michal Marek 
 Cc: Andrew Morton 
 Cc: Linus Torvalds 
>>>
>>> I suppose um doesn't care deeply about binary size, but ideally I would
>>> suggest changing arch/x86/um/Makefile to make elfcore.c compiled in when
>>> CONFIG_ELF_CORE rather than CONFIG_BINFMT_ELF.
>>
>> That looks better! Since the first patch has been added to the mmots tree 
>> (but not yet in mmotm) I'll send a patch update instead of a new one 
>> reverting the first. I hope this is OK.
> 
> -mm regularly replaces patches with newer versions, so that ought to be
> fine.

Usually non-trivial UML stuff goes thought me.
As Josh noted, just post an updated version of the patch.
Either me or Andrew will pick it up.

Thanks,
//richard

--
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/2] mm, oom: introduce oom reaper

[Michal Hocko]

On Thu 24-12-15 20:06:50, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > This is VM_BUG_ON_PAGE(page_mapped(page), page), right? Could you attach
> > the full kernel log? It all smells like a race when OOM reaper tears
> > down the mapping and there is a truncate still in progress. But hitting
> > the BUG_ON just because of that doesn't make much sense to me. OOM
> > reaper is essentially MADV_DONTNEED. I have to think about this some
> > more, though, but I am in a holiday mode until early next year so please
> > bear with me.
> 
> I don't know whether the OOM killer was invoked just before this
> VM_BUG_ON_PAGE().
> 
> > Is this somehow DAX related?
> 
> 4.4.0-rc6-next-20151223_new_fsync_v6+ suggests that this kernel
> has "[PATCH v6 0/7] DAX fsync/msync support" applied. But I think
> http://marc.info/?l=linux-mm=145068666428057 should be applied
> when retesting. (20151223 does not have this fix.)

Hmm, I think you are right! Very well spotted! If ignore_dirty ends up
being true then we would simply skip over dirty page and wouldn't end up
doing page_remove_rmap. I can see that the truncation code can later trip
over this page.

Thanks!
-- 
Michal Hocko
SUSE Labs
--
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/2] mm, oom: introduce oom reaper

[Michal Hocko]

On Fri 25-12-15 12:35:37, Michal Hocko wrote:
[...]
> Thanks I will try to reproduce early next year. But so far I think this
> is just a general issue of MADV_DONTNEED vs. truncate and oom_reaper is
> just lucky to trigger it. There shouldn't be anything oom_reaper
> specific here. Maybe there is some additional locking missing?

Hmm, scratch that. I think Tetsuo has nailed it. It seems like
the missing initialization of details structure during unmap
is the culprit. So there most probably was on OOM killing
invoked. It is just a side effect of the patch and missing
http://marc.info/?l=linux-mm=145068666428057 follow up fix.
-- 
Michal Hocko
SUSE Labs
--
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 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks

[Borislav Petkov]

On Tue, Dec 15, 2015 at 05:30:49PM -0800, Tony Luck wrote:
> Using __copy_user_nocache() as inspiration create a memory copy
> routine for use by kernel code with annotations to allow for
> recovery from machine checks.
> 
> Notes:
> 1) We align the source address rather than the destination. This
>means we never have to deal with a memory read that spans two
>cache lines ... so we can provide a precise indication of
>where the error occurred without having to re-execute at
>a byte-by-byte level to find the exact spot like the original
>did.
> 2) We 'or' BIT(63) into the return if the copy failed because of
>a machine check. If we failed during a copy from user space
>because the user provided a bad address, then we just return
>then number of bytes not copied like other copy_from_user
>functions.
> 3) This code doesn't play any cache games. Future functions can
>use non-temporal loads/stores to meet needs of different callers.
> 4) Provide helpful macros to decode the return value.
> 
> Signed-off-by: Tony Luck 
> ---
> Boris: This version has all the return options coded.
>   return 0; /* SUCCESS */
>   return remain_bytes | (1ul << 63); /* failed because of machine check */
>   return remain_bytes; /* failed because of invalid source address */

Ok, how about a much simpler approach and finally getting rid of that
bit 63? :-)

Here's what we could do, it is totally untested but at least it builds
here (full patch below).

So first we define __mcsafe_copy to return two u64 values, or two
int values or whatever... Bottomline is, we return 2 values with
remain_bytes in %rdx and the actual error in %rax.

+struct mcsafe_ret {
+   u64 ret;
+   u64 remain;
+};
+
+struct mcsafe_ret __mcsafe_copy(void *dst, const void __user *src, unsigned 
size);

Then, in fixup_exception()/fixup_mcexception(), we set the *respective*
regs->ax (which is mcsafe_ret.ret) depending on which function is fixing
up the exception. I've made it return -EINVAL and -EFAULT respectively
but those are arbitrary.

We detect that we're in __mcsafe_copy() by using its start and a
previously defined end label. I've done this in order to get rid of the
mce-specific exception tables. Mind you, this is still precise enough
since we're using the _ASM_EXTABLE entries from __mcsafe_copy.

And this approach gets rid of those mce-specific exception tables, bit
63, makes __mcsafe_copy simpler, you name it... :-)

Thoughts?

---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index adb28a2dab44..efef4d72674c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1021,6 +1021,16 @@ config X86_MCE_INJECT
  If you don't know what a machine check is and you don't do kernel
  QA it is safe to say n.
 
+config MCE_KERNEL_RECOVERY
+   bool "Recovery from machine checks in special kernel memory copy 
functions"
+   default n
+   depends on X86_MCE && X86_64
+   ---help---
+ This option provides a new memory copy function mcsafe_memcpy()
+ that is annotated to allow the machine check handler to return
+ to an alternate code path to return an error to the caller instead
+ of crashing the system. Say yes if you have a driver that uses this.
+
 config X86_THERMAL_VECTOR
def_bool y
depends on X86_MCE_INTEL
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 2ea4527e462f..9c5371d1069b 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -287,4 +287,13 @@ struct cper_sec_mem_err;
 extern void apei_mce_report_mem_error(int corrected,
  struct cper_sec_mem_err *mem_err);
 
+#ifdef CONFIG_MCE_KERNEL_RECOVERY
+int fixup_mcexception(struct pt_regs *regs);
+#else
+static inline int fixup_mcexception(struct pt_regs *regs)
+{
+   return 0;
+}
+#endif
+
 #endif /* _ASM_X86_MCE_H */
diff --git a/arch/x86/include/asm/string_64.h b/arch/x86/include/asm/string_64.h
index ff8b9a17dc4b..6b6431797749 100644
--- a/arch/x86/include/asm/string_64.h
+++ b/arch/x86/include/asm/string_64.h
@@ -78,6 +78,16 @@ int strcmp(const char *cs, const char *ct);
 #define memset(s, c, n) __memset(s, c, n)
 #endif
 
+#ifdef CONFIG_MCE_KERNEL_RECOVERY
+struct mcsafe_ret {
+   u64 ret;
+   u64 remain;
+};
+
+struct mcsafe_ret __mcsafe_copy(void *dst, const void __user *src, unsigned 
size);
+extern void __mcsafe_copy_end(void);
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif /* _ASM_X86_STRING_64_H */
diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h 
b/arch/x86/kernel/cpu/mcheck/mce-internal.h
index 547720efd923..e8a2c8067fcb 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-internal.h
+++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h
@@ -80,4 +80,12 @@ static inline int apei_clear_mce(u64 record_id)
 }
 #endif
 
+#ifdef CONFIG_MCE_KERNEL_RECOVERY
+static inline bool mce_in_kernel_recov(unsigned long addr)
+{
+   return (addr >= (unsigned 

[PATCH] pinctrl: qcom: make PMIC drivers bool

[Linus Walleij]

commit ab4256cfeab91569e1d96e7f0014538fe0845259
"pinctrl: qcom: pmic-gpio/mpp: of_irq_count() == npins"
made the Qualcomm PMIC pin control drivers make use of
of_irq_count() which is not an exported function, making
modular builds fail.

Fix this by marking the drivers as compiled-in/bool.

Cc: Stephen Boyd 
Cc: Andy Gross 
Cc: Mark Brown 
Signed-off-by: Linus Walleij 
---
 drivers/pinctrl/qcom/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index eeac8cba8a21..c658d9bce285 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -80,7 +80,7 @@ config PINCTRL_QDF2XXX
  Qualcomm Technologies QDF2xxx SOCs.
 
 config PINCTRL_QCOM_SPMI_PMIC
-   tristate "Qualcomm SPMI PMIC pin controller driver"
+   bool "Qualcomm SPMI PMIC pin controller driver"
depends on GPIOLIB && OF && SPMI
select REGMAP_SPMI
select PINMUX
@@ -93,7 +93,7 @@ config PINCTRL_QCOM_SPMI_PMIC
  devices are pm8841, pm8941 and pma8084.
 
 config PINCTRL_QCOM_SSBI_PMIC
-   tristate "Qualcomm SSBI PMIC pin controller driver"
+   bool "Qualcomm SSBI PMIC pin controller driver"
depends on GPIOLIB && OF
select PINMUX
select PINCONF
-- 
2.4.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: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Pali Rohár]

On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > * Arnd Bergmann  [150515 14:26]:
> > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > If setting up the generic binding is expected to take a while,
> > you can naturally pass it in pdata while waiting for the generic
> > binding to get merged.
> 
> Yes, good idea. So the n900 machine can use auxdata to pass this for
> the time being, while the binding and generic implementation is
> being worked out.
> 
>   Arnd

Ok, so what is needed to finish this patch series?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] crypto: ccp - use to_pci_dev and to_platform_device

[Herbert Xu]

On Wed, Dec 23, 2015 at 08:49:01PM +0800, Geliang Tang wrote:
> Use to_pci_dev() and to_platform_device() instead of open-coding.
> 
> Signed-off-by: Geliang Tang 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/

sata_mv: Another source code review around exception handling?

[SF Markus Elfring]

Hello,

I have looked at the source file for the Marvell SATA support driver once more.
I would appreciate if a specific implementation detail can be clarified there.

Static source code analysis can point out that functions like the following
are called by the mv_platform_probe() function.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/ata/sata_mv.c?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n4055

* ata_host_alloc_pinfo
  http://lxr.free-electrons.com/source/drivers/ata/libata-core.c?v=4.3#L5768

* devm_kzalloc
  http://lxr.free-electrons.com/source/include/linux/device.h?v=4.3#L645


The value "-ENOMEM" will be returned if one of these function calls failed.
Can it be that any system resources (like memory) are not appropriately
released if any calls of this sequence succeeded before the failure?


Is the use of the single jump label "err" also suspicious here?

Regards,
Markus
--
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] parisc syscall restart fix for v4.4

[Helge Deller]

Hi Linus,

please pull one late patch for the parisc architecture for kernel v4.4 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
parisc-4.4-4

The architectural design of parisc always uses two instructions to call kernel
syscalls (delayed branch feature). This means that the instruction following
the branch (located in the delay slot of the branch instruction) is executed
before control passes to the branch destination.
Depending on which assembler instruction and how it is used in usersapce in
the delay slot, this sometimes made restarted syscalls like futex() and poll()
failing with -ENOSYS.

Thanks,
Helge


Helge Deller (1):
  parisc: Fix syscall restarts

 arch/parisc/kernel/signal.c | 64 -
 1 file changed, 52 insertions(+), 12 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 1/2] dell-wmi: Check if Dell WMI descriptor structure is valid

[Pali Rohár]

On Friday 25 December 2015 02:23:04 Andy Lutomirski wrote:
> On Thu, Dec 24, 2015 at 1:18 PM, Pali Rohár 
> wrote:
> > According to Dell WMI document mentioned in ML dicussion archived
> > at http://www.spinics.net/lists/platform-driver-x86/msg07220.html
> > OS should check Dell WMI descriptor structure. Structure also
> > provide Dell WMI interface version which is used later.
> 
> I will rebase my big series on top of this.  It'll give me a good
> excuse to test that I got the probe ordering right.  (The code is
> explicitly intended to support use cases like this, and now I'll have
> a real-world test for it.)  I'll also test this in a bit.

Ok!

> > +MODULE_ALIAS("wmi:"DELL_DESCRIPTOR_GUID);
> 
> I don't think this is necessary.  The driver will only work if both
> wmi devices and, hence, modaliases are present, so there's no need to
> cause just one or the other to trigger dell-wmi autoloading.

Maybe now when you are working on big WMI patch series is time to change 
modalias support in WMI to support AND-conjunction (&&) on WMI aliases, 
not just OR (one alias match).

Something like: load dell-wmi.ko driver if system provides both WMI 
GUIDs.

> > +/**
> 
> > + * Descriptor buffer is 128 byte long and contains:
> This isn't kerneldoc format, so I think this should just be "/*".
> 

Ok, I will fix this in next version.

> > +   if (obj->buffer.length != 128) {
> > +   pr_err("Dell descriptor buffer has invalid length
> > (%d)\n", +   obj->buffer.length);
> > +   kfree(obj);
> > +   return -EINVAL;
> > +   }
> 
> I would advocate for being more permissive: a buffer that is actually
> too short for the fields we need would result in -EINVAL, but a
> buffer that isn't 128 bytes would just be a warning and not cause
> module load to fail.
> 
> --Andy

Sounds good, I will change this part.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v3] um: Fix build error and kconfig for i386

[Mickaël Salaün]

On 25/12/2015 02:34, Josh Triplett wrote:
> On Thu, Dec 24, 2015 at 01:12:11PM +0100, Mickaël Salaün wrote:
>> Fix build error by generating elfcore.o only when ELF_CORE (depending on
>> COREDUMP) is selected:
>>
>> arch/x86/um/built-in.o: In function `elf_core_write_extra_phdrs':
>> (.text+0x3e62): undefined reference to `dump_emit'
>> arch/x86/um/built-in.o: In function `elf_core_write_extra_data':
>> (.text+0x3eef): undefined reference to `dump_emit'
>>
>> Fixes: 5d2acfc7b974 ("kconfig: make allnoconfig disable options behind 
>> EMBEDDED and EXPERT")
>> Signed-off-by: Mickaël Salaün 
>> Cc: Jeff Dike 
>> Cc: Richard Weinberger 
>> Cc: Josh Triplett 
>> Cc: Paul E. McKenney 
>> Cc: Michal Marek 
>> Cc: Andrew Morton 
>> Cc: Linus Torvalds 
> 
> It looks like ELF_CORE depends on COREDUMP, but not on BINFMT_ELF.
> Should it?  What happens if you build this with ELF_CORE=y and
> BINFMT_ELF=n?  Does that configuration even make sense?

It build fine with ELF_CORE=y and BINFMT_ELF=n but does not seem useful. 
Nevertheless, it's the same for all architectures (cf. init/Kconfig): ELF_CORE 
only depends on COREDUMP.

 Mickaël



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] mm, oom: introduce oom reaper

[Michal Hocko]

On Thu 24-12-15 13:44:03, Ross Zwisler wrote:
> On Thu, Dec 24, 2015 at 2:47 AM, Michal Hocko  wrote:
> > On Wed 23-12-15 16:00:09, Ross Zwisler wrote:
> > [...]
> >> While running xfstests on next-20151223 I hit a pair of kernel BUGs
> >> that bisected to this commit:
> >>
> >> 1eb3a80d8239 ("mm, oom: introduce oom reaper")
> >
> > Thank you for the report and the bisection.
> >
> >> Here is a BUG produced by generic/029 when run against XFS:
> >>
> >> [  235.751723] [ cut here ]
> >> [  235.752194] kernel BUG at mm/filemap.c:208!
> >
> > This is VM_BUG_ON_PAGE(page_mapped(page), page), right? Could you attach
> > the full kernel log? It all smells like a race when OOM reaper tears
> > down the mapping and there is a truncate still in progress. But hitting
> > the BUG_ON just because of that doesn't make much sense to me. OOM
> > reaper is essentially MADV_DONTNEED. I have to think about this some
> > more, though, but I am in a holiday mode until early next year so please
> > bear with me.
> 
> The two stack traces were gathered with next-20151223, so the line numbers
> may have moved around a bit when compared to the actual "mm, oom: introduce
> oom reaper" commit.

I was looking at the same next tree, I believe
$ git describe
next-20151223

[...]
> > There was a warning before this triggered. The full kernel log would be
> > helpful as well.
> 
> Sure, I can gather full kernel logs, but it'll probably after the new year.

OK, I will wait for the logs. It is really interesting to see what was
the timing between OOM killer invocation and this trace.

> > [...]
> >> [  609.425325] Call Trace:
> >> [  609.425797]  [] invalidate_inode_pages2+0x17/0x20
> >> [  609.426971]  [] xfs_file_read_iter+0x297/0x300
> >> [  609.428097]  [] __vfs_read+0xc9/0x100
> >> [  609.429073]  [] vfs_read+0x89/0x130
> >> [  609.430010]  [] SyS_read+0x58/0xd0
> >> [  609.430943]  [] entry_SYSCALL_64_fastpath+0x12/0x76
> >> [  609.432139] Code: 85 d8 fe ff ff 01 00 00 00 f6 c4 40 0f 84 59 ff
> >> ff ff 49 8b 47 20 48 8d 78 ff a8 01 49 0f 44 ff 8b 47 48 85 c0 0f 88
> >> bd 01 00 00 <0f> 0b 4d 3b 67 08 0f 85 70 ff ff ff 49 f7 07 00 18 00 00
> >> 74 15
> > [...]
> >> My test setup is a qemu guest machine with a pair of 4 GiB PMEM
> >> ramdisk test devices, one for the xfstest test disk and one for the
> >> scratch disk.
> >
> > Is this just a plain ramdisk device or it needs a special configuration?
> 
> Just a plain PMEM ram disk with DAX turned off.  Configuration instructions
> for PMEM can be found here:
> 
> https://nvdimm.wiki.kernel.org/

Thanks I will try to reproduce early next year. But so far I think this
is just a general issue of MADV_DONTNEED vs. truncate and oom_reaper is
just lucky to trigger it. There shouldn't be anything oom_reaper
specific here. Maybe there is some additional locking missing?

-- 
Michal Hocko
SUSE Labs
--
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 v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag

[Jingoo Han]

On Thursday, December 24, 2015 10:23 AM, Yakir Yang wrote:
> 
> Hi Jingoo,
> 
> Okay, fine, I would drop this patch, until I found the the root cause.

OK, I see.

Best regards,
Jingoo Han

> 
> - Yakir
> 
> On 12/23/2015 11:10 PM, Jingoo Han wrote:
> > On Wednesday, December 23, 2015 9:51 PM, Yakir Yang wrote:
> >> On Rockchip platform, sometimes driver would failed at reading EDID
> >> message, and it's caused by the AUX reply flag wouldn't received under
> >> the 100*10us wait time.
> > The problem is specific for Rockchip platform.
> > Also, 1 ms is long time.
> > The best way is that your hardware engineers find the root cause.
> > I cannot understand why your engineers cannot find the root cause. :-(
> >
> >> But after expand the wait time a little, the AUX reply flag would be
> >> set, so maybe the wait time is a little critical. Besides the analogix
> >> dp book haven't reminded the standard wait for looking AUX reply flag,
> >> so I thought it's okay to expand the wait time.
> >>
> >> And the external wait time won't hurt Exynos DP too much, cause they
> >> wouldn't meet this problem, then driver would received the reply command
> >> very soon, so no more additional wait time would bring to Exynos platform.
> > Then, when loop time happens on Exynos platform, it will take long time
> > to return error.
> >
> >> Signed-off-by: Yakir Yang 
> >> ---
> >> Changes in v12:
> >> - Using another way to expand the AUX reply wait time (Jingoo)
> >>
> >> Changes in v11: None
> >> Changes in v10: None
> >> Changes in v9: None
> >> Changes in v8: None
> >> Changes in v7: None
> >> Changes in v6: None
> >> Changes in v5: None
> >> Changes in v4: None
> >> Changes in v3: None
> >> Changes in v2: None
> >>
> >>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
> >>   1 file changed, 4 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> index cba3ffd..8687eea 100644
> >> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> @@ -471,7 +471,7 @@ int analogix_dp_start_aux_transaction(struct 
> >> analogix_dp_device *dp)
> >>   {
> >>int reg;
> >>int retval = 0;
> >> -  int timeout_loop = 0;
> >> +  unsigned long timeout;
> >>
> >>/* Enable AUX CH operation */
> >>reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
> >> @@ -479,14 +479,12 @@ int analogix_dp_start_aux_transaction(struct 
> >> analogix_dp_device *dp)
> >>writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
> >>
> >>/* Is AUX CH command reply received? */
> >> -  reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> >> -  while (!(reg & RPLY_RECEIV)) {
> >> -  timeout_loop++;
> >> -  if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> >> +  timeout = jiffies + msecs_to_jiffies(5);
> >> +  while ((readl(dp->reg_base + ANALOGIX_DP_INT_STA) & RPLY_RECEIV) == 0) {
> >> +  if (time_after(jiffies, timeout)) {
> >>dev_err(dp->dev, "AUX CH command reply failed!\n");
> >>return -ETIMEDOUT;
> >>}
> >> -  reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> > Sorry, I don't like your patch.
> >
> > The problem happens because of Rockchip platform.
> > So, you need to add workaround for only Rockchip platform.
> >
> > Just add new DT property and new variable for the value for wait time.
> > When, the probe is called, new wait time value is read from Rockchip DT 
> > file.
> > Then, the new wait time value can be written to the new variable.
> >
> >  new DT property: wait-time-aux
> >  new variable: wait_time_aux
> >
> >
> > If ( ) // New DT
> >  wait_time_aux = New DT;
> > else
> >  wait_time_aux = 10;
> >
> >
> >>usleep_range(10, 11);
> > If there is NO  new wait time value from DT file, the default value '10' is
> > used for sleep.
> >
> > But, if there is new wait time value from DT file, new wait time value
> > can be used for sleep.
> >
> >   usleep_range(dp->wait_time_aux, dp->wait_time_aux + 1);
> >
> > What I want to say is that there should be NO effect on Exynos platform,
> > because of the hardware bug of Rockchip platform.
> >
> > Best regards,
> > Jingoo Han
> >
> >>}
> >>
> >> --
> >> 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 v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

[Ivaylo Dimitrov]

Hi Tomi,

On 13.01.2014 12:20, Tomi Valkeinen wrote:

On 2014-01-11 11:39, Ivaylo Dimitrov wrote:


The patch does not apply cleanly on top of rc7, however I applied it by
hand. So far it seems it fixes the issue brought by
c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if
mutex_lock/mutex_unlock are complementary in every code path (at least
not explicitly, I guess maemo is doing it for us anyway :) ).


Ok, thanks.


So, shall I send a patch incorporating your code changes, or you will do
it?


I can handle it.

  Tomi




I still don't see those fixes in mainline, shall I send a patch?

Ivo
--
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] null_blk: don't enable irqs when in irq

[Rabin Vincent]

When using irq_mode=NULL_IRQ_TIMER, blk_start_queue() is called from the
hrtimer interrupt.  null_request_fn() calls spin_unlock_irq() and this
causes the following splat from lockdep since interrupts are being
enabled while we're in an interrupt handler.

When we're in null_request_fn() we can't know the status of the flags
saved before blk_start_queue() was called, but we can use in_irq() to
conditionally enable interrupts only if we're not in a hard interrupt in
order to handle this case.

 [ cut here ]
 WARNING: CPU: 0 PID: 398 at kernel/locking/lockdep.c:2608 
trace_hardirqs_on_caller+0x11a/0x1b0()
 DEBUG_LOCKS_WARN_ON(current->hardirq_context)
 CPU: 0 PID: 398 Comm: mkfs.ext4 Not tainted 4.4.0-rc6+ #77
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 
04/01/2014
 Call Trace:
[] dump_stack+0x4e/0x82
  [] warn_slowpath_common+0x82/0xc0
  [] ? _raw_spin_unlock_irq+0x2c/0x60
  [] ? null_softirq_done_fn+0x30/0x30
  [] warn_slowpath_fmt+0x4c/0x50
  [] trace_hardirqs_on_caller+0x11a/0x1b0
  [] trace_hardirqs_on+0xd/0x10
  [] _raw_spin_unlock_irq+0x2c/0x60
  [] null_request_fn+0x4e/0xb0
  [] __blk_run_queue+0x33/0x40
  [] blk_start_queue+0x3f/0x80
  [] end_cmd+0x117/0x120
  [] null_cmd_timer_expired+0x12/0x20
  [] __hrtimer_run_queues+0x12b/0x4b0
  [] hrtimer_interrupt+0xaf/0x1b0
  [] local_apic_timer_interrupt+0x36/0x60
  [] smp_apic_timer_interrupt+0x3d/0x50
  [] apic_timer_interrupt+0x8c/0xa0
[] ? fprop_fraction_percpu+0xeb/0x110
  [] ? __wb_calc_thresh+0x2f/0xc0
  [] __wb_calc_thresh+0x2f/0xc0
  [] ? domain_dirty_limits+0x1bc/0x1f0
  [] balance_dirty_pages_ratelimited+0x6d5/0xfb0
  [] ? rcu_read_lock_sched_held+0x77/0x90
  [] ? __block_commit_write.isra.1+0x7a/0xb0
  [] generic_perform_write+0x14c/0x1c0
  [] __generic_file_write_iter+0x190/0x1f0
  [] blkdev_write_iter+0x7b/0x100
  [] __vfs_write+0xaa/0xe0
  [] vfs_write+0x95/0x100
  [] ? __fget_light+0x6f/0x90
  [] SyS_pwrite64+0x77/0x90
  [] entry_SYSCALL_64_fastpath+0x12/0x76
 ---[ end trace 39b7df36fb237be1 ]---

Signed-off-by: Rabin Vincent 
---
 drivers/block/null_blk.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index a428e4e..d16c5dc 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -342,13 +342,20 @@ static int null_rq_prep_fn(struct request_queue *q, 
struct request *req)
 static void null_request_fn(struct request_queue *q)
 {
struct request *rq;
+   bool irq = in_irq();
 
while ((rq = blk_fetch_request(q)) != NULL) {
struct nullb_cmd *cmd = rq->special;
 
-   spin_unlock_irq(q->queue_lock);
+   if (irq)
+   spin_unlock(q->queue_lock);
+   else
+   spin_unlock_irq(q->queue_lock);
null_handle_cmd(cmd);
-   spin_lock_irq(q->queue_lock);
+   if (irq)
+   spin_lock(q->queue_lock);
+   else
+   spin_lock_irq(q->queue_lock);
}
 }
 
-- 
2.6.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 0/2] two fixes for new bq27000/10 and bq27500 driver

[Pali Rohár]

On Thursday 24 December 2015 14:57:56 Andrew F. Davis wrote: 
> > Also I wonder if you would be available as official reviewer for
> > the driver.
> 
> Sure, what's the normal procedure for this, should I submit a
> patch adding myself to that driver in MAINTAINERS?

Yes, send patch.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] power:bq27xxx: fix reading for bq27000 and bq27010

[Pali Rohár]

On Thursday 17 December 2015 11:12:53 H. Nikolaus Schaller wrote:
> bug: the driver reports funny capacity values:
> 
> root@letux:/sys/class/power_supply/bq27000-battery# cat uevent
> POWER_SUPPLY_NAME=bq27000-battery
> POWER_SUPPLY_STATUS=Charging
> POWER_SUPPLY_PRESENT=1
> POWER_SUPPLY_VOLTAGE_NOW=3702000
> POWER_SUPPLY_CURRENT_NOW=-464635
> POWER_SUPPLY_CAPACITY=1536<- over 100% is magic
> POWER_SUPPLY_CAPACITY_LEVEL=Normal
> POWER_SUPPLY_TEMP=311
> POWER_SUPPLY_TIME_TO_FULL_NOW=10440
> POWER_SUPPLY_TECHNOLOGY=Li-ion
> POWER_SUPPLY_CHARGE_FULL=805450
> POWER_SUPPLY_CHARGE_NOW=1068
> POWER_SUPPLY_CHARGE_FULL_DESIGN=8844998   <- battery has just 1200 mAh
> POWER_SUPPLY_CYCLE_COUNT=21
> POWER_SUPPLY_ENERGY_NOW=0
> POWER_SUPPLY_POWER_AVG=0
> POWER_SUPPLY_HEALTH=Good
> POWER_SUPPLY_MANUFACTURER=Texas Instruments
> 
> reason: the state of charge and the design capacity register are
> single byte only. The design capacity returns the higer order byte.
> 
> tested: GTA04 with Openmoko/FIC HF08x battery (using hdq)
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  drivers/power/bq27xxx_battery.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/power/bq27xxx_battery.c
> b/drivers/power/bq27xxx_battery.c index 880233c..e54a125 100644
> --- a/drivers/power/bq27xxx_battery.c
> +++ b/drivers/power/bq27xxx_battery.c
> @@ -471,7 +471,10 @@ static int bq27xxx_battery_read_soc(struct
> bq27xxx_device_info *di) {
>   int soc;
> 
> - soc = bq27xxx_read(di, BQ27XXX_REG_SOC, false);
> + if (di->chip == BQ27000 || di->chip == BQ27010)
> + soc = bq27xxx_read(di, BQ27XXX_REG_SOC, true);
> + else
> + soc = bq27xxx_read(di, BQ27XXX_REG_SOC, false);
> 
>   if (soc < 0)
>   dev_dbg(di->dev, "error reading State-of-Charge\n");
> @@ -536,7 +539,10 @@ static int bq27xxx_battery_read_dcap(struct
> bq27xxx_device_info *di) {
>   int dcap;
> 
> - dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, false);
> + if (di->chip == BQ27000 || di->chip == BQ27010)
> + dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, true);
> + else
> + dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, false);
> 
>   if (dcap < 0) {
>   dev_dbg(di->dev, "error reading initial last measured
> discharge\n"); @@ -544,7 +550,7 @@ static int
> bq27xxx_battery_read_dcap(struct bq27xxx_device_info *di) }
> 
>   if (di->chip == BQ27000 || di->chip == BQ27010)
> - dcap *= BQ27XXX_CURRENT_CONSTANT / BQ27XXX_RS;
> + dcap = (dcap << 8) * BQ27XXX_CURRENT_CONSTANT / BQ27XXX_RS;
>   else
>   dcap *= 1000;

Hi!

This patch fixes commit d74534c27775857cb09abd0f92ed9539dc8d0a93 (power: 
bq27xxx_battery: Add support for additional bq27xxx family devices) in 
which this bug (all 3 patch chunks) were introduced.

Before that commit code was very similar after applying this patch. So:

Reviewed-by: Pali Rohár 

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: mmc does not work in qemu n900

[Pali Rohár]

On Monday 26 January 2015 22:04:59 Pali Rohár wrote:
> Hello,
> 
> for unknown reason kernel in qemu n900 machine is not able to
> detect internal eMMC memory. External SD card is detected without
> problem.
> 
> If I apply this one-line patch eMMC in qemu start working:
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 9584bff..0d4461c 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -2337,6 +2337,9 @@ static int mmc_rescan_try_freq(
>   return 0;
>   if (!mmc_attach_sd(host))
>   return 0;
> +
> + mmc_go_idle(host);
> +
>   if (!mmc_attach_mmc(host))
>   return 0;
> 
> I played with mmc and qemu n900 a bit and also this simple patch
> (without first) fix problem (that mmc is not detected by kernel):
> 
> diff --git a/drivers/mmc/core/mmc_ops.c
> b/drivers/mmc/core/mmc_ops.c
> index 3b044c5..0c93a2c 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -157,6 +157,10 @@ int mmc_send_op_cond(
> 
>   BUG_ON(!host);
> 
> + /* reset mmc before calling op_cond */
> + memset(, 0, sizeof(struct mmc_command));
> + mmc_wait_for_cmd(host, , MMC_CMD_RETRIES);
> +
>   cmd.opcode = MMC_SEND_OP_COND;
>   cmd.arg = mmc_host_is_spi(host) ? 0 : ocr;
>   cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R3 | MMC_CMD_BCR;
> 
> 
> I have no idea where is problem. I also do not understand mmc
> kernel code, but second patch I have on my HDD since 2.6.37.
> 
> Can somebody with knowledge of mmc subsystem look at this
> problem? Why any of these two patches fix problem when mmc is not
> detected by kernel in qemu (machine n900)? Detection of mmc fails
> because function mmc_send_op_cond() without one of above patches
> fails.

I will bring this tread to front again as mmc without one of provided 
patches does not work with 4.4-rc6 kernel in N900 qemu.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

[PATCH v2 11/16] arm/samsung: Change s3c_pm_run_res() to use System RAM type

[Toshi Kani]

Change s3c_pm_run_res() to check with IORESOURCE_SYSTEM_RAM,
instead of strcmp() with "System RAM", to walk through
System RAM ranges in the iomem table.

No functional change is made to the interface.

Cc: Krzysztof Kozlowski 
Cc: linux-samsung-...@vger.kernel.org
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Toshi Kani 
---
 arch/arm/plat-samsung/pm-check.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/pm-check.c b/arch/arm/plat-samsung/pm-check.c
index 04aff2c..70f2f69 100644
--- a/arch/arm/plat-samsung/pm-check.c
+++ b/arch/arm/plat-samsung/pm-check.c
@@ -53,8 +53,8 @@ static void s3c_pm_run_res(struct resource *ptr, run_fn_t fn, 
u32 *arg)
if (ptr->child != NULL)
s3c_pm_run_res(ptr->child, fn, arg);
 
-   if ((ptr->flags & IORESOURCE_MEM) &&
-   strcmp(ptr->name, "System RAM") == 0) {
+   if ((ptr->flags & IORESOURCE_SYSTEM_RAM)
+   == IORESOURCE_SYSTEM_RAM) {
S3C_PMDBG("Found system RAM at %08lx..%08lx\n",
  (unsigned long)ptr->start,
  (unsigned long)ptr->end);
--
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/