Re: [PATCH v6] USB: serial: add Moxa UPORT 11x0 driver

[Johan Hovold]

On Mon, Dec 28, 2015 at 09:21:25PM +0100, Mathieu OTHACEHE wrote:
> Add a driver which supports :
> 
> - UPort 1110  : 1 port RS-232 USB to Serial Hub.
> - UPort 1130  : 1 port RS-422/485 USB to Serial Hub.
> - UPort 1130I : 1 port RS-422/485 USB to Serial Hub with Isolation.
> - UPort 1150  : 1 port RS-232/422/485 USB to Serial Hub.
> - UPort 1150I : 1 port RS-232/422/485 USB to Serial Hub with Isolation.
> 
> This driver is based on GPL MOXA driver written by Hen Huang and available
> on MOXA website. The original driver was based on io_ti serial driver.
> 
> Signed-off-by: Mathieu OTHACEHE 
> ---
> 
> Hi Johan,
> 
> Here is the v6 of the driver.
> 
> I understand the problems with the TIOCSRS485/TIOCGRS485 ioctls in
> this driver.
> For now, I prefer dropping mode switching support from the driver as
> you suggested.
>
> So UPORT 1110 and 1150 only support RS232 and UPORT 1130 only support
> RS-485-2W.
> If a new interface is developped, I'll restore mode switching code.

Sounds good.
 
> About firmware images, I just sent a patch to linux-firmware. Here is the 
> link :
> https://lkml.org/lkml/2015/12/28/239

Thanks, I've done some quick tests using a 1150 now. When looking
through the code one last time I found a few issues that I fixed up. I'll
submit patches for these to the USB list.

But there are couple of things you could consider to do as follow ups as
well. Details below.

> +static int mxu1_port_probe(struct usb_serial_port *port)
> +{
> + struct mxu1_port *mxport;
> + struct mxu1_device *mxdev;
> + struct urb *urb;
> +
> + mxport = kzalloc(sizeof(struct mxu1_port), GFP_KERNEL);
> + if (!mxport)
> + return -ENOMEM;
> +
> + spin_lock_init(>spinlock);
> + mutex_init(>mutex);
> +
> + mxdev = usb_get_serial_data(port->serial);
> +
> + urb = port->interrupt_in_urb;
> + if (!urb) {

You are leaking the port private data here (fixed).

> + dev_err(>dev, "%s - no interrupt urb\n", __func__);
> + return -EINVAL;
> + }
> +
> + switch (mxdev->mxd_model) {
> + case MXU1_1110_PRODUCT_ID:
> + case MXU1_1150_PRODUCT_ID:
> + case MXU1_1151_PRODUCT_ID:
> + mxport->uart_mode = MXU1_UART_232;
> + break;
> + case MXU1_1130_PRODUCT_ID:
> + case MXU1_1131_PRODUCT_ID:
> + mxport->uart_mode = MXU1_UART_485_RECEIVER_DISABLED;
> + break;
> + }
> +
> + usb_set_serial_port_data(port, mxport);
> +
> + port->port.closing_wait =
> + msecs_to_jiffies(MXU1_DEFAULT_CLOSING_WAIT * 10);
> + port->port.drain_delay = 1;
> +
> + return 0;
> +}
> +
> +static int mxu1_startup(struct usb_serial *serial)
> +{
> + struct mxu1_device *mxdev;
> + struct usb_device *dev = serial->dev;
> + struct usb_host_interface *cur_altsetting;
> + char fw_name[32];
> + const struct firmware *fw_p = NULL;
> + int err;
> + int status = 0;
> +
> + dev_dbg(>interface->dev, "%s - product 0x%04X, num 
> configurations %d, configuration value %d\n",
> + __func__, le16_to_cpu(dev->descriptor.idProduct),
> + dev->descriptor.bNumConfigurations,
> + dev->actconfig->desc.bConfigurationValue);
> +
> + /* create device structure */
> + mxdev = kzalloc(sizeof(struct mxu1_device), GFP_KERNEL);
> + if (!mxdev)
> + return -ENOMEM;
> +
> + usb_set_serial_data(serial, mxdev);
> +
> + mxdev->mxd_model = le16_to_cpu(dev->descriptor.idProduct);
> +
> + cur_altsetting = serial->interface->cur_altsetting;
> +
> + /* if we have only 1 configuration, download firmware */
> + if (cur_altsetting->desc.bNumEndpoints == 1) {
> +
> + snprintf(fw_name,
> +  sizeof(fw_name),
> +  "moxa/moxa-%04x.fw",
> +  mxdev->mxd_model);
> +
> + err = request_firmware(_p, fw_name, >interface->dev);
> + if (err) {
> + dev_err(>interface->dev, "failed to request 
> firmware: %d\n",
> + err);
> + kfree(mxdev);
> + return err;
> + }
> +
> + err = mxu1_download_firmware(serial, fw_p);
> + if (err) {
> + release_firmware(fw_p);
> + kfree(mxdev);
> + return err;
> + }
> +
> + status = -ENODEV;
> + release_firmware(fw_p);

And you're leaking the interface private data here as well (also fixed).

What you could consider doing as a follow up it so move both the
interrupt-in urb test in port_probe and the firmware download to a new
probe callback. That way you avoid the unnecessary memory allocations
done by core before attach is called, and you can verify and refuse to
bind to a device in case the expected endpoints are missing.

> + }
> +
> + return status;
> +}

> + if (C_BAUD(tty) == 

Re: [PATCH v2 1/4] x86/signal/64: Add a comment about sigcontext->fs and gs

[Stas Sergeev]

08.12.2015 02:23, Andy Lutomirski пишет:
> On Oct 31, 2015 8:25 AM, "Stas Sergeev"  wrote:
>>
>> 26.10.2015 04:25, Andy Lutomirski пишет:
>>
>>> These fields have a strange history.  This tries to document it.
>>>
>>> This borrows from 9a036b93a344 ("x86/signal/64: Remove 'fs' and 'gs'
>>> from sigcontext"), which was reverted by ed596cde9425 ("Revert x86
>>> sigcontext cleanups").
>>>
>>> Signed-off-by: Andy Lutomirski 
>>
>> Now the strategy about SS is to always save it to the sigcontext.
>> This is good because the syscall can clobber it, so the app had
>> to be very careful in the past trying to save it by hands.
>> How about saving also fs and gs? (without restoring yet)
>> If you do, you'll save dosemu a headache of doing any "pre-syscall"
>> work. Pre-syscall work is very nasty.
>> I haven't checked if the syscall clobber also these or only SS,
>> but perhaps saving them by the kernel won't hurt?
> 
> There's a bunch of ongoing work about FS and GS.  I want to wait and see.
Andy, have you postponed only this, or also the sigreturn patch?
Long time no news...
sigreturn patch would really be nice to have.
--
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] [media] uvcvideo: Fix build if !MEDIA_CONTROLLER

[Javier Martinez Canillas]

Hello Thierry,

On 12/29/2015 07:30 AM, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Accesses to the UVC device's mdev field need to be protected by a
> preprocessor conditional to avoid build errors, since the field is only
> included if the MEDIA_CONTROLLER option is selected.
> 
> Fixes: 1590ad7b5271 ("[media] media-device: split media initialization and 
> registration")
> Cc: Javier Martinez Canillas 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Thierry Reding 
> ---

Thanks for the patch but I've already posted the same fix a couple of
days ago [0]. Since the offending commit still has not landed in
mainline, Mauro squashed the fixes with the original commit and will
refresh his next branch soon.

[0]: https://lkml.org/lkml/2015/12/21/224

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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] Fixes for dell-wmi

[Michał Kępień]

> > > This patch series adds check if Dell WMI descriptor structure is
> > > valid and fixes processing WMI events on devices with WMI
> > > interface version 0.
> > > 
> > > After testing, second patch is good candidate for backporting into
> > > stable kernels, but problem is that it cannot be used without
> > > first patch. So I let decision to other people.
> > > 
> > > Gabriele and Michał, this patch series should fix processing events
> > > on yours Dell laptops (you have in DSDT defined version 0). Can
> > > you test it?
> > 
> > My Vostro V131 (and any other as well, judging from the DSDT dumps I
> > found scattered around the web) has the WMI Interface Version field
> > set to 1, as the first one of your patches correctly asserts.
> 
> Ok, great. Can you post DEBUG output when receiving events before and 
> after patch (to check that processing is correct)? 

After applying your patches on my Vostro V131, the WMI events reported
are exactly the same as they were when I originally posted them [1].

[1] http://www.spinics.net/lists/platform-driver-x86/msg07191.html

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

[PATCH] mm/vmstat: fix overflow in mod_zone_page_state()

[Heiko Carstens]

mod_zone_page_state() takes a "delta" integer argument. delta contains
the number of pages that should be added or subtracted from a struct
zone's vm_stat field.

If a zone is larger than 8TB this will cause overflows. E.g. for a
zone with a size slightly larger than 8TB the line

mod_zone_page_state(zone, NR_ALLOC_BATCH, zone->managed_pages);

in mm/page_alloc.c:free_area_init_core() will result in a negative
result for the NR_ALLOC_BATCH entry within the zone's vm_stat, since
8TB contain 0x8xxx pages which will be sign extended to a negative
value.

Fix this by changing the delta argument to long type.

This could fix an early boot problem seen on s390, where we have a 9TB
system with only one node. ZONE_DMA contains 2GB and ZONE_NORMAL the
rest. The system is trying to allocate a GFP_DMA page but ZONE_DMA is
completely empty, so it tries to reclaim pages in an endless loop.

This was seen on a heavily patched 3.10 kernel. One possible
explaination seem to be the overflows caused by mod_zone_page_state().
Unfortunately I did not have the chance to verify that this patch
actually fixes the problem, since I don't have access to the system
right now. However the overflow problem does exist anyway.

Given the description that a system with slightly less than 8TB does
work, this seems to be a candidate for the observed problem.

Signed-off-by: Heiko Carstens 
---
 include/linux/vmstat.h |  6 +++---
 mm/vmstat.c| 10 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 5dbc8b0ee567..3e5d9075960f 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -176,11 +176,11 @@ extern void zone_statistics(struct zone *, struct zone *, 
gfp_t gfp);
 #define sub_zone_page_state(__z, __i, __d) mod_zone_page_state(__z, __i, 
-(__d))
 
 #ifdef CONFIG_SMP
-void __mod_zone_page_state(struct zone *, enum zone_stat_item item, int);
+void __mod_zone_page_state(struct zone *, enum zone_stat_item item, long);
 void __inc_zone_page_state(struct page *, enum zone_stat_item);
 void __dec_zone_page_state(struct page *, enum zone_stat_item);
 
-void mod_zone_page_state(struct zone *, enum zone_stat_item, int);
+void mod_zone_page_state(struct zone *, enum zone_stat_item, long);
 void inc_zone_page_state(struct page *, enum zone_stat_item);
 void dec_zone_page_state(struct page *, enum zone_stat_item);
 
@@ -205,7 +205,7 @@ void set_pgdat_percpu_threshold(pg_data_t *pgdat,
  * The functions directly modify the zone and global counters.
  */
 static inline void __mod_zone_page_state(struct zone *zone,
-   enum zone_stat_item item, int delta)
+   enum zone_stat_item item, long delta)
 {
zone_page_state_add(delta, zone, item);
 }
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 0d5712b0206c..4ebc17d948cb 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -219,7 +219,7 @@ void set_pgdat_percpu_threshold(pg_data_t *pgdat,
  * particular counter cannot be updated from interrupt context.
  */
 void __mod_zone_page_state(struct zone *zone, enum zone_stat_item item,
-   int delta)
+  long delta)
 {
struct per_cpu_pageset __percpu *pcp = zone->pageset;
s8 __percpu *p = pcp->vm_stat_diff + item;
@@ -318,8 +318,8 @@ EXPORT_SYMBOL(__dec_zone_page_state);
  * 1   Overstepping half of threshold
  * -1  Overstepping minus half of threshold
 */
-static inline void mod_state(struct zone *zone,
-   enum zone_stat_item item, int delta, int overstep_mode)
+static inline void mod_state(struct zone *zone, enum zone_stat_item item,
+long delta, int overstep_mode)
 {
struct per_cpu_pageset __percpu *pcp = zone->pageset;
s8 __percpu *p = pcp->vm_stat_diff + item;
@@ -357,7 +357,7 @@ static inline void mod_state(struct zone *zone,
 }
 
 void mod_zone_page_state(struct zone *zone, enum zone_stat_item item,
-   int delta)
+long delta)
 {
mod_state(zone, item, delta, 0);
 }
@@ -384,7 +384,7 @@ EXPORT_SYMBOL(dec_zone_page_state);
  * Use interrupt disable to serialize counter updates
  */
 void mod_zone_page_state(struct zone *zone, enum zone_stat_item item,
-   int delta)
+long delta)
 {
unsigned long flags;
 
-- 
2.3.9

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

[SUSPECTED SPAM] hi Tux

[wsonguci]

hey Tux


http://pinewoodaccounting.ca/freedom.php?silver=k1e13tzhma16pt



Yours Truly

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

[tip:timers/core] clocksource/drivers/acpi_pm: Convert to pr_* macros

[tip-bot for Andy Shevchenko]

Commit-ID:  01414888eaf725a677171605cb051b1c6311e6ab
Gitweb: http://git.kernel.org/tip/01414888eaf725a677171605cb051b1c6311e6ab
Author: Andy Shevchenko 
AuthorDate: Mon, 28 Dec 2015 15:41:25 +0200
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 12:52:57 +0100

clocksource/drivers/acpi_pm: Convert to pr_* macros

Like it's already done in one place in the driver, convert the rest to use pr_*
macros instead of printk(KERN_LEVEL) calls.

While here, join strings to be one string for one line to make grep on them
easier.

There is no functional change.

Signed-off-by: Andy Shevchenko 
Cc: Daniel Lezcano 
Link: 
http://lkml.kernel.org/r/1451310085-113182-1-git-send-email-andriy.shevche...@linux.intel.com
Signed-off-by: Thomas Gleixner 
---
 drivers/clocksource/acpi_pm.c | 27 ++-
 1 file changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index 6eab889..28037d0 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -109,10 +109,8 @@ static void acpi_pm_check_blacklist(struct pci_dev *dev)
 
/* the bug has been fixed in PIIX4M */
if (dev->revision < 3) {
-   printk(KERN_WARNING "* Found PM-Timer Bug on the chipset."
-  " Due to workarounds for a bug,\n"
-  "* this clock source is slow. Consider trying"
-  " other clock sources\n");
+   pr_warn("* Found PM-Timer Bug on the chipset. Due to 
workarounds for a bug,\n"
+   "* this clock source is slow. Consider trying other 
clock sources\n");
 
acpi_pm_need_workaround();
}
@@ -125,12 +123,9 @@ static void acpi_pm_check_graylist(struct pci_dev *dev)
if (acpi_pm_good)
return;
 
-   printk(KERN_WARNING "* The chipset may have PM-Timer Bug. Due to"
-  " workarounds for a bug,\n"
-  "* this clock source is slow. If you are sure your timer"
-  " does not have\n"
-  "* this bug, please use \"acpi_pm_good\" to disable the"
-  " workaround\n");
+   pr_warn("* The chipset may have PM-Timer Bug. Due to workarounds for a 
bug,\n"
+   "* this clock source is slow. If you are sure your timer does 
not have\n"
+   "* this bug, please use \"acpi_pm_good\" to disable the 
workaround\n");
 
acpi_pm_need_workaround();
 }
@@ -162,8 +157,7 @@ static int verify_pmtmr_rate(void)
/* Check that the PMTMR delta is within 5% of what we expect */
if (delta < (PMTMR_EXPECTED_RATE * 19) / 20 ||
delta > (PMTMR_EXPECTED_RATE * 21) / 20) {
-   printk(KERN_INFO "PM-Timer running at invalid rate: %lu%% "
-   "of normal - aborting.\n",
+   pr_info("PM-Timer running at invalid rate: %lu%% of normal - 
aborting.\n",
100UL * delta / PMTMR_EXPECTED_RATE);
return -1;
}
@@ -199,15 +193,14 @@ static int __init init_acpi_pm_clocksource(void)
break;
if ((value2 < value1) && ((value2) < 0xFFF))
break;
-   printk(KERN_INFO "PM-Timer had inconsistent results:"
-  " %#llx, %#llx - aborting.\n",
-  value1, value2);
+   pr_info("PM-Timer had inconsistent results: %#llx, 
%#llx - aborting.\n",
+   value1, value2);
pmtmr_ioport = 0;
return -EINVAL;
}
if (i == ACPI_PM_READ_CHECKS) {
-   printk(KERN_INFO "PM-Timer failed consistency check "
-  " (%#llx) - aborting.\n", value1);
+   pr_info("PM-Timer failed consistency check  (%#llx) - 
aborting.\n",
+   value1);
pmtmr_ioport = 0;
return -ENODEV;
}
--
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] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option

[Thomas Gleixner]

On Tue, 29 Dec 2015, Yury Norov wrote:

> All new 32-bit architectures should have 64-bit off_t type, but existing
> architectures has 32-bit ones.
> 
> To handle it, new config option is added to arch/Kconfig that defaults
> ARCH_32BIT_OFF_T to be disabled for non-64 bit architectures. All existing
> 32-bit architectures enable it explicitly here.
> 
> New option affects force_o_largefile() behaviour. Namely, if off_t is
> 64-bits long, we have no reason to reject user to open big files.
> 
> Note that even if architectures has only 64-bit off_t in the kernel
> (arc, c6x, h8300, hexagon, metag, nios2, openrisc, tile32 and unicore32),
> a libc may use 32-bit off_t, and therefore want to limit the file size
> to 4GB unless specified differently in the open flags.

For the x86 part: Acked-by: Thomas Gleixner 
--
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] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option

[Yury Norov]

On Tue, Dec 29, 2015 at 12:02:33PM +0100, Arnd Bergmann wrote:
> On Tuesday 29 December 2015 12:26:35 Yury Norov wrote:
> > All new 32-bit architectures should have 64-bit off_t type, but existing
> > architectures has 32-bit ones.
> > 
> > To handle it, new config option is added to arch/Kconfig that defaults
> > ARCH_32BIT_OFF_T to be disabled for non-64 bit architectures. All existing
> > 32-bit architectures enable it explicitly here.
> > 
> > New option affects force_o_largefile() behaviour. Namely, if off_t is
> > 64-bits long, we have no reason to reject user to open big files.
> > 
> > Note that even if architectures has only 64-bit off_t in the kernel
> > (arc, c6x, h8300, hexagon, metag, nios2, openrisc, tile32 and unicore32),
> > a libc may use 32-bit off_t, and therefore want to limit the file size
> > to 4GB unless specified differently in the open flags.
> > 
> > Signed-off-by: Yury Norov 
> > 
> 
> Acked-by: Arnd Bergmann 
> 
> Should we merge the two patches through my asm-generic tree now, or should
> we keep them in the ilp32 series, any preferences?
> 
> I think either way works.
> 
>   Arnd

I'd prefer asm-generic tree because they are not related to ILP32 only.

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

[tip:x86/mm] x86/mm: Drop WARN from multi-BAR check

[tip-bot for Laura Abbott]

Commit-ID:  9abb0ecdee69a2577560cc283368e490da974934
Gitweb: http://git.kernel.org/tip/9abb0ecdee69a2577560cc283368e490da974934
Author: Laura Abbott 
AuthorDate: Mon, 21 Dec 2015 12:01:14 -0800
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 12:34:38 +0100

x86/mm: Drop WARN from multi-BAR check

ioremapping multiple BARs produces a warning with a message "Your kernel is
fine". This message mostly serves to comfort kernel developers. Users do
not read the message, they only see the big scary warning which means
something must be horribly broken with their system. Less dramatically, the
warn also sets the taint flag which makes it difficult to differentiate
problems. If the kernel is actually fine as the warning claims it doesn't
make sense for it to be tainted. Change the WARN_ONCE to a pr_warn with the
caller of the ioremap.

Signed-off-by: Laura Abbott 
Link: 
http://lkml.kernel.org/r/1450728074-31029-1-git-send-email-labb...@fedoraproject.org
Signed-off-by: Thomas Gleixner 
---
 arch/x86/mm/ioremap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index b9c78f3..0d8d53d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -194,8 +194,8 @@ static void __iomem *__ioremap_caller(resource_size_t 
phys_addr,
 * Check if the request spans more than any BAR in the iomem resource
 * tree.
 */
-   WARN_ONCE(iomem_map_sanity_check(unaligned_phys_addr, unaligned_size),
- KERN_INFO "Info: mapping multiple BARs. Your kernel is 
fine.");
+   if (iomem_map_sanity_check(unaligned_phys_addr, unaligned_size))
+   pr_warn("caller %pS mapping multiple BARs\n", caller);
 
return ret_addr;
 err_free_area:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/mm] x86/LDT: Print the real LDT base address

[tip-bot for Jan Beulich]

Commit-ID:  0d430e3fb3f7cdc13c0d22078b820f682821b45a
Gitweb: http://git.kernel.org/tip/0d430e3fb3f7cdc13c0d22078b820f682821b45a
Author: Jan Beulich 
AuthorDate: Tue, 22 Dec 2015 08:42:44 -0700
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 12:34:38 +0100

x86/LDT: Print the real LDT base address

This was meant to print base address and entry count; make it do so
again.

Fixes: 37868fe113ff "x86/ldt: Make modify_ldt synchronous"
Signed-off-by: Jan Beulich 
Acked-by: Andy Lutomirski 
Link: http://lkml.kernel.org/r/56797d840278000c2...@prv-mh.provo.novell.com
Signed-off-by: Thomas Gleixner 
---
 arch/x86/kernel/process_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index e835d26..b9d99e0 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -125,7 +125,7 @@ void release_thread(struct task_struct *dead_task)
if (dead_task->mm->context.ldt) {
pr_warn("WARNING: dead process %s still has LDT? 
<%p/%d>\n",
dead_task->comm,
-   dead_task->mm->context.ldt,
+   dead_task->mm->context.ldt->entries,
dead_task->mm->context.ldt->size);
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] [media] msi2500: Delete an unnecessary check in msi2500_set_usb_adc()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 29 Dec 2015 12:32:41 +0100

This issue was detected by using the Coccinelle software.

Return the value from a call of the msi2500_ctrl_msg() function
without using an extra check for the variable "ret" at the end.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/msi2500/msi2500.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/usb/msi2500/msi2500.c 
b/drivers/media/usb/msi2500/msi2500.c
index c104315..2d33033 100644
--- a/drivers/media/usb/msi2500/msi2500.c
+++ b/drivers/media/usb/msi2500/msi2500.c
@@ -839,8 +839,6 @@ static int msi2500_set_usb_adc(struct msi2500_dev *dev)
goto err;
 
ret = msi2500_ctrl_msg(dev, CMD_WREG, reg3);
-   if (ret)
-   goto err;
 err:
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/

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Paul Kocialkowski]

Hi Milo,

Le mardi 29 décembre 2015 à 09:45 +0900, Milo Kim a écrit :
> Hi Paul,
> 
> On 29/12/15 07:49, Paul Kocialkowski wrote:
> > Hi Milo, thanks for the review,
> >
> > Le lundi 28 décembre 2015 à 09:56 +0900, Milo Kim a écrit :
> >> Hi Paul,
> >>
> >> On 23/12/15 20:56, Mark Brown wrote:
> >>> On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
> >>>
>  +gpio = lp->pdata->enable_gpio;
>  +if (!gpio_is_valid(gpio))
>  +return 0;
>  +
>  +/* Always set enable GPIO high. */
>  +ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, 
>  "LP872X EN");
>  +if (ret) {
>  +dev_err(lp->dev, "gpio request err: %d\n", ret);
>  +return ret;
>  +}
> >>>
> >>> This isn't really adding support for the enable GPIO as the changelog
> >>> suggests, it's requesting but not managing the GPIO.  Since there is
> >>> core support for manging enable GPIOs this seems especially silly,
> >>> please tell the core about the GPIO and then it will work at runtime
> >>> too.
> >>>
> >>
> >> With reference to my previous mail, external GPIOs for LDO3 and BUCK2 in
> >> LP8725 can be specified through regulator_config.ena_gpio. BUCK2 only
> >> can be controlled by external pin when CONFIG pin is grounded.
> >>
> >> Please see the description at page 5 of the datasheet.
> >>
> >>http://www.ti.com/lit/ds/symlink/lp8725.pdf
> >
> > After reading the datasheets thoroughly, it seems to me that for the
> > lp8720, the EN pin is used to enable the regulators output, which is a
> > good fit for the core regulator GPIO framework, as there is no reason to
> > keep it on when no regulator is in use. The serial interface is already
> > available when EN=0 and regulators can be configured in that state. The
> > lp8725 seems seems to behave the same when CONFIG=0 (the datasheet
> > clearly states: "CONFIG=0: EN=1 turns on outputs or standby mode if
> > EN=0"). On the other hand, it is indeed used as a power-on pin when
> > CONFIG=1.
> 
> I think it's different use case. LP8720/5 are designed for system PMU, 
> so some regulators are enabled by default after the device is on. EN pin 
> is used for turning on/off the chip. This pin does not control regulator 
> outputs directly. It's separate functional block in the silicon.

Well, I really don't understand why the EN pin would turn on/off the
chip. All it does it enable the regulators outputs (by entering IDLE
mode), the serial block is already available in STANDBY state.

If we want some regulators enabled at boot, the best thing to do seems
to be to request the GPIO with the GPIOF_INIT_HIGH flag, as done in e.g.
the max8952 regulator driver:

if (pdata->reg_data->constraints.boot_on)
config.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;

> On the other hand, 'ena_gpio' is used for each regulator control itself.
> For example, WM8994 has two LDOs which are controlled by external pins. 
> LDOs are enabled/disabled through LDO1ENA and LDO2ENA pins. In this 
> case, 'ena_gpio' is used.

Of course, but the ena_gpio feature is also a good fit for a global
enable pin, as the GPIO can be shared by multiple regulators of the same
chip, which is what we have here.

In my opinion, using the ena_gpio feature is a good fit, as we don't
need to keep the EN pin high when no regulator is used.

>   http://www.cirrus.com/en/pubs/proDatasheet/WM8994_v4.4.pdf
>   (please refer to page 224 and 225)

Cheers,

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/



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

Re: [f2fs-dev] [PATCH 1/2] f2fs: use atomic variable for total_extent_tree

[He YunLei]

On 2015/12/22 11:38, Jaegeuk Kim wrote:

It would be better to use atomic variable for total_extent_tree.

Signed-off-by: Jaegeuk Kim 
---
  fs/f2fs/debug.c| 5 +++--
  fs/f2fs/extent_cache.c | 8 
  fs/f2fs/f2fs.h | 2 +-
  fs/f2fs/node.c | 3 ++-
  fs/f2fs/shrinker.c | 3 ++-
  5 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index bb307e6..ed5dfcc 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -38,7 +38,7 @@ static void update_general_status(struct f2fs_sb_info *sbi)
si->hit_rbtree = atomic64_read(>read_hit_rbtree);
si->hit_total = si->hit_largest + si->hit_cached + si->hit_rbtree;
si->total_ext = atomic64_read(>total_hit_ext);
-   si->ext_tree = sbi->total_ext_tree;
+   si->ext_tree = atomic_read(>total_ext_tree);
si->ext_node = atomic_read(>total_ext_node);
si->ndirty_node = get_pages(sbi, F2FS_DIRTY_NODES);
si->ndirty_dent = get_pages(sbi, F2FS_DIRTY_DENTS);
@@ -193,7 +193,8 @@ get_cache:
si->cache_mem += si->inmem_pages * sizeof(struct inmem_pages);
for (i = 0; i <= UPDATE_INO; i++)
si->cache_mem += sbi->im[i].ino_num * sizeof(struct ino_entry);
-   si->cache_mem += sbi->total_ext_tree * sizeof(struct extent_tree);
+   si->cache_mem += atomic_read(>total_ext_tree) *
+   sizeof(struct extent_tree);
si->cache_mem += atomic_read(>total_ext_node) *
sizeof(struct extent_node);

diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
index e86e9f1e..0e97d6af 100644
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -70,7 +70,7 @@ static struct extent_tree *__grab_extent_tree(struct inode 
*inode)
rwlock_init(>lock);
atomic_set(>refcount, 0);
et->count = 0;
-   sbi->total_ext_tree++;
+   atomic_inc(>total_ext_tree);
}
atomic_inc(>refcount);
up_write(>extent_tree_lock);
@@ -570,7 +570,7 @@ unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info 
*sbi, int nr_shrink)

radix_tree_delete(root, et->ino);
kmem_cache_free(extent_tree_slab, et);
-   sbi->total_ext_tree--;
+   atomic_dec(>total_ext_tree);
tree_cnt++;

if (node_cnt + tree_cnt >= nr_shrink)
@@ -663,7 +663,7 @@ void f2fs_destroy_extent_tree(struct inode *inode)
f2fs_bug_on(sbi, atomic_read(>refcount) || et->count);
radix_tree_delete(>extent_tree_root, inode->i_ino);
kmem_cache_free(extent_tree_slab, et);
-   sbi->total_ext_tree--;
+   atomic_dec(>total_ext_tree);
up_write(>extent_tree_lock);

F2FS_I(inode)->extent_tree = NULL;
@@ -715,7 +715,7 @@ void init_extent_cache_info(struct f2fs_sb_info *sbi)
init_rwsem(>extent_tree_lock);
INIT_LIST_HEAD(>extent_list);
spin_lock_init(>extent_lock);
-   sbi->total_ext_tree = 0;
+   atomic_set(>total_ext_tree, 0);

Hi,
here we'd better to init total_zombie_tree:
atomic_set(>total_zombie_tree, 0);
Thanks,

atomic_set(>total_ext_node, 0);
  }

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 19beabe..a7f6191 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -762,7 +762,7 @@ struct f2fs_sb_info {
struct rw_semaphore extent_tree_lock;   /* locking extent radix tree */
struct list_head extent_list;   /* lru list for shrinker */
spinlock_t extent_lock; /* locking extent lru list */
-   int total_ext_tree; /* extent tree count */
+   atomic_t total_ext_tree;/* extent tree count */
atomic_t total_ext_node;/* extent info count */

/* basic filesystem units */
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index d842b19..6cc8ac7 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -65,7 +65,8 @@ bool available_free_memory(struct f2fs_sb_info *sbi, int type)
sizeof(struct ino_entry)) >> PAGE_CACHE_SHIFT;
res = mem_size < ((avail_ram * nm_i->ram_thresh / 100) >> 1);
} else if (type == EXTENT_CACHE) {
-   mem_size = (sbi->total_ext_tree * sizeof(struct extent_tree) +
+   mem_size = (atomic_read(>total_ext_tree) *
+   sizeof(struct extent_tree) +
atomic_read(>total_ext_node) *
sizeof(struct extent_node)) >> PAGE_CACHE_SHIFT;
res = mem_size < ((avail_ram * nm_i->ram_thresh / 100) >> 1);
diff --git a/fs/f2fs/shrinker.c b/fs/f2fs/shrinker.c
index da0d8e0..a11e099 100644
--- a/fs/f2fs/shrinker.c
+++ b/fs/f2fs/shrinker.c
@@ -32,7 +32,8 @@ static 

[PATCH v3 1/3] device property: add spaces to PROPERTY_ENTRY_STRING macro

[Andy Shevchenko]

Just a style fix, no functional changes.

To be folded to Andrew's patch [1].

[1] http://comments.gmane.org/gmane.linux.kernel.commits.mm/97592

Or in linux next:

e39ece7 include-linux-propertyh-fix-build-issues-with-gcc-444-fix
40bb8a1 include/linux/property.h: fix build issues with gcc-4.4.4

Signed-off-by: Andy Shevchenko 
---
 include/linux/property.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/property.h b/include/linux/property.h
index b8c4e42..b51fcd3 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -230,7 +230,7 @@ struct property_entry {
.name = _name_, \
.length = sizeof(_val_),\
.is_string = true,  \
-   { .value = {.str = _val_} },\
+   { .value = { .str = _val_ } },  \
 }
 
 #define PROPERTY_ENTRY_BOOL(_name_)\
-- 
2.6.4

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

Re: [PATCH v6] serial: rewrite pxa2xx-uart to use 8250_core

[Heikki Krogerus]

On Thu, Dec 24, 2015 at 06:15:14PM +0300, Sergei Ianovich wrote:
> pxa2xx-uart was a separate uart platform driver. It was declaring
> the same device names and numbers as 8250 driver. As a result,
> it was impossible to use 8250 driver on PXA SoCs.
> 
> Upon closer examination pxa2xx-uart turned out to be a clone of
> 8250_core driver.
> 
> Workaround for Erratum #19 according to Marvel(R) PXA270M Processor
> Specification Update (April 19, 2010) is dropped. 8250_core reads
> from FIFO immediately after checking DR bit in LSR.
> 
> The patch leaves the original SERIAL_PXA driver around. The original
> driver is just marked DEPRECATED in Kconfig and C source. When
> the original driver is considered safe to remove, no changes
> to SERIAL_8250 will be necessary.
> 
> Compiling SERIAL_8250_CONSOLE and SERIAL_PXA_CONSOLE even without
> SERIAL_8250_PXA breaks console for SERIAL_PXA. For this reasons, the new
> and the original drivers are made mutually exclusive.
> 
> Signed-off-by: Sergei Ianovich 
> CC: Heikki Krogerus 

Reviewed-by: Heikki Krogerus 

Thanks,

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

[PATCH v3 3/3] device property: avoid allocations of 0 length

[Andy Shevchenko]

Arrays can not have zero elements by definition of the unified device
properties. If such property comes from outside we should not allow it to pass.
Otherwise memory allocation on 0 length will return non-NULL value, which we
currently don't check.

Prevent memory allocations of 0 length.

Signed-off-by: Andy Shevchenko 
---
 drivers/base/property.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index b3429cc..c359351 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -653,6 +653,9 @@ int fwnode_property_match_string(struct fwnode_handle 
*fwnode,
if (nval < 0)
return nval;
 
+   if (nval == 0)
+   return -ENODATA;
+
values = kcalloc(nval, sizeof(*values), GFP_KERNEL);
if (!values)
return -ENOMEM;
@@ -718,6 +721,9 @@ static int pset_copy_entry(struct property_entry *dst,
return -ENOMEM;
 
if (src->is_array) {
+   if (!src->length)
+   return -ENODATA;
+
if (src->is_string) {
nval = src->length / sizeof(const char *);
dst->pointer.str = kcalloc(nval, sizeof(const char *),
-- 
2.6.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 v3 0/3] device property: post merge fixes

[Andy Shevchenko]

Three fixes to device property API.

Patch 1 is a simple style fix to be folded into previous Andrew's patch to
allow old gcc to build (see commit message for the details).

There is a crash in linux-next
 BUG: unable to handle kernel NULL pointer dereference at 0008
 IP: [] fwnode_property_present+0x16/0x30

Check for fwnode pointer before dereference (patch 2).

Patch 3 prevents to allocate buffers with 0 length (the result maybe surprising
to someone).

Changelog v3:
- fix typo in Heikki's patch (patch 2)
- update commit message for patch 1 to explain what is the fixup for

Changelog v2:
- added patches 2 and 3

Andy Shevchenko (2):
  device property: add spaces to PROPERTY_ENTRY_STRING macro
  device property: avoid allocations of 0 length

Heikki Krogerus (1):
  device property: the secondary fwnode needs to depend on the primary

 drivers/base/property.c  | 14 ++
 include/linux/property.h |  2 +-
 2 files changed, 11 insertions(+), 5 deletions(-)

-- 
2.6.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 v3 2/3] device property: the secondary fwnode needs to depend on the primary

[Andy Shevchenko]

From: Heikki Krogerus 

This fixes NULL pointer dereference when the primary fwnode handle
does not exist, for example with PCI devices that do not have ACPI
companion.

Signed-off-by: Heikki Krogerus 
Signed-off-by: Andy Shevchenko 
---
 drivers/base/property.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 0b22c8a..b3429cc 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -218,7 +218,7 @@ bool fwnode_property_present(struct fwnode_handle *fwnode, 
const char *propname)
bool ret;
 
ret = __fwnode_property_present(fwnode, propname);
-   if (ret == false && fwnode->secondary)
+   if (ret == false && fwnode && fwnode->secondary)
ret = __fwnode_property_present(fwnode->secondary, propname);
return ret;
 }
@@ -423,7 +423,7 @@ EXPORT_SYMBOL_GPL(device_property_match_string);
int _ret_;  
\
_ret_ = FWNODE_PROP_READ(_fwnode_, _propname_, _type_, _proptype_,  
\
 _val_, _nval_);
\
-   if (_ret_ == -EINVAL && _fwnode_->secondary)
\
+   if (_ret_ == -EINVAL && _fwnode_ && _fwnode_->secondary)
\
_ret_ = FWNODE_PROP_READ(_fwnode_->secondary, _propname_, 
_type_,   \
_proptype_, _val_, _nval_); 
\
_ret_;  
\
@@ -593,7 +593,7 @@ int fwnode_property_read_string_array(struct fwnode_handle 
*fwnode,
int ret;
 
ret = __fwnode_property_read_string_array(fwnode, propname, val, nval);
-   if (ret == -EINVAL && fwnode->secondary)
+   if (ret == -EINVAL && fwnode && fwnode->secondary)
ret = __fwnode_property_read_string_array(fwnode->secondary,
  propname, val, nval);
return ret;
@@ -621,7 +621,7 @@ int fwnode_property_read_string(struct fwnode_handle 
*fwnode,
int ret;
 
ret = __fwnode_property_read_string(fwnode, propname, val);
-   if (ret == -EINVAL && fwnode->secondary)
+   if (ret == -EINVAL && fwnode && fwnode->secondary)
ret = __fwnode_property_read_string(fwnode->secondary,
propname, val);
return ret;
-- 
2.6.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/

[tip:irq/core] irqchip/ts4800: Add TS-4800 interrupt controller

[tip-bot for Damien Riegel]

Commit-ID:  d01f8633d52e4dac5ee598b87d49fd23346ccfd6
Gitweb: http://git.kernel.org/tip/d01f8633d52e4dac5ee598b87d49fd23346ccfd6
Author: Damien Riegel 
AuthorDate: Mon, 21 Dec 2015 15:11:23 -0500
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:58:53 +0100

irqchip/ts4800: Add TS-4800 interrupt controller

This commit adds support for the TS-4800 interrupt controller. This
controller is instantiated in a companion FPGA, and multiplex interrupts
for other FPGA IPs.

As this component is external to the SoC, the SoC might need to reserve
pins, so this controller is implemented as a platform driver and doesn't
use the IRQCHIP_DECLARE construct.

Signed-off-by: Damien Riegel 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: ker...@savoirfairelinux.com
Link: 
http://lkml.kernel.org/r/1450728683-31416-2-git-send-email-damien.rie...@savoirfairelinux.com
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/Kconfig  |   6 ++
 drivers/irqchip/Makefile |   1 +
 drivers/irqchip/irq-ts4800.c | 163 +++
 3 files changed, 170 insertions(+)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b5f5133..11fc2a2 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -151,6 +151,12 @@ config TB10X_IRQC
select IRQ_DOMAIN
select GENERIC_IRQ_CHIP
 
+config TS4800_IRQ
+   tristate "TS-4800 IRQ controller"
+   select IRQ_DOMAIN
+   help
+ Support for the TS-4800 FPGA IRQ controller
+
 config VERSATILE_FPGA_IRQ
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 83d1fce..d4c2e4e 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_ARCH_NSPIRE) += irq-zevio.o
 obj-$(CONFIG_ARCH_VT8500)  += irq-vt8500.o
 obj-$(CONFIG_ST_IRQCHIP)   += irq-st.o
 obj-$(CONFIG_TB10X_IRQC)   += irq-tb10x.o
+obj-$(CONFIG_TS4800_IRQ)   += irq-ts4800.o
 obj-$(CONFIG_XTENSA)   += irq-xtensa-pic.o
 obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
 obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
diff --git a/drivers/irqchip/irq-ts4800.c b/drivers/irqchip/irq-ts4800.c
new file mode 100644
index 000..4192bdc
--- /dev/null
+++ b/drivers/irqchip/irq-ts4800.c
@@ -0,0 +1,163 @@
+/*
+ * Multiplexed-IRQs driver for TS-4800's FPGA
+ *
+ * Copyright (c) 2015 - Savoir-faire Linux
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IRQ_MASK0x4
+#define IRQ_STATUS  0x8
+
+struct ts4800_irq_data {
+   void __iomem*base;
+   struct irq_domain   *domain;
+   struct irq_chip irq_chip;
+};
+
+static void ts4800_irq_mask(struct irq_data *d)
+{
+   struct ts4800_irq_data *data = irq_data_get_irq_chip_data(d);
+   u16 reg = readw(data->base + IRQ_MASK);
+   u16 mask = 1 << d->hwirq;
+
+   writew(reg | mask, data->base + IRQ_MASK);
+}
+
+static void ts4800_irq_unmask(struct irq_data *d)
+{
+   struct ts4800_irq_data *data = irq_data_get_irq_chip_data(d);
+   u16 reg = readw(data->base + IRQ_MASK);
+   u16 mask = 1 << d->hwirq;
+
+   writew(reg & ~mask, data->base + IRQ_MASK);
+}
+
+static int ts4800_irqdomain_map(struct irq_domain *d, unsigned int irq,
+   irq_hw_number_t hwirq)
+{
+   struct ts4800_irq_data *data = d->host_data;
+
+   irq_set_chip_and_handler(irq, >irq_chip, handle_simple_irq);
+   irq_set_chip_data(irq, data);
+   irq_set_noprobe(irq);
+
+   return 0;
+}
+
+struct irq_domain_ops ts4800_ic_ops = {
+   .map = ts4800_irqdomain_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static void ts4800_ic_chained_handle_irq(struct irq_desc *desc)
+{
+   struct ts4800_irq_data *data = irq_desc_get_handler_data(desc);
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   u16 status = readw(data->base + IRQ_STATUS);
+
+   chained_irq_enter(chip, desc);
+
+   if (unlikely(status == 0)) {
+   handle_bad_irq(desc);
+   goto out;
+   }
+
+   do {
+   unsigned int bit = __ffs(status);
+   int irq = irq_find_mapping(data->domain, bit);
+
+   status &= ~(1 << bit);
+   generic_handle_irq(irq);
+   } while (status);
+
+out:
+   chained_irq_exit(chip, desc);
+}
+
+static int ts4800_ic_probe(struct platform_device *pdev)
+{
+   struct device_node *node = pdev->dev.of_node;
+   struct ts4800_irq_data *data;
+   struct irq_chip *irq_chip;
+  

[tip:irq/core] irqchip/ts4800: Add documentation for TS-4800 interrupt controller

[tip-bot for Damien Riegel]

Commit-ID:  0f6d785c847eeff55ae19546f5885156394be569
Gitweb: http://git.kernel.org/tip/0f6d785c847eeff55ae19546f5885156394be569
Author: Damien Riegel 
AuthorDate: Mon, 21 Dec 2015 15:11:22 -0500
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:58:53 +0100

irqchip/ts4800: Add documentation for TS-4800 interrupt controller

This is an interrupt-controller implemented in an FPGA, to multiplex
interrupts generated from other IPs. The FPGA usually uses a GPIO as a
parent interrupt controller to notify that one of the multiplexed
interrupts has triggered.

Signed-off-by: Damien Riegel 
Acked-by: Rob Herring 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: ker...@savoirfairelinux.com
Link: 
http://lkml.kernel.org/r/1450728683-31416-1-git-send-email-damien.rie...@savoirfairelinux.com
Signed-off-by: Thomas Gleixner 
---
 .../bindings/interrupt-controller/technologic,ts4800.txt | 16 
 1 file changed, 16 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt 
b/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt
new file mode 100644
index 000..7f15f1b
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt
@@ -0,0 +1,16 @@
+TS-4800 FPGA interrupt controller
+
+TS-4800 FPGA has an internal interrupt controller. When one of the
+interrupts is triggered, the SoC is notified, usually using a GPIO as
+parent interrupt source.
+
+Required properties:
+- compatible: should be "technologic,ts4800-irqc"
+- interrupt-controller: identifies the node as an interrupt controller
+- reg: physical base address of the controller and length of memory mapped
+  region
+- #interrupt-cells: specifies the number of cells needed to encode an interrupt
+  source, should be 1.
+- interrupt-parent: phandle to the parent interrupt controller this one is
+  cascaded from
+- interrupts: specifies the interrupt line in the interrupt-parent controller
--
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/

[tip:irq/core] irq/platform-MSI: Increase the maximum MSIs the MSI framework can support

[tip-bot for MaJun]

Commit-ID:  aff5e06b0dda7704ff2fa45162cfc4dde316a6f1
Gitweb: http://git.kernel.org/tip/aff5e06b0dda7704ff2fa45162cfc4dde316a6f1
Author: MaJun 
AuthorDate: Tue, 22 Dec 2015 10:47:22 +0800
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:58:53 +0100

irq/platform-MSI: Increase the maximum MSIs the MSI framework can support

The current MSI framework can only support 256 platform MSIs. But on Hisilicon
platform, some network related devices has about 500 wired interrupts.

To support these devices and align with MSI-X increase the maximum to 2048
devices.

Signed-off-by: Ma Jun 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Link: 
http://lkml.kernel.org/r/1450752442-9392-1-git-send-email-majun...@huawei.com
Signed-off-by: Thomas Gleixner 
---
 drivers/base/platform-msi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index a203896..47c4338 100644
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 
-#define DEV_ID_SHIFT   24
+#define DEV_ID_SHIFT   21
 #define MAX_DEV_MSIS   (1 << (32 - DEV_ID_SHIFT))
 
 /*
--
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/

[tip:irq/core] irqchip/omap-intc: Remove duplicate setup for IRQ chip type handler

[tip-bot for Milo Kim]

Commit-ID:  fee48dfcd76b21b9a7117c3014e1345697ff08ec
Gitweb: http://git.kernel.org/tip/fee48dfcd76b21b9a7117c3014e1345697ff08ec
Author: Milo Kim 
AuthorDate: Mon, 21 Dec 2015 17:53:14 +0900
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:58:54 +0100

irqchip/omap-intc: Remove duplicate setup for IRQ chip type handler

Some OMAP interrupt controllers use generic level detection, so
handle_level_irq() is used as the chip type handler.
Allocated IRQ chip type handler doesn't need to set it again because
irq_alloc_domain_generic_chips() has already registered it.

Tested with BeagleBoneBlack Rev C.

Signed-off-by: Milo Kim 
Cc: Tony Lindgren 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: linux-o...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1450687994-12580-1-git-send-email-milo@ti.com
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-omap-intc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 8587d0f..ed25175 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -207,7 +207,6 @@ static int __init omap_alloc_gc_of(struct irq_domain *d, 
void __iomem *base)
ct = gc->chip_types;
 
ct->type = IRQ_TYPE_LEVEL_MASK;
-   ct->handler = handle_level_irq;
 
ct->chip.irq_ack = omap_mask_ack_irq;
ct->chip.irq_mask = irq_gc_mask_disable_reg;
--
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/

[tip:irq/core] irqchip/gicv2m: Miscellaneous fixes for v2m resources and SPI ranges

[tip-bot for Suravee Suthikulpanit]

Commit-ID:  5a1ff480f4ec40ace313c16b0543c7c6af09e227
Gitweb: http://git.kernel.org/tip/5a1ff480f4ec40ace313c16b0543c7c6af09e227
Author: Suravee Suthikulpanit 
AuthorDate: Tue, 22 Dec 2015 16:24:23 -0800
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:58:53 +0100

irqchip/gicv2m: Miscellaneous fixes for v2m resources and SPI ranges

This patch contain fixes for v2m resources and SPI ranges:

  * Fix off-by-one error when set up v2m resource end range in
gicv2m_acpi_init().

  * Fix the off-by-one print error for SPI range.

  * Use %pR to properly print resource range information.

Both ACPI and DT should now print:

  GICv2m: range[mem 0xe118-0xe1180fff], SPI[64:319]

Suggested-by: Bjorn Helgaas 
Signed-off-by: Suravee Suthikulpanit 
Cc: Lorenzo Pieralisi 
Cc: Will Deacon 
Cc: Catalin Marinas 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Link: 
http://lkml.kernel.org/r/1450830263-28914-1-git-send-email-suravee.suthikulpa...@amd.com
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-gic-v2m.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
index e2d2d02..c779f83 100644
--- a/drivers/irqchip/irq-gic-v2m.c
+++ b/drivers/irqchip/irq-gic-v2m.c
@@ -365,9 +365,8 @@ static int __init gicv2m_init_one(struct fwnode_handle 
*fwnode,
 
list_add_tail(>entry, _nodes);
 
-   pr_info("range[%#lx:%#lx], SPI[%d:%d]\n",
-   (unsigned long)res->start, (unsigned long)res->end,
-   v2m->spi_start, (v2m->spi_start + v2m->nr_spis));
+   pr_info("range%pR, SPI[%d:%d]\n", res,
+   v2m->spi_start, (v2m->spi_start + v2m->nr_spis - 1));
return 0;
 
 err_iounmap:
@@ -456,7 +455,8 @@ acpi_parse_madt_msi(struct acpi_subtable_header *header,
return -EINVAL;
 
res.start = m->base_address;
-   res.end = m->base_address + SZ_4K;
+   res.end = m->base_address + SZ_4K - 1;
+   res.flags = IORESOURCE_MEM;
 
if (m->flags & ACPI_MADT_OVERRIDE_SPI_VALUES) {
spi_start = m->spi_base;
--
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] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option

[Arnd Bergmann]

On Tuesday 29 December 2015 12:26:35 Yury Norov wrote:
> All new 32-bit architectures should have 64-bit off_t type, but existing
> architectures has 32-bit ones.
> 
> To handle it, new config option is added to arch/Kconfig that defaults
> ARCH_32BIT_OFF_T to be disabled for non-64 bit architectures. All existing
> 32-bit architectures enable it explicitly here.
> 
> New option affects force_o_largefile() behaviour. Namely, if off_t is
> 64-bits long, we have no reason to reject user to open big files.
> 
> Note that even if architectures has only 64-bit off_t in the kernel
> (arc, c6x, h8300, hexagon, metag, nios2, openrisc, tile32 and unicore32),
> a libc may use 32-bit off_t, and therefore want to limit the file size
> to 4GB unless specified differently in the open flags.
> 
> Signed-off-by: Yury Norov 
> 

Acked-by: Arnd Bergmann 

Should we merge the two patches through my asm-generic tree now, or should
we keep them in the ilp32 series, any preferences?

I think either way works.

Arnd

--
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] kexec: Provide arch_kexec_protect(unprotect)_crashkres()

[Xunlei Pang]

On 12/28/2015 at 08:14 PM, Minfei Huang wrote:
> On 12/28/15 at 02:32pm, Xunlei Pang wrote:
>> On 12/24/2015 at 02:44 PM, Xunlei Pang wrote:
>>> +static void kexec_mark_crashkres(bool protect)
>>> +{
>>> +   unsigned long control;
>>> +
>>> +   kexec_mark_range(crashk_low_res.start, crashk_low_res.end, 
>>> protect);
>>> +
>>> +   /* Don't touch the control code page used in crash_kexec().*/
>>> +   control = 
>>> PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
>>> +   /* Control code page is located in the 2nd page. */
>>> +   control = control + PAGE_SIZE;
 Though it works because the control code is less than 1 page, but use the 
 macro
 of KEXEC_CONTROL_PAGE_SIZE looks better..
>> The 1st page is pagetable, control code page locates at the 2nd page.
>> The following kexec_mark_range() wants to mark ro from crashk_res.start
>> to the 1st page(included), so here we must use PAGE_SIZE.
>>
>>> +   kexec_mark_range(crashk_res.start, control - 1, protect);
>>> +   kexec_mark_range(control + PAGE_SIZE, crashk_res.end, protect);
>> X86 kexec will copy the page while kexecing, could you check if we can 
>> move
>> that copying to earliyer while kexec loading, maybe 
>> machine_kexec_prepare so
>> that we can make a arch-independent implementation.
> For some arch, may use huge tlb directly to do the kernel mapping,
> in such cases, we can't implement this function. So I think it should
> be arch-dependent.
 Ok, that's fine.
>>> At least moving the x86 control-copying code into arch-related
>>> machine_kexec_prepare() should work, and this can omit the
>>> special treatment of the control code page.
>> The "relocate_kernel" routine in "relocate_kernel_64.S" will use it as
>> a temp storage "for jumping back"(as its comment), so we can't mark
>> it readonly.
> kexec will copy the relocate_kernel binary to control_code_page in
> function machine_kexec. This is a major reason to set the region
> control_code_page to control_code_page + PAGE_SIZE with mode read/write.

Yes, I mean after avoiding this copy by  moving the x86 control-copying
code into arch-related machine_kexec_prepare(), we still can't mark it
readonly because of its temp storage role.

Of course we can still do that by setting its kernel pte to rwx and do a
local tlb invalidation when crash_kexec(), but I think we can simply leave
that alone, since its content is meaningless before crash happens where
the code is copied into it. Unless you want to capture the wrong kernel
operations that only write to this reserved page.

Regards,
Xunlei

>
> Thanks
> Minfei
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

--
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] af_unix: Fix splice-bind deadlock

[Hannes Frederic Sowa]

Hello Rainer,

On 27.12.2015 21:13, Rainer Weikusat wrote:

-static int unix_mknod(const char *sun_path, umode_t mode, struct path *res)
+static int unix_mknod(struct dentry *dentry, struct path *path, umode_t mode,
+ struct path *res)
  {
-   struct dentry *dentry;
-   struct path path;
-   int err = 0;
-   /*
-* Get the parent directory, calculate the hash for last
-* component.
-*/
-   dentry = kern_path_create(AT_FDCWD, sun_path, , 0);
-   err = PTR_ERR(dentry);
-   if (IS_ERR(dentry))
-   return err;
+   int err;

-   /*
-* All right, let's create it.
-*/
-   err = security_path_mknod(, dentry, mode, 0);
+   err = security_path_mknod(path, dentry, mode, 0);
if (!err) {
-   err = vfs_mknod(d_inode(path.dentry), dentry, mode, 0);
+   err = vfs_mknod(d_inode(path->dentry), dentry, mode, 0);
if (!err) {
-   res->mnt = mntget(path.mnt);
+   res->mnt = mntget(path->mnt);
res->dentry = dget(dentry);
}
}
-   done_path_create(, dentry);
+


The reordered call to done_path_create will change the locking ordering 
between the i_mutexes and the unix readlock. Can you comment on this? On 
a first sight this looks like a much more dangerous change than the 
original deadlock report. Can't this also conflict with splice code deep 
down in vfs layer?


Thanks,
  Hannes

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

Re: [PATCH v2 2/3] device property: the secondary fwnode needs to depend on the primary

[Andy Shevchenko]

On Tue, 2015-12-29 at 10:40 +0200, Heikki Krogerus wrote:
> Hi Andy,
> 
> Found a bug from my code..
> 
> > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > index 0b22c8a..6c04d18 100644
> > --- a/drivers/base/property.c
> > +++ b/drivers/base/property.c
> > @@ -218,7 +218,7 @@ bool fwnode_property_present(struct
> > fwnode_handle *fwnode, const char *propname)
> >     bool ret;
> >  
> >     ret = __fwnode_property_present(fwnode, propname);
> > -   if (ret == false && fwnode->secondary)
> > +   if (ret == false && fwnode && fwnode->secondary)
> >     ret = __fwnode_property_present(fwnode->secondary, 
> > propname);
> >     return ret;
> >  }
> > @@ -423,7 +423,7 @@
> > EXPORT_SYMBOL_GPL(device_property_match_string);
> >     int _ret_;  
> > \
> >     _ret_ = FWNODE_PROP_READ(_fwnode_, _propname_, _type_,
> > _proptype_, \
> >      _val_, _nval_);
> > \
> > -   if (_ret_ == -EINVAL && _fwnode_->secondary)
> > \
> > +   if (_ret_ == -EINVAL && fwnode && _fwnode_->secondary)  
> > \
> 
> This should be .._fwnode_ && _fwnode_->secondary)

Yeah, we compiled it correctly due to fwnode presents in all
occurrences of this macro.

I will fix and resend a new version.

> 
> >     _ret_ = FWNODE_PROP_READ(_fwnode_->secondary,
> > _propname_, _type_, \
> >     _proptype_, _val_, _nval_); 
> > \
> >     _ret_;  
> > \
> 
> 
> Cheers,
> 

-- 
Andy Shevchenko 
Intel Finland Oy

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

[tip:irq/core] irqchip/bcm2836: Add SMP support for the 2836

[tip-bot for Andrea Merello]

Commit-ID:  41f4988cc287e5f836d3f6620c9f900bc9b560e9
Gitweb: http://git.kernel.org/tip/41f4988cc287e5f836d3f6620c9f900bc9b560e9
Author: Andrea Merello 
AuthorDate: Sat, 26 Dec 2015 13:47:22 -0800
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:40:45 +0100

irqchip/bcm2836: Add SMP support for the 2836

The firmware sets the secondaries spinning waiting for a non-NULL
value to show up in the last IPI mailbox.

The original SMP port from the downstream tree was done by Andrea, and
Eric cleaned it up/rewrote it a few times from there.

Signed-off-by: Andrea Merello 
Signed-off-by: Eric Anholt 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Florian Fainelli 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: linux-rpi-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/1451166444-11044-3-git-send-email-e...@anholt.net
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-bcm2836.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 6ec125e..59ac40c 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -53,14 +53,16 @@
 /* Same status bits as above, but for FIQ. */
 #define LOCAL_FIQ_PENDING0 0x070
 /*
- * Mailbox0 write-to-set bits.  There are 16 mailboxes, 4 per CPU, and
+ * Mailbox write-to-set bits.  There are 16 mailboxes, 4 per CPU, and
  * these bits are organized by mailbox number and then CPU number.  We
  * use mailbox 0 for IPIs.  The mailbox's interrupt is raised while
  * any bit is set.
  */
 #define LOCAL_MAILBOX0_SET00x080
-/* Mailbox0 write-to-clear bits. */
+#define LOCAL_MAILBOX3_SET00x08c
+/* Mailbox write-to-clear bits. */
 #define LOCAL_MAILBOX0_CLR00x0c0
+#define LOCAL_MAILBOX3_CLR00x0cc
 
 #define LOCAL_IRQ_CNTPSIRQ 0
 #define LOCAL_IRQ_CNTPNSIRQ1
@@ -220,6 +222,24 @@ static struct notifier_block 
bcm2836_arm_irqchip_cpu_notifier = {
.notifier_call = bcm2836_arm_irqchip_cpu_notify,
.priority = 100,
 };
+
+int __init bcm2836_smp_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+   unsigned long secondary_startup_phys =
+   (unsigned long)virt_to_phys((void *)secondary_startup);
+
+   dsb();
+   writel(secondary_startup_phys,
+  intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
+
+   return 0;
+}
+
+static const struct smp_operations bcm2836_smp_ops __initconst = {
+   .smp_boot_secondary = bcm2836_smp_boot_secondary,
+};
+
 #endif
 
 static const struct irq_domain_ops bcm2836_arm_irqchip_intc_ops = {
@@ -237,6 +257,7 @@ bcm2836_arm_irqchip_smp_init(void)
register_cpu_notifier(_arm_irqchip_cpu_notifier);
 
set_smp_cross_call(bcm2836_arm_irqchip_send_ipi);
+   smp_set_ops(_smp_ops);
 #endif
 }
 
--
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/

[tip:irq/core] irqchip/bcm2836: Tolerate IRQs while no flag is set in ISR

[tip-bot for Andrea Merello]

Commit-ID:  a51744ddcc62925ec4d3d3d3a8a13bdd2033af59
Gitweb: http://git.kernel.org/tip/a51744ddcc62925ec4d3d3d3a8a13bdd2033af59
Author: Andrea Merello 
AuthorDate: Sat, 26 Dec 2015 13:47:23 -0800
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:40:45 +0100

irqchip/bcm2836: Tolerate IRQs while no flag is set in ISR

On my RPi2 I got a lot of:
unexpected IRQ trap at vector 00

This happens because bcm2836_arm_irqchip_handle_irq() is sometimes
invoked even if the ISR is clear, and this case is not handled.

This patch explicitly handle this case, fixing the kernel complaints
about the bad IRQ lookup.

Signed-off-by: Andrea Merello 
Reviewed-by: Eric Anholt 
Signed-off-by: Eric Anholt 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Florian Fainelli 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: linux-rpi-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/1451166444-11044-4-git-send-email-e...@anholt.net
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-bcm2836.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 59ac40c..bb8f234 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -177,7 +177,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct 
pt_regs *regs)
writel(1 << ipi, mailbox0);
handle_IPI(ipi, regs);
 #endif
-   } else {
+   } else if (stat) {
u32 hwirq = ffs(stat) - 1;
 
handle_IRQ(irq_linear_revmap(intc.domain, hwirq), regs);
--
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/

[tip:irq/core] irqchip/bcm2836: Make code more readable

[tip-bot for Andrea Merello]

Commit-ID:  64103f061573e3d7670ba295b07919fb8fc7594c
Gitweb: http://git.kernel.org/tip/64103f061573e3d7670ba295b07919fb8fc7594c
Author: Andrea Merello 
AuthorDate: Sat, 26 Dec 2015 13:47:24 -0800
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:40:46 +0100

irqchip/bcm2836: Make code more readable

Avoid using hardcoded magics. We have a #define for this number.
No functional changes.

Signed-off-by: Andrea Merello 
Reviewed-by: Eric Anholt 
Signed-off-by: Eric Anholt 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Florian Fainelli 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: linux-rpi-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/1451166444-11044-5-git-send-email-e...@anholt.net
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-bcm2836.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index bb8f234..963065a 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -167,7 +167,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct 
pt_regs *regs)
u32 stat;
 
stat = readl_relaxed(intc.base + LOCAL_IRQ_PENDING0 + 4 * cpu);
-   if (stat & 0x10) {
+   if (stat & BIT(LOCAL_IRQ_MAILBOX0)) {
 #ifdef CONFIG_SMP
void __iomem *mailbox0 = (intc.base +
  LOCAL_MAILBOX0_CLR0 + 16 * cpu);
--
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/

[tip:irq/core] irqchip/bcm2836: Fix initialization of the LOCAL_IRQ_CNT timers

[tip-bot for Eric Anholt]

Commit-ID:  401667bb8a2e0825090c5e6c15b899c1c36a4773
Gitweb: http://git.kernel.org/tip/401667bb8a2e0825090c5e6c15b899c1c36a4773
Author: Eric Anholt 
AuthorDate: Sat, 26 Dec 2015 13:47:21 -0800
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:40:45 +0100

irqchip/bcm2836: Fix initialization of the LOCAL_IRQ_CNT timers

The irqchip's register area includes the the setup for the timer's
scaling factors, and for the platform we want a fixed configuration of
these registers.

Signed-off-by: Eric Anholt 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Florian Fainelli 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: linux-rpi-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/1451166444-11044-2-git-send-email-e...@anholt.net
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-bcm2836.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index f687082..6ec125e 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -21,6 +21,9 @@
 #include 
 #include 
 
+#define LOCAL_CONTROL  0x000
+#define LOCAL_PRESCALER0x008
+
 /*
  * The low 2 bits identify the CPU that the GPU IRQ goes to, and the
  * next 2 bits identify the CPU that the GPU FIQ goes to.
@@ -237,6 +240,27 @@ bcm2836_arm_irqchip_smp_init(void)
 #endif
 }
 
+/*
+ * The LOCAL_IRQ_CNT* timer firings are based off of the external
+ * oscillator with some scaling.  The firmware sets up CNTFRQ to
+ * report 19.2Mhz, but doesn't set up the scaling registers.
+ */
+static void bcm2835_init_local_timer_frequency(void)
+{
+   /*
+* Set the timer to source from the 19.2Mhz crystal clock (bit
+* 8 unset), and only increment by 1 instead of 2 (bit 9
+* unset).
+*/
+   writel(0, intc.base + LOCAL_CONTROL);
+
+   /*
+* Set the timer prescaler to 1:1 (timer freq = input freq *
+* 2**31 / prescaler)
+*/
+   writel(0x8000, intc.base + LOCAL_PRESCALER);
+}
+
 static int __init bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
  struct device_node 
*parent)
 {
@@ -246,6 +270,8 @@ static int __init 
bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
node->full_name);
}
 
+   bcm2835_init_local_timer_frequency();
+
intc.domain = irq_domain_add_linear(node, LAST_IRQ + 1,
_arm_irqchip_intc_ops,
NULL);
--
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/

[tip:x86/cleanups] arch/x86/kernel/ptrace.c: Remove unused arg_offs_table

[tip-bot for cheng...@emindsoft.com.cn]

Commit-ID:  0105c8d8334fc941e0297ca6708fa57854114c0e
Gitweb: http://git.kernel.org/tip/0105c8d8334fc941e0297ca6708fa57854114c0e
Author: cheng...@emindsoft.com.cn 
AuthorDate: Sat, 26 Dec 2015 21:49:58 +0800
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:35:34 +0100

arch/x86/kernel/ptrace.c: Remove unused arg_offs_table

The related warning from gcc 6.0:

  arch/x86/kernel/ptrace.c:127:18: warning: ‘arg_offs_table’ defined but not 
used [-Wunused-const-variable]
   static const int arg_offs_table[] = {
^~

Signed-off-by: Chen Gang 
Link: 
http://lkml.kernel.org/r/1451137798-28701-1-git-send-email-cheng...@emindsoft.com.cn
Signed-off-by: Thomas Gleixner 
---
 arch/x86/kernel/ptrace.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 558f50e..32e9d9c 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -124,21 +124,6 @@ const char *regs_query_register_name(unsigned int offset)
return NULL;
 }
 
-static const int arg_offs_table[] = {
-#ifdef CONFIG_X86_32
-   [0] = offsetof(struct pt_regs, ax),
-   [1] = offsetof(struct pt_regs, dx),
-   [2] = offsetof(struct pt_regs, cx)
-#else /* CONFIG_X86_64 */
-   [0] = offsetof(struct pt_regs, di),
-   [1] = offsetof(struct pt_regs, si),
-   [2] = offsetof(struct pt_regs, dx),
-   [3] = offsetof(struct pt_regs, cx),
-   [4] = offsetof(struct pt_regs, r8),
-   [5] = offsetof(struct pt_regs, r9)
-#endif
-};
-
 /*
  * does not yet catch signals sent when the child dies.
  * in exit.c or in signal.c.
--
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/

[tip:timers/urgent] posix-clock: Fix return code on the poll method's error path

[tip-bot for Richard Cochran]

Commit-ID:  1b9f23727abb92c5e58f139e7d180befcaa06fe0
Gitweb: http://git.kernel.org/tip/1b9f23727abb92c5e58f139e7d180befcaa06fe0
Author: Richard Cochran 
AuthorDate: Tue, 22 Dec 2015 22:19:58 +0100
Committer:  Thomas Gleixner 
CommitDate: Tue, 29 Dec 2015 11:33:06 +0100

posix-clock: Fix return code on the poll method's error path

The posix_clock_poll function is supposed to return a bit mask of
POLLxxx values.  However, in case the hardware has disappeared (due to
hot plugging for example) this code returns -ENODEV in a futile
attempt to throw an error at the file descriptor level.  The kernel's
file_operations interface does not accept such error codes from the
poll method.  Instead, this function aught to return POLLERR.

The value -ENODEV does, in fact, contain the POLLERR bit (and almost
all the other POLLxxx bits as well), but only by chance.  This patch
fixes code to return a proper bit mask.

Credit goes to Markus Elfring for pointing out the suspicious
signed/unsigned mismatch.

Reported-by: Markus Elfring 
igned-off-by: Richard Cochran 
Cc: John Stultz 
Cc: Julia Lawall 
Link: 
http://lkml.kernel.org/r/1450819198-17420-1-git-send-email-richardcoch...@gmail.com
Cc: sta...@vger.kernel.org
Signed-off-by: Thomas Gleixner 
---
 kernel/time/posix-clock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/posix-clock.c b/kernel/time/posix-clock.c
index ce033c7..9cff0ab 100644
--- a/kernel/time/posix-clock.c
+++ b/kernel/time/posix-clock.c
@@ -69,10 +69,10 @@ static ssize_t posix_clock_read(struct file *fp, char 
__user *buf,
 static unsigned int posix_clock_poll(struct file *fp, poll_table *wait)
 {
struct posix_clock *clk = get_posix_clock(fp);
-   int result = 0;
+   unsigned int result = 0;
 
if (!clk)
-   return -ENODEV;
+   return POLLERR;
 
if (clk->ops.poll)
result = clk->ops.poll(clk, fp, wait);
--
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] printk: nmi: Use correct format specifier for size_t

[Thierry Reding]

From: Thierry Reding 

The correct format specifier for arguments of type size_t is %zu. Using
anything else is bound to trigger warnings on either 32-bit or 64-bit
builds.

Fixes: 0dcfca2060ee ("printk-nmi-generic-solution-for-safe-printk-in-nmi-v4")
Cc: Andrew Morton 
Cc: Petr Mladek 
Signed-off-by: Thierry Reding 
---
 kernel/printk/nmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/printk/nmi.c b/kernel/printk/nmi.c
index 92c61e960c4a..cdee2707a1f2 100644
--- a/kernel/printk/nmi.c
+++ b/kernel/printk/nmi.c
@@ -140,7 +140,7 @@ more:
 * @len must only increase.
 */
if (i && i >= len)
-   pr_err("printk_nmi_flush: internal error: i=%d >= len=%lu\n",
+   pr_err("printk_nmi_flush: internal error: i=%d >= len=%zu\n",
   i, len);
 
if (!len)
-- 
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/

[PATCH] [media] uvcvideo: Fix build if !MEDIA_CONTROLLER

[Thierry Reding]

From: Thierry Reding 

Accesses to the UVC device's mdev field need to be protected by a
preprocessor conditional to avoid build errors, since the field is only
included if the MEDIA_CONTROLLER option is selected.

Fixes: 1590ad7b5271 ("[media] media-device: split media initialization and 
registration")
Cc: Javier Martinez Canillas 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Thierry Reding 
---
 drivers/media/usb/uvc/uvc_driver.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 4dfd3eb814e7..fc63f9aae63e 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1937,9 +1937,11 @@ static int uvc_probe(struct usb_interface *intf,
if (uvc_register_chains(dev) < 0)
goto error;
 
+#ifdef CONFIG_MEDIA_CONTROLLER
/* Register the media device node */
if (media_device_register(>mdev) < 0)
goto error;
+#endif
 
/* Save our data pointer in the interface data. */
usb_set_intfdata(intf, dev);
-- 
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: On Lindent shortcomings and massive style fixing

[Julia Lawall]

On Tue, 29 Dec 2015, Andrey Utkin wrote:

> On Tue, Dec 29, 2015 at 9:32 AM, Mauro Carvalho Chehab
>  wrote:
> > IMHO, there are two problems by letting indent breaking long
> > lines:
> >
> > 1) indent would break strings on printks. This is something that we don't
> > want to break strings on multiple lines in the Kernel;
>
> Yeah, GNU indent does its work badly (although I believe it could be
> taught to respect long literals), this makes me want to have a better
> tool for clean "relayouting" C code.
> I believe that'd require at last a proper syntax parser. With such
> tool, it would be straightforward to rewrite source code automatically
> to please any demanding reviewer of code style, except for issues of
> higher level of thought (like naming or nesting limitations).
>
> > 2) It doesn't actually solve the problem of having too complex loops,
> > with is why the 80 columns warning is meant to warn. Worse than that,
> > if a piece of code is inside more than 4 or 5 indentation levels, the
> > resulting code of using indent for 80-cols line break is a total crap.
>
> Then I'd propose to enforce nesting limitation explicitly, because
> Documentation/CodingStyle appreciates low nesting, just doesn't give
> exact numbers.
> It's better this way, because the programmer could pay attention to N
> places of excessive nesting and fix it manually, and then carelessly
> reformat NNN places of "80 chars" issues automatically, comparing to
> reviewing all NNN places, to figure out if there's excessive nesting,
> or not.
> (CCed checkpatch.pl maintainers.)

Personally, I prefer to see only 80 characters per line, as long as it
doesn't require contorting the code in some other way.  So perhaps not
everyone would agree that the issue is only the amount of nesting.

julia

> > That's said, on a quick look at the driver, it seems that the 80-cols
> > violations are mostly (if not all) on the comments, like:
> >
> > int i_poc_lsb = (frame_seqno_in_gop << 1); /* why multiplied by 
> > two? TODO try without multiplication */
> >
> > and
> >
> > #define TW5864_UNDEF_REG_0x0224 0x0224  /* Undeclared in spec (or not yet 
> > added to tw5864-reg.h) but used */
> > #define TW5864_UNDEF_REG_0x4014 0x4014  /* Undeclared in spec (or not yet 
> > added to tw5864-reg.h) but used */
> > #define TW5864_UNDEF_REG_0xA800 0xA800  /* Undeclared in spec (or not yet 
> > added to tw5864-reg.h) but used */
> >
> > Btw, the content of tw5864-reg-undefined.h is weird... Why not just
> > add the stuff there at tw5864-reg.h and remove the comments for all
> > defines there?
>
> tw5864-reg-undefined.h will be edited for sure (maybe dropped), of
> course it won't stay as it is now.
> It was generated by script during reverse-engineering that bastard
> chip from hell.
>
> > Also, Lindent already did some crappy 80-cols like breaks, like:
> >
> > static int pci_i2c_multi_read(struct tw5864_dev *dev, u8 devid, u8 devfn, 
> > u8 *buf,
> >u32 count)
> >
> > (count is misaligned with the open parenthesis)
>
> I just added "static " after indenting.
> Actually, Documentation/CodingStyle says nothing about alignment of
> function declaration tail on open parenthesis.
> Also I'd like to mention that I hate such alignment, because it
> requires intermixing of tabs and spaces. I am not aware if this is K
> thing or not. If it is, then please don't kill me.
>
> Thanks for kind replies, gentlemen.
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [media] hdpvr: Refactoring for hdpvr_read()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 29 Dec 2015 11:02:43 +0100

Let us return directly if the element "status" of the variable "buf"
indicates "BUFSTAT_READY".
A check repetition can be excluded for the variable "ret" at the end then.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/hdpvr/hdpvr-video.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c 
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 7dee22d..ba7f022 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -462,10 +462,8 @@ static ssize_t hdpvr_read(struct file *file, char __user 
*buffer, size_t count,
}
 
if (wait_event_interruptible(dev->wait_data,
- buf->status == BUFSTAT_READY)) {
-   ret = -ERESTARTSYS;
-   goto err;
-   }
+ buf->status == BUFSTAT_READY))
+   return -ERESTARTSYS;
}
 
if (buf->status != BUFSTAT_READY)
-- 
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] lightnvm: fix rrpc_lun_gc

[Wenwei Tao]

This patch fix two issues in rrpc_lun_gc

1. prio_list is protected by rrpc_lun's lock not nvm_lun's, so
acquire rlun's lock instead of lun's before operate on the list.

2. we delete block from prio_list before allocating gcb, but gcb
allocation may fail, we end without putting it back to the list,
this makes the block won't get reclaimed in the future. To solve
this issue, delete block after gcb allocation.

Signed-off-by: Wenwei Tao 
---
 drivers/lightnvm/rrpc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 67b14d4..373dd9c 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -443,7 +443,7 @@ static void rrpc_lun_gc(struct work_struct *work)
if (nr_blocks_need < rrpc->nr_luns)
nr_blocks_need = rrpc->nr_luns;
 
-   spin_lock(>lock);
+   spin_lock(>lock);
while (nr_blocks_need > lun->nr_free_blocks &&
!list_empty(>prio_list)) {
struct rrpc_block *rblock = block_prio_find_max(rlun);
@@ -452,7 +452,6 @@ static void rrpc_lun_gc(struct work_struct *work)
if (!rblock->nr_invalid_pages)
break;
 
-   list_del_init(>prio);
 
BUG_ON(!block_is_full(rrpc, rblock));
 
@@ -462,6 +461,8 @@ static void rrpc_lun_gc(struct work_struct *work)
if (!gcb)
break;
 
+   list_del_init(>prio);
+
gcb->rrpc = rrpc;
gcb->rblk = rblock;
INIT_WORK(>ws_gc, rrpc_block_gc);
@@ -470,7 +471,7 @@ static void rrpc_lun_gc(struct work_struct *work)
 
nr_blocks_need--;
}
-   spin_unlock(>lock);
+   spin_unlock(>lock);
 
/* TODO: Hint that request queue can be started again */
 }
-- 
1.8.3.1

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

[PATCH] perf/kvm: Guest Symbol Resolution for powerpc

[Ravi Bangoria]

'perf kvm {record|report}' is used to record and report the profiled
performance of any workload on a guest. From the host, we can collect
guest kernel statistics which is useful in finding out any contentions
in guest kernel symbols for a certain workload.
This feature is not available on powerpc because 'perf' relies on the
'cycles' event (a PMU event) to profile the guest. However, for powerpc,
this can't be used from the host because the PMUs are controlled by the
guest rather than the host.

Due to this issue, we need a different approach to profile the
workload in the guest. There exists a tracepoint 'kvm_hv:kvm_guest_exit'
in powerpc which is hit whenever any of the threads exit the guest
context. The guest instruction pointer dumped along with this
tracepoint data in the field 'pc', can be used as guest instruction
pointer while postprocessing the trace data to map this IP to symbol
from guest.kallsyms.

However, to have some kind of periodicity, we can't use all the kvm
exits, rather exits which are bound to happen in certain intervals.
HV_DECREMENTER Interrupt forces the threads to exit after an interval
of 10 ms.

This patch makes use of the 'kvm_guest_exit' tracepoint and checks the
exit reason for any kvm exit. If it is HV_DECREMENTER, then the
instruction pointer dumped along with this tracepoint is retrieved and
mapped with the guest kallsyms. So for powerpc, 'perf kvm record' will
record 'kvm_hv:kvm_guest_exit' events instead of cycles.

This patch will enable --guest option for perf kvm {record|report} on
powerpc. Still --host --guest together won't work.

This patch can be considered as a next iteration to RFC patch sent by
Hemant Kumar: https://lkml.org/lkml/2015/6/15/670. Hemant's patch is used
for enabling 'perf kvm report', while I've added code to enable
'perf kvm record' on powerpc.

Before applying patch:
[Note: one needs to run vm with kvm enabled]

$ ./perf kvm --guestkallsyms=guest.kallsyms --guestmodules=guest.modules record 
-a
[ perf record: Captured and wrote 1.530 MB perf.data.guest (28768 samples) ]

$ ./perf script -i perf.data.guest
 qemu-system-ppc  9688 [000] 842566.451558:  1 cycles:ppp:  
c01f2860 .mmap_region ([kernel.kallsyms])
 qemu-system-ppc  9688 [000] 842566.451562:  1 cycles:ppp:  
c00a2d68 .kvmppc_do_h_enter ([kernel.kallsyms])
 qemu-system-ppc  9688 [000] 842566.451564:  7 cycles:ppp:  
c001f26c .vsx_unavailable_tm ([kernel.kallsyms])
 qemu-system-ppc  9688 [000] 842566.451565:138 cycles:ppp:  
c001f26c .vsx_unavailable_tm ([kernel.kallsyms])
 qemu-system-ppc  9688 [000] 842566.451567:   3128 cycles:ppp:  
c00097d8 ._switch ([kernel.kallsyms])
 qemu-system-ppc  9688 [000] 842566.451570:  81568 cycles:ppp:  
c00ea8bc .wake_up_new_task ([kernel.kallsyms])
 swapper 0 [004] 842566.451580:  1 cycles:ppp:  
c01f2d88 .sys_munmap ([kernel.kallsyms])
 swapper 0 [004] 842566.451583:  1 cycles:ppp:  
c001f26c .vsx_unavailable_tm ([kernel.kallsyms])
 swapper 0 [004] 842566.451584: 11 cycles:ppp:  
c001f26c .vsx_unavailable_tm ([kernel.kallsyms])
 swapper 0 [004] 842566.451585:226 cycles:ppp:  
c00097d4 ._switch ([kernel.kallsyms])
 swapper 0 [004] 842566.451586:   5664 cycles:ppp:  
c000990c resume_kernel ([kernel.kallsyms])
 swapper 0 [004] 842566.451591: 147929 cycles:ppp:  
c010a4fc .freeze_set_ops ([kernel.kallsyms])
 swapper 0 [008] 842566.451597:  1 cycles:ppp:  
c01f2d98 .sys_munmap ([kernel.kallsyms])
 swapper 0 [008] 842566.451600:  1 cycles:ppp:  
c00a2ee0 .kvmppc_do_h_enter ([kernel.kallsyms])
 swapper 0 [008] 842566.451602: 11 cycles:ppp:  
c00a2ee0 .kvmppc_do_h_enter ([kernel.kallsyms])
 swapper 0 [008] 842566.451603:224 cycles:ppp:  
c001f274 .vsx_unavailable_tm ([kernel.kallsyms])
 swapper 0 [008] 842566.451604:   5240 cycles:ppp:  
c0009984 fast_exception_return ([kernel.kallsyms])
 swapper 0 [008] 842566.451608: 134752 cycles:ppp:  
c0780af4 .inet_diag_handler_get_info ([kernel.kallsyms])
 swapper 0 [012] 842566.451616:  1 cycles:ppp:  
c01f2828 .mmap_region ([kernel.kallsyms])
 swapper 0 [012] 842566.451619:  1 cycles:ppp:  
c00a2d78 .kvmppc_do_h_enter ([kernel.kallsyms])
 swapper 0 [012] 842566.451620: 11 cycles:ppp:  
c001f26c .vsx_unavailable_tm ([kernel.kallsyms])
 swapper 0 [012] 842566.451621:226 cycles:ppp:  
c00097d4 ._switch ([kernel.kallsyms])
 swapper 0 [012] 842566.451623:   5549 cycles:ppp:  
c000990c resume_kernel ([kernel.kallsyms])

$ ./perf kvm --guestkallsyms=guest.kallsyms 

[PATCH] drivers: power: fix typo in documentation

[Manuel Pégourié-Gonnard]

The documentation for detach() said attach.

Signed-off-by: Manuel Pégourié-Gonnard 
Cc: triv...@kernel.org
---
 drivers/base/power/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
index f32b802b98f4..f48e33385b3e 100644
--- a/drivers/base/power/common.c
+++ b/drivers/base/power/common.c
@@ -112,7 +112,7 @@ EXPORT_SYMBOL_GPL(dev_pm_domain_attach);
 
 /**
  * dev_pm_domain_detach - Detach a device from its PM domain.
- * @dev: Device to attach.
+ * @dev: Device to detach.
  * @power_off: Used to indicate whether we should power off the device.
  *
  * This functions will reverse the actions from dev_pm_domain_attach() and thus
-- 
2.6.4

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

Re: [PATCH 08/13] IB/srpt: chain RDMA READ/WRITE requests

[Bart Van Assche]

On 12/07/2015 09:51 PM, Christoph Hellwig wrote:
> Remove struct rdma_iu and instead allocate the struct ib_rdma_wr array
> early and fill out directly.  This allows us to chain the WRs, and thus
> archive both less lock contention on the HCA workqueue as well as much
> simpler error handling.

Please consider folding the patch below into this patch.

Thanks,

Bart.

[PATCH] IB/srpt: Fix a recently introduced kernel crash

BUG: unable to handle kernel paging request at 00010198
IP: [] __lock_acquire+0xa2/0x560
Call Trace:
 [] lock_acquire+0x62/0x80
 [] _raw_spin_lock_irqsave+0x43/0x60
 [] srpt_rdma_read_done+0x57/0x120 [ib_srpt]
 [] __ib_process_cq+0x43/0xc0 [ib_core]
 [] ib_cq_poll_work+0x25/0x70 [ib_core]
 [] process_one_work+0x1bd/0x460
 [] worker_thread+0x118/0x420
 [] kthread+0xe4/0x100
 [] ret_from_fork+0x3f/0x70

---
 drivers/infiniband/ulp/srpt/ib_srpt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c 
b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 8068aff..3daab39 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -1395,7 +1395,7 @@ static void srpt_rdma_read_done(struct ib_cq *cq, struct 
ib_wc *wc)
 {
struct srpt_rdma_ch *ch = cq->cq_context;
struct srpt_send_ioctx *ioctx =
-   container_of(wc->wr_cqe, struct srpt_send_ioctx, ioctx.cqe);
+   container_of(wc->wr_cqe, struct srpt_send_ioctx, rdma_cqe);
 
WARN_ON(ioctx->n_rdma <= 0);
atomic_add(ioctx->n_rdma, >sq_wr_avail);
@@ -1418,7 +1418,7 @@ static void srpt_rdma_read_done(struct ib_cq *cq, struct 
ib_wc *wc)
 static void srpt_rdma_write_done(struct ib_cq *cq, struct ib_wc *wc)
 {
struct srpt_send_ioctx *ioctx =
-   container_of(wc->wr_cqe, struct srpt_send_ioctx, ioctx.cqe);
+   container_of(wc->wr_cqe, struct srpt_send_ioctx, rdma_cqe);
 
if (unlikely(wc->status != IB_WC_SUCCESS)) {
pr_info("RDMA_WRITE for ioctx 0x%p failed with status %d\n",
-- 
2.1.4


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

Re: [PATCH 03/13] irq_poll: fold irq_poll_sched_prep into irq_poll_sched

[Bart Van Assche]

On 12/07/2015 09:51 PM, Christoph Hellwig wrote:

diff --git a/lib/irq_poll.c b/lib/irq_poll.c
index 88af879..13cb149 100644
--- a/lib/irq_poll.c
+++ b/lib/irq_poll.c
@@ -21,13 +21,17 @@ static DEFINE_PER_CPU(struct list_head, blk_cpu_iopoll);
   *
   * Description:
   * Add this irq_poll structure to the pending poll list and trigger the
- * raise of the blk iopoll softirq. The driver must already have gotten a
- * successful return from irq_poll_sched_prep() before calling this.
+ * raise of the blk iopoll softirq.
   **/
  void irq_poll_sched(struct irq_poll *iop)
  {
unsigned long flags;

+   if (test_bit(IRQ_POLL_F_DISABLE, >state))
+   return;
+   if (!test_and_set_bit(IRQ_POLL_F_SCHED, >state))
+   return;
+
local_irq_save(flags);
list_add_tail(>list, this_cpu_ptr(_cpu_iopoll));
__raise_softirq_irqoff(IRQ_POLL_SOFTIRQ);


After having applied these changes the SRP initiator didn't receive any 
RDMA completions anymore. I could remedy that by changing 
"!test_and_set_bit()" into "test_and_set_bit()":


diff --git a/lib/irq_poll.c b/lib/irq_poll.c
index 43a3370..3a67019 100644
--- a/lib/irq_poll.c
+++ b/lib/irq_poll.c
@@ -29,7 +29,7 @@ void irq_poll_sched(struct irq_poll *iop)

if (test_bit(IRQ_POLL_F_DISABLE, >state))
return;
-   if (!test_and_set_bit(IRQ_POLL_F_SCHED, >state))
+   if (test_and_set_bit(IRQ_POLL_F_SCHED, >state))
return;

local_irq_save(flags);
--
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: completion queue abstraction V2

[Bart Van Assche]

On 12/07/2015 09:51 PM, Christoph Hellwig wrote:

This series adds a new RDMA core abstraction that insulated the
ULPs from the nitty gritty details of CQ polling.  See the individual
patches for more details.


Hello Christoph,

After having tested the SRP initiator and target drivers with this patch 
series applied I have further feedback about this patch series. I will 
provide that feedback as replies to the individual patches.


Bart.
--
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] f2fs: introduce F2FS_MAX_BLOCKS

[Chao Yu]

Introduce a macro named F2FS_MAX_BLOCKS to indicate maximum block index
in f2fs, it could be used to avoid unneeded calculation in runtime.

Signed-off-by: Chao Yu 
---
 fs/f2fs/data.c  |  2 +-
 fs/f2fs/f2fs.h  |  1 -
 fs/f2fs/super.c | 19 ++-
 include/linux/f2fs_fs.h |  5 +
 4 files changed, 8 insertions(+), 19 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7175d33..a366a4c 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -762,7 +762,7 @@ static int get_data_block_bmap(struct inode *inode, 
sector_t iblock,
struct buffer_head *bh_result, int create)
 {
/* Block number less than F2FS MAX BLOCKS */
-   if (unlikely(iblock > max_file_size(0)))
+   if (unlikely(iblock > F2FS_MAX_BLOCKS))
return -EFBIG;
 
return __get_data_block(inode, iblock, bh_result, create,
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 9ba6a09..95c6f38 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1731,7 +1731,6 @@ static inline int f2fs_add_link(struct dentry *dentry, 
struct inode *inode)
  * super.c
  */
 int f2fs_commit_super(struct f2fs_sb_info *, bool);
-loff_t max_file_size(unsigned bits);
 int f2fs_sync_fs(struct super_block *, int);
 extern __printf(3, 4)
 void f2fs_msg(struct super_block *, const char *, const char *, ...);
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index f474355..5f7e632 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -909,24 +909,9 @@ static const struct export_operations f2fs_export_ops = {
.get_parent = f2fs_get_parent,
 };
 
-loff_t max_file_size(unsigned bits)
+static loff_t max_file_size(unsigned bits)
 {
-   loff_t result = (DEF_ADDRS_PER_INODE - F2FS_INLINE_XATTR_ADDRS);
-   loff_t leaf_count = ADDRS_PER_BLOCK;
-
-   /* two direct node blocks */
-   result += (leaf_count * 2);
-
-   /* two indirect node blocks */
-   leaf_count *= NIDS_PER_BLOCK;
-   result += (leaf_count * 2);
-
-   /* one double indirect node block */
-   leaf_count *= NIDS_PER_BLOCK;
-   result += leaf_count;
-
-   result <<= bits;
-   return result;
+   return ((loff_t)F2FS_MAX_BLOCKS << bits);
 }
 
 static inline bool sanity_check_area_boundary(struct super_block *sb,
diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
index e59c3be..814c471 100644
--- a/include/linux/f2fs_fs.h
+++ b/include/linux/f2fs_fs.h
@@ -189,6 +189,11 @@ struct f2fs_extent {
 #define F2FS_DATA_EXIST0x08/* file inline data exist flag 
*/
 #define F2FS_INLINE_DOTS   0x10/* file having implicit dot dentries */
 
+#define F2FS_MAX_BLOCKS((DEF_ADDRS_PER_INODE - 
F2FS_INLINE_XATTR_ADDRS) + \
+   ADDRS_PER_BLOCK * 2 + ADDRS_PER_BLOCK * \
+   NIDS_PER_BLOCK * 2 + ADDRS_PER_BLOCK * \
+   NIDS_PER_BLOCK * NIDS_PER_BLOCK)
+
 #define MAX_INLINE_DATA(sizeof(__le32) * (DEF_ADDRS_PER_INODE 
- \
F2FS_INLINE_XATTR_ADDRS - 1))
 
-- 
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 RFC] mm: Rework virtual memory accounting

[Cyrill Gorcunov]

On Mon, Dec 28, 2015 at 03:10:02PM -0800, Andrew Morton wrote:
> On Tue, 29 Dec 2015 00:10:15 +0300 Cyrill Gorcunov  wrote:
...
> 
> This clashes with
> mm-mmapc-remove-redundant-local-variables-for-may_expand_vm.patch,
> below.  I resolved it thusly:
> 
> bool may_expand_vm(struct mm_struct *mm, vm_flags_t flags, unsigned long 
> npages)
> {
>   if (mm->total_vm + npages > rlimit(RLIMIT_AS) >> PAGE_SHIFT)
>   return false;
> 
>   if ((flags & (VM_WRITE | VM_SHARED | (VM_STACK_FLAGS &
>   (VM_GROWSUP | VM_GROWSDOWN == VM_WRITE)
>   return mm->data_vm + npages <= rlimit(RLIMIT_DATA);
> 
>   return true;
> }

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

Re: [RFC v2 3/3] irq: Privatize irq_common_data::state_use_accessors

[Thomas Gleixner]

On Tue, 29 Dec 2015, Boqun Feng wrote:

> irq_common_data::state_use_accessors is not designed for public use.
> Therefore make it private so that people who write code accessing it
> directly will get blamed by sparse. Also #undef the macro
> __irqd_to_state after used in header files, so that the macro can't be
> misused.
> 
> Signed-off-by: Boqun Feng 

Reviewed-by: Thomas Gleixner 

--
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: timerfd_settime/timerfd_gettime issue ?

[Thomas Gleixner]

Helge,

On Sat, 26 Dec 2015, Helge Deller wrote:

> I see a strange behavior on the parisc platform, for which I'm not sure if
> it's intended or if there is a bug somewhere.

> The program calls timerfd_settime() and sets a timer (e.g. sec=0, 
> nsec=1).
> Directly after setting the timer it calls timerfd_gettime() and receives
> (sec=0, nsec=103914413).
> The second nsec is higher than the initial nsec value which was set.
> 
> Does timerfd_settime() maybe tries to add the initial time it takes to start
> the timer?
>
> Any idea or hint?

Yes. This is a fallout from the power aware batching magic. Interesting that
nobody noticed this within 7 years.

Does the patch below fix your issue?

Thanks,

tglx

8<

diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 76dd4f0da5ca..0f4a3e8734f1 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -268,7 +268,7 @@ static inline s64 hrtimer_get_expires_ns(const struct 
hrtimer *timer)
 
 static inline ktime_t hrtimer_expires_remaining(const struct hrtimer *timer)
 {
-   return ktime_sub(timer->node.expires, timer->base->get_time());
+   return ktime_sub(timer->_softexpires, timer->base->get_time());
 }
 
 static inline ktime_t hrtimer_cb_get_time(struct hrtimer *timer)
--
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 RFC] mm: Rework virtual memory accounting

[Cyrill Gorcunov]

On Mon, Dec 28, 2015 at 02:22:23PM -0800, Linus Torvalds wrote:
> On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov  wrote:
> > Really sorry for delays. Konstantin, I slightly updated the
> > changelog (to point where problem came from). Linus are you
> > fine with accounting not only anonymous memory in VmData?
> 
> The patch looks ok to me. I guess if somebody relies on old behavior
> we may have to tweak it a bit, but on the whole this looks sane and
> I'd be happy to merge it in the 4.5 merge window (and maybe even have
> it marked for stable if it works out)

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

RE: [PATCH 1/2] mmc: enable mmc host device to suspend/resume asynchronously

[Venu Byravarasu]

Looks good to me.

Acked-by: Venu Byravarasu 

BR,
Venu


-Original Message-
From: Fu, Zhonghui [mailto:zhonghui...@linux.intel.com] 
Sent: Monday, December 28, 2015 9:09 PM
To: Ulf Hansson
Cc: Adrian Hunter; chaotian.j...@mediatek.com; l...@metafoo.de; Venu 
Byravarasu; sergei.shtyl...@cogentembedded.com; linux-mmc; 
linux-kernel@vger.kernel.org
Subject: [PATCH 1/2] mmc: enable mmc host device to suspend/resume 
asynchronously

Now, PM core supports asynchronous suspend/resume mode for devices during 
system suspend/resume, and the power state transition of one device may be 
completed in separate kernel thread. PM core ensures all power state transition 
dependency between devices. This patch enables mmc hosts to suspend/resume 
asynchronously. This will take advantage of multicore and improve system 
suspend/resume speed.
After applying this patch and enabling all mmc hosts' child devices to 
suspend/resume asynchronously on ASUS T100TA, the system suspend-to-idle time 
is reduced from 1645ms to 1107ms, and the system resume time is reduced from 
940ms to 914ms.

Signed-off-by: Zhonghui Fu 
---
 drivers/mmc/core/host.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index 
da950c4..7222fd7 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -339,6 +339,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device 
*dev)
host->class_dev.parent = dev;
host->class_dev.class = _host_class;
device_initialize(>class_dev);
+   device_enable_async_suspend(>class_dev);
 
if (mmc_gpio_alloc(host)) {
put_device(>class_dev);
-- 1.7.1

Re: [PATCH] lightnvm: check bi_error in gc

[Matias Bjørling]

On 12/29/2015 06:50 AM, Wenwei Tao wrote:

We should check last io compeltion status before
start another one.

Signed-off-by: Wenwei Tao 
---
  drivers/lightnvm/rrpc.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index c0886a8..d40c140 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -328,6 +328,10 @@ try:
goto finished;
}
wait_for_completion_io();
+   if (bio->bi_error) {
+   rrpc_inflight_laddr_release(rrpc, rqd);
+   goto finished;
+   }

bio_reset(bio);
reinit_completion();
@@ -350,6 +354,8 @@ try:
wait_for_completion_io();

rrpc_inflight_laddr_release(rrpc, rqd);
+   if (bio->bi_error)
+   goto finished;

bio_reset(bio);
}


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

Re: [PATCH] lightnvm: put block back to gc list on its reclaim fail

[Matias Bjørling]

On 12/29/2015 09:27 AM, Wenwei Tao wrote:

We delete a block from the gc list before reclaim it, so
put it back to the list on its reclaim fail, otherwize
this block will not get reclaimed and be programable
in the future.

Signed-off-by: Wenwei Tao 
---
  drivers/lightnvm/rrpc.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index d40c140..67b14d4 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -379,16 +379,26 @@ static void rrpc_block_gc(struct work_struct *work)
struct rrpc *rrpc = gcb->rrpc;
struct rrpc_block *rblk = gcb->rblk;
struct nvm_dev *dev = rrpc->dev;
+   struct nvm_lun *lun = rblk->parent->lun;
+   struct rrpc_lun *rlun = >luns[lun->id - rrpc->lun_offset];

+   mempool_free(gcb, rrpc->gcb_pool);
pr_debug("nvm: block '%lu' being reclaimed\n", rblk->parent->id);

if (rrpc_move_valid_pages(rrpc, rblk))
-   goto done;
+   goto put_back;
+
+   if (nvm_erase_blk(dev, rblk->parent))
+   goto put_back;

-   nvm_erase_blk(dev, rblk->parent);
rrpc_put_blk(rrpc, rblk);
-done:
-   mempool_free(gcb, rrpc->gcb_pool);
+
+   return;
+
+put_back:
+   spin_lock(>lock);
+   list_add_tail(>prio, >prio_list);
+   spin_unlock(>lock);
  }

  /* the block with highest number of invalid pages, will be in the beginning


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

Re: [PATCH v2 00/12] mtd: nand_bbt: introduce independent nand BBT

[Boris Brezillon]

Hi,

On Mon, 28 Dec 2015 17:42:50 -0300
Ezequiel Garcia  wrote:

> This is looking a lot better, thanks for the good work!
> 
> On 15 December 2015 at 02:59, Peter Pan  wrote:
> > Currently nand_bbt.c is tied with struct nand_chip, and it makes other
> > NAND family chips hard to use nand_bbt.c. Maybe it's the reason why
> > onenand has own bbt(onenand_bbt.c).
> >
> > Separate struct nand_chip from BBT code can make current BBT shareable.
> > We create struct nand_bbt to take place of nand_chip in nand_bbt.c.
> > Struct nand_bbt contains all the information BBT needed from outside and
> > it should be embedded into NAND family chip struct (such as struct 
> > nand_chip).
> > NAND family driver should allocate, initialize and free struct nand_bbt.
> >
> > Below is mtd folder structure we want:
> > mtd
> > ├── Kconfig
> > ├── Makefile
> > ├── ...
> > ├── nand_bbt.c
> 
> Hm.. I'm not sure about having nand_bbt.c in drivers/mtd.
> What's wrong with drivers/mtd/nand ?

I haven't reviewed the series yet, but I agree. If the BBT code is only
meant to be used on NAND based devices, it should probably stay in
drivers/mtd/nand.

> 
> In fact, I  was thinking we could go further and clean up the directories a 
> bit
> by separating core code, from controllers code, from SPI NAND code:
> 
> drivers/mtd/nand/
> drivers/mtd/nand/controllers
> drivers/mtd/nand/spi
> 
> Makes any sense?

Actually I had the secret plan of moving all (raw) NAND controller
drivers into the drivers/mtd/nand/controllers directory, though this
was for a different reason: I'd like to create another directory for
manufacturer specific code in order to support some advanced features
on NANDs that do not implement (or only partially implement) the ONFI
standard.

The separation you're talking about here is more related to the
interface used to communicate with the NAND chip.

How about using the following hierarchy?

drivers/mtd/nand/
drivers/mtd/nand/interfaces/raw/
drivers/mtd/nand/interfaces/raw/controllers/
drivers/mtd/nand/interfaces/spi/
drivers/mtd/nand/interfaces/onenand/
drivers/mtd/nand/chips/

What do you think?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RCU stall and the system boot hang with nfsroot

[Aaron Ma]

Add paul...@linux.vnet.ibm.com

On Tue, Dec 29, 2015 at 5:32 PM, Aaron Ma  wrote:
> Hi, Paul:
> I found the linux-stable-4.1.15 with rt15 patches boot hang sometimes.
> Hardware is Grantley-EP and WildcatPass.
> No response by sysrq.
>
> Did you found any issue about this? Or how can I address this issue?
>
> Attached kernel config.
>
> Thanks,
> Pengyu
>
> xhci_hcd :00:14.0: cache line size of 32 is not supported
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 15 ports detected
> xhci_hcd :00:14.0: xHCI Host Controller
> xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 6 ports detected
> initcall xhci_pci_init+0x0/0x44 returned 0 after 306571 usecs
> calling  ehci_hcd_init+0x0/0x5d @ 1
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> initcall ehci_hcd_init+0x0/0x5d returned 0 after 5695 usecs
> calling  ehci_pci_init+0x0/0x69 @ 1
> ehci-pci: EHCI PCI platform driver
> ehci-pci :00:1a.0: enabling bus mastering
> ehci-pci :00:1a.0: EHCI Host Controller
> ehci-pci :00:1a.0: new USB bus registered, assigned bus number 3
> ehci-pci :00:1a.0: debug port 2
> ehci-pci :00:1a.0: cache line size of 32 is not supported
> ehci-pci :00:1a.0: irq 18, io mem 0x91d02000
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
> INFO: rcu_preempt detected stalls on CPUs/tasks:
> 18: (0 ticks this GP) idle=284/0/0 softirq=0/0 fqs=0
> (detected by 12, t=26002 jiffies, g=5351, c=5350, q=451332)
> Task dump for CPU 18:
> swapper/18  R  running task0 0  1 0x0020
>  814946a7 88045fbc7e58 814f42f7 0004
>  0004 8804663e0f60 820dc5c0 88045fbc7ea8
>  8181fca5   0046
> Call Trace:
>  [] ? debug_smp_processor_id+0x17/0x20
>  [] ? intel_idle+0x137/0x140
>  [] ? cpuidle_enter_state+0x65/0x3e0
>  [] ? cpuidle_enter+0x17/0x20
>  [] ? cpu_startup_entry+0x33d/0x630
>  [] ? start_secondary+0x12e/0x140
> rcu_preempt kthread starved for 26002 jiffies!
> INFO: rcu_preempt detected stalls on CPUs/tasks:
> 18: (0 ticks this GP) idle=326/0/0 softirq=0/0 fqs=1
> (detected by 67, t=104007 jiffies, g=5351, c=5350, q=451332)
> Task dump for CPU 18:
> swapper/18  R  running task0 0  1 0x0020
>  814946a7 88045fbc7e58 814f42f7 0004
>  0004 8804663e0f60 820dc5c0 88045fbc7ea8
>  8181fca5   0046
> Call Trace:
>  [] ? debug_smp_processor_id+0x17/0x20
>  [] ? intel_idle+0x137/0x140
>  [] ? cpuidle_enter_state+0x65/0x3e0
>  [] ? cpuidle_enter+0x17/0x20
>  [] ? cpu_startup_entry+0x33d/0x630
>  [] ? start_secondary+0x12e/0x140
> rcu_preempt kthread starved for 78005 jiffies!
> INFO: rcu_preempt detected stalls on CPUs/tasks:
> 18: (0 ticks this GP) idle=35c/0/0 softirq=0/0 fqs=0
> (detected by 62, t=26002 jiffies, g=5352, c=5351, q=451332)
> Task dump for CPU 18:
> swapper/18  R  running task0 0  1 0x0020
>  814946a7 88045fbc7e58 814f42f7 0004
>  0004 8804663e0f60 820dc5c0 88045fbc7ea8
>  8181fca5   0046
> Call Trace:
>  [] ? debug_smp_processor_id+0x17/0x20
>  [] ? intel_idle+0x137/0x140
>  [] ? cpuidle_enter_state+0x65/0x3e0
>  [] ? cpuidle_enter+0x17/0x20
>  [] ? cpu_startup_entry+0x33d/0x630
>  [] ? start_secondary+0x12e/0x140
> rcu_preempt kthread starved for 26002 jiffies!
> perf interrupt took too long (2575 > 2500), lowering
> kernel.perf_event_max_sample_rate to 5
> INFO: task swapper/0:1 blocked for more than 120 seconds.
>   Not tainted 4.1.15-rt13-WR8.0.0.0_preempt-rt+ #25
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> swapper/0   D 880453547a18 0 1  0 0x
>  880453547a18 880851aa8000 d7a0 88045f604ba0
>  880851aa8000 8804535479e8 814946a7 880453547a08
>  880453548000 880851aa8000 880453547a68 8804663ce500
> Call Trace:
>  [] ? debug_smp_processor_id+0x17/0x20
>  [] schedule+0x3f/0xd0
>  [] schedule_timeout+0x189/0x3f0
>  [] ? timer_cpu_notify+0x190/0x190
>  [] msleep+0x42/0x50
>  [] ehci_run+0xf6/0x1d0
>  [] usb_add_hcd+0x2dd/0x810
>  [] usb_hcd_pci_probe+0x33e/0x490
>  [] ehci_pci_probe+0x36/0x40
>  [] local_pci_probe+0x42/0xa0
>  [] ? pci_match_device+0xf2/0x120
>  [] pci_device_probe+0xe9/0x150
>  [] driver_probe_device+0x181/0x310
>  [] 

[PATCH 2/2] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option

[Yury Norov]

All new 32-bit architectures should have 64-bit off_t type, but existing
architectures has 32-bit ones.

To handle it, new config option is added to arch/Kconfig that defaults
ARCH_32BIT_OFF_T to be disabled for non-64 bit architectures. All existing
32-bit architectures enable it explicitly here.

New option affects force_o_largefile() behaviour. Namely, if off_t is
64-bits long, we have no reason to reject user to open big files.

Note that even if architectures has only 64-bit off_t in the kernel
(arc, c6x, h8300, hexagon, metag, nios2, openrisc, tile32 and unicore32),
a libc may use 32-bit off_t, and therefore want to limit the file size
to 4GB unless specified differently in the open flags.

Signed-off-by: Yury Norov 
---
 arch/Kconfig| 4 
 arch/arc/Kconfig| 1 +
 arch/arm/Kconfig| 1 +
 arch/blackfin/Kconfig   | 1 +
 arch/cris/Kconfig   | 1 +
 arch/frv/Kconfig| 1 +
 arch/h8300/Kconfig  | 1 +
 arch/hexagon/Kconfig| 1 +
 arch/m32r/Kconfig   | 1 +
 arch/m68k/Kconfig   | 1 +
 arch/metag/Kconfig  | 1 +
 arch/microblaze/Kconfig | 1 +
 arch/mips/Kconfig   | 1 +
 arch/mn10300/Kconfig| 1 +
 arch/nios2/Kconfig  | 1 +
 arch/openrisc/Kconfig   | 1 +
 arch/parisc/Kconfig | 1 +
 arch/powerpc/Kconfig| 1 +
 arch/score/Kconfig  | 1 +
 arch/sh/Kconfig | 1 +
 arch/sparc/Kconfig  | 1 +
 arch/tile/Kconfig   | 1 +
 arch/unicore32/Kconfig  | 1 +
 arch/x86/Kconfig| 1 +
 arch/x86/um/Kconfig | 1 +
 arch/xtensa/Kconfig | 1 +
 include/linux/fcntl.h   | 2 +-
 27 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 4e949e5..b356bb6 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -233,6 +233,10 @@ config ARCH_THREAD_INFO_ALLOCATOR
 config ARCH_WANTS_DYNAMIC_TASK_STRUCT
bool
 
+config ARCH_32BIT_OFF_T
+   bool
+   depends on !64BIT
+
 config HAVE_REGS_AND_STACK_ACCESS_API
bool
help
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 6312f60..570dc39 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -9,6 +9,7 @@
 config ARC
def_bool y
select ARCH_SUPPORTS_ATOMIC_RMW if ARC_HAS_LLSC
+   select ARCH_32BIT_OFF_T
select BUILDTIME_EXTABLE_SORT
select COMMON_CLK
select CLONE_BACKWARDS
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 34e1569..dafdebe 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,6 +1,7 @@
 config ARM
bool
default y
+   select ARCH_32BIT_OFF_T
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index af76634..9b5fc06 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -12,6 +12,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config BLACKFIN
def_bool y
+   select ARCH_32BIT_OFF_T
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
select HAVE_DYNAMIC_FTRACE
diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig
index e086f9e..5bc9203 100644
--- a/arch/cris/Kconfig
+++ b/arch/cris/Kconfig
@@ -50,6 +50,7 @@ config LOCKDEP_SUPPORT
 config CRIS
bool
default y
+   select ARCH_32BIT_OFF_T
select HAVE_IDE
select GENERIC_ATOMIC64
select HAVE_UID16
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index 34aa193..09b82fc 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -1,6 +1,7 @@
 config FRV
bool
default y
+   select ARCH_32BIT_OFF_T
select HAVE_IDE
select HAVE_ARCH_TRACEHOOK
select HAVE_PERF_EVENTS
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index dd3ac75..7761f4a 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -1,5 +1,6 @@
 config H8300
 def_bool y
+   select ARCH_32BIT_OFF_T
select GENERIC_ATOMIC64
select HAVE_UID16
select VIRT_TO_BUS
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 4dc89d1..29836fc 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -3,6 +3,7 @@ comment "Linux Kernel Configuration for Hexagon"
 
 config HEXAGON
def_bool y
+   select ARCH_32BIT_OFF_T
select HAVE_OPROFILE
# Other pending projects/to-do items.
# select HAVE_REGS_AND_STACK_ACCESS_API
diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
index 9e44bbd..c6865a9 100644
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -1,6 +1,7 @@
 config M32R
bool
default y
+   select ARCH_32BIT_OFF_T
select HAVE_IDE
select HAVE_OPROFILE
select INIT_ALL_POSSIBLE
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 498b567..e9897e4 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -1,6 +1,7 @@
 config M68K
bool
default y
+   select ARCH_32BIT_OFF_T
select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
select 

[PATCH 1/2] compat ABI: use non-compat openat and open_by_handle_at variants

[Yury Norov]

The only difference is that non-compat version forces O_LARGEFILE,
and it should be the default behaviour for all architectures, as
we don't support 32-bit off_t. The only exception is tile32, that
continues with compat version of syscalls.

Signed-off-by: Yury Norov 
Acked-by: Arnd Bergmann 
Acked-by: Chris Metcalf  [for tile]
---
 arch/tile/kernel/compat.c | 3 +++
 include/uapi/asm-generic/unistd.h | 5 ++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/tile/kernel/compat.c b/arch/tile/kernel/compat.c
index 4912084..489ae19 100644
--- a/arch/tile/kernel/compat.c
+++ b/arch/tile/kernel/compat.c
@@ -94,6 +94,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned 
int, offset_high,
 #define compat_sys_readahead sys32_readahead
 #define sys_llseek compat_sys_llseek
 
+#define sys_openat compat_sys_openat
+#define sys_open_by_handle_at  compat_sys_open_by_handle_at
+
 /* Call the assembly trampolines where necessary. */
 #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
 #define sys_clone _sys_clone
diff --git a/include/uapi/asm-generic/unistd.h 
b/include/uapi/asm-generic/unistd.h
index 1324b02..07761e5 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -175,7 +175,7 @@ __SYSCALL(__NR_fchownat, sys_fchownat)
 #define __NR_fchown 55
 __SYSCALL(__NR_fchown, sys_fchown)
 #define __NR_openat 56
-__SC_COMP(__NR_openat, sys_openat, compat_sys_openat)
+__SYSCALL(__NR_openat, sys_openat)
 #define __NR_close 57
 __SYSCALL(__NR_close, sys_close)
 #define __NR_vhangup 58
@@ -673,8 +673,7 @@ __SYSCALL(__NR_fanotify_mark, sys_fanotify_mark)
 #define __NR_name_to_handle_at 264
 __SYSCALL(__NR_name_to_handle_at, sys_name_to_handle_at)
 #define __NR_open_by_handle_at 265
-__SC_COMP(__NR_open_by_handle_at, sys_open_by_handle_at, \
- compat_sys_open_by_handle_at)
+__SYSCALL(__NR_open_by_handle_at, sys_open_by_handle_at)
 #define __NR_clock_adjtime 266
 __SC_COMP(__NR_clock_adjtime, sys_clock_adjtime, compat_sys_clock_adjtime)
 #define __NR_syncfs 267
-- 
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/

[PATCH v2 0/2] ABI: handle 32-bit off_t for 32-bit and compat ABIs

[Yury Norov]

32-bit off_t is supported only for old 32-bit and compat ABIs. New ABIs
are 64-bit length only. This patchset makes 64-bit length the default
for off_t, and reverts it for old architectures where needed. It does not
change the behaviour of existing code.

First patch makes all compat users of generic unistd.h to use non-compat
versions of openat and open_by_handle_at. Tile that requires old behaviour
is turned around.

Second patch introduces ARCH_32BIT_OFF_T config option, disabled by default,
but enables it explicitly for existing 32-bit architectures.

v2:
 - removed ARCH_32BIT_OFF_T for IA64, s390, as 32-bit kernels are not supported 
there.
 - patch 2: added Arnd's note,
 - patch 2: stylistic changes.

Yury Norov (2):
  ABI: compat: use non-compat openat and open_by_handle_at variants
  32-bit ABI: introduce ARCH_32BIT_OFF_T config option

 arch/Kconfig  | 4 
 arch/arc/Kconfig  | 1 +
 arch/arm/Kconfig  | 1 +
 arch/blackfin/Kconfig | 1 +
 arch/cris/Kconfig | 1 +
 arch/frv/Kconfig  | 1 +
 arch/h8300/Kconfig| 1 +
 arch/hexagon/Kconfig  | 1 +
 arch/ia64/Kconfig | 1 +
 arch/m32r/Kconfig | 1 +
 arch/m68k/Kconfig | 1 +
 arch/metag/Kconfig| 1 +
 arch/microblaze/Kconfig   | 1 +
 arch/mips/Kconfig | 1 +
 arch/mn10300/Kconfig  | 1 +
 arch/nios2/Kconfig| 1 +
 arch/openrisc/Kconfig | 1 +
 arch/parisc/Kconfig   | 1 +
 arch/powerpc/Kconfig  | 1 +
 arch/s390/Kconfig | 1 +
 arch/score/Kconfig| 1 +
 arch/sh/Kconfig   | 1 +
 arch/sparc/Kconfig| 1 +
 arch/tile/Kconfig | 1 +
 arch/tile/kernel/compat.c | 3 +++
 arch/unicore32/Kconfig| 1 +
 arch/x86/Kconfig  | 1 +
 arch/x86/um/Kconfig   | 1 +
 arch/xtensa/Kconfig   | 1 +
 include/linux/fcntl.h | 3 ++-
 include/uapi/asm-generic/unistd.h | 5 ++---
 31 files changed, 38 insertions(+), 4 deletions(-)

-- 
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: [f2fs-dev] [PATCH 3/3] f2fs: load largest extent all the time

[Chao Yu]

Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, December 29, 2015 7:32 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 3/3] f2fs: load largest extent all the time
> 
> Otherwise, we can get mismatched largest extent information.
> 
> One example is:
> 1. mount f2fs w/ extent_cache
> 2. make a small extent
> 3. umount
> 4. mount f2fs w/o extent_cache
> 5. update the largest extent
> 6. umount
> 7. mount f2fs w/ extent_cache
> 8. get the old extent made by #2

Good catch!

It's a pity to drop it since it may provide some help if we
can reuse it.

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/extent_cache.c | 18 +-
>  fs/f2fs/f2fs.h |  2 +-
>  fs/f2fs/inode.c|  3 ++-
>  3 files changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
> index e7b6548..23e7c82 100644
> --- a/fs/f2fs/extent_cache.c
> +++ b/fs/f2fs/extent_cache.c
> @@ -166,20 +166,27 @@ static void __drop_largest_extent(struct inode *inode,
>   largest->len = 0;
>  }
> 
> -void f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
> +/* return true, if inode page is changed */
> +bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
>  {
>   struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
>   struct extent_tree *et;
>   struct extent_node *en;
>   struct extent_info ei;
> 
> - if (!f2fs_may_extent_tree(inode))
> - return;
> + if (!f2fs_may_extent_tree(inode)) {
> + /* drop largest extent */
> + if (i_ext && i_ext->len) {
> + i_ext->len = 0;
> + return true;
> + }
> + return false;
> + }
> 
>   et = __grab_extent_tree(inode);
> 
> - if (!i_ext || le32_to_cpu(i_ext->len) < F2FS_MIN_EXTENT_LEN)
> - return;
> + if (!i_ext || !i_ext->len)
> + return false;
> 
>   set_extent_info(, le32_to_cpu(i_ext->fofs),
>   le32_to_cpu(i_ext->blk), le32_to_cpu(i_ext->len));
> @@ -196,6 +203,7 @@ void f2fs_init_extent_tree(struct inode *inode, struct 
> f2fs_extent *i_ext)
>   }
>  out:
>   write_unlock(>lock);
> + return false;
>  }
> 
>  static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t pgofs,
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index e04b2be..a339508 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -2083,7 +2083,7 @@ void f2fs_leave_shrinker(struct f2fs_sb_info *);
>   * extent_cache.c
>   */
>  unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info *, int);
> -void f2fs_init_extent_tree(struct inode *, struct f2fs_extent *);
> +bool f2fs_init_extent_tree(struct inode *, struct f2fs_extent *);
>  unsigned int f2fs_destroy_extent_node(struct inode *);
>  void f2fs_destroy_extent_tree(struct inode *);
>  bool f2fs_lookup_extent_cache(struct inode *, pgoff_t, struct extent_info *);
> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> index ec3fb32..e955008 100644
> --- a/fs/f2fs/inode.c
> +++ b/fs/f2fs/inode.c
> @@ -138,7 +138,8 @@ static int do_read_inode(struct inode *inode)
>   fi->i_pino = le32_to_cpu(ri->i_pino);
>   fi->i_dir_level = ri->i_dir_level;
> 
> - f2fs_init_extent_tree(inode, >i_ext);
> + if (f2fs_init_extent_tree(inode, >i_ext))
> + set_page_dirty(node_page);
> 
>   get_inline_info(fi, ri);
> 
> --
> 2.5.4 (Apple Git-61)
> 
> 
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

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

RE: [f2fs-dev] [PATCH 2/3] f2fs: use i_size_read to get i_size

[Chao Yu]

Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, December 29, 2015 7:32 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 2/3] f2fs: use i_size_read to get i_size
> 
> We need to use i_size_read() to get inode->i_size.

All callers of f2fs_write_failed should be protected by i_mutex, so no
one can change i_size, do we really need to use i_size_read here?

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/data.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index f34f42a..8a89810 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1386,10 +1386,11 @@ skip_write:
>  static void f2fs_write_failed(struct address_space *mapping, loff_t to)
>  {
>   struct inode *inode = mapping->host;
> + loff_t i_size = i_size_read(inode);
> 
> - if (to > inode->i_size) {
> - truncate_pagecache(inode, inode->i_size);
> - truncate_blocks(inode, inode->i_size, true);
> + if (to > i_size) {
> + truncate_pagecache(inode, i_size);
> + truncate_blocks(inode, i_size, true);
>   }
>  }
> 
> --
> 2.5.4 (Apple Git-61)
> 
> 
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

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

[PATCH] iommu/amd: set AMD iommu-callbacks for the amba bus

[Wan Zongshun]

From: Wan Zongshun 

Since uart dma is using AMD iommu, and it bases on amba bus.
So we need set callbacks for amba bus type firstly.

Signed-off-by: Wan Zongshun 
---
 drivers/iommu/amd_iommu.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 8b2be1e..9097b11 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2758,7 +2759,17 @@ static struct dma_map_ops amd_iommu_dma_ops = {
 
 int __init amd_iommu_init_api(void)
 {
-   return bus_set_iommu(_bus_type, _iommu_ops);
+   int err = 0;
+
+   err = bus_set_iommu(_bus_type, _iommu_ops);
+   if (err)
+   return err;
+#ifdef CONFIG_ARM_AMBA
+   err = bus_set_iommu(_bustype, _iommu_ops);
+   if (err)
+   return err;
+#endif
+   return 0;
 }
 
 int __init amd_iommu_init_dma_ops(void)
-- 
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: On Lindent shortcomings and massive style fixing

[Andrey Utkin]

On Tue, Dec 29, 2015 at 9:32 AM, Mauro Carvalho Chehab
 wrote:
> IMHO, there are two problems by letting indent breaking long
> lines:
>
> 1) indent would break strings on printks. This is something that we don't
> want to break strings on multiple lines in the Kernel;

Yeah, GNU indent does its work badly (although I believe it could be
taught to respect long literals), this makes me want to have a better
tool for clean "relayouting" C code.
I believe that'd require at last a proper syntax parser. With such
tool, it would be straightforward to rewrite source code automatically
to please any demanding reviewer of code style, except for issues of
higher level of thought (like naming or nesting limitations).

> 2) It doesn't actually solve the problem of having too complex loops,
> with is why the 80 columns warning is meant to warn. Worse than that,
> if a piece of code is inside more than 4 or 5 indentation levels, the
> resulting code of using indent for 80-cols line break is a total crap.

Then I'd propose to enforce nesting limitation explicitly, because
Documentation/CodingStyle appreciates low nesting, just doesn't give
exact numbers.
It's better this way, because the programmer could pay attention to N
places of excessive nesting and fix it manually, and then carelessly
reformat NNN places of "80 chars" issues automatically, comparing to
reviewing all NNN places, to figure out if there's excessive nesting,
or not.
(CCed checkpatch.pl maintainers.)

> That's said, on a quick look at the driver, it seems that the 80-cols
> violations are mostly (if not all) on the comments, like:
>
> int i_poc_lsb = (frame_seqno_in_gop << 1); /* why multiplied by two? 
> TODO try without multiplication */
>
> and
>
> #define TW5864_UNDEF_REG_0x0224 0x0224  /* Undeclared in spec (or not yet 
> added to tw5864-reg.h) but used */
> #define TW5864_UNDEF_REG_0x4014 0x4014  /* Undeclared in spec (or not yet 
> added to tw5864-reg.h) but used */
> #define TW5864_UNDEF_REG_0xA800 0xA800  /* Undeclared in spec (or not yet 
> added to tw5864-reg.h) but used */
>
> Btw, the content of tw5864-reg-undefined.h is weird... Why not just
> add the stuff there at tw5864-reg.h and remove the comments for all
> defines there?

tw5864-reg-undefined.h will be edited for sure (maybe dropped), of
course it won't stay as it is now.
It was generated by script during reverse-engineering that bastard
chip from hell.

> Also, Lindent already did some crappy 80-cols like breaks, like:
>
> static int pci_i2c_multi_read(struct tw5864_dev *dev, u8 devid, u8 devfn, u8 
> *buf,
>u32 count)
>
> (count is misaligned with the open parenthesis)

I just added "static " after indenting.
Actually, Documentation/CodingStyle says nothing about alignment of
function declaration tail on open parenthesis.
Also I'd like to mention that I hate such alignment, because it
requires intermixing of tabs and spaces. I am not aware if this is K
thing or not. If it is, then please don't kill me.

Thanks for kind replies, gentlemen.
--
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/7] omapfb: fix error return code

[Tomi Valkeinen]

On 26/12/15 17:28, Julia Lawall wrote:
> Return a negative error code on failure.
> 
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> identifier ret; expression e1,e2;
> @@
> (
> if (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret = 0
> )
> ... when != ret = e1
> when != 
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> // 
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c |   12 
> +++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c 
> b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
> index 677e254..fc4cfa9 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
> @@ -241,22 +241,28 @@ static int tpd_probe(struct platform_device *pdev)
>  
>   gpio = devm_gpiod_get_index_optional(>dev, NULL, 0,
>   GPIOD_OUT_LOW);
> - if (IS_ERR(gpio))
> + if (IS_ERR(gpio)) {
> + r = PTR_ERR(gpio);
>   goto err_gpio;
> + }
>  
>   ddata->ct_cp_hpd_gpio = gpio;
>  
>   gpio = devm_gpiod_get_index_optional(>dev, NULL, 1,
>   GPIOD_OUT_LOW);
> - if (IS_ERR(gpio))
> + if (IS_ERR(gpio)) {
> + r = PTR_ERR(gpio);
>   goto err_gpio;
> + }
>  
>   ddata->ls_oe_gpio = gpio;
>  
>   gpio = devm_gpiod_get_index(>dev, NULL, 2,
>   GPIOD_IN);
> - if (IS_ERR(gpio))
> + if (IS_ERR(gpio)) {
> + r = PTR_ERR(gpio);
>   goto err_gpio;
> + }
>  
>   ddata->hpd_gpio = gpio;

Thanks. Looks like recent changes to the driver break the error
handling. I'll just drop those patches from my for-next branch, and let
the author fix the patches.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH 4/5] x86/events: Move perf_event_amd_iommu.*

[Boris Petkov]

Joerg Roedel  wrote:

>Hmm, the arch/x86/events directory does not exist yet, is it the plan
>to move non-cpu event over there? It looks to be a better place for the
>iommu events, are there more no-cpu events to move there?

Yeah, basically move all arch/x86/ *perf_event* stuff there.



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

Re: [PATCH v2 2/3] device property: the secondary fwnode needs to depend on the primary

[Heikki Krogerus]

Hi Andy,

Found a bug from my code..

> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 0b22c8a..6c04d18 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -218,7 +218,7 @@ bool fwnode_property_present(struct fwnode_handle 
> *fwnode, const char *propname)
>   bool ret;
>  
>   ret = __fwnode_property_present(fwnode, propname);
> - if (ret == false && fwnode->secondary)
> + if (ret == false && fwnode && fwnode->secondary)
>   ret = __fwnode_property_present(fwnode->secondary, propname);
>   return ret;
>  }
> @@ -423,7 +423,7 @@ EXPORT_SYMBOL_GPL(device_property_match_string);
>   int _ret_;  
> \
>   _ret_ = FWNODE_PROP_READ(_fwnode_, _propname_, _type_, _proptype_,  
> \
>_val_, _nval_);
> \
> - if (_ret_ == -EINVAL && _fwnode_->secondary)
> \
> + if (_ret_ == -EINVAL && fwnode && _fwnode_->secondary)  
> \

This should be .._fwnode_ && _fwnode_->secondary)

>   _ret_ = FWNODE_PROP_READ(_fwnode_->secondary, _propname_, 
> _type_,   \
>   _proptype_, _val_, _nval_); 
> \
>   _ret_;  
> \


Cheers,

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

[Bug] compile error

[Chen Bough]

Hi,
For the latest linux-next tree[tag: v4.4-rc6], I meet one compile error, 

drivers/media/usb/uvc/uvc_driver.c: In function 'uvc_probe':
drivers/media/usb/uvc/uvc_driver.c:1941:32: error: 'struct uvc_device' has no 
member named 'mdev'
  if (media_device_register(>mdev) < 0)
^
make[4]: *** [drivers/media/usb/uvc/uvc_driver.o] Error 1
make[4]: *** Waiting for unfinished jobs



Best Regards
Haibo 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/

[PATCH V3 1/1] arm64: dts: add Hi6220 spi configuration nodes

[Zhong Kaihua]

arm64: dts: add Hi6220 spi configuration nodes

Signed-off-by: Zhong Kaihua 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |  1 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  | 20 
 2 files changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 4fb0bdc..2313ae0 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -23,6 +23,7 @@
serial1 =  /* BT UART */
serial2 =  /* LS Expansion UART0 */
serial3 =  /* LS Expansion UART1 */
+   spi0 = _0;
};
 
chosen {
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 0f11e2a..da0fe37 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -489,5 +489,25 @@
clock-names = "apb_pclk";
status = "ok";
};
+
+   spi_0: spi@f7106000 {
+   compatible = "arm,pl022", "arm,primecell";
+   reg = <0x0 0xf7106000 0x0 0x1000>;
+   interrupts = <0 50 4>;
+   bus-id = <0>;
+   enable-dma = <0>;
+   /*dmas = < 12  13>;*/
+   /*dma-names = "rx", "tx";*/
+
+   clocks = <_ctrl HI6220_SPI_CLK>;
+   clock-names = "apb_pclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmx_func _cfg_func>;
+   num-cs = <1>;
+   cs-gpios = < 2 0>;
+
+   status = "ok";
+   };
+
};
 };
-- 
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] lightnvm: put block back to gc list on its reclaim fail

[Wenwei Tao]

We delete a block from the gc list before reclaim it, so
put it back to the list on its reclaim fail, otherwize
this block will not get reclaimed and be programable
in the future.

Signed-off-by: Wenwei Tao 
---
 drivers/lightnvm/rrpc.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index d40c140..67b14d4 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -379,16 +379,26 @@ static void rrpc_block_gc(struct work_struct *work)
struct rrpc *rrpc = gcb->rrpc;
struct rrpc_block *rblk = gcb->rblk;
struct nvm_dev *dev = rrpc->dev;
+   struct nvm_lun *lun = rblk->parent->lun;
+   struct rrpc_lun *rlun = >luns[lun->id - rrpc->lun_offset];
 
+   mempool_free(gcb, rrpc->gcb_pool);
pr_debug("nvm: block '%lu' being reclaimed\n", rblk->parent->id);
 
if (rrpc_move_valid_pages(rrpc, rblk))
-   goto done;
+   goto put_back;
+
+   if (nvm_erase_blk(dev, rblk->parent))
+   goto put_back;
 
-   nvm_erase_blk(dev, rblk->parent);
rrpc_put_blk(rrpc, rblk);
-done:
-   mempool_free(gcb, rrpc->gcb_pool);
+
+   return;
+
+put_back:
+   spin_lock(>lock);
+   list_add_tail(>prio, >prio_list);
+   spin_unlock(>lock);
 }
 
 /* the block with highest number of invalid pages, will be in the beginning
-- 
1.8.3.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: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

On Mon, Dec 28, 2015 at 8:41 PM, Bjorn Andersson  wrote:
> I interpreted this as you picked patch 1-4 and didn't pay more
> attention to them, but I can't find them in your kernel.org trees. So
> I've looked through them again.
>
> Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find
> a v5 of patch 2, but it's unrelated so no need to wait for a new
> version of that.

I was under the impression that Lee plans to resubmit once the
discussion around patch 2 settles, so I haven't picked the series yet.

Lee please let me know - I can take 1/3/4 and wait for the new 2 as well.

Thanks,
Ohad.
--
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] lightnvm: wrong offset in bad blk lun calculation

[Jens Axboe]

On 12/29/2015 06:37 AM, Matias Bjørling wrote:

dev->nr_luns reports the total number of luns available in a device
while dev->luns_per_chnl is the number of luns per channel.

When multiple channels are available, the offset is calculated from a
channel and lun id into a linear array. As it multiplies with
the total number of luns, we go out of bound when channel id > 0 and
causes the kernel to panic when we read a protected kernel memory area.


Added for 4.4, thanks.

--
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: use-after-free in hash_sock_destruct

[Dmitry Vyukov]

On Tue, Dec 29, 2015 at 3:40 PM, Herbert Xu  wrote:
> On Thu, Dec 17, 2015 at 01:59:50PM +0100, Dmitry Vyukov wrote:
>>
>> The following program causes use-after-free in hash_sock_destruct:
>
> This patch should fix the problem.  AFAIK everything that you have
> reported should now be fixed.  If you still have issues please
> resubmit them (and please cc me).  Thanks!

Thanks Herbert!
I will do another round of crypto testing with this patch (on top of
the other two patches) and report if I see any bugs.



> ---8<---
> Subject: crypto: af_alg - Disallow bind/setkey/... after accept(2)
>
> Each af_alg parent socket obtained by socket(2) corresponds to a
> tfm object once bind(2) has succeeded.  An accept(2) call on that
> parent socket creates a context which then uses the tfm object.
>
> Therefore as long as any child sockets created by accept(2) exist
> the parent socket must not be modified or freed.
>
> This patch guarantees this by using locks and a reference count
> on the parent socket.  Any attempt to modify the parent socket will
> fail with EBUSY.
>
> Cc: sta...@vger.kernel.org
> Reported-by: Dmitry Vyukov 
> Signed-off-by: Herbert Xu 
>
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index a8e7aa3..f5a2426 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -125,6 +125,23 @@ int af_alg_release(struct socket *sock)
>  }
>  EXPORT_SYMBOL_GPL(af_alg_release);
>
> +void af_alg_release_parent(struct sock *sk)
> +{
> +   struct alg_sock *ask = alg_sk(sk);
> +   bool last;
> +
> +   sk = ask->parent;
> +   ask = alg_sk(sk);
> +
> +   lock_sock(sk);
> +   last = !--ask->refcnt;
> +   release_sock(sk);
> +
> +   if (last)
> +   sock_put(sk);
> +}
> +EXPORT_SYMBOL_GPL(af_alg_release_parent);
> +
>  static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int 
> addr_len)
>  {
> const u32 forbidden = CRYPTO_ALG_INTERNAL;
> @@ -133,6 +150,7 @@ static int alg_bind(struct socket *sock, struct sockaddr 
> *uaddr, int addr_len)
> struct sockaddr_alg *sa = (void *)uaddr;
> const struct af_alg_type *type;
> void *private;
> +   int err;
>
> if (sock->state == SS_CONNECTED)
> return -EINVAL;
> @@ -160,16 +178,22 @@ static int alg_bind(struct socket *sock, struct 
> sockaddr *uaddr, int addr_len)
> return PTR_ERR(private);
> }
>
> +   err = -EBUSY;
> lock_sock(sk);
> +   if (ask->refcnt)
> +   goto unlock;
>
> swap(ask->type, type);
> swap(ask->private, private);
>
> +   err = 0;
> +
> +unlock:
> release_sock(sk);
>
> alg_do_release(type, private);
>
> -   return 0;
> +   return err;
>  }
>
>  static int alg_setkey(struct sock *sk, char __user *ukey,
> @@ -188,14 +212,41 @@ static int alg_setkey(struct sock *sk, char __user 
> *ukey,
> if (copy_from_user(key, ukey, keylen))
> goto out;
>
> +   err = -EBUSY;
> +   lock_sock(sk);
> +   if (ask->refcnt)
> +   goto unlock;
> +
> err = type->setkey(ask->private, key, keylen);
>
> +unlock:
> +   release_sock(sk);
> +
>  out:
> sock_kzfree_s(sk, key, keylen);
>
> return err;
>  }
>
> +static int alg_setauthsize(struct sock *sk, unsigned int size)
> +{
> +   int err;
> +   struct alg_sock *ask = alg_sk(sk);
> +   const struct af_alg_type *type = ask->type;
> +
> +   err = -EBUSY;
> +   lock_sock(sk);
> +   if (ask->refcnt)
> +   goto unlock;
> +
> +   err = type->setauthsize(ask->private, size);
> +
> +unlock:
> +   release_sock(sk);
> +
> +   return err;
> +}
> +
>  static int alg_setsockopt(struct socket *sock, int level, int optname,
>   char __user *optval, unsigned int optlen)
>  {
> @@ -224,7 +275,7 @@ static int alg_setsockopt(struct socket *sock, int level, 
> int optname,
> goto unlock;
> if (!type->setauthsize)
> goto unlock;
> -   err = type->setauthsize(ask->private, optlen);
> +   err = alg_setauthsize(sk, optlen);
> }
>
>  unlock:
> @@ -264,7 +315,8 @@ int af_alg_accept(struct sock *sk, struct socket *newsock)
>
> sk2->sk_family = PF_ALG;
>
> -   sock_hold(sk);
> +   if (!ask->refcnt++)
> +   sock_hold(sk);
> alg_sk(sk2)->parent = sk;
> alg_sk(sk2)->type = type;
>
> diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
> index 018afb2..589716f 100644
> --- a/include/crypto/if_alg.h
> +++ b/include/crypto/if_alg.h
> @@ -30,6 +30,8 @@ struct alg_sock {
>
> struct sock *parent;
>
> +   unsigned int refcnt;
> +
> const struct af_alg_type *type;
> void *private;
>  };
> @@ -67,6 +69,7 @@ int af_alg_register_type(const struct af_alg_type *type);
>  int 

[PATCH v2 1/2] lib/vsprintf: refactor duplicate code to special_hex_number()

[Andy Shevchenko]

special_hex_number() is a helper to print a fixed size type in a hex format
with '0x' prefix, zero padding, and small letters. In the module we have
already several copies of such code. Consolidate them under
special_hex_number() helper.

There are couple of differences though.

It seems nobody cared about the output in case of CONFIG_KALLSYMS=n, when
printing symbol address, because the asked field width is not enough to care
last 2 characters in the string represantation of the pointer. Fixed here.

The %pNF specifier used to be allowed with a specific field width, though there
is neither any user of it nor mention the possibility in the documentation.

Signed-off-by: Andy Shevchenko 
---
 lib/vsprintf.c | 53 +++--
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 88ed574..6946431 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -514,6 +514,20 @@ char *number(char *buf, char *end, unsigned long long num,
return buf;
 }
 
+static noinline_for_stack
+char *special_hex_number(char *buf, char *end, unsigned long long num, int 
size)
+{
+   struct printf_spec spec;
+
+   spec.type = FORMAT_TYPE_PTR;
+   spec.field_width = 2 + 2 * size;/* 0x + hex */
+   spec.flags = SPECIAL | SMALL | ZEROPAD;
+   spec.base = 16;
+   spec.precision = -1;
+
+   return number(buf, end, num, spec);
+}
+
 static void move_right(char *buf, char *end, unsigned len, unsigned spaces)
 {
size_t size;
@@ -649,11 +663,7 @@ char *symbol_string(char *buf, char *end, void *ptr,
 
return string(buf, end, sym, spec);
 #else
-   spec.field_width = 2 * sizeof(void *);
-   spec.flags |= SPECIAL | SMALL | ZEROPAD;
-   spec.base = 16;
-
-   return number(buf, end, value, spec);
+   return special_hex_number(buf, end, value, sizeof(void *));
 #endif
 }
 
@@ -1315,39 +1325,33 @@ char *uuid_string(char *buf, char *end, const u8 *addr,
 }
 
 static
-char *netdev_feature_string(char *buf, char *end, const u8 *addr,
- struct printf_spec spec)
+char *netdev_feature_string(char *buf, char *end, const void *addr)
 {
-   spec.flags |= SPECIAL | SMALL | ZEROPAD;
-   if (spec.field_width == -1)
-   spec.field_width = 2 + 2 * sizeof(netdev_features_t);
-   spec.base = 16;
+   unsigned long long num = *(const netdev_features_t *)addr;
+   int size = sizeof(netdev_features_t);
 
-   return number(buf, end, *(const netdev_features_t *)addr, spec);
+   return special_hex_number(buf, end, num, size);
 }
 
 static noinline_for_stack
-char *address_val(char *buf, char *end, const void *addr,
- struct printf_spec spec, const char *fmt)
+char *address_val(char *buf, char *end, const void *addr, const char *fmt)
 {
unsigned long long num;
-
-   spec.flags |= SPECIAL | SMALL | ZEROPAD;
-   spec.base = 16;
+   int size;
 
switch (fmt[1]) {
case 'd':
num = *(const dma_addr_t *)addr;
-   spec.field_width = sizeof(dma_addr_t) * 2 + 2;
+   size = sizeof(dma_addr_t);
break;
case 'p':
default:
num = *(const phys_addr_t *)addr;
-   spec.field_width = sizeof(phys_addr_t) * 2 + 2;
+   size = sizeof(phys_addr_t);
break;
}
 
-   return number(buf, end, num, spec);
+   return special_hex_number(buf, end, num, size);
 }
 
 static noinline_for_stack
@@ -1366,10 +1370,7 @@ char *clock(char *buf, char *end, struct clk *clk, 
struct printf_spec spec,
 #ifdef CONFIG_COMMON_CLK
return string(buf, end, __clk_get_name(clk), spec);
 #else
-   spec.base = 16;
-   spec.field_width = sizeof(unsigned long) * 2 + 2;
-   spec.flags |= SPECIAL | SMALL | ZEROPAD;
-   return number(buf, end, (unsigned long)clk, spec);
+   return special_hex_number(buf, end, (unsigned long)clk, 
sizeof(unsigned long));
 #endif
}
 }
@@ -1672,11 +1673,11 @@ char *pointer(const char *fmt, char *buf, char *end, 
void *ptr,
case 'N':
switch (fmt[1]) {
case 'F':
-   return netdev_feature_string(buf, end, ptr, spec);
+   return netdev_feature_string(buf, end, ptr);
}
break;
case 'a':
-   return address_val(buf, end, ptr, spec, fmt);
+   return address_val(buf, end, ptr, fmt);
case 'd':
return dentry_name(buf, end, ptr, spec, fmt);
case 'C':
-- 
2.6.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 0/2] lib/vsprintf: introduce stricter rules for %p extensions

[Andy Shevchenko]

Besides the code refactoring we introduce the following rules for %p extensions
here. i.e:

- fixed type extensions are always printed in hex format, prefixed by '0x',
  small letters, full field width on a running architecture (%pa[dp], %pNF)

- fallback to %p based on different kernel configuration will be under the same
  rule set as for fixed types above (%pCn when COMMON_CLK=n, %p[FfSsB] when
  KALLSYMS=n)

- fallback to %p of unimplemented extension will be under the same rule set as
  for fixed types above (%pN)

Since v1:
 - address comments from Joe and Rasmums (might be not all of them)
 - add patch 2
 - desribe in cover letter what is done besides refactoring

Andy Shevchenko (2):
  lib/vsprintf: refactor duplicate code to special_hex_number()
  lib/vsprintf: factor out %pN[F] handler as netdev_bits()

 lib/vsprintf.c | 70 --
 1 file changed, 39 insertions(+), 31 deletions(-)

-- 
2.6.4

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

Re: [PATCH] drivers: power: fix typo in documentation

[Pavel Machek]

On Tue 2015-12-29 11:03:21, Manuel Pégourié-Gonnard wrote:
> The documentation for detach() said attach.
> 
> Signed-off-by: Manuel Pégourié-Gonnard 
> Cc: triv...@kernel.org

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] lib/vsprintf: factor out %pN[F] handler as netdev_bits()

[Andy Shevchenko]

Move switch case to the netdev_features_string() and rename it to
netdev_bits(). In the future we can extend it as needed.

Here we replace the fallback of %pN from '%p' with possible flags to sticter
'0x%p' without any flags variation.

Signed-off-by: Andy Shevchenko 
---
 lib/vsprintf.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 6946431..5c22317 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1324,11 +1324,22 @@ char *uuid_string(char *buf, char *end, const u8 *addr,
return string(buf, end, uuid, spec);
 }
 
-static
-char *netdev_feature_string(char *buf, char *end, const void *addr)
+static noinline_for_stack
+char *netdev_bits(char *buf, char *end, const void *addr, const char *fmt)
 {
-   unsigned long long num = *(const netdev_features_t *)addr;
-   int size = sizeof(netdev_features_t);
+   unsigned long long num;
+   int size;
+
+   switch (fmt[1]) {
+   case 'F':
+   num = *(const netdev_features_t *)addr;
+   size = sizeof(netdev_features_t);
+   break;
+   default:
+   num = (unsigned long)addr;
+   size = sizeof(unsigned long);
+   break;
+   }
 
return special_hex_number(buf, end, num, size);
 }
@@ -1671,11 +1682,7 @@ char *pointer(const char *fmt, char *buf, char *end, 
void *ptr,
break;
 
case 'N':
-   switch (fmt[1]) {
-   case 'F':
-   return netdev_feature_string(buf, end, ptr);
-   }
-   break;
+   return netdev_bits(buf, end, ptr, fmt);
case 'a':
return address_val(buf, end, ptr, fmt);
case 'd':
-- 
2.6.4

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

Re: [PATCH] pty: fix use after free of tty->driver_data

[Herton R. Krzesinski]

On Tue, Dec 15, 2015 at 04:05:09PM -0200, Herton R. Krzesinski wrote:
> On Tue, Dec 15, 2015 at 09:36:26AM -0800, Peter Hurley wrote:
> > > since in this
> > > case any of the tty->driver_data can be stale, due to all references/
> > > files being closed before (files related to ptmx/pts inodes set at
> > > tty->driver_data), we have the possibility of referencing an already
> > > freed inode.
> > 
> > As I wrote above, I believe this is the only possible circumstance
> > for which the file that is releasing could have stale pts inodes.
> > 
> > 
> > > The fix here is to keep a reference on the opened master ptmx inode.
> > > We maintain the inode referenced until the final pty_unix98_shutdown,
> > > and only pass this inode to devpts_kill_index.
> > 
> > Let me think some on your proposed solution.
> 
> Ok, let me know what you think, at least I will have to repost the patch
> with the changelog fixed, unless you think there is another/better solution
> for the issue.

Hi Peter, any news on this issue?

I gave some more thought and testing into this, and I think we simply should do
a change like below instead of my previous patch proposal:

diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index a45660f..73e36bd 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -68,6 +68,7 @@ static void pty_close(struct tty_struct *tty, struct file 
*filp)
mutex_lock(_mutex);
if (tty->link->driver_data)
devpts_pty_kill(tty->link->driver_data);
+   devpts_kill_index(tty->driver_data, tty->index);
mutex_unlock(_mutex);
}
 #endif
@@ -678,12 +679,6 @@ static void pty_unix98_remove(struct tty_driver *driver, 
struct tty_struct *tty)
 {
 }
 
-/* this is called once with whichever end is closed last */
-static void pty_unix98_shutdown(struct tty_struct *tty)
-{
-   devpts_kill_index(tty->driver_data, tty->index);
-}
-
 static const struct tty_operations ptm_unix98_ops = {
.lookup = ptm_unix98_lookup,
.install = pty_unix98_install,
@@ -697,7 +692,6 @@ static const struct tty_operations ptm_unix98_ops = {
.unthrottle = pty_unthrottle,
.ioctl = pty_unix98_ioctl,
.resize = pty_resize,
-   .shutdown = pty_unix98_shutdown,
.cleanup = pty_cleanup
 };
 
@@ -715,7 +709,6 @@ static const struct tty_operations pty_unix98_ops = {
.set_termios = pty_set_termios,
.start = pty_start,
.stop = pty_stop,
-   .shutdown = pty_unix98_shutdown,
.cleanup = pty_cleanup,
 };
 
-- 
2.4.3


That is, move devpts_kill_index up into pty_close(). It also resolves the
problem, while at the same time handles another problem which my previous
patch didn't catch, for example look at this other test case:

#define _XOPEN_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
pid_t pid;
int ptm_fd, pty_fd, tty_fd;

system("mkdir -p /mnt/newpts");
system("mount -t devpts -o newinstance none /mnt/newpts");
pid = fork();
if (pid != 0)
exit(0);
daemon(1, 0);
ptm_fd = open("/mnt/newpts/ptmx", O_RDWR);
unlockpt(ptm_fd);
pty_fd = open("/mnt/newpts/0", O_RDWR);
tty_fd = open("/dev/tty", O_RDWR);
pid = fork();
if (pid == 0) {
ioctl(tty_fd, TIOCNOTTY, NULL);
setsid();
sleep(20);
close(pty_fd);
close(ptm_fd);
system("umount /mnt/newpts");
sleep(10);
exit(0);
}
sleep(10);
return 0;
}

The idea here is to umount a pts mount while still we have /dev/tty pointing to
a pty opened...

And of course it doesn't go well with the late devpts_kill_index:

[ 1326.233991] [ cut here ]
[ 1326.234014] WARNING: CPU: 1 PID: 2668 at lib/idr.c:1051 
ida_remove+0x9b/0x130()
[ 1326.234015] ida_remove called for id=0 which is not allocated.
[ 1326.234016] Modules linked in: 8021q mrp garp stp llc nf_conntrack_ipv4 
nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 
xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc ppdev joydev 
floppy parport_pc parport serio_raw tpm_tis tpm virtio_balloon virtio_console 
virtio_net iosf_mbi crct10dif_pclmul crc32_pclmul pcspkr snd_hda_codec_generic 
i2c_piix4 snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq 
snd_seq_device snd_pcm snd_timer snd soundcore qxl ttm drm_kms_helper drm 
virtio_blk crc32c_intel virtio_pci virtio_ring virtio pata_acpi ata_generic 
[last unloaded: speedstep_lib]
[ 1326.234061] CPU: 1 PID: 2668 Comm: newpty Not tainted 4.4.0-rc7 #1
[ 1326.234062] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.8.1-20150318_183358- 04/01/2014
[ 1326.234065]  041b 8800375ffbc8 8139aed4 

Re: [PATCH] ath6kl: Use vmalloc to allocate ar->fw for api1 method

[Souptick Joarder]

Brent,

On Tue, Dec 22, 2015 at 2:42 PM, Kalle Valo  wrote:
> Souptick Joarder  writes:
>
>> Hi Brent,
>>
>> On Tue, Dec 22, 2015 at 3:23 AM, Brent Taylor  wrote:
>>> On Mon, Dec 21, 2015 at 1:23 PM, Souptick Joarder  
>>> wrote:
 Hi Brent,

 On Tue, Dec 1, 2015 at 11:11 AM, Brent Taylor  wrote:

> --- a/drivers/net/wireless/ath/ath6kl/init.c
> +++ b/drivers/net/wireless/ath/ath6kl/init.c
> @@ -673,10 +673,15 @@ static int ath6kl_get_fw(struct ath6kl *ar, const 
> char *filename,
> return ret;
>
> *fw_len = fw_entry->size;
> -   *fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
> +   if (>fw == fw)
> +   *fw = vmalloc(fw_entry->size);
> +   else
> +   *fw = kmalloc(fw_entry->size, GFP_KERNEL)

   Why vmalloc and kmalloc both are required? can't use either
 vmalloc or kmalloc?
>>>
>>> My original problem was that kmemdup (which uses kmalloc) could not
>>> allocate enough memory
>>
>> If kmemdump ( which uses kmalloc) could not allocate memory then
>> using kmalloc again can lead to same problem.
>> I guess it will be correct to use
>> *fw = vmalloc(fw_entry->size);
>> Correct me if i am wrong.
>
> That sounds best. But remember take into account DMA requirements, IIRC
> you cannot DMA from vmalloc memory on all platforms.

Is it possible to modify the patch as per feedback from Kalle.

>
> --
> Kalle Valo

-Souptick
--
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] mfd: twl-core: One function call less in add_numbered_child() after error detection

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 29 Dec 2015 19:29:08 +0100

The platform_device_put() function was called in one case by the
add_numbered_child() function during error handling even if the passed
variable "pdev" 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/mfd/twl-core.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 831696e..0d9350c 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -625,7 +625,7 @@ add_numbered_child(unsigned mod_no, const char *name, int 
num,
if (!pdev) {
dev_dbg(>client->dev, "can't alloc dev\n");
status = -ENOMEM;
-   goto err;
+   goto report_failure;
}
 
pdev->dev.parent = >client->dev;
@@ -634,7 +634,7 @@ add_numbered_child(unsigned mod_no, const char *name, int 
num,
status = platform_device_add_data(pdev, pdata, pdata_len);
if (status < 0) {
dev_dbg(>dev, "can't add platform_data\n");
-   goto err;
+   goto put_device;
}
}
 
@@ -647,21 +647,20 @@ add_numbered_child(unsigned mod_no, const char *name, int 
num,
status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1);
if (status < 0) {
dev_dbg(>dev, "can't add irqs\n");
-   goto err;
+   goto put_device;
}
}
 
status = platform_device_add(pdev);
-   if (status == 0)
+   if (!status) {
device_init_wakeup(>dev, can_wakeup);
-
-err:
-   if (status < 0) {
-   platform_device_put(pdev);
-   dev_err(>client->dev, "can't add %s dev\n", name);
-   return ERR_PTR(status);
+   return >dev;
}
-   return >dev;
+put_device:
+   platform_device_put(pdev);
+report_failure:
+   dev_err(>client->dev, "can't add %s dev\n", name);
+   return ERR_PTR(status);
 }
 
 static inline struct device *add_child(unsigned mod_no, const char *name,
-- 
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 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Rob Herring]

On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> Signed-off-by: Bjorn Andersson 
> ---
>  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> ++
>  1 file changed, 76 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> new file mode 100644
> index ..7b314b9f30af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> @@ -0,0 +1,76 @@
> +Qualcomm WCN36xx WiFi Binding
> +
> +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware block
> +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> variety
> +of Qualcomm platforms.

Are BT/FM functions completely separate? If so, separate bindings are 
okay. If not, then we need to describe the full chip.

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

Re: [PATCH v3 2/5] dt-bindings: mediatek: Modify pinctrl bindings for mt2701

[Rob Herring]

On Mon, Dec 28, 2015 at 03:09:03PM +0800, Biao Huang wrote:
> Signed-off-by: Biao Huang 
> ---
>  .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)

I acked v2 already. Please add acks when posting new versions.

Acked-by: Rob Herring 

--
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] mtd: fixing memory leak and handling failed kmalloc

[Insu Yun]

kmalloc needs to be handled when failing in memory pressure.
Also, it has memory leak in error routine.

Signed-off-by: Insu Yun 
---
 drivers/mtd/chips/cfi_cmdset_0001.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c 
b/drivers/mtd/chips/cfi_cmdset_0001.c
index 286b97a..5e1b68c 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -596,7 +596,7 @@ static struct mtd_info *cfi_intelext_setup(struct mtd_info 
*mtd)
mtd->size = devsize * cfi->numchips;
 
mtd->numeraseregions = cfi->cfiq->NumEraseRegions * cfi->numchips;
-   mtd->eraseregions = kmalloc(sizeof(struct mtd_erase_region_info)
+   mtd->eraseregions = kzalloc(sizeof(struct mtd_erase_region_info)
* mtd->numeraseregions, GFP_KERNEL);
if (!mtd->eraseregions)
goto setup_err;
@@ -614,6 +614,8 @@ static struct mtd_info *cfi_intelext_setup(struct mtd_info 
*mtd)

mtd->eraseregions[(j*cfi->cfiq->NumEraseRegions)+i].erasesize = ersize;

mtd->eraseregions[(j*cfi->cfiq->NumEraseRegions)+i].numblocks = ernum;

mtd->eraseregions[(j*cfi->cfiq->NumEraseRegions)+i].lockmap = kmalloc(ernum / 8 
+ 1, GFP_KERNEL);
+   if 
(!mtd->eraseregions[(j*cfi->cfiq->NumEraseRegions)+i].lockmap)
+   goto setup_err;
}
offset += (ersize * ernum);
}
@@ -650,6 +652,10 @@ static struct mtd_info *cfi_intelext_setup(struct mtd_info 
*mtd)
return mtd;
 
  setup_err:
+   if (mtd->eraseregions)
+   for (i=0; icfiq->NumEraseRegions; i++)
+   for (j=0; jnumchips; j++)
+   
kfree(mtd->eraseregions[(j*cfi->cfiq->NumEraseRegions)+i].lockmap);
kfree(mtd->eraseregions);
kfree(mtd);
kfree(cfi->cmdset_priv);
-- 
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 1/1] kernel booting messages, first line

[Randy Dunlap]

On 12/28/15 17:31, Alexandru GOIA wrote:
> 
> For -rc8 ,
> 
> Hoping that someone DO cares about the aesthetic of kernel messages at boot :
> 
>  
> What it does : first line of booting kernel, as seen in dmesg(1), will be the 
> Linux kernel signature
> (version, compiler, compiler hostname).
> 
> What it solves : it appers ahead of cgroup messages at booting.
> 
> 
> This ugliness, since 3.10.x kernel.
> 
> 
> So :
> 
> Instead of the unaesthetic lines :
> 
> Initializing cgroup subsys cpuset
> Initializing cgroup subsys cpu
> Initializing cgroup subsys cpuacct
> Linux version 4 ...
> 
> 
> ... We will have :
> 
> 
> Linux version 4 ...
> Initializing cgroup subsys cpuset
> Initializing cgroup subsys cpu
> Initializing cgroup subsys cpuacct
> 
> 
> As normal .
> 
> 
> In file linux-4.4-rc7/init/main.c  :
> 
> 
> 
> --- main.c  2015-12-28 04:17:37.0 +0200
> +++ main+.c 2015-12-29 03:18:59.896820046 +0200
> @@ -512,6 +512,7 @@
>   * Set up the the initial canary ASAP:
>   */
>  boot_init_stack_canary();
> +   pr_notice("%s", linux_banner);
>  
>  cgroup_init_early();
>  
> @@ -524,7 +525,6 @@
>   */
>  boot_cpu_init();
>  page_address_init();
> -   pr_notice("%s", linux_banner);
>  setup_arch(_line);
>  mm_init_cpumask(_mm);
>  setup_command_line(command_line);
> 
> 
> 
> 
> Signed-off-by: Alexandru Goia --


I like the patch. Could you make it a proper kernel patch, please?


thanks,
-- 
~Randy
--
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] qxl: correctly handling failed allocation

[Insu Yun]

Since kmalloc can be failed in memory pressure, 
when fails, return error code.

Signed-off-by: Insu Yun 
---
 drivers/gpu/drm/qxl/qxl_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index b2977a1..2e99854 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -221,6 +221,9 @@ static int qxl_device_init(struct qxl_device *qdev,
kmalloc(qdev->n_mem_slots * sizeof(struct qxl_memslot),
GFP_KERNEL);
 
+   if (!qdev->memslots)
+   return -ENOMEM;
+
idr_init(>release_idr);
spin_lock_init(>release_idr_lock);
spin_lock_init(>release_lock);
-- 
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 3/3] bpf: hash: use per-bucket spinlock

[Daniel Borkmann]

On 12/29/2015 03:40 PM, Ming Lei wrote:

Both htab_map_update_elem() and htab_map_delete_elem() can be
called from eBPF program, and they may be in kernel hot path,
so it isn't efficient to use a per-hashtable lock in this two
helpers.

The per-hashtable spinlock is used for protecting bucket's
hlist, and per-bucket lock is just enough. This patch converts
the per-hashtable lock into per-bucket spinlock, so that
contention can be decreased a lot.

Signed-off-by: Ming Lei 


Looks better, thanks!

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

Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Sebastian Frias]

On 12/29/2015 03:16 PM, Frans Klaver wrote:

On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias  wrote:

Right now we don't know if the driver will be upstreamed.
Let me rephrase my question:

- how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?

If that is not possible, I guess we will have to keep a forked tree until
the driver is upstreamed, but we would like to avoid that, hence the
question.


I guess you'll have to keep on doing that indeed. I'm not aware of any
location where out-of-tree drivers are considered. You should try
again when you have some actual code to upstream.



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

Re: [PATCH v6] serial: rewrite pxa2xx-uart to use 8250_core

[Robert Jarzmik]

Heikki Krogerus  writes:

> On Thu, Dec 24, 2015 at 06:15:14PM +0300, Sergei Ianovich wrote:
>> pxa2xx-uart was a separate uart platform driver. It was declaring
>> the same device names and numbers as 8250 driver. As a result,
>> it was impossible to use 8250 driver on PXA SoCs.
>> 
>> Upon closer examination pxa2xx-uart turned out to be a clone of
>> 8250_core driver.
>> 
>> Workaround for Erratum #19 according to Marvel(R) PXA270M Processor
>> Specification Update (April 19, 2010) is dropped. 8250_core reads
>> from FIFO immediately after checking DR bit in LSR.
>> 
>> The patch leaves the original SERIAL_PXA driver around. The original
>> driver is just marked DEPRECATED in Kconfig and C source. When
>> the original driver is considered safe to remove, no changes
>> to SERIAL_8250 will be necessary.
>> 
>> Compiling SERIAL_8250_CONSOLE and SERIAL_PXA_CONSOLE even without
>> SERIAL_8250_PXA breaks console for SERIAL_PXA. For this reasons, the new
>> and the original drivers are made mutually exclusive.
>> 
>> Signed-off-by: Sergei Ianovich 
>> CC: Heikki Krogerus 
>
> Reviewed-by: Heikki Krogerus 
Tested-by: Robert Jarzmik 

The tests were done on lubbock(pxa25x), mainstone(pxa27x) and zylonite(pxa3xx)
boards.

I don't expect any breakage in PXA architecture. There might be issues with :
 - arch/arm/mach-pxa/capc7117.c
 - arch/arm/mach-pxa/viper.c
  -arch/arm/mach-pxa/zeus.c (very small probability for this one)
The mitigation plan if any concern arises is to fallback on the
CONFIG_SERIAL_PXA configuration.

I find a bit misleading this chunk, but I'm not very good at KConfig :
 config SERIAL_PXA
-   bool "PXA serial port support"
+   bool "PXA serial port support (DEPRECATED)"
depends on ARCH_PXA || ARCH_MMP
select SERIAL_CORE
+   select SERIAL_8250_PXA if SERIAL_8250=y
+   select SERIAL_PXA_NON8250 if !SERIAL_8250=y

What bothers me a bit is that selecting this option has a different effect
whether SERIAL_8250 is set or not. Somebody selecting the deprecated option
obviously wants the old driver, but will be provided the new one if his config
has SERIAL_8250 set. Maybe someone else can comment on this ...

This apart, from pxa perspective, it's good to go.

Cheers.

-- 
Robert
--
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: mm, vmstat: kernel BUG at mm/vmstat.c:1408!

[Christoph Lameter]

On Thu, 24 Dec 2015, Sasha Levin wrote:

> >> > [ 3462.527795]   pwq 4: cpus=2 node=2 flags=0x0 nice=0 active=1/256
> >> > [ 3462.554836] pending: vmstat_update
> > Does that mean that vmstat_update locks up or something that schedules it?
>
> I think it means that vmstat_update didn't finish running (working).

There is nothing in there that blocks.

> > Also what workload triggers the BUG()?
>
> Fuzzing with trinity inside a KVM guest. I've attached my config.

Ok will have a look.

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

Re: [PATCH RESEND] nvme:Fix error handling in the function nvme_init_integrity

[Keith Busch]

On Tue, Dec 29, 2015 at 01:10:48PM -0500, Nicholas Krause wrote:
> - blk_integrity_register(ns->disk, );
> + if (blk_integrity_register(ns->disk, )) {

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

Re: [PATCH RESEND] csiostor:Fix locking issues in the function csio_scsim_cleanup_io_lnode

[Jens Axboe]

On 12/29/2015 11:23 AM, Nicholas Krause wrote:

This fixes locking issues in the function csio_scsim_cleanup_io_lnode
by locking around the call to the function csio_csci_gather_active_ios
with the function pair spin_lock_irq/spin_unlock_irq as any function
calling this particular function must do in order to avoid concurrent
threads of execution on the passed structure pointer of type csio_hw
as this structure pointer can be shared across mutliple threads in the
kernel.

Signed-off-by: Nicholas Krause 
---
  drivers/scsi/csiostor/csio_scsi.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/csiostor/csio_scsi.c 
b/drivers/scsi/csiostor/csio_scsi.c
index 2c4562d..c318855 100644
--- a/drivers/scsi/csiostor/csio_scsi.c
+++ b/drivers/scsi/csiostor/csio_scsi.c
@@ -1327,7 +1327,9 @@ csio_scsim_cleanup_io_lnode(struct csio_scsim *scm, 
struct csio_lnode *ln)
sld.level = CSIO_LEV_LNODE;
sld.lnode = ln;
INIT_LIST_HEAD(>cmpl_q);
+   spin_lock_irq(>lock);
csio_scsi_gather_active_ios(scm, , >cmpl_q);
+   spin_unlock_irq(>lock);


All the callers grab that lock, you've just added a deadlock instead.

Nick, I've said this before and I'll say this again. Stop sending me 
patches. They are all untested and broken, you are wasting peoples time.


--
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] cx231xx: correctly handling failed allocation

[Devin Heitmueller]

On Tue, Dec 29, 2015 at 1:53 PM, Insu Yun  wrote:
> Since kmalloc can be failed in memory pressure,
> if not properly handled, NULL dereference can be happend
>
> Signed-off-by: Insu Yun 
> ---
>  drivers/media/usb/cx231xx/cx231xx-417.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c 
> b/drivers/media/usb/cx231xx/cx231xx-417.c
> index 47a98a2..9725e4f 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-417.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-417.c
> @@ -1382,6 +1382,8 @@ static int cx231xx_bulk_copy(struct cx231xx *dev, 
> struct urb *urb)
> buffer_size = urb->actual_length;
>
> buffer = kmalloc(buffer_size, GFP_ATOMIC);
> +   if (!buffer)
> +   return -ENOMEM;

A kmalloc() call inside a bulk handler running in softirq context?
That doesn't look right.

That said, I don't have any specific objection to the patch (which I'm
assuming came from some automated tool), but I suspect the cx231xx-417
code is probably completely broken.  The only device I've ever seen
that has the cx23102 and cx23417 is one of the Polaris EVKs, which
AFAIK nobody has ever shipped a production design based on.

Devin

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

RE: [PATCH 2/2] pci: Update VPD size with correct length

[Jordan_Hargrave]

>On Mon, Dec 28, 2015 at 9:29 PM,   wrote:
>> I had posted a patch recently to enable exposing the VPD-R valyes to sysfs.  
>> I need access
>> to these to parse into systemd for network naming (biosdevname style names).
>>
>>
>> The VPD-R is a readonly area contained within the PCI Vital Product
>> data.  There are some standard and vendor-specific keys stored in
>> this region.
>>
>> PN = Part Number
>> SN = Serial Number
>> MN = Manufacturer ID
>> Vx = Vendor-specific (x=0..9 A..Z)
>>
>> Biosdevname/Systemd will use these VPD keys for determining Network
>> partitioning and port numbers for NIC cards
>
>Can you please repost this as a patch instead of as a reply to our
>thread about VPD size.  The fact is the subject is misleading as your
>patch isn't actually related to VPD sizing.
>

I had already posted this a few weeks back but never got any feedback.

[PATCH] Create sysfs entries for VPD-R keys
https://marc.info/?l=linux-pci=144959803316031=2

>> Signed-off-by: Jordan Hargrave 
>> ---
>>  drivers/pci/pci-sysfs.c |  216 
>> +++
>>  include/linux/pci.h |2 +
>>  2 files changed, 218 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>> index eead54c..4966ece 100644
>> --- a/drivers/pci/pci-sysfs.c
>> +++ b/drivers/pci/pci-sysfs.c
>> @@ -1295,6 +1295,210 @@ static struct bin_attribute pcie_config_attr = {
>> .write = pci_write_config,
>>  };
>>
>> +static umode_t vpd_attr_exist(struct kobject *kobj,
>> + struct attribute *attr, int n)
>> +{
>> +   struct device *dev;
>> +   struct pci_dev *pdev;
>> +   const char *name;
>> +   int i;
>> +
>> +   dev = container_of(kobj, struct device, kobj);
>> +   pdev = to_pci_dev(dev);
>> +
>> +   name = attr->name;
>> +   if (pdev->vpdr_data == NULL)
>> +   return 0;
>> +   i = pci_vpd_find_info_keyword(pdev->vpdr_data, 0,
>> + pdev->vpdr_len, name);
>> +   return (i >= 0 ? S_IRUGO : 0);
>> +}
>> +
>
>So I assume there is another patch that implements
>pci_vpd_find_info_keyword so that it can go through the vpdr_data and
>parse it?
>

That's already an existing function in drivers/pci/vpd.c

>> +static ssize_t vpd_attr_show(struct device *dev,
>> +struct device_attribute *attr, char *buf)
>> +{
>> +   struct pci_dev *pdev;
>> +   const char *name;
>> +   char kv_data[257] = { 0 };
>> +   int i, len;
>> +
>> +   pdev = to_pci_dev(dev);
>> +   name = attr->attr.name;
>> +   if (pdev->vpdr_data == NULL)
>> +   return 0;
>> +   i = pci_vpd_find_info_keyword(pdev->vpdr_data, 0,
>> + pdev->vpdr_len, name);
>> +   if (i >= 0) {
>> +   len = pci_vpd_info_field_size(>vpdr_data[i]);
>> +   memcpy(kv_data, pdev->vpdr_data + i +
>> +  PCI_VPD_INFO_FLD_HDR_SIZE, len);
>> +   return scnprintf(buf, PAGE_SIZE, "%s\n", kv_data);
>> +   }
>> +   return 0;
>> +}
>> +
>> +#define VPD_ATTR_RO(x) \
>> +struct device_attribute vpd ## x = { \
>> +   .attr = { .name = #x, .mode = S_IRUGO | S_IWUSR }, \
>> +   .show = vpd_attr_show \
>> +}
>> +
>> +VPD_ATTR_RO(PN);
>> +VPD_ATTR_RO(EC);
>> +VPD_ATTR_RO(MN);
>> +VPD_ATTR_RO(SN);
>> +VPD_ATTR_RO(V0);
>> +VPD_ATTR_RO(V1);
>> +VPD_ATTR_RO(V2);
>> +VPD_ATTR_RO(V3);
>> +VPD_ATTR_RO(V4);
>> +VPD_ATTR_RO(V5);
>> +VPD_ATTR_RO(V6);
>> +VPD_ATTR_RO(V7);
>> +VPD_ATTR_RO(V8);
>> +VPD_ATTR_RO(V9);
>> +VPD_ATTR_RO(VA);
>> +VPD_ATTR_RO(VB);
>> +VPD_ATTR_RO(VC);
>> +VPD_ATTR_RO(VD);
>> +VPD_ATTR_RO(VE);
>> +VPD_ATTR_RO(VF);
>> +VPD_ATTR_RO(VG);
>> +VPD_ATTR_RO(VH);
>> +VPD_ATTR_RO(VI);
>> +VPD_ATTR_RO(VJ);
>> +VPD_ATTR_RO(VK);
>> +VPD_ATTR_RO(VL);
>> +VPD_ATTR_RO(VM);
>> +VPD_ATTR_RO(VN);
>> +VPD_ATTR_RO(VO);
>> +VPD_ATTR_RO(VP);
>> +VPD_ATTR_RO(VQ);
>> +VPD_ATTR_RO(VR);
>> +VPD_ATTR_RO(VS);
>> +VPD_ATTR_RO(VT);
>> +VPD_ATTR_RO(VU);
>> +VPD_ATTR_RO(VV);
>> +VPD_ATTR_RO(VW);
>> +VPD_ATTR_RO(VX);
>> +VPD_ATTR_RO(VY);
>> +VPD_ATTR_RO(VZ);
>> +
>> +static struct attribute *vpd_attributes[] = {
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   ,
>> +   NULL,
>> +};
>> +
>> +static struct attribute_group vpd_attr_group = {
>> +   .name = "vpdr",
>> +   .attrs = vpd_attributes,
>> +   .is_visible = vpd_attr_exist,
>> +};
>> +
>> +
>> 

Re: [PATCH] drivers/char/mem.c: Add /dev/ioports, supporting 16-bit and 32-bit ports

[Santosh Shukla]

On 29 December 2015 at 18:58, Arnd Bergmann  wrote:
> On Wednesday 23 December 2015 17:04:40 Santosh Shukla wrote:
>> On 23 December 2015 at 03:26, Arnd Bergmann  wrote:
>> > On Tuesday 22 December 2015, Santosh Shukla wrote:
>> >> }
>> >>
>> >> So I care for /dev/ioport types interface who could do more than byte
>> >> data copy to/from user-space. I tested this patch with little
>> >> modification and could able to run pmd driver for arm/arm64 case.
>> >>
>> >> Like to know how to address pci_io region mapping problem for
>> >> arm/arm64, in-case /dev/ioports approach is not acceptable or else I
>> >> can spent time on restructuring the patch?
>> >>
>> >
>> > For the use case you describe, can't you use the vfio framework to
>> > access the PCI BARs?
>> >
>>
>> I looked at file: drivers/vfio/pci/vfio_pci.c, func vfio_pci_map() and
>> it look to me that it only maps ioresource_mem pci region, pasting
>> code snap:
>>
>> if (!(pci_resource_flags(pdev, index) & IORESOURCE_MEM))
>> return -EINVAL;
>> 
>>
>> and I want to map ioresource_io pci region for arm platform in my
>> use-case. Not sure vfio maps pci_iobar region?
>
> Mapping I/O BARs is not portable, notably it doesn't work on x86.
>
> You should be able access them using the read/write interface on
> the vfio device.
>
Right, x86 doesn't care as iopl() could give userspace application
direct access to ioports.

Also, Alex in other dpdk thread [1] suggested someone to propose io
bar mapping in vfio-pci, I guess in particular to non-x86 arch so I
started working on it.

Thanks.

[1] http://dpdk.org/ml/archives/dev/2015-December/030852.html

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

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

[Pali Rohár]

On Tuesday 29 December 2015 13:44:13 Michał Kępień 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.
> > > 
> > > "Should" or "can"?  I skimmed through the ACPI-WMI PDF and
> > > Mario's message again and I couldn't find any explicit statement
> > > urging the reader to check the structure in question before
> > > doing anything else.
> > 
> > That's questionable... In "Design flow" is first point that WMI
> > descriptor check.
> 
> Which "Design flow" are you referring to?  Because I found at least
> two: chapter 2.3 and a subsection of chapter 2.3.3.  Funnily enough,
> in both of these locations the WMI Descriptor Method is discussed
> first.
> 
> Personally, I wouldn't use the structure of that document to draw
> cause-effect conclusions.  Just look at the last chapter (2.3.4),
> which shows how to tell whether the BIOS supports the ACPI-WMI
> interface. Shouldn't that be the first thing to check, before doing
> anything else mentioned in that document?  Yet, it's the last thing
> discussed.
> 
> Anyway, while the document mentions in several places that the BIOS
> WMI Descriptor object can be queried, it fails to convince me as to
> why this is necessary at all as all values in the returned buffer
> are constant. Perhaps parsing the buffer is useful as a sanity check
> of some kind, but it certainly isn't a prerequisite for performing
> further actions.
> 
> Given the nature of your patchset, I'd personally rephrase the commit
> message(s) to state that according to your observations, there are
> behavioral differences between models with different versions of the
> WMI Interface, so we parse the WMI Descriptor object to determine
> which WMI Interface version is used on the machine we're running on.
>  Perhaps with an additional word or two that it won't hurt to also
> check the WMI Descriptor object's correctness while we're at it.
> 
> If you feel like I'm nit-picking and none of the above matters,
> please feel free to disregard my input and just follow your gut.

It's ok. We just understand it quite differently. And in this case what 
about changing commit message to something like this?

===
dell-wmi: Check if Dell WMI descriptor structure is valid

After examining existing DSDT ACPI tables of more laptops and looking 
into Dell WMI document mentioned in ML dicussion archived at 
http://www.spinics.net/lists/platform-driver-x86/msg07220.html we will 
parse and check WMI descriptor if contains expected data. It is because 
WMI descriptor contains interface version number and it is needed to 
know in next commit.
===

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


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

Re: BUG: Bad rss-counter state mm:ffff8800c5a96000 idx:3 val:3894

[Michal Hocko]

[CCing Andrew]

On Thu 24-12-15 09:12:53, Jeremiah Mahler wrote:
> all,
> 
> I have started seeing a "Bad rss-counter" message in the logs with
> the latest linux-next 20151222+.
> 
>   [  458.282192] BUG: Bad rss-counter state mm:8800c5a96000 idx:3 val:3894

This is MM_SHMEMPAGES so an "unamapped" shmem memory. One possible
reason might be an unitialized zap_details used from unmap_mapping_range
during truncate introduced by "mm, oom: introduce oom reaper" from the
mmotm tree. There is a fix for this which is still pending
http://lkml.kernel.org/r/1450487091-7822-1-git-send-email-sasha.levin%40oracle.com
-- 
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 02/10] spi: cadence, zynq: use to_platform_device()

[Moritz Fischer]

Hi,

On Sun, Dec 27, 2015 at 5:15 AM, Geliang Tang  wrote:
> Use to_platform_device() instead of open-coding it.
>
Reviewed-by: Moritz Fischer 
> Signed-off-by: Geliang Tang 

Looks good to me, maybe (nit) split it up into two commits.

Cheers,

Moritz
--
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] net, socket, socket_wq: fix missing initialization of flags

[Eric Dumazet]

On Tue, 2015-12-29 at 13:29 +0100, Nicolai Stange wrote:
> Fixes: ceb5d58b2170 ("net: fix sock_wake_async() rcu protection")

>  Sorry for any inconvenience this late-night induced brainfart might
>  have caused at your side...

Not really, because I read the source code and saw the bug there ;)

Acked-by: Eric Dumazet 



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

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Bjorn Andersson]

On Tue 29 Dec 10:34 PST 2015, Rob Herring wrote:

> On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> > Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> > Signed-off-by: Bjorn Andersson 
> > ---
> >  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> > ++
> >  1 file changed, 76 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > new file mode 100644
> > index ..7b314b9f30af
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > @@ -0,0 +1,76 @@
> > +Qualcomm WCN36xx WiFi Binding
> > +
> > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware 
> > block
> > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> > variety
> > +of Qualcomm platforms.
> 
> Are BT/FM functions completely separate? If so, separate bindings are 
> okay. If not, then we need to describe the full chip.
> 

It's three different hardware blocks (WiFi, BT and FM-radio) with shared
RF-hardware and an ARM core for control logic.

There seems to be some control commands going towards the BT part that
controls coexistence properties of the RF-hardware, but other than that
I see it as logically separate blocks.


So I think it's fine to model this as separate pieces in DT.

Regards,
Bjorn
--
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] drivers/char/mem.c: Add /dev/ioports, supporting 16-bit and 32-bit ports

[Arnd Bergmann]

On Tuesday 29 December 2015 21:25:15 Santosh Shukla wrote:
> mistakenly added wrong email-id of alex, looping his correct one.
> 
> On 29 December 2015 at 21:23, Santosh Shukla  
> wrote:
> > On 29 December 2015 at 18:58, Arnd Bergmann  wrote:
> >> On Wednesday 23 December 2015 17:04:40 Santosh Shukla wrote:
> >>> On 23 December 2015 at 03:26, Arnd Bergmann  wrote:
> >>> > On Tuesday 22 December 2015, Santosh Shukla wrote:
> >>> >> }
> >>> >>
> >>> >> So I care for /dev/ioport types interface who could do more than byte
> >>> >> data copy to/from user-space. I tested this patch with little
> >>> >> modification and could able to run pmd driver for arm/arm64 case.
> >>> >>
> >>> >> Like to know how to address pci_io region mapping problem for
> >>> >> arm/arm64, in-case /dev/ioports approach is not acceptable or else I
> >>> >> can spent time on restructuring the patch?
> >>> >>
> >>> >
> >>> > For the use case you describe, can't you use the vfio framework to
> >>> > access the PCI BARs?
> >>> >
> >>>
> >>> I looked at file: drivers/vfio/pci/vfio_pci.c, func vfio_pci_map() and
> >>> it look to me that it only maps ioresource_mem pci region, pasting
> >>> code snap:
> >>>
> >>> if (!(pci_resource_flags(pdev, index) & IORESOURCE_MEM))
> >>> return -EINVAL;
> >>> 
> >>>
> >>> and I want to map ioresource_io pci region for arm platform in my
> >>> use-case. Not sure vfio maps pci_iobar region?
> >>
> >> Mapping I/O BARs is not portable, notably it doesn't work on x86.
> >>
> >> You should be able access them using the read/write interface on
> >> the vfio device.
> >>
> > Right, x86 doesn't care as iopl() could give userspace application
> > direct access to ioports.
> >
> > Also, Alex in other dpdk thread [1] suggested someone to propose io
> > bar mapping in vfio-pci, I guess in particular to non-x86 arch so I
> > started working on it.
> >
> 

So what's wrong with just using the existing read/write API on all
architectures?

Arnd
--
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/3] OOM detection rework v4

[Michal Hocko]

On Thu 24-12-15 21:41:19, Tetsuo Handa wrote:
> I got OOM killers while running heavy disk I/O (extracting kernel source,
> running lxr's genxref command). (Environ: 4 CPUs / 2048MB RAM / no swap / XFS)
> Do you think these OOM killers reasonable? Too weak against fragmentation?

I will have a look at the oom report more closely early next week (I am
still in holiday mode) but it would be good to compare how the same load
behaves with the original implementation. It would be also interesting
to see how stable are the results (is there any variability in multiple
runs?).

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] cfq-iosched: convert slice idle time to jiffies

[Jens Axboe]

On 12/28/2015 06:08 PM, Alexandru Moise wrote:

This patch refers to Jens Axboe's change way back in 2006:
7b14e3b52 cfq-iosched: slice expiry fixups

In this patch he fixed a potential timer race condition by delaying
idle_slice_timer by the slice_idle time value.

Today this timer is delayed by either slice_idle or group_idle time
values, which on my system, and according to
Documentation/block/cfq-iosched.txt the default value for both is 8ms.

Since the time given by either variables is supposed to be in
milliseconds we should convert that value from milliseconds to jiffies
before adding it to jiffies variable and setting our timer.

In my obervations the area is really active as I've seen that function
get called a lot for each device on my btrfs raid setup during btrfs
check. I've also timed the btrfs check before and after applying the
patch and I might've noticed a very slight improvement in execution
time but the numbers vary too much for me to post any believable
numbers (10 milliseconds difference at most on average).


cfqd->cfq_slice_idle is in jiffies, it's not in msecs.

--
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 v2 1/4] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Rob Herring]

On Thu, Dec 24, 2015 at 07:01:00PM +0800, Yuan Yao wrote:
> new compatible string: "fsl,ls2080a-qspi".
> 
> Signed-off-by: Yuan Yao 
> ---
> Changed in v2:
> Update my email to 
> ---
>  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt 
> b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> index fa77f87..2fe51d6 100644
> --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> @@ -1,7 +1,8 @@
>  ARM Freescale DSPI controller
>  
>  Required properties:
> -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", "fsl,ls2085a-dspi"
> +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> + "fsl,ls2085a-dspi", "fsl,ls2080a-dspi"

You should explain what combinations of compatible strings are valid.

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