Re: x86_64: MAX_LOCAL_APIC way too big?

[Denys Vlasenko]

On 09/25/2015 06:56 PM, Jiang Liu wrote:
> On 2015/9/26 0:16, Denys Vlasenko wrote:
>> 32 thousand APICs? That's a lot. Especially
>> considering that event with CONFIG_MAXSMP=y,
>> NR_CPUS is "only" 8096.
>>
>> After a quick glance through code, it looks like
>> such a big value causes several data arrays to be
>> quite oversized:
>>
>> phys_cpu_present_map is 4 kbytes (one bit per apicid)
>> __apicid_to_node is 64 kbytes
>> apic_version is 128 kbytes (!!!)
>>
...
>> Maybe we can reduce MAX_LOCAL_APIC?
>> Why it has to be this big in the first place?
>>
>> IIRC: APIC id at first was just a 8-bit quantity,
>> then x2apic mode it was extended to 32 bits.
>>
>> On "usual" systems, apic ids simply go from zero
>> to maximum logical CPU number, mirroring CPU ids.


> Hi Denys,
>   The above assumption is risky with modern
> x86 platforms. APIC ids are assigned by firmware,
> and may be discrete.


I guess it means a new CONFIG option will be needed then,
for such machines. I'll send an RFC patch now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

[Rafael J. Wysocki]

On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote:
> On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> 
> > We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag,
> > but it isn't very useful, so I'd prefer to replace it with a "no remote 
> > wakeup"
> > bit in struct dev_pm_info or something similar).
> > 
> > That is actually quite important, because (a) we can save energy but not
> > configuring the device to do remote wakeup in the first place and (b) that
> > may involve more than just the driver (for example, disabling PCI or ACPI
> > remote wakeup involves the bus type or similar).
> > 
> > So it looks like we need to be able to distinguish between "runtime suspend
> > with remote wakeup" and "runtime suspend without remote wakeup".
> > 
> > And if we do the latter, we may not even need the "inhibit" thing any more,
> > because suspended devices without that are not configured to do remote 
> > wakeup
> > cannot really signal anything in the majority of cases.
> 
> That works only for drivers that use autosuspend to go to low power in
> between events.  It doesn't work for drivers that remain at full power 
> as long as the device file is open.  That kind of driver does require 
> an "inhibit" interface.

Or an interface allowing user space to trigger pm_request_idle() for them.

So user space would change the "no remote wakeup" setting and then do the
"try to suspend now" thing.

Thanks,
Rafael

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

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[Rafael J. Wysocki]

On Friday, September 25, 2015 10:18:13 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> > for big endian 64 bit systems. There are no such platforms yet, but the
> > code needs to be robust for such a case.
> > 
> > Fix that by passing a local variable to debugfs_create_bool() and
> > assigning its value to global_lock later.
> > 
> > Signed-off-by: Viresh Kumar 
> 
> Acked-by: Rafael J. Wysocki 
> 
> Greg, please take this one if the [2/2] looks good to you.

Ouch, turns out it was a bad idea.  Please scratch that.

Thanks,
Rafael

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

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[Johannes Berg]

> Rafael wrote:
> > Actually, what about adding a local u32 variable, say val, here and 
> > doing
> > 
> > >   if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 
> > > *)_ec->gpe))
> > >   goto error;
> > >   if (!debugfs_create_bool("use_global_lock", 0444, 
> > > dev_dir,
> > > -  (u32 *)_ec->global_lock))
> > > +  _ec->global_lock))
> > 
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, 
> > ))
> > 
> > >   goto error;
> > 
> > first_ec->global_lock = val;
> > 
> > And then you can turn val into bool just fine without changing the 
> > structure
> > definition.

Ok, then, but that means Rafael is completely wrong ...
debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
it can't be on the stack. You also don't get a call when it changes.

If you cannot change the struct definition then you must implement a
debugfs file with its own read/write handlers.

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

[PATCH] gpio: omap: fix static checker warning

[Grygorii Strashko]

This patch fixes below static checker warning by changing
type of irq field in struct gpio_bank from u16 to int.

drivers/gpio/gpio-omap.c:1191 omap_gpio_probe()
warn: assigning (-6) to unsigned variable 'bank->irq'

drivers/gpio/gpio-omap.c
  1188  bank->irq = platform_get_irq(pdev, 0);
  1189  if (bank->irq <= 0) {

bank->irq is u16.

  1190  if (!bank->irq)
  1191  bank->irq = -ENXIO;

Does not work.

  1192  if (bank->irq != -EPROBE_DEFER)

Does not work.

  1193  dev_err(dev,
  1194  "can't get irq resource ret=%d\n", 
bank->irq);
  1195  return bank->irq;
  1196  }

Fixes: commit 89d18e3af8b9: "gpio: omap: switch to use platform_get_irq"
Signed-off-by: Grygorii Strashko 
---
 drivers/gpio/gpio-omap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 376827f..56d2d02 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -51,7 +51,7 @@ struct gpio_regs {
 struct gpio_bank {
struct list_head node;
void __iomem *base;
-   u16 irq;
+   int irq;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
-- 
2.5.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] Clk: tegra: Use module_platform_driver

[Shraddha Barke]

Use module_platform_driver for drivers whose init and exit functions
only register and unregister, respectively.

Coccinelle patch used-

@a@
identifier f, x;
@@
-static f(...) { return platform_driver_register(); }

@b depends on a@
identifier e, a.x;
@@
-static e(...) { platform_driver_unregister(); }

@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);

@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_platform_driver;
@@
-module_exit(e);
+module_platform_driver(x);

Signed-off-by: Shraddha Barke 
---
 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c 
b/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
index 6125333..88b4ef4 100644
--- a/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
+++ b/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
@@ -147,18 +147,7 @@ static struct platform_driver tegra124_dfll_fcpu_driver = {
.pm = _dfll_pm_ops,
},
 };
-
-static int __init tegra124_dfll_fcpu_init(void)
-{
-   return platform_driver_register(_dfll_fcpu_driver);
-}
-module_init(tegra124_dfll_fcpu_init);
-
-static void __exit tegra124_dfll_fcpu_exit(void)
-{
-   platform_driver_unregister(_dfll_fcpu_driver);
-}
-module_exit(tegra124_dfll_fcpu_exit);
+module_platform_driver(tegra124_dfll_fcpu_driver);
 
 MODULE_DESCRIPTION("Tegra124 DFLL clock source driver");
 MODULE_LICENSE("GPL v2");
-- 
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/16] page-flags: introduce page flags policies wrt compound pages

[Kirill A. Shutemov]

On Fri, Sep 25, 2015 at 03:29:17PM +0300, Konstantin Khlebnikov wrote:
> On 24.09.2015 17:50, Kirill A. Shutemov wrote:
> >This patch adds a third argument to macros which create function
> >definitions for page flags.  This argument defines how page-flags helpers
> >behave on compound functions.
> >
> >For now we define four policies:
> >
> >- PF_ANY: the helper function operates on the page it gets, regardless
> >   if it's non-compound, head or tail.
> >
> >- PF_HEAD: the helper function operates on the head page of the compound
> >   page if it gets tail page.
> >
> >- PF_NO_TAIL: only head and non-compond pages are acceptable for this
> >   helper function.
> >
> >- PF_NO_COMPOUND: only non-compound pages are acceptable for this helper
> >   function.
> >
> >For now we use policy PF_ANY for all helpers, which matches current
> >behaviour.
> >
> >We do not enforce the policy for TESTPAGEFLAG, because we have flags
> >checked for random pages all over the kernel.  Noticeable exception to
> >this is PageTransHuge() which triggers VM_BUG_ON() for tail page.
> >
> >Signed-off-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com>
> >---
> >  include/linux/page-flags.h | 154 
> > ++---
> >  1 file changed, 90 insertions(+), 64 deletions(-)
> >
> >diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> >index 713d3f2c2468..1b3babe5ff69 100644
> >--- a/include/linux/page-flags.h
> >+++ b/include/linux/page-flags.h
> >@@ -154,49 +154,68 @@ static inline int PageCompound(struct page *page)
> > return test_bit(PG_head, >flags) || PageTail(page);
> >  }
> >
> >+/* Page flags policies wrt compound pages */
> >+#define PF_ANY(page, enforce)   page
> >+#define PF_HEAD(page, enforce)  compound_head(page)
> >+#define PF_NO_TAIL(page, enforce) ({
> >\
> >+if (enforce)\
> >+VM_BUG_ON_PAGE(PageTail(page), page);   \
> >+else\
> >+page = compound_head(page); \
> >+page;})
> >+#define PF_NO_COMPOUND(page, enforce) ({
> >\
> >+if (enforce)\
> >+VM_BUG_ON_PAGE(PageCompound(page), page);   \
> 
> Linux next-20150925 crashes here (at least in lkvm)
> if CONFIG_DEFERRED_STRUCT_PAGE_INIT=y

Hm. I don't see the crash in qemu. Could you share your config?

> [0.00] Kernel command line: noapic noacpi pci=conf1 reboot=k panic=1
> i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 console=ttyS0
> earlyprintk=serial i8042.noaux=1  root=/dev/root rw
> rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p init=/virt/init
> ip=dhcp
> [0.00] PID hash table entries: 2048 (order: 2, 16384 bytes)
> [0.00] BUG: unable to handle kernel NULL pointer dereference at
> 000c
> [0.00] IP: [] dump_page_badflags+0x2b/0xe0
> [0.00] PGD 0
> [0.00] Oops:  [#1] SMP
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.3.0-rc2-next-20150925+ #2
> [0.00] task: 81c12580 ti: 81c0 task.ti:
> 81c0
> [0.00] RIP: 0010:[]  []
> dump_page_badflags+0x2b/0xe0
> [0.00] RSP: :81c03ea8  EFLAGS: 00010002
> [0.00] RAX: 000c RBX: ea6dfd40 RCX:
> 0100
> [0.00] RDX: 0001 RSI: 81a4aeb8 RDI:
> ea6dfd40
> [0.00] RBP: 81c03ec0 R08:  R09:
> 
> [0.00] R10: 0001 R11:  R12:
> 
> [0.00] R13: 0001b7f7 R14: 81fe50c0 R15:
> 81c03fb0
> [0.00] FS:  () GS:88001a40()
> knlGS:
> [0.00] CS:  0010 DS:  ES:  CR0: 80050033
> [0.00] CR2: 000c CR3: 01c0b000 CR4:
> 000406b0
> [0.00] DR0:  DR1:  DR2:
> 
> [0.00] DR3:  DR6: fffe0ff0 DR7:
> 0400
> [0.00] Stack:
> [0.00]  0001b7f5 ea6dfd40 0001b7f7
> 81c03ed0
> [0.00]  811aabc0 81c03ef8 81785eda
> 81c

[PATCH V2 2/3] RAS, mce_amd_inj: Add capability to trigger apic interrupts

[Aravind Gopalakrishnan]

With this extension to the flags attribute, deferred error interrupts
and threshold interrupts can be triggered to test the apic interrupt
handler functionality for these type of errors

Update README section about the same too.

Signed-off-by: Aravind Gopalakrishnan 
---
 arch/x86/ras/mce_amd_inj.c | 44 +++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/arch/x86/ras/mce_amd_inj.c b/arch/x86/ras/mce_amd_inj.c
index 4fd8bb9..794ca1f 100644
--- a/arch/x86/ras/mce_amd_inj.c
+++ b/arch/x86/ras/mce_amd_inj.c
@@ -34,12 +34,16 @@ static u8 n_banks;
 enum injection_type {
SW_INJ = 0, /* SW injection, simply decode the error */
HW_INJ, /* Trigger a #MC */
+   DFR_INT_INJ,/* Trigger Deferred error interrupt */
+   THR_INT_INJ,/* Trigger threshold interrupt */
N_INJ_TYPES,
 };
 
 static const char * const flags_options[] = {
[SW_INJ] = "sw",
[HW_INJ] = "hw",
+   [DFR_INT_INJ] = "df",
+   [THR_INT_INJ] = "th",
NULL
 };
 
@@ -182,6 +186,16 @@ static void trigger_mce(void *info)
asm volatile("int $18");
 }
 
+static void trigger_dfr_int(void *info)
+{
+   asm volatile("int %0" :: "i" (DEFERRED_ERROR_VECTOR));
+}
+
+static void trigger_thr_int(void *info)
+{
+   asm volatile("int %0" :: "i" (THRESHOLD_APIC_VECTOR));
+}
+
 static void do_inject(void)
 {
u64 mcg_status = 0;
@@ -202,6 +216,20 @@ static void do_inject(void)
if (!(i_mce.status & MCI_STATUS_PCC))
mcg_status |= MCG_STATUS_RIPV;
 
+   if (inj_type == DFR_INT_INJ) {
+   /*
+* Ensure necessary status bits for deferred errors:
+* a. MCx_STATUS[Deferred] is set -
+*This is to ensure the error will be handled by the
+*interrupt handler
+* b. unset MCx_STATUS[UC]
+*As deferred errors are _not_ UC
+*/
+
+   i_mce.status |= MCI_STATUS_DEFERRED;
+   i_mce.status |= (i_mce.status & ~MCI_STATUS_UC);
+   }
+
get_online_cpus();
if (!cpu_online(cpu))
goto err;
@@ -222,7 +250,16 @@ static void do_inject(void)
 
toggle_hw_mce_inject(cpu, false);
 
-   smp_call_function_single(cpu, trigger_mce, NULL, 0);
+   switch (inj_type) {
+   case DFR_INT_INJ:
+   smp_call_function_single(cpu, trigger_dfr_int, NULL, 0);
+   break;
+   case THR_INT_INJ:
+   smp_call_function_single(cpu, trigger_thr_int, NULL, 0);
+   break;
+   default:
+   smp_call_function_single(cpu, trigger_mce, NULL, 0);
+   }
 
 err:
put_online_cpus();
@@ -287,6 +324,11 @@ static const char readme_msg[] =
 "\thandle the error. Be warned: might cause system panic if 
MCi_STATUS[PCC] \n"
 "\tis set. Therefore, consider setting (debugfs_mountpoint)/mce/fake_panic 
\n"
 "\tbefore injecting.\n"
+"\t  - \"df\": Trigger APIC interrupt for Deferred error. Causes deferred \n"
+"\terror APIC interrupt handler to handle the error if the feature is \n"
+"\tis present in hardware. \n"
+"\t  - \"th\": Trigger APIC interrupt for Threshold errors. Causes threshold 
\n"
+"\tAPIC interrupt handler to handle the error. \n"
 "\n";
 
 static ssize_t
-- 
2.4.0

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

Re: [PATCH] xen/pvhvm: add soft reset on kexec/kdump support

[Boris Ostrovsky]

On 09/25/2015 03:01 PM, Konrad Rzeszutek Wilk wrote:

On Fri, Sep 25, 2015 at 01:17:40PM -0400, Boris Ostrovsky wrote:

On 09/25/2015 12:07 PM, Vitaly Kuznetsov wrote:

Also, I am not sure I see how this new op will be used in the
hypervisor --- currently AFAICS it is only processed under
is_hardware_domain(). Are there other patches that will support HVM
guests?

Please see my Xen series:
http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg00547.html
(last 'full' submission).

All patches from my 'toolstack-assisted approach to PVHVM guest kexec'
are already merged to xen.git (first 10 are already in 'master' and the
last one is in 'staging').



OK, so I was looking at the right tree. Then I don't understand how
SHUTDOWN_soft_reset would be reached for a non-privileged domain. The only
path that I see is

 domain_shutdown()
 {
 ...
 if ( is_hardware_domain(d) )
 hwdom_shutdown(reason);
 ...
 }

Is there another path to handle this op?

Yes:
  e1bd9812966de9a16f30a58e7162b80bd6af361b libxc: support XEN_DOMCTL_soft_reset 
operation
and
  c57e6ebd8c3e490e353e68d96abec1dad01e72f5 (lib)xl: soft reset support




That's toolstack issuing hypercalls from dom0.

I am asking about (non-privileged) guest itself calling SCHEDOP_shutdown.

-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/10] mm, page_alloc: Reserve pageblocks for high-order atomic allocations on demand

[Johannes Weiner]

On Mon, Sep 21, 2015 at 11:52:41AM +0100, Mel Gorman wrote:
> High-order watermark checking exists for two reasons --  kswapd high-order
> awareness and protection for high-order atomic requests. Historically the
> kernel depended on MIGRATE_RESERVE to preserve min_free_kbytes as high-order
> free pages for as long as possible. This patch introduces MIGRATE_HIGHATOMIC
> that reserves pageblocks for high-order atomic allocations on demand and
> avoids using those blocks for order-0 allocations. This is more flexible
> and reliable than MIGRATE_RESERVE was.
> 
> A MIGRATE_HIGHORDER pageblock is created when an atomic high-order allocation
> request steals a pageblock but limits the total number to 1% of the zone.
> Callers that speculatively abuse atomic allocations for long-lived
> high-order allocations to access the reserve will quickly fail. Note that
> SLUB is currently not such an abuser as it reclaims at least once.  It is
> possible that the pageblock stolen has few suitable high-order pages and
> will need to steal again in the near future but there would need to be
> strong justification to search all pageblocks for an ideal candidate.
> 
> The pageblocks are unreserved if an allocation fails after a direct
> reclaim attempt.
> 
> The watermark checks account for the reserved pageblocks when the allocation
> request is not a high-order atomic allocation.
> 
> The reserved pageblocks can not be used for order-0 allocations. This may
> allow temporary wastage until a failed reclaim reassigns the pageblock. This
> is deliberate as the intent of the reservation is to satisfy a limited
> number of atomic high-order short-lived requests if the system requires them.
> 
> The stutter benchmark was used to evaluate this but while it was running
> there was a systemtap script that randomly allocated between 1 high-order
> page and 12.5% of memory's worth of order-3 pages using GFP_ATOMIC. This
> is much larger than the potential reserve and it does not attempt to be
> realistic.  It is intended to stress random high-order allocations from
> an unknown source, show that there is a reduction in failures without
> introducing an anomaly where atomic allocations are more reliable than
> regular allocations.  The amount of memory reserved varied throughout the
> workload as reserves were created and reclaimed under memory pressure. The
> allocation failures once the workload warmed up were as follows;
> 
> 4.2-rc5-vanilla   70%
> 4.2-rc5-atomic-reserve56%
> 
> The failure rate was also measured while building multiple kernels. The
> failure rate was 14% but is 6% with this patch applied.
> 
> Overall, this is a small reduction but the reserves are small relative
> to the number of allocation requests. In early versions of the patch,
> the failure rate reduced by a much larger amount but that required much
> larger reserves and perversely made atomic allocations seem more reliable
> than regular allocations.
> 
> Signed-off-by: Mel Gorman 
> Acked-by: Vlastimil Babka 

Cool, this is much more obvious than trusting the MIGRATE_RESERVE
mechanism for higher order atomics.

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

[PATCH 0/2] convert to use generic irq handler

[Grygorii Strashko]

This patch series contains patches which fixes wrong APIs usage in atomic
context on RT-kernel. The final goal is to make TI OMAP GPIO driver
compatible with -RT kernel as much as possible.

Patch 1: required to be compatible with -RT kernel, because PM runtime's
irq_safe mode is incompatible with -RT.
Patch 2: This patch converts TI OMAP GPIO driver to use generic irq
 handler instead of chained IRQ handler. This way OMAP GPIO driver will be
 compatible with RT-kernel where it will be forced thread IRQ handler
 while in non-RT kernel it still will be executed in HW IRQ context.

Boot, basic gpio functionality tested on:
 dra7-evm, BeagleBone(white), am43xx-gpevm, am437x-sk
Manually tested on dra7-evm including suspend/resume and wakeup.

Links on RFC:
 https://lkml.org/lkml/2015/8/18/161
 https://lkml.org/lkml/2015/8/18/162

Grygorii Strashko (2):
  gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock
  gpio: omap: convert to use generic irq handler

 drivers/gpio/gpio-omap.c | 80 +---
 1 file changed, 42 insertions(+), 38 deletions(-)

-- 
2.5.1

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

[PATCH 2/2] gpio: omap: convert to use generic irq handler

[Grygorii Strashko]

This patch converts TI OMAP GPIO driver to use generic irq handler
instead of chained IRQ handler. This way OMAP GPIO driver will be
compatible with RT kernel where it will be forced thread IRQ handler
while in non-RT kernel it still will be executed in HW IRQ context.
As part of this change the IRQ wakeup configuration is applied to
GPIO Bank IRQ as it now will be under control of IRQ PM Core during
suspend.

There are also additional benefits:
 - on-RT kernel there will be no complains any more about PM runtime usage
   in atomic context  "BUG: sleeping function called from invalid context";
 - GPIO bank IRQs will appear in /proc/interrupts and its usage statistic
will be  visible;
 - GPIO bank IRQs could be configured through IRQ proc_fs interface and,
   as result, could be a part of IRQ balancing process if needed;
 - GPIO bank IRQs will be under control of IRQ PM Core during
   suspend to RAM.

Disadvantage:
 - additional runtime overhed as call chain till
   omap_gpio_irq_handler() will be longer now
 - necessity to use wa_lock in omap_gpio_irq_handler() to W/A warning
   in handle_irq_event_percpu()
   WARNING: CPU: 1 PID: 35 at kernel/irq/handle.c:149 
handle_irq_event_percpu+0x51c/0x638()

This patch doesn't fully follows recommendations provided by Sebastian
Andrzej Siewior [1], because It's required to go through and check all
GPIO IRQ pin states as fast as possible and pass control to handle_level_irq
or handle_edge_irq. handle_level_irq or handle_edge_irq will perform actions
specific for IRQ triggering type and wakeup corresponding registered
threaded IRQ handler (at least it's expected to be threaded).
IRQs can be lost if handle_nested_irq() will be used, because excecution
time of some pin specific GPIO IRQ handler can be very significant and
require accessing ext. devices (I2C).

Idea of such kind reworking was also discussed in [2].

[1] http://www.spinics.net/lists/linux-omap/msg120665.html
[2] http://www.spinics.net/lists/linux-omap/msg119516.html

Tested-by: Tony Lindgren 
Tested-by: Austin Schuh 
Signed-off-by: Grygorii Strashko 
---
 drivers/gpio/gpio-omap.c | 55 
 1 file changed, 27 insertions(+), 28 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a254691..376827f 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -59,6 +59,7 @@ struct gpio_bank {
u32 level_mask;
u32 toggle_mask;
raw_spinlock_t lock;
+   raw_spinlock_t wa_lock;
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
@@ -649,8 +650,13 @@ static int omap_gpio_wake_enable(struct irq_data *d, 
unsigned int enable)
 {
struct gpio_bank *bank = omap_irq_data_get_bank(d);
unsigned offset = d->hwirq;
+   int ret;
+
+   ret = omap_set_gpio_wakeup(bank, offset, enable);
+   if (!ret)
+   ret = irq_set_irq_wake(bank->irq, enable);
 
-   return omap_set_gpio_wakeup(bank, offset, enable);
+   return ret;
 }
 
 static int omap_gpio_request(struct gpio_chip *chip, unsigned offset)
@@ -704,26 +710,21 @@ static void omap_gpio_free(struct gpio_chip *chip, 
unsigned offset)
  * line's interrupt handler has been run, we may miss some nested
  * interrupts.
  */
-static void omap_gpio_irq_handler(struct irq_desc *desc)
+static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
 {
void __iomem *isr_reg = NULL;
u32 isr;
unsigned int bit;
-   struct gpio_bank *bank;
-   int unmasked = 0;
-   struct irq_chip *irqchip = irq_desc_get_chip(desc);
-   struct gpio_chip *chip = irq_desc_get_handler_data(desc);
+   struct gpio_bank *bank = gpiobank;
+   unsigned long wa_lock_flags;
unsigned long lock_flags;
 
-   chained_irq_enter(irqchip, desc);
-
-   bank = container_of(chip, struct gpio_bank, chip);
isr_reg = bank->base + bank->regs->irqstatus;
-   pm_runtime_get_sync(bank->dev);
-
if (WARN_ON(!isr_reg))
goto exit;
 
+   pm_runtime_get_sync(bank->dev);
+
while (1) {
u32 isr_saved, level_mask = 0;
u32 enabled;
@@ -745,13 +746,6 @@ static void omap_gpio_irq_handler(struct irq_desc *desc)
 
raw_spin_unlock_irqrestore(>lock, lock_flags);
 
-   /* if there is only edge sensitive GPIO pin interrupts
-   configured, we could unmask GPIO bank interrupt immediately */
-   if (!level_mask && !unmasked) {
-   unmasked = 1;
-   chained_irq_exit(irqchip, desc);
-   }
-
if (!isr)
break;
 
@@ -772,18 +766,18 @@ static void omap_gpio_irq_handler(struct irq_desc *desc)
 
raw_spin_unlock_irqrestore(>lock, lock_flags);
 
+   

[PATCHv4 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.

[Enric Balletbo i Serra]

The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.

You can add support to your board with current binding.

Example:

anx7814: anx7814@38 {
compatible = "analogix,anx7814";
reg = <0x38>;
pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
};

Signed-off-by: Enric Balletbo i Serra 
---
 .../devicetree/bindings/video/bridge/anx7814.txt   | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt

diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt 
b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
new file mode 100644
index 000..a8cc746
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
@@ -0,0 +1,22 @@
+Analogix ANX7814 SlimPort (Full-HD Transmitter)
+---
+
+The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
+designed for portable devices.
+
+Required properties:
+
+ - compatible  : "analogix,anx7814"
+ - reg : I2C address of the device
+ - pd-gpios: Which GPIO to use for power down
+ - reset-gpios : Which GPIO to use for reset
+
+Example:
+
+   anx7814: anx7814@38 {
+   compatible = "analogix,anx7814";
+   reg = <0x38>;
+   pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   };
+
-- 
2.1.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/

[PATCHv4 0/3] Add initial support for slimport anx78xx

[Enric Balletbo i Serra]

Hi all,

This is the fouth version with fixes suggested by Nicolas Boichat and Dan 
Carpenter.

See the changelog below for details.

The following series add initial support for the Slimport ANX7814 transmitter, a
ultra-low power Full-HD (1080p60) transmitter designed for portable device.

The driver was originally created and based from the work of Junhua Xia from
Analogix. This driver is a refactor of the original driver and fixes different
coding style lines, and different errors/warnings reported by checkpatch. Also
there were things that I noticed that we need to change like:

 - Convert the numbered GPIO API to the new descriptor based GPIO API.
 - Review the DT binding
 - Add missing MODULE_DEVICE_TABLE(of, ...);
 - Fix Makefiles and Kconfig to build conditionally.
 - Use SIMPLE_DEV_PM_OPS() instead of the deprecated i2c .suspend and
  .resume callbacks.
 - Move to use managed device resources.
 - Remove dead/unused code.
 - And others ...

Changes since v3:

Nicolas Boichat: 
 - Integrate sp_edid_header_result with sp_check_edid_data
 - Fix loop forever.
 - Use meaningful messages and variable names
 - Replace some 'while' loops and use a for loop.
 - Might be clearer to say >= LINK_6P75G
 - Convert a function to void function because always return 0
 - Remove some magic numbers and refactor sp_tx_pclk_calc
 - Replace sp_read_reg(SP_TX_LINK_BW_SET_REG) for sp_tx_get_link_bw.
 - Mask bits 4:0. Bit 5 has another purpose, and 7:6 are reserved.
 - Use ARRAY_SIZE.
 - Use memset for initialization.
 - Simply condition if (!(c1 & POLLING_EN) || (c & POLLING_ERR))
 - Don not use a temporal variable write the value directly.
 - Fix various typos
 - Return directly PTR_ERR.

Dan Carpenter: 
 - Refactor while loop removing the earlier condition and do while (--c) instead
 - Simplify double negative and fix alignment
 - Remove the superflous casts to u16 and parens
 - Remove debug printks and use ftrace instead.
 - Flip this condition around and pull the code in one indent level.
 - Fix return value 'ret' that should be an int. It causes a signedness bug 
later.
 - Use better style for devm_kzalloc
 - Get rid of AUX_*.  They aren't used much and we could easily use normal 
error codes instead.

Enric Balletbo
 - Fix errors reported by scripts/checkpatch.pl --strict --subjective
 - Remove XTAL_CLK_M10 XTAL_CLK definitions
 - replace ulong for unsigned long
 - remove some magic numbers and refactor sp_tx_enable_audio_output
 - remove some magic numbers and refactor sp_tx_phy_auto_test

Changes since v2 (requested by Daniel Kurtz):
 - clean up the typos, and little nits requested by Dan.
 - move to the drm/bridge directory
 - rename the files, variables, types, etc. to anx78xx
 - plumb through the context struct to all functions that act on the device
 - use proper messaging (dev_ rather than pr_, _dbg/_err rather than _info)

Changes since v1:
 - As requested by Greg, move from staging to a subsystem.

Best regards,

Enric Balletbo i Serra (3):
  of: Add vendor prefix for Analogix Semiconductor, Inc.
  devicetree: Add new ANX7814 SlimPort transmitter binding.
  drm: bridge: anx78xx: Add anx78xx driver support by analogix.

 .../devicetree/bindings/vendor-prefixes.txt|1 +
 .../devicetree/bindings/video/bridge/anx7814.txt   |   22 +
 drivers/gpu/drm/bridge/Kconfig |2 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/anx78xx/Kconfig |7 +
 drivers/gpu/drm/bridge/anx78xx/Makefile|4 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx.h   |   41 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c  |  228 ++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c   | 3148 
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h   |  214 ++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h   |  807 +
 11 files changed, 4475 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Makefile
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h

-- 
2.1.0

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

Re: [PATCH net-next] net: remove unused argument of __netdev_find_adj()

[David Miller]

From: Michal Kubecek 
Date: Thu, 24 Sep 2015 10:59:05 +0200 (CEST)

> The __netdev_find_adj() helper does not use its first argument, only the
> device to find and list to walk through.
> 
> Signed-off-by: Michal Kubecek 

Applied, 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: [v3 2/8] dpaa_eth: add support for DPAA Ethernet

[David Miller]

From: Madalin Bucur 
Date: Thu, 24 Sep 2015 18:00:13 +0300

> +#define DPA_NAPI_WEIGHT  64

This is just the default, so simply use "NAPI_POLL_WEIGHT" rather
than defining your own macro unnecessarily for this.

> +static int dpa_eth_priv_stop(struct net_device *net_dev)
> +{
> + int err;
> + struct dpa_priv_s *priv;
> +
> + err = dpa_stop(net_dev);
> + /* Allow NAPI to consume any frame still in the Rx/TxConfirm
> +  * ingress queues. This is to avoid a race between the current
> +  * context and ksoftirqd which could leave NAPI disabled while
> +  * in fact there's still Rx traffic to be processed.
> +  */
> + usleep_range(5000, 1);

A wait never fixes a race.  Instead you must use appropriate mutual
exclusion mechanisms to ensure that NAPI is really completed it's
run, and we definitely have a means by which to do that properly.

> + net_dev->hw_features |= (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
> + NETIF_F_LLTX);

This second line should start exactly at the first column after the
openning parenthesis of the first line.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[Rafael J. Wysocki]

On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems. There are no such platforms yet, but the
> code needs to be robust for such a case.
> 
> Fix that by passing a local variable to debugfs_create_bool() and
> assigning its value to global_lock later.
> 
> Signed-off-by: Viresh Kumar 

Acked-by: Rafael J. Wysocki 

Greg, please take this one if the [2/2] looks good to you.

> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
>   (Rafael)
> - Drop the stable tag
> - BCC'd a lot of people (rather than cc'ing them) to make sure
>   - the series reaches them
>   - mailing lists do not block the patchset due to long cc list
>   - and we don't spam the BCC'd people for every reply
> ---
>  drivers/acpi/ec_sys.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..b44b91331a56 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, 
> unsigned int ec_device_count)
>   struct dentry *dev_dir;
>   char name[64];
>   umode_t mode = 0400;
> + u32 val;
>  
>   if (ec_device_count == 0) {
>   acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
> @@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, 
> unsigned int ec_device_count)
>  
>   if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)_ec->gpe))
>   goto error;
> - if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> -  (u32 *)_ec->global_lock))
> + if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, ))
>   goto error;
>  
> + first_ec->global_lock = val;
> +
>   if (write_support)
>   mode = 0600;
>   if (!debugfs_create_file("io", mode, dev_dir, ec, _ec_io_ops))
> 

Thanks,
Rafael

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

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[Rafael J. Wysocki]

On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> On 25-09-15, 20:49, Johannes Berg wrote:
> > Ok, then, but that means Rafael is completely wrong ...
> > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > it can't be on the stack. You also don't get a call when it changes.
> 
> Ahh, ofcourse. My bad as well...

Well, sorry about the wrong suggestion.

> I think we can change structure definition but will wait for Rafael's
> comment before that.

OK, change the structure then.

Thanks,
Rafael

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

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[Rafael J. Wysocki]

On Friday, September 25, 2015 10:26:22 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> > On 25-09-15, 20:49, Johannes Berg wrote:
> > > Ok, then, but that means Rafael is completely wrong ...
> > > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > > it can't be on the stack. You also don't get a call when it changes.
> > 
> > Ahh, ofcourse. My bad as well...
> 
> Well, sorry about the wrong suggestion.
> 
> > I think we can change structure definition but will wait for Rafael's
> > comment before that.
> 
> OK, change the structure then.

But here's a question.

You're going to change that into bool in the next patch, right?

So what if bool is a byte and the field is not word-aligned and changing
that byte requires a read-modify-write.  How do we ensure that things remain
consistent in that case?

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH] xen-blkback: free requests on disconnection

[Konrad Rzeszutek Wilk]

On Tue, Sep 22, 2015 at 12:10:18AM +0100, Julien Grall wrote:
> Hi Konrad,
> 
> On 09/09/2015 16:02, Konrad Rzeszutek Wilk wrote:
> >>Konrad, would you like me to resend the patch with the modified commit
> >>message, or do you plan to amend it yourself while committing?
> >
> >I will amend it. Thanks!
> 
> What the status for this patch?

Applied and sent the git pull.
> 
> Regards,
> 
> -- 
> Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 31/41] nfsd: Add support for the v4.1 dacl attribute

[Andreas Gruenbacher]

2015-09-24 21:59 GMT+02:00 J. Bruce Fields :
> I'd probably move this up top with the other ACL case.

Okay.

Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] platform: x86: PMC IPC depends on ACPI

[Lee Jones]

This patch solves:

on x86_64:

when CONFIG_ACPI is not enabled:

../drivers/mfd/intel_soc_pmic_bxtwc.c: In function 'bxtwc_probe':
../drivers/mfd/intel_soc_pmic_bxtwc.c:342:2:
error: implicit declaration of function 'acpi_evaluate_integer' 
[-Werror=implicit-function-declaration]
status = acpi_evaluate_integer(handle, "_HRV", NULL, );
^

Reported-by: Randy Dunlap 
Signed-off-by: Lee Jones 
---
 drivers/platform/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index c69bb70..744cb80 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -914,6 +914,7 @@ config PVPANIC
 
 config INTEL_PMC_IPC
tristate "Intel PMC IPC Driver"
+   depends on ACPI
---help---
This driver provides support for PMC control on some Intel platforms.
The PMC is an ARC processor which defines IPC commands for communication
-- 
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] gpio: ath79: Convert to the state container design pattern

[Linus Walleij]

On Tue, Sep 1, 2015 at 2:38 AM, Alban Bedel  wrote:

> Turn the ath79 driver into a true driver supporting multiple
> instances. While at it also removed unneed includes and make use of
> the BIT() macro.
>
> Signed-off-by: Alban Bedel 
> ---
>
> This patch apply on top of my previous MIPS GPIO patches that are pending
> for 4.3, so it might be better to take it thru the MIPS tree.

Patch applied (for v4.4).

Would you consider sending a patch adding yourself as maintainer
for this file in MAINTAINERS?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Voltage setting on chained regulators, how?

[Mark Brown]

On Fri, Sep 25, 2015 at 11:07:24AM +0200, Sascha Hauer wrote:

> Any idea how such a scenario could be implemented? The regulator
> framework already has some idea of supply regulators, but it only takes
> care of en/disabling the supplies and will not change the voltage on the
> supplies. Should this be implemented in the regulator framework?  Some
> first experiments brought me into a locking hell quite fast.

It's just a case of implementation, but yes the locking is fun.  I don't
think it's that big a deal to rethink it, it's partly complicated since
the existing locking is designed to be really simple and easy to review.

> For added fun ideally we want to put the LDOs in bypass mode instead of
> configuring them for minimum dropout. The bypass mode doesn't work for
> the 1.2GHz operating point though since the ripple on the switching
> regulator gets too high. So we can't just statically configure bypass
> mode but have to enable it dynamically based on the operating points.

I suspect you always want the LDO in there to clean the supply up, it's
just a more serious issue when more power is being drawn.  Having a DCDC
doing most of the voltage drop for efficiency with a LDO to clean up the
output of the DCDC is pretty common.


signature.asc
Description: Digital signature

Re: [PATCH] gpio:Fix error checking in the function device_pca957x_init

[Linus Walleij]

On Wed, Aug 26, 2015 at 2:52 PM, Nicholas Krause  wrote:

> This fixes error checking in the function device_pca957x_init
> to properly check and return error code values from the calls
> to the function pca953x_write_regs if they fail as to properly
> signal callers when a error occurs due a failure when writing
> registers for this gpio based device.
>
> Signed-off-by: Nicholas Krause 

Patch applied with Alexandre's review tag.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/1 RESEND] gpio: arizona: add support for WM8998 and WM1814

[Linus Walleij]

On Thu, Sep 10, 2015 at 8:59 AM, Richard Fitzgerald
 wrote:

> Signed-off-by: Richard Fitzgerald 
> Acked-by: Linus Walleij 

OK dependencies are upstream, patch applied.

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

Re: [PATCH v4 3/7] fs: Verify access of user towards block device file when mounting

[Seth Forshee]

On Fri, Sep 25, 2015 at 12:16:59PM -0500, Eric W. Biederman wrote:
> 
> Argh.  This looks like morning person meets night owl.

Indded :-)

> Seth Forshee  writes:
> 
> > On Thu, Sep 24, 2015 at 04:53:11PM -0500, Eric W. Biederman wrote:
> >> Seth Forshee  writes:
> >> 
> >> > When mounting a filesystem on a block device there is currently
> >> > no verification that the user has appropriate access to the
> >> > device file passed to mount. This has not been an issue so far
> >> > since the user in question has always been root, but this must
> >> > be changed before allowing unprivileged users to mount in user
> >> > namespaces.
> >> >
> >> > To do this, a new version of lookup_bdev() is added named
> >> > lookup_bdev_perm(). Both of these functions become wrappers
> >> > around a common inner fucntion. The behavior of lookup_bdev() is
> >> > unchanged, but calling lookup_bdev_perm() will fail if the user
> >> > does not have the specified access rights to the supplied path.
> >> > The permission check is skipped if the user has CAP_SYS_ADMIN to
> >> > avoid any possible regressions in behavior.
> >> >
> >> > blkdev_get_by_path() is updated to use lookup_bdev_perm(). This
> >> > is used by mount_bdev() and mount_mtd(), so this will cause
> >> > mounts on block devices to fail when the user lacks the required
> >> > permissions. Other calls to blkdev_get_by_path() will all happen
> >> > with root privileges, so these calls will be unaffected.
> >> 
> >> Good but buggy patch.
> >> 
> >> In the mtd bits the flags are super flags, not file mode bits,
> >> which makes testing them against FMODE_READ and FMODE_WRITE is
> >> incorrect.
> >
> > Bah, yes. Fixed.
> >
> >> Further it looks like quite a few more possibly all of the lookup_bdev
> >> instances could use inode level permission checking.
> >> 
> >> Certainly code such as quotactl makes me wonder.
> >
> > I opted to stick to places related to mounting, but let's take a look at
> > the other callers.
> >
> > bcache calls it in the context of sysfs writes, and those attributes are
> > writable only by root. In that case the inode permission check will be
> > skipped anyway, so it makes no difference either way.
> >
> > Device mapper calls it in dm_get_device, which is called from a bunch of
> > places. I had started trying to walk back through all the callers of
> > dm_get_device, but that rabbit hole got really deep really quickly so I
> > didn't feel confident that changing it wouldn't break anyone.
> >
> > quotactl gave me pause, as it seems to have done for you too. I was
> > surprised that inode permissions aren't checked, but
> > check_quotactl_permission does get called before actually doing
> > anything. I fear that adding a check of inode permissions could end up
> > breaking someone.
> 
> My gut feel on all of this is that we should act like may_open and have
> have a flag of 0 for access mode mean don't check permissions.
> 
> That way we can change all of the callers of lookup_bdev to pass an
> additional argument and make it explicit what is going on but we don't
> actually have to change the callers to actually perform an additional
> check.

Sounds reasonable, I'll make that change.

> Leaving stones unturned is a good way to introduce a security hole by
> accident so I don't want to leave dm_get_device unreviewed, but any
> changes can be in later patches.

Unless I've made a mistake it shouldn't introduce security holes,
dm_get_device should behave exactly the same was as it behaves today.
Any security problems would already be present.

I can take another crack at reviewing, but it might also be good if
someone who already knows the code commented as well. As I recall I gave
up after getting several levels deep in indirect function calls where the
names of the struct members which held the function pointers were
identical at a couple of levels, so I was having a hard time knowing if
I was keeping everything straight.

Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: mention in DT binding doc that -gpio is deprecated

[Rob Herring]

On Mon, Sep 21, 2015 at 7:57 AM, Javier Martinez Canillas
 wrote:
> The gpiolib supports parsing DT properties of the form -gpio but it
> was only added for compatibility with older DT bindings that got it wrong
> and should not be used in newer bindings.
>
> The commit that added support for this was:
>
> dd34c37aa3e8 ("gpio: of: Allow -gpio suffix for property names")
>
> but didn't update the documentation to explain this so it's been a source
> of confusion. So let's make this clear in the GPIO DT binding doc.
>
> Signed-off-by: Javier Martinez Canillas 

Applied. Thanks.

Rob

>
> ---
>
> Changes in v2:
> - Explain that -gpio is deprecated instead of saying that is
>   supported. Suggested by Alexandre Courbot.
>
>  Documentation/devicetree/bindings/gpio/gpio.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt 
> b/Documentation/devicetree/bindings/gpio/gpio.txt
> index 5788d5cf1252..82d40e2505f6 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -16,7 +16,9 @@ properties, each containing a 'gpio-list':
>  GPIO properties should be named "[-]gpios", with  being the 
> purpose
>  of this GPIO for the device. While a non-existent  is considered valid
>  for compatibility reasons (resolving to the "gpios" property), it is not 
> allowed
> -for new bindings.
> +for new bindings. Also, GPIO properties named "[-]gpio" are valid and 
> old
> +bindings use it, but are only supported for compatibility reasons and should 
> not
> +be used for newer bindings since it has been deprecated.
>
>  GPIO properties can contain one or more GPIO phandles, but only in 
> exceptional
>  cases should they contain more than one. If your device uses several GPIOs 
> with
> --
> 2.4.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: fsl-mc: Fixed uintX_t CHECK checkpatch warnings

[J. German Rivera]

Replaced all uses of uintX_t types to uX types, to be
checkpatch clean.

Signed-off-by: J. German Rivera 
---
This patch depends on the patch posted at
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg981518.html

 drivers/staging/fsl-mc/bus/dpbp.c   | 112 +++
 drivers/staging/fsl-mc/bus/dpmcp.c  |  98 ++---
 drivers/staging/fsl-mc/bus/dpmng.c  |   4 +-
 drivers/staging/fsl-mc/bus/dprc-driver.c|   2 +-
 drivers/staging/fsl-mc/bus/dprc.c   | 184 
 drivers/staging/fsl-mc/bus/mc-allocator.c   |   4 +-
 drivers/staging/fsl-mc/bus/mc-bus.c |   6 +-
 drivers/staging/fsl-mc/bus/mc-sys.c |   6 +-
 drivers/staging/fsl-mc/include/dpbp.h   | 108 +++---
 drivers/staging/fsl-mc/include/dpmng.h  |  10 +-
 drivers/staging/fsl-mc/include/dprc.h   | 212 ++--
 drivers/staging/fsl-mc/include/mc-cmd.h |  26 ++--
 drivers/staging/fsl-mc/include/mc-private.h |   6 +-
 drivers/staging/fsl-mc/include/mc-sys.h |   8 +-
 drivers/staging/fsl-mc/include/mc.h |  16 +--
 15 files changed, 401 insertions(+), 401 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/dpbp.c 
b/drivers/staging/fsl-mc/bus/dpbp.c
index f5a2028..2d97173 100644
--- a/drivers/staging/fsl-mc/bus/dpbp.c
+++ b/drivers/staging/fsl-mc/bus/dpbp.c
@@ -52,9 +52,9 @@
  * Return: '0' on Success; Error code otherwise.
  */
 int dpbp_open(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
+ u32 cmd_flags,
  int dpbp_id,
- uint16_t *token)
+ u16 *token)
 {
struct mc_command cmd = { 0 };
int err;
@@ -88,8 +88,8 @@ EXPORT_SYMBOL(dpbp_open);
  * Return: '0' on Success; Error code otherwise.
  */
 int dpbp_close(struct fsl_mc_io *mc_io,
-  uint32_t cmd_flags,
-  uint16_t token)
+  u32 cmd_flags,
+  u16 token)
 {
struct mc_command cmd = { 0 };

@@ -124,9 +124,9 @@ EXPORT_SYMBOL(dpbp_close);
  * Return: '0' on Success; Error code otherwise.
  */
 int dpbp_create(struct fsl_mc_io *mc_io,
-   uint32_t cmd_flags,
+   u32 cmd_flags,
const struct dpbp_cfg *cfg,
-   uint16_t *token)
+   u16 *token)
 {
struct mc_command cmd = { 0 };
int err;
@@ -157,8 +157,8 @@ int dpbp_create(struct fsl_mc_io *mc_io,
  * Return: '0' on Success; error code otherwise.
  */
 int dpbp_destroy(struct fsl_mc_io *mc_io,
-uint32_t cmd_flags,
-uint16_t token)
+u32 cmd_flags,
+u16 token)
 {
struct mc_command cmd = { 0 };

@@ -179,8 +179,8 @@ int dpbp_destroy(struct fsl_mc_io *mc_io,
  * Return: '0' on Success; Error code otherwise.
  */
 int dpbp_enable(struct fsl_mc_io *mc_io,
-   uint32_t cmd_flags,
-   uint16_t token)
+   u32 cmd_flags,
+   u16 token)
 {
struct mc_command cmd = { 0 };

@@ -202,8 +202,8 @@ EXPORT_SYMBOL(dpbp_enable);
  * Return: '0' on Success; Error code otherwise.
  */
 int dpbp_disable(struct fsl_mc_io *mc_io,
-uint32_t cmd_flags,
-uint16_t token)
+u32 cmd_flags,
+u16 token)
 {
struct mc_command cmd = { 0 };

@@ -226,8 +226,8 @@ EXPORT_SYMBOL(dpbp_disable);
  * Return: '0' on Success; Error code otherwise.
  */
 int dpbp_is_enabled(struct fsl_mc_io *mc_io,
-   uint32_t cmd_flags,
-   uint16_t token,
+   u32 cmd_flags,
+   u16 token,
int *en)
 {
struct mc_command cmd = { 0 };
@@ -256,8 +256,8 @@ int dpbp_is_enabled(struct fsl_mc_io *mc_io,
  * Return: '0' on Success; Error code otherwise.
  */
 int dpbp_reset(struct fsl_mc_io *mc_io,
-  uint32_t cmd_flags,
-  uint16_t token)
+  u32 cmd_flags,
+  u16 token)
 {
struct mc_command cmd = { 0 };

@@ -280,9 +280,9 @@ int dpbp_reset(struct fsl_mc_io *mc_io,
  * Return: '0' on Success; Error code otherwise.
  */
 int dpbp_set_irq(struct fsl_mc_io *mc_io,
-uint32_t cmd_flags,
-uint16_t token,
-uint8_t irq_index,
+u32 cmd_flags,
+u16 token,
+u8 irq_index,
 struct dpbp_irq_cfg *irq_cfg)
 {
struct mc_command cmd = { 0 };
@@ -312,9 +312,9 @@ int dpbp_set_irq(struct fsl_mc_io *mc_io,
  * Return: '0' on Success; Error code otherwise.
  */
 int dpbp_get_irq(struct fsl_mc_io *mc_io,
-uint32_t cmd_flags,
-uint16_t token,
-uint8_t irq_index,
+u32 cmd_flags,
+u16 token,
+u8 irq_index,
 int *type,
 struct dpbp_irq_cfg *irq_cfg)
 {
@@ -332,8 

Re: [PATCH] richacl: Possible other write-through fix

[Andreas Gruenbacher]

2015-09-24 20:33 GMT+02:00 J. Bruce Fields :
> On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote:
>> +int
>> +richacl_apply_masks(struct richacl **acl, kuid_t owner)
>> +{
>> + if ((*acl)->a_flags & RICHACL_MASKED) {
>> + struct richacl_alloc alloc = {
>> + .acl = richacl_clone(*acl, GFP_KERNEL),
>> + .count = (*acl)->a_count,
>> + };
>> + if (!alloc.acl)
>> + return -ENOMEM;
>> +
>> + if (richacl_move_everyone_aces_down() ||
>> + richacl_propagate_everyone() ||
>> + __richacl_apply_masks(, owner) ||
>> + richacl_set_owner_permissions() ||
>> + richacl_set_other_permissions() ||
>
> Hm, I'm a little unsure about this step: it seems like the one step that
> can actually change the permissions (making them more permissive, in
> this case), whereas the others are neutral.
>
> The following two steps should fix that, but I'm not sure they do.
>
> E.g. if I have an ACL like
>
> mask 0777, WRITE_THROUGH
> GROUP@:r--::allow
>
> I think it should result in
>
> OWNER@:   rwx::allow
> GROUP@:   -wx::deny
> GROUP@:   r--::allow
> EVERYONE@:rwx::allow
>
> But does the GROUP@ deny actually get in there?  It looks to me like the
> denies inserted by richacl_isolate_group_class only take into account
> the group mask, not the actual permissions granted to any group class
> user.
>
> I may be mising something.

Thanks for the test case and analysis. The group@ deny ace that should be
inserted here actually doesn't get inserted. I'm attaching a fix.

---

By the way, all those scenarios can easily be tries out using the test
suite in the user-space richacl package, even without a richacl enabled
kernel. In this case, without the fix, we get:

  $ make tests/richacl-apply-masks
  $ tests/richacl-apply-masks -m 777 group@:r::allow
  group@:r::allow
  everyone@:rwpx::allow

With the fix, we are now getting:

  $ tests/richacl-apply-masks -m 777 group@:r::allow
  owner@:rwpx::allow
  group@:r::allow
  group@:wpx::deny
  everyone@:rwpx::allow

Thanks,
Andreas

diff --git a/fs/richacl_compat.c b/fs/richacl_compat.c
index 726d796..bc0bcfe 100644
--- a/fs/richacl_compat.c
+++ b/fs/richacl_compat.c
@@ -463,23 +463,28 @@ richacl_set_owner_permissions(struct richacl_alloc *alloc)
 
 /**
  * richacl_set_other_permissions  -  set the other permissions to the other 
mask
+ * @alloc: acl and number of allocated entries
+ * @added: permissions added for everyone@
  *
  * Change the acl so that everyone@ is granted the permissions set in the other
  * mask.  This leaves at most one efective everyone@ allow entry at the end of
- * the acl.
+ * the acl.  If everyone@ end up being granted additional permissions, these
+ * permissions are returned in @added.
  */
 static int
-richacl_set_other_permissions(struct richacl_alloc *alloc)
+richacl_set_other_permissions(struct richacl_alloc *alloc, unsigned int *added)
 {
struct richacl *acl = alloc->acl;
unsigned int x = RICHACE_POSIX_ALWAYS_ALLOWED;
unsigned int other_mask = acl->a_other_mask & ~x;
-   struct richace *ace = acl->a_entries + acl->a_count - 1;
+   struct richace *ace;
 
if (!(other_mask &&
  (acl->a_flags & RICHACL_WRITE_THROUGH)))
return 0;
 
+   *added = other_mask;
+   ace = acl->a_entries + acl->a_count - 1;
if (acl->a_count == 0 ||
!richace_is_everyone(ace) ||
richace_is_inherit_only(ace)) {
@@ -490,8 +495,10 @@ richacl_set_other_permissions(struct richacl_alloc *alloc)
ace->e_flags = RICHACE_SPECIAL_WHO;
ace->e_mask = other_mask;
ace->e_id.special = RICHACE_EVERYONE_SPECIAL_ID;
-   } else
+   } else {
+   *added &= ~ace->e_mask;
richace_change_mask(alloc, , other_mask);
+   }
return 0;
 }
 
@@ -645,6 +652,7 @@ __richacl_isolate_who(struct richacl_alloc *alloc, struct 
richace *who,
 /**
  * richacl_isolate_group_class  -  limit the group class to the group file mask
  * @alloc: acl and number of allocated entries
+ * @deny:  additional permissions to deny
  *
  * POSIX requires that after a chmod, the group class is granted no more
  * permissions than the group file permission bits.  For richacls, this
@@ -679,21 +687,20 @@ __richacl_isolate_who(struct richacl_alloc *alloc, struct 
richace *who,
  *everyone@:rw::allow
  */
 static int
-richacl_isolate_group_class(struct richacl_alloc *alloc)
+richacl_isolate_group_class(struct richacl_alloc *alloc, unsigned int deny)
 {
struct richace who = {
.e_flags = RICHACE_SPECIAL_WHO,
.e_id.special = RICHACE_GROUP_SPECIAL_ID,
};
struct richace *ace;
-   unsigned int deny;
 
if 

Re: [PATCH v3 2/5] mfd: tps65912: Remove old driver in preparation for new driver

[Lee Jones]

On Thu, 24 Sep 2015, Andrew F. Davis wrote:

> The old tps65912 driver is being replaced, delete old driver.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/gpio/Kconfig   |   6 -
>  drivers/gpio/Makefile  |   1 -
>  drivers/gpio/gpio-tps65912.c   | 153 --
>  drivers/mfd/Kconfig|  26 --
>  drivers/mfd/Makefile   |   4 -
>  drivers/mfd/tps65912-core.c| 175 ---
>  drivers/mfd/tps65912-i2c.c | 139 -
>  drivers/mfd/tps65912-irq.c | 217 -
>  drivers/mfd/tps65912-spi.c | 141 -
>  drivers/regulator/Kconfig  |   6 -
>  drivers/regulator/Makefile |   1 -
>  drivers/regulator/tps65912-regulator.c | 541 
> -
>  include/linux/mfd/tps65912.h   | 328 
>  13 files changed, 1738 deletions(-)
>  delete mode 100644 drivers/gpio/gpio-tps65912.c
>  delete mode 100644 drivers/mfd/tps65912-core.c
>  delete mode 100644 drivers/mfd/tps65912-i2c.c
>  delete mode 100644 drivers/mfd/tps65912-irq.c
>  delete mode 100644 drivers/mfd/tps65912-spi.c
>  delete mode 100644 drivers/regulator/tps65912-regulator.c
>  delete mode 100644 include/linux/mfd/tps65912.h

I initially thought it was a bad idea due to bisectability blah blah
blah, but as the next patch adds a completely new incarnation I
thought this point to be moot.

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 06/22] gpio: Probe pinctrl devices on demand

[Linus Walleij]

On Mon, Sep 7, 2015 at 5:23 AM, Tomeu Vizoso  wrote:

Nit: prefix patch with "pinctrl:"

> When looking up a pin controller through its OF node, probe it if it
> hasn't already.
>
> The goal is to reduce deferred probes to a minimum, as it makes it very
> cumbersome to find out why a device failed to probe, and can introduce
> very big delays in when a critical device is probed.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None

Acked-by: Linus Walleij 

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

Re: [PATCH v4 05/22] gpio: Probe GPIO drivers on demand

[Linus Walleij]

On Mon, Sep 7, 2015 at 5:23 AM, Tomeu Vizoso  wrote:

> When looking up a gpiochip through its firmware node, probe it if it
> hasn't already.
>
> The goal is to reduce deferred probes to a minimum, as it makes it very
> cumbersome to find out why a device failed to probe, and can introduce
> very big delays in when a critical device is probed.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None

Acked-by: Linus Walleij 

That is if the whole thing goes in as-is for the GPIO parts.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio/pca953x: Add TI TCA9539 support

[Linus Walleij]

On Wed, Sep 9, 2015 at 8:23 AM, Thierry Reding  wrote:

> From: Thierry Reding 
>
> The TCA9539 is almost identical to the PCA9555 and software-compatible
> with this driver. It exposes 16 general purpose I/O pins in two 8-bit
> configurations.
>
> Signed-off-by: Thierry Reding 

Looks good! But:

> +   { .compatible = "ti,tca9539", },

You forgot to patch Documentation/devicetree/bindings/gpio/gpio-pca953x.txt

Fix that and I'll apply it.

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

[PATCH 3/4] lib/vsprintf.c: Remove SPECIAL handling in pointer()

[Rasmus Villemoes]

As a quick

   git grep -E '%[ +0#-]*#[ +0#-]*(\*|[0-9]+)?(\.(\*|[0-9]+)?)?p'

shows, nobody uses the # flag with %p. Moreover, I think users are
unlikely to show up since gcc will complain with

  warning: `#' flag used with ‘%p’ gnu_printf format [-Wformat]

Since default_width is effectively always 2*sizeof(void*), we can
simplify the prologue of pointer() and save a few instructions.

Signed-off-by: Rasmus Villemoes 
---
 lib/vsprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 03fa10b4be96..98b0d7be3fb7 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1457,7 +1457,7 @@ static noinline_for_stack
 char *pointer(const char *fmt, char *buf, char *end, void *ptr,
  struct printf_spec spec)
 {
-   int default_width = 2 * sizeof(void *) + (spec.flags & SPECIAL ? 2 : 0);
+   const int default_width = 2 * sizeof(void *);
 
if (!ptr && *fmt != 'K') {
/*
-- 
2.1.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 4/4] test_printf: test printf family at runtime

[Rasmus Villemoes]

This adds a simple module for testing the kernel's printf
facilities. Previously, some %p extensions have caused a wrong return
value in case the entire output didn't fit and/or been unusable in
kasprintf(). This should help catch such issues. Also, it should help
ensure that changes to the formatting algorithms don't break anything.

I'm not sure if we have a struct dentry or struct file lying around at
boot time or if we can fake one, but most %p extensions should be
testable, as should the ordinary number and string formatting.

The nature of vararg functions means we can't use a more conventional
table-driven approach.

For now, this is mostly a skeleton; contributions are very
welcome. Some tests are/will be slightly annoying to write, since the
expected output depends on stuff like CONFIG_*, sizeof(long), runtime
values etc.

Signed-off-by: Rasmus Villemoes 
---
 lib/Kconfig.debug |   3 +
 lib/Makefile  |   1 +
 lib/test_printf.c | 364 ++
 3 files changed, 368 insertions(+)
 create mode 100644 lib/test_printf.c

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ab76b99adc85..c23fc42dc659 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1685,6 +1685,9 @@ config TEST_STRING_HELPERS
 config TEST_KSTRTOX
tristate "Test kstrto*() family of functions at runtime"
 
+config TEST_PRINTF
+   tristate "Test printf() family of functions at runtime"
+
 config TEST_RHASHTABLE
tristate "Perform selftest on resizable hash table"
default n
diff --git a/lib/Makefile b/lib/Makefile
index 13a7c6ae3fec..775de427ea92 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_TEST_RHASHTABLE) += test_rhashtable.o
 obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o
 obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o
 obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
+obj-$(CONFIG_TEST_PRINTF) += test_printf.o
 
 ifeq ($(CONFIG_DEBUG_KOBJECT),y)
 CFLAGS_kobject.o += -DDEBUG
diff --git a/lib/test_printf.c b/lib/test_printf.c
new file mode 100644
index ..d9a2741c2909
--- /dev/null
+++ b/lib/test_printf.c
@@ -0,0 +1,364 @@
+/*
+ * Test cases for printf facility.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define BUF_SIZE 256
+#define FILL_CHAR '$'
+
+#define PTR1 ((void*)0x01234567)
+#define PTR2 ((void*)(long)(int)0xfedcba98)
+
+#if BITS_PER_LONG == 64
+#define PTR1_ZEROES "0"
+#define PTR1_SPACES " "
+#define PTR1_STR "1234567"
+#define PTR2_STR "fedcba98"
+#define PTR_WIDTH 16
+#else
+#define PTR1_ZEROES "0"
+#define PTR1_SPACES " "
+#define PTR1_STR "1234567"
+#define PTR2_STR "fedcba98"
+#define PTR_WIDTH 8
+#endif
+#define PTR_WIDTH_STR stringify(PTR_WIDTH)
+
+static unsigned total_tests __initdata;
+static unsigned failed_tests __initdata;
+static char *test_buffer __initdata;
+
+static int __printf(4, 0) __init
+do_test(int bufsize, const char *expect, int elen,
+   const char *fmt, va_list ap)
+{
+   va_list aq;
+   int ret, written;
+
+   total_tests++;
+
+   memset(test_buffer, FILL_CHAR, BUF_SIZE);
+   va_copy(aq, ap);
+   ret = vsnprintf(test_buffer, bufsize, fmt, aq);
+   va_end(aq);
+
+   if (ret != elen) {
+   pr_warn("bad return value, expected %d, got %d, format was 
'%s'\n",
+   elen, ret, fmt);
+   return 1;
+   }
+
+   if (!bufsize) {
+   if (memchr_inv(test_buffer, FILL_CHAR, BUF_SIZE)) {
+   pr_warn("vsnprintf(buf, 0, \"%s\", ...) wrote to 
buffer\n",
+   fmt);
+   return 1;
+   }
+   return 0;
+   }
+
+   written = min(bufsize-1, elen);
+   if (test_buffer[written]) {
+   pr_warn("vsnprintf(buf, %d, \"%s\", ...) did not nul-terminate 
buffer\n",
+   bufsize, fmt);
+   return 1;
+   }
+
+   if (memcmp(test_buffer, expect, written)) {
+   pr_warn("vsnprintf(buf, %d, \"%s\", ...) wrote '%s', expected 
'%.*s'\n",
+   bufsize, fmt, test_buffer, written, expect);
+   return 1;
+   }
+   return 0;
+}
+
+
+static void __printf(3, 4) __init
+__test(const char *expect, int elen, const char *fmt, ...)
+{
+   va_list ap;
+   int rand;
+   char *p;
+
+   BUG_ON(elen >= BUF_SIZE);
+
+   va_start(ap, fmt);
+
+   /*
+* Every fmt+args is subjected to four tests: Three where we
+* tell vsnprintf varying buffer sizes (plenty, not quite
+* enough and 0), and then we also test that kvasprintf would
+* be able to print it as expected.
+*/
+   failed_tests += do_test(BUF_SIZE, expect, elen, fmt, ap);
+   rand = 1 + prandom_u32_max(elen+1);
+   /* Since 

[PATCH] sched/fair: Skip wake_affine() for core siblings

[Kirill Tkhai]

We are not interested in actual target if both prev
and curr cpus share CPU cache. select_idle_sibling()
searches in top-down order; top level is the same
for both of them, and the result will be the same.
So, we can save a little CPU cycles and cache misses
and skip wake_affine() calculations.

tbench on 2 physical CPU Xeon (x 6 cores x 2 ht) inside cgroup:

threads  | Before |  After
---
  1  | 203.943 MB/sec |  211.524 MB/sec
  2  | 407.211 MB/sec |  411.701 MB/sec
  3  | 591.089 MB/sec |  608.404 MB/sec
  4  | 743.768 MB/sec |  790.026 MB/sec (+ 6.2%)
  5  | 914.237 MB/sec |  972.882 MB/sec (+ 6.4%)
  6  | 1053.91 MB/sec |  1092.81 MB/sec
  7  | 1208.24 MB/sec |  1281.1 MB/sec  (+ 6.0%)
  8  | 1357.53 MB/sec |  1385.79 MB/sec
  9  | 1474.11 MB/sec |  1496.76 MB/sec
 10  | 1586.89 MB/sec |  1616.76 MB/sec
 11  | 1720.17 MB/sec |  1732.7 MB/sec
 12  | 1835.4 MB/sec  |  1868.77 MB/sec
 13  | 1964.76 MB/sec |  2003.68 MB/sec
 14  | 2117.01 MB/sec |  2128.16 MB/sec
 15  | 2220.97 MB/sec |  2254.8 MB/sec
 16  | 2326.52 MB/sec |  2378.38 MB/sec
 17  | 2458.79 MB/sec |  2484.15 MB/sec
 18  | 2473.59 MB/sec |  2591.01 MB/sec (+ 4.7%)

Signed-off-by: Kirill Tkhai 
---
 kernel/sched/fair.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4df37a4..b378c34 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4666,6 +4666,9 @@ static int wake_affine(struct sched_domain *sd, struct 
task_struct *p, int sync)
unsigned long weight;
int balanced;
 
+   if (sd->flags & SD_SHARE_PKG_RESOURCES)
+   return 1;
+
idx   = sd->wake_idx;
this_cpu  = smp_processor_id();
prev_cpu  = task_cpu(p);

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

[PATCH v2 0/8] Improvements for SPI IMX driver for Freescale IMX53 and IMX6 families

[Anton Bondarenko]

A number of patches to impove or add the implementation
for the spi-imx driver related to Freescale IMX53 and IMX6.
It would also possible some of patches can be applied for other
Freescale controllers using spi-imx driver but could not be tested
due to lack of hardware.

Anton Bondarenko (8):
  spi: imx: Fix DMA transfer
  spi: imx: replace fixed timeout with calculated one
  spi: imx: add support for all SPI word width for DMA transfer
  spi: imx: add selection for iMX53 and iMX6 controller type
  spi: imx: Add support for loopback for ECSPI controllers
  spi: imx: return error from dma channel request
  spi: imx: defer spi initialization, if DMA engine is pending
  spi: imx: Add support for SPI Slave mode for imx53 and imx6 chips

 .../devicetree/bindings/spi/fsl-imx-cspi.txt   |   3 +
 drivers/spi/spi-imx.c  | 486 -
 2 files changed, 388 insertions(+), 101 deletions(-)

-- 
2.5.2

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

Re: [PATCH] net: via/Kconfig: GENERIC_PCI_IOMAP required if PCI not selected

[Sergei Shtylyov]

Hello.

On 9/24/2015 1:16 PM, Sudip Mukherjee wrote:


The builds of allmodconfig of avr32 is failing with:

drivers/net/ethernet/via/via-rhine.c:1098:2: error: implicit declaration
of function 'pci_iomap' [-Werror=implicit-function-declaration]
drivers/net/ethernet/via/via-rhine.c:1119:2: error: implicit declaration
of function 'pci_iounmap' [-Werror=implicit-function-declaration]

The generic empty pci_iomap and pci_iounmap is used only if CONFIG_PCI
is not defined and CONFIG_GENERIC_PCI_IOMAP is defined.

Add GENERIC_PCI_IOMAP in the dependency list for VIA_RHINE as we are
getting build failure when CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP both
are not defined.

Signed-off-by: Sudip Mukherjee 
---

Failed build log is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/81127188

An exactly similar patch has been posted earlier and relevant discussion
is at:
https://patchwork.ozlabs.org/patch/498722/

I posted a patch to include empty pci_iomap, pci_iounmap in avr32. That
discussion is at:
https://lkml.org/lkml/2015/9/19/100

  drivers/net/ethernet/via/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index 2f1264b..17831e5 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -17,7 +17,7 @@ if NET_VENDOR_VIA

  config VIA_RHINE
tristate "VIA Rhine support"
-   depends on (PCI || OF_IRQ)
+   depends on (PCI || (OF_IRQ && GENERIC_PCI_IOMAP))


  Could you remove outer braces, while at it?

[...]

MBR, Sergei

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

Re: [PATCH] arm64: Increase the max granular size

[Tirumalesh Chalamarla]

On 09/25/2015 07:45 AM, Robert Richter wrote:

Will,

On 22.09.15 19:29:02, Will Deacon wrote:

On Tue, Sep 22, 2015 at 06:59:48PM +0100, Robert Richter wrote:

From: Tirumalesh Chalamarla 

Increase the standard cacheline size to avoid having locks in the same
cacheline.

Cavium's ThunderX core implements cache lines of 128 byte size. With
current granulare size of 64 bytes (L1_CACHE_SHIFT=6) two locks could
share the same cache line leading a performance degradation.
Increasing the size fixes that.

Do you have an example of that happening?

I did some 'poor man's kernel build all modules benchmarking' and
could not find significant performance improvements so far (second
part with the patch reverted):

  build-allmodules-4.2.0-01404-g5818d6e89783.log:real   7m10.490s
  build-allmodules-4.2.0-01404-g5818d6e89783.log:real   6m59.747s
  build-allmodules-4.2.0-01404-g5818d6e89783.log:real   6m59.264s
  build-allmodules-4.2.0-01404-g5818d6e89783.log:real   7m0.435s
  build-allmodules-4.2.0-01404-g5818d6e89783.log:real   6m59.569s
  build-allmodules-4.2.0-01404-g5818d6e89783.log:real   6m59.274s
  build-allmodules-4.2.0-01404-g5818d6e89783.log:real   7m0.507s
  build-allmodules-4.2.0-01404-g5818d6e89783.log:real   7m1.551s
  build-allmodules-4.2.0-01404-g5818d6e89783.log:real   6m59.073s
  build-allmodules-4.2.0-01404-g5818d6e89783.log:real   7m1.738s

  build-allmodules-4.2.0-01406-g638c69fddc40.log:real   7m10.644s
  build-allmodules-4.2.0-01406-g638c69fddc40.log:real   6m59.814s
  build-allmodules-4.2.0-01406-g638c69fddc40.log:real   7m0.315s
  build-allmodules-4.2.0-01406-g638c69fddc40.log:real   6m59.610s
  build-allmodules-4.2.0-01406-g638c69fddc40.log:real   6m59.885s
  build-allmodules-4.2.0-01406-g638c69fddc40.log:real   6m59.281s
  build-allmodules-4.2.0-01406-g638c69fddc40.log:real   7m0.869s
  build-allmodules-4.2.0-01406-g638c69fddc40.log:real   7m0.953s
  build-allmodules-4.2.0-01406-g638c69fddc40.log:real   7m0.787s
  build-allmodules-4.2.0-01406-g638c69fddc40.log:real   7m0.656s

I will check what kind of workloads this patch was written for.
Tirumalesh, any idea?


mainly for workloads where compiler optimizes based on cache line size,
let me write a small bench mark

Thanks,

-Robert


Increasing the size has no negative impact to cache invalidation on
systems with a smaller cache line. There is an impact on memory usage,
but that's not too important for arm64 use cases.

Do you have any before/after numbers to show the impact of this change
on other supported SoCs?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] kernel/cpu.c: eliminate cpu_*_mask

[Rasmus Villemoes]

Replace the variables cpu_possible_mask, cpu_online_mask,
cpu_present_mask and cpu_active_mask with macros expanding to
expressions of the same type and value, eliminating some indirection.

Signed-off-by: Rasmus Villemoes 
---
 include/linux/cpumask.h | 8 
 kernel/cpu.c| 8 
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index d4545a1852f2..52ab539aefce 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -85,14 +85,14 @@ extern int nr_cpu_ids;
  *only one CPU.
  */
 
-extern const struct cpumask *const cpu_possible_mask;
-extern const struct cpumask *const cpu_online_mask;
-extern const struct cpumask *const cpu_present_mask;
-extern const struct cpumask *const cpu_active_mask;
 extern struct cpumask __cpu_possible_mask;
 extern struct cpumask __cpu_online_mask;
 extern struct cpumask __cpu_present_mask;
 extern struct cpumask __cpu_active_mask;
+#define cpu_possible_mask ((const struct cpumask *)&__cpu_possible_mask)
+#define cpu_online_mask   ((const struct cpumask *)&__cpu_online_mask)
+#define cpu_present_mask  ((const struct cpumask *)&__cpu_present_mask)
+#define cpu_active_mask   ((const struct cpumask *)&__cpu_active_mask)
 
 #if NR_CPUS > 1
 #define num_online_cpus()  cpumask_weight(cpu_online_mask)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index e08db26d351b..dd70f600442f 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -778,23 +778,15 @@ struct cpumask __cpu_possible_mask __read_mostly
 struct cpumask __cpu_possible_mask __read_mostly;
 #endif
 EXPORT_SYMBOL(__cpu_possible_mask);
-const struct cpumask *const cpu_possible_mask = &__cpu_possible_mask;
-EXPORT_SYMBOL(cpu_possible_mask);
 
 struct cpumask __cpu_online_mask __read_mostly;
 EXPORT_SYMBOL(__cpu_online_mask);
-const struct cpumask *const cpu_online_mask = &__cpu_online_mask;
-EXPORT_SYMBOL(cpu_online_mask);
 
 struct cpumask __cpu_present_mask __read_mostly;
 EXPORT_SYMBOL(__cpu_present_mask);
-const struct cpumask *const cpu_present_mask = &__cpu_present_mask;
-EXPORT_SYMBOL(cpu_present_mask);
 
 struct cpumask __cpu_active_mask __read_mostly;
 EXPORT_SYMBOL(__cpu_active_mask);
-const struct cpumask *const cpu_active_mask = &__cpu_active_mask;
-EXPORT_SYMBOL(cpu_active_mask);
 
 void set_cpu_possible(unsigned int cpu, bool possible)
 {
-- 
2.1.3

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

[PATCH 1/5] kernel/cpu.c: change type of cpu_possible_bits and friends

[Rasmus Villemoes]

Change cpu_possible_bits and friends (online, present, active) from
being bitmaps that happen to have the right size to actually being
struct cpumasks. Also rename them to __cpu_xyz_mask. This is mostly a
small cleanup in preparation for exporting them and, eventually,
eliminating the extra indirection through the cpu_xyz_mask variables.

Signed-off-by: Rasmus Villemoes 
---
 kernel/cpu.c | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 82cf9dff4295..fea4a3ce3011 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -772,71 +772,71 @@ const DECLARE_BITMAP(cpu_all_bits, NR_CPUS) = 
CPU_BITS_ALL;
 EXPORT_SYMBOL(cpu_all_bits);
 
 #ifdef CONFIG_INIT_ALL_POSSIBLE
-static DECLARE_BITMAP(cpu_possible_bits, CONFIG_NR_CPUS) __read_mostly
-   = CPU_BITS_ALL;
+static struct cpumask __cpu_possible_mask __read_mostly
+   = {CPU_BITS_ALL};
 #else
-static DECLARE_BITMAP(cpu_possible_bits, CONFIG_NR_CPUS) __read_mostly;
+static struct cpumask __cpu_possible_mask __read_mostly;
 #endif
-const struct cpumask *const cpu_possible_mask = to_cpumask(cpu_possible_bits);
+const struct cpumask *const cpu_possible_mask = &__cpu_possible_mask;
 EXPORT_SYMBOL(cpu_possible_mask);
 
-static DECLARE_BITMAP(cpu_online_bits, CONFIG_NR_CPUS) __read_mostly;
-const struct cpumask *const cpu_online_mask = to_cpumask(cpu_online_bits);
+static struct cpumask __cpu_online_mask __read_mostly;
+const struct cpumask *const cpu_online_mask = &__cpu_online_mask;
 EXPORT_SYMBOL(cpu_online_mask);
 
-static DECLARE_BITMAP(cpu_present_bits, CONFIG_NR_CPUS) __read_mostly;
-const struct cpumask *const cpu_present_mask = to_cpumask(cpu_present_bits);
+static struct cpumask __cpu_present_mask __read_mostly;
+const struct cpumask *const cpu_present_mask = &__cpu_present_mask;
 EXPORT_SYMBOL(cpu_present_mask);
 
-static DECLARE_BITMAP(cpu_active_bits, CONFIG_NR_CPUS) __read_mostly;
-const struct cpumask *const cpu_active_mask = to_cpumask(cpu_active_bits);
+static struct cpumask __cpu_active_mask __read_mostly;
+const struct cpumask *const cpu_active_mask = &__cpu_active_mask;
 EXPORT_SYMBOL(cpu_active_mask);
 
 void set_cpu_possible(unsigned int cpu, bool possible)
 {
if (possible)
-   cpumask_set_cpu(cpu, to_cpumask(cpu_possible_bits));
+   cpumask_set_cpu(cpu, &__cpu_possible_mask);
else
-   cpumask_clear_cpu(cpu, to_cpumask(cpu_possible_bits));
+   cpumask_clear_cpu(cpu, &__cpu_possible_mask);
 }
 
 void set_cpu_present(unsigned int cpu, bool present)
 {
if (present)
-   cpumask_set_cpu(cpu, to_cpumask(cpu_present_bits));
+   cpumask_set_cpu(cpu, &__cpu_present_mask);
else
-   cpumask_clear_cpu(cpu, to_cpumask(cpu_present_bits));
+   cpumask_clear_cpu(cpu, &__cpu_present_mask);
 }
 
 void set_cpu_online(unsigned int cpu, bool online)
 {
if (online) {
-   cpumask_set_cpu(cpu, to_cpumask(cpu_online_bits));
-   cpumask_set_cpu(cpu, to_cpumask(cpu_active_bits));
+   cpumask_set_cpu(cpu, &__cpu_online_mask);
+   cpumask_set_cpu(cpu, &__cpu_active_mask);
} else {
-   cpumask_clear_cpu(cpu, to_cpumask(cpu_online_bits));
+   cpumask_clear_cpu(cpu, &__cpu_online_mask);
}
 }
 
 void set_cpu_active(unsigned int cpu, bool active)
 {
if (active)
-   cpumask_set_cpu(cpu, to_cpumask(cpu_active_bits));
+   cpumask_set_cpu(cpu, &__cpu_active_mask);
else
-   cpumask_clear_cpu(cpu, to_cpumask(cpu_active_bits));
+   cpumask_clear_cpu(cpu, &__cpu_active_mask);
 }
 
 void init_cpu_present(const struct cpumask *src)
 {
-   cpumask_copy(to_cpumask(cpu_present_bits), src);
+   cpumask_copy(&__cpu_present_mask, src);
 }
 
 void init_cpu_possible(const struct cpumask *src)
 {
-   cpumask_copy(to_cpumask(cpu_possible_bits), src);
+   cpumask_copy(&__cpu_possible_mask, src);
 }
 
 void init_cpu_online(const struct cpumask *src)
 {
-   cpumask_copy(to_cpumask(cpu_online_bits), src);
+   cpumask_copy(&__cpu_online_mask, src);
 }
-- 
2.1.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 3/5] drivers/base/cpu.c: use __cpu_*_mask directly

[Rasmus Villemoes]

The only user of the lvalue-ness of the cpu_*_mask variables is in
drivers/base/cpu.c, and that is mostly a work-around for the fact that
not even const variables can be used in static initialization. Now
that the underlying struct cpumasks are exposed we can take their
address.

Signed-off-by: Rasmus Villemoes 
---
 drivers/base/cpu.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 91bbb1959d8d..691eeea2f19a 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -200,7 +200,7 @@ static const struct attribute_group 
*hotplugable_cpu_attr_groups[] = {
 
 struct cpu_attr {
struct device_attribute attr;
-   const struct cpumask *const * const map;
+   const struct cpumask *const map;
 };
 
 static ssize_t show_cpus_attr(struct device *dev,
@@ -209,7 +209,7 @@ static ssize_t show_cpus_attr(struct device *dev,
 {
struct cpu_attr *ca = container_of(attr, struct cpu_attr, attr);
 
-   return cpumap_print_to_pagebuf(true, buf, *ca->map);
+   return cpumap_print_to_pagebuf(true, buf, ca->map);
 }
 
 #define _CPU_ATTR(name, map) \
@@ -217,9 +217,9 @@ static ssize_t show_cpus_attr(struct device *dev,
 
 /* Keep in sync with cpu_subsys_attrs */
 static struct cpu_attr cpu_attrs[] = {
-   _CPU_ATTR(online, _online_mask),
-   _CPU_ATTR(possible, _possible_mask),
-   _CPU_ATTR(present, _present_mask),
+   _CPU_ATTR(online, &__cpu_online_mask),
+   _CPU_ATTR(possible, &__cpu_possible_mask),
+   _CPU_ATTR(present, &__cpu_present_mask),
 };
 
 /*
-- 
2.1.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 V1 2/6] ASoC: tlv320aic26: Fix module autoload

[Cormier, Jonathan]

Add the missing MODULE_DEVICE_TABLE() for OF and SPI to export
the information so modules have the correct aliases built-in and
autoloading works correctly.

A longer explanation by Javier Canillas can be found here:
https://lkml.org/lkml/2015/7/30/519
https://lkml.org/lkml/2014/9/11/458

Signed-off-by: Cormier, Jonathan 
---
 sound/soc/codecs/tlv320aic26.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 65c2bfb02e76..bf3a9ec40e1e 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -370,10 +370,17 @@ static int aic26_spi_remove(struct spi_device *spi)
return 0;
 }
 
+static const struct spi_device_id tlv320aic26_id_table[] = {
+   { "tlv320aic26" },
+   {},
+};
+MODULE_DEVICE_TABLE(spi, tlv320aic26_id_table);
+
 static const struct of_device_id tlv320aic26_of_match[] = {
{ .compatible = "ti,tlv320aic26", },
{},
 };
+MODULE_DEVICE_TABLE(of, tlv320aic26_of_match);
 
 static struct spi_driver aic26_spi = {
.driver = {
@@ -383,6 +390,7 @@ static struct spi_driver aic26_spi = {
},
.probe = aic26_spi_probe,
.remove = aic26_spi_remove,
+   .id_table = tlv320aic26_id_table,
 };
 
 module_spi_driver(aic26_spi);
-- 
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 V1 1/6] ASoC: tlv320aic26: Add device tree binding

[Cormier, Jonathan]

Signed-off-by: Cormier, Jonathan 
---
 .../devicetree/bindings/sound/tlv320aic26.txt  | 65 ++
 sound/soc/codecs/tlv320aic26.c |  6 ++
 2 files changed, 71 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/tlv320aic26.txt

diff --git a/Documentation/devicetree/bindings/sound/tlv320aic26.txt 
b/Documentation/devicetree/bindings/sound/tlv320aic26.txt
new file mode 100644
index ..93aa0f76ec0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tlv320aic26.txt
@@ -0,0 +1,65 @@
+Texas Instruments - tlv320aic26 Codec module
+
+The tlv320aic26 serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - "string" - One of:
+"ti,tlv320aic26" - TLV320AIC26
+- reg -  -  SPI chip select
+
+CODEC input pins:
+  * MICIN
+  * AUX
+
+CODEC output pins:
+  * HPL
+  * HPR
+
+The pins can be used in referring sound node's audio-routing property.
+
+Example:
+
+tlv320aic26: tlv320aic26@0 {
+   compatible = "ti,tlv320aic26";
+   reg = <0>;
+};
+
+ {
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_sleep_pins>;
+
+   status = "okay";
+   ti,pindir-d0-out-d1-in = <1>;
+
+   tlv320aic26: tlv320aic26@1 {
+   compatible = "ti,tlv320aic26";
+   reg = <0x1>;
+   status = "okay";
+
+   spi-max-frequency = <200>;
+   spi-cpha;
+   };
+};
+
+sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "AM335x_SND";
+   simple-audio-card,format = "dsp_b";
+   /* SND_SOC_DAIFMT_CBM_CFM */
+   simple-audio-card,bitclock-master = <_codec>;
+   simple-audio-card,frame-master = <_codec>;
+   /* SND_SOC_DAIFMT_IB_NF */
+   simple-audio-card,bitclock-inversion;
+
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   system-clock-frequency = <24576000>;
+   };
+
+   tlv320aic26_codec: simple-audio-card,codec {
+   sound-dai = <>;
+   system-clock-frequency = <24576000>;
+   };
+};
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 620ab9ea1ef0..65c2bfb02e76 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -370,10 +370,16 @@ static int aic26_spi_remove(struct spi_device *spi)
return 0;
 }
 
+static const struct of_device_id tlv320aic26_of_match[] = {
+   { .compatible = "ti,tlv320aic26", },
+   {},
+};
+
 static struct spi_driver aic26_spi = {
.driver = {
.name = "tlv320aic26-codec",
.owner = THIS_MODULE,
+   .of_match_table = of_match_ptr(tlv320aic26_of_match),
},
.probe = aic26_spi_probe,
.remove = aic26_spi_remove,
-- 
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 V1 6/6] ASoC: tlv320aic26: Change Capture Mute to Capture Switch to match alsa documentation.

[Cormier, Jonathan]

Signed-off-by: Cormier, Jonathan 
---
 sound/soc/codecs/tlv320aic26.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 7d2fbca068d0..f7629b17ee5b 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -269,7 +269,7 @@ static const struct snd_kcontrol_new aic26_snd_controls[] = 
{
SOC_DOUBLE("PCM Playback Volume", AIC26_REG_DAC_GAIN, 8, 0, 0x7f, 1),
SOC_DOUBLE("PCM Playback Switch", AIC26_REG_DAC_GAIN, 15, 7, 1, 1),
SOC_SINGLE("PCM Capture Volume", AIC26_REG_ADC_GAIN, 8, 0x7f, 0),
-   SOC_SINGLE("PCM Capture Mute", AIC26_REG_ADC_GAIN, 15, 1, 1),
+   SOC_SINGLE("PCM Capture Switch", AIC26_REG_ADC_GAIN, 15, 1, 1),
SOC_SINGLE("Keyclick activate", AIC26_REG_AUDIO_CTRL2, 15, 0x1, 0),
SOC_SINGLE("Keyclick amplitude", AIC26_REG_AUDIO_CTRL2, 12, 0x7, 0),
SOC_SINGLE("Keyclick frequency", AIC26_REG_AUDIO_CTRL2, 8, 0x7, 0),
-- 
1.9.1

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

[PATCH V1 5/6] ASoC: tlv320aic26: hw_params was unintentionally clearing AIC26 master mode

[Cormier, Jonathan]

Commit: 5b0959d472c2 "ASoC: tlv320aic26: Use snd_soc_update_bits()" broke 
setting AIC26_REG_AUDIO_CTRL3
in master mode when fsref happens to be 48000. The master mode bit was getting 
cleared.

Also fix setting AIC26_REG_DAC_GAIN and AIC26_REG_AUDIO_CTRL2 which was broke 
by same commit.

Fixes: 5b0959d472c2 "ASoC: tlv320aic26: Use snd_soc_update_bits()"
Signed-off-by: Cormier, Jonathan 
---
 sound/soc/codecs/tlv320aic26.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 8355f379d45d..7d2fbca068d0 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -138,11 +138,12 @@ static int aic26_hw_params(struct snd_pcm_substream 
*substream,
snd_soc_write(codec, AIC26_REG_PLL_PROG2, reg);
 
/* Audio Control 3 (master mode, fsref rate) */
+   reg = 0;
if (aic26->master)
-   reg = 0x0800;
+   reg |= 0x0800;
if (fsref == 48000)
-   reg = 0x2000;
-   snd_soc_update_bits(codec, AIC26_REG_AUDIO_CTRL3, 0xf800, reg);
+   reg |= 0x2000;
+   snd_soc_update_bits(codec, AIC26_REG_AUDIO_CTRL3, 0x2800, reg);
 
/* Audio Control 1 (FSref divisor) */
reg = wlen | aic26->datfm | (divisor << 3) | divisor;
@@ -167,7 +168,7 @@ static int aic26_mute(struct snd_soc_dai *dai, int mute)
reg = 0x8080;
else
reg = 0;
-   snd_soc_update_bits(codec, AIC26_REG_DAC_GAIN, 0x8000, reg);
+   snd_soc_update_bits(codec, AIC26_REG_DAC_GAIN, 0x8080, reg);
 
return 0;
 }
@@ -302,7 +303,7 @@ static ssize_t aic26_keyclick_set(struct device *dev,
struct aic26 *aic26 = dev_get_drvdata(dev);
 
snd_soc_update_bits(aic26->codec, AIC26_REG_AUDIO_CTRL2,
-   0x8000, 0x800);
+   0x8000, 0x8000);
 
return count;
 }
-- 
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 V1 4/6] ASoC: tlv320aic26: Fix regmap by setting reg_defaults and reg_stride

[Cormier, Jonathan]

tlv320aic26 codec wasn't being setup correctly on bootup due to misconfigured 
regmap cache.

Fixes: b7e9f3973279 "ASoC: tlv320aic26: Convert to direct regmap API usage"
Signed-off-by: Cormier, Jonathan 
---
 sound/soc/codecs/tlv320aic26.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index bf3a9ec40e1e..8355f379d45d 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -41,6 +41,27 @@ struct aic26 {
int keyclick_len;
 };
 
+static const struct reg_default aic26_reg[] = {
+   /* Page 0 */
+   { 0x00A0, 0x }, { 0x00C0, 0x }, { 0x00E0, 0x },
+   { 0x0120, 0x }, { 0x0140, 0x },
+   /* Page 1 */
+   { 0x0800, 0x }, { 0x0820, 0x8000 }, { 0x0860, 0x0002 },
+   { 0x0880, 0x },
+   /* Page 2 */
+   { 0x1000, 0x }, { 0x1020, 0x8000 }, { 0x1040, 0x },
+   { 0x1060, 0xC580 }, { 0x1080, 0x4410 }, { 0x10A0, 0xAFC0 },
+   { 0x10C0, 0x }, { 0x10E0,  27619 }, { 0x1100, -27034 },
+   { 0x1120,  26461 }, { 0x1140,  27619 }, { 0x1160, -27034 },
+   { 0x1180,  26461 }, { 0x11A0,  32131 }, { 0x11C0, -31506 },
+   { 0x11E0,  32131 }, { 0x1200, -31506 }, { 0x1220,  27619 },
+   { 0x1240, -27034 }, { 0x1260,  26461 }, { 0x1280,  27619 },
+   { 0x12A0, -27034 }, { 0x12C0,  26461 }, { 0x12E0,  32131 },
+   { 0x1300, -31506 }, { 0x1320,  32131 }, { 0x1340, -31506 },
+   { 0x1360, 0x1004 }, { 0x1380, 0x }, { 0x13A0, 0x },
+   { 0x13C0, 0xFE00 },
+};
+
 static const struct snd_soc_dapm_widget tlv320aic26_dapm_widgets[] = {
 SND_SOC_DAPM_INPUT("MICIN"),
 SND_SOC_DAPM_INPUT("AUX"),
@@ -332,6 +353,13 @@ static struct snd_soc_codec_driver aic26_soc_codec_dev = {
 static const struct regmap_config aic26_regmap = {
.reg_bits = 16,
.val_bits = 16,
+   /* AIC26_PAGE_ADDR(0, 0x01) */
+   .reg_stride = 0x20,
+
+   .max_register = AIC26_REG_AUDIO_CTRL5,
+   .reg_defaults = aic26_reg,
+   .num_reg_defaults = ARRAY_SIZE(aic26_reg),
+   .cache_type = REGCACHE_RBTREE,
 };
 
 /* -
-- 
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 V1 3/6] ASoC: tlv320aic26: Make SND_SOC_TLV320AIC26 user-visible

[Cormier, Jonathan]

Allow SND_SOC_TLV320AIC26 to be built.

Based on commit: 
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-October/011287.html

Signed-off-by: Cormier, Jonathan 
---
 sound/soc/codecs/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index efaafce8ba38..a70b5a00dc5e 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -640,7 +640,7 @@ config SND_SOC_TLV320AIC23_SPI
select SND_SOC_TLV320AIC23
 
 config SND_SOC_TLV320AIC26
-   tristate
+   tristate "Texas Instruments TLV320AIC26 Codec support"
depends on SPI
 
 config SND_SOC_TLV320AIC31XX
-- 
1.9.1

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

[PATCH V4 2/2] debugfs: Pass bool pointer to debugfs_create_bool()

[Viresh Kumar]

Its a bit odd that debugfs_create_bool() takes 'u32 *' as an argument,
when all it needs is a boolean pointer.

It would be better to update this API to make it accept 'bool *'
instead, as that will make it more consistent and often more convenient.
Over that bool takes just a byte (mostly).

That required updates to all user sites as well, in the same commit
updating the API. regmap core was also using
debugfs_{read|write}_file_bool(), directly and variable types were
updated for that to be bool as well.

Signed-off-by: Viresh Kumar 
Acked-by: Mark Brown 
Acked-by: Charles Keepax 
---
V3->V4:
- Updated commit log to make it clear
- Drop 'global_lock = !!tmp' change, as that's not required at all.
- s/u32/bool for ec_sys.c
- Added Ack from Charles.
- BCC'd a lot of people (rather than cc'ing them) to make sure
  - the series reaches them
  - mailing lists do not block the patchset due to long cc list
  - and we don't spam the BCC'd people for every reply
---
 Documentation/filesystems/debugfs.txt  |  2 +-
 arch/arm64/kernel/debug-monitors.c |  4 ++--
 drivers/acpi/ec_sys.c  |  2 +-
 drivers/acpi/internal.h|  2 +-
 drivers/base/regmap/internal.h |  6 +++---
 drivers/base/regmap/regcache-lzo.c |  4 ++--
 drivers/base/regmap/regcache.c | 24 
 drivers/bluetooth/hci_qca.c|  4 ++--
 drivers/iommu/amd_iommu_init.c |  2 +-
 drivers/iommu/amd_iommu_types.h|  2 +-
 drivers/misc/mei/mei_dev.h |  2 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |  4 ++--
 drivers/net/wireless/ath/ath10k/core.h |  2 +-
 drivers/net/wireless/ath/ath5k/ath5k.h |  2 +-
 drivers/net/wireless/ath/ath9k/hw.c|  2 +-
 drivers/net/wireless/ath/ath9k/hw.h|  4 ++--
 drivers/net/wireless/b43/debugfs.c | 18 +-
 drivers/net/wireless/b43/debugfs.h |  2 +-
 drivers/net/wireless/b43legacy/debugfs.c   | 10 +-
 drivers/net/wireless/b43legacy/debugfs.h   |  2 +-
 drivers/net/wireless/iwlegacy/common.h |  6 +++---
 drivers/net/wireless/iwlwifi/mvm/mvm.h |  6 +++---
 drivers/scsi/snic/snic_trc.c   |  4 ++--
 drivers/scsi/snic/snic_trc.h   |  2 +-
 drivers/uwb/uwb-debug.c|  2 +-
 fs/debugfs/file.c  |  6 +++---
 include/linux/debugfs.h|  4 ++--
 include/linux/edac.h   |  2 +-
 include/linux/fault-inject.h   |  2 +-
 kernel/futex.c |  4 ++--
 lib/dma-debug.c|  2 +-
 mm/failslab.c  |  8 
 mm/page_alloc.c|  8 
 sound/soc/codecs/wm_adsp.h |  2 +-
 34 files changed, 79 insertions(+), 79 deletions(-)

diff --git a/Documentation/filesystems/debugfs.txt 
b/Documentation/filesystems/debugfs.txt
index 463f595733e8..4f45f71149cb 100644
--- a/Documentation/filesystems/debugfs.txt
+++ b/Documentation/filesystems/debugfs.txt
@@ -105,7 +105,7 @@ a variable of type size_t.
 Boolean values can be placed in debugfs with:
 
 struct dentry *debugfs_create_bool(const char *name, umode_t mode,
-  struct dentry *parent, u32 *value);
+  struct dentry *parent, bool *value);
 
 A read on the resulting file will yield either Y (for non-zero values) or
 N, followed by a newline.  If written to, it will accept either upper- or
diff --git a/arch/arm64/kernel/debug-monitors.c 
b/arch/arm64/kernel/debug-monitors.c
index cebf78661a55..1c4cd4a0d7cc 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -58,7 +58,7 @@ static u32 mdscr_read(void)
  * Allow root to disable self-hosted debug from userspace.
  * This is useful if you want to connect an external JTAG debugger.
  */
-static u32 debug_enabled = 1;
+static bool debug_enabled = true;
 
 static int create_debug_debugfs_entry(void)
 {
@@ -69,7 +69,7 @@ fs_initcall(create_debug_debugfs_entry);
 
 static int __init early_debug_disable(char *buf)
 {
-   debug_enabled = 0;
+   debug_enabled = false;
return 0;
 }
 
diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index b44b91331a56..f025b044a1cf 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -110,7 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned 
int ec_device_count)
struct dentry *dev_dir;
char name[64];
umode_t mode = 0400;
-   u32 val;
+   bool val;
 
if (ec_device_count == 0) {
acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 9e426210c2a8..5a72e2b140fc 100644
--- a/drivers/acpi/internal.h
+++ 

Re: [PATCH] xen/pvhvm: add soft reset on kexec/kdump support

[Vitaly Kuznetsov]

Boris Ostrovsky  writes:

> On 09/25/2015 09:59 AM, Konrad Rzeszutek Wilk wrote:
>> On Fri, Sep 25, 2015 at 11:59:52AM +0200, Vitaly Kuznetsov wrote:
>>> Currently there is a number of issues preventing PVHVM Xen guests from
>>> doing successful kexec/kdump:
>>> - Bound event channels.
>>> - Registered vcpu_info.
>>> - PIRQ/emuirq mappings.
>>> - shared_info frame after XENMAPSPACE_shared_info operation.
>>> - Active grant mappings.
>>> Basically, newly booted kernel stumbles upon already set up Xen interfaces
>>> and there is no way to reestablish them. In Xen-4.7 a new feature called
>>> 'soft reset' is coming. A guest performing kexec/kdump operation is
>>> supposed to call SCHEDOP_shutdown hypercall with SHUTDOWN_soft_reset reason
>>> before jumping to new kernel. Hypervisor (with some help from toolstack)
>>> will do full domain cleanup (but keeping its memory and vCPU contexts
>>> intact) returning the guest to the state it had when it was first booted
>>> and thus allowing it to start over.
>>>
>>> Doing SHUTDOWN_soft_reset on Xen hypervisors which don't support it is
>>> probably OK as by default all unknown shutdown reasons cause domain destroy
>>> with a message in toolstack log:
>>> 'Unknown shutdown reason code 5. Destroying domain.'
>>> which gives a clue to what the problem is and eliminates false
>>> expectations.
>>>
>>> Signed-off-by: Vitaly Kuznetsov 
>> Reviewed-by: Konrad Rzeszutek Wilk 
>>
>> with s/pvhvm/hvm/
>>
>> to match with the rest of the file.
>>
>> Thanks.
>>>   +#ifdef CONFIG_KEXEC_CORE
>>> +static void xen_pvhvm_kexec_shutdown(void)
>>> +{
>>> +   native_machine_shutdown();
>>> +   if (kexec_in_progress)
>>> +   xen_reboot(SHUTDOWN_soft_reset);
>>> +}
>
> This routine is not kexec-specific so "kexec_" should be dropped from
> the name.

Ok,

>
> Also, I am not sure I see how this new op will be used in the
> hypervisor --- currently AFAICS it is only processed under
> is_hardware_domain(). Are there other patches that will support HVM
> guests?

Please see my Xen series:
http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg00547.html
(last 'full' submission).

All patches from my 'toolstack-assisted approach to PVHVM guest kexec'
are already merged to xen.git (first 10 are already in 'master' and the
last one is in 'staging').

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

Re: [PATCH v5] mfd: tps6105x: Fix possible NULL pointer access.

[Lee Jones]

On Fri, 25 Sep 2015, Grigoryev Denis wrote:

> tps6105 driver provides two cells. One is for GPIO and another one is
> for selected mode depending on platform data. When tps6105x is used in
> GPIO-only mode, this driver calls mfd_add_devices() with mfd_cell
> .name == NULL. This value causes an oops in platform_device_register()
> later.
> 
> The following patch adds a mfd_cell for each possible mode thereby
> excluding .name assignment in runtime.
> 
> Signed-off-by: Denis Grigoryev 
> ---
>  drivers/mfd/tps6105x.c |   72 
> +---
>  1 file changed, 43 insertions(+), 29 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/tps6105x.c b/drivers/mfd/tps6105x.c
> index 5de95c2..182ebe0 100644
> --- a/drivers/mfd/tps6105x.c
> +++ b/drivers/mfd/tps6105x.c
> @@ -119,27 +119,47 @@ static int tps6105x_startup(struct tps6105x *tps6105x)
>  }
>  
>  /*
> - * MFD cells - we have one cell which is selected operation
> - * mode, and we always have a GPIO cell.
> + * MFD cells - we always have a GPIO cell and we have one cell
> + * which is selected operation mode.
>   */
> -static struct mfd_cell tps6105x_cells[] = {
> - {
> - /* name will be runtime assigned */
> - .id = -1,
> - },
> - {
> - .name = "tps6105x-gpio",
> - .id = -1,
> - },
> +static struct mfd_cell tps6105x_gpio_cell = {
> + .name = "tps6105x-gpio",
> +};
> +
> +static struct mfd_cell tps6105x_leds_cell = {
> + .name = "tps6105x-leds",
> +};
> +
> +static struct mfd_cell tps6105x_flash_cell = {
> + .name = "tps6105x-flash",
>  };
>  
> +static struct mfd_cell tps6105x_regulator_cell = {
> + .name = "tps6105x-regulator",
> +};
> +
> +static int tps6105x_add_device(struct tps6105x *tps6105x,
> +struct mfd_cell *cell)
> +{
> + cell->platform_data = tps6105x;
> + cell->pdata_size = sizeof(*tps6105x);
> +
> + return mfd_add_devices(>client->dev,
> +PLATFORM_DEVID_AUTO, cell, 1, NULL, 0, NULL);
> +}
> +
>  static int tps6105x_probe(struct i2c_client *client,
>   const struct i2c_device_id *id)
>  {
>   struct tps6105x *tps6105x;
>   struct tps6105x_platform_data   *pdata;
>   int ret;
> - int i;
> +
> + pdata = dev_get_platdata(>dev);
> + if (!pdata) {
> + dev_err(>dev, "missing platform data\n");
> + return -ENODEV;
> + }
>  
>   tps6105x = devm_kmalloc(>dev, sizeof(*tps6105x), GFP_KERNEL);
>   if (!tps6105x)
> @@ -147,7 +167,6 @@ static int tps6105x_probe(struct i2c_client *client,
>  
>   i2c_set_clientdata(client, tps6105x);
>   tps6105x->client = client;
> - pdata = dev_get_platdata(>dev);
>   tps6105x->pdata = pdata;
>   mutex_init(>lock);
>  
> @@ -157,38 +176,33 @@ static int tps6105x_probe(struct i2c_client *client,
>   return ret;
>   }
>  
> - /* Remove warning texts when you implement new cell drivers */
> + ret = tps6105x_add_device(tps6105x, _gpio_cell);
> + if (ret)
> + return ret;
> +
>   switch (pdata->mode) {
>   case TPS6105X_MODE_SHUTDOWN:
>   dev_info(>dev,
>"present, not used for anything, only GPIO\n");
>   break;
>   case TPS6105X_MODE_TORCH:
> - tps6105x_cells[0].name = "tps6105x-leds";
> - dev_warn(>dev,
> -  "torch mode is unsupported\n");
> + ret = tps6105x_add_device(tps6105x, _leds_cell);
>   break;
>   case TPS6105X_MODE_TORCH_FLASH:
> - tps6105x_cells[0].name = "tps6105x-flash";
> - dev_warn(>dev,
> -  "flash mode is unsupported\n");
> + ret = tps6105x_add_device(tps6105x, _flash_cell);
>   break;
>   case TPS6105X_MODE_VOLTAGE:
> - tps6105x_cells[0].name ="tps6105x-regulator";
> + ret = tps6105x_add_device(tps6105x, _regulator_cell);
>   break;
>   default:
> + dev_warn(>dev, "invalid mode: %d\n", pdata->mode);
>   break;
>   }
>  
> - /* Set up and register the platform devices. */
> - for (i = 0; i < ARRAY_SIZE(tps6105x_cells); i++) {
> - /* One state holder for all drivers, this is simple */
> - tps6105x_cells[i].platform_data = tps6105x;
> - tps6105x_cells[i].pdata_size = sizeof(*tps6105x);
> - }
> + if (ret)
> + mfd_remove_devices(>dev);
>  
> - return mfd_add_devices(>dev, 0, tps6105x_cells,
> -ARRAY_SIZE(tps6105x_cells), NULL, 0, NULL);
> + return ret;
>  }
>  
>  static int tps6105x_remove(struct i2c_client *client)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from 

Re: [RFC 0/2] VFIO: Add virtual MSI doorbell support.

[Christoffer Dall]

On Tue, Sep 22, 2015 at 11:09:14PM +0100, Marc Zyngier wrote:
> On Tue, 4 Aug 2015 06:52:01 +0100
> Bhushan Bharat  wrote:
> 
> > 
> > 
> > > -Original Message-
> > > From: Pranavkumar Sawargaonkar [mailto:pranavku...@linaro.org]
> > > Sent: Tuesday, August 04, 2015 11:18 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: k...@vger.kernel.org; Alex Williamson; kvm...@lists.cs.columbia.edu;
> > > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > christoffer.d...@linaro.org; marc.zyng...@arm.com; will.dea...@arm.com;
> > > bhelg...@google.com; a...@arndb.de; rob.herr...@linaro.org;
> > > eric.au...@linaro.org; patc...@apm.com; Yoder Stuart-B08248
> > > Subject: Re: [RFC 0/2] VFIO: Add virtual MSI doorbell support.
> > > 
> > > Hi Bharat,
> > > 
> > > On 28 July 2015 at 23:28, Alex Williamson 
> > > wrote:
> > > > On Tue, 2015-07-28 at 17:23 +, Bhushan Bharat wrote:
> > > >> Hi Alex,
> > > >>
> > > >> > -Original Message-
> > > >> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > >> > Sent: Tuesday, July 28, 2015 9:52 PM
> > > >> > To: Pranavkumar Sawargaonkar
> > > >> > Cc: k...@vger.kernel.org; kvm...@lists.cs.columbia.edu; linux-arm-
> > > >> > ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > >> > christoffer.d...@linaro.org; marc.zyng...@arm.com;
> > > >> > will.dea...@arm.com; bhelg...@google.com; a...@arndb.de;
> > > >> > rob.herr...@linaro.org; eric.au...@linaro.org; patc...@apm.com;
> > > >> > Bhushan Bharat-R65777; Yoder
> > > >> > Stuart-B08248
> > > >> > Subject: Re: [RFC 0/2] VFIO: Add virtual MSI doorbell support.
> > > >> >
> > > >> > On Fri, 2015-07-24 at 14:33 +0530, Pranavkumar Sawargaonkar wrote:
> > > >> > > In current VFIO MSI/MSI-X implementation, linux host kernel
> > > >> > > allocates MSI/MSI-X vectors when userspace requests through vfio
> > > ioctls.
> > > >> > > Vfio creates irqfd mappings to notify MSI/MSI-X interrupts to the
> > > >> > > userspace when raised.
> > > >> > > Guest OS will see emulated MSI/MSI-X controller and receives an
> > > >> > > interrupt when kernel notifies the same via irqfd.
> > > >> > >
> > > >> > > Host kernel allocates MSI/MSI-X using standard linux routines
> > > >> > > like
> > > >> > > pci_enable_msix_range() and pci_enable_msi_range().
> > > >> > > These routines along with requset_irq() in host kernel sets up
> > > >> > > MSI/MSI-X vectors with Physical MSI/MSI-X addresses provided by
> > > >> > > interrupt controller driver in host kernel.
> > > >> > >
> > > >> > > This means when a device is assigned with the guest OS, MSI/MSI-X
> > > >> > > addresses present in PCIe EP are the PAs programmed by the host
> > > >> > > linux
> > > >> > kernel.
> > > >> > >
> > > >> > > In x86 MSI/MSI-X physical address range is reserved and iommu is
> > > >> > > aware about these addreses and transalation is bypassed for these
> > > address range.
> > > >> > >
> > > >> > > Unlike x86, ARM/ARM64 does not reserve MSI/MSI-X Physical address
> > > >> > > range and all the transactions including MSI go through
> > > >> > > iommu/smmu
> > > >> > without bypass.
> > > >> > > This requires extending current vfio MSI layer with additional
> > > >> > > functionality for ARM/ARM64 by 1. Programing IOVA (referred as a
> > > >> > > MSI virtual doorbell address)
> > > >> > >in device's MSI vector as a MSI address.
> > > >> > >This IOVA will be provided by the userspace based on the
> > > >> > >MSI/MSI-X addresses reserved for the guest.
> > > >> > > 2. Create an IOMMU mapping between this IOVA and
> > > >> > >Physical address (PA) assigned to the MSI vector.
> > > >> > >
> > > >> > > This RFC is proposing a solution for MSI/MSI-X passthrough for
> > > >> > ARM/ARM64.
> > > >> >
> > > >> >
> > > >> > Hi Pranavkumar,
> > > >> >
> > > >> > Freescale has the same, or very similar, need, so any solution in
> > > >> > this space will need to work for both ARM and powerpc.  I'm not a
> > > >> > big fan of this approach as it seems to require the user to
> > > >> > configure MSI/X via ioctl and then call a separate ioctl mapping
> > > >> > the doorbells.  That's more code for the user, more code to get
> > > >> > wrong and potentially a gap between configuring MSI/X and enabling
> > > mappings where we could see IOMMU faults.
> > > >> >
> > > >> > If we know that doorbell mappings are required, why can't we set
> > > >> > aside a bank of IOVA space and have them mapped automatically as
> > > >> > MSI/X is being configured?  Then the user's need for special
> > > >> > knowledge and handling of this case is limited to setup.  The IOVA
> > > >> > space will be mapped and used as needed, we only need the user to
> > > >> > specify the IOVA space reserved for this.  Thanks,
> > > >>
> > > >> We probably need a mix of both to support Freescale PowerPC and ARM
> > > >> based machines.
> > > >> In this mix mode kernel vfio driver will reserve some IOVA 

Re: [PATCH] xen/pvhvm: add soft reset on kexec/kdump support

[Boris Ostrovsky]

On 09/25/2015 12:07 PM, Vitaly Kuznetsov wrote:

Also, I am not sure I see how this new op will be used in the
hypervisor --- currently AFAICS it is only processed under
is_hardware_domain(). Are there other patches that will support HVM
guests?

Please see my Xen series:
http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg00547.html
(last 'full' submission).

All patches from my 'toolstack-assisted approach to PVHVM guest kexec'
are already merged to xen.git (first 10 are already in 'master' and the
last one is in 'staging').




OK, so I was looking at the right tree. Then I don't understand how 
SHUTDOWN_soft_reset would be reached for a non-privileged domain. The 
only path that I see is


domain_shutdown()
{
...
if ( is_hardware_domain(d) )
hwdom_shutdown(reason);
...
}

Is there another path to handle this op?

Thanks.
-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma-debug: Allow poisoning nonzero allocations

[Robin Murphy]

Hi Russell,

On 25/09/15 13:44, Russell King - ARM Linux wrote:

On Fri, Sep 25, 2015 at 01:15:46PM +0100, Robin Murphy wrote:

Since some dma_alloc_coherent implementations return a zeroed buffer
regardless of whether __GFP_ZERO is passed, there exist drivers which
are implicitly dependent on this and pass otherwise uninitialised
buffers to hardware. This can lead to subtle and awkward-to-debug issues
using those drivers on different platforms, where nonzero uninitialised
junk may for instance occasionally look like a valid command which
causes the hardware to start misbehaving. To help with debugging such
issues, add the option to make uninitialised buffers much more obvious.


The reason people started to do this is to stop a security leak in the
ALSA code: ALSA allocates the ring buffer with dma_alloc_coherent()
which used to grab pages and return them uninitialised.  These pages
could contain anything - including the contents of /etc/shadow, or
your bank details.

ALSA then lets userspace mmap() that memory, which means any user process
which has access to the sound devices can read data leaked from kernel
memory.

I think I did bring it up at the time I found it, and decided that the
safest thing to do was to always return an initialised buffer - short of
constantly auditing every dma_alloc_coherent() user which also mmap()s
the buffer into userspace, I couldn't convince myself that it was safe
to avoid initialising the buffer.

I don't know whether the original problem still exists in ALSA or not,
but I do know that there are dma_alloc_coherent() implementations out
there which do not initialise prior to returning memory.


Indeed, I think we've discussed this before, and I don't imagine we'll 
be changing the actual behaviour of the existing allocators any time soon.


[ I still don't see that as an excuse for callers not to be fixed, 
though - anyone allocating something that may be exposed to userspace 
has a responsibility to initialise it appropriately. After all, the DMA 
API is just one source, what do we do if such a careless subsystem got 
some uninitialised pages of leftover sensitive data from, say, 
alloc_pages() instead? ]


That's a bit of a separate issue though. If a driver itself _needs_ a 
zeroed buffer but doesn't specifically request one, or doesn't get one 
even if it did, then that's just a regular bug, and it's what this patch 
is intended to help weed out. We've no need for a special poison value 
for data protection in the general case; zero is just fine for that.



diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 908fb35..40514ed 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -30,6 +30,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 

  #include 
@@ -1447,7 +1448,7 @@ void debug_dma_unmap_sg(struct device *dev, struct 
scatterlist *sglist,
  EXPORT_SYMBOL(debug_dma_unmap_sg);

  void debug_dma_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t dma_addr, void *virt)
+ dma_addr_t dma_addr, void *virt, gfp_t flags)
  {
struct dma_debug_entry *entry;

@@ -1457,6 +1458,9 @@ void debug_dma_alloc_coherent(struct device *dev, size_t 
size,
if (unlikely(virt == NULL))
return;

+   if (IS_ENABLED(CONFIG_DMA_API_DEBUG_POISON) && !(flags & __GFP_ZERO))
+   memset(virt, DMA_ALLOC_POISON, size);
+


This is likely to be slow in the case of non-cached memory and large
allocations.  The config option should come with a warning.


It depends on DMA_API_DEBUG, which already has a stern performance 
warning, is additionally hidden behind EXPERT, and carries a slightly 
flippant yet largely truthful warning that actually using it could break 
pretty much every driver in your system; is that not enough?


If I was feeling particularly antagonistic, I'd also point out that as 
discussed above you've already taken the hit of a memset(0) and cache 
flush that you _didn't_ ask for, and there was no warning on that ;)


The intent is a specific troubleshooting tool - realistically it's 
probably only usable at all when restricting DMA debug to a per-driver 
basis. My hunch is that nobody's too fussed about the performance of a 
driver that doesn't work properly, especially once they've reached the 
point of dumping buffers in an attempt to figure out why, when seeing 
the presence or not of uniform poison values could be helpful.


(Of course, sometimes you end up debugging the allocator itself - see 
commit 7132813c3845 - which was one of the motivating factors for this 
patch).


Robin.

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

Re: [PATCH v4 1/7] fs: Add user namesapace member to struct super_block

[Eric W. Biederman]

Seth Forshee  writes:

> On Thu, Sep 24, 2015 at 04:14:33PM -0500, Eric W. Biederman wrote:
>> Seth Forshee  writes:
>> 
>> > Initially this will be used to eliminate the implicit MNT_NODEV
>> > flag for mounts from user namespaces. In the future it will also
>> > be used for translating ids and checking capabilities for
>> > filesystems mounted from user namespaces.
>> >
>> > s_user_ns is initialized in alloc_super() and is generally set to
>> > current_user_ns(). To avoid security and corruption issues, two
>> > additional mount checks are also added:
>> >
>> >  - do_new_mount() gains a check that the user has CAP_SYS_ADMIN
>> >in current_user_ns().
>> >
>> >  - sget() will fail with EBUSY when the filesystem it's looking
>> >for is already mounted from another user namespace.
>> >
>> > proc requires some special handling. The user namespace of
>> > current isn't appropriate when forking as a result of clone (2)
>> > with CLONE_NEWPID|CLONE_NEWUSER, as it will set s_user_ns to the
>> > namespace of the parent and make proc unmountable in the new user
>> > namespace. Instead, the user namespace which owns the new pid
>> > namespace is used. sget_userns() is allowed to allow passing in
>> > a namespace other than that of current, and sget becomes a
>> > wrapper around sget_userns() which passes current_user_ns().
>> 
>> Minor nits below.  I have fixed them up.
>> 
>> > Signed-off-by: Seth Forshee 
>> > ---
>> >  fs/namespace.c |  3 +++
>> >  fs/proc/root.c |  3 ++-
>> >  fs/super.c | 38 +-
>> >  include/linux/fs.h |  9 -
>> >  4 files changed, 46 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/fs/namespace.c b/fs/namespace.c
>> > index 0570729c87fd..d023a353dc63 100644
>> > --- a/fs/namespace.c
>> > +++ b/fs/namespace.c
>> > @@ -2381,6 +2381,9 @@ static int do_new_mount(struct path *path, const 
>> > char *fstype, int flags,
>> >struct vfsmount *mnt;
>> >int err;
>> >  
>> > +  if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN))
>> > +  return -EPERM;
>> > +
>> >if (!fstype)
>> >return -EINVAL;
>> >  
>> > diff --git a/fs/proc/root.c b/fs/proc/root.c
>> > index 361ab4ee42fc..4b302cbf13f9 100644
>> > --- a/fs/proc/root.c
>> > +++ b/fs/proc/root.c
>> > @@ -117,7 +117,8 @@ static struct dentry *proc_mount(struct 
>> > file_system_type *fs_type,
>> >return ERR_PTR(-EPERM);
>> >}
>> >  
>> > -  sb = sget(fs_type, proc_test_super, proc_set_super, flags, ns);
>> > +  sb = sget_userns(fs_type, proc_test_super, proc_set_super, flags,
>> > +   ns->user_ns, ns);
>> >if (IS_ERR(sb))
>> >return ERR_CAST(sb);
>> >  
>> > diff --git a/fs/super.c b/fs/super.c
>> > index 954aeb80e202..42837da7d641 100644
>> > --- a/fs/super.c
>> > +++ b/fs/super.c
>> > @@ -33,6 +33,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >  #include "internal.h"
>> >  
>> >  
>> > @@ -163,6 +164,7 @@ static void destroy_super(struct super_block *s)
>> >  {
>> >list_lru_destroy(>s_dentry_lru);
>> >list_lru_destroy(>s_inode_lru);
>> > +  put_user_ns(s->s_user_ns);
>> >security_sb_free(s);
>> >WARN_ON(!list_empty(>s_mounts));
>> >kfree(s->s_subtype);
>> > @@ -178,7 +180,8 @@ static void destroy_super(struct super_block *s)
>> >   *Allocates and initializes a new  super_block.  
>> > alloc_super()
>> >   *returns a pointer new superblock or %NULL if allocation had 
>> > failed.
>> >   */
>> > -static struct super_block *alloc_super(struct file_system_type *type, int 
>> > flags)
>> > +static struct super_block *alloc_super(struct file_system_type *type, int 
>> > flags,
>> > + struct user_namespace *user_ns)
>> >  {
>> >struct super_block *s = kzalloc(sizeof(struct super_block),  GFP_USER);
>> >static const struct super_operations default_op;
>> > @@ -246,6 +249,8 @@ static struct super_block *alloc_super(struct 
>> > file_system_type *type, int flags)
>> >s->s_shrink.count_objects = super_cache_count;
>> >s->s_shrink.batch = 1024;
>> >s->s_shrink.flags = SHRINKER_NUMA_AWARE | SHRINKER_MEMCG_AWARE;
>> > +
>> > +  s->s_user_ns = get_user_ns(user_ns);
>> >return s;
>> >  
>> >  fail:
>> > @@ -442,17 +447,17 @@ void generic_shutdown_super(struct super_block *sb)
>> >  EXPORT_SYMBOL(generic_shutdown_super);
>> >  
>> >  /**
>> > - *sget-   find or create a superblock
>> > + *sget_userns -   find or create a superblock
>> >   *@type:  filesystem type superblock should belong to
>> >   *@test:  comparison callback
>> >   *@set:   setup callback
>> >   *@flags: mount flags
>> 
>> You don't mention the user namespace parameter here.  I have fixed that
>> as.
>> 
>>   + * @user_ns: User namespace you need CAP_SYS_ADMIN over to mount this 
>> fs.
>

Re: [PATCH 3/5] UBI: switch the UBI device in read-only mode when mtd returns -EROFS

[Richard Weinberger]

Am 25.09.2015 um 17:09 schrieb Boris Brezillon:
> The NAND layer is now able to forward power-cut emulation errors from
> a NAND driver to the MTD user.
> Check for this kind of errors in UBI and switch the UBI device in read-only
> mode if such an error occurs.
> The error will also be forwarded to the UBI user requesting the operation
> if any, thus allowing UBIFS to act accordingly.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/mtd/ubi/io.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
> index 5bbd1f0..c5ebef7 100644
> --- a/drivers/mtd/ubi/io.c
> +++ b/drivers/mtd/ubi/io.c
> @@ -303,6 +303,8 @@ int ubi_io_write(struct ubi_device *ubi, const void *buf, 
> int pnum, int offset,
>   len = ubi->peb_size - offset;
>   if (len)
>   err = ubi_self_check_all_ff(ubi, pnum, offset, len);
> + } else if (err == -EROFS) {
> + ubi_ro_mode(ubi);
>   }
>  
>   return err;
> @@ -355,7 +357,7 @@ retry:
>  
>   err = mtd_erase(ubi->mtd, );
>   if (err) {
> - if (retries++ < UBI_IO_RETRIES) {
> + if (err != -EROFS && retries++ < UBI_IO_RETRIES) {

Looks good! :)
One small nit, can you please add a comment above both lines that the EROFS 
checks are
here because of emulators.

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

[GIT PULL] Btrfs

[Chris Mason]

Hi Linus,

My for-linus-4.3 branch has a few fixes:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git 
for-linus-4.3

This is an assorted set I've been queuing up:

Jeff Mahoney tracked down a tricky one where we ended up starting IO on
the wrong mapping for special files in btrfs_evict_inode.  A few people
reported this one on the list.

Filipe found (and provided a test for) a difficult bug in reading
compressed extents, and Josef fixed up some quota record keeping with
snapshot deletion.  Chandan killed off an accounting bug during DIO that
lead to WARN_ONs as we freed inodes.

Filipe Manana (3) commits (+58/-16):
Btrfs: remove unnecessary locking of cleaner_mutex to avoid deadlock (+0/-4)
Btrfs: don't initialize a space info as full to prevent ENOSPC (+1/-4)
Btrfs: fix read corruption of compressed and shared extents (+57/-8)

Josef Bacik (1) commits (+37/-2):
Btrfs: keep dropped roots in cache until transaction commit

Jeff Mahoney (1) commits (+2/-1):
btrfs: skip waiting on ordered range for special files

chandan (1) commits (+21/-23):
Btrfs: Direct I/O: Fix space accounting

Total: (6) commits (+118/-42)

 fs/btrfs/btrfs_inode.h |  2 --
 fs/btrfs/disk-io.c |  2 --
 fs/btrfs/extent-tree.c |  7 ++
 fs/btrfs/extent_io.c   | 65 +++---
 fs/btrfs/inode.c   | 45 +-
 fs/btrfs/super.c   |  2 --
 fs/btrfs/transaction.c | 32 +
 fs/btrfs/transaction.h |  5 +++-
 8 files changed, 118 insertions(+), 42 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm64: Add support for PTE contiguous bit.

[Steve Capper]

On 21 September 2015 at 09:44, David Woods  wrote:
>
> Steve,

Hi Dave,

>
> Thanks for your review and comments.  I take your points about the 16k
> granule - it's helpful to know that support is in the works. However, I'm
> not sure I agree with your reading of section 4.4.2. It's clear that for 16k
> granules, the number of contiguous pages is different for the PTE and PMD
> levels.  But I don't see anywhere it says that for 4K and 64K that the
> contig bit is not supported at the PMD level - just that the number of
> contiguous pages is the same at each level.

Many apologies, I appear to have led you down the garden path there.
Having double checked at ARM, the valid contiguous page sizes are indeed:
4K granule:
16 x ptes = 64K
16 x pmds = 32M
16 x puds = 16G

16K granule:
128 x ptes = 2M
32 x pmds = 1G

64K granule:
32 x ptes = 2M
32 x pmds = 16G

>
> I tried using the tarmac trace module of the ARM simulator to support this
> idea by turning on MMU tracing.  Using 4k granule, I created 64k and 32m
> pages and touched each location in the page.  In both cases, the trace
> recorded just one TLB fill (rather than the 16 you'd expect if the
> contiguous bit were being ignored) and it indicated the expected page size.
>
> 1817498494 clk cpu2 TLB FILL cpu2.S1TLB 64K 0x20_NS vmid=0, nG
> asid=303:0x08fa36_NS Normal InnerShareable Inner=WriteBackWriteAllocate
> Outer=WriteBackWriteAllocate xn=0 pxn=1 ContiguousHint=1
>
> 1263366314 clk cpu2 TLB FILL cpu2.UTLB 32M 0x20_NS vmid=0, nG
> asid=300:0x08f600_NS Normal InnerShareable Inner=WriteBackWriteAllocate
> Outer=WriteBackWriteAllocate xn=0 pxn=1 ContiguousHint=1
>
> I'll try this with a 64k granule next.  I'm not sure what will happen with
> 16G pages since we are using an A53 model which I don't think supports such
> large pages.

The Cortex-A53 supported TLB sizes can be found in the TRM:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500f/Chddiifa.html

My understanding is that the core is allowed to ignore the contiguous
bit if it doesn't support the particular TLB entry size, or substitute
in a slightly smaller TLB entry than hinted possible. Anyway, do give
it a go :-).

Cheers,
--
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/8] spi: imx: Add support for SPI Slave mode for imx53 and imx6 chips

[Anton Bondarenko]

Currently i.MX SPI controller only works in Master mode.
This patch adds support to work also in Slave mode by adding
"fsl,spi-slave-mode" in corresponding ecspi node in devicetree.

Currently SPI Slave mode support patch has the following limitations:
1. The stale data in RXFIFO will be dropped when the Slave does any new
   transfer.
2. One transfer can be finished only after all transfer->len data been
   transferred to master device
3. Slave device only accepts transfer->len data. Any data longer than this
   from master device will be dropped. Any data shorter than this from
   master will cause SPI to stuck du to mentioned HW limitation 2.

Following HW limitation applies:
1.  ECSPI has a HW issue when works in Slave mode, after 64
words written to TXFIFO, even TXFIFO becomes empty,
ECSPI_TXDATA keeps shift out the last word data,
so we have to disable ECSPI when in slave mode after the
transfer completes
2.  Due to Freescale errata ERR003775 "eCSPI: Burst completion by Chip
Select (SS) signal in Slave mode is not functional" burst size must
be set exactly to the size of the transfer. This limit SPI transaction
with maximum 2^12 bits.

Signed-off-by: Jiada Wang 
Signed-off-by: Muzaffar Mahmood 
Signed-off-by: Anton Bondarenko 
---
 .../devicetree/bindings/spi/fsl-imx-cspi.txt   |   1 +
 drivers/spi/spi-imx.c  | 169 ++---
 2 files changed, 146 insertions(+), 24 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt 
b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
index 425485f..ffe28f2 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
@@ -15,6 +15,7 @@ Required properties:
 - interrupts : Should contain CSPI/eCSPI interrupt
 - fsl,spi-num-chipselects : Contains the number of the chipselect
 - cs-gpios : Specifies the gpio pins to be used for chipselects.
+- fsl,spi-slave-mode : Indicate the spi controller works in Slave mode.
 - clocks : Clock specifiers for both ipg and per clocks.
 - clock-names : Clock names should include both "ipg" and "per"
 See the clock consumer binding,
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 1bf0739a..f271d1e 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -55,6 +55,7 @@
 /* generic defines to abstract from the different register layouts */
 #define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */
 #define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */
+#define MXC_INT_RDRBIT(4) /* Receive date threshold interrupt */
 #define MXC_INT_TCEN   BIT(7)   /* Transfer complete */
 
 /* The maximum  bytes that a sdma BD can transfer.*/
@@ -84,6 +85,7 @@ struct spi_imx_devtype_data {
void (*trigger)(struct spi_imx_data *);
int (*rx_available)(struct spi_imx_data *);
void (*reset)(struct spi_imx_data *);
+   void (*disable)(struct spi_imx_data *);
enum spi_imx_devtype devtype;
 };
 
@@ -108,6 +110,10 @@ struct spi_imx_data {
const void *tx_buf;
unsigned int txfifo; /* number of words pushed in tx FIFO */
 
+   unsigned int slave_mode;
+   unsigned int slave_burst;
+   unsigned int total_count;
+
/* DMA */
unsigned int dma_is_inited;
unsigned int dma_finished;
@@ -248,6 +254,7 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_INT 0x10
 #define MX51_ECSPI_INT_TEEN(1 <<  0)
 #define MX51_ECSPI_INT_RREN(1 <<  3)
+#define MX51_ECSPI_INT_RDREN   BIT(4)
 #define MX51_ECSPI_INT_TCENBIT(7)
 
 #define MX51_ECSPI_DMA  0x14
@@ -268,6 +275,52 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_TEST0x20
 #define MX51_ECSPI_LOOPBIT(31)
 
+static void mx53_ecspi_rx_slave(struct spi_imx_data *spi_imx)
+{
+   u32 val = be32_to_cpu(readl(spi_imx->base + MXC_CSPIRXDATA));
+
+   if (spi_imx->rx_buf) {
+   int shift = spi_imx->slave_burst % sizeof(val);
+
+   if (shift) {
+   memcpy(spi_imx->rx_buf,
+  ((u8 *)) + sizeof(val) - shift, shift);
+   } else {
+   *((u32 *)spi_imx->rx_buf) = val;
+   shift = sizeof(val);
+   }
+
+   spi_imx->rx_buf += shift;
+   spi_imx->slave_burst -= shift;
+   }
+}
+
+static void mx53_ecspi_tx_slave(struct spi_imx_data *spi_imx)
+{
+   u32 val = 0;
+   int shift = spi_imx->count % sizeof(val);
+
+   if (spi_imx->tx_buf) {
+   if (shift) {
+   memcpy(((u8 *)) + sizeof(val) - shift,
+  spi_imx->tx_buf, shift);
+ 

[PATCH v2 6/8] spi: imx: return error from dma channel request

[Anton Bondarenko]

On SDMA initialization return exactly the same error, which is
reported by dma_request_slave_channel_reason(), it is a preceding
change to defer SPI DMA initialization, if SDMA module is not yet
available.

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Anton Bondarenko 
---
 drivers/spi/spi-imx.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 4b3c16e..44d3cf0 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -929,18 +929,20 @@ static int spi_imx_sdma_init(struct device *dev, struct 
spi_imx_data *spi_imx,
spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
 
/* Prepare for TX DMA: */
-   master->dma_tx = dma_request_slave_channel(dev, "tx");
-   if (!master->dma_tx) {
-   dev_err(dev, "cannot get the TX DMA channel!\n");
-   ret = -EINVAL;
+   master->dma_tx = dma_request_slave_channel_reason(dev, "tx");
+   if (IS_ERR(master->dma_tx)) {
+   dev_info(dev, "cannot get the TX DMA channel!\n");
+   ret = PTR_ERR(master->dma_tx);
+   master->dma_tx = NULL;
goto err;
}
 
/* Prepare for RX : */
-   master->dma_rx = dma_request_slave_channel(dev, "rx");
-   if (!master->dma_rx) {
-   dev_dbg(dev, "cannot get the DMA channel.\n");
-   ret = -EINVAL;
+   master->dma_rx = dma_request_slave_channel_reason(dev, "rx");
+   if (IS_ERR(master->dma_rx)) {
+   dev_info(dev, "cannot get the DMA channel.\n");
+   ret = PTR_ERR(master->dma_rx);
+   master->dma_rx = NULL;
goto err;
}
 
-- 
2.5.2

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

[PATCH v2 1/8] spi: imx: Fix DMA transfer

[Anton Bondarenko]

RX DMA tail data handling doesn't work correctly in many cases with
current implementation. It happens because SPI core was setup
to generates both RX watermark level and RX DATA TAIL events
incorrectly. SPI transfer triggering for DMA also done in wrong way.

SPI client wants to transfer 70 words for example. The old DMA
implementation setup RX DATA TAIL equal 6 words. In this case
RX DMA event will be generated after 6 words read from RX FIFO.
The garbage can be read out from RX FIFO because SPI HW does
not receive all required words to trigger RX watermark event.

New implementation change handling of RX data tail. DMA is used to process
all TX data and only full chunks of RX data with size aligned to FIFO/2.
Driver is waiting until both TX and RX DMA transaction done and all
TX data are pushed out. At that moment there is only RX data tail in
the RX FIFO. This data read out using PIO.

Transfer triggering changed to avoid RX data loss.

Signed-off-by: Anton Bondarenko 
---
 drivers/spi/spi-imx.c | 105 +++---
 1 file changed, 66 insertions(+), 39 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index f9deb84..165bc2c 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -39,6 +39,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 
@@ -53,6 +55,7 @@
 /* generic defines to abstract from the different register layouts */
 #define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */
 #define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */
+#define MXC_INT_TCEN   BIT(7)   /* Transfer complete */
 
 /* The maximum  bytes that a sdma BD can transfer.*/
 #define MAX_SDMA_BD_BYTES  (1 << 15)
@@ -104,9 +107,7 @@ struct spi_imx_data {
unsigned int dma_is_inited;
unsigned int dma_finished;
bool usedma;
-   u32 rx_wml;
-   u32 tx_wml;
-   u32 rxt_wml;
+   u32 wml;
struct completion dma_rx_completion;
struct completion dma_tx_completion;
 
@@ -201,9 +202,8 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 {
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
 
-   if (spi_imx->dma_is_inited
-   && transfer->len > spi_imx->rx_wml * sizeof(u32)
-   && transfer->len > spi_imx->tx_wml * sizeof(u32))
+   if (spi_imx->dma_is_inited &&
+   (transfer->len > spi_imx->wml * sizeof(u32)))
return true;
return false;
 }
@@ -228,6 +228,7 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_INT 0x10
 #define MX51_ECSPI_INT_TEEN(1 <<  0)
 #define MX51_ECSPI_INT_RREN(1 <<  3)
+#define MX51_ECSPI_INT_TCENBIT(7)
 
 #define MX51_ECSPI_DMA  0x14
 #define MX51_ECSPI_DMA_TX_WML_OFFSET   0
@@ -292,6 +293,9 @@ static void __maybe_unused mx51_ecspi_intctrl(struct 
spi_imx_data *spi_imx, int
if (enable & MXC_INT_RR)
val |= MX51_ECSPI_INT_RREN;
 
+   if (enable & MXC_INT_TCEN)
+   val |= MX51_ECSPI_INT_TCEN;
+
writel(val, spi_imx->base + MX51_ECSPI_INT);
 }
 
@@ -311,8 +315,9 @@ static void __maybe_unused mx51_ecspi_trigger(struct 
spi_imx_data *spi_imx)
 static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
struct spi_imx_config *config)
 {
-   u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0, dma = 0;
-   u32 tx_wml_cfg, rx_wml_cfg, rxt_wml_cfg;
+   u32 ctrl = MX51_ECSPI_CTRL_ENABLE, dma = 0;
+   u32 cfg = readl(spi_imx->base + MX51_ECSPI_CONFIG);
+
u32 clk = config->speed_hz, delay;
 
/*
@@ -369,19 +374,10 @@ static int __maybe_unused mx51_ecspi_config(struct 
spi_imx_data *spi_imx,
 * and enable DMA request.
 */
if (spi_imx->dma_is_inited) {
-   dma = readl(spi_imx->base + MX51_ECSPI_DMA);
-
-   spi_imx->rxt_wml = spi_imx_get_fifosize(spi_imx) / 2;
-   rx_wml_cfg = spi_imx->rx_wml << MX51_ECSPI_DMA_RX_WML_OFFSET;
-   tx_wml_cfg = spi_imx->tx_wml << MX51_ECSPI_DMA_TX_WML_OFFSET;
-   rxt_wml_cfg = spi_imx->rxt_wml << MX51_ECSPI_DMA_RXT_WML_OFFSET;
-   dma = (dma & ~MX51_ECSPI_DMA_TX_WML_MASK
-  & ~MX51_ECSPI_DMA_RX_WML_MASK
-  & ~MX51_ECSPI_DMA_RXT_WML_MASK)
-  | rx_wml_cfg | tx_wml_cfg | rxt_wml_cfg
-  |(1 << MX51_ECSPI_DMA_TEDEN_OFFSET)
-  |(1 << MX51_ECSPI_DMA_RXDEN_OFFSET)
-  |(1 << MX51_ECSPI_DMA_RXTDEN_OFFSET);
+   dma = (spi_imx->wml - 1) << MX51_ECSPI_DMA_RX_WML_OFFSET
+ | (spi_imx->wml - 1) << MX51_ECSPI_DMA_TX_WML_OFFSET
+ | (1 << MX51_ECSPI_DMA_TEDEN_OFFSET)
+ | (1 << MX51_ECSPI_DMA_RXDEN_OFFSET);
 

[PATCH v2 3/8] spi: imx: add support for all SPI word width for DMA transfer

[Anton Bondarenko]

DMA transfer for SPI was limited to up to 8 bits word size until now.
Sync in SPI burst size and DMA bus width is necessary to correctly
support other BPW supported by HW.

Signed-off-by: Anton Bondarenko 
---
 drivers/spi/spi-imx.c | 121 --
 1 file changed, 87 insertions(+), 34 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 6c98eda..d9b730d 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -91,11 +91,15 @@ struct spi_imx_data {
 
struct completion xfer_done;
void __iomem *base;
+   unsigned long base_phys;
+
struct clk *clk_per;
struct clk *clk_ipg;
unsigned long spi_clk;
unsigned int spi_bus_clk;
 
+   unsigned int bpw_w;
+
unsigned int count;
void (*tx)(struct spi_imx_data *);
void (*rx)(struct spi_imx_data *);
@@ -201,9 +205,13 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 struct spi_transfer *transfer)
 {
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+   unsigned int bpw_w = transfer->bits_per_word;
 
-   if (spi_imx->dma_is_inited &&
-   (transfer->len > spi_imx->wml * sizeof(u32)))
+   if (!bpw_w)
+   bpw_w = spi->bits_per_word;
+
+   bpw_w = DIV_ROUND_UP(bpw_w, 8);
+   if (spi_imx->dma_is_inited && (transfer->len > spi_imx->wml * bpw_w))
return true;
return false;
 }
@@ -761,11 +769,62 @@ static irqreturn_t spi_imx_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+static int spi_imx_sdma_configure(struct spi_master *master)
+{
+   int ret;
+   enum dma_slave_buswidth dsb_default = DMA_SLAVE_BUSWIDTH_1_BYTE;
+   struct dma_slave_config slave_config = {};
+   struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+
+   switch (spi_imx->bpw_w) {
+   case 4:
+   dsb_default = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   break;
+   case 2:
+   dsb_default = DMA_SLAVE_BUSWIDTH_2_BYTES;
+   break;
+   case 1:
+   dsb_default = DMA_SLAVE_BUSWIDTH_1_BYTE;
+   break;
+   default:
+   pr_err("Not supported word size %d\n", spi_imx->bpw_w);
+   ret = -EINVAL;
+   goto err;
+   }
+
+   slave_config.direction = DMA_MEM_TO_DEV;
+   slave_config.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
+   slave_config.dst_addr_width = dsb_default;
+   slave_config.dst_maxburst = spi_imx_get_fifosize(spi_imx)
+   - spi_imx->wml;
+   ret = dmaengine_slave_config(master->dma_tx, _config);
+   if (ret) {
+   pr_err("error in TX dma configuration.\n");
+   goto err;
+   }
+
+   memset(_config, 0, sizeof(slave_config));
+
+   slave_config.direction = DMA_DEV_TO_MEM;
+   slave_config.src_addr = spi_imx->base_phys + MXC_CSPIRXDATA;
+   slave_config.src_addr_width = dsb_default;
+   slave_config.src_maxburst = spi_imx_get_fifosize(spi_imx)
+   - spi_imx->wml;
+   ret = dmaengine_slave_config(master->dma_rx, _config);
+   if (ret)
+   pr_err("error in RX dma configuration.\n");
+
+err:
+   return ret;
+}
+
 static int spi_imx_setupxfer(struct spi_device *spi,
 struct spi_transfer *t)
 {
struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
struct spi_imx_config config;
+   unsigned int bpw_w_new;
+   int ret = 0;
 
config.bpw = t ? t->bits_per_word : spi->bits_per_word;
config.speed_hz  = t ? t->speed_hz : spi->max_speed_hz;
@@ -789,9 +848,18 @@ static int spi_imx_setupxfer(struct spi_device *spi,
spi_imx->tx = spi_imx_buf_tx_u32;
}
 
-   spi_imx->devtype_data->config(spi_imx, );
+   bpw_w_new = DIV_ROUND_UP(config.bpw, 8);
+   if (spi_imx->dma_is_inited && spi_imx->bpw_w != bpw_w_new) {
+   spi_imx->bpw_w = bpw_w_new;
+   ret = spi_imx_sdma_configure(spi->master);
+   if (ret != 0)
+   pr_err("Can't configure SDMA, error %d\n", ret);
+   }
 
-   return 0;
+   if (!ret)
+   ret = spi_imx->devtype_data->config(spi_imx, );
+
+   return ret;
 }
 
 static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
@@ -812,10 +880,8 @@ static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
 }
 
 static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
-struct spi_master *master,
-const struct resource *res)
+struct spi_master *master)
 {
-   struct dma_slave_config slave_config = {};
int ret;
 
/* use pio mode for i.mx6dl chip TKT238285 */
@@ 

Re: [PATCH v2 0/2] ASoC: atmel-classd: add driver for Atmel CLASSD

[Mark Brown]

On Thu, Sep 24, 2015 at 01:41:25PM +0800, Songjun Wu wrote:

> Songjun Wu (2):
>   ASoC: atmel-classd: add the Audio Class D Amplifier
>   ASoC: atmel-classd: DT binding for Class D audio amplifier driver

I don't seem to have the second patch with the binding documentation.


signature.asc
Description: Digital signature

Re: [PATCH] richacl: Possible other write-through fix

[Andreas Gruenbacher]

2015-09-24 20:33 GMT+02:00 J. Bruce Fields :
> On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote:
>> +int
>> +richacl_apply_masks(struct richacl **acl, kuid_t owner)
>> +{
>> + if ((*acl)->a_flags & RICHACL_MASKED) {
>> + struct richacl_alloc alloc = {
>> + .acl = richacl_clone(*acl, GFP_KERNEL),
>> + .count = (*acl)->a_count,
>> + };
>> + if (!alloc.acl)
>> + return -ENOMEM;
>> +
>> + if (richacl_move_everyone_aces_down() ||
>> + richacl_propagate_everyone() ||
>> + __richacl_apply_masks(, owner) ||
>> + richacl_set_owner_permissions() ||
>> + richacl_set_other_permissions() ||
>
> Hm, I'm a little unsure about this step: it seems like the one step that
> can actually change the permissions (making them more permissive, in
> this case), whereas the others are neutral.
>
> The following two steps should fix that, but I'm not sure they do.
>
> E.g. if I have an ACL like
>
> mask 0777, WRITE_THROUGH
> GROUP@:r--::allow
>
> I think it should result in
>
> OWNER@:   rwx::allow
> GROUP@:   -wx::deny
> GROUP@:   r--::allow
> EVERYONE@:rwx::allow
>
> But does the GROUP@ deny actually get in there?  It looks to me like the
> denies inserted by richacl_isolate_group_class only take into account
> the group mask, not the actual permissions granted to any group class
> user.
>
> I may be mising something.

Thanks for the test case and analysis. The group@ deny ace that should be
inserted here actually doesn't get inserted. I'm attaching a fix.

---

By the way, all those scenarios can easily be tries out using the test
suite in the user-space richacl package, even without a richacl enabled
kernel. In this case, without the fix, we get:

  $ make tests/richacl-apply-masks
  $ tests/richacl-apply-masks -m 777 group@:r::allow
  group@:r::allow
  everyone@:rwpx::allow

With the fix, we are now getting:

  $ tests/richacl-apply-masks -m 777 group@:r::allow
  owner@:rwpx::allow
  group@:r::allow
  group@:wpx::deny
  everyone@:rwpx::allow

Thanks,
Andreas

diff --git a/fs/richacl_compat.c b/fs/richacl_compat.c
index 726d796..bc0bcfe 100644
--- a/fs/richacl_compat.c
+++ b/fs/richacl_compat.c
@@ -463,23 +463,28 @@ richacl_set_owner_permissions(struct richacl_alloc *alloc)
 
 /**
  * richacl_set_other_permissions  -  set the other permissions to the other 
mask
+ * @alloc: acl and number of allocated entries
+ * @added: permissions added for everyone@
  *
  * Change the acl so that everyone@ is granted the permissions set in the other
  * mask.  This leaves at most one efective everyone@ allow entry at the end of
- * the acl.
+ * the acl.  If everyone@ end up being granted additional permissions, these
+ * permissions are returned in @added.
  */
 static int
-richacl_set_other_permissions(struct richacl_alloc *alloc)
+richacl_set_other_permissions(struct richacl_alloc *alloc, unsigned int *added)
 {
struct richacl *acl = alloc->acl;
unsigned int x = RICHACE_POSIX_ALWAYS_ALLOWED;
unsigned int other_mask = acl->a_other_mask & ~x;
-   struct richace *ace = acl->a_entries + acl->a_count - 1;
+   struct richace *ace;
 
if (!(other_mask &&
  (acl->a_flags & RICHACL_WRITE_THROUGH)))
return 0;
 
+   *added = other_mask;
+   ace = acl->a_entries + acl->a_count - 1;
if (acl->a_count == 0 ||
!richace_is_everyone(ace) ||
richace_is_inherit_only(ace)) {
@@ -490,8 +495,10 @@ richacl_set_other_permissions(struct richacl_alloc *alloc)
ace->e_flags = RICHACE_SPECIAL_WHO;
ace->e_mask = other_mask;
ace->e_id.special = RICHACE_EVERYONE_SPECIAL_ID;
-   } else
+   } else {
+   *added &= ~ace->e_mask;
richace_change_mask(alloc, , other_mask);
+   }
return 0;
 }
 
@@ -645,6 +652,7 @@ __richacl_isolate_who(struct richacl_alloc *alloc, struct 
richace *who,
 /**
  * richacl_isolate_group_class  -  limit the group class to the group file mask
  * @alloc: acl and number of allocated entries
+ * @deny:  additional permissions to deny
  *
  * POSIX requires that after a chmod, the group class is granted no more
  * permissions than the group file permission bits.  For richacls, this
@@ -679,21 +687,20 @@ __richacl_isolate_who(struct richacl_alloc *alloc, struct 
richace *who,
  *everyone@:rw::allow
  */
 static int
-richacl_isolate_group_class(struct richacl_alloc *alloc)
+richacl_isolate_group_class(struct richacl_alloc *alloc, unsigned int deny)
 {
struct richace who = {
.e_flags = RICHACE_SPECIAL_WHO,
.e_id.special = RICHACE_GROUP_SPECIAL_ID,
};
struct richace *ace;
-   unsigned int deny;
 
if 

[PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[Viresh Kumar]

global_lock is defined as an unsigned long and accessing only its lower
32 bits from sysfs is incorrect, as we need to consider other 32 bits
for big endian 64 bit systems. There are no such platforms yet, but the
code needs to be robust for such a case.

Fix that by passing a local variable to debugfs_create_bool() and
assigning its value to global_lock later.

Signed-off-by: Viresh Kumar 
---
V3->V4:
- Create a local variable instead of changing type of global_lock
  (Rafael)
- Drop the stable tag
- BCC'd a lot of people (rather than cc'ing them) to make sure
  - the series reaches them
  - mailing lists do not block the patchset due to long cc list
  - and we don't spam the BCC'd people for every reply
---
 drivers/acpi/ec_sys.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index b4c216bab22b..b44b91331a56 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned 
int ec_device_count)
struct dentry *dev_dir;
char name[64];
umode_t mode = 0400;
+   u32 val;
 
if (ec_device_count == 0) {
acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
@@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, 
unsigned int ec_device_count)
 
if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)_ec->gpe))
goto error;
-   if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
-(u32 *)_ec->global_lock))
+   if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, ))
goto error;
 
+   first_ec->global_lock = val;
+
if (write_support)
mode = 0600;
if (!debugfs_create_file("io", mode, dev_dir, ec, _ec_io_ops))
-- 
2.4.0

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

Re: [PATCH] pinctrl: mediatek: Consistently use the BIT() macro

[Linus Walleij]

On Fri, Aug 28, 2015 at 4:25 PM, Javier Martinez Canillas
 wrote:

> The mediatek pinctrl driver uses the BIT() macro instead of open
> coding 1 << n in all but one place. Replace this occurrence with
> the BIT() macro for consistency.
>
> Signed-off-by: Javier Martinez Canillas 

Patch applied with Matthias' Ack.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC

[Lee Jones]

On Thu, 24 Sep 2015, Andrew F. Davis wrote:

> This patch adds support for TPS65912 mfd device. It provides
> communication through the I2C and SPI interfaces. It contains
> the following components:
> 
>  - Regulators
>  - GPIO controller
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/mfd/Kconfig  |  24 +++
>  drivers/mfd/Makefile |   3 +
>  drivers/mfd/tps65912-core.c  | 114 +
>  drivers/mfd/tps65912-i2c.c   |  86 ++
>  drivers/mfd/tps65912-spi.c   |  85 ++
>  include/linux/mfd/tps65912.h | 393 
> +++
>  6 files changed, 705 insertions(+)
>  create mode 100644 drivers/mfd/tps65912-core.c
>  create mode 100644 drivers/mfd/tps65912-i2c.c
>  create mode 100644 drivers/mfd/tps65912-spi.c
>  create mode 100644 include/linux/mfd/tps65912.h

[...]

> +#define TPS65912_IRQ(_name, _reg, _offset)   \
> + [TPS65912_IRQ_ ## _name] = {\
> + .mask = TPS65912_ ## _reg ## _ ## _name,\
> + .reg_offset = _offset,  \
> + }

I told you about this already.

If you want this set to be merged for v4.3 then you'll need commit
b4fe8ba ("regmap: Add generic macro to define regmap_irq") from my
tree.

[...]

> +static struct i2c_driver tps65912_i2c_driver = {
> + .driver = {
> + .name   = "tps65912",
> + .of_match_table = tps65912_i2c_of_match_table,

of_match_ptr()

[...]

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAINTAINERS: Remove Samuel Ortiz as MFD Maintainer

[Lee Jones]

Signed-off-by: Lee Jones 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 274f854..fb2ba3d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7038,7 +7038,6 @@ F:drivers/media/i2c/mt9v032.c
 F: include/media/mt9v032.h
 
 MULTIFUNCTION DEVICES (MFD)
-M: Samuel Ortiz 
 M: Lee Jones 
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
 S: Supported
-- 
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 v4 1/2] pinctrl: Add driver for Alphascale asm9260 pinctrl

[Linus Walleij]

On Tue, Sep 8, 2015 at 10:55 PM, Oleksij Rempel  wrote:
> [Me]
>> Why is it necessary for the driver to copy one description of
>> the pin into another?
>
> If i understand it correctly, pinctrl_pin_desc is essential part of
> pinmux framework. Theoretically i should define just statical array of
> this struct, but by this number of pins and functions it hard to keep it
> readable and error free. So i decided to create asm9260_mux_table which
> contains every thing i need. The side effect is higher memory usage
> since i need to create pinctrl_pin_desc on fly.
>
> May be i miss some thing?

I don't see how having code copying data from one data container
to another makes things "more readable and error free". Go for *one*
static definition. Also the memory waste is a total no-no.

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

Re: [PATCH v4 3/7] fs: Verify access of user towards block device file when mounting

[Eric W. Biederman]

Argh.  This looks like morning person meets night owl.

Seth Forshee  writes:

> On Thu, Sep 24, 2015 at 04:53:11PM -0500, Eric W. Biederman wrote:
>> Seth Forshee  writes:
>> 
>> > When mounting a filesystem on a block device there is currently
>> > no verification that the user has appropriate access to the
>> > device file passed to mount. This has not been an issue so far
>> > since the user in question has always been root, but this must
>> > be changed before allowing unprivileged users to mount in user
>> > namespaces.
>> >
>> > To do this, a new version of lookup_bdev() is added named
>> > lookup_bdev_perm(). Both of these functions become wrappers
>> > around a common inner fucntion. The behavior of lookup_bdev() is
>> > unchanged, but calling lookup_bdev_perm() will fail if the user
>> > does not have the specified access rights to the supplied path.
>> > The permission check is skipped if the user has CAP_SYS_ADMIN to
>> > avoid any possible regressions in behavior.
>> >
>> > blkdev_get_by_path() is updated to use lookup_bdev_perm(). This
>> > is used by mount_bdev() and mount_mtd(), so this will cause
>> > mounts on block devices to fail when the user lacks the required
>> > permissions. Other calls to blkdev_get_by_path() will all happen
>> > with root privileges, so these calls will be unaffected.
>> 
>> Good but buggy patch.
>> 
>> In the mtd bits the flags are super flags, not file mode bits,
>> which makes testing them against FMODE_READ and FMODE_WRITE is
>> incorrect.
>
> Bah, yes. Fixed.
>
>> Further it looks like quite a few more possibly all of the lookup_bdev
>> instances could use inode level permission checking.
>> 
>> Certainly code such as quotactl makes me wonder.
>
> I opted to stick to places related to mounting, but let's take a look at
> the other callers.
>
> bcache calls it in the context of sysfs writes, and those attributes are
> writable only by root. In that case the inode permission check will be
> skipped anyway, so it makes no difference either way.
>
> Device mapper calls it in dm_get_device, which is called from a bunch of
> places. I had started trying to walk back through all the callers of
> dm_get_device, but that rabbit hole got really deep really quickly so I
> didn't feel confident that changing it wouldn't break anyone.
>
> quotactl gave me pause, as it seems to have done for you too. I was
> surprised that inode permissions aren't checked, but
> check_quotactl_permission does get called before actually doing
> anything. I fear that adding a check of inode permissions could end up
> breaking someone.

My gut feel on all of this is that we should act like may_open and have
have a flag of 0 for access mode mean don't check permissions.

That way we can change all of the callers of lookup_bdev to pass an
additional argument and make it explicit what is going on but we don't
actually have to change the callers to actually perform an additional
check.

Leaving stones unturned is a good way to introduce a security hole by
accident so I don't want to leave dm_get_device unreviewed, but any
changes can be in later patches.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: core: handle pinctrl_get failure

[Linus Walleij]

On Thu, Sep 10, 2015 at 6:38 AM, Peng Fan  wrote:

> Need to do error handling path when pinctrl_get fails. Also when
> pinctrl_get success, insert 'pctldev->node' to pinctrldev_list.
>
> Signed-off-by: Peng Fan 
> Cc: Linus Walleij 

I think this patch is totally wrong and you have probably not tested
it using pinctrl hogs.

pinctr_get() from self will *not work* unless the device is added to
the list *first*.

Dropping this.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/12] mtd: nand-bbt: move nand_bbt.c to mtd folder

[Brian Norris]

Hi Peter,

First of all, thanks for taking the time to try to address my
long-delayed comments. I hope to give this a proper look soon. (I also
hope you can fix the email threading soon! I know that's a pain...)

But first, a simpler comment:

On Fri, Sep 25, 2015 at 06:48:05AM +, Peter Pan 潘栋 (peterpandong) wrote:
> Since struct nand_chip is removed from nand_bbt.c, BBT is now
> shareable. Both NAND and SPI NAND can use it. So move nand_bbt.c
> from nand/ foler to mtd/ folder and create MTD_NAND_BBT config.
> Both NAND and SPI NAND should depend on MTD_NAND_BBT.
> 
> Signed-off-by: Peter Pan 
> ---
>  drivers/mtd/Kconfig |7 +
>  drivers/mtd/Makefile|1 +
>  drivers/mtd/nand/Kconfig|2 +-
>  drivers/mtd/nand/Makefile   |2 +-
>  drivers/mtd/nand/nand_bbt.c | 1289 
> ---
>  drivers/mtd/nand_bbt.c  | 1289 
> +++
>  6 files changed, 1299 insertions(+), 1291 deletions(-)
>  delete mode 100644 drivers/mtd/nand/nand_bbt.c
>  create mode 100644 drivers/mtd/nand_bbt.c
> 
[...]
> diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
> deleted file mode 100644
> index 47c1084..000
> --- a/drivers/mtd/nand/nand_bbt.c
> +++ /dev/null
> @@ -1,1289 +0,0 @@

[snip deleting entire file]

> diff --git a/drivers/mtd/nand_bbt.c b/drivers/mtd/nand_bbt.c
> new file mode 100644
> index 000..47c1084
> --- /dev/null
> +++ b/drivers/mtd/nand_bbt.c
> @@ -0,0 +1,1289 @@

[snip adding the whole file again -- exactly the same I hope?]

When moving files, it helps if you can use the '-M' (or
'--find-renames') option to git-format-patch. That will give much
smaller output that's easier to review. And if you had to change
anything in the move, it should also help highlight exactly what
changed, instead of including the entire file "diff".

Regards,
Brian

P.S. Incidentally, this should also work around your issues with the
copyright symbol. But then, I suspect that some people have used these
sorts of non-ASCII characters just to fish out issues with mail
clients/MTAs like yours :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags

[Nishanth Menon]

On 09/25/2015 11:15 AM, santosh shilimkar wrote:
> 9/25/2015 9:01 AM, Nishanth Menon wrote:
>> On 09/25/2015 10:18 AM, santosh shilimkar wrote:
>>> On 9/25/2015 7:50 AM, Nishanth Menon wrote:
>> [...]
 But, how about userspace
 needing to know which SoC they are on, without needing to depend on
 board->soc mapping? How do we help resolve that?

>>> Why the user space should care about exact SOC ?
>>
>> examples vary - trivial one is: debug tools like omapconf[1] or testing
>> tools like opentest[2] need some standard way to ensure Linux kernel is
>> functional - trusting the least set of parameters is usually what we
>> would prefer. while building a generic distro such as debian or yocto,
>> one prefers NOT to need to do a package build per SoC/perboard - that
>> never scales. instead, you'd like the same application run on different
>> systems dynamically.
>>
> I guessed omapconf example is coming though Keystone has no such tool

:) That is true - as of now. maynot be the case for future.

> yet ;-). Opentest shouldn't need that info either.

we did debate this on opentest, but we could not implement anything
since we did not have a consistent solution yet.

> I do agree that having a soc along with board is useful in
> longer run to accommodation more boards and variants.
> And only on that merit, I am willing to take these patches.
> 
> Please refresh the series commit messages based on the
> discussion so far and repost. Will pick it up then.
> 
Thanks. I will do so (probably early next week)..


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

Re: [PATCH v4 3/7] fs: Verify access of user towards block device file when mounting

[Eric W. Biederman]

Seth Forshee  writes:

> On Fri, Sep 25, 2015 at 12:16:59PM -0500, Eric W. Biederman wrote:
>> 
>> Argh.  This looks like morning person meets night owl.
>
> Indded :-)
>
>> Seth Forshee  writes:
>> 
>> > On Thu, Sep 24, 2015 at 04:53:11PM -0500, Eric W. Biederman wrote:
>> >> Seth Forshee  writes:
>> >> 
>> >> > When mounting a filesystem on a block device there is currently
>> >> > no verification that the user has appropriate access to the
>> >> > device file passed to mount. This has not been an issue so far
>> >> > since the user in question has always been root, but this must
>> >> > be changed before allowing unprivileged users to mount in user
>> >> > namespaces.
>> >> >
>> >> > To do this, a new version of lookup_bdev() is added named
>> >> > lookup_bdev_perm(). Both of these functions become wrappers
>> >> > around a common inner fucntion. The behavior of lookup_bdev() is
>> >> > unchanged, but calling lookup_bdev_perm() will fail if the user
>> >> > does not have the specified access rights to the supplied path.
>> >> > The permission check is skipped if the user has CAP_SYS_ADMIN to
>> >> > avoid any possible regressions in behavior.
>> >> >
>> >> > blkdev_get_by_path() is updated to use lookup_bdev_perm(). This
>> >> > is used by mount_bdev() and mount_mtd(), so this will cause
>> >> > mounts on block devices to fail when the user lacks the required
>> >> > permissions. Other calls to blkdev_get_by_path() will all happen
>> >> > with root privileges, so these calls will be unaffected.
>> >> 
>> >> Good but buggy patch.
>> >> 
>> >> In the mtd bits the flags are super flags, not file mode bits,
>> >> which makes testing them against FMODE_READ and FMODE_WRITE is
>> >> incorrect.
>> >
>> > Bah, yes. Fixed.
>> >
>> >> Further it looks like quite a few more possibly all of the lookup_bdev
>> >> instances could use inode level permission checking.
>> >> 
>> >> Certainly code such as quotactl makes me wonder.
>> >
>> > I opted to stick to places related to mounting, but let's take a look at
>> > the other callers.
>> >
>> > bcache calls it in the context of sysfs writes, and those attributes are
>> > writable only by root. In that case the inode permission check will be
>> > skipped anyway, so it makes no difference either way.
>> >
>> > Device mapper calls it in dm_get_device, which is called from a bunch of
>> > places. I had started trying to walk back through all the callers of
>> > dm_get_device, but that rabbit hole got really deep really quickly so I
>> > didn't feel confident that changing it wouldn't break anyone.
>> >
>> > quotactl gave me pause, as it seems to have done for you too. I was
>> > surprised that inode permissions aren't checked, but
>> > check_quotactl_permission does get called before actually doing
>> > anything. I fear that adding a check of inode permissions could end up
>> > breaking someone.
>> 
>> My gut feel on all of this is that we should act like may_open and have
>> have a flag of 0 for access mode mean don't check permissions.
>> 
>> That way we can change all of the callers of lookup_bdev to pass an
>> additional argument and make it explicit what is going on but we don't
>> actually have to change the callers to actually perform an additional
>> check.
>
> Sounds reasonable, I'll make that change.
>
>> Leaving stones unturned is a good way to introduce a security hole by
>> accident so I don't want to leave dm_get_device unreviewed, but any
>> changes can be in later patches.
>
> Unless I've made a mistake it shouldn't introduce security holes,
> dm_get_device should behave exactly the same was as it behaves today.
> Any security problems would already be present.

*Nod*

There are two parts to this.  Splitting this into changes that are small
enough to be correct.  And just passing in a 0 for acc_mode seems good
enough in that case.  The other question is what happens when we start
allowing unprivileged users to mount things, and in general what happens
when we start relaxing permission checks.

Frankly we need to understand how everything interacts if we are to
relax permissions safely if we don't want to be chasing security issues
for the next several years as things come to lite that we have
overlooked.

> I can take another crack at reviewing, but it might also be good if
> someone who already knows the code commented as well. As I recall I gave
> up after getting several levels deep in indirect function calls where the
> names of the struct members which held the function pointers were
> identical at a couple of levels, so I was having a hard time knowing if
> I was keeping everything straight.

For this patch I am not concerned but we do need to understand how all
of the pieces interact and that is just plain challenging.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo 

[PATCH v2 2/8] spi: imx: replace fixed timeout with calculated one

[Anton Bondarenko]

Fixed timeout value can fire while transaction is ongoing. This may happen
because there are no strict requirements on SPI transaction duration.
Dynamic timeout value is generated based on SCLK and transaction size.

There is also 4 * SCLK delay between TX bursts related to CS change.

Signed-off-by: Anton Bondarenko 
---
 drivers/spi/spi-imx.c | 49 +
 1 file changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 165bc2c..6c98eda 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -59,7 +59,6 @@
 
 /* The maximum  bytes that a sdma BD can transfer.*/
 #define MAX_SDMA_BD_BYTES  (1 << 15)
-#define IMX_DMA_TIMEOUT (msecs_to_jiffies(3000))
 struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
@@ -95,6 +94,7 @@ struct spi_imx_data {
struct clk *clk_per;
struct clk *clk_ipg;
unsigned long spi_clk;
+   unsigned int spi_bus_clk;
 
unsigned int count;
void (*tx)(struct spi_imx_data *);
@@ -317,8 +317,7 @@ static int __maybe_unused mx51_ecspi_config(struct 
spi_imx_data *spi_imx,
 {
u32 ctrl = MX51_ECSPI_CTRL_ENABLE, dma = 0;
u32 cfg = readl(spi_imx->base + MX51_ECSPI_CONFIG);
-
-   u32 clk = config->speed_hz, delay;
+   u32 delay;
 
/*
 * The hardware seems to have a race condition when changing modes. The
@@ -330,7 +329,9 @@ static int __maybe_unused mx51_ecspi_config(struct 
spi_imx_data *spi_imx,
ctrl |= MX51_ECSPI_CTRL_MODE_MASK;
 
/* set clock speed */
-   ctrl |= mx51_ecspi_clkdiv(spi_imx->spi_clk, config->speed_hz, );
+   spi_imx->spi_bus_clk = config->speed_hz;
+   ctrl |= mx51_ecspi_clkdiv(spi_imx->spi_clk, config->speed_hz,
+ _imx->spi_bus_clk);
 
/* set chip select to use */
ctrl |= MX51_ECSPI_CTRL_CS(config->cs);
@@ -363,7 +364,7 @@ static int __maybe_unused mx51_ecspi_config(struct 
spi_imx_data *spi_imx,
 * the SPI communication as the device on the other end would consider
 * the change of SCLK polarity as a clock tick already.
 */
-   delay = (2 * 100) / clk;
+   delay = (2 * USEC_PER_SEC) / spi_imx->spi_bus_clk;
if (likely(delay < 10)) /* SCLK is faster than 100 kHz */
udelay(delay);
else/* SCLK is _very_ slow */
@@ -889,12 +890,40 @@ static void spi_imx_dma_tx_callback(void *cookie)
complete(_imx->dma_tx_completion);
 }
 
+static int spi_imx_calculate_timeout(struct spi_imx_data *spi_imx, int size)
+{
+   unsigned long coef1 = 1;
+   unsigned long coef2 = MSEC_PER_SEC;
+   unsigned long timeout = 0;
+
+   /* Swap coeficients to avoid div by 0 */
+   if (spi_imx->spi_bus_clk < MSEC_PER_SEC) {
+   coef1 = MSEC_PER_SEC;
+   coef2 = 1;
+   }
+
+   /* Time with actual data transfer */
+   timeout += DIV_ROUND_UP(8 * size * coef1,
+   spi_imx->spi_bus_clk / coef2);
+
+   /* Take CS change delay related to HW */
+   timeout += DIV_ROUND_UP((size - 1) * 4 * coef1,
+   spi_imx->spi_bus_clk / coef2);
+
+   /* Add extra second for scheduler related activities */
+   timeout += MSEC_PER_SEC;
+
+   /* Double calculated timeout */
+   return msecs_to_jiffies(2 * timeout);
+}
+
 static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
struct spi_transfer *transfer)
 {
struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
int ret;
unsigned long timeout;
+   unsigned long transfer_timeout;
const int left = transfer->len % spi_imx->wml;
struct spi_master *master = spi_imx->bitbang.master;
struct sg_table *tx = >tx_sg, *rx = >rx_sg;
@@ -947,9 +976,11 @@ static int spi_imx_dma_transfer(struct spi_imx_data 
*spi_imx,
dma_async_issue_pending(master->dma_tx);
spi_imx->devtype_data->trigger(spi_imx);
 
+   transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
+
/* Wait SDMA to finish the data transfer.*/
timeout = wait_for_completion_timeout(_imx->dma_tx_completion,
-   IMX_DMA_TIMEOUT);
+   transfer_timeout);
if (!timeout) {
pr_warn("%s %s: I/O Error in DMA TX\n",
dev_driver_string(>dev),
@@ -957,8 +988,10 @@ static int spi_imx_dma_transfer(struct spi_imx_data 
*spi_imx,
dmaengine_terminate_all(master->dma_tx);
dmaengine_terminate_all(master->dma_rx);
} else {
+   transfer_timeout = spi_imx_calculate_timeout(spi_imx,
+spi_imx->wml * 2);
timeout = 

Re: [PATCH] dax: fix deadlock in __dax_fault

[Ross Zwisler]

On Fri, Sep 25, 2015 at 12:53:57PM +1000, Dave Chinner wrote:
<>
> We've already got block allocation serialisation at the filesystem
> level, and the issue is the unserialised block zeroing being done by
> the dax code. That can be fixed by moving the zeroing into the
> filesystem code when it runs "complete_unwritten" and checks whether
> the mapping has already been marked as written or not...
> 
> I've recently pointed out in a different thread that this is the
> solution to whatever that problem was (can't recall which
> thread/problem is was now :/ ) and it the same solution here. We
> already have the serialisation we need, we just need to move the
> block zeroing operation into the appropriate places to make it work
> correctly.

I think perhaps this is the thread that you're remembering:
https://lkml.org/lkml/2015/8/11/731
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] kernel/cpu.c: export __cpu_*_mask

[Rasmus Villemoes]

Exporting the cpumasks __cpu_possible_mask and friends will allow us
to remove the extra indirection through the cpu_*_mask variables. It
will also allow the set_cpu_* functions to become static inlines,
which will give a .text reduction.

Signed-off-by: Rasmus Villemoes 
---
 include/linux/cpumask.h |  4 
 kernel/cpu.c| 14 +-
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 59915ea5373c..d4545a1852f2 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -89,6 +89,10 @@ extern const struct cpumask *const cpu_possible_mask;
 extern const struct cpumask *const cpu_online_mask;
 extern const struct cpumask *const cpu_present_mask;
 extern const struct cpumask *const cpu_active_mask;
+extern struct cpumask __cpu_possible_mask;
+extern struct cpumask __cpu_online_mask;
+extern struct cpumask __cpu_present_mask;
+extern struct cpumask __cpu_active_mask;
 
 #if NR_CPUS > 1
 #define num_online_cpus()  cpumask_weight(cpu_online_mask)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index fea4a3ce3011..e08db26d351b 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -772,23 +772,27 @@ const DECLARE_BITMAP(cpu_all_bits, NR_CPUS) = 
CPU_BITS_ALL;
 EXPORT_SYMBOL(cpu_all_bits);
 
 #ifdef CONFIG_INIT_ALL_POSSIBLE
-static struct cpumask __cpu_possible_mask __read_mostly
+struct cpumask __cpu_possible_mask __read_mostly
= {CPU_BITS_ALL};
 #else
-static struct cpumask __cpu_possible_mask __read_mostly;
+struct cpumask __cpu_possible_mask __read_mostly;
 #endif
+EXPORT_SYMBOL(__cpu_possible_mask);
 const struct cpumask *const cpu_possible_mask = &__cpu_possible_mask;
 EXPORT_SYMBOL(cpu_possible_mask);
 
-static struct cpumask __cpu_online_mask __read_mostly;
+struct cpumask __cpu_online_mask __read_mostly;
+EXPORT_SYMBOL(__cpu_online_mask);
 const struct cpumask *const cpu_online_mask = &__cpu_online_mask;
 EXPORT_SYMBOL(cpu_online_mask);
 
-static struct cpumask __cpu_present_mask __read_mostly;
+struct cpumask __cpu_present_mask __read_mostly;
+EXPORT_SYMBOL(__cpu_present_mask);
 const struct cpumask *const cpu_present_mask = &__cpu_present_mask;
 EXPORT_SYMBOL(cpu_present_mask);
 
-static struct cpumask __cpu_active_mask __read_mostly;
+struct cpumask __cpu_active_mask __read_mostly;
+EXPORT_SYMBOL(__cpu_active_mask);
 const struct cpumask *const cpu_active_mask = &__cpu_active_mask;
 EXPORT_SYMBOL(cpu_active_mask);
 
-- 
2.1.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 0/5] kernel/cpu.c: eliminate some indirection

[Rasmus Villemoes]

Maybe third time's the charm...

The four cpumasks cpu_{possible,online,present,active}_bits are
exposed readonly via the corresponding const variables
cpu_xyz_mask. But they are also accessible for arbitrary writing via
the exposed functions set_cpu_xyz. There's quite a bit of code
throughout the kernel which iterates over or otherwise accesses these
bitmaps, and having the access go via the cpu_xyz_mask variables is
simply a useless indirection.

It may be that any problem in CS can be solved by an extra level of
indirection, but that doesn't mean every extra indirection solves a
problem. In this case, it even necessitates some minor ugliness (see
3/5).

The first four patches eliminate the cpu_xyz_mask variables by simply
exposing the actual bitmaps, after renaming them to discourage direct
access - that still happens through cpu_xyz_mask, which are now simply
macros with the same type and value as they used to have.

After that, there's no longer any reason to have the setter functions
be out-of-line: The boolean parameter is almost always a literal true
or false, so by making them static inlines they will usually compile
to one or two instructions.

For a defconfig build, bloat-o-meter says we save ~3000 bytes.

Rasmus Villemoes (5):
  kernel/cpu.c: change type of cpu_possible_bits and friends
  kernel/cpu.c: export __cpu_*_mask
  drivers/base/cpu.c: use __cpu_*_mask directly
  kernel/cpu.c: eliminate cpu_*_mask
  kernel/cpu.c: make set_cpu_* static inlines

 drivers/base/cpu.c  | 10 
 include/linux/cpumask.h | 55 +++---
 kernel/cpu.c| 64 ++---
 3 files changed, 65 insertions(+), 64 deletions(-)

-- 
2.1.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 5/5] kernel/cpu.c: make set_cpu_* static inlines

[Rasmus Villemoes]

Almost all callers of the set_cpu_* functions pass an explicit true
or false. Making them static inline thus replaces the function calls
with a simple set_bit/clear_bit, saving some .text.

Signed-off-by: Rasmus Villemoes 
---
 include/linux/cpumask.h | 43 +++
 kernel/cpu.c| 34 --
 2 files changed, 39 insertions(+), 38 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 52ab539aefce..fc14275ff34e 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -720,14 +720,49 @@ extern const DECLARE_BITMAP(cpu_all_bits, NR_CPUS);
 #define for_each_present_cpu(cpu)  for_each_cpu((cpu), cpu_present_mask)
 
 /* Wrappers for arch boot code to manipulate normally-constant masks */
-void set_cpu_possible(unsigned int cpu, bool possible);
-void set_cpu_present(unsigned int cpu, bool present);
-void set_cpu_online(unsigned int cpu, bool online);
-void set_cpu_active(unsigned int cpu, bool active);
 void init_cpu_present(const struct cpumask *src);
 void init_cpu_possible(const struct cpumask *src);
 void init_cpu_online(const struct cpumask *src);
 
+static inline void
+set_cpu_possible(unsigned int cpu, bool possible)
+{
+   if (possible)
+   cpumask_set_cpu(cpu, &__cpu_possible_mask);
+   else
+   cpumask_clear_cpu(cpu, &__cpu_possible_mask);
+}
+
+static inline void
+set_cpu_present(unsigned int cpu, bool present)
+{
+   if (present)
+   cpumask_set_cpu(cpu, &__cpu_present_mask);
+   else
+   cpumask_clear_cpu(cpu, &__cpu_present_mask);
+}
+
+static inline void
+set_cpu_online(unsigned int cpu, bool online)
+{
+   if (online) {
+   cpumask_set_cpu(cpu, &__cpu_online_mask);
+   cpumask_set_cpu(cpu, &__cpu_active_mask);
+   } else {
+   cpumask_clear_cpu(cpu, &__cpu_online_mask);
+   }
+}
+
+static inline void
+set_cpu_active(unsigned int cpu, bool active)
+{
+   if (active)
+   cpumask_set_cpu(cpu, &__cpu_active_mask);
+   else
+   cpumask_clear_cpu(cpu, &__cpu_active_mask);
+}
+
+
 /**
  * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
  * @bitmap: the bitmap
diff --git a/kernel/cpu.c b/kernel/cpu.c
index dd70f600442f..5210d80efc28 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -788,40 +788,6 @@ EXPORT_SYMBOL(__cpu_present_mask);
 struct cpumask __cpu_active_mask __read_mostly;
 EXPORT_SYMBOL(__cpu_active_mask);
 
-void set_cpu_possible(unsigned int cpu, bool possible)
-{
-   if (possible)
-   cpumask_set_cpu(cpu, &__cpu_possible_mask);
-   else
-   cpumask_clear_cpu(cpu, &__cpu_possible_mask);
-}
-
-void set_cpu_present(unsigned int cpu, bool present)
-{
-   if (present)
-   cpumask_set_cpu(cpu, &__cpu_present_mask);
-   else
-   cpumask_clear_cpu(cpu, &__cpu_present_mask);
-}
-
-void set_cpu_online(unsigned int cpu, bool online)
-{
-   if (online) {
-   cpumask_set_cpu(cpu, &__cpu_online_mask);
-   cpumask_set_cpu(cpu, &__cpu_active_mask);
-   } else {
-   cpumask_clear_cpu(cpu, &__cpu_online_mask);
-   }
-}
-
-void set_cpu_active(unsigned int cpu, bool active)
-{
-   if (active)
-   cpumask_set_cpu(cpu, &__cpu_active_mask);
-   else
-   cpumask_clear_cpu(cpu, &__cpu_active_mask);
-}
-
 void init_cpu_present(const struct cpumask *src)
 {
cpumask_copy(&__cpu_present_mask, src);
-- 
2.1.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: No more new fbdev drivers, please

[Daniel Vetter]

On Fri, Sep 25, 2015 at 04:09:46PM +0300, Tomi Valkeinen wrote:
> 
> 
> On 25/09/15 13:41, Kamil Lulko wrote:
> > Hi,
> > 
> >> fbdev is (more or less) maintained, but it's a deprecated framework. All
> >> new Linux display drivers should be done on DRM.
> > 
> > What about no-mmu platforms? DRM has a big fat MMU dependency in the
> > kconfig, is there a way to write DRM driver for such devices?
> 
> I guess not.
> 
> Then again, I don't see why DRM would have a hard dependency to MMU, if
> the work is done to make DRM work optionally without MMU. How much work
> that is, I have no idea.

We have plenty drivers in drm without hw mmu, and yeah there's probably no
reason at all why the drm subsystem has a hard depency on cpu MMUs. Might
be some #ifdef fallout that needs to be done, but there shouldn't be
anything fundamental. Maybe the old dri1 days code has something, but
that's all historical cruft anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

consignment

[COMPENSATION HEAD OFFICE]

 
Contact us for your compensation consignment box
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

[Rafael J. Wysocki]

On Friday, September 25, 2015 11:52:23 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 05:13:04 PM Alan Stern wrote:
> > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> > 
> > > On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote:
> > > > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> > > > 
> > > > > We are missing the "no remote wakeup" bit now (well, there is a PM 
> > > > > QoS flag,
> > > > > but it isn't very useful, so I'd prefer to replace it with a "no 
> > > > > remote wakeup"
> > > > > bit in struct dev_pm_info or something similar).
> > > > > 
> > > > > That is actually quite important, because (a) we can save energy but 
> > > > > not
> > > > > configuring the device to do remote wakeup in the first place and (b) 
> > > > > that
> > > > > may involve more than just the driver (for example, disabling PCI or 
> > > > > ACPI
> > > > > remote wakeup involves the bus type or similar).
> > > > > 
> > > > > So it looks like we need to be able to distinguish between "runtime 
> > > > > suspend
> > > > > with remote wakeup" and "runtime suspend without remote wakeup".
> > > > > 
> > > > > And if we do the latter, we may not even need the "inhibit" thing any 
> > > > > more,
> > > > > because suspended devices without that are not configured to do 
> > > > > remote wakeup
> > > > > cannot really signal anything in the majority of cases.
> > > > 
> > > > That works only for drivers that use autosuspend to go to low power in
> > > > between events.  It doesn't work for drivers that remain at full power 
> > > > as long as the device file is open.  That kind of driver does require 
> > > > an "inhibit" interface.
> > > 
> > > Or an interface allowing user space to trigger pm_request_idle() for them.
> > > 
> > > So user space would change the "no remote wakeup" setting and then do the
> > > "try to suspend now" thing.
> > 
> > So something like:
> > 
> > echo on >/sys/.../power/control  (in case the device was
> > already in runtime suspend with wakeups enabled)
> > echo off >/sys/.../power/wakeup
> > echo auto >/sys/.../power/control
> 
> That, or there may be an additional value, say "aggressive", to write to the
> control file in which case it becomes just
> 
> echo aggressive >/sys/.../power/control

That said I suppose that the "off" value for the "wakeup" file might also be
useful in some other cases, so it likely is a better approach.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] selinux: use kstrdup() in security_get_bools()

[Rasmus Villemoes]

This is much simpler.

Signed-off-by: Rasmus Villemoes 
---
 security/selinux/ss/services.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 994c824a34c6..aa2bdcb20848 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -2609,18 +2609,12 @@ int security_get_bools(int *len, char ***names, int 
**values)
goto err;
 
for (i = 0; i < *len; i++) {
-   size_t name_len;
-
(*values)[i] = policydb.bool_val_to_struct[i]->state;
-   name_len = strlen(sym_name(, SYM_BOOLS, i)) + 1;
 
rc = -ENOMEM;
-   (*names)[i] = kmalloc(sizeof(char) * name_len, GFP_ATOMIC);
+   (*names)[i] = kstrdup(sym_name(, SYM_BOOLS, i), 
GFP_ATOMIC);
if (!(*names)[i])
goto err;
-
-   strncpy((*names)[i], sym_name(, SYM_BOOLS, i), 
name_len);
-   (*names)[i][name_len - 1] = 0;
}
rc = 0;
 out:
-- 
2.1.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 2/5] selinux: remove pointless cast in selinux_inode_setsecurity()

[Rasmus Villemoes]

security_context_to_sid() expects a const char* argument, so there's
no point in casting away the const qualifier of value.

Signed-off-by: Rasmus Villemoes 
---
 security/selinux/hooks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index fd50cd5ac2ec..5edb57df86f8 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3162,7 +3162,7 @@ static int selinux_inode_setsecurity(struct inode *inode, 
const char *name,
if (!value || !size)
return -EACCES;
 
-   rc = security_context_to_sid((void *)value, size, , GFP_KERNEL);
+   rc = security_context_to_sid(value, size, , GFP_KERNEL);
if (rc)
return rc;
 
-- 
2.1.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 v4 0/2] pwm: Broadcom BCM7038 PWM controller (v4)

[Florian Fainelli]

On 14/09/15 16:47, Florian Fainelli wrote:
> Hi,
> 
> This patch series add PWM support for the Broadcom BCM7xxx
> chips which feature one or more PWM controllers capable of
> output periods from 148ns to ~622ms using a combination of
> variable and fixed frequency settings.

Thierry, are you happy with this version of the patches? Thanks.

> 
> The controller does not support setting a polarity.
> 
> This is based on Thierry's pwm/next branch.
> 
> Florian Fainelli (2):
>   Documentation: dt: add Broadcom BCM7038 PWM controller binding
>   pwm: Add Broadcom BCM7038 PWM controller support
> 
>  .../devicetree/bindings/pwm/brcm,bcm7038-pwm.txt   |  20 ++
>  drivers/pwm/Kconfig|  10 +
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-brcmstb.c  | 345 
> +
>  4 files changed, 376 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
>  create mode 100644 drivers/pwm/pwm-brcmstb.c
> 


-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: PIDs Controller Limit

[Aleksa Sarai]

> On Thu, Sep 24, 2015 at 09:42:38AM +1000, Aleksa Sarai wrote:
>> Does it make sense for the PIDs controller to allow a user to set a
>> limit of 0? Since we don't cancel attaches, a limit of 0 doesn't
>> affect anything (nothing stops attaches, and you need to have a
>> process in the PIDs cgroup in order for fork()s to be affected by the
>> limit). So I think that attempting to set pid.limit to 0 should return
>> an -EINVAL.
>
> I don't know.  Why does it matter?

Well, it might be confusing that a limit of `0` is not different from
a limit of `1`. Especially since someone might think that a limit of
`0` means "no processes AT ALL", which is wrong. Although, I guess
they should've just RTFM'd in that case.

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

Re: [PATCH v2 0/5] ACPI probing infrastructure

[Rafael J. Wysocki]

On Sunday, September 13, 2015 03:02:18 PM Marc Zyngier wrote:
> IRQ controllers and timers are the two types of device the kernel
> requires before being able to use the device driver model.
> 
> The Device Tree infrastructure makes it very easy to make these
> discoverable by the rest of the kernel. For example, each interrupt
> controller driver has at least one entry like this:
> 
> IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);
> 
> which says: if you find a node having "arm,gic-400" as a compatible
> string in the device tree, then call gic_of_init with this node as a
> parameter. The probing itself is done by the OF layer when the
> architecture code calls of_irq_init() (usually via irqchip_init).
> 
> This has a number of benefits:
> 
> - The irqchip code is self-contained. No architecture specific entry
> point, no exposed symbols. Just a standard interface.
> 
> - The low-level architecture code doesn't have to know about which
> interrupt controller is present. It just calls into the firmware
> interface (of_irq_init) which is going to sort things out.
> 
> Similar infrastructure is provided for the timers/clock sources. Note
> that this is not a replacement for the device model, but acts as a
> probing infrastructure for things that are required too early for the
> device infrastructure to be available.
> 
> What I'm aiming for is to introduce the same level of abstraction for
> ACPI, or at least for the few bits that are required before a full blown
> ACPI/device model can be used. For this, I introduce something vaguely
> similar:
> 
> IRQCHIP_ACPI_DECLARE(gic_v2, ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
>gic_validate_dist, ACPI_MADT_GIC_VERSION_V2,
>gic_v2_acpi_init);
> 
> which says: if you find a ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR entry in
> MADT (implied by the macro), and that entry is of type
> ACPI_MADT_GIC_VERSION_V2 (as checked by gic_validate_dist), then call
> gic_v2_acpi_init with the entry as a parameter. A bit more convoluted,
> but still without any special entry point.
> 
> The various interrupt controller drivers can then implement the above,
> and the arch code can use a firmware-specific call to get the probing
> done, still oblivious to what interrupt controller is being used. It
> also makes the adaptation of a DT driver to ACPI easier.
> 
> It turns out that providing such a probing infrastructure is rather
> easy, and provides a much deserved cleanup in both the arch code, the
> GIC driver, and the architected timer driver.
> 
> I'm sure there is some more code to be deleted, and one can only
> wonder why this wasn't done before the arm64 code was initially merged
> (the diffstat says it all...).
> 
> Patches are against v4.3-rc1, and a branch is available at
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git 
> acpi/device-probing-v2
> 
> * From the initial version:
>   - Make the infrastructure more DT like by providing an
> acpi_probe_entry array per "device type" (one for irqchips, one
> for clocksources). This means that entries can depend on any ACPI
> static table.
>   - Use some cpp magic to reduce the amount of code added to an
> absolute minimum.
>   - Rebased on v4.3-rc1
> 
> Marc Zyngier (5):
>   acpi: Add basic device probing infrastructure
>   irqchip/acpi: Add probing infrastructure for ACPI-based irqchips
>   irqchip/gic: Convert the GIC driver to ACPI probing
>   clocksource/acpi: Add probing infrastructure for ACPI-based
> clocksources
>   clocksource/arm_arch_timer: Convert to ACPI probing

I'm generally fine with this (modulo a couple of super-minor nits in the
first patch), but it needs ACKs from Thomas for the irqchip-related and
clocksource-related patches.

Plus [3/5] needs to be rebased on top of the Al's patches removing 
BAD_MADT_ENTRY
(currently in my bleeding-edge branch).

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] acpi: Add basic device probing infrastructure

[Rafael J. Wysocki]

On Sunday, September 13, 2015 03:02:19 PM Marc Zyngier wrote:

The subject is slightly confusing IMO (there is a device probing infrastructure
in the ACPI subsystem, but not for the kind of devices in question here).

> IRQ controllers and timers are the two types of device the kernel
> requires before being able to use the device driver model.
> 
> ACPI so far lacks a proper probing infrastructure similar to the one
> we have with DT, where we're able to declare IRQ chips and
> clocksources inside the driver code, and let the core code pick it up
> and call us back on a match. This leads to all kind of really ugly
> hacks all over the arm64 code and even in the ACPI layer.
> 
> In order to allow some basic probing based on the ACPI tables,
> introduce "struct acpi_probe_entry" which contains just enough
> data and callbacks to match a table, an optional subtable, and
> call a probe function. A driver can, at build time, register itself
> and expect being called if the right entry exists in the ACPI
> table.
> 
> A acpi_probe_device_table() is provided, taking an identifier for
> a set of acpi_prove_entries, and iterating over the registered
> entries.
> 
> Signed-off-by: Marc Zyngier 
> ---
>  drivers/acpi/scan.c   | 39 +++
>  include/asm-generic/vmlinux.lds.h | 10 ++
>  include/linux/acpi.h  | 65 
> +++
>  3 files changed, 114 insertions(+)
> 
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 01136b8..ac3030b 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1933,3 +1933,42 @@ int __init acpi_scan_init(void)
>   mutex_unlock(_scan_lock);
>   return result;
>  }
> +
> +static struct acpi_probe_entry *ape;
> +static int acpi_probe_count;
> +static DEFINE_SPINLOCK(acpi_probe_lock);
> +
> +static int __init acpi_match_madt(struct acpi_subtable_header *header,
> +   const unsigned long end)
> +{
> + if (!ape->validate_subtbl || ape->validate_subtbl(header, ape))
> + if (!ape->probe_subtbl(header, end))
> + acpi_probe_count++;
> +
> + return 0;
> +}
> +
> +int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int 
> nr)
> +{
> + int count = 0;
> +
> + if (acpi_disabled)
> + return 0;
> +
> + spin_lock(_probe_lock);
> + for (ape = ap_head; nr; ape++, nr--) {
> + if (ACPI_COMPARE_NAME(ACPI_SIG_MADT, ape->id)) {
> + acpi_probe_count = 0;
> + acpi_table_parse_madt(ape->type, acpi_match_madt, 0);
> + count += acpi_probe_count;
> + } else {
> + int res;
> + res = acpi_table_parse(ape->id, ape->probe_table);
> + if (!res)
> + count++;
> + }
> + }
> + spin_unlock(_probe_lock);
> +
> + return count;
> +}
> diff --git a/include/asm-generic/vmlinux.lds.h 
> b/include/asm-generic/vmlinux.lds.h
> index 1781e54..efd7ed1 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -181,6 +181,16 @@
>  #define CPUIDLE_METHOD_OF_TABLES() OF_TABLE(CONFIG_CPU_IDLE, cpuidle_method)
>  #define EARLYCON_OF_TABLES() OF_TABLE(CONFIG_SERIAL_EARLYCON, earlycon)
>  
> +#ifdef CONFIG_ACPI
> +#define ACPI_PROBE_TABLE(name)   
> \
> + . = ALIGN(8);   \
> + VMLINUX_SYMBOL(__##name##_acpi_probe_table) = .;\
> + *(__##name##_acpi_probe_table)  \
> + VMLINUX_SYMBOL(__##name##_acpi_probe_table_end) = .;
> +#else
> +#define ACPI_PROBE_TABLE(name)
> +#endif
> +
>  #define KERNEL_DTB() \
>   STRUCT_ALIGN(); \
>   VMLINUX_SYMBOL(__dtb_start) = .;\
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 7235c48..c63fbda 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -759,6 +759,61 @@ int acpi_dev_prop_read(struct acpi_device *adev, const 
> char *propname,
>  
>  struct acpi_device *acpi_get_next_child(struct device *dev,
>   struct acpi_device *child);
> +
> +struct acpi_probe_entry;
> +typedef bool (*acpi_probe_entry_validate_subtbl)(struct acpi_subtable_header 
> *,
> +  struct acpi_probe_entry *);
> +
> +#define ACPI_TABLE_ID_LEN5
> +
> +/**
> + * struct acpi_probe_entry - boot-time probing entry
> + * @id:  ACPI table name
> + * @type:Optional subtable type to match
> + *   (if @id contains subtables)
> + * @validate_subtbl: Optional callback to check the validity of
> + *   the subtable

I'd 

Re: [PATCH 1/1] PCI/MSI: X-Gene: Remove msi_controller assignment in X-Gene PCIe driver

[Bjorn Helgaas]

On Fri, Sep 18, 2015 at 09:59:56AM +0100, Marc Zyngier wrote:
> On Wed, 16 Sep 2015 17:31:40 -0700
> Duc Dang  wrote:
> 
> > With commit 8d63bc7beaee ("PCI/MSI: pci-xgene-msi: Get rid of
> > struct msi_controller"), it is no longer required to assign
> > msi_controller for X-Gene PCIe host bridge to support MSI. This
> > patch removes this unnecessary code and also helps avoid a warning
> > message ("failed to enable MSI") during boot.
> > 
> > Signed-off-by: Duc Dang 
> > Cc: Tanmay Inamdar 
> 
> Acked-by: Marc Zyngier 

I lost the original mail from Duc, but I applied this to pci/host-xgene for
v4.4 with this changelog:

commit 00b9b91cb330e70b6bc571a9aa7175b4590ca452
Author: Duc Dang 
Date:   Wed Sep 16 17:31:40 2015 -0700

PCI/MSI: xgene: Remove msi_controller assignment

After 8d63bc7beaee ("PCI/MSI: pci-xgene-msi: Get rid of struct
msi_controller"), it is no longer required to assign msi_controller for
X-Gene PCIe host bridge to support MSI.

Remove this unnecessary code.  This also avoids a warning message ("failed
to enable MSI") during boot.

[bhelgaas: changelog]
Signed-off-by: Duc Dang 
Signed-off-by: Bjorn Helgaas 
Acked-by: Marc Zyngier 
Cc: Tanmay Inamdar 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Glibc recvmsg from kernel netlink socket hangs forever

[Steven Schlansker]

On Sep 25, 2015, at 2:37 PM, Steven Schlansker  
wrote:

> 
> On Sep 24, 2015, at 10:34 PM, Guenter Roeck  wrote:
> 
>> Herbert,
>> 
>> On 09/24/2015 09:58 PM, Herbert Xu wrote:
>>> On Thu, Sep 24, 2015 at 09:36:53PM -0700, Guenter Roeck wrote:
 
 http://comments.gmane.org/gmane.linux.network/363085
 
 might explain your problem.
 
 I thought this was resolved in 4.1, but it looks like the problem still 
 persists
 there. At least I have reports from my workplace that 4.1.6 and 4.1.7 are 
 still
 affected. I don't know if there have been any relevant changes in 4.2.
 
 Copying Herbert and Eric for additional input.
>>> 
>>> There was a separate bug discovered by Tejun recently.  You need
>>> to apply the patches
>>> 
>>> https://patchwork.ozlabs.org/patch/519245/
>>> https://patchwork.ozlabs.org/patch/520824/
>>> 
>> I assume this is on top of mainline ?
>> 
>>> There is another follow-up but it shouldn't make any difference
>>> in practice.
>>> 
>> 
>> Any idea what may be needed for 4.1 ?
>> I am currently trying https://patchwork.ozlabs.org/patch/473041/,
>> but I have no idea if that will help with the problem we are seeing there.
> 
> Thank you for the patches to try, I'll build a kernel with them early next 
> week
> and report back.  It sounds like it may not match my problem exactly so we'll
> see.
Huh, when it rains, it pours... now I have a legit panic too!

[ 1675.228701] BUG: unable to handle kernel paging request at fe70
[ 1675.232058] IP: [] netlink_compare+0xa/0x30
[ 1675.232058] PGD 2015067 PUD 2017067 PMD 0 
[ 1675.232058] Oops:  [#1] SMP 
[ 1675.232058] Modules linked in: i2c_piix4(E) btrfs(E) crct10dif_pclmul(E) 
crc32_pclmul(E) ghash_clmulni_intel(E) aesni_intel(E) aes_x86_64(E) lrw(E) 
gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) floppy(E)
[ 1675.232058] CPU: 2 PID: 11152 Comm: pf_dump Tainted: GE   4.0.4 
#1
[ 1675.232058] Hardware name: Xen HVM domU, BIOS 4.2.amazon 05/06/2015
[ 1675.232058] task: 880150fa6480 ti: 880150fb4000 task.ti: 
880150fb4000
[ 1675.232058] RIP: 0010:[]  [] 
netlink_compare+0xa/0x30
[ 1675.232058] RSP: 0018:880150fb7d10  EFLAGS: 00010246
[ 1675.232058] RAX:  RBX: 023e503b RCX: 0561f992
[ 1675.232058] RDX: fffc27e4 RSI: 880150fb7db8 RDI: fbb8
[ 1675.232058] RBP: 880150fb7d58 R08: 8805a82f5ab8 R09: 000c
[ 1675.232058] R10:  R11: 0202 R12: 
[ 1675.232058] R13: 8175dce0 R14: 88008b37e800 R15: 88076db4
[ 1675.232058] FS:  7feec2440700() GS:88078fc4() 
knlGS:
[ 1675.232058] CS:  0010 DS:  ES:  CR0: 80050033
[ 1675.232058] CR2: fe70 CR3: 00053bd17000 CR4: 001407e0
[ 1675.232058] Stack:
[ 1675.232058]  81434dae 88076d864400 880150fb7db8 
8801559ee8b8
[ 1675.232058]  88076db4 8805a82f5c48 88008b37e800 
88076d864400
[ 1675.232058]   880150fb7da8 81435476 
880150fb7db8
[ 1675.232058] Call Trace:
[ 1675.232058]  [] ? rhashtable_lookup_compare+0x5e/0xb0
[ 1675.232058]  [] rhashtable_lookup_compare_insert+0x66/0xc0
[ 1675.232058]  [] netlink_insert+0x83/0xe0
[ 1675.232058]  [] netlink_autobind.isra.34+0xad/0xd0
[ 1675.232058]  [] netlink_bind+0x1b1/0x240
[ 1675.232058]  [] SYSC_bind+0xb8/0xf0
[ 1675.232058]  [] ? __audit_syscall_entry+0xb4/0x110
[ 1675.232058]  [] ? do_audit_syscall_entry+0x6c/0x70
[ 1675.232058]  [] ? syscall_trace_enter_phase1+0x123/0x180
[ 1675.232058]  [] ? syscall_trace_leave+0xc6/0x120
[ 1675.232058]  [] ? fd_install+0x25/0x30
[ 1675.232058]  [] SyS_bind+0xe/0x10
[ 1675.232058]  [] system_call_fastpath+0x16/0x1b
[ 1675.232058] Code: 00 8b 77 08 39 77 14 8d 4e 01 41 0f 44 c9 41 39 c8 89 4f 
08 74 09 48 8b 08 83 3c 11 04 74 e2 5d c3 0f 1f 44 00 00 31 c0 8b 56 08 <39> 97 
b8 02 00 00 55 48 89 e5 74 0a 5d c3 0f 1f 84 00 00 00 00 
[ 1675.232058] RIP  [] netlink_compare+0xa/0x30
[ 1675.232058]  RSP 
[ 1675.232058] CR2: fe70
[ 1675.232058] ---[ end trace 963ff50a058120d0 ]---
[ 1675.232058] Kernel panic - not syncing: Fatal exception in interrupt
[ 1675.232058] Kernel Offset: 0x0 from 0x8100 (relocation range: 
0x8000-0x9fff)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: First kernel patch (optimization)

[Dmitry Torokhov]

Hi Erik,

>
> Yeah, I'm still reading this email thread and learned lots from it.
> I'm working on something more meaningful, but it's not going to be
> ground breaking of course, there is a led on my capslock key on a new
> machine I won at work that does not switch off properly after it is
> switched on.

Is it Debian-derivative by any chance? Their capslock setup is wonky
because CapsLock key does no actually set up as a CapsLock but another
modifier. Also is it in X or is it on text console? Because X handles
led state on its own...

> I think it is something to do with the LED_CAPSL variable
> in here:
>
> drivers/hid/usbhid/usbkbd.c

I do not think you are using usbkbd driver - it is for keyboards in
"boot protocol" and barely anyone users them in such mode. You need to
look into drivers/hid/hid-input.c.

Thanks.

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

[PATCH 5/5] selinux: use sprintf return value

[Rasmus Villemoes]

sprintf returns the number of characters printed (excluding '\0'), so
we can use that and avoid duplicating the length computation.

Signed-off-by: Rasmus Villemoes 
---
 security/selinux/ss/services.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index aa2bdcb20848..ebb5eb3c318c 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1218,13 +1218,10 @@ static int context_struct_to_string(struct context 
*context, char **scontext, u3
/*
 * Copy the user name, role name and type name into the context.
 */
-   sprintf(scontextp, "%s:%s:%s",
+   scontextp += sprintf(scontextp, "%s:%s:%s",
sym_name(, SYM_USERS, context->user - 1),
sym_name(, SYM_ROLES, context->role - 1),
sym_name(, SYM_TYPES, context->type - 1));
-   scontextp += strlen(sym_name(, SYM_USERS, context->user - 1)) +
-1 + strlen(sym_name(, SYM_ROLES, context->role - 
1)) +
-1 + strlen(sym_name(, SYM_TYPES, context->type - 
1));
 
mls_sid_to_context(context, );
 
-- 
2.1.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 3/5] selinux: use kmemdup in security_sid_to_context_core()

[Rasmus Villemoes]

Signed-off-by: Rasmus Villemoes 
---
 security/selinux/ss/services.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index c550df0e0ff1..994c824a34c6 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1259,12 +1259,12 @@ static int security_sid_to_context_core(u32 sid, char 
**scontext,
*scontext_len = strlen(initial_sid_to_string[sid]) + 1;
if (!scontext)
goto out;
-   scontextp = kmalloc(*scontext_len, GFP_ATOMIC);
+   scontextp = kmemdup(initial_sid_to_string[sid],
+   *scontext_len, GFP_ATOMIC);
if (!scontextp) {
rc = -ENOMEM;
goto out;
}
-   strcpy(scontextp, initial_sid_to_string[sid]);
*scontext = scontextp;
goto out;
}
-- 
2.1.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 0/5] selinux: minor cleanup suggestions

[Rasmus Villemoes]

A few random things I stumbled on.

While I'm pretty sure of the change in 1/5, I'm also confused, because
the doc for the reverse security_sid_to_context state that
@scontext_len is set to "the length of the string", which one would
normally interpret as being what strlen() would give (i.e., without
the \0). However, security_sid_to_context_core clearly includes the \0
in the return value, and I think callers rely on that.

Rasmus Villemoes (5):
  selinux: introduce security_context_str_to_sid
  selinux: remove pointless cast in selinux_inode_setsecurity()
  selinux: use kmemdup in security_sid_to_context_core()
  selinux: use kstrdup() in security_get_bools()
  selinux: use sprintf return value

 security/selinux/hooks.c| 14 +-
 security/selinux/include/security.h |  2 ++
 security/selinux/selinuxfs.c| 26 +-
 security/selinux/ss/services.c  | 22 +-
 4 files changed, 25 insertions(+), 39 deletions(-)

-- 
2.1.3

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

[PATCH 1/5] selinux: introduce security_context_str_to_sid

[Rasmus Villemoes]

There seems to be a little confusion as to whether the scontext_len
parameter of security_context_to_sid() includes the nul-byte or
not. Reading security_context_to_sid_core(), it seems that the
expectation is that it does not (both the string copying and the test
for scontext_len being zero hint at that).

Introduce the helper security_context_str_to_sid() to do the strlen()
call and fix all callers.

Signed-off-by: Rasmus Villemoes 
---
 security/selinux/hooks.c| 12 
 security/selinux/include/security.h |  2 ++
 security/selinux/selinuxfs.c| 26 +-
 security/selinux/ss/services.c  |  5 +
 4 files changed, 20 insertions(+), 25 deletions(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e4369d86e588..fd50cd5ac2ec 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -674,10 +674,9 @@ static int selinux_set_mnt_opts(struct super_block *sb,
 
if (flags[i] == SBLABEL_MNT)
continue;
-   rc = security_context_to_sid(mount_options[i],
-strlen(mount_options[i]), , 
GFP_KERNEL);
+   rc = security_context_str_to_sid(mount_options[i], , 
GFP_KERNEL);
if (rc) {
-   printk(KERN_WARNING "SELinux: security_context_to_sid"
+   printk(KERN_WARNING "SELinux: 
security_context_str_to_sid"
   "(%s) failed for (dev %s, type %s) errno=%d\n",
   mount_options[i], sb->s_id, name, rc);
goto out;
@@ -2617,15 +2616,12 @@ static int selinux_sb_remount(struct super_block *sb, 
void *data)
 
for (i = 0; i < opts.num_mnt_opts; i++) {
u32 sid;
-   size_t len;
 
if (flags[i] == SBLABEL_MNT)
continue;
-   len = strlen(mount_options[i]);
-   rc = security_context_to_sid(mount_options[i], len, ,
-GFP_KERNEL);
+   rc = security_context_str_to_sid(mount_options[i], , 
GFP_KERNEL);
if (rc) {
-   printk(KERN_WARNING "SELinux: security_context_to_sid"
+   printk(KERN_WARNING "SELinux: 
security_context_str_to_sid"
   "(%s) failed for (dev %s, type %s) errno=%d\n",
   mount_options[i], sb->s_id, sb->s_type->name, 
rc);
goto out_free_opts;
diff --git a/security/selinux/include/security.h 
b/security/selinux/include/security.h
index 6a681d26bf20..223e9fd15d66 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -166,6 +166,8 @@ int security_sid_to_context_force(u32 sid, char **scontext, 
u32 *scontext_len);
 int security_context_to_sid(const char *scontext, u32 scontext_len,
u32 *out_sid, gfp_t gfp);
 
+int security_context_str_to_sid(const char *scontext, u32 *out_sid, gfp_t gfp);
+
 int security_context_to_sid_default(const char *scontext, u32 scontext_len,
u32 *out_sid, u32 def_sid, gfp_t gfp_flags);
 
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 5bed7716f8ab..c02da25d7b63 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -731,13 +731,11 @@ static ssize_t sel_write_access(struct file *file, char 
*buf, size_t size)
if (sscanf(buf, "%s %s %hu", scon, tcon, ) != 3)
goto out;
 
-   length = security_context_to_sid(scon, strlen(scon) + 1, ,
-GFP_KERNEL);
+   length = security_context_str_to_sid(scon, , GFP_KERNEL);
if (length)
goto out;
 
-   length = security_context_to_sid(tcon, strlen(tcon) + 1, ,
-GFP_KERNEL);
+   length = security_context_str_to_sid(tcon, , GFP_KERNEL);
if (length)
goto out;
 
@@ -819,13 +817,11 @@ static ssize_t sel_write_create(struct file *file, char 
*buf, size_t size)
objname = namebuf;
}
 
-   length = security_context_to_sid(scon, strlen(scon) + 1, ,
-GFP_KERNEL);
+   length = security_context_str_to_sid(scon, , GFP_KERNEL);
if (length)
goto out;
 
-   length = security_context_to_sid(tcon, strlen(tcon) + 1, ,
-GFP_KERNEL);
+   length = security_context_str_to_sid(tcon, , GFP_KERNEL);
if (length)
goto out;
 
@@ -882,13 +878,11 @@ static ssize_t sel_write_relabel(struct file *file, char 
*buf, size_t size)
if (sscanf(buf, "%s %s %hu", scon, tcon, ) != 3)
goto out;
 
-   length = security_context_to_sid(scon, strlen(scon) + 1, ,
-   

Re: [PATCH 10/26] x86, pkeys: notify userspace about protection key faults

[Dave Hansen]

On 09/25/2015 12:11 AM, Ingo Molnar wrote:
>>> > > Btw., how does pkey support interact with hugepages?
>> > 
>> > Surprisingly little.  I've made sure that everything works with huge pages 
>> > and 
>> > that the (huge) PTEs and VMAs get set up correctly, but I'm not sure I had 
>> > to 
>> > touch the huge page code at all.  I have test code to ensure that it works 
>> > the 
>> > same as with small pages, but everything worked pretty naturally.
> Yeah, so the reason I'm asking about expectations is that this code:
> 
> +   follow_ret = follow_pte(tsk->mm, address, , );
> +   if (!follow_ret) {
> +   /*
> +* On a successful follow, make sure to
> +* drop the lock.
> +*/
> +   pte = *ptep;
> +   pte_unmap_unlock(ptep, ptl);
> +   ret = pte_pkey(pte);
> 
> is visibly hugepage-unsafe: if a vma is hugepage mapped, there are no ptes, 
> only 
> pmds - and the protection key index lives in the pmd. We don't seem to 
> recover 
> that information properly.

You got me on this one.  I assumed that follow_pte() handled huge pages.
 It does not.

But, the code still worked.  Since follow_pte() fails for all huge
pages, it just falls back to pulling the protection key out of the VMA,
which _does_ work for huge pages.

I've actually removed the PTE walking and I just now use the VMA
directly.  I don't see a ton of additional value from walking the page
tables when we can get what we need from the VMA.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] Broadcom iProc PCIe fixes and outbound mapping support

[Bjorn Helgaas]

On Tue, Sep 15, 2015 at 05:39:14PM -0700, Ray Jui wrote:
> This patch series contains various fixes and outbound mapping support for
> the Broadcom iProc PCIe driver. Some of the critical fixes include 1) fix of
> PCIe core reset logic and therefore remove its dependency on the bootloader;
> 2) improved link detection logic that works for more iProc based SoCs.
> 
> This patch series also adds the outbound address mapping support. While
> outbound address mapping support is not required on chips like North Star,
> Cygnus, and etc., some of the newer iProc based chips like North Star 2 
> require
> this support to properly map the AXI address into the address used in the 
> iProc
> PCIe core
> 
> This patch series is constructed based on Linux v4.3-rc1 (with workaround to
> disable calls to pci_read_bridge_bases in pci/probe.c that breaks some of the
> ARM based PCIe devices including iProc)
> 
> This patch series is tested on the following platforms with an Intel e1000e
> based PCIe x1 NIC card:
> - ARM32 based Cygnus BCM958305K Wireless Audio board
> - ARM64 based North Star 2 SVK board
> 
> code available at GITHUB:
> https://github.com/Broadcom/cygnus-linux/tree/iproc-pcie-fix-v1
> 
> Ray Jui (8):
>   PCI: iproc: Fix code comment
>   PCI: iproc: Remove unused code
>   PCI: iproc: Remove ARCH specific flag
>   PCI: iproc: Fix PCIe reset logic
>   PCI: iproc: Improve link detection logic
>   PCI: iproc: Update iProc PCIe device tree bindings
>   PCI: iproc: Add outbound mapping support
>   PCI: iproc: Fix compile warnings
> 
>  .../devicetree/bindings/pci/brcm,iproc-pcie.txt|  20 +++
>  drivers/pci/host/pcie-iproc-platform.c |  27 
>  drivers/pci/host/pcie-iproc.c  | 159 
> +++--
>  drivers/pci/host/pcie-iproc.h  |  20 ++-
>  4 files changed, 210 insertions(+), 16 deletions(-)

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

[PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

[Matt Fleming]

From: Matt Fleming 

Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that
signals that the firmware PE/COFF loader supports splitting code and
data sections of PE/COFF images into separate EFI memory map entries.
This allows the kernel to map those regions with strict memory
protections, e.g. EFI_MEMORY_RO for code, EFI_MEMORY_XP for data, etc.

Unfortunately, an unwritten requirement of this new feature is that
the regions need to be mapped with the same offsets relative to each
other as observed in the EFI memory map. If this is not done crashes
like this may occur,

 [0.006391] BUG: unable to handle kernel paging request at fffefe6086dd
 [0.006923] IP: [] 0xfffefe6086dd
 [0.007000] Call Trace:
 [0.007000]  [] efi_call+0x7e/0x100
 [0.007000]  [] ? virt_efi_set_variable+0x61/0x90
 [0.007000]  [] efi_delete_dummy_variable+0x63/0x70
 [0.007000]  [] efi_enter_virtual_mode+0x383/0x392
 [0.007000]  [] start_kernel+0x38a/0x417
 [0.007000]  [] x86_64_start_reservations+0x2a/0x2c
 [0.007000]  [] x86_64_start_kernel+0xeb/0xef

Here 0xfffefe6086dd refers to an address the firmware expects to
be mapped but which the OS never claimed was mapped. The issue is that
included in these regions are relative addresses to other regions
which were emitted by the firmware toolchain before the "splitting" of
sections occurred at runtime.

Needless to say, we don't satisfy this unwritten requirement on x86_64
and instead map the EFI memory map entries in reverse order. The above
crash is almost certainly triggerable with any kernel newer than v3.13
because that's when we rewrote the EFI runtime region mapping code, in
commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping"). For
kernel versions before v3.13 things may work by pure luck depending on
the fragmentation of the kernel virtual address space at the time we
map the EFI regions.

Instead of mapping the EFI memory map entries in reverse order, where
entry N has a higher virtual address than entry N+1, map them in the
same order as they appear in the EFI memory map to preserve this
relative offset between regions.

This patch has been kept as small as possible with the intention that
it should be applied aggressively to stable and distribution kernels.
It is very much a bugfix rather than support for a new feature, since
when EFI_PROPERTIES_TABLE is enabled we must map things as outlined
above to even boot - we have no way of asking the firmware not to
split the code/data regions.

In fact, this patch doesn't even make use of the more strict memory
protections available in UEFI v2.5. That will come later.

Reported-by: Ard Biesheuvel 
Suggested-by: Ard Biesheuvel 
Cc: "Lee, Chun-Yi" 
Cc: Borislav Petkov 
Cc: Leif Lindholm 
Cc: Peter Jones 
Cc: James Bottomley 
Cc: Matthew Garrett 
Cc: H. Peter Anvin 
Cc: Dave Young 
Cc: 
Signed-off-by: Matt Fleming 
---
 arch/x86/platform/efi/efi.c | 67 -
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 1db84c0758b7..6a28ded74211 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -705,6 +705,70 @@ out:
 }
 
 /*
+ * Iterate the EFI memory map in reverse order because the regions
+ * will be mapped top-down. The end result is the same as if we had
+ * mapped things forward, but doesn't require us to change the
+ * existing implementation of efi_map_region().
+ */
+static inline void *efi_map_next_entry_reverse(void *entry)
+{
+   /* Initial call */
+   if (!entry)
+   return memmap.map_end - memmap.desc_size;
+
+   entry -= memmap.desc_size;
+   if (entry < memmap.map)
+   return NULL;
+
+   return entry;
+}
+
+/*
+ * efi_map_next_entry - Return the next EFI memory map descriptor
+ * @entry: Previous EFI memory map descriptor
+ *
+ * This is a helper function to iterate over the EFI memory map, which
+ * we do in different orders depending on the current configuration.
+ *
+ * To begin traversing the memory map @entry must be %NULL.
+ *
+ * Returns %NULL when we reach the end of the memory map.
+ */
+static void *efi_map_next_entry(void *entry)
+{
+   if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
+   /*
+* Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
+* config table feature requires us to map all entries
+* in the same order as they appear in the EFI memory
+* map. That is to say, entry N must have a lower
+* virtual address than entry N+1. This is because the
+* firmware 

[GIT PULL 0/2] EFI urgent fixes

[Matt Fleming]

From: Matt Fleming 

Folks,

The patches in this pull request fix kernel crashes when booting Linux
on UEFI v2.5 machines with the Properties Table feature enabled.

Essentially, when this feature is enabled the firmware allocates
separate entries in the EFI memory map for the code and data sections
of PE/COFF images, whereas previously only one memory map entry would
have existed.

Because we've now got two entries that reference each other we *must*
map them into the kernel virtual address space with the same offsets
and in the same order as they appear in the EFI memory map. Failure to
do so causes the firmware to access unmapped/invalid addresses. 

These patches were intentionally kept as small as possible so that
they can be backported by distributions, aggressively.

The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde:

  Linux 4.3-rc2 (2015-09-20 14:32:34 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent

for you to fetch changes up to 1fa25e09ca2ce07f03bca93ad71800c312fd4951:

  arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions (2015-09-25 22:35:15 
+0100)


 * arm64 bug fix for UEFI 2.5 firmware that has the Properties Table
   feature enabled. The fix avoids a kernel crash by removing the padding
   between runtime regions that we currently do in the kernel so we don't
   break the EFI's cross-region references - Ard Biesheuvel

 * Map EFI memory regions in-order on x86 so that we maintain the
   relative offset between regions and fix a crash when booting on
   UEFI 2.5 machines with the Properties Table feature enabled.


Ard Biesheuvel (1):
  arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

Matt Fleming (1):
  x86/efi: Map EFI memmap entries in-order at runtime

 arch/arm64/kernel/efi.c |  3 +-
 arch/x86/platform/efi/efi.c | 67 -
 drivers/firmware/efi/libstub/arm-stub.c | 88 +++--
 3 files changed, 141 insertions(+), 17 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/