Re: net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"

[SF Markus Elfring]

> Whereas if you learn how to base your changes cleanly on the correct
> base now, all of your future submissions will go quickly and smoothly
> into my tree.

My reluctance to work with more Linux repositories will evolve
over time. The faster affected software versions can be rebuilt
the more it will become interesting to try even more source
code improvements out, won't it?

I find it nice that you could accept update suggestions for
a few other Linux components already.

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

Re: net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"

[SF Markus Elfring]

>> I imagine than someone other can also pick up this update suggestion
>> (a simple change of two lines) quicker before I might try another
>> software build again from a different commit as a base.
> 
> I have no idea why someone would do that.

I imagine that other software users (besides me) like developers
and testers might also become curious to try the proposed changes out.

How much will they eventually help to run Linux components a bit faster?


> If you don't bother resubmit, nobody will.

I hope that there are more possibilities for anticipation and acceptance
of source code improvement potentials.
Would you also like to contribute a bit more fine-tuning for the affected
software versions?

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

Re: [PATCH v4 2/5] x86, traps: Track entry into and exit from IST context

[Paul E. McKenney]

On Fri, Nov 21, 2014 at 09:53:29PM -0800, Andy Lutomirski wrote:
> On Fri, Nov 21, 2014 at 8:20 PM, Paul E. McKenney
>  wrote:
> > On Fri, Nov 21, 2014 at 06:00:14PM -0800, Andy Lutomirski wrote:
> >> On Fri, Nov 21, 2014 at 3:38 PM, Paul E. McKenney
> >>  wrote:
> >> > On Fri, Nov 21, 2014 at 03:06:48PM -0800, Andy Lutomirski wrote:
> >> >> On Fri, Nov 21, 2014 at 2:55 PM, Paul E. McKenney
> >> >>  wrote:
> >> >> > On Fri, Nov 21, 2014 at 02:19:17PM -0800, Andy Lutomirski wrote:
> >> >> >> On Fri, Nov 21, 2014 at 2:07 PM, Paul E. McKenney
> >> >> >>  wrote:
> >> >> >> > On Fri, Nov 21, 2014 at 01:32:50PM -0800, Andy Lutomirski wrote:
> >> >> >> >> On Fri, Nov 21, 2014 at 1:26 PM, Andy Lutomirski 
> >> >> >> >>  wrote:
> >> >> >> >> > We currently pretend that IST context is like standard exception
> >> >> >> >> > context, but this is incorrect.  IST entries from userspace are 
> >> >> >> >> > like
> >> >> >> >> > standard exceptions except that they use per-cpu stacks, so 
> >> >> >> >> > they are
> >> >> >> >> > atomic.  IST entries from kernel space are like NMIs from RCU's
> >> >> >> >> > perspective -- they are not quiescent states even if they
> >> >> >> >> > interrupted the kernel during a quiescent state.
> >> >> >> >> >
> >> >> >> >> > Add and use ist_enter and ist_exit to track IST context.  Even
> >> >> >> >> > though x86_32 has no IST stacks, we track these interrupts the 
> >> >> >> >> > same
> >> >> >> >> > way.
> >> >> >> >>
> >> >> >> >> I should add:
> >> >> >> >>
> >> >> >> >> I have no idea why RCU read-side critical sections are safe inside
> >> >> >> >> __do_page_fault today.  It's guarded by exception_enter(), but 
> >> >> >> >> that
> >> >> >> >> doesn't do anything if context tracking is off, and context 
> >> >> >> >> tracking
> >> >> >> >> is usually off. What am I missing here?
> >> >> >> >
> >> >> >> > Ah!  There are three cases:
> >> >> >> >
> >> >> >> > 1.  Context tracking is off on a non-idle CPU.  In this case, 
> >> >> >> > RCU is
> >> >> >> > still paying attention to CPUs running in both userspace 
> >> >> >> > and in
> >> >> >> > the kernel.  So if a page fault happens, RCU will be set 
> >> >> >> > up to
> >> >> >> > notice any RCU read-side critical sections.
> >> >> >> >
> >> >> >> > 2.  Context tracking is on on a non-idle CPU.  In this case, 
> >> >> >> > RCU
> >> >> >> > might well be ignoring userspace execution: NO_HZ_FULL and
> >> >> >> > all that.  However, as you pointed out, in this case the
> >> >> >> > context-tracking code lets RCU know that we have entered 
> >> >> >> > the
> >> >> >> > kernel, which means that RCU will again be paying 
> >> >> >> > attention to
> >> >> >> > RCU read-side critical sections.
> >> >> >> >
> >> >> >> > 3.  The CPU is idle.  In this case, RCU is ignoring the CPU, so
> >> >> >> > if we take a page fault when context tracking is off, life
> >> >> >> > will be hard.  But the kernel is not supposed to take page
> >> >> >> > faults in the idle loop, so this is not a problem.
> >> >> >>
> >> >> >> I guess so, as long as there are really no page faults in the idle 
> >> >> >> loop.
> >> >> >
> >> >> > As far as I know, there are not.  If there are, someone needs to let
> >> >> > me know!  ;-)
> >> >> >
> >> >> >> There are, however, machine checks in the idle loop, and maybe 
> >> >> >> kprobes
> >> >> >> (haven't checked), so I think this patch might fix real bugs.
> >> >> >
> >> >> > If you can get ISTs from the idle loop, then the patch is needed.
> >> >> >
> >> >> >> > Just out of curiosity...  Can an NMI occur in IST context?  If it 
> >> >> >> > can,
> >> >> >> > I need to make rcu_nmi_enter() and rcu_nmi_exit() deal properly 
> >> >> >> > with
> >> >> >> > nested calls.
> >> >> >>
> >> >> >> Yes, and vice versa.  That code looked like it handled nesting
> >> >> >> correctly, but I wasn't entirely sure.
> >> >> >
> >> >> > It currently does not, please see below patch.  Are you able to test
> >> >> > nesting?  It would be really cool if you could do so -- I have no
> >> >> > way to test this patch.
> >> >>
> >> >> I can try.  It's sort of easy -- I'll put an int3 into do_nmi and add
> >> >> a fixup to avoid crashing.
> >> >>
> >> >> What should I look for?  Should I try to force full nohz on and assert
> >> >> something?  I don't really know how to make full nohz work.
> >> >
> >> > You should look for the WARN_ON_ONCE() calls in rcu_nmi_enter() and
> >> > rcu_nmi_exit() to fire.
> >>
> >> No warning with or without your patch, maybe because all of those
> >> returns skip the labels.
> >
> > I will be guardedly optimistic and take this as a good sign.  ;-)
> >
> >> Also, an NMI can happen *during* rcu_nmi_enter or rcu_nmi_exit.  Is
> >> that okay?  Should those dynticks_nmi_nesting++ things be local_inc
> >> and local_dec_and_test?
> >
> > Yep, it is OK during rcu_nmi_enter() or rcu_nmi_exit().  The nested
> > NMI will put the 

Re: futex testsuite suggestion...

[Darren Hart]

On Mon, Oct 27, 2014 at 04:31:16PM -0400, David Miller wrote:
> From: Darren Hart 
> Date: Mon, 27 Oct 2014 13:29:14 -0700
> 
> > On 10/27/14 12:56, David Miller wrote:
> >> I'd like to suggest that you add a test that triggers transparent
> >> hugepages, because if an architecture doesn't implement
> >> __get_user_pages_fast() such futexes cause a machine to hang.
> >> 
> >> I hacked up something simple that took the existing performance
> >> test and made it operate in a register allocated using memalign().
> >> 
> >> I would suggest doing a memalign(HUGEPAGE_SIZE, HUGEPAGE_SIZE) then
> >> iterating running a futex test within each normal page within that
> >> hugepage.
> > 
> > Do you want this option for the performance tests, or would a less
> > intensive functional test be sufficient?
> 
> I think a functional test is sufficient.

Hi David,

>From your suggestion I put together a simple transparent hugepage functional
test. See the "thp" branch, functional/futex_wait_thp.c.

I'd like your thoughts on if this functions as desired. Is the simple single
threaded timeout sufficient, or would you prefer to see a waiter/waker pair of
threads for each iteration?

Some TODOs still:

I wasn't sure if there was a way to test for hugepagesize and my quick search
didn't reveal anything (other than /proc/meminfo).

Check at runtime if the test is getting a huge page, otherwise it just reports
success, but used several regular pages instead.

-- 
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-net 0/4] Increase the limit of tuntap queues

[Pankaj Gupta]

> On Wed, Nov 19, 2014 at 03:16:28PM -0500, David Miller wrote:
> > From: Pankaj Gupta 
> > Date: Tue, 18 Nov 2014 21:52:54 +0530
> > 
> > > - Accept maximum number of queues as sysctl param so that any user space
> > >   application like libvirt can use this value to limit number of queues.
> > >   Also
> > >   Administrators can specify maximum number of queues by updating this
> > >   sysctl
> > >   entry.
> > 
> > This is the only part I don't like.
> > 
> > Just let whoever has privileges to configure the tun device shoot
> > themselves in the foot if they want to by configuring "too many"
> > queues.
> > 
> > If the virtual entity runs itself out of resources by doing something
> > stupid, it's purely their problem.

We can configure some fixed number of queues like 16 or so at the start 
if multiqueue is enabled and then if somebody needs more then that, they
can do on their own.

If we dont want anyone to directly increase the number of queues, we can add
an ioctl command for increasing number of queues?



Suggestions here. 
> 
> Well it will run host out of kernel, no?
> 
> --
> MST
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ftrace/x86/extable] WARNING: CPU: 0 PID: 1 at init/main.c:803 do_one_initcall()

[Fengguang Wu]

On Sat, Nov 22, 2014 at 04:53:02PM -0500, Steven Rostedt wrote:
> On Sat, 22 Nov 2014 11:59:26 -0800
> Fengguang Wu  wrote:
> 
> >
> > > Is it possible for your tests to see if a branch was rebased before
> > > posting bug reports to LKML? This gave me a scare that my new code had
> > > the same brain fart in it.
> > 
> > Sure and good idea! I'll implement it right now.
> > 
> 
> It should also make sure that the rebase does not include the offending
> commit before not sending out the email. A rebase alone may still have
> the bug.
> 
> And if you really want to be fancy, you can check to see if the code
> itself changed. The attached script takes two git releases (SHA1s,
> tags, etc) or one git release and uses HEAD, and finds where the two
> are different. Not just by commit id, but also by code. I use this
> because I'll modify a branch to add an acked-by and not change the code,
> but still want to know the last commit that I tested. It may not have
> the same commit id.

I definitely would like to be fancy. I think I'll not only check if
the branch has been rebased, but also test the rebased branch out to
make sure the problem is still there. I've been doing this check for
the build bisects. When doing so, it no longer matters how the rebased
branch differs from the original branch in source code level. For
example, even the simple rebase to a new RC base might make a problem
disappear.

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

Re: [PATCH 2/4] i2c: omap: implement workaround for handling invalid BB-bit values

[Felipe Balbi]

On Sat, Nov 22, 2014 at 07:02:22PM +0100, Wolfram Sang wrote:
> On Sat, Nov 22, 2014 at 05:06:10PM +0300, Alexander Kochetkov wrote:
> > 
> > 22 нояб. 2014 г., в 16:23, Wolfram Sang  написал(а):
> > 
> > > Huh, I can't apply this one? Which kernel version is this based on?
> > 
> > v.3.13-rc8
> 
> Wow, that's old. Can you please rebase the series on top of 3.18-rc4? Or
> my i2c/for-next? Or at the very least 3.17?
> 
> @Felipe: With which kernel did you test the series? Also, 3.13?

maybe there was a typo? I tested on v3.18-rc3 :-)


-- 
balbi


signature.asc
Description: Digital signature

Re: net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"

[David Miller]

From: SF Markus Elfring 
Date: Sun, 23 Nov 2014 01:51:24 +0100

>> This has nothing to do with me asking you to frame your patches
>> against the correct tree.
> 
> I imagine than someone other can also pick up this update suggestion
> (a simple change of two lines) quicker before I might try another
> software build again from a different commit as a base.

Whereas if you learn how to base your changes cleanly on the correct
base now, all of your future submissions will go quickly and smoothly
into my tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

IMPORTANT MALWARE PRECAUTION!!!

[Help Desk]

Your e-mail account needs to be improved, with our new
F-Secure ? HTK4S anti-virus/anti-Spam 2014-version. Due to increase in
Account Hacking.

Fill in the columns below and send to Us or your account will be
temporarily excluded from our services.

E-mail Address(ID):
Old Password:
Desired New Password:
Desired New Password Again:
Phone:
Department:

* Please note that your password is encrypted with
1024-bit RSA keys for increased security.

" ACCOUNT SUPPORT TEAM".
? ACCOUNT ACCOUNT ABN 31 088 377 860 All Rights Reserved.
E-Mail Account Maintenance

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

Re: [PATCH 1/2] 8139too: Allow setting MTU larger than 1500

[Ben Hutchings]

On Fri, 2014-11-21 at 19:57 +0100, Alban wrote:
> On Fri, 21 Nov 2014 18:51:51 +
> Ben Hutchings  wrote:
> 
> > On Fri, 2014-11-21 at 14:58 +0100, Alban wrote:
> > > On Fri, 21 Nov 2014 00:34:34 +
> > > Ben Hutchings  wrote:
> > > 
> > > > On Sat, 2014-11-08 at 12:48 +0100, Alban Bedel wrote:
> > > > > Replace the default ndo_change_mtu callback with one that allow
> > > > > setting MTU that the driver can handle.
> > > > > 
> > > > > Signed-off-by: Alban Bedel 
> > > > > ---
> > > > >  drivers/net/ethernet/realtek/8139too.c | 13 -
> > > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/net/ethernet/realtek/8139too.c
> > > > > b/drivers/net/ethernet/realtek/8139too.c index 007b38c..8387de9
> > > > > 100644 --- a/drivers/net/ethernet/realtek/8139too.c
> > > > > +++ b/drivers/net/ethernet/realtek/8139too.c
> > > > > @@ -185,6 +185,9 @@ static int debug = -1;
> > > > >  /* max supported ethernet frame size -- must be at least
> > > > > (dev->mtu+14+4).*/ #define MAX_ETH_FRAME_SIZE 1536
> > > > >  
> > > > > +/* max supported payload size */
> > > > > +#define MAX_ETH_DATA_SIZE(MAX_ETH_FRAME_SIZE -
> > > > > ETH_HLEN - ETH_FCS_LEN)
> > > > [...]
> > > > 
> > > > Does this maximum still allow for VLAN tags, or should it use
> > > > VLAN_ETH_HLEN instead of ETH_HLEN?
> > > 
> > > That might well be as the VLAN code seems to assume that the
> > > physical device can handle frames of MTU + VLAN_HLEN bytes. I can
> > > fix it, but to me it seems like the VLAN code should be fixed to
> > > respect the physical device MTU.
> > 
> > Drivers that support VLANs have to allow for at least one VLAN tag
> > when validating the MTU.  This is obviously broken for multiple
> > layers of VLAN tags, but those are the semantics we're stuck with.
> 
> Ok, I see. Should a I send a fix patch or redo a new version of this
> patch?

As your previous patches have already been applied, you'll need to send
a fix patch (if the answer to my question was no).

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


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

Re: [PATCH] dell-smo8800: Add more acpi ids and change description of driver

[Pali Rohár]

Oops, I lost this mail somewhere...

I copied these ids from windows driver inf file. I did not tested 
them because I do not have machine which reports these ids. It 
looks like all SMOXX devices have same acpi structure (one IRQ). 
So adding ids could not break anything (if acpi device will not 
have for some reason IRQ specified, device probe function will 
fail).

On Monday 29 September 2014 22:56:04 Darren Hart wrote:
> On Mon, Sep 29, 2014 at 02:45:48PM +0200, Pali Rohár wrote:
> 
> Please see Documentation/SubmittingPatches, 15) The canonical
> patch format, and provide a complete message body.
> 
> Have you validated each of the 6 ACPI IDs added to the driver?
> 
> > Signed-off-by: Pali Rohár 
> > ---
> > 
> >  drivers/platform/x86/Kconfig|4 ++--
> >  drivers/platform/x86/dell-smo8800.c |   10 --
> >  2 files changed, 10 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/platform/x86/Kconfig
> > b/drivers/platform/x86/Kconfig index 3bbcbf1..ba9ee4f
> > 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -128,10 +128,10 @@ config DELL_WMI_AIO
> > 
> >   be called dell-wmi-aio.
> >  
> >  config DELL_SMO8800
> > 
> > -   tristate "Dell Latitude freefall driver (ACPI
> > SMO8800/SMO8810)" + tristate "Dell Latitude freefall driver
> > (ACPI SMO88XX)"
> > 
> > depends on ACPI
> > ---help---
> > 
> > - Say Y here if you want to support SMO8800/SMO8810
> > freefall device + Say Y here if you want to support
> > SMO88XX freefall device
> 
> "devices" now that multiple are supported.
> 
> Thanks,

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


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

Re: [RFC 2/2] This is a kernel driver for the Cadence QSPI Flash Controller. It uses the spi-nor framework.

[Ezequiel Garcia]

On 10/24/2014 03:34 PM, Graham Moore wrote:

The subject is completely off and you need a proper commit log,
git-log drivers/mtd/spi-nor/ for examples.

Some comments below from a first review.

> Signed-off-by: Graham Moore 
> ---
>  drivers/mtd/spi-nor/Kconfig   |6 +
>  drivers/mtd/spi-nor/Makefile  |1 +
>  drivers/mtd/spi-nor/cadence-quadspi.c | 1349 
> +
>  3 files changed, 1356 insertions(+)
>  create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c
> 
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 64a4f0e..9485481 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -28,4 +28,10 @@ config SPI_FSL_QUADSPI
> This enables support for the Quad SPI controller in master mode.
> We only connect the NOR to this controller now.
>  
> +config SPI_CADENCE_QUADSPI
> + tristate "Cadence Quad SPI controller"
> + depends on ARCH_SOCFPGA
> + help
> +   This enables support for the Cadence Quad SPI controller and NOR 
> flash.
> +
>  endif # MTD_SPI_NOR
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 6a7ce14..372628c 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_MTD_SPI_NOR)+= spi-nor.o
> +obj-$(CONFIG_SPI_CADENCE_QUADSPI)+= cadence-quadspi.o
>  obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
> b/drivers/mtd/spi-nor/cadence-quadspi.c
> new file mode 100644
> index 000..51c65de
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -0,0 +1,1349 @@
> +/*
> + * Driver for Cadence QSPI Controller
> + *
> + * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Headers should be ordered alphabetically.

> +
> +#define CQSPI_NAME   "cadence-qspi"
> +#define CQSPI_MAX_TRANS  (2)
> +#define CQSPI_MAX_CHIP_SELECT(16)

Here and below you have unneeded parenthesis around macros' values.

> +
> +struct cqspi_flash_pdata {
> + struct mtd_info mtd;
> + struct spi_nor nor;
> + unsigned int page_size;
> + unsigned int block_size;
> + unsigned int read_delay;
> + unsigned int tshsl_ns;
> + unsigned int tsd2d_ns;
> + unsigned int tchsh_ns;
> + unsigned int tslch_ns;
> +};
> +
> +struct cqspi_st {
> + struct platform_device *pdev;
> + struct device *dev;
> +
> + u32 clk_rate;
> + struct clk *clk;
> + unsigned int sclk;
> +
> + void __iomem *iobase;
> + void __iomem *ahb_base;
> + struct completion transfer_complete;
> + int irq;
> + unsigned int irq_status;

The irq and irq_status doesn't seem to be needed here.

> + unsigned int irq_mask;
> + int current_cs;
> + unsigned int bus_num;

Doesn't seem used.

> + unsigned int num_chipselect;

Doesn't seem used.

> + unsigned int ahb_phy_addr;
> + unsigned int master_ref_clk_hz;
> + unsigned int ext_decoder;
> + unsigned int fifo_depth;
> + unsigned int num_chipselects_used;
> + struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIP_SELECT];
> +};
> +
> +static struct of_device_id cqspi_dt_ids[] = {
> + { .compatible = "cdns,qspi-nor",},
> + { /* end of table */}
> +};
> +MODULE_DEVICE_TABLE(of, cqspi_dt_ids);
> +

IMHO, it's better to put this above the platorm_driver.

> +#define CQSPI_WRITEL __raw_writel
> +#define CQSPI_READL  __raw_readl
> +

Drop these macros and just use readl or readl_relaxed (which is
endian-friendly) directly.

> +/* Operation timeout value */
> +#define CQSPI_TIMEOUT_MS (5000)
> +#define CQSPI_POLL_IDLE_RETRY(3)
> +
> +#define CQSPI_FIFO_WIDTH (4)
> +
> +/* Controller sram size in word */
> +#define CQSPI_REG_SRAM_RESV_WORDS(2)
> +#define CQSPI_REG_SRAM_PARTITION_WR  (1)
> +
> +#define CQSPI_REG_SRAM_THRESHOLD_BYTES   (50)
> +
> +/* Instruction type 

Re: [PATCH v2 5/5] ARM: dts: exynos5410: Add ODROID-XU LEDs

[Andreas Färber]

Hello Hakjoo,

Am 22.11.2014 um 21:26 schrieb Andreas Färber:
> Signed-off-by: Hakjoo Kim 

Sorry, I was too quick here: Only the previous two patches got signed
off by you, plus the last one on your 3.14 branch. Are you able to sign
off all patches authored by you there? (An email reply indicating the
Signed-off-by should do, if updating the branch is too much work.)

Thanks,
Andreas

> Signed-off-by: Andreas Färber 
> ---
> v1 -> v2:
> * Filled in Sob from Hakjoo Kim
> 
>  arch/arm/boot/dts/exynos5410-odroidxu.dts | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts 
> b/arch/arm/boot/dts/exynos5410-odroidxu.dts
> index 97310bb727e2..b02cd3ab7b38 100644
> --- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
> +++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
> @@ -15,6 +15,7 @@
>  
>  /dts-v1/;
>  #include "exynos5410.dtsi"
> +#include 
>  / {
>   model = "ODROID-XU based on EXYNOS5410";
>   compatible = "hardkernel,odroid-xu", "samsung,exynos5410", 
> "samsung,exynos5";
> @@ -39,6 +40,30 @@
>   reg = <0x02037000 0x1000>;
>   };
>  
> + leds {
> + compatible = "gpio-leds";
> +
> + blue {
> + label = "blue:heartbeat";
> + gpios = < 2 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "heartbeat";
> + };
> +
> + green {
> + label = "green:activity";
> + gpios = < 1 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc0";
> + };
> +
> + red {
> + label = "red:activity";
> + gpios = < 3 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc1";
> + };
> + };
>  };
>  
>  _0 {
> 


-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Low Interest Rate!

[Ocean Finance And Bussiness Co]

Do You Need A Loan?Apply Now For More Details.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"

[Eric Dumazet]

On Sun, 2014-11-23 at 01:51 +0100, SF Markus Elfring wrote:
> > This has nothing to do with me asking you to frame your patches
> > against the correct tree.
> 
> I imagine than someone other can also pick up this update suggestion
> (a simple change of two lines) quicker before I might try another
> software build again from a different commit as a base.

I have no idea why someone would do that.

If you don't bother resubmit, nobody will.


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

Re: [PATCH v7 6/7] sched: replace capacity_factor by usage

[Wanpeng Li]

Hi Vincent,
On 10/9/14, 10:18 PM, Vincent Guittot wrote:

On 9 October 2014 14:16, Peter Zijlstra  wrote:

On Tue, Oct 07, 2014 at 02:13:36PM +0200, Vincent Guittot wrote:

+static inline bool
+group_has_capacity(struct lb_env *env, struct sg_lb_stats *sgs)
  {
+ if ((sgs->group_capacity * 100) >
+ (sgs->group_usage * env->sd->imbalance_pct))
+ return true;

Why the imb_pct there? We're looking for 100% utilization, not 130 or
whatnot, right?

Having exactly 100% is quite difficult because of various rounding.


Could you give some examples about the various rounding？

Regards,
Wanpeng Li


So i have added a margin/threshold to prevent any excessive change of the state.
I have just to use the same margin/threshold than in other place in
load balance.

so the current threshold depends of the sched_level. it's around 14% at MC level


+ if (sgs->sum_nr_running < sgs->group_weight)
+ return true;

With the code as it stands, this is the cheaper test (no mults) so why
is it second?


+ return false;
+}

+static inline bool
+group_is_overloaded(struct lb_env *env, struct sg_lb_stats *sgs)
+{
+ if (sgs->sum_nr_running <= sgs->group_weight)
+ return false;
+
+ if ((sgs->group_capacity * 100) <
+ (sgs->group_usage * env->sd->imbalance_pct))
+ return true;

+ return false;
  }

Same thing here wrt imb_pct

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


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

Re: [PATCH] clk: rockchip: fix clock gate for rk3188 spdif_pre

[Heiko Stübner]

Am Freitag, 21. November 2014, 10:27:41 schrieb Julien CHAUVEAU:
> In rk3188 clock branches, spdif_pre gate was set to RK2928_CLKGATE_CON(13)
> bit 13. This appears to be a copy-paste error because such a register does
> not exist. We correct it to RK2928_CLKGATE_CON(0) and find out that the
> rk3188 spdif clock is the same as the rk3066 spdif clock, so we move it to
> the common clock branches.
> 
> Signed-off-by: Julien CHAUVEAU 

applied to my clk branch for 3.19 after verifying the manual-values


Thanks
Heiko

> ---
>  drivers/clk/rockchip/clk-rk3188.c | 25 +
>  1 file changed, 9 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3188.c
> b/drivers/clk/rockchip/clk-rk3188.c index b0293c4..725d841 100644
> --- a/drivers/clk/rockchip/clk-rk3188.c
> +++ b/drivers/clk/rockchip/clk-rk3188.c
> @@ -330,6 +330,15 @@ static struct rockchip_clk_branch common_clk_branches[]
> __initdata = { RK2928_CLKSEL_CON(24), 8, 8, DFLAGS,
>   RK2928_CLKGATE_CON(2), 8, GFLAGS),
> 
> + COMPOSITE_NOMUX(0, "spdif_pre", "i2s_src", 0,
> + RK2928_CLKSEL_CON(5), 0, 7, DFLAGS,
> + RK2928_CLKGATE_CON(0), 13, GFLAGS),
> + COMPOSITE_FRAC(0, "spdif_frac", "spdif_pll", 0,
> + RK2928_CLKSEL_CON(9), 0,
> + RK2928_CLKGATE_CON(0), 14, GFLAGS),
> + MUX(SCLK_SPDIF, "sclk_spdif", mux_sclk_spdif_p, 0,
> + RK2928_CLKSEL_CON(5), 8, 2, MFLAGS),
> +
>   /*
>* Clock-Architecture Diagram 4
>*/
> @@ -577,14 +586,6 @@ static struct rockchip_clk_branch
> rk3066a_clk_branches[] __initdata = { RK2928_CLKGATE_CON(0), 12, GFLAGS),
>   MUX(SCLK_I2S2, "sclk_i2s2", mux_sclk_i2s2_p, 0,
>   RK2928_CLKSEL_CON(4), 8, 2, MFLAGS),
> - COMPOSITE_NOMUX(0, "spdif_pre", "i2s_src", 0,
> - RK2928_CLKSEL_CON(5), 0, 7, DFLAGS,
> - RK2928_CLKGATE_CON(0), 13, GFLAGS),
> - COMPOSITE_FRAC(0, "spdif_frac", "spdif_pll", 0,
> - RK2928_CLKSEL_CON(9), 0,
> - RK2928_CLKGATE_CON(0), 14, GFLAGS),
> - MUX(SCLK_SPDIF, "sclk_spdif", mux_sclk_spdif_p, 0,
> - RK2928_CLKSEL_CON(5), 8, 2, MFLAGS),
> 
>   GATE(HCLK_I2S1, "hclk_i2s1", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 3,
> GFLAGS), GATE(HCLK_I2S2, "hclk_i2s2", "hclk_cpu", 0, RK2928_CLKGATE_CON(7),
> 4, GFLAGS), @@ -675,14 +676,6 @@ static struct rockchip_clk_branch
> rk3188_clk_branches[] __initdata = { RK2928_CLKGATE_CON(0), 10, GFLAGS),
>   MUX(SCLK_I2S0, "sclk_i2s0", mux_sclk_i2s0_p, 0,
>   RK2928_CLKSEL_CON(3), 8, 2, MFLAGS),
> - COMPOSITE_NOMUX(0, "spdif_pre", "i2s_src", 0,
> - RK2928_CLKSEL_CON(5), 0, 7, DFLAGS,
> - RK2928_CLKGATE_CON(13), 13, GFLAGS),
> - COMPOSITE_FRAC(0, "spdif_frac", "spdif_pll", 0,
> - RK2928_CLKSEL_CON(9), 0,
> - RK2928_CLKGATE_CON(0), 14, GFLAGS),
> - MUX(SCLK_SPDIF, "sclk_spdif", mux_sclk_spdif_p, 0,
> - RK2928_CLKSEL_CON(5), 8, 2, MFLAGS),
> 
>   GATE(0, "hclk_imem0", "hclk_cpu", 0, RK2928_CLKGATE_CON(4), 14, GFLAGS),
>   GATE(0, "hclk_imem1", "hclk_cpu", 0, RK2928_CLKGATE_CON(4), 15, GFLAGS),

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: rockchip: fix rk3188 USB HSIC PHY clock divider

[Heiko Stübner]

Am Freitag, 21. November 2014, 11:08:47 schrieb Julien CHAUVEAU:
> The USB HSIC PHY clock divider is set in the register RK2928_CLKSEL_CON(11).
> 
> Signed-off-by: Julien CHAUVEAU 

applied to my clk branch for 3.19


Thanks
Heiko

> ---
>  drivers/clk/rockchip/clk-rk3188.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3188.c
> b/drivers/clk/rockchip/clk-rk3188.c index 725d841..f27ea47 100644
> --- a/drivers/clk/rockchip/clk-rk3188.c
> +++ b/drivers/clk/rockchip/clk-rk3188.c
> @@ -664,7 +664,7 @@ static struct rockchip_clk_branch rk3188_clk_branches[]
> __initdata = { RK2928_CLKSEL_CON(30), 0, 2, DFLAGS,
>   RK2928_CLKGATE_CON(3), 6, GFLAGS),
>   DIV(0, "sclk_hsicphy_12m", "sclk_hsicphy_480m", 0,
> - RK2928_CLKGATE_CON(11), 8, 6, DFLAGS),
> + RK2928_CLKSEL_CON(11), 8, 6, DFLAGS),
> 
>   MUX(0, "i2s_src", mux_pll_src_gpll_cpll_p, 0,
>   RK2928_CLKSEL_CON(2), 15, 1, MFLAGS),

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"

[SF Markus Elfring]

> This has nothing to do with me asking you to frame your patches
> against the correct tree.

I imagine than someone other can also pick up this update suggestion
(a simple change of two lines) quicker before I might try another
software build again from a different commit as a base.

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

Re: [PATCH percpu/for-3.18-fixes] percpu-ref: fix DEAD flag contamination of percpu pointer

[Shaohua Li]

On Sat, Nov 22, 2014 at 12:06:02PM -0500, Tejun Heo wrote:
> On Sat, Nov 22, 2014 at 09:04:48AM -0800, Shaohua Li wrote:
> ...
> > > + /*
> > > +  * Theoretically, the following could test just ATOMIC; however,
> > > +  * then we'd have to mask off DEAD separately as DEAD may be
> > > +  * visible without ATOMIC if we race with percpu_ref_kill().  DEAD
> > > +  * implies ATOMIC anyway.  Test them together.
> > > +  */
> > > + if (unlikely(percpu_ptr & __PERCPU_REF_ATOMIC_DEAD))
> > >   return false;
> > 
> > this sounds not the correct answer. the DEAD/ATOMIC bit can be set by
> > percpu_ref_kill() right after the check.
> 
> Yes, but that's why we're fetching @percpu_ptr with ACCESS_ONCE()
> before checking the flags.

Ok, I forgot we cache the percpu_ptr. Yes, this does work. You can add my
signed-off in the patch.

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

Re: [PATCH v6 5/6] sched: replace capacity_factor by usage

[Wanpeng Li]

Hi Vincent,
On 10/3/14, 8:50 PM, Vincent Guittot wrote:

On 3 October 2014 11:35, Morten Rasmussen  wrote:

On Fri, Oct 03, 2014 at 08:24:23AM +0100, Vincent Guittot wrote:

On 2 October 2014 18:57, Morten Rasmussen  wrote:

On Tue, Sep 23, 2014 at 05:08:04PM +0100, Vincent Guittot wrote:

Below are two examples to illustrate the problem that this patch solves:

1 - capacity_factor makes the assumption that max capacity of a CPU is
SCHED_CAPACITY_SCALE and the load of a thread is always is
SCHED_LOAD_SCALE. It compares the output of these figures with the sum
of nr_running to decide if a group is overloaded or not.

But if the default capacity of a CPU is less than SCHED_CAPACITY_SCALE
(640 as an example), a group of 3 CPUS will have a max capacity_factor
of 2 ( div_round_closest(3x640/1024) = 2) which means that it will be
seen as overloaded if we have only one task per CPU.

I did some testing on TC2 which has the setup you describe above on the
A7 cluster when the clock-frequency property is set in DT. The two A15s
have max capacities above 1024. When using sysbench with five threads I
still get three tasks on the two A15s and two tasks on the three A7
leaving one cpu idle (on average).

Using cpu utilization (usage) does correctly identify the A15 cluster as
overloaded and it even gets as far as selecting the A15 running two
tasks as the source cpu in load_balance(). However, load_balance() bails
out without pulling the task due to calculate_imbalance() returning a
zero imbalance. calculate_imbalance() bails out just before the hunk you
changed due to comparison of the sched_group avg_loads. sgs->avg_load is
basically the sum of load in the group divided by its capacity. Since
load isn't scaled the avg_load of the overloaded A15 group is slightly
_lower_ than the partially idle A7 group. Hence calculate_imbalance()
bails out, which isn't what we want.

I think we need to have a closer look at the imbalance calculation code
and any other users of sgs->avg_load to get rid of all code making
assumptions about cpu capacity.

We already had this discussion during the review of a previous version
https://lkml.org/lkml/2014/6/3/422
and my answer has not changed; This patch is necessary to solve the 1
task per CPU issue of the HMP system but is not enough. I have a patch
for solving the imbalance calculation issue and i have planned to send
it once this patch will be in a good shape for being accepted by
Peter.

I don't want to mix this patch and the next one because there are
addressing different problem: this one is how evaluate the capacity of
a system and detect when a group is overloaded and the next one will
handle the case when the balance of the system can't rely on the
average load figures of the group because we have a significant
capacity difference between groups. Not that i haven't specifically
mentioned HMP for the last patch because SMP system can also take
advantage of it

You do mention 'big' and 'little' cores in your commit message and quote
example numbers with are identical to the cpu capacities for TC2. That

By last patch, i mean the patch about imbalance that i haven't sent
yet, but it's not related with this patch


lead me to believe that this patch would address the issues we see for
HMP systems. But that is clearly wrong. I would suggest that you drop

This patch addresses one issue: correctly detect how much capacity we
have and correctly detect when the group is overloaded; HMP system


What's the meaning of "HMP system"?

Regards,
Wanpeng Li


clearly falls in this category but not only.
This is the only purpose of this patch and not the "1 task per CPU
issue" that you mentioned.

The second patch is about correctly balance the tasks on system where
the capacity of a group is significantly less than another group. It
has nothing to do in capacity computation and overload detection but
it will use these corrected/new metrics to make a better choice.

Then, there is the "1 task per CPU issue on HMP" that you mentioned
and this latter will be solved thanks to these 2 patchsets but this is
not the only/main target of these patchsets so i don't want to reduce
them into: "solve an HMP issue"


mentioning big and little cores and stick to only describing cpu
capacity reductions due to rt tasks and irq to avoid any confusion about
the purpose of the patch. Maybe explicitly say that non-default cpu
capacities (capacity_orig) isn't addressed yet.

But they are addressed by this patchset. you just mixed various goal
together (see above)


I think the two problems you describe are very much related. This patch
set is half the solution of the HMP balancing problem. We just need the
last bit for avg_load and then we can add scale-invariance on top.

i don't see the link between scale invariance and a bad load-balancing
choice. The fact that the current load balancer puts more tasks than
CPUs in a group on HMP system should not influence or break the scale
invariance load tracking. Isn't it ?

Re: [PATCH] sony-laptop: add support for Sony Vaio Fit multi-flip laptop/presentation/tablet transformation

[Mattia Dongili]

On Fri, Nov 21, 2014 at 10:55:04AM -0800, Darren Hart wrote:
> On Thu, Nov 20, 2014 at 11:51:12AM +0300, Alexander Gavrilenko wrote:
> > Current mode is exported via sysfs:
> > /sys/devices/platform/sony-laptop/tablet
> > 
> 
> Merging with your reply and a few updates from me, you OK with:

I'll piggy-back on this merged mail for some other comments.

> 
> sony-laptop: Support Sony Vaio Fit multi-flip tablet transformations
> 
> Transformation events are sent through the ACPI bus as sony/hotkey
> events. Tablet mode also triggers the SW_TABLET_MODE event via the
> Sony Vaio Keys input device.
> 

could you send me (privately) the whole DSDT from a Vaio FIT? I think I
found one implementation, is it something like this?

If (LEqual (Local0, 0x0E))
{
And (Local1, 0x03, Local1)
If (LEqual (Local1, Zero))
{
Store (One, ^^EC0.STEN)
Return (Arg0)
}

If (LEqual (Local1, One))
{
Store (Zero, ^^EC0.STEN)
Return (Arg0)
}

If (LEqual (Local1, 0x02))
{
Store (Zero, Local5)
And (^^EC0.MDST, 0x03, Local5)
Return (Local5)
}
}


> Current mode is exported via sysfs:
> /sys/devices/platform/sony-laptop/tablet
> 
> It's important to keep the subject under 72 characters or so, or it
> gets truncated for a lot of git users.
> 
> > Signed-off-by: Alexander Gavrilenko 
> > ---
> > --- linux-3.17.3/drivers/platform/x86/sony-laptop.c.orig2014-11-19 
> > 13:15:35.965048636 +0300
> > +++ linux-3.17.3/drivers/platform/x86/sony-laptop.c 2014-11-19 
> > 13:17:21.139166837 +0300
> > @@ -135,6 +135,13 @@ MODULE_PARM_DESC(kbd_backlight_timeout,
> >  "meaningful values vary from 0 to 3 and their meaning depends "
> >  "on the model (default: no change from current value)");
> >  
> > +static int tablet_mode = 2;
> > +module_param(tablet_mode, int, 0);
> > +MODULE_PARM_DESC(tablet_mode,
> > +"set this if your laptop have different tablet mode value, "
> 
> s/have/has a/
> 
> Generally speaking module params requied for normal usage a frowned upon.
> 
> This looks like something we should be able to detect by the HID or at worst 
> the
> DMI strings. Maybe I'm missing something, why is this needed?

I'd agree this parameter is unnecessary at the moment. In many cases,
different implementations of the same functionality end up having a
different handle (0x16f in this case). You may be able to use different
values based on that.
Also, how many other tablet_mode values are known so far? If only "2" then
I wouldn't bother using this module parameter.

...
> > +"default is 2 (Sony Vaio Fit multi-flip), "
> > +"only affects SW_TABLET_MODE events");
> > +
> >  #ifdef CONFIG_PM_SLEEP
> >  static void sony_nc_thermal_resume(void);
> >  #endif
> > @@ -181,6 +188,11 @@ static int sony_nc_touchpad_setup(struct
> >   unsigned int handle);
> >  static void sony_nc_touchpad_cleanup(struct platform_device *pd);
> >  
> > +static int sony_nc_tablet_mode_setup(struct platform_device *pd,
> > + unsigned int handle);
> > +static void sony_nc_tablet_mode_cleanup(struct platform_device *pd);
> > +static int sony_nc_tablet_mode_update(void);
> > +
> >  enum sony_nc_rfkill {
> > SONY_WIFI,
> > SONY_BLUETOOTH,
> > @@ -1198,7 +1210,8 @@ static int sony_nc_hotkeys_decode(u32 ev
> >  enum event_types {
> > HOTKEY = 1,
> > KILLSWITCH,
> > -   GFX_SWITCH
> > +   GFX_SWITCH,
> > +   TABLET_MODE_SWITCH
> >  };
> >  static void sony_nc_notify(struct acpi_device *device, u32 event)
> >  {
> > @@ -1273,6 +1286,10 @@ static void sony_nc_notify(struct acpi_d
> > ev_type = GFX_SWITCH;
> > real_ev = __sony_nc_gfx_switch_status_get();
> > break;
> > +   case 0x016f:
> > +   ev_type = TABLET_MODE_SWITCH;
> > +   real_ev = sony_nc_tablet_mode_update();
> > +   break;
> > default:
> > dprintk("Unknown event 0x%x for handle 0x%x\n",
> > event, handle);
> > @@ -1428,6 +1445,13 @@ static void sony_nc_function_setup(struc
> > pr_err("couldn't set up smart connect support 
> > (%d)\n",
> > result);
> > break;
> > +   case 0x016f:
> > +   /* laptop/presentation/tablet transformation for Sony 
> > Vaio Fit 11a/13a/14a/15a */
> 
> The comment can wrap to meet line length guidelines.
> 
> > +   result = sony_nc_tablet_mode_setup(pf_device, handle);
> > +   if (result)
> > +   pr_err("couldn't set up tablet mode support 
> > (%d)\n",

Re: [PATCH 5/6] net/core: support compiling out splice

[Josh Triplett]

[Please don't top-post.]

On Sat, Nov 22, 2014 at 11:50:51PM +0100, Pieter Smith wrote:
> splice exports a structure that is used by skbuf. Mocking out a function is
> straightforward. To my knowledge there is no elegant way of mocking out a
> splice_operations struct. I directly modified the code to prevent linking
> against the struct. Do you know of a better technique to get the same
> result?

No, I don't.  The approach you took seems fine; I'm just saying that you
need to explain the need for it in the commit message.

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

[PATCH v3 3/5] pinctrl: exynos: add exynos5410 SoC specific data

[Andreas Färber]

From: Hakjoo Kim 

Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
support for all platforms based on EXYNOS5410.

Signed-off-by: Hakjoo Kim 
[AF: Rebased onto Exynos5260 and irq_chip consolidation]
Signed-off-by: Andreas Färber 
---
 v2 -> v3:
 * Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)
 
 v1 -> v2:
 * Filled in Sob from Hakjoo Kim
 
 .../bindings/pinctrl/samsung-pinctrl.txt   |   1 +
 drivers/pinctrl/samsung/pinctrl-exynos.c   | 107 +
 drivers/pinctrl/samsung/pinctrl-samsung.c  |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h  |   1 +
 4 files changed, 111 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index e82aaf492517..b87a176e730e 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -17,6 +17,7 @@ Required Properties:
   - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
   - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
   - "samsung,exynos5260-pinctrl": for Exynos5260 compatible pin-controller.
+  - "samsung,exynos5410-pinctrl": for Exynos5410 compatible pin-controller.
   - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller.
 
 - reg: Base address of the pin controller hardware module and length of
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d7154ed0b0eb..0580399a6587 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1084,6 +1084,113 @@ struct samsung_pin_ctrl exynos5260_pin_ctrl[] = {
},
 };
 
+/* pin banks of exynos5410 pin-controller 0 */
+static struct samsung_pin_bank exynos5410_pin_banks0[] = {
+   EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
+   EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04),
+   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpa2", 0x08),
+   EXYNOS_PIN_BANK_EINTG(5, 0x060, "gpb0", 0x0c),
+   EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpb1", 0x10),
+   EXYNOS_PIN_BANK_EINTG(4, 0x0A0, "gpb2", 0x14),
+   EXYNOS_PIN_BANK_EINTG(4, 0x0C0, "gpb3", 0x18),
+   EXYNOS_PIN_BANK_EINTG(7, 0x0E0, "gpc0", 0x1c),
+   EXYNOS_PIN_BANK_EINTG(4, 0x100, "gpc3", 0x20),
+   EXYNOS_PIN_BANK_EINTG(7, 0x120, "gpc1", 0x24),
+   EXYNOS_PIN_BANK_EINTG(7, 0x140, "gpc2", 0x28),
+   EXYNOS_PIN_BANK_EINTN(2, 0x160, "gpm5"),
+   EXYNOS_PIN_BANK_EINTG(8, 0x180, "gpd1", 0x2c),
+   EXYNOS_PIN_BANK_EINTG(8, 0x1A0, "gpe0", 0x30),
+   EXYNOS_PIN_BANK_EINTG(2, 0x1C0, "gpe1", 0x34),
+   EXYNOS_PIN_BANK_EINTG(6, 0x1E0, "gpf0", 0x38),
+   EXYNOS_PIN_BANK_EINTG(8, 0x200, "gpf1", 0x3c),
+   EXYNOS_PIN_BANK_EINTG(8, 0x220, "gpg0", 0x40),
+   EXYNOS_PIN_BANK_EINTG(8, 0x240, "gpg1", 0x44),
+   EXYNOS_PIN_BANK_EINTG(2, 0x260, "gpg2", 0x48),
+   EXYNOS_PIN_BANK_EINTG(4, 0x280, "gph0", 0x4c),
+   EXYNOS_PIN_BANK_EINTG(8, 0x2A0, "gph1", 0x50),
+   EXYNOS_PIN_BANK_EINTN(8, 0x2C0, "gpm7"),
+   EXYNOS_PIN_BANK_EINTN(6, 0x2E0, "gpy0"),
+   EXYNOS_PIN_BANK_EINTN(4, 0x300, "gpy1"),
+   EXYNOS_PIN_BANK_EINTN(6, 0x320, "gpy2"),
+   EXYNOS_PIN_BANK_EINTN(8, 0x340, "gpy3"),
+   EXYNOS_PIN_BANK_EINTN(8, 0x360, "gpy4"),
+   EXYNOS_PIN_BANK_EINTN(8, 0x380, "gpy5"),
+   EXYNOS_PIN_BANK_EINTN(8, 0x3A0, "gpy6"),
+   EXYNOS_PIN_BANK_EINTN(8, 0x3C0, "gpy7"),
+   EXYNOS_PIN_BANK_EINTW(8, 0xC00, "gpx0", 0x00),
+   EXYNOS_PIN_BANK_EINTW(8, 0xC20, "gpx1", 0x04),
+   EXYNOS_PIN_BANK_EINTW(8, 0xC40, "gpx2", 0x08),
+   EXYNOS_PIN_BANK_EINTW(8, 0xC60, "gpx3", 0x0c),
+};
+
+/* pin banks of exynos5410 pin-controller 1 */
+static struct samsung_pin_bank exynos5410_pin_banks1[] = {
+   EXYNOS_PIN_BANK_EINTG(5, 0x000, "gpj0", 0x00),
+   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpj1", 0x04),
+   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpj2", 0x08),
+   EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpj3", 0x0c),
+   EXYNOS_PIN_BANK_EINTG(2, 0x080, "gpj4", 0x10),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0A0, "gpk0", 0x14),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0C0, "gpk1", 0x18),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0E0, "gpk2", 0x1c),
+   EXYNOS_PIN_BANK_EINTG(7, 0x100, "gpk3", 0x20),
+};
+
+/* pin banks of exynos5410 pin-controller 2 */
+static struct samsung_pin_bank exynos5410_pin_banks2[] = {
+   EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpv0", 0x00),
+   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpv1", 0x04),
+   EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpv2", 0x08),
+   EXYNOS_PIN_BANK_EINTG(8, 0x080, "gpv3", 0x0c),
+   EXYNOS_PIN_BANK_EINTG(2, 0x0C0, "gpv4", 0x10),
+};
+
+/* pin banks of exynos5410 pin-controller 3 */
+static struct samsung_pin_bank exynos5410_pin_banks3[] = {
+   EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),
+};
+
+/*
+ * Samsung pinctrl driver data for Exynos5410 

crypto: user - crypto_alg_match removal

[Stephan Mueller]

Hi Steffen, Herbert,

may I ask for the reasons why crypto_alg_match exists? Doesn't it 
implement crypto_alg_lookup -- and that not even complete? Is there a 
particular reason why this exact flag of crypto_alg_match is really 
needed in the context of crypto_user?

Unless there is such valid reason, may I ask whether we can remove 
crypto_alg_match and simply use crypto_alg_lookup in all instances where 
crypto_alg_match is invoked using the following replacement:

alg = crypto_alg_lookup(p->cru_name, p->cru_type, p->cru_mask)

The only problem with this replacement is that p->cru_driver_name is not 
considered with that. Do you think a double invocation of 
crypto_alg_lookup should be done or that even the user space interface 
should be changed such that cru_driver_name is removed from it?

Note, this change would now imply that crypto_user follows the kernel-
internal crypto API invocation approach.

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

Re: [DRBD-user] FIX MEs for spinlocks in drbd_worker.c

[Lars Ellenberg]

On Thu, Nov 20, 2014 at 05:37:19PM -0500, nick wrote:
> Greetings Lars,
> I am wondering about removing the spin locks around the linked list
> operators in worker.c or do we need to test it first it first on
> actual hardware.
> Cheers Nick

Unless you have deep insight in the inner workings of DRBD
and their interactions, I'd strongly recommend to go find
some other fixmes.

That is much more complicated than just removing those lines and hope
for the best. Otherwise they would not be there (and not FIXME tag to
find them).

Maybe you just want to reverse-sort your grep for fixmes,
so that the bottom of the list gets some love, too.

Thanks,
Lars

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] fs/splice: full support for compiling out splice

[Josh Triplett]

On Sat, Nov 22, 2014 at 10:00:01PM +0100, Pieter Smith wrote:
> Entirely compile out splice translation unit when the system is configured
> without splice family of syscalls (i.e. CONFIG_SYSCALL_SPLICE is undefined).
> 
> add/remove: 0/25 grow/shrink: 0/5 up/down: 0/-4845 (-4845)

Very nice!

- Josh Triplett

> function old new   delta
> pipe_to_null   4   -  -4
> generic_pipe_buf_nosteal   6   -  -6
> spd_release_page  10   - -10
> PageUptodate  22  11 -11
> lock_page 36  24 -12
> page_cache_pipe_buf_release   16   - -16
> splice_write_null 24   4 -20
> page_cache_pipe_buf_ops   20   - -20
> nosteal_pipe_buf_ops  20   - -20
> default_pipe_buf_ops  20   - -20
> generic_splice_sendpage   24   - -24
> splice_shrink_spd 27   - -27
> direct_splice_actor   47   - -47
> default_file_splice_write 49   - -49
> wakeup_pipe_writers   54   - -54
> write_pipe_buf71   - -71
> page_cache_pipe_buf_confirm   80   - -80
> splice_grow_spd   87   - -87
> splice_from_pipe  93   - -93
> splice_from_pipe_next106   --106
> pipe_to_sendpage 109   --109
> page_cache_pipe_buf_steal114   --114
> generic_file_splice_read 131   8-123
> do_splice_direct 148   --148
> __splice_from_pipe   246   --246
> splice_direct_to_actor   416   --416
> splice_to_pipe   417   --417
> default_file_splice_read 688   --688
> iter_file_splice_write   702   4-698
> __generic_file_splice_read  1109   -   -1109
> 
> Signed-off-by: Pieter Smith 
> ---
>  fs/Makefile|  3 ++-
>  fs/splice.c|  2 --
>  include/linux/fs.h | 26 ++
>  include/linux/splice.h | 43 +++
>  4 files changed, 71 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/Makefile b/fs/Makefile
> index fb7646e..9395622 100644
> --- a/fs/Makefile
> +++ b/fs/Makefile
> @@ -10,7 +10,7 @@ obj-y :=open.o read_write.o file_table.o super.o \
>   ioctl.o readdir.o select.o dcache.o inode.o \
>   attr.o bad_inode.o file.o filesystems.o namespace.o \
>   seq_file.o xattr.o libfs.o fs-writeback.o \
> - pnode.o splice.o sync.o utimes.o \
> + pnode.o sync.o utimes.o \
>   stack.o fs_struct.o statfs.o fs_pin.o
>  
>  ifeq ($(CONFIG_BLOCK),y)
> @@ -22,6 +22,7 @@ endif
>  obj-$(CONFIG_PROC_FS) += proc_namespace.o
>  
>  obj-$(CONFIG_FSNOTIFY)   += notify/
> +obj-$(CONFIG_SYSCALL_SPLICE) += splice.o
>  obj-$(CONFIG_EPOLL)  += eventpoll.o
>  obj-$(CONFIG_ANON_INODES)+= anon_inodes.o
>  obj-$(CONFIG_SIGNALFD)   += signalfd.o
> diff --git a/fs/splice.c b/fs/splice.c
> index 7c4c695..44b201b 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -1316,7 +1316,6 @@ long do_splice_direct(struct file *in, loff_t *ppos, 
> struct file *out,
>   return ret;
>  }
>  
> -#ifdef CONFIG_SYSCALL_SPLICE
>  static int splice_pipe_to_pipe(struct pipe_inode_info *ipipe,
>  struct pipe_inode_info *opipe,
>  size_t len, unsigned int flags);
> @@ -2201,5 +2200,4 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, 
> in_fd,
>   return do_sendfile(out_fd, in_fd, NULL, count, 0);
>  }
>  #endif
> -#endif
>  
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 04c0975..9b3054e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2449,6 +2449,7 @@ extern void block_sync_page(struct page *page);
>  #define __splice_p(x) NULL
>  #endif
>  
> +#ifdef CONFIG_SYSCALL_SPLICE
>  /* fs/splice.c */
>  extern ssize_t generic_file_splice_read(struct file *, loff_t *,
>   struct pipe_inode_info *, size_t, unsigned int);
> @@ -2458,6 +2459,31 @@ extern ssize_t iter_file_splice_write(struct 
> pipe_inode_info *,
>   struct file *, loff_t *, size_t, unsigned int);
>  extern ssize_t generic_splice_sendpage(struct pipe_inode_info *pipe,
>   struct file *out, loff_t *, size_t len, unsigned int flags);
> +#else
> +static inline ssize_t 

Re: [ftrace/x86/extable] WARNING: CPU: 0 PID: 1 at init/main.c:803 do_one_initcall()

[Steven Rostedt]

On Sat, 22 Nov 2014 11:59:26 -0800
Fengguang Wu  wrote:

>
> > Is it possible for your tests to see if a branch was rebased before
> > posting bug reports to LKML? This gave me a scare that my new code had
> > the same brain fart in it.
> 
> Sure and good idea! I'll implement it right now.
> 

It should also make sure that the rebase does not include the offending
commit before not sending out the email. A rebase alone may still have
the bug.

And if you really want to be fancy, you can check to see if the code
itself changed. The attached script takes two git releases (SHA1s,
tags, etc) or one git release and uses HEAD, and finds where the two
are different. Not just by commit id, but also by code. I use this
because I'll modify a branch to add an acked-by and not change the code,
but still want to know the last commit that I tested. It may not have
the same commit id.


-- Steve


git-find-last-same
Description: Binary data

Re: [PATCH 3/6] fs/splice: support compiling out splice-family syscalls

[Josh Triplett]

On Sat, Nov 22, 2014 at 09:59:58PM +0100, Pieter Smith wrote:
> Many embedded systems will not need the splice-family syscalls (splice,
> vmsplice, tee and sendfile). Omitting them saves space.  This adds a new 
> EXPERT
> config option CONFIG_SYSCALL_SPLICE (default y) to support compiling them out.
> 
> This patch removes almost all callers of .splice_read() and .splice_write()
> in the file_operations struct. This paves the way to eventually compile out 
> the
> .splice_read and .splice_write members of the file_operations struct as well 
> as
> the remaining splice-related infrastructure.

This commit message doesn't reflect the new approach of leaving those
members in the structure.

The patch looks good otherwise.

- Josh Triplett

> add/remove: 0/16 grow/shrink: 2/5 up/down: 114/-3693 (-3579)
> function old new   delta
> splice_direct_to_actor   348 416 +68
> splice_to_pipe   371 417 +46
> splice_from_pipe_next107 106  -1
> fdput 11   - -11
> signal_pending39  26 -13
> fdget 56  42 -14
> user_page_pipe_buf_ops20   - -20
> user_page_pipe_buf_steal  25   - -25
> file_end_write58  29 -29
> file_start_write  68  34 -34
> pipe_to_user  43   - -43
> wakeup_pipe_readers   54   - -54
> do_splice_to  87   - -87
> ipipe_prep.part   92   - -92
> opipe_prep.part  119   --119
> sys_sendfile 122   --122
> sys_sendfile64   126   --126
> sys_vmsplice 137   --137
> vmsplice_to_user 205   --205
> sys_tee  491   --491
> do_sendfile  492   --492
> vmsplice_to_pipe 558   --558
> sys_splice  1020   -   -1020
> 
> Signed-off-by: Pieter Smith 
> ---
>  fs/splice.c |  2 ++
>  init/Kconfig| 10 ++
>  kernel/sys_ni.c |  8 
>  3 files changed, 20 insertions(+)
> 
> diff --git a/fs/splice.c b/fs/splice.c
> index 44b201b..7c4c695 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -1316,6 +1316,7 @@ long do_splice_direct(struct file *in, loff_t *ppos, 
> struct file *out,
>   return ret;
>  }
>  
> +#ifdef CONFIG_SYSCALL_SPLICE
>  static int splice_pipe_to_pipe(struct pipe_inode_info *ipipe,
>  struct pipe_inode_info *opipe,
>  size_t len, unsigned int flags);
> @@ -2200,4 +2201,5 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, 
> in_fd,
>   return do_sendfile(out_fd, in_fd, NULL, count, 0);
>  }
>  #endif
> +#endif
>  
> diff --git a/init/Kconfig b/init/Kconfig
> index d811d5f..dec9819 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1571,6 +1571,16 @@ config NTP
> system clock to an NTP server, you can disable this option to save
> space.
>  
> +config SYSCALL_SPLICE
> + bool "Enable splice/vmsplice/tee/sendfile syscalls" if EXPERT
> + default y
> + help
> +   This option enables the splice, vmsplice, tee and sendfile syscalls. 
> These
> +   are used by applications to: move data between buffers and arbitrary 
> file
> +   descriptors; "copy" data between buffers; or copy data from userspace 
> into
> +   buffers. If building an embedded system where no applications use 
> these
> +   syscalls, you can disable this option to save space.
> +
>  config PCI_QUIRKS
>   default y
>   bool "Enable PCI quirk workarounds" if EXPERT
> diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
> index d2f5b00..25d5551 100644
> --- a/kernel/sys_ni.c
> +++ b/kernel/sys_ni.c
> @@ -170,6 +170,14 @@ cond_syscall(sys_fstat);
>  cond_syscall(sys_stat);
>  cond_syscall(sys_uname);
>  cond_syscall(sys_olduname);
> +cond_syscall(sys_vmsplice);
> +cond_syscall(sys_splice);
> +cond_syscall(sys_tee);
> +cond_syscall(sys_sendfile);
> +cond_syscall(sys_sendfile64);
> +cond_syscall(compat_sys_vmsplice);
> +cond_syscall(compat_sys_sendfile);
> +cond_syscall(compat_sys_sendfile64);
>  
>  /* arch-specific weak syscall entries */
>  cond_syscall(sys_pciconfig_read);
> -- 
> 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 5/6] net/core: support compiling out splice

[Josh Triplett]

On Sat, Nov 22, 2014 at 10:00:00PM +0100, Pieter Smith wrote:
> Compile out splice support from networking core when the splice-family of
> syscalls is not supported by the system (i.e. CONFIG_SYSCALL_SPLICE is
> undefined).

Please explain in the commit message why this particular bit of splice
support needs compiling out when most other bits do not.

Also, a couple of style comments below.

> Signed-off-by: Pieter Smith 
> ---
>  include/linux/skbuff.h | 9 +
>  net/core/skbuff.c  | 9 ++---
>  2 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index a59d934..8c28524 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -2640,9 +2640,18 @@ int skb_copy_bits(const struct sk_buff *skb, int 
> offset, void *to, int len);
>  int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int 
> len);
>  __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to,
> int len, __wsum csum);
> +#ifdef CONFIG_SYSCALL_SPLICE
>  int skb_splice_bits(struct sk_buff *skb, unsigned int offset,
>   struct pipe_inode_info *pipe, unsigned int len,
>   unsigned int flags);
> +#else /* #ifdef CONFIG_SYSCALL_SPLICE */
> +static inline int skb_splice_bits(struct sk_buff *skb, unsigned int offset,
> + struct pipe_inode_info *pipe, unsigned int len,
> + unsigned int flags)
> +{
> + return -EPERM;
> +}
> +#endif /* #ifdef CONFIG_SYSCALL_SPLICE */

These comments, and the one added below in the corresponding .c file,
don't match the prevailing style.  These are so short (fitting on one
screen) that they hardly seem worth the comments at all, but if you want
to include them, s/#ifdef// in the comment.

>  void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to);
>  unsigned int skb_zerocopy_headlen(const struct sk_buff *from);
>  int skb_zerocopy(struct sk_buff *to, struct sk_buff *from,
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 61059a0..74fad8a 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -1781,9 +1781,9 @@ static bool __splice_segment(struct page *page, 
> unsigned int poff,
>   * Map linear and fragment data from the skb to spd. It reports true if the
>   * pipe is full or if we already spliced the requested length.
>   */
> -static bool __skb_splice_bits(struct sk_buff *skb, struct pipe_inode_info 
> *pipe,
> -   unsigned int *offset, unsigned int *len,
> -   struct splice_pipe_desc *spd, struct sock *sk)
> +static bool __maybe_unused __skb_splice_bits(struct sk_buff *skb, struct 
> pipe_inode_info *pipe,
> +  unsigned int *offset, unsigned int 
> *len,
> +  struct splice_pipe_desc *spd, 
> struct sock *sk)
>  {
>   int seg;
>  
> @@ -1821,6 +1821,7 @@ static bool __skb_splice_bits(struct sk_buff *skb, 
> struct pipe_inode_info *pipe,
>   * the frag list, if such a thing exists. We'd probably need to recurse to
>   * handle that cleanly.
>   */
> +#ifdef CONFIG_SYSCALL_SPLICE
>  int skb_splice_bits(struct sk_buff *skb, unsigned int offset,
>   struct pipe_inode_info *pipe, unsigned int tlen,
>   unsigned int flags)
> @@ -1876,6 +1877,8 @@ done:
>  
>   return ret;
>  }
> +#endif /* #ifdef CONFIG_SYSCALL_SPLICE */
> +

This extra blank line shouldn't be here.

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

Re: [PATCH v2 3/5] pinctrl: exynos: add exynos5410 SoC specific data

[Andreas Färber]

Am 22.11.2014 um 21:26 schrieb Andreas Färber:
> From: Hakjoo Kim 
> 
> Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
> support for all platforms based on EXYNOS5410.
> 
> Signed-off-by: Hakjoo Kim 
> [AF: Rebased onto Exynos5260]
> Signed-off-by: Andreas Färber 
> ---
> v1 -> v2:
> * Filled in Sob from Hakjoo Kim
> * Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)

Ugh, this patch is actually missing exactly this change! Stay tuned...

Andreas

-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] fs/fuse: support compiling out splice

[Josh Triplett]

On Sat, Nov 22, 2014 at 09:59:59PM +0100, Pieter Smith wrote:
> Compile out splice support from fuse when the splice-family of syscalls is not
> supported by the system (i.e. CONFIG_SYSCALL_SPLICE is undefined).

This patch needs some additional explanation.  Could you explain in the
commit message why this particular splice_read function (and only the
splice_read function, not the splice_write function) needs compiling
out, when others do not?

- Josh Triplett

> Signed-off-by: Pieter Smith 
> ---
>  fs/fuse/dev.c  | 4 ++--
>  include/linux/fs.h | 6 ++
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index ca88731..f8f92a4 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -1291,7 +1291,7 @@ static ssize_t fuse_dev_read(struct kiocb *iocb, const 
> struct iovec *iov,
>   return fuse_dev_do_read(fc, file, , iov_length(iov, nr_segs));
>  }
>  
> -static ssize_t fuse_dev_splice_read(struct file *in, loff_t *ppos,
> +static ssize_t __maybe_unused fuse_dev_splice_read(struct file *in, loff_t 
> *ppos,
>   struct pipe_inode_info *pipe,
>   size_t len, unsigned int flags)
>  {
> @@ -2144,7 +2144,7 @@ const struct file_operations fuse_dev_operations = {
>   .llseek = no_llseek,
>   .read   = do_sync_read,
>   .aio_read   = fuse_dev_read,
> - .splice_read= fuse_dev_splice_read,
> + .splice_read= __splice_p(fuse_dev_splice_read),
>   .write  = do_sync_write,
>   .aio_write  = fuse_dev_write,
>   .splice_write   = fuse_dev_splice_write,
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index a957d43..04c0975 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2443,6 +2443,12 @@ extern int blkdev_fsync(struct file *filp, loff_t 
> start, loff_t end,
>   int datasync);
>  extern void block_sync_page(struct page *page);
>  
> +#ifdef CONFIG_SYSCALL_SPLICE
> +#define __splice_p(x) x
> +#else
> +#define __splice_p(x) NULL
> +#endif
> +
>  /* fs/splice.c */
>  extern ssize_t generic_file_splice_read(struct file *, loff_t *,
>   struct pipe_inode_info *, size_t, unsigned int);
> -- 
> 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] i2c: omap: fix i207 errata handling

[Wolfram Sang]

> Guys, I really appreciate you help.
> So much testing and review.
> I could not have done one.
> Thank you!

Well, thank YOU, for your hard work in verifying this controller at
low-level and in corner-cases. This is very much appreciated. Plus, you
have been very responsive to comments. Really good work! Hope you'll be
around for more :)



signature.asc
Description: Digital signature

Re: [PATCH 1/1] [IA64] Deletion of unnecessary checks before the function call "unw_remove_unwind_table"

[Dan Carpenter]

This one is buggy.

regards,
dan carpenter

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

Re: [PATCH] i2c: omap: fix i207 errata handling

[Wolfram Sang]

On Fri, Nov 21, 2014 at 04:16:51AM +0400, Alexander Kochetkov wrote:
> commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR
> and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
> Set) get handled. 6d9939f6514 code doesn't correspond to workaround provided 
> by
> errata.
> 
> According to errata ISR must filter out spurious RDR before data read not 
> after.
> ISR must read RXSTAT to get number of bytes available to read. Because RDR
> could be set while there could no data in the receive FIFO.
> 
> Restored pre 6d9939f6514 way of handling errata.
> 
> Found by code review. Real impact haven't seen.
> Tested on Beagleboard XM C.
> 
> Signed-off-by: Alexander Kochetkov 
> Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY

Applied to for-current, thanks!



signature.asc
Description: Digital signature

Re: [PATCH v3 0/4] i2c: omap: patch series related to multimaster mode

[Wolfram Sang]

On Sat, Nov 22, 2014 at 11:47:10PM +0400, Alexander Kochetkov wrote:
> Here is the patch series intended to improve stability of
> i2c-omap driver in the i2c multimaster environments.
> 
> Tested on Beagleboard XM C.
> For now all fine. No controller timeouts, no data corruptions.
> 
> Also impelemented i2c bus fault detection during startup and
> after reset.
> 
> So, instead of the message "controller timeout" blaming IP,
> you get "timeout waiting for bus ready".
> 
> Rebased against i2c/for-next (eb61694b43dea0d43ea2574e7d48f476a6bdffb0)
> 
> Tested on the kernel from angstrom-v2013.06-yocto1.4
> Kernel recepie linux-mainline_3.2.bb
> git://github.com/Angstrom-distribution/meta-ti.git; branch 
> angstrom-staging-yocto1.4
> With all i2-omap.c patches backported from upstream linux/master
> 
> Signed-off-by: Alexander Kochetkov 
> 
> Alexander Kochetkov (4):
>   i2c: omap: cleanup register definitions
>   i2c: omap: implement workaround for handling invalid BB-bit values
>   i2c: omap: don't reset controller if Arbitration Lost detected
>   i2c: omap: add notes related to i2c multimaster mode

All applied to for-next, thanks!



signature.asc
Description: Digital signature

[PATCH 6/6] fs/splice: full support for compiling out splice

[Pieter Smith]

Entirely compile out splice translation unit when the system is configured
without splice family of syscalls (i.e. CONFIG_SYSCALL_SPLICE is undefined).

add/remove: 0/25 grow/shrink: 0/5 up/down: 0/-4845 (-4845)
function old new   delta
pipe_to_null   4   -  -4
generic_pipe_buf_nosteal   6   -  -6
spd_release_page  10   - -10
PageUptodate  22  11 -11
lock_page 36  24 -12
page_cache_pipe_buf_release   16   - -16
splice_write_null 24   4 -20
page_cache_pipe_buf_ops   20   - -20
nosteal_pipe_buf_ops  20   - -20
default_pipe_buf_ops  20   - -20
generic_splice_sendpage   24   - -24
splice_shrink_spd 27   - -27
direct_splice_actor   47   - -47
default_file_splice_write 49   - -49
wakeup_pipe_writers   54   - -54
write_pipe_buf71   - -71
page_cache_pipe_buf_confirm   80   - -80
splice_grow_spd   87   - -87
splice_from_pipe  93   - -93
splice_from_pipe_next106   --106
pipe_to_sendpage 109   --109
page_cache_pipe_buf_steal114   --114
generic_file_splice_read 131   8-123
do_splice_direct 148   --148
__splice_from_pipe   246   --246
splice_direct_to_actor   416   --416
splice_to_pipe   417   --417
default_file_splice_read 688   --688
iter_file_splice_write   702   4-698
__generic_file_splice_read  1109   -   -1109

Signed-off-by: Pieter Smith 
---
 fs/Makefile|  3 ++-
 fs/splice.c|  2 --
 include/linux/fs.h | 26 ++
 include/linux/splice.h | 43 +++
 4 files changed, 71 insertions(+), 3 deletions(-)

diff --git a/fs/Makefile b/fs/Makefile
index fb7646e..9395622 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -10,7 +10,7 @@ obj-y :=  open.o read_write.o file_table.o super.o \
ioctl.o readdir.o select.o dcache.o inode.o \
attr.o bad_inode.o file.o filesystems.o namespace.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
-   pnode.o splice.o sync.o utimes.o \
+   pnode.o sync.o utimes.o \
stack.o fs_struct.o statfs.o fs_pin.o
 
 ifeq ($(CONFIG_BLOCK),y)
@@ -22,6 +22,7 @@ endif
 obj-$(CONFIG_PROC_FS) += proc_namespace.o
 
 obj-$(CONFIG_FSNOTIFY) += notify/
+obj-$(CONFIG_SYSCALL_SPLICE)   += splice.o
 obj-$(CONFIG_EPOLL)+= eventpoll.o
 obj-$(CONFIG_ANON_INODES)  += anon_inodes.o
 obj-$(CONFIG_SIGNALFD) += signalfd.o
diff --git a/fs/splice.c b/fs/splice.c
index 7c4c695..44b201b 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1316,7 +1316,6 @@ long do_splice_direct(struct file *in, loff_t *ppos, 
struct file *out,
return ret;
 }
 
-#ifdef CONFIG_SYSCALL_SPLICE
 static int splice_pipe_to_pipe(struct pipe_inode_info *ipipe,
   struct pipe_inode_info *opipe,
   size_t len, unsigned int flags);
@@ -2201,5 +2200,4 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, 
in_fd,
return do_sendfile(out_fd, in_fd, NULL, count, 0);
 }
 #endif
-#endif
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 04c0975..9b3054e 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2449,6 +2449,7 @@ extern void block_sync_page(struct page *page);
 #define __splice_p(x) NULL
 #endif
 
+#ifdef CONFIG_SYSCALL_SPLICE
 /* fs/splice.c */
 extern ssize_t generic_file_splice_read(struct file *, loff_t *,
struct pipe_inode_info *, size_t, unsigned int);
@@ -2458,6 +2459,31 @@ extern ssize_t iter_file_splice_write(struct 
pipe_inode_info *,
struct file *, loff_t *, size_t, unsigned int);
 extern ssize_t generic_splice_sendpage(struct pipe_inode_info *pipe,
struct file *out, loff_t *, size_t len, unsigned int flags);
+#else
+static inline ssize_t generic_file_splice_read(struct file *in, loff_t *ppos,
+   struct pipe_inode_info *pipe, size_t len, unsigned int flags)
+{
+   return -EPERM;
+}
+
+static inline ssize_t default_file_splice_read(struct file *in, loff_t *ppos,
+   struct pipe_inode_info *pipe, 

[PATCH 4/6] fs/fuse: support compiling out splice

[Pieter Smith]

Compile out splice support from fuse when the splice-family of syscalls is not
supported by the system (i.e. CONFIG_SYSCALL_SPLICE is undefined).

Signed-off-by: Pieter Smith 
---
 fs/fuse/dev.c  | 4 ++--
 include/linux/fs.h | 6 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index ca88731..f8f92a4 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -1291,7 +1291,7 @@ static ssize_t fuse_dev_read(struct kiocb *iocb, const 
struct iovec *iov,
return fuse_dev_do_read(fc, file, , iov_length(iov, nr_segs));
 }
 
-static ssize_t fuse_dev_splice_read(struct file *in, loff_t *ppos,
+static ssize_t __maybe_unused fuse_dev_splice_read(struct file *in, loff_t 
*ppos,
struct pipe_inode_info *pipe,
size_t len, unsigned int flags)
 {
@@ -2144,7 +2144,7 @@ const struct file_operations fuse_dev_operations = {
.llseek = no_llseek,
.read   = do_sync_read,
.aio_read   = fuse_dev_read,
-   .splice_read= fuse_dev_splice_read,
+   .splice_read= __splice_p(fuse_dev_splice_read),
.write  = do_sync_write,
.aio_write  = fuse_dev_write,
.splice_write   = fuse_dev_splice_write,
diff --git a/include/linux/fs.h b/include/linux/fs.h
index a957d43..04c0975 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2443,6 +2443,12 @@ extern int blkdev_fsync(struct file *filp, loff_t start, 
loff_t end,
int datasync);
 extern void block_sync_page(struct page *page);
 
+#ifdef CONFIG_SYSCALL_SPLICE
+#define __splice_p(x) x
+#else
+#define __splice_p(x) NULL
+#endif
+
 /* fs/splice.c */
 extern ssize_t generic_file_splice_read(struct file *, loff_t *,
struct pipe_inode_info *, size_t, unsigned int);
-- 
1.9.1

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

[PATCH 5/6] net/core: support compiling out splice

[Pieter Smith]

Compile out splice support from networking core when the splice-family of
syscalls is not supported by the system (i.e. CONFIG_SYSCALL_SPLICE is
undefined).

Signed-off-by: Pieter Smith 
---
 include/linux/skbuff.h | 9 +
 net/core/skbuff.c  | 9 ++---
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a59d934..8c28524 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2640,9 +2640,18 @@ int skb_copy_bits(const struct sk_buff *skb, int offset, 
void *to, int len);
 int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len);
 __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to,
  int len, __wsum csum);
+#ifdef CONFIG_SYSCALL_SPLICE
 int skb_splice_bits(struct sk_buff *skb, unsigned int offset,
struct pipe_inode_info *pipe, unsigned int len,
unsigned int flags);
+#else /* #ifdef CONFIG_SYSCALL_SPLICE */
+static inline int skb_splice_bits(struct sk_buff *skb, unsigned int offset,
+   struct pipe_inode_info *pipe, unsigned int len,
+   unsigned int flags)
+{
+   return -EPERM;
+}
+#endif /* #ifdef CONFIG_SYSCALL_SPLICE */
 void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to);
 unsigned int skb_zerocopy_headlen(const struct sk_buff *from);
 int skb_zerocopy(struct sk_buff *to, struct sk_buff *from,
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 61059a0..74fad8a 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1781,9 +1781,9 @@ static bool __splice_segment(struct page *page, unsigned 
int poff,
  * Map linear and fragment data from the skb to spd. It reports true if the
  * pipe is full or if we already spliced the requested length.
  */
-static bool __skb_splice_bits(struct sk_buff *skb, struct pipe_inode_info 
*pipe,
- unsigned int *offset, unsigned int *len,
- struct splice_pipe_desc *spd, struct sock *sk)
+static bool __maybe_unused __skb_splice_bits(struct sk_buff *skb, struct 
pipe_inode_info *pipe,
+unsigned int *offset, unsigned int 
*len,
+struct splice_pipe_desc *spd, 
struct sock *sk)
 {
int seg;
 
@@ -1821,6 +1821,7 @@ static bool __skb_splice_bits(struct sk_buff *skb, struct 
pipe_inode_info *pipe,
  * the frag list, if such a thing exists. We'd probably need to recurse to
  * handle that cleanly.
  */
+#ifdef CONFIG_SYSCALL_SPLICE
 int skb_splice_bits(struct sk_buff *skb, unsigned int offset,
struct pipe_inode_info *pipe, unsigned int tlen,
unsigned int flags)
@@ -1876,6 +1877,8 @@ done:
 
return ret;
 }
+#endif /* #ifdef CONFIG_SYSCALL_SPLICE */
+
 
 /**
  * skb_store_bits - store bits from kernel buffer to skb
-- 
1.9.1

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

[PATCH 2/6] fs: moved kernel_write to fs/read_write

[Pieter Smith]

kernel_write shares infrastructure with the read_write translation unit but not
with the splice translation unit. Grouping kernel_write with the read_write
translation unit is more logical. It also paves the way to compiling out the
splice group of syscalls for embedded systems that do not need them.

Signed-off-by: Pieter Smith 
---
 fs/read_write.c | 16 
 fs/splice.c | 16 
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/fs/read_write.c b/fs/read_write.c
index d9451ba..f4c8d8b 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1191,3 +1191,19 @@ COMPAT_SYSCALL_DEFINE5(pwritev, compat_ulong_t, fd,
 }
 #endif
 
+ssize_t kernel_write(struct file *file, const char *buf, size_t count,
+   loff_t pos)
+{
+   mm_segment_t old_fs;
+   ssize_t res;
+
+   old_fs = get_fs();
+   set_fs(get_ds());
+   /* The cast to a user pointer is valid due to the set_fs() */
+   res = vfs_write(file, (__force const char __user *)buf, count, );
+   set_fs(old_fs);
+
+   return res;
+}
+EXPORT_SYMBOL(kernel_write);
+
diff --git a/fs/splice.c b/fs/splice.c
index c1a2861..44b201b 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -583,22 +583,6 @@ static ssize_t kernel_readv(struct file *file, const 
struct iovec *vec,
return res;
 }
 
-ssize_t kernel_write(struct file *file, const char *buf, size_t count,
-   loff_t pos)
-{
-   mm_segment_t old_fs;
-   ssize_t res;
-
-   old_fs = get_fs();
-   set_fs(get_ds());
-   /* The cast to a user pointer is valid due to the set_fs() */
-   res = vfs_write(file, (__force const char __user *)buf, count, );
-   set_fs(old_fs);
-
-   return res;
-}
-EXPORT_SYMBOL(kernel_write);
-
 ssize_t default_file_splice_read(struct file *in, loff_t *ppos,
 struct pipe_inode_info *pipe, size_t len,
 unsigned int flags)
-- 
1.9.1

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

[PATCH 3/6] fs/splice: support compiling out splice-family syscalls

[Pieter Smith]

Many embedded systems will not need the splice-family syscalls (splice,
vmsplice, tee and sendfile). Omitting them saves space.  This adds a new EXPERT
config option CONFIG_SYSCALL_SPLICE (default y) to support compiling them out.

This patch removes almost all callers of .splice_read() and .splice_write()
in the file_operations struct. This paves the way to eventually compile out the
.splice_read and .splice_write members of the file_operations struct as well as
the remaining splice-related infrastructure.

add/remove: 0/16 grow/shrink: 2/5 up/down: 114/-3693 (-3579)
function old new   delta
splice_direct_to_actor   348 416 +68
splice_to_pipe   371 417 +46
splice_from_pipe_next107 106  -1
fdput 11   - -11
signal_pending39  26 -13
fdget 56  42 -14
user_page_pipe_buf_ops20   - -20
user_page_pipe_buf_steal  25   - -25
file_end_write58  29 -29
file_start_write  68  34 -34
pipe_to_user  43   - -43
wakeup_pipe_readers   54   - -54
do_splice_to  87   - -87
ipipe_prep.part   92   - -92
opipe_prep.part  119   --119
sys_sendfile 122   --122
sys_sendfile64   126   --126
sys_vmsplice 137   --137
vmsplice_to_user 205   --205
sys_tee  491   --491
do_sendfile  492   --492
vmsplice_to_pipe 558   --558
sys_splice  1020   -   -1020

Signed-off-by: Pieter Smith 
---
 fs/splice.c |  2 ++
 init/Kconfig| 10 ++
 kernel/sys_ni.c |  8 
 3 files changed, 20 insertions(+)

diff --git a/fs/splice.c b/fs/splice.c
index 44b201b..7c4c695 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1316,6 +1316,7 @@ long do_splice_direct(struct file *in, loff_t *ppos, 
struct file *out,
return ret;
 }
 
+#ifdef CONFIG_SYSCALL_SPLICE
 static int splice_pipe_to_pipe(struct pipe_inode_info *ipipe,
   struct pipe_inode_info *opipe,
   size_t len, unsigned int flags);
@@ -2200,4 +2201,5 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, 
in_fd,
return do_sendfile(out_fd, in_fd, NULL, count, 0);
 }
 #endif
+#endif
 
diff --git a/init/Kconfig b/init/Kconfig
index d811d5f..dec9819 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1571,6 +1571,16 @@ config NTP
  system clock to an NTP server, you can disable this option to save
  space.
 
+config SYSCALL_SPLICE
+   bool "Enable splice/vmsplice/tee/sendfile syscalls" if EXPERT
+   default y
+   help
+ This option enables the splice, vmsplice, tee and sendfile syscalls. 
These
+ are used by applications to: move data between buffers and arbitrary 
file
+ descriptors; "copy" data between buffers; or copy data from userspace 
into
+ buffers. If building an embedded system where no applications use 
these
+ syscalls, you can disable this option to save space.
+
 config PCI_QUIRKS
default y
bool "Enable PCI quirk workarounds" if EXPERT
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index d2f5b00..25d5551 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -170,6 +170,14 @@ cond_syscall(sys_fstat);
 cond_syscall(sys_stat);
 cond_syscall(sys_uname);
 cond_syscall(sys_olduname);
+cond_syscall(sys_vmsplice);
+cond_syscall(sys_splice);
+cond_syscall(sys_tee);
+cond_syscall(sys_sendfile);
+cond_syscall(sys_sendfile64);
+cond_syscall(compat_sys_vmsplice);
+cond_syscall(compat_sys_sendfile);
+cond_syscall(compat_sys_sendfile64);
 
 /* arch-specific weak syscall entries */
 cond_syscall(sys_pciconfig_read);
-- 
1.9.1

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

[PATCH 1/6] fs: move sendfile syscall into fs/splice

[Pieter Smith]

sendfile functionally forms part of the splice group of syscalls (splice,
vmsplice and tee). Grouping sendfile with splice paves the way to compiling out
the splice group of syscalls for embedded systems that do not need these.

add/remove: 0/0 grow/shrink: 7/2 up/down: 86/-61 (25)
function old new   delta
file_start_write  34  68 +34
file_end_write29  58 +29
sys_pwritev  115 122  +7
sys_preadv   115 122  +7
fdput_pos 29  36  +7
sys_pwrite64 115 116  +1
sys_pread64  115 116  +1
sys_tee  497 491  -6
sys_splice  10751020 -55

Signed-off-by: Pieter Smith 
---
 fs/read_write.c | 175 ---
 fs/splice.c | 178 
 2 files changed, 178 insertions(+), 175 deletions(-)

diff --git a/fs/read_write.c b/fs/read_write.c
index 7d9318c..d9451ba 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1191,178 +1191,3 @@ COMPAT_SYSCALL_DEFINE5(pwritev, compat_ulong_t, fd,
 }
 #endif
 
-static ssize_t do_sendfile(int out_fd, int in_fd, loff_t *ppos,
-  size_t count, loff_t max)
-{
-   struct fd in, out;
-   struct inode *in_inode, *out_inode;
-   loff_t pos;
-   loff_t out_pos;
-   ssize_t retval;
-   int fl;
-
-   /*
-* Get input file, and verify that it is ok..
-*/
-   retval = -EBADF;
-   in = fdget(in_fd);
-   if (!in.file)
-   goto out;
-   if (!(in.file->f_mode & FMODE_READ))
-   goto fput_in;
-   retval = -ESPIPE;
-   if (!ppos) {
-   pos = in.file->f_pos;
-   } else {
-   pos = *ppos;
-   if (!(in.file->f_mode & FMODE_PREAD))
-   goto fput_in;
-   }
-   retval = rw_verify_area(READ, in.file, , count);
-   if (retval < 0)
-   goto fput_in;
-   count = retval;
-
-   /*
-* Get output file, and verify that it is ok..
-*/
-   retval = -EBADF;
-   out = fdget(out_fd);
-   if (!out.file)
-   goto fput_in;
-   if (!(out.file->f_mode & FMODE_WRITE))
-   goto fput_out;
-   retval = -EINVAL;
-   in_inode = file_inode(in.file);
-   out_inode = file_inode(out.file);
-   out_pos = out.file->f_pos;
-   retval = rw_verify_area(WRITE, out.file, _pos, count);
-   if (retval < 0)
-   goto fput_out;
-   count = retval;
-
-   if (!max)
-   max = min(in_inode->i_sb->s_maxbytes, 
out_inode->i_sb->s_maxbytes);
-
-   if (unlikely(pos + count > max)) {
-   retval = -EOVERFLOW;
-   if (pos >= max)
-   goto fput_out;
-   count = max - pos;
-   }
-
-   fl = 0;
-#if 0
-   /*
-* We need to debate whether we can enable this or not. The
-* man page documents EAGAIN return for the output at least,
-* and the application is arguably buggy if it doesn't expect
-* EAGAIN on a non-blocking file descriptor.
-*/
-   if (in.file->f_flags & O_NONBLOCK)
-   fl = SPLICE_F_NONBLOCK;
-#endif
-   file_start_write(out.file);
-   retval = do_splice_direct(in.file, , out.file, _pos, count, fl);
-   file_end_write(out.file);
-
-   if (retval > 0) {
-   add_rchar(current, retval);
-   add_wchar(current, retval);
-   fsnotify_access(in.file);
-   fsnotify_modify(out.file);
-   out.file->f_pos = out_pos;
-   if (ppos)
-   *ppos = pos;
-   else
-   in.file->f_pos = pos;
-   }
-
-   inc_syscr(current);
-   inc_syscw(current);
-   if (pos > max)
-   retval = -EOVERFLOW;
-
-fput_out:
-   fdput(out);
-fput_in:
-   fdput(in);
-out:
-   return retval;
-}
-
-SYSCALL_DEFINE4(sendfile, int, out_fd, int, in_fd, off_t __user *, offset, 
size_t, count)
-{
-   loff_t pos;
-   off_t off;
-   ssize_t ret;
-
-   if (offset) {
-   if (unlikely(get_user(off, offset)))
-   return -EFAULT;
-   pos = off;
-   ret = do_sendfile(out_fd, in_fd, , count, MAX_NON_LFS);
-   if (unlikely(put_user(pos, offset)))
-   return -EFAULT;
-   return ret;
-   }
-
-   return do_sendfile(out_fd, in_fd, NULL, count, 0);
-}
-
-SYSCALL_DEFINE4(sendfile64, int, out_fd, int, in_fd, loff_t __user *, offset, 
size_t, count)
-{
-   loff_t pos;
-   ssize_t ret;
-
-   

[PATCH 1/1] scripts: add a graph generator based on checkpatch reports

[Fabian Frederick]

This script generates a graph based on errors/warnings/checks detected
by checkpatch -f recursively on each files of a directory.
Results are grouped by subfolders and pushed in gnuplot datasets.

By default checkstat.png is generated with an histogram.

This script should always be called from kernel source root.
eg scripts/checkstat.pl fs

Cc: Joe Perches 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Signed-off-by: Fabian Frederick 
---
 scripts/checkstat.pl | 120 +++
 1 file changed, 120 insertions(+)
 create mode 100755 scripts/checkstat.pl

diff --git a/scripts/checkstat.pl b/scripts/checkstat.pl
new file mode 100755
index 000..8b7d451
--- /dev/null
+++ b/scripts/checkstat.pl
@@ -0,0 +1,120 @@
+#!/usr/bin/perl
+# (c) 2014, Fabian Frederick (f...@skynet.be)
+#
+# Based on scripts/checkpatch.pl
+#
+# This script generates a graph based on errors/warnings/checks detected
+# by checkpatch -f recursively on each files of a directory.
+# Results are grouped by subfolders.
+#
+
+use strict;
+use Getopt::Long;
+use File::Basename;
+use Chart::Gnuplot;
+
+my $P = $0;
+my $statdir = '.';
+my $files;
+my @cfiles = ();
+my %stat;
+my %stats;
+my $report;
+my $currentdir = '';
+
+my $checkpatch = "scripts/checkpatch.pl";
+my $output = "checkstat.png";
+my @dontcheck = qw/fs\/nls/;
+
+sub help {
+   my $text = << "EOM";
+Usage: $P [OPTION] [DIRECTORY]
+
+This script should always be called from kernel source root.
+
+Options:
+   --outputname of generated png graph.
+EOM
+   my $std=shift;
+   if ($std == 1) {
+   print STDERR $text;
+   } else {
+   print $text;
+   }
+   exit;
+}
+
+GetOptions(
+   'h|help'=> \,
+   'output=s'  => \$output
+);
+
+if ($#ARGV >= 0) {
+   $statdir = @ARGV[0];
+}
+
+my $graphreport = Chart::Gnuplot->new(
+   output => $output,
+   yrange => [0, '*'],
+   imagesize => '3, 2',
+   xtics => {
+   rotate => '90 right',
+   },
+   bmargin => 15,
+   title => 'Linux Kernel: checkstat - Date: `date`'
+);
+
+$files = `find $statdir -name "*.c"`;
+@cfiles = split('\n', $files);
+
+#Execute checkpatch on each file and store results
+foreach my $file (@cfiles) {
+   print "checkpatch: $file: ";
+   $currentdir = dirname($file);
+
+   if (not grep(/^$currentdir$/, @dontcheck)){
+   $report = `$checkpatch -f --terse $file | tail -n 1`;
+
+   if ($currentdir ne $statdir) {
+   $currentdir =~ s/$statdir\///;
+   $currentdir =~ s/\/(.*)//;
+   $currentdir = $statdir."/".$currentdir;
+   }
+   print "adding to ".$currentdir." stats\n";
+   my $i = 0;
+
+   foreach my $stat_type ("errors", "warnings", "checks") {
+   $report =~ m/(\d+)\s$stat_type/;
+   $stat{$currentdir}[$i++] += $1;
+   $stats{$stat_type}{$currentdir} += $1;
+   }
+   } else {
+   print "File in dontcheck list ...\n";
+   }
+}
+
+my @columns=();
+my %colors=(
+   errors => 'red',
+   warnings => 'orange',
+   checks => 'green'
+);
+
+#Reorder and push data in datasets.
+foreach my $stat_type (keys %stats) {
+   my @xdir=();
+
+   foreach my $dir (sort keys %{$stats{$stat_type}}){
+   push @xdir, [$dir, $stats{$stat_type}{$dir}];
+   }
+   push @columns, Chart::Gnuplot::DataSet->new(
+   points => \@xdir,
+   title => $stat_type,
+   color => $colors{$stat_type},
+   fill => {density => 1},
+   style => "histograms",
+   );
+}
+
+$graphreport->plot2d(@columns);
+print("graph generated: $output\n");
-- 
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/

[tip:x86/mpx] asm-generic: Remove asm-generic arch_bprm_mm_init()

[tip-bot for Dave Hansen]

Commit-ID:  9f7789f845cc100dd0d94fa1aa083e3373dc03db
Gitweb: http://git.kernel.org/tip/9f7789f845cc100dd0d94fa1aa083e3373dc03db
Author: Dave Hansen 
AuthorDate: Sat, 22 Nov 2014 08:37:11 -0800
Committer:  Thomas Gleixner 
CommitDate: Sat, 22 Nov 2014 21:52:08 +0100

asm-generic: Remove asm-generic arch_bprm_mm_init()

This is a follow-on to commit 62e88b1c00de 'mm: Make
arch_unmap()/bprm_mm_init() available to all architectures'

I removed the asm-generic version of arch_unmap() in that patch,
but missed arch_bprm_mm_init().  So this broke the build for
architectures using asm-generic/mmu_context.h who actually have
an MMU.

Fixes: 62e88b1c00de 'mm: Make arch_unmap()/bprm_mm_init() available to all 
architectures'
Signed-off-by: Dave Hansen 
Cc: Dave Hansen 
Cc: linux-a...@vger.kernel.org
Cc: x...@kernel.org
Link: http://lkml.kernel.org/r/20141122163711.0f037...@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner 

---
 include/asm-generic/mmu_context.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/include/asm-generic/mmu_context.h 
b/include/asm-generic/mmu_context.h
index 1f2a8f9..a7eec91 100644
--- a/include/asm-generic/mmu_context.h
+++ b/include/asm-generic/mmu_context.h
@@ -42,9 +42,4 @@ static inline void activate_mm(struct mm_struct *prev_mm,
 {
 }
 
-static inline void arch_bprm_mm_init(struct mm_struct *mm,
-   struct vm_area_struct *vma)
-{
-}
-
 #endif /* __ASM_GENERIC_MMU_CONTEXT_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT pull] timer updates for 3.18

[Thomas Gleixner]

Linus,

please pull the latest timers-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
timers-urgent-for-linus

A single bugfix for an init order problem in the sun4i subarch
clockevents code.

Thanks,

tglx

-->
Maxime Ripard (1):
  clockevent: sun4i: Fix race condition in the probe code


 drivers/clocksource/sun4i_timer.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c 
b/drivers/clocksource/sun4i_timer.c
index efb17c3ee120..f4a9c0058b4d 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -182,6 +182,12 @@ static void __init sun4i_timer_init(struct device_node 
*node)
/* Make sure timer is stopped before playing with interrupts */
sun4i_clkevt_time_stop(0);
 
+   sun4i_clockevent.cpumask = cpu_possible_mask;
+   sun4i_clockevent.irq = irq;
+
+   clockevents_config_and_register(_clockevent, rate,
+   TIMER_SYNC_TICKS, 0x);
+
ret = setup_irq(irq, _timer_irq);
if (ret)
pr_warn("failed to setup irq %d\n", irq);
@@ -189,12 +195,6 @@ static void __init sun4i_timer_init(struct device_node 
*node)
/* Enable timer0 interrupt */
val = readl(timer_base + TIMER_IRQ_EN_REG);
writel(val | TIMER_IRQ_EN(0), timer_base + TIMER_IRQ_EN_REG);
-
-   sun4i_clockevent.cpumask = cpu_possible_mask;
-   sun4i_clockevent.irq = irq;
-
-   clockevents_config_and_register(_clockevent, rate,
-   TIMER_SYNC_TICKS, 0x);
 }
 CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
   sun4i_timer_init);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/5] ARM: dts: add pinctrl support to Exynos5410

[Andreas Färber]

From: Hakjoo Kim 

Add the required pin configuration support to Exynos5410 using pinctrl
interface.

Signed-off-by: Hakjoo Kim 
[AF: Rebased, style changes]
Signed-off-by: Andreas Färber 
---
v1 -> v2:
* Filled in Sob from Hakjoo Kim

 arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 406 ++
 arch/arm/boot/dts/exynos5410.dtsi |  30 +++
 2 files changed, 436 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5410-pinctrl.dtsi

diff --git a/arch/arm/boot/dts/exynos5410-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos5410-pinctrl.dtsi
new file mode 100644
index ..f9aa6bb55464
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410-pinctrl.dtsi
@@ -0,0 +1,406 @@
+/*
+ * Exynos5410 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2013 Hardkernel Co., Ltd.
+ *  http://www.hardkernel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+_0 {
+   gpa0: gpa0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpa1: gpa1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpa2: gpa2 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpb0: gpb0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpb1: gpb1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpb2: gpb2 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpb3: gpb3 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpc0: gpc0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpc3: gpc3 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpc1: gpc1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpc2: gpc2 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpm5: gpm5 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   gpd1: gpd1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpe0: gpe0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpe1: gpe1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpf0: gpf0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpf1: gpf1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpg0: gpg0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpg1: gpg1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpg2: gpg2 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gph0: gph0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gph1: gph1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   

[PATCH v2 2/5] ARM: dts: exynos5410: Prepare ODROID-XU device tree

[Andreas Färber]

Derived from exynos5410-smdk5410.dts.

Signed-off-by: Andreas Färber 
---
v1 -> v2: Unchanged

 arch/arm/boot/dts/Makefile|  1 +
 arch/arm/boot/dts/exynos5410-odroidxu.dts | 78 +++
 2 files changed, 79 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5410-odroidxu.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91cd4d08b7f1..5b7cddbcb959 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -84,6 +84,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-rinato.dtb \
exynos5250-snow.dtb \
exynos5250-spring.dtb \
exynos5260-xyref5260.dtb \
+   exynos5410-odroidxu.dtb \
exynos5410-smdk5410.dtb \
exynos5420-arndale-octa.dtb \
exynos5420-peach-pit.dtb \
diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts 
b/arch/arm/boot/dts/exynos5410-odroidxu.dts
new file mode 100644
index ..97310bb727e2
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
@@ -0,0 +1,78 @@
+/*
+ * Hardkernel ODROID-XU device tree source
+ *
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * Based on exynos5410-smdk5410.dts:
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include "exynos5410.dtsi"
+/ {
+   model = "ODROID-XU based on EXYNOS5410";
+   compatible = "hardkernel,odroid-xu", "samsung,exynos5410", 
"samsung,exynos5";
+
+   memory {
+   reg = <0x4000 0x8000>;
+   };
+
+   chosen {
+   bootargs = "console=ttySAC2,115200";
+   };
+
+   fin_pll: xxti {
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   clock-output-names = "fin_pll";
+   #clock-cells = <0>;
+   };
+
+   firmware@02037000 {
+   compatible = "samsung,secure-firmware";
+   reg = <0x02037000 0x1000>;
+   };
+
+};
+
+_0 {
+   status = "okay";
+   num-slots = <1>;
+   cap-mmc-highspeed;
+   broken-cd;
+   card-detect-delay = <200>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <2 3>;
+   samsung,dw-mshc-ddr-timing = <1 2>;
+   bus-width = <8>;
+};
+
+_2 {
+   status = "okay";
+   num-slots = <1>;
+   cap-sd-highspeed;
+   card-detect-delay = <200>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <2 3>;
+   samsung,dw-mshc-ddr-timing = <1 2>;
+   bus-width = <4>;
+   disable-wp;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.1.2

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

[PATCH v2 5/5] ARM: dts: exynos5410: Add ODROID-XU LEDs

[Andreas Färber]

Signed-off-by: Hakjoo Kim 
Signed-off-by: Andreas Färber 
---
v1 -> v2:
* Filled in Sob from Hakjoo Kim

 arch/arm/boot/dts/exynos5410-odroidxu.dts | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts 
b/arch/arm/boot/dts/exynos5410-odroidxu.dts
index 97310bb727e2..b02cd3ab7b38 100644
--- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
+++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
@@ -15,6 +15,7 @@
 
 /dts-v1/;
 #include "exynos5410.dtsi"
+#include 
 / {
model = "ODROID-XU based on EXYNOS5410";
compatible = "hardkernel,odroid-xu", "samsung,exynos5410", 
"samsung,exynos5";
@@ -39,6 +40,30 @@
reg = <0x02037000 0x1000>;
};
 
+   leds {
+   compatible = "gpio-leds";
+
+   blue {
+   label = "blue:heartbeat";
+   gpios = < 2 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   linux,default-trigger = "heartbeat";
+   };
+
+   green {
+   label = "green:activity";
+   gpios = < 1 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   linux,default-trigger = "mmc0";
+   };
+
+   red {
+   label = "red:activity";
+   gpios = < 3 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   linux,default-trigger = "mmc1";
+   };
+   };
 };
 
 _0 {
-- 
2.1.2

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

[PATCH v2 1/5] ARM: dts: exynos5410: Clean up SMDK5410 indentation

[Andreas Färber]

The UART status properties are indented one level too deep, and we want
to derive a device tree for the ODROID-XU. Fix this before it propagates.

Signed-off-by: Andreas Färber 
---
v1 -> v2: Unchanged

 arch/arm/boot/dts/exynos5410-smdk5410.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts 
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index be3e02530b42..cebeaab3abec 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -62,13 +62,13 @@
 };
 
  {
-   status = "okay";
+   status = "okay";
 };
 
  {
-   status = "okay";
+   status = "okay";
 };
 
  {
-   status = "okay";
+   status = "okay";
 };
-- 
2.1.2

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

[PATCH v2 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs

[Andreas Färber]

Hello,

This series adds a dedicated ODROID-XU device tree and enhances it with 
LED configuration, to match the downstream 3.14 based behavior.

Regards,
Andreas

v1 -> v2:
* Inserted needed Sobs from Hakjoo Kim
* Rebased pinctrl (.svc, .{g,w}eint_{con,mask,pend} fields dropped)

Andreas Färber (3):
  ARM: dts: exynos5410: Clean up SMDK5410 indentation
  ARM: dts: exynos5410: Prepare ODROID-XU device tree
  ARM: dts: exynos5410: Add ODROID-XU LEDs

Hakjoo Kim (2):
  pinctrl: exynos: add exynos5410 SoC specific data
  ARM: dts: add pinctrl support to Exynos5410

 .../bindings/pinctrl/samsung-pinctrl.txt   |   1 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/exynos5410-odroidxu.dts  | 103 ++
 arch/arm/boot/dts/exynos5410-pinctrl.dtsi  | 406 +
 arch/arm/boot/dts/exynos5410-smdk5410.dts  |   6 +-
 arch/arm/boot/dts/exynos5410.dtsi  |  30 ++
 drivers/pinctrl/samsung/pinctrl-exynos.c   | 126 +++
 drivers/pinctrl/samsung/pinctrl-samsung.c  |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h  |   1 +
 9 files changed, 673 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos5410-odroidxu.dts
 create mode 100644 arch/arm/boot/dts/exynos5410-pinctrl.dtsi

-- 
2.1.2

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

[PATCH v2 3/5] pinctrl: exynos: add exynos5410 SoC specific data

[Andreas Färber]

From: Hakjoo Kim 

Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
support for all platforms based on EXYNOS5410.

Signed-off-by: Hakjoo Kim 
[AF: Rebased onto Exynos5260]
Signed-off-by: Andreas Färber 
---
v1 -> v2:
* Filled in Sob from Hakjoo Kim
* Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)

 .../bindings/pinctrl/samsung-pinctrl.txt   |   1 +
 drivers/pinctrl/samsung/pinctrl-exynos.c   | 126 +
 drivers/pinctrl/samsung/pinctrl-samsung.c  |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h  |   1 +
 4 files changed, 130 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index e82aaf492517..b87a176e730e 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -17,6 +17,7 @@ Required Properties:
   - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
   - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
   - "samsung,exynos5260-pinctrl": for Exynos5260 compatible pin-controller.
+  - "samsung,exynos5410-pinctrl": for Exynos5410 compatible pin-controller.
   - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller.
 
 - reg: Base address of the pin controller hardware module and length of
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d7154ed0b0eb..ef0e2a0d26eb 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1084,6 +1084,132 @@ struct samsung_pin_ctrl exynos5260_pin_ctrl[] = {
},
 };
 
+/* pin banks of exynos5410 pin-controller 0 */
+static struct samsung_pin_bank exynos5410_pin_banks0[] = {
+   EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
+   EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04),
+   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpa2", 0x08),
+   EXYNOS_PIN_BANK_EINTG(5, 0x060, "gpb0", 0x0c),
+   EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpb1", 0x10),
+   EXYNOS_PIN_BANK_EINTG(4, 0x0A0, "gpb2", 0x14),
+   EXYNOS_PIN_BANK_EINTG(4, 0x0C0, "gpb3", 0x18),
+   EXYNOS_PIN_BANK_EINTG(7, 0x0E0, "gpc0", 0x1c),
+   EXYNOS_PIN_BANK_EINTG(4, 0x100, "gpc3", 0x20),
+   EXYNOS_PIN_BANK_EINTG(7, 0x120, "gpc1", 0x24),
+   EXYNOS_PIN_BANK_EINTG(7, 0x140, "gpc2", 0x28),
+   EXYNOS_PIN_BANK_EINTN(2, 0x160, "gpm5"),
+   EXYNOS_PIN_BANK_EINTG(8, 0x180, "gpd1", 0x2c),
+   EXYNOS_PIN_BANK_EINTG(8, 0x1A0, "gpe0", 0x30),
+   EXYNOS_PIN_BANK_EINTG(2, 0x1C0, "gpe1", 0x34),
+   EXYNOS_PIN_BANK_EINTG(6, 0x1E0, "gpf0", 0x38),
+   EXYNOS_PIN_BANK_EINTG(8, 0x200, "gpf1", 0x3c),
+   EXYNOS_PIN_BANK_EINTG(8, 0x220, "gpg0", 0x40),
+   EXYNOS_PIN_BANK_EINTG(8, 0x240, "gpg1", 0x44),
+   EXYNOS_PIN_BANK_EINTG(2, 0x260, "gpg2", 0x48),
+   EXYNOS_PIN_BANK_EINTG(4, 0x280, "gph0", 0x4c),
+   EXYNOS_PIN_BANK_EINTG(8, 0x2A0, "gph1", 0x50),
+   EXYNOS_PIN_BANK_EINTN(8, 0x2C0, "gpm7"),
+   EXYNOS_PIN_BANK_EINTN(6, 0x2E0, "gpy0"),
+   EXYNOS_PIN_BANK_EINTN(4, 0x300, "gpy1"),
+   EXYNOS_PIN_BANK_EINTN(6, 0x320, "gpy2"),
+   EXYNOS_PIN_BANK_EINTN(8, 0x340, "gpy3"),
+   EXYNOS_PIN_BANK_EINTN(8, 0x360, "gpy4"),
+   EXYNOS_PIN_BANK_EINTN(8, 0x380, "gpy5"),
+   EXYNOS_PIN_BANK_EINTN(8, 0x3A0, "gpy6"),
+   EXYNOS_PIN_BANK_EINTN(8, 0x3C0, "gpy7"),
+   EXYNOS_PIN_BANK_EINTW(8, 0xC00, "gpx0", 0x00),
+   EXYNOS_PIN_BANK_EINTW(8, 0xC20, "gpx1", 0x04),
+   EXYNOS_PIN_BANK_EINTW(8, 0xC40, "gpx2", 0x08),
+   EXYNOS_PIN_BANK_EINTW(8, 0xC60, "gpx3", 0x0c),
+};
+
+/* pin banks of exynos5410 pin-controller 1 */
+static struct samsung_pin_bank exynos5410_pin_banks1[] = {
+   EXYNOS_PIN_BANK_EINTG(5, 0x000, "gpj0", 0x00),
+   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpj1", 0x04),
+   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpj2", 0x08),
+   EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpj3", 0x0c),
+   EXYNOS_PIN_BANK_EINTG(2, 0x080, "gpj4", 0x10),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0A0, "gpk0", 0x14),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0C0, "gpk1", 0x18),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0E0, "gpk2", 0x1c),
+   EXYNOS_PIN_BANK_EINTG(7, 0x100, "gpk3", 0x20),
+};
+
+/* pin banks of exynos5410 pin-controller 2 */
+static struct samsung_pin_bank exynos5410_pin_banks2[] = {
+   EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpv0", 0x00),
+   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpv1", 0x04),
+   EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpv2", 0x08),
+   EXYNOS_PIN_BANK_EINTG(8, 0x080, "gpv3", 0x0c),
+   EXYNOS_PIN_BANK_EINTG(2, 0x0C0, "gpv4", 0x10),
+};
+
+/* pin banks of exynos5410 pin-controller 3 */
+static struct samsung_pin_bank exynos5410_pin_banks3[] = {
+   EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),
+};
+
+/*
+ * Samsung pinctrl driver data for Exynos5410 SoC. Exynos5410 SoC includes
+ * four 

Re: [PATCH] can: eliminate banner[] variable and switch to pr_info()

[Jeremiah Mahler]

Oliver,

On Sat, Nov 22, 2014 at 05:41:28PM +0100, Oliver Hartkopp wrote:
> On 22.11.2014 08:42, Jeremiah Mahler wrote:
> >Several CAN modules use a design pattern with a banner[] variable at the
> >top which defines a string that is used once during init to print the
> >banner.  The string is also embedded with KERN_INFO which makes it
> >printk() specific.
> >
> >Improve the code by eliminating the banner[] variable and moving the
> >string to where it is printed.  Then switch from printk(KERN_INFO to
> >pr_info() for the lines that were changed.
> >
> >Signed-off-by: Jeremiah Mahler 
> 
> Acked-by: Oliver Hartkopp 
> 
> Next time please only post on linux-can ML which is the first address for
> CAN related stuff - as long as you don't feel it's a networking relevant
> issue.
> 
> But for almost editorial changes - which is not urgent - linux-can should be
> enough.
> 
> Thanks,
> Oliver
> 
Will do, thanks.

-- 
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ipc,sem block sem_lock on sma->lock during sma initialization

[Rik van Riel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/22/2014 02:14 PM, Manfred Spraul wrote:
> On 11/21/2014 09:29 PM, Rik van Riel wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 11/21/2014 03:09 PM, Andrew Morton wrote:
>>> On Fri, 21 Nov 2014 14:52:26 -0500 Rik van Riel
>>>  wrote:
>>> 
 When manipulating just one semaphore with semop, sem_lock
 only takes that single semaphore's lock. This creates a
 problem during initialization of the semaphore array, when
 the data structures used by sem_lock have not been set up
 yet. The sma->lock is already held by newary, and we just
 have to make sure everything else waits on that lock during
 initialization.
 
 Luckily it is easy to make sem_lock wait on the sma->lock,
 by pretending there is a complex operation in progress while
 the sma is being initialized.
 
 The newary function already zeroes sma->complex_count before 
 unlocking the sma->lock.
>>> What are the runtime effects of the bug?
>>> 
>> NULL pointer dereference in spin_lock from sem_lock, if it is
>> called before sma->sem_base has been pointed somewhere valid.
> No, this can't happen: - sma is initialized to 0 with memset() -
> sma->sem_nsems is set last. - semtimedop() contains a "max >=
> sma->sem_nsems".
> 
> with sma->sem_nsems==0, this will always fail and therefore
> sem_lock() can't be reached.

You're right. The reported race must have been semop vs RMID.

The kernel tree in question was missing this changeset:

commit 6e224f94597842c5eb17f1fc2208d20b6f7f7d49
Author: Manfred Spraul 
Date:   Wed Oct 16 13:46:45 2013 -0700

ipc/sem.c: synchronize semop and semctl with IPC_RMID


- -- 
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEbBAEBAgAGBQJUcO6rAAoJEM553pKExN6DPXkH+Ot5H94no3DJ6b1WdhOhDMUM
sQaWErEcSJ2dxzVES4WUMzqnnEZPokG2uK4z2PVUWjE+YA1U7hGfctLg/Eabr5tV
tD+uZhrbSbJVT7HiS5wyqmyzCV5eUV+2Am19pqwa6gyfB30cAYA/GtYfnMhKRGR0
l9hcvyzhci59d/2V2/Y5cGrxvQaWued33JZYfjp2TCl1GDpPD1bocptc3BO0DbwO
iHMZBcWfjR5t/EJ2Pg9gwu8X4C7amHsaNM58yTU6o93dE4bpS//A7WtwlLHJ/WEE
tD9zoOMnv7o8B5AHl3UDUJJ+JjieQU498AC3IganXQE8WrsZMJWZXo1OZtQP7A==
=vZEa
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] btrfs: enable swap file support

[Omar Sandoval]

On Fri, Nov 21, 2014 at 07:00:45PM +0100, David Sterba wrote:
> > +   pr_err("BTRFS: swapfile has holes");
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }
> > +   if (em->block_start == EXTENT_MAP_INLINE) {
> > +   pr_err("BTRFS: swapfile is inline");
> 
> While the test is valid, this would mean that the file is smaller than
> the inline limit, which is now one page. I think the generic swap code
> would refuse such a small file anyway.
> 
Sure. This test doesn't really cost us anything, so I think I'd feel a little
better just leaving it in. I'll add a comment for the next close reader.

Besides that and Filipe's response, I'll address everything you mentioned here
and in your other email in the next version, thanks.

> > +   ret = -EINVAL;
> > +   goto out;
> > +   }
> > +   if (test_bit(EXTENT_FLAG_COMPRESSED, >flags)) {
> > +   pr_err("BTRFS: swapfile is compresed");
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }
> 
> I think the preallocated extents should be refused as well. This means
> the filesystem has enough space to hold the data but it would still have
> to go through the allocation and could in turn stress the memory
> management code that triggered the swapping activity in the first place.
> 
> Though it's probably still possible to reach such corner case even with
> fully allocated nodatacow file, this should be reviewed anyway.
> 
I'll definitely take a closer look at this. In particular,
btrfs_get_blocks_direct and btrfs_get_extent do allocations in some cases which
I'll look into.

-- 
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ftrace/x86/extable] WARNING: CPU: 0 PID: 1 at init/main.c:803 do_one_initcall()

[Fengguang Wu]

Hi Steven,

On Sat, Nov 22, 2014 at 02:11:39PM -0500, Steven Rostedt wrote:
> On Sat, 22 Nov 2014 10:43:49 -0800
> Fengguang Wu  wrote:
> 
> > Greetings,
> > 
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git 
> > rfc/seq-buf
> > 
> > commit 716c18f8e57c5eff4725f0b5acbdb2fead202d8c
> 
> Yeah I had a brain fart with this patch that my tests quickly caught
> (which I push to my repo for your basic tests as I start testing with
> my own tests). But it wasn't up for very long before I rebased it with
> a working patch.

Sorry about that! The auto bisect was actually done in Nov 19,
unfortunately I was on travel in the past days, which lead to
the long delay in reporting out.

> 
> > Author: Steven Rostedt (Red Hat) 
> > AuthorDate: Tue Nov 18 21:14:11 2014 -0500
> > Commit: Steven Rostedt 
> > CommitDate: Tue Nov 18 23:26:23 2014 -0500
> 
> Is it possible for your tests to see if a branch was rebased before
> posting bug reports to LKML? This gave me a scare that my new code had
> the same brain fart in it.

Sure and good idea! I'll implement it right now.

Thanks,
Fengguang

> > ftrace/x86/extable: Add is_ftrace_trampoline() function
> > 
> > Stack traces that happen from function tracing check if the address
> > on the stack is a __kernel_text_address(). That is, is the address
> > kernel code. This calls core_kernel_text() which returns true
> > if the address is part of the builtin kernel code. It also calls
> > is_module_text_address() which returns true if the address belongs
> > to module code.
> > 
> > But what is missing is ftrace dynamically allocated trampolines.
> > These trampolines are allocated for individual ftrace_ops that
> > call the ftrace_ops callback functions directly. But if they do a
> > stack trace, the code checking the stack wont detect them as they
> > are neither core kernel code nor module address space.
> > 
> > Adding another field to ftrace_ops that also stores the size of
> > the trampoline assigned to it we can create a new function called
> > is_ftrace_trampoline() that returns true if the address is a
> > dynamically allocate ftrace trampoline. Note, it ignores trampolines
> > that are not dynamically allocated as they will return true with
> > the core_kernel_text() function.
> > 
> > Link: http://lkml.kernel.org/r/20141119034829.497125...@goodmis.org
> > 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Signed-off-by: Steven Rostedt 
> > 
> > +-++++
> > | | 
> > 766d21c795 | 716c18f8e5 | d165a751a0 |
> > +-++++
> > | boot_successes  | 
> > 60 | 0  | 0  |
> > | boot_failures   | 
> > 0  | 20 | 16 |
> > | WARNING:at_init/main.c:do_one_initcall()| 
> > 0  | 20 | 16 |
> > | initcall_init_kprobes_returned_with_preemption_imbalance| 
> > 0  | 20 | 16 |
> > | BUG:scheduling_while_atomic | 
> > 0  | 20 | 11 |
> > | BUG:workqueue_leaked_lock_or_atomic:kworker | 
> > 0  | 1  | 2  |
> > | backtrace:init_kprobes  | 
> > 0  | 20 | 16 |
> > | backtrace:warn_slowpath_fmt | 
> > 0  | 20 | 16 |
> > | backtrace:kernel_init_freeable  | 
> > 0  | 20 | 16 |
> > | backtrace:event_trace_self_tests| 
> > 0  | 20 | 11 |
> > | backtrace:event_trace_self_tests_init   | 
> > 0  | 20 | 11 |
> > | backtrace:dump_stack| 
> > 0  | 1  | 2  |
> > | backtrace:test_work | 
> > 0  | 1  | 2  |
> > | initcall_event_trace_self_tests_init_returned_with_preemption_imbalance | 
> > 0  | 18 | 7  |
> > | backtrace:unregister_ftrace_function| 
> > 0  | 18 | 7  |
> > | BUG:kernel_boot_hang| 
> > 0  | 0   

[PATCH v3 1/4] i2c: omap: cleanup register definitions

[Alexander Kochetkov]

Delete STAT_AD0 mask as unrelated to current IP (omap1?).
Delete DEBUG conditional around SYSTEST masks group.
Add SYSTEST functional mode masks for SCL and SDA.
Add STAT_BF mask.

Signed-off-by: Alexander Kochetkov 
Tested-by: Felipe Balbi 
Reviewed-by: Felipe Balbi 
---
 drivers/i2c/busses/i2c-omap.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 32dc651..adfac9b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -98,7 +98,7 @@ enum {
 #define OMAP_I2C_STAT_ROVR (1 << 11)   /* Receive overrun */
 #define OMAP_I2C_STAT_XUDF (1 << 10)   /* Transmit underflow */
 #define OMAP_I2C_STAT_AAS  (1 << 9)/* Address as slave */
-#define OMAP_I2C_STAT_AD0  (1 << 8)/* Address zero */
+#define OMAP_I2C_STAT_BF   (1 << 8)/* Bus Free */
 #define OMAP_I2C_STAT_XRDY (1 << 4)/* Transmit data ready */
 #define OMAP_I2C_STAT_RRDY (1 << 3)/* Receive data ready */
 #define OMAP_I2C_STAT_ARDY (1 << 2)/* Register access ready */
@@ -146,16 +146,20 @@ enum {
 #define OMAP_I2C_SCLH_HSSCLH   8
 
 /* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
 #define OMAP_I2C_SYSTEST_ST_EN (1 << 15)   /* System test enable */
 #define OMAP_I2C_SYSTEST_FREE  (1 << 14)   /* Free running mode */
 #define OMAP_I2C_SYSTEST_TMODE_MASK(3 << 12)   /* Test mode select */
 #define OMAP_I2C_SYSTEST_TMODE_SHIFT   (12)/* Test mode select */
+/* Functional mode */
+#define OMAP_I2C_SYSTEST_SCL_I_FUNC(1 << 8)/* SCL line input value 
*/
+#define OMAP_I2C_SYSTEST_SCL_O_FUNC(1 << 7)/* SCL line output 
value */
+#define OMAP_I2C_SYSTEST_SDA_I_FUNC(1 << 6)/* SDA line input value 
*/
+#define OMAP_I2C_SYSTEST_SDA_O_FUNC(1 << 5)/* SDA line output 
value */
+/* SDA/SCL IO mode */
 #define OMAP_I2C_SYSTEST_SCL_I (1 << 3)/* SCL line sense in */
 #define OMAP_I2C_SYSTEST_SCL_O (1 << 2)/* SCL line drive out */
 #define OMAP_I2C_SYSTEST_SDA_I (1 << 1)/* SDA line sense in */
 #define OMAP_I2C_SYSTEST_SDA_O (1 << 0)/* SDA line drive out */
-#endif
 
 /* OCP_SYSSTATUS bit definitions */
 #define SYSS_RESETDONE_MASK(1 << 0)
-- 
1.7.9.5

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

[PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values

[Alexander Kochetkov]

In a multimaster environment, after IP software reset, BB-bit value doesn't
correspond to the current bus state. It may happen what BB-bit will be 0,
while the bus is busy due to another I2C master activity.

Any transfer started when BB=0 and bus is busy wouldn't be completed by IP
and results in controller timeout. More over, in some cases IP could
interrupt another master's transfer and corrupt data on wire.

The commit implement method allowing to prevent IP from entering into
"controller timeout" state and from "data corruption" state.

The one drawback is the need to wait for 10ms before the first transfer.

Tested on Beagleboard XM C.
Tested on BBB and AM437x Starter Kit by Felipe Balbi.

Signed-off-by: Alexander Kochetkov 
Tested-by: Felipe Balbi 
Reviewed-by: Felipe Balbi 
---
 drivers/i2c/busses/i2c-omap.c |  103 +
 1 file changed, 103 insertions(+)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index adfac9b..a238a1d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -54,6 +54,9 @@
 /* timeout for pm runtime autosuspend */
 #define OMAP_I2C_PM_TIMEOUT1000/* ms */
 
+/* timeout for making decision on bus free status */
+#define OMAP_I2C_BUS_FREE_TIMEOUT (msecs_to_jiffies(10))
+
 /* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
 enum {
OMAP_I2C_REV_REG = 0,
@@ -206,6 +209,9 @@ struct omap_i2c_dev {
 */
u32 rev;
unsignedb_hw:1; /* bad h/w fixes */
+   unsignedbb_valid:1; /* true when BB-bit reflects
+* the I2C bus state
+*/
unsignedreceiver:1; /* true when we're in receiver 
mode */
u16 iestate;/* Saved interrupt register */
u16 pscstate;
@@ -332,7 +338,10 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
/* SYSC register is cleared by the reset; rewrite it */
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
 
+   /* Schedule I2C-bus monitoring on the next transfer */
+   dev->bb_valid = 0;
}
+
return 0;
 }
 
@@ -445,6 +454,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev->scllstate = scll;
dev->sclhstate = sclh;
 
+   if (dev->rev < OMAP_I2C_OMAP1_REV_2) {
+   /* Not implemented */
+   dev->bb_valid = 1;
+   }
+
__omap_i2c_init(dev);
 
return 0;
@@ -469,6 +483,91 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
 }
 
+/*
+ * Wait while BB-bit doesn't reflect the I2C bus state
+ *
+ * In a multimaster environment, after IP software reset, BB-bit value doesn't
+ * correspond to the current bus state. It may happen what BB-bit will be 0,
+ * while the bus is busy due to another I2C master activity.
+ * Here are BB-bit values after reset:
+ * SDA   SCL   BB   NOTES
+ *   0 00   1, 2
+ *   1 00   1, 2
+ *   0 11
+ *   1 10   3
+ * Later, if IP detect SDA=0 and SCL=1 (ACK) or SDA 1->0 while SCL=1 (START)
+ * combinations on the bus, it set BB-bit to 1.
+ * If IP detect SDA 0->1 while SCL=1 (STOP) combination on the bus,
+ * it set BB-bit to 0 and BF to 1.
+ * BB and BF bits correctly tracks the bus state while IP is suspended
+ * BB bit became valid on the next FCLK clock after CON_EN bit set
+ *
+ * NOTES:
+ * 1. Any transfer started when BB=0 and bus is busy wouldn't be
+ *completed by IP and results in controller timeout.
+ * 2. Any transfer started when BB=0 and SCL=0 results in IP
+ *starting to drive SDA low. In that case IP corrupt data
+ *on the bus.
+ * 3. Any transfer started in the middle of another master's transfer
+ *results in unpredictable results and data corruption
+ */
+static int omap_i2c_wait_for_bb_valid(struct omap_i2c_dev *dev)
+{
+   unsigned long bus_free_timeout = 0;
+   unsigned long timeout;
+   int bus_free = 0;
+   u16 stat, systest;
+
+   if (dev->bb_valid)
+   return 0;
+
+   timeout = jiffies + OMAP_I2C_TIMEOUT;
+   while (1) {
+   stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+   /*
+* We will see BB or BF event in a case IP had detected any
+* activity on the I2C bus. Now IP correctly tracks the bus
+* state. BB-bit value is valid.
+*/
+   if (stat & (OMAP_I2C_STAT_BB | OMAP_I2C_STAT_BF))
+   break;
+
+   /*
+* Otherwise, we must look signals on the bus to make
+* the right decision.
+*/
+   systest = omap_i2c_read_reg(dev, 

[PATCH v3 4/4] i2c: omap: add notes related to i2c multimaster mode

[Alexander Kochetkov]

No functional changes.

Signed-off-by: Alexander Kochetkov 
Reviewed-by: Felipe Balbi 
---
 drivers/i2c/busses/i2c-omap.c |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e67b7d0..f276c0c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -300,6 +300,12 @@ static void __omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
 
/*
+* NOTE: right after setting CON_EN, STAT_BB could be 0 while the
+* bus is busy. It will be changed to 1 on the next IP FCLK clock.
+* udelay(1) will be enough to fix that.
+*/
+
+   /*
 * Don't write to this register if the IE state is 0 as it can
 * cause deadlock.
 */
@@ -660,7 +666,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
 
if (!dev->b_hw && stop)
w |= OMAP_I2C_CON_STP;
-
+   /*
+* NOTE: STAT_BB bit could became 1 here if another master occupy
+* the bus. IP successfully complete transfer when the bus will be
+* free again (BB reset to 0).
+*/
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
 
/*
-- 
1.7.9.5

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

[PATCH v3 0/4] i2c: omap: patch series related to multimaster mode

[Alexander Kochetkov]

Here is the patch series intended to improve stability of
i2c-omap driver in the i2c multimaster environments.

Tested on Beagleboard XM C.
For now all fine. No controller timeouts, no data corruptions.

Also impelemented i2c bus fault detection during startup and
after reset.

So, instead of the message "controller timeout" blaming IP,
you get "timeout waiting for bus ready".

Rebased against i2c/for-next (eb61694b43dea0d43ea2574e7d48f476a6bdffb0)

Tested on the kernel from angstrom-v2013.06-yocto1.4
Kernel recepie linux-mainline_3.2.bb
git://github.com/Angstrom-distribution/meta-ti.git; branch 
angstrom-staging-yocto1.4
With all i2-omap.c patches backported from upstream linux/master

Signed-off-by: Alexander Kochetkov 

Alexander Kochetkov (4):
  i2c: omap: cleanup register definitions
  i2c: omap: implement workaround for handling invalid BB-bit values
  i2c: omap: don't reset controller if Arbitration Lost detected
  i2c: omap: add notes related to i2c multimaster mode

 drivers/i2c/busses/i2c-omap.c |  131 +++--
 1 file changed, 125 insertions(+), 6 deletions(-)

-- 
1.7.9.5

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

[PATCH v3 3/4] i2c: omap: don't reset controller if Arbitration Lost detected

[Alexander Kochetkov]

Arbitration Lost is an expected situation in a multimaster
environment. I2C controller (IP) correctly detect and report AL.

The only one visible reason for reseting IP in the AL case is
to avoid advisory 1.94 (omap3) and errata i595 (omap4): "I2C:
After an Arbitration is Lost the Module Incorrectly Starts
the Next Transfer".

Errata workaround states: "The MST and STT bits inside I2C_CON
should be set to 1 at the same moment (avoid setting the MST bit
to 1 while STT = 0)." The driver never set MST and STT bits
separately and doesn't create condition for errata. So the reset
is not necessary.

Also corrected return value for AL to -EAGAIN.

Tested on Beagleboard XM C.
Tested on BBB and AM437x Starter Kit by Felipe Balbi.

Signed-off-by: Alexander Kochetkov 
Tested-by: Felipe Balbi 
Reviewed-by: Felipe Balbi 
---
 drivers/i2c/busses/i2c-omap.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a238a1d..e67b7d0 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -703,13 +703,15 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
return 0;
 
/* We have an error */
-   if (dev->cmd_err & (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
-   OMAP_I2C_STAT_XUDF)) {
+   if (dev->cmd_err & (OMAP_I2C_STAT_ROVR | OMAP_I2C_STAT_XUDF)) {
omap_i2c_reset(dev);
__omap_i2c_init(dev);
return -EIO;
}
 
+   if (dev->cmd_err & OMAP_I2C_STAT_AL)
+   return -EAGAIN;
+
if (dev->cmd_err & OMAP_I2C_STAT_NACK) {
if (msg->flags & I2C_M_IGNORE_NAK)
return 0;
-- 
1.7.9.5

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

[PATCH] radeon: acquire BIOS via firmware subsystem if everything else failed

[Wilfried Klaebe]

At least Apple's MacBook Pro 8,2 booting EFI -> GRUB2 -> Linux (without
BIOS emulation) seems to have no Radeon BIOS accessible via conventional
means. Loading one via firmware system previously dumped (with
"dd if=/dev/mem of=/lib/firmware/radeon/vbios.bin bs=65536 skip=12 count=1")
when booted with BIOS emulation works. I carry this patch around since
about 3.8 and never had any problems, not even with several dozen cycles
of suspend2ram and resume. Also, I tested every new release if this patch
was still necessary, and it always was.

Thanks to Stefan Dösinger and others at 
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=26891

Signed-off-by: Wilfried Klaebe 

---

Note: I'm not subscribed to dri-de...@lists.freedesktop.org, please cc:
me if replying there.

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index 63ccb8f..cf55e0e 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -29,6 +29,7 @@
 #include "radeon_reg.h"
 #include "radeon.h"
 #include "atom.h"
+#include 
 
 #include 
 #include 
@@ -74,6 +75,44 @@ static bool igp_read_bios_from_vram(struct radeon_device 
*rdev)
return true;
 }
 
+static bool radeon_read_bios_from_firmware(struct radeon_device *rdev)
+{
+   const uint8_t __iomem *bios;
+   resource_size_t size;
+   const struct firmware *fw = NULL;
+   char *err = NULL;
+
+   request_firmware(, "radeon/vbios.bin", rdev->dev);
+   if (!fw) {
+   err = "firmware request returned NULL\n";
+   goto out;
+   }
+   size = fw->size;
+   bios = fw->data;
+
+   if (size == 0 || !bios) {
+   err = "firmware request returned zero sized or NULL data\n";
+   goto out;
+   }
+
+   if (bios[0] != 0x55 || bios[1] != 0xaa) {
+   err = "wrong signature on firmware\n";
+   goto out;
+   }
+   rdev->bios = kmalloc(size, GFP_KERNEL);
+   if (rdev->bios == NULL) {
+   err = "failed to kmalloc() memory for firmware\n";
+   goto out;
+   }
+   memcpy(rdev->bios, bios, size);
+out:
+   if (err)
+   DRM_ERROR(err);
+   if (fw)
+   release_firmware(fw);
+   return !err;
+}
+
 static bool radeon_read_bios(struct radeon_device *rdev)
 {
uint8_t __iomem *bios;
@@ -662,6 +701,8 @@ bool radeon_get_bios(struct radeon_device *rdev)
r = radeon_read_disabled_bios(rdev);
if (r == false)
r = radeon_read_platform_bios(rdev);
+   if (r == false)
+   r = radeon_read_bios_from_firmware(rdev);
if (r == false || rdev->bios == NULL) {
DRM_ERROR("Unable to locate a BIOS ROM\n");
rdev->bios = NULL;

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

Re: [PATCH] platform: x86: dell-laptop: Add support for keyboard backlight

[Darren Hart]

On Sat, Nov 22, 2014 at 07:46:25PM +0100, Pali Rohár wrote:

> > > 0   Completed successfully
> > > -1  Completed with error
> > > -2  Function not supported
> > > 
> > > So we can return something other too (not always -EINVAL).
> > > Do you have any idea which errno should we return for -1
> > > and -2?
> > 
> > For -1, I should think  -EIO (I/O Error)
> > For -2, I'd expect -ENXIO (No such device or address)
> > 
> 
> What about -ENOSYS for -2?

No. This specific topic came up at kernel summit this year. ENOSYS is
specifically for not implemented system calls.

> 
> > > > > + if (convert) {
> > > > > + /* NOTE: this switch fall down */
> > > > 
> > > > "fall down" ? As in, it intentionally doesn't have breaks?
> > > 
> > > This code convert "value" in "units" to new value in minutes
> > > units. So for unit == days it is: 24*60*60... So no breaks.
> > 
> > Right, so the language of the comment just wasn't clear, try:
> > 
> > /* Convert value from seconds to minutes */
> > 
> 
> Err... to seconds :-) But OK, I will change comment.

Oops, duh.

/* Convert value from current units to seconds. */

> 
> > > > > + switch (unit) {
> > > > > + case KBD_TIMEOUT_DAYS:
> > > > > + value *= 24;
> > > > > + case KBD_TIMEOUT_HOURS:
> > > > > + value *= 60;
> > > > > + case KBD_TIMEOUT_MINUTES:
> > > > > + value *= 60;
> > > > > + unit = KBD_TIMEOUT_SECONDS;
> > > > > + }

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

[RFC PATCH] fs/binfmt_elf.c: fix inconsistent vma dump size

[Jungseung Lee]

vma_dump_size() has been used several times on actual dumper
and it is supposed to be same values for same vma.
But vma_dump_size() could be different, while coredump is procceeded.
(e.g. remove shared memory)

In that case, header info and vma size could be inconsistent
and it cause wrong coredump file creation.

Fix the problem by always using the same vma dump size
which is stored in vma_filsz.

Signed-off-by: Jungseung Lee 
---
 fs/binfmt_elf.c | 40 ++--
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d8fc060..3ba08ca 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1994,18 +1994,6 @@ static void fill_extnum_info(struct elfhdr *elf, struct 
elf_shdr *shdr4extnum,
shdr4extnum->sh_info = segs;
 }
 
-static size_t elf_core_vma_data_size(struct vm_area_struct *gate_vma,
-unsigned long mm_flags)
-{
-   struct vm_area_struct *vma;
-   size_t size = 0;
-
-   for (vma = first_vma(current, gate_vma); vma != NULL;
-vma = next_vma(vma, gate_vma))
-   size += vma_dump_size(vma, mm_flags);
-   return size;
-}
-
 /*
  * Actual dumper
  *
@@ -2017,7 +2005,8 @@ static int elf_core_dump(struct coredump_params *cprm)
 {
int has_dumped = 0;
mm_segment_t fs;
-   int segs;
+   int segs, i;
+   size_t vma_data_size = 0;
struct vm_area_struct *vma, *gate_vma;
struct elfhdr *elf = NULL;
loff_t offset = 0, dataoff;
@@ -2026,6 +2015,7 @@ static int elf_core_dump(struct coredump_params *cprm)
struct elf_shdr *shdr4extnum = NULL;
Elf_Half e_phnum;
elf_addr_t e_shoff;
+   elf_addr_t *vma_filesz = NULL;
 
/*
 * We no longer stop all VM operations.
@@ -2093,7 +2083,20 @@ static int elf_core_dump(struct coredump_params *cprm)
 
dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
 
-   offset += elf_core_vma_data_size(gate_vma, cprm->mm_flags);
+   vma_filesz = kmalloc(sizeof(*vma_filesz) * (segs - 1), GFP_KERNEL);
+   if (!vma_filesz)
+   goto end_coredump;
+
+   for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
+   vma = next_vma(vma, gate_vma)) {
+   unsigned long dump_size;
+
+   dump_size = vma_dump_size(vma, cprm->mm_flags);
+   vma_filesz[i++] = dump_size;
+   vma_data_size += dump_size;
+   }
+
+   offset += vma_data_size;
offset += elf_core_extra_data_size();
e_shoff = offset;
 
@@ -2113,7 +2116,7 @@ static int elf_core_dump(struct coredump_params *cprm)
goto end_coredump;
 
/* Write program headers for segments dump */
-   for (vma = first_vma(current, gate_vma); vma != NULL;
+   for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
vma = next_vma(vma, gate_vma)) {
struct elf_phdr phdr;
 
@@ -2121,7 +2124,7 @@ static int elf_core_dump(struct coredump_params *cprm)
phdr.p_offset = offset;
phdr.p_vaddr = vma->vm_start;
phdr.p_paddr = 0;
-   phdr.p_filesz = vma_dump_size(vma, cprm->mm_flags);
+   phdr.p_filesz = vma_filesz[i++];
phdr.p_memsz = vma->vm_end - vma->vm_start;
offset += phdr.p_filesz;
phdr.p_flags = vma->vm_flags & VM_READ ? PF_R : 0;
@@ -2149,12 +2152,12 @@ static int elf_core_dump(struct coredump_params *cprm)
if (!dump_skip(cprm, dataoff - cprm->written))
goto end_coredump;
 
-   for (vma = first_vma(current, gate_vma); vma != NULL;
+   for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
vma = next_vma(vma, gate_vma)) {
unsigned long addr;
unsigned long end;
 
-   end = vma->vm_start + vma_dump_size(vma, cprm->mm_flags);
+   end = vma->vm_start + vma_filesz[i++];
 
for (addr = vma->vm_start; addr < end; addr += PAGE_SIZE) {
struct page *page;
@@ -2187,6 +2190,7 @@ end_coredump:
 cleanup:
free_note_info();
kfree(shdr4extnum);
+   kfree(vma_filesz);
kfree(phdr4note);
kfree(elf);
 out:
-- 
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] ipc,sem block sem_lock on sma->lock during sma initialization

[Manfred Spraul]

On 11/21/2014 09:29 PM, Rik van Riel wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/21/2014 03:09 PM, Andrew Morton wrote:

On Fri, 21 Nov 2014 14:52:26 -0500 Rik van Riel 
wrote:


When manipulating just one semaphore with semop, sem_lock only
takes that single semaphore's lock. This creates a problem during
initialization of the semaphore array, when the data structures
used by sem_lock have not been set up yet. The sma->lock is
already held by newary, and we just have to make sure everything
else waits on that lock during initialization.

Luckily it is easy to make sem_lock wait on the sma->lock, by
pretending there is a complex operation in progress while the sma
is being initialized.

The newary function already zeroes sma->complex_count before
unlocking the sma->lock.

What are the runtime effects of the bug?


NULL pointer dereference in spin_lock from sem_lock,
if it is called before sma->sem_base has been pointed
somewhere valid.

No, this can't happen:
- sma is initialized to 0 with memset()
- sma->sem_nsems is set last.
- semtimedop() contains a "max >= sma->sem_nsems".

with sma->sem_nsems==0, this will always fail and therefore sem_lock() 
can't be reached.


The only misbehavior (apart from returning -EFBIG) is that 
find_alloc_undo() could allocate a wrong-sized undo structure.

Would cause random memory corruptions - but not NULL pointer dereference.

Which which kernel version have you seen the NULL pointer dereference?

--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ftrace/x86/extable] WARNING: CPU: 0 PID: 1 at init/main.c:803 do_one_initcall()

[Steven Rostedt]

On Sat, 22 Nov 2014 10:43:49 -0800
Fengguang Wu  wrote:

> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git 
> rfc/seq-buf
> 
> commit 716c18f8e57c5eff4725f0b5acbdb2fead202d8c

Yeah I had a brain fart with this patch that my tests quickly caught
(which I push to my repo for your basic tests as I start testing with
my own tests). But it wasn't up for very long before I rebased it with
a working patch.


> Author: Steven Rostedt (Red Hat) 
> AuthorDate: Tue Nov 18 21:14:11 2014 -0500
> Commit: Steven Rostedt 
> CommitDate: Tue Nov 18 23:26:23 2014 -0500

Is it possible for your tests to see if a branch was rebased before
posting bug reports to LKML? This gave me a scare that my new code had
the same brain fart in it.

-- Steve


> 
> ftrace/x86/extable: Add is_ftrace_trampoline() function
> 
> Stack traces that happen from function tracing check if the address
> on the stack is a __kernel_text_address(). That is, is the address
> kernel code. This calls core_kernel_text() which returns true
> if the address is part of the builtin kernel code. It also calls
> is_module_text_address() which returns true if the address belongs
> to module code.
> 
> But what is missing is ftrace dynamically allocated trampolines.
> These trampolines are allocated for individual ftrace_ops that
> call the ftrace_ops callback functions directly. But if they do a
> stack trace, the code checking the stack wont detect them as they
> are neither core kernel code nor module address space.
> 
> Adding another field to ftrace_ops that also stores the size of
> the trampoline assigned to it we can create a new function called
> is_ftrace_trampoline() that returns true if the address is a
> dynamically allocate ftrace trampoline. Note, it ignores trampolines
> that are not dynamically allocated as they will return true with
> the core_kernel_text() function.
> 
> Link: http://lkml.kernel.org/r/20141119034829.497125...@goodmis.org
> 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Signed-off-by: Steven Rostedt 
> 
> +-++++
> | | 
> 766d21c795 | 716c18f8e5 | d165a751a0 |
> +-++++
> | boot_successes  | 
> 60 | 0  | 0  |
> | boot_failures   | 0 
>  | 20 | 16 |
> | WARNING:at_init/main.c:do_one_initcall()| 0 
>  | 20 | 16 |
> | initcall_init_kprobes_returned_with_preemption_imbalance| 0 
>  | 20 | 16 |
> | BUG:scheduling_while_atomic | 0 
>  | 20 | 11 |
> | BUG:workqueue_leaked_lock_or_atomic:kworker | 0 
>  | 1  | 2  |
> | backtrace:init_kprobes  | 0 
>  | 20 | 16 |
> | backtrace:warn_slowpath_fmt | 0 
>  | 20 | 16 |
> | backtrace:kernel_init_freeable  | 0 
>  | 20 | 16 |
> | backtrace:event_trace_self_tests| 0 
>  | 20 | 11 |
> | backtrace:event_trace_self_tests_init   | 0 
>  | 20 | 11 |
> | backtrace:dump_stack| 0 
>  | 1  | 2  |
> | backtrace:test_work | 0 
>  | 1  | 2  |
> | initcall_event_trace_self_tests_init_returned_with_preemption_imbalance | 0 
>  | 18 | 7  |
> | backtrace:unregister_ftrace_function| 0 
>  | 18 | 7  |
> | BUG:kernel_boot_hang| 0 
>  | 0  | 2  |
> +-++++
> 
> [1.649109] Kprobe smoke test: passed successfully
> [1.649888] [ cut here ]
> [1.649888] [ cut here ]
> [1.650631] WARNING: CPU: 0 PID: 1 at init/main.c:803 
> do_one_initcall+0x1a9/0x200()
> [1.650631] WARNING: CPU: 0 PID: 1 at init/main.c:803 
> 

Re: [PATCH] staging: lustre: Coalesce string fragments

[Greg Kroah-Hartman]

On Thu, Nov 20, 2014 at 03:43:39PM -0800, Joe Perches wrote:
> Join the string fragments to make it easier to grep.
> 
> Ignored all the 80+ column lines.
> Added many missing spaces when coalescing formats.
> 
> Signed-off-by: Joe Perches 
> ---
> 
> I used this directory as a test for a new "coalesce string
> fragments" checkpatch rule.  Might as well submit the change.

Doesn't apply to my staging-testing branch anymore due to other changes
that were sent in before 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] staging:lustre:lnet:lnet Function must be static

[Greg Kroah-Hartman]

On Sun, Nov 16, 2014 at 09:24:44PM +0800, sunwxg wrote:
> From: Sun Wang 
> 
> Function must be static if function will not be used in other files.
> 
> Signed-off-by: Sun Wang 
> 
> ---
>  drivers/staging/lustre/lnet/lnet/{module.c.org => module.c} | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/lnet/lnet/module.c.org 
> b/drivers/staging/lustre/lnet/lnet/module.c
> index e84d59d..4ca7b1d 100644
> --- a/drivers/staging/lustre/lnet/lnet/module.c.org
> +++ b/drivers/staging/lustre/lnet/lnet/module.c
> @@ -43,7 +43,7 @@ MODULE_PARM_DESC(config_on_load, "configure network at 
> module load");
>  
>  static struct mutex lnet_config_mutex;
>  
> -int
> +static int
>  lnet_configure(void *arg)
>  {
>   /* 'arg' only there so I can be passed to cfs_create_thread() */

Does not apply :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: lustre: Fix sparse warnings for static declarations

[Greg KH]

On Tue, Nov 11, 2014 at 12:15:28AM -0500, Adrian Nicoara wrote:
> All the changes are against variables/functions that are only accessed from
> within the same file. If the scope needs to change later on, the static 
> keyword
> can be removed.
> 
> Build tested.
> 
> Signed-off-by: Adrian Nicoara 

Adds a few build warnings, so I can't take this patch, sorry :(

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

Re: [PATCH] drivers:staging:skein:skein_generic.c: Fixed a whitespace error

[Greg KH]

On Sat, Nov 22, 2014 at 01:11:59PM +0530, Anjana Sasindran wrote:
>  This patch fixes the checkpatch.pl error:
> 
>  ERROR: trailing whitespace
> 
> Signed-off-by: Anjana Sasindran 
> ---
>  drivers/staging/skein/skein_generic.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/staging/skein/skein_generic.c 
> b/drivers/staging/skein/skein_generic.c
> index 7096d5a..268e4de 100644
> --- a/drivers/staging/skein/skein_generic.c
> +++ b/drivers/staging/skein/skein_generic.c
> @@ -188,7 +188,6 @@ static int __init skein_generic_init(void)
>   goto unreg256;
>   if (crypto_register_shash())
>   goto unreg512;
> -
>   return 0;
>  unreg512:
>   crypto_unregister_shash();

Your changelog body does not match the patch :(

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Staging:skein: Fix trailing whitespace error

[Greg KH]

On Sat, Nov 22, 2014 at 11:34:29AM +0530, Anjana Sasindran wrote:
>   This patch fixes the checkpatch.pl error:
> 
>   ERROR: trailing whitespace
> 
> Signed-off-by: Anjana Sasindran 
> ---
>  drivers/staging/skein/skein_generic.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/skein/skein_generic.c 
> b/drivers/staging/skein/skein_generic.c
> index 7096d5a..8660509 100644
> --- a/drivers/staging/skein/skein_generic.c
> +++ b/drivers/staging/skein/skein_generic.c
> @@ -190,6 +190,7 @@ static int __init skein_generic_init(void)
>   goto unreg512;
>  
>   return 0;
> +
>  unreg512:
>   crypto_unregister_shash();
>  unreg256:

Still doesn't apply :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Staging:skein: Fix trailing whitespace error

[Greg KH]

On Fri, Nov 21, 2014 at 05:37:04AM +0530, Anjana Sasindran wrote:
>   This patch fixes the checkpatch.pl error:
> 
>   ERROR: trailing whitespace
> 
> Signed-off-by: Anjana Sasindran 
> ---
>  drivers/staging/skein/skein_generic.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/skein/skein_generic.c 
> b/drivers/staging/skein/skein_generic.c
> index 7096d5a..8660509 100644
> --- a/drivers/staging/skein/skein_generic.c
> +++ b/drivers/staging/skein/skein_generic.c
> @@ -190,6 +190,7 @@ static int __init skein_generic_init(void)
>   goto unreg512;
>  
>   return 0;
> +
>  unreg512:
>   crypto_unregister_shash();
>  unreg256:

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

Re: [PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

[Javier Martinez Canillas]

Hello Vivek

On Wed, Nov 19, 2014 at 1:03 PM, Vivek Gautam  wrote:
>>
>> Tested-by: Javier Martinez Canillas 
>
> Thanks for testing.
>

You are welcome

>>
>> Kukjin,
>
> Sorry for not adding Kukjin to the list and thereby for the delay
> about this patch.
>

No worries but I'm not sure if Kukjin is aware of this patch. I see he
has been applying other patches but didn't pick $subject.

Maybe you can resend it to Kukjin just to be sure he will have it in
his mailbox?

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [time] WARNING: CPU: 0 PID: 1 at kernel/time/timekeeping.c:1337 update_wall_time()

[Fengguang Wu]

Hi Xunlei,

FYI, here is another bisect result.

https://git.linaro.org/people/john.stultz/linux.git fortglx/3.19/time

commit 59fa38d60ca4bc7a2efffae1b40aa7960374ef9d
Author: pang.xunlei 
AuthorDate: Wed Oct 8 15:03:34 2014 +0800
Commit: John Stultz 
CommitDate: Thu Oct 23 21:26:24 2014 -0700

time: Avoid possible NTP adjustment mult overflow.

Ideally, __clocksource_updatefreq_scale, selects the largest shift
value possible for a clocksource. This results in the mult memember of
struct clocksource being particularly large, although not so large
that NTP would adjust the clock to cause it to overflow.

That said, nothing actually prohibits an overflow from occuring, its
just that it "shouldn't" occur.

So while very unlikely, and so far never observed, the value of
(cs->mult+cs->maxadj) may have a chance to reach very near 0x,
so there is a possibility it may overflow when doing NTP positive
adjustment

See the following detail: When NTP slewes the clock, kernel goes
through update_wall_time()->...->timekeeping_apply_adjustment():
tk->tkr.mult += mult_adj;

Since there is no guard against it, its possible tk->tkr.mult may
overflow during this operation.

This patch avoids any possible mult overflow by judging the overflow
case before adding mult_adj to mult, also adds the WARNING message
when capturing such case.

Signed-off-by: pang.xunlei 
[jstultz: Reworded commit message]
Signed-off-by: John Stultz 

+-++++
| | 3953d54968 | 
59fa38d60c | 59fa38d60c |
+-++++
| boot_successes  | 60 | 0  
| 0  |
| boot_failures   | 0  | 11 
| 11 |
| WARNING:at_kernel/time/timekeeping.c:update_wall_time() | 0  | 11 
| 11 |
| backtrace:event_create_dir  | 0  | 11 
| 11 |
| backtrace:event_trace_init  | 0  | 11 
| 11 |
| backtrace:kernel_init_freeable  | 0  | 11 
| 11 |
+-++++

[0.489933] Warning: could not register all branches stats
[0.491673] Warning: could not register annotated branches stats
[0.500012] [ cut here ]
[0.500012] WARNING: CPU: 0 PID: 1 at kernel/time/timekeeping.c:1337 
update_wall_time+0x5d8/0x8dc()
[0.500012] Modules linked in:
[0.500012] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
3.18.0-rc1-00274-g59fa38d #496
[0.500012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[0.500012]  0009 880013a03e58 818a545a 

[0.500012]   880013a03e98 810cd4d6 
0001
[0.500012]  811659ec 2201 0001 
0001
[0.500012] Call Trace:
[0.500012][] dump_stack+0x7e/0xaa
[0.500012]  [] warn_slowpath_common+0x98/0xb2
[0.500012]  [] ? update_wall_time+0x5d8/0x8dc
[0.500012]  [] warn_slowpath_null+0x1a/0x1c
[0.500012]  [] update_wall_time+0x5d8/0x8dc
[0.500012]  [] tick_periodic+0x9d/0xc6
[0.500012]  [] ? tick_handle_periodic+0x27/0xa7
[0.500012]  [] tick_handle_periodic+0x27/0xa7
[0.500012]  [] local_apic_timer_interrupt+0x6c/0x70
[0.500012]  [] smp_apic_timer_interrupt+0x40/0x52
[0.500012]  [] apic_timer_interrupt+0x72/0x80
[0.500012][] ? __lock_acquire+0x7f4/0xc24
[0.500012]  [] ? lock_acquire+0xcc/0x12b
[0.500012]  [] ? __d_instantiate+0x33/0x1c7
[0.500012]  [] _raw_spin_lock+0x36/0x84
[0.500012]  [] ? __d_instantiate+0x33/0x1c7
[0.500012]  [] __d_instantiate+0x33/0x1c7
[0.500012]  [] d_instantiate+0x7f/0xb1
[0.500012]  [] simple_lookup+0x76/0x84
[0.500012]  [] lookup_real+0x6d/0xb6
[0.500012]  [] __lookup_hash+0x42/0x49
[0.500012]  [] lookup_one_len+0x224/0x233
[0.500012]  [] __create_file+0xbf/0x24c
[0.500012]  [] debugfs_create_file+0x21/0x23
[0.500012]  [] trace_create_file+0x12/0x33
[0.500012]  [] event_create_dir+0x36b/0x411
[0.500012]  [] event_trace_init+0x1b9/0x23c
[0.500012]  [] ? event_trace_enable+0x170/0x170
[0.500012]  [] do_one_initcall+0x14d/0x257
[0.500012]  [] ? parse_args+0x352/0x433
[0.500012]  [] kernel_init_freeable+0x111/0x1da
[0.500012]  [] ? rest_init+0xc7/0xc7
[0.500012]  [] kernel_init+0xe/0x157
[0.500012]  [] ret_from_fork+0x7c/0xb0
[0.500012]  [] ? rest_init+0xc7/0xc7
[0.500012] ---[ end trace 

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Ivaylo Dimitrov]

Hi,


Can you capture raw bayer images correctly? I assume green
means YUV buffers that are all zero.

Do you know more specifically which patch breaks it?


CCing freemangordon (Ivaylo Dimitrov). He tried to debug it
months ago but without success. Should know more info about this
problem.

I think that commit which broke it was not bisected...



According to my vague memories, the green captured image was a result 
from the ISP IRQ never got triggered. I tried to find why, but never 
succeeded.


Sakari, we discussed that on #maemo-ssu when I was playing with cameras, 
and there is nothing new in that regard:
http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2013-09-18.log.html#t2013-09-18T18:46:38 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] platform: x86: dell-laptop: Add support for keyboard backlight

[Pali Rohár]

On Friday 21 November 2014 21:39:30 Darren Hart wrote:
> On Wed, Nov 19, 2014 at 09:41:20PM +0100, Pali Rohár wrote:
> > Hello,
> 
> Hi Pali,
> 
> > I removed other lines so mail is not too long.
> 
> > On Wednesday 19 November 2014 19:34:16 Darren Hart wrote:
> ...
> 
> > > > +}
> > > > +
> > > > +static unsigned int kbd_get_max_level(void)
> > > > +{
> > > > +   if (kbd_info.levels != 0)
> > > > +   return kbd_info.levels;
> > > 
> > > This test does nothing? if it is 0, you still return 0
> > > below :-)
> > > 
> > > > +   if (kbd_mode_levels_count > 0)
> > > > +   return kbd_mode_levels_count - 1;
> > > > +   return 0;
> > > 
> > > So the function is:
> > > 
> > > return kbd_mode_levels_count > 0 ? kbd_mode_levels_count -
> > > 1 : kbd_info.levels;
> > > 
> > > The if blocks are more legible, so that's fine, but the
> > > first one doesn't seem to do anything and you can replace
> > > the final return with return kbd_info.levels.
> > 
> > There are two main way for setting keyboard backlight level.
> > One is setting level register and other one is setting
> > special keyboard mode. And some dell laptops support only
> > first and some only second. So this code choose first
> > available/valid method and then return correct data. I'm
> > not sure if those two methods are only one and also do not
> > know if in future there will be something other. Because of
> > this I use code pattern:
> > 
> > if (check_method_1) return value_method_1;
> > if (check_method_2) return value_method_2;
> > ...
> > return unsupported;
> > 
> > Same pattern logic is used in all functions which doing
> > something with keyboard backlight level. (I will not other
> > functions).
> 
> Fair enough. Clear, legible, consistent coding is preferable
> to a few micro optimizations that the compiler is likely to
> catch anyway. I withdraw the comment :-)
> 

Ok.

> > > > +static int kbd_set_state(struct kbd_state *state)
> > > > +{
> > > > +   int ret;
> > > > +
> > > > +   get_buffer();
> > > > +   buffer->input[0] = 0x2;
> > > > +   buffer->input[1] = BIT(state->mode_bit) & 0x;
> > > > +   buffer->input[1] |= (state->triggers & 0xFF) << 16;
> > > > +   buffer->input[1] |= (state->timeout_value & 0x3F) <<
> > > > 24; +   buffer->input[1] |= (state->timeout_unit & 0x3)
> > > > << 30; +buffer->input[2] = state->als_setting & 0xFF;
> > > > +   buffer->input[2] |= (state->level & 0xFF) << 16;
> > > > +   dell_send_request(buffer, 4, 11);
> > > > +   ret = buffer->output[0];
> > > > +   release_buffer();
> > > > +
> > > > +   if (ret)
> > > > +   return -EINVAL;
> > > 
> > > Also, is EINVAL right here and elsewhere? Or did something
> > > fail? EXIO?
> > 
> > According to Dell documentation, return value is stored in
> > buffer->output[0] and can be:
> > 
> > 0   Completed successfully
> > -1  Completed with error
> > -2  Function not supported
> > 
> > So we can return something other too (not always -EINVAL).
> > Do you have any idea which errno should we return for -1
> > and -2?
> 
> For -1, I should think  -EIO (I/O Error)
> For -2, I'd expect -ENXIO (No such device or address)
> 

What about -ENOSYS for -2?

> Cc Rafael, Mika, linux-acpi in case they have a better idea.
> 
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +
> > > > +static int kbd_set_state_safe(struct kbd_state *state,
> > > > struct kbd_state *old) +{
> > > > +   int ret;
> > > > +
> > > > +   ret = kbd_set_state(state);
> > > > +   if (ret == 0)
> > > > +   return 0;
> > > > +
> > > > +   if (kbd_set_state(old))
> > > > +   pr_err("Setting old previous keyboard state
> > 
> > failed\n");
> > 
> > > And if we got an error and kbd_set_state(old) doesn't
> > > return !0, what's the state of things? Still a failure a
> > > presume?
> > 
> > In some cases some laptops do not have to support
> > everything. And when I (and Gabriele too) tried to set
> > something unsupported Dell BIOS just resetted all settings
> > to some default values. So this function try to set new
> > state and if it fails then it try to restore previous
> > settings.
> 
> OK, that deserves a comment then as the rationale isn't
> obvious.
> 

Ok, I will add comment.

> > > > +
> > > > +   return ret;
> > > > +}
> > > > 
> > > > +static void kbd_init(void)
> > > > +{
> > > > +   struct kbd_state state;
> > > > +   int ret;
> > > > +   int i;
> > > > +
> > > > +   ret = kbd_get_info(_info);
> > > > +
> > > > +   if (ret == 0) {
> > > > +
> > > 
> > > Checking for success, let's invert and avoid the
> > > indentation here too.
> > 
> > Again this is hard and not possible. This function first
> > process data from kbd_get_info (if does not fail), then
> > process data for kbd_tokens (via function find_token_id)
> > and then set kbd_led_present to true if at least
> > kbd_get_info or kbd_tokens succed.
> 
> The goal here is 

[spi/of] WARNING: CPU: 0 PID: 1 at drivers/spi/spi.c:2434 spi_init()

[Fengguang Wu]

Greetings,

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

git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux 
devicetree/next-overlay

commit 9b84294398291359d6c8f4ac4f36c7c666c6948a
Author: Pantelis Antoniou 
AuthorDate: Tue Oct 28 22:36:05 2014 +0200
Commit: Grant Likely 
CommitDate: Fri Nov 21 16:51:58 2014 +

spi/of: Add OF notifier handler

Add OF notifier handler needed for creating/destroying spi devices
according to dynamic runtime changes in the DT live tree. This code is
enabled when CONFIG_OF_DYNAMIC is selected.

Signed-off-by: Pantelis Antoniou 
Signed-off-by: Grant Likely 

+-++++
| | 528a376eb2 | 9b84294398 | 
7ddde6bcf8 |
+-++++
| boot_successes  | 60 | 0  | 0 
 |
| boot_failures   | 0  | 20 | 12
 |
| WARNING:at_drivers/spi/spi.c:spi_init() | 0  | 20 | 12
 |
| backtrace:spi_init  | 0  | 20 | 12
 |
| backtrace:warn_slowpath_null| 0  | 20 | 12
 |
| backtrace:kernel_init_freeable  | 0  | 20 | 12
 |
+-++++

[0.157186] regulator-dummy: no parameters
[0.158309] NET: Registered protocol family 16
[0.160561] [ cut here ]
[0.161315] WARNING: CPU: 0 PID: 1 at drivers/spi/spi.c:2434 
spi_init+0x5c/0x81()
[0.162667] CPU: 0 PID: 1 Comm: swapper Not tainted 
3.18.0-rc5-00044-g9b84294 #6
[0.167195]    51c75ef0 4160e32b 51c75f0c 4103776f 0982 
41abbd9c
[0.168590]   41abbd40 51e60ea0 51c75f1c 41037817 0009  
51c75f28
[0.170011]  41abbd9c  51c75f88 41a82c87  53ff7821 51c75f00 
4104e04b
[0.171428] Call Trace:
[0.171820]  [<4160e32b>] dump_stack+0x16/0x18
[0.172513]  [<4103776f>] warn_slowpath_common+0x61/0x78
[0.173394]  [<41abbd9c>] ? spi_init+0x5c/0x81
[0.174081]  [<41abbd40>] ? ftrace_define_fields_spi_transfer+0x85/0x85
[0.175070]  [<41037817>] warn_slowpath_null+0x14/0x18
[0.175871]  [<41abbd9c>] spi_init+0x5c/0x81
[0.176584]  [<41a82c87>] do_one_initcall+0x100/0x1aa
[0.177382]  [<4104e04b>] ? parse_args+0x2c7/0x3e1
[0.178120]  [<41a82435>] ? do_early_param+0x73/0x73
[0.178892]  [<41a82e0c>] kernel_init_freeable+0xdb/0x158
[0.179736]  [<41a82e0c>] ? kernel_init_freeable+0xdb/0x158
[0.180020]  [<4160ab57>] kernel_init+0xd/0xb8
[0.180755]  [<41615980>] ret_from_kernel_thread+0x20/0x30
[0.181634]  [<4160ab4a>] ? rest_init+0xa5/0xa5
[0.182354] ---[ end trace d94d5f4e01dcfac4 ]---
[0.210073] cpuidle: using governor menu

git bisect start 7ddde6bcf8a4f0d1ed5e4aa1738ac0a190c46342 
0df1f2487d2f0d04703f142813d53615d62a1da4 --
git bisect good 53a4ab96c61a34d62717b1481f6043e0b4338d74  # 17:50 20+  
0  of: Change of_device_is_available() to return bool
git bisect good 8c77e1164d2c04e401807d11c854484716c6e84f  # 17:52 20+  
0  of/overlay: Add overlay unittests
git bisect good 0eec03c7fbec316b885ee158f0f57a618392cab5  # 17:56 20+  
0  fixup of_platform
git bisect good 0b90f7808351f9d0c0a2ba6cd96f4246505b592b  # 17:59 20+  
0  i2c: Add OF notifier handler
git bisect good 528a376eb2db8e9b18054ab4dee952b9dfddef57  # 18:03 20+  
0  spi/of: Create new device registration method and accessors
git bisect  bad 9b84294398291359d6c8f4ac4f36c7c666c6948a  # 18:06  0- 
20  spi/of: Add OF notifier handler
# first bad commit: [9b84294398291359d6c8f4ac4f36c7c666c6948a] spi/of: Add OF 
notifier handler
git bisect good 528a376eb2db8e9b18054ab4dee952b9dfddef57  # 18:09 60+  
0  spi/of: Create new device registration method and accessors
git bisect  bad 7ddde6bcf8a4f0d1ed5e4aa1738ac0a190c46342  # 18:09  0- 
12  HACK: Make overlay support user selectable
git bisect good 8a84e01e147f44111988f9d8ccd2eaa30215a0f2  # 18:12 60+  
0  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good ed6778aef7428a6c5fc1acf08a3e9126f5eef770  # 18:16 60+  
0  Add linux-next specific files for 20141121


This script may reproduce the error.


#!/bin/bash

kernel=$1
initrd=quantal-core-i386.cgz

wget --no-clobber 
https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd

kvm=(
qemu-system-x86_64
-enable-kvm
-cpu Haswell,+smep,+smap
-kernel $kernel
-initrd $initrd
-m 320
-smp 2
-net nic,vlan=1,model=e1000
-net user,vlan=1
-boot order=nc

[patch] tracing: remove unneeded NULL check

[Dan Carpenter]

We checked "iter->trace" earlier so there is no need to check here.

Signed-off-by: Dan Carpenter 

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 9ddd6aa..52fbbc5 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3019,7 +3019,7 @@ __tracing_open(struct inode *inode, struct file *file, 
bool snapshot)
mutex_init(>mutex);
 
/* Notify the tracer early; before we stop tracing. */
-   if (iter->trace && iter->trace->open)
+   if (iter->trace->open)
iter->trace->open(iter);
 
/* Annotate start of buffers if we had overruns */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] i2c: slave-eeprom: add eeprom simulator driver

[Wolfram Sang]

> this mail is thematically more a reply to patch 1 and maybe just serves
> my understanding of the slave support.

Sure. This shows how badly needed the documentation is :)

...
> > +   break;
> > +
> > +   case I2C_SLAVE_STOP:
> > +   eeprom->first_write = true;
> > +   break;
> > +
> > +   default:
> > +   break;
> > +   }
> > +
> > +   return 0;
> > +}
> This is the most interesting function here because it uses the new
> interface, the functions below are only to update and show the simulated
> eeprom contents and driver boilerplate, right?

Yes.

> When the eeprom driver is probed and the adapter driver notices a read
> request for the respective i2c address, this callback is called with
> event=I2C_SLAVE_REQ_READ_START. Returning 0 here and provide the first
> byte to send make the adapter ack the read request and send the data
> provided. If something != 0 is returned a NAK is sent?

We only send NAK on write requests (I use read/write from the master
perspective). Then, we have to say if the received byte was successfully
processed. When reading, the master has to ack the successful reception
of the byte.

> How is the next byte requested from the slave driver? I assume with two
> additional calls to the callback, first with
> event=I2C_SLAVE_REQ_READ_END, then event=I2C_SLAVE_REQ_READ_START once
> more. Would it make sense to reduce this to a single call? Does the
> driver at READ_END time already know if its write got acked? If so, how?

No single call. I had this first, but my experiments showed that it is
important for the EEPROM driver to only increase the internal pointer
when the byte was ACKed. Otherwise, I was off-by-one.

Ideally, I2C_SLAVE_REQ_READ_END should be used when the master ACKed the
byte, right. However, the rcar hardware doesn't have an interrupt for
this, so I imply that the start of a new read request ends the old one.
I probably should add a comment for that.

> This means that for each byte the callback is called. Would it make
> sense to make the API more flexible and allow the slave driver to return
> a buffer? This would remove some callback overhead and might allow to
> let the adapter driver make use of its DMA mechanism.

For DMA, I haven't seen DMA slave support yet. Makes sense to me, we
wouldn't know the transfer size, since the master can send a stop
anytime. This makes possible gains of using a buffer also speculative.
Also, I2C is still a low-bandwith bus, so usually we have a high number
of small transfers.

For now, I'd skip this idea. As I said in another thread, we need more
use cases. If the need arises, we can come up with something. I don't
think the current design prevents such an addition?

Thanks,

   Wolfram



signature.asc
Description: Digital signature

Re: [PATCH 2/3] i2c: slave-eeprom: add eeprom simulator driver

[Wolfram Sang]

Hi Uwe,

please don't quote so much :)

> > > + case I2C_SLAVE_REQ_READ_END:
> > > + eeprom->buffer_idx++;
> > You don't check here for buffer_idx >= ARRAY_SIZE(buffer)?
> > Ditto in the I2C_SLAVE_REQ_WRITE_END case.
> I just noticed that buffer_idx is an u8, so it overflows at 255+1. So
> the probe routine should error out if size is bigger than 256.

But size is currently fixed to 256, so all is fine. Yes, if we extend it
for bigger sizes, all that stuff needs to be taken care of, right.



signature.asc
Description: Digital signature

Re: [PATCH 2/3] i2c: slave-eeprom: add eeprom simulator driver

[Wolfram Sang]

Hi,

Please quote only relevant parts of the message (like I did). This
improves readability a lot.

> > +static int i2c_slave_eeprom_slave_cb(struct i2c_client *client,
> > +enum i2c_slave_event event, u8 *val)
> > +{
> > +   struct eeprom_data *eeprom = i2c_get_clientdata(client);
> > +
> > +   switch (event) {
> > +   case I2C_SLAVE_REQ_WRITE_END:
> > +   if (eeprom->first_write) {
> > +   eeprom->buffer_idx = *val;
> > +   eeprom->first_write = false;
> > +   } else {
> > +   spin_lock(>buffer_lock);
> > +   eeprom->buffer[eeprom->buffer_idx++] = *val;
> > +   spin_unlock(>buffer_lock);
> > +   }
> > +   break;
> > +
> > +   case I2C_SLAVE_REQ_READ_START:
> > +   spin_lock(>buffer_lock);
> > +   *val = eeprom->buffer[eeprom->buffer_idx];
> > +   spin_unlock(>buffer_lock);
> > +   break;
> > +
> > +   case I2C_SLAVE_REQ_READ_END:
> > +   eeprom->buffer_idx++;
> > +   break;
> > +
> > +   case I2C_SLAVE_STOP:
> > +   eeprom->first_write = true;
> > +   break;
> > +
> > +   default:
> > +   break;
> > +   }
> > +
> > +   return 0;
> > +}
> 
> 
> Would it make sense to have:
> WRITE_START
> WRITE_NEXT
> WRITE_STOP
> WRITE_REPEAT_START
> READ_START
> READ_NEXT
> READ_STOP
> READ_REPEAT_START
> 
> Some devices may want different behavior for subsequent
> reads when they are separate transactions, compared to
> a single larger transaction.

This can all be handled with I2C_SLAVE_STOP.

> e.g. a single transaction may wraparound inside a >8bit
> register (e.g. for 16bit: msb, lsb, msb, lsb, ...), but step
> to the next register when a separate read/write is issued.
> Alternatively, a WRITE/READ_NEXT may be implemented
> more efficiently. This may not matter for current systems
> compared to the low-frequency bus, but who knows what
> IoT devices may bring to the table.

Let's start simple until we have more use cases. WRITE_NEXT may be
useful when you have an internal u8 pointer to be set before actually
sending data, but already less useful if this is u16. Also, slaves may
decide to handle stops at unexpected places differently. Furthermore, my
feeling is that slave drivers will be more robust if they handle those
simple primitives properly.

What I could imagine, though, is that somewhen the eeprom simulator will
be able to get data via other means than the shared memory, maybe via
some callback. Then, the callback really only has to deal with "read
this byte" or "write that byte" while for the outer world we have a
proper well-known EEPROM like I2C interface.

That being said, the list of I2C_SLAVE_* events is extensible, of
course. Though, I rather see low-level stuff there like "General Call
Adress received".

> 
> Also, behavior may be different for repeat start versus
> stop/start, although a repeat start could be a start
> without a previous stop as well...

IMO a repeated start is to ensure that two messages arrive at the slave
without interruption from another master. I can't think why a slave
should know which type of start that was. In fact, if it does that would
raise an eyebrow for me. Do you have an example?

> Of course, if an I2C adapter cannot distinguish these
> events, this is probably a futile attempt at adding
> semantics that will silently break depending on the
> actual hardware/driver used.

That as well. I have not seen an I2C adapter which could provide this
information so far.

Thanks,

   Wolfram



signature.asc
Description: Digital signature

Re: [PATCH] platform: x86: dell-laptop: Add support for keyboard backlight

[Darren Hart]

On Wed, Nov 19, 2014 at 09:41:20PM +0100, Pali Rohár wrote:
> Hello,

Hi Pali,

> 
> I removed other lines so mail is not too long.
> 
> On Wednesday 19 November 2014 19:34:16 Darren Hart wrote:
...
> > > +}
> > > +
> > > +static unsigned int kbd_get_max_level(void)
> > > +{
> > > + if (kbd_info.levels != 0)
> > > + return kbd_info.levels;
> > 
> > This test does nothing? if it is 0, you still return 0
> > below :-)
> > 
> > > + if (kbd_mode_levels_count > 0)
> > > + return kbd_mode_levels_count - 1;
> > > + return 0;
> > 
> > So the function is:
> > 
> > return kbd_mode_levels_count > 0 ? kbd_mode_levels_count - 1 :
> > kbd_info.levels;
> > 
> > The if blocks are more legible, so that's fine, but the first
> > one doesn't seem to do anything and you can replace the final
> > return with return kbd_info.levels.
> > 
> 
> There are two main way for setting keyboard backlight level. One 
> is setting level register and other one is setting special 
> keyboard mode. And some dell laptops support only first and some 
> only second. So this code choose first available/valid method and 
> then return correct data. I'm not sure if those two methods are 
> only one and also do not know if in future there will be 
> something other. Because of this I use code pattern:
> 
> if (check_method_1) return value_method_1;
> if (check_method_2) return value_method_2;
> ...
> return unsupported;
> 
> Same pattern logic is used in all functions which doing something 
> with keyboard backlight level. (I will not other functions).

Fair enough. Clear, legible, consistent coding is preferable to a few micro
optimizations that the compiler is likely to catch anyway. I withdraw the
comment :-)

> 
> > > +static int kbd_set_state(struct kbd_state *state)
> > > +{
> > > + int ret;
> > > +
> > > + get_buffer();
> > > + buffer->input[0] = 0x2;
> > > + buffer->input[1] = BIT(state->mode_bit) & 0x;
> > > + buffer->input[1] |= (state->triggers & 0xFF) << 16;
> > > + buffer->input[1] |= (state->timeout_value & 0x3F) << 24;
> > > + buffer->input[1] |= (state->timeout_unit & 0x3) << 30;
> > > + buffer->input[2] = state->als_setting & 0xFF;
> > > + buffer->input[2] |= (state->level & 0xFF) << 16;
> > > + dell_send_request(buffer, 4, 11);
> > > + ret = buffer->output[0];
> > > + release_buffer();
> > > +
> > > + if (ret)
> > > + return -EINVAL;
> > 
> > Also, is EINVAL right here and elsewhere? Or did something
> > fail? EXIO?
> > 
> 
> According to Dell documentation, return value is stored in 
> buffer->output[0] and can be:
> 
> 0   Completed successfully
> -1  Completed with error
> -2  Function not supported
> 
> So we can return something other too (not always -EINVAL). Do you 
> have any idea which errno should we return for -1 and -2?

For -1, I should think  -EIO (I/O Error)
For -2, I'd expect -ENXIO (No such device or address)

Cc Rafael, Mika, linux-acpi in case they have a better idea.

> 
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int kbd_set_state_safe(struct kbd_state *state,
> > > struct kbd_state *old) +{
> > > + int ret;
> > > +
> > > + ret = kbd_set_state(state);
> > > + if (ret == 0)
> > > + return 0;
> > > +
> > > + if (kbd_set_state(old))
> > > + pr_err("Setting old previous keyboard state 
> failed\n");
> > 
> > And if we got an error and kbd_set_state(old) doesn't return
> > !0, what's the state of things? Still a failure a presume?
> > 
> 
> In some cases some laptops do not have to support everything. And 
> when I (and Gabriele too) tried to set something unsupported Dell 
> BIOS just resetted all settings to some default values. So this 
> function try to set new state and if it fails then it try to 
> restore previous settings.

OK, that deserves a comment then as the rationale isn't obvious.

> 
> > > +
> > > + return ret;
> > > +}
> 
> > > +static void kbd_init(void)
> > > +{
> > > + struct kbd_state state;
> > > + int ret;
> > > + int i;
> > > +
> > > + ret = kbd_get_info(_info);
> > > +
> > > + if (ret == 0) {
> > > +
> > 
> > Checking for success, let's invert and avoid the indentation
> > here too.
> > 
> 
> Again this is hard and not possible. This function first process 
> data from kbd_get_info (if does not fail), then process data for 
> kbd_tokens (via function find_token_id) and then set 
> kbd_led_present to true if at least kbd_get_info or kbd_tokens 
> succed.

The goal here is to avoid more than 3 levels of indentations for improved
legibility. Often there are logical inversions and such we can make to
accomplish this. When that fails, we break things up into functions, static
inlines, etc.

For reference:
https://lkml.org/lkml/2007/6/15/449

Which elaborates on CodingStyle Chapter 1: Indentation a bit.

...
> > > +static ssize_t kbd_led_timeout_store(struct device *dev,
> > > +  struct device_attribute *attr,
> > > +  const char *buf, size_t count)
> > > +{
> > > + struct 

Re: [PATCH 2/4] i2c: omap: implement workaround for handling invalid BB-bit values

[Wolfram Sang]

On Sat, Nov 22, 2014 at 05:06:10PM +0300, Alexander Kochetkov wrote:
> 
> 22 нояб. 2014 г., в 16:23, Wolfram Sang  написал(а):
> 
> > Huh, I can't apply this one? Which kernel version is this based on?
> 
> v.3.13-rc8

Wow, that's old. Can you please rebase the series on top of 3.18-rc4? Or
my i2c/for-next? Or at the very least 3.17?

@Felipe: With which kernel did you test the series? Also, 3.13?



signature.asc
Description: Digital signature

Re: [RFC] situation with csum_and_copy_... API

[Linus Torvalds]

On Fri, Nov 21, 2014 at 8:28 PM, Al Viro  wrote:
> OK, here's the next bunch.

Looks like good patches to me. Not that I actually _tested_ it, or
even have a good test-case (yeah, that "historical" ATM fix? I don't
think anybody cares ;), but it all seemed sane.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/5] x86, traps: Track entry into and exit from IST context

[Borislav Petkov]

On Fri, Nov 21, 2014 at 01:26:08PM -0800, Andy Lutomirski wrote:
> We currently pretend that IST context is like standard exception
> context, but this is incorrect.  IST entries from userspace are like
> standard exceptions except that they use per-cpu stacks, so they are
> atomic.  IST entries from kernel space are like NMIs from RCU's
> perspective -- they are not quiescent states even if they
> interrupted the kernel during a quiescent state.
> 
> Add and use ist_enter and ist_exit to track IST context.  Even
> though x86_32 has no IST stacks, we track these interrupts the same
> way.
> 
> This fixes two issues:
> 
>  - Scheduling from an IST interrupt handler will now warn.  It would
>previously appear to work as long as we got lucky and nothing
>overwrote the stack frame.  (I don't know of any bugs in this
>that would trigger the warning, but it's good to be on the safe
>side.)
> 
>  - RCU handling in IST context was dangerous.  As far as I know,
>only machine checks were likely to trigger this, but it's good to
>be on the safe side.
> 
> Note that the machine check handlers appears to have been missing
> any context tracking at all before this patch.
> 
> Cc: "Paul E. McKenney" 
> Cc: Josh Triplett 
> Cc: Frédéric Weisbecker 
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/include/asm/traps.h |  4 +++
>  arch/x86/kernel/cpu/mcheck/mce.c |  5 
>  arch/x86/kernel/cpu/mcheck/p5.c  |  6 +
>  arch/x86/kernel/cpu/mcheck/winchip.c |  5 
>  arch/x86/kernel/traps.c  | 49 
> ++--
>  5 files changed, 61 insertions(+), 8 deletions(-)

...

> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 0d0e922fafc1..f5c4b8813774 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -107,6 +107,39 @@ static inline void preempt_conditional_cli(struct 
> pt_regs *regs)
>   preempt_count_dec();
>  }
>  
> +enum ctx_state ist_enter(struct pt_regs *regs)
> +{
> + /*
> +  * We are atomic because we're on the IST stack (or we're on x86_32,
> +  * in which case we still shouldn't schedule.
> +  */
> + preempt_count_add(HARDIRQ_OFFSET);
> +
> + if (user_mode_vm(regs)) {
> + /* Other than that, we're just an exception. */
> + return exception_enter();
> + } else {
> + /*
> +  * We might have interrupted pretty much anything.  In
> +  * fact, if we're a machine check, we can even interrupt
> +  * NMI processing.  We don't want in_nmi() to return true,
> +  * but we need to notify RCU.
> +  */
> + rcu_nmi_enter();
> + return IN_KERNEL;  /* the value is irrelevant. */
> + }

I guess dropping the explicit else-branch could make it look a bit nicer
with the curly braces gone and all...

enum ctx_state ist_enter(struct pt_regs *regs)
{
/*
 * We are atomic because we're on the IST stack (or we're on x86_32,
 * in which case we still shouldn't schedule.
 */
preempt_count_add(HARDIRQ_OFFSET);

if (user_mode_vm(regs))
/* Other than that, we're just an exception. */
return exception_enter();

/*
 * We might have interrupted pretty much anything.  In fact, if we're a
 * machine check, we can even interrupt NMI processing.  We don't want
 * in_nmi() to return true, but we need to notify RCU.
 */
rcu_nmi_enter();
return IN_KERNEL;  /* the value is irrelevant. */
} 

> +}
> +
> +void ist_exit(struct pt_regs *regs, enum ctx_state prev_state)
> +{
> + preempt_count_sub(HARDIRQ_OFFSET);
> +
> + if (user_mode_vm(regs))
> + return exception_exit(prev_state);
> + else
> + rcu_nmi_exit();
> +}

Ditto here.

> +
>  static nokprobe_inline int
>  do_trap_no_signal(struct task_struct *tsk, int trapnr, char *str,
> struct pt_regs *regs, long error_code)

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH percpu/for-3.18-fixes] percpu-ref: fix DEAD flag contamination of percpu pointer

[Tejun Heo]

On Sat, Nov 22, 2014 at 09:04:48AM -0800, Shaohua Li wrote:
...
> > +   /*
> > +* Theoretically, the following could test just ATOMIC; however,
> > +* then we'd have to mask off DEAD separately as DEAD may be
> > +* visible without ATOMIC if we race with percpu_ref_kill().  DEAD
> > +* implies ATOMIC anyway.  Test them together.
> > +*/
> > +   if (unlikely(percpu_ptr & __PERCPU_REF_ATOMIC_DEAD))
> > return false;
> 
> this sounds not the correct answer. the DEAD/ATOMIC bit can be set by
> percpu_ref_kill() right after the check.

Yes, but that's why we're fetching @percpu_ptr with ACCESS_ONCE()
before checking the flags.

Thanks.

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

Re: [PATCH percpu/for-3.18-fixes] percpu-ref: fix DEAD flag contamination of percpu pointer

[Shaohua Li]

On Sat, Nov 22, 2014 at 09:22:42AM -0500, Tejun Heo wrote:
> While decoupling ATOMIC and DEAD flags, f47ad4578461 ("percpu_ref:
> decouple switching to percpu mode and reinit") updated
> __ref_is_percpu() so that it only tests ATOMIC flag to determine
> whether the ref is in percpu mode or not; however, while DEAD implies
> ATOMIC, the two flags are set separately during percpu_ref_kill() and
> if __ref_is_percpu() races percpu_ref_kill(), it may see DEAD w/o
> ATOMIC.  Because __ref_is_percpu() returns @ref->percpu_count_ptr
> value verbatim as the percpu pointer after testing ATOMIC, the pointer
> may now be contaminated with the DEAD flag.
> 
> This can be fixed by clearing the flag bits before returning the
> pointer which was the fix proposed by Shaohua; however, as DEAD
> implies ATOMIC, we can just test for both flags at once and avoid the
> explicit masking.
> 
> Update __ref_is_percpu() so that it tests that both ATOMIC and DEAD
> are clear before returning @ref->percpu_count_ptr as the percpu
> pointer.
> 
> Signed-off-by: Tejun Heo 
> Reported-by: Shaohua Li 
> Link: 
> http://lkml.kernel.org/r/995deb699f5b873c45d667df4add3b06f73c2c25.1416638887.git.s...@kernel.org
> Fixes: f47ad4578461 ("percpu_ref: decouple switching to percpu mode and 
> reinit")
> ---
> Hello, Shaohua.
> 
> That was a nasty one.  I think this fix is slightly better.  Can you
> please confirm that this fixes the issues you're seeing too?
> 
> Thanks.
> 
>  include/linux/percpu-refcount.h |8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
> index d5c89e0..51ce60c 100644
> --- a/include/linux/percpu-refcount.h
> +++ b/include/linux/percpu-refcount.h
> @@ -133,7 +133,13 @@ static inline bool __ref_is_percpu(struct percpu_ref 
> *ref,
>   /* paired with smp_store_release() in percpu_ref_reinit() */
>   smp_read_barrier_depends();
>  
> - if (unlikely(percpu_ptr & __PERCPU_REF_ATOMIC))
> + /*
> +  * Theoretically, the following could test just ATOMIC; however,
> +  * then we'd have to mask off DEAD separately as DEAD may be
> +  * visible without ATOMIC if we race with percpu_ref_kill().  DEAD
> +  * implies ATOMIC anyway.  Test them together.
> +  */
> + if (unlikely(percpu_ptr & __PERCPU_REF_ATOMIC_DEAD))
>   return false;

this sounds not the correct answer. the DEAD/ATOMIC bit can be set by
percpu_ref_kill() right after the check.

Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] can: eliminate banner[] variable and switch to pr_info()

[Marc Kleine-Budde]

On 11/22/2014 08:42 AM, Jeremiah Mahler wrote:
> Several CAN modules use a design pattern with a banner[] variable at the
> top which defines a string that is used once during init to print the
> banner.  The string is also embedded with KERN_INFO which makes it
> printk() specific.
> 
> Improve the code by eliminating the banner[] variable and moving the
> string to where it is printed.  Then switch from printk(KERN_INFO to
> pr_info() for the lines that were changed.

Applied to can-next.

Thanks,
Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Maarten Lankhorst]

Hey,

Op 22-11-14 om 01:19 schreef Michael Marineau:
> On Thu, Nov 20, 2014 at 12:53 AM, Maarten Lankhorst
>  wrote:
>> Op 20-11-14 om 05:06 schreef Michael Marineau:
>>> On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
>>>  wrote:
 Hey,

 On 19-11-14 07:43, Michael Marineau wrote:
> On 3.18-rc kernel's I have been intermittently experiencing GPU
> lockups shortly after startup, accompanied with one or both of the
> following errors:
>
> nouveau E[   PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
> from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
> nouveau E[ DRM] GPU lockup - switching to software fbcon
>
> I was able to trace the issue with bisect to commit
> 809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared
> fences for readable objects". The lockups appear to have cleared up
> since reverting that and a few related followup commits:
>
> 809e9447: "drm/nouveau: use shared fences for readable objects"
> 055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1"
> e3be4c23: "drm/nouveau: specify if interruptible wait is desired in
> nouveau_fence_sync"
> 15a996bb: "drm/nouveau: assign fence_chan->name correctly"
 Weird. I'm not sure yet what causes it.

 http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect=86be4f216bbb9ea3339843a5658d4c21162c7ee2
>>> Building a kernel from that commit gives me an entirely new behavior:
>>> X hangs for at least 10-20 seconds at a time with brief moments of
>>> responsiveness before hanging again while gitk on the kernel repo
>>> loads. Otherwise the system is responsive. The head of that
>>> fixed-fences-for-bisect branch (1c6aafb5) which is the "use shared
>>> fences for readable objects" commit I originally bisected to does
>>> feature the complete lockups I was seeing before.
>> Ok for the sake of argument lets just assume they're separate bugs, and we 
>> should look at xorg
>> hanging first.
>>
>> Is there anything in the dmesg when the hanging happens?
>>
>> And it's probably 15 seconds, if it's called through nouveau_fence_wait.
>>
>> Try changing else if (!ret) to else if (WARN_ON(!ret)) in that function, and 
>> see if you get some dmesg spam. :)
> Adding the WARN_ON to 86be4f21 repots the following:
>
> [ 1188.676073] [ cut here ]
> [ 1188.676161] WARNING: CPU: 1 PID: 474 at
> drivers/gpu/drm/nouveau/nouveau_fence.c:359
> nouveau_fence_wait.part.9+0x33/0x40 [nouveau]()
> [ 1188.676166] Modules linked in: rndis_host cdc_ether usbnet mii bnep
> ecb btusb bluetooth rfkill bridge stp llc hid_generic usb_storage
> joydev mousedev hid_apple usbhid bcm5974 nls_iso8859_1 nls_cp437 vfat
> fat nouveau snd_hda_codec_hdmi coretemp x86_pkg_temp_thermal
> intel_powerclamp kvm_intel kvm iTCO_wdt crct10dif_pclmul
> iTCO_vendor_support crc32c_intel evdev aesni_intel mac_hid aes_x86_64
> lrw glue_helper ablk_helper applesmc snd_hda_codec_cirrus cryptd
> input_polldev snd_hda_codec_generic mxm_wmi led_class wmi microcode
> hwmon snd_hda_intel ttm snd_hda_controller lpc_ich i2c_i801 mfd_core
> snd_hda_codec i2c_algo_bit snd_hwdep drm_kms_helper snd_pcm sbs drm
> apple_gmux i2ccore snd_timer snd agpgart mei_me soundcore sbshc mei
> video xhci_hcd usbcore usb_common apple_bl button battery ac efivars
> autofs4
> [ 1188.676300]  efivarfs
> [ 1188.676308] CPU: 1 PID: 474 Comm: Xorg Tainted: GW
> 3.17.0-rc2-nvtest+ #147
> [ 1188.676313] Hardware name: Apple Inc.
> MacBookPro11,3/Mac-2BD1B31983FE1663, BIOS
> MBP112.88Z.0138.B11.1408291503 08/29/2014
> [ 1188.676316]  0009 88045daebce8 814f0c09
> 
> [ 1188.676325]  88045daebd20 8104ea5d 88006a6c1468
> fff0
> [ 1188.676333]    88006a6c1000
> 88045daebd30
> [ 1188.676341] Call Trace:
> [ 1188.676356]  [] dump_stack+0x4d/0x66
> [ 1188.676369]  [] warn_slowpath_common+0x7d/0xa0
> [ 1188.676377]  [] warn_slowpath_null+0x1a/0x20
> [ 1188.676439]  []
> nouveau_fence_wait.part.9+0x33/0x40 [nouveau]
> [ 1188.676496]  [] nouveau_fence_wait+0x16/0x30 [nouveau]
> [ 1188.676552]  []
> nouveau_gem_ioctl_cpu_prep+0xef/0x1f0 [nouveau]
> [ 1188.676578]  [] drm_ioctl+0x1ec/0x660 [drm]
> [ 1188.676590]  [] ? _raw_spin_unlock_irqrestore+0x36/0x70
> [ 1188.676600]  [] ? trace_hardirqs_on+0xd/0x10
> [ 1188.676655]  [] nouveau_drm_ioctl+0x54/0xc0 [nouveau]
> [ 1188.676663]  [] do_vfs_ioctl+0x300/0x520
> [ 1188.676671]  [] ? sysret_check+0x22/0x5d
> [ 1188.676677]  [] SyS_ioctl+0x41/0x80
> [ 1188.676683]  [] system_call_fastpath+0x16/0x1b
> [ 1188.676688] ---[ end trace 6f7a510865b4674f ]---
>
> Here are the fence events that fired during that particular fence_wait:
> Xorg   474 [004]  1173.667645: fence:fence_wait_start:
> driver=nouveau timeline=Xorg[474] context=2 seqno=56910
> Xorg   474 [004]  1173.667647: fence:fence_enable_signal:
> 

Re: [PATCH v4 1/5] uprobes, x86: Fix _TIF_UPROBE vs _TIF_NOTIFY_RESUME

[Borislav Petkov]

On Fri, Nov 21, 2014 at 01:26:07PM -0800, Andy Lutomirski wrote:
> x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set
> but not on non-paranoid returns.  I suspect that this is a mistake
> and that the code only works because int3 is paranoid.
> 
> Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a
> workaround for the x86 bug.  With that bug fixed, we can remove
> _TIF_NOTIFY_RESUME from the uprobes code.
> 
> Acked-by: Srikar Dronamraju 
> Reported-by: Oleg Nesterov 
> Signed-off-by: Andy Lutomirski 

Acked-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] can: eliminate banner[] variable and switch to pr_info()

[Oliver Hartkopp]

On 22.11.2014 08:42, Jeremiah Mahler wrote:

Several CAN modules use a design pattern with a banner[] variable at the
top which defines a string that is used once during init to print the
banner.  The string is also embedded with KERN_INFO which makes it
printk() specific.

Improve the code by eliminating the banner[] variable and moving the
string to where it is printed.  Then switch from printk(KERN_INFO to
pr_info() for the lines that were changed.

Signed-off-by: Jeremiah Mahler 


Acked-by: Oliver Hartkopp 

Next time please only post on linux-can ML which is the first address for CAN 
related stuff - as long as you don't feel it's a networking relevant issue.


But for almost editorial changes - which is not urgent - linux-can should be 
enough.


Thanks,
Oliver



---
  net/can/af_can.c | 5 +
  net/can/bcm.c| 4 +---
  net/can/raw.c| 4 +---
  3 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/net/can/af_can.c b/net/can/af_can.c
index ce82337..ac05be1 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -64,9 +64,6 @@

  #include "af_can.h"

-static __initconst const char banner[] = KERN_INFO
-   "can: controller area network core (" CAN_VERSION_STRING ")\n";
-
  MODULE_DESCRIPTION("Controller Area Network PF_CAN core");
  MODULE_LICENSE("Dual BSD/GPL");
  MODULE_AUTHOR("Urs Thuermann , "
@@ -896,7 +893,7 @@ static __init int can_init(void)
 offsetof(struct can_frame, data) !=
 offsetof(struct canfd_frame, data));

-   printk(banner);
+   pr_info("can: controller area network core (" CAN_VERSION_STRING ")\n");

memset(_rx_alldev_list, 0, sizeof(can_rx_alldev_list));

diff --git a/net/can/bcm.c b/net/can/bcm.c
index dcb75c0..9aa3f76 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -78,8 +78,6 @@
 (CAN_SFF_MASK | CAN_EFF_FLAG | CAN_RTR_FLAG))

  #define CAN_BCM_VERSION CAN_VERSION
-static __initconst const char banner[] = KERN_INFO
-   "can: broadcast manager protocol (rev " CAN_BCM_VERSION " t)\n";

  MODULE_DESCRIPTION("PF_CAN broadcast manager protocol");
  MODULE_LICENSE("Dual BSD/GPL");
@@ -1615,7 +1613,7 @@ static int __init bcm_module_init(void)
  {
int err;

-   printk(banner);
+   pr_info("can: broadcast manager protocol (rev " CAN_BCM_VERSION " 
t)\n");

err = can_proto_register(_can_proto);
if (err < 0) {
diff --git a/net/can/raw.c b/net/can/raw.c
index 081e81f..e3250e2 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -56,8 +56,6 @@
  #include 

  #define CAN_RAW_VERSION CAN_VERSION
-static __initconst const char banner[] =
-   KERN_INFO "can: raw protocol (rev " CAN_RAW_VERSION ")\n";

  MODULE_DESCRIPTION("PF_CAN raw protocol");
  MODULE_LICENSE("Dual BSD/GPL");
@@ -810,7 +808,7 @@ static __init int raw_module_init(void)
  {
int err;

-   printk(banner);
+   pr_info("can: raw protocol (rev " CAN_RAW_VERSION ")\n");

err = can_proto_register(_can_proto);
if (err < 0)


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

[PATCH] remove asm-generic arch_bprm_mm_init()

[Dave Hansen]

From: Dave Hansen 

This is a follow-on to commit:

https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=x86/mpx=62e88b1c00de9cb30d937841ed5debed871070b8

I removed the asm-generic version of arch_unmap() in that patch,
but missed arch_bprm_mm_init().  So this broke the build for
architectures using asm-generic/mmu_context.h who actually have
an MMU.

This has been cross compiled for:
s390
arm
cris
microblaze

Signed-off-by: Dave Hansen 
Cc: linux-a...@vger.kernel.org
Cc: x...@kernel.org
Cc: Thomas Gleixner 

---

 b/include/asm-generic/mmu_context.h |5 -
 1 file changed, 5 deletions(-)

diff -puN include/asm-generic/mmu_context.h~remove-generic-arch_bprm_mm_init 
include/asm-generic/mmu_context.h
--- a/include/asm-generic/mmu_context.h~remove-generic-arch_bprm_mm_init
2014-11-20 14:39:38.191036388 -0800
+++ b/include/asm-generic/mmu_context.h 2014-11-20 14:39:38.194036524 -0800
@@ -42,9 +42,4 @@ static inline void activate_mm(struct mm
 {
 }
 
-static inline void arch_bprm_mm_init(struct mm_struct *mm,
-   struct vm_area_struct *vma)
-{
-}
-
 #endif /* __ASM_GENERIC_MMU_CONTEXT_H */
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Bls: May peace and grace never depart from your Home

[Mrs.Aaliyah H. Al-Ghrari]

My name is Mrs. Aaliyah H. Al-Ghrari, the surving widow of late mr Al-Ghrari, i 
have a charity/orphanage proposal for you, your social and financial status is 
an expection, please contact me on my private email if you are interested and i 
will send you complete details and procedure of the project

God bless you and your family.
Regards
Mrs. Aaliyah H. Al-Ghrari
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86/mce: Try printing all machine check banks known before panic

[Borislav Petkov]

On Sat, Nov 22, 2014 at 11:32:00PM +0800, rui wang wrote:
> But that means mcelog buffer will have to become circular, and we can
> only dump the last 32 errors. There must be a reason why it wasn't
> designed as circular.

Is there? Please do tell because I don't know the reason why.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] kvm: x86: move assigned-dev.c and iommu.c to arch/x86/

[Paolo Bonzini]

On 21/11/2014 22:21, Radim Krčmář wrote:
> Now that ia64 is gone, we can hide deprecated device assignment in x86.
> 
> Notable changes:
>  - kvm_vm_ioctl_assigned_device() was moved to x86/kvm_arch_vm_ioctl()
> 
> The easy parts were removed from generic kvm code, remaining
>  - kvm_iommu_(un)map_pages() would require new code to be moved
>  - struct kvm_assigned_dev_kernel depends on struct kvm_irq_ack_notifier

kvm_assign_device and kvm_deassign_device can also be moved to arch/x86,
in a new assigned-dev.h header.  The header could include struct
kvm_assigned_dev_kernel too but, if you change the argument of
kvm_assign_device and kvm_deassign_device to struct pci_dev, the struct
can move directly to assigned-dev.c and remain hidden there.

It's fine to do this as a follow up.

Thanks!

Paolo

> Signed-off-by: Radim Krčmář 
> ---
>  Or are we going to remove it instead? ;)
> 
>  arch/x86/include/asm/kvm_host.h   | 23 +++
>  arch/x86/kvm/Makefile |  2 +-
>  {virt => arch/x86}/kvm/assigned-dev.c |  0
>  {virt => arch/x86}/kvm/iommu.c|  0
>  arch/x86/kvm/x86.c|  2 +-
>  include/linux/kvm_host.h  | 26 --
>  virt/kvm/kvm_main.c   |  2 --
>  7 files changed, 25 insertions(+), 30 deletions(-)
>  rename {virt => arch/x86}/kvm/assigned-dev.c (100%)
>  rename {virt => arch/x86}/kvm/iommu.c (100%)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 76ff3e2..d549cf8 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1112,4 +1112,27 @@ int kvm_pmu_read_pmc(struct kvm_vcpu *vcpu, unsigned 
> pmc, u64 *data);
>  void kvm_handle_pmu_event(struct kvm_vcpu *vcpu);
>  void kvm_deliver_pmi(struct kvm_vcpu *vcpu);
>  
> +#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
> +int kvm_iommu_map_guest(struct kvm *kvm);
> +int kvm_iommu_unmap_guest(struct kvm *kvm);
> +
> +long kvm_vm_ioctl_assigned_device(struct kvm *kvm, unsigned ioctl,
> +   unsigned long arg);
> +
> +void kvm_free_all_assigned_devices(struct kvm *kvm);
> +#else
> +static inline int kvm_iommu_unmap_guest(struct kvm *kvm)
> +{
> + return 0;
> +}
> +
> +static inline long kvm_vm_ioctl_assigned_device(struct kvm *kvm, unsigned 
> ioctl,
> + unsigned long arg)
> +{
> + return -ENOTTY;
> +}
> +
> +static inline void kvm_free_all_assigned_devices(struct kvm *kvm) {}
> +#endif
> +
>  #endif /* _ASM_X86_KVM_HOST_H */
> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
> index ee1cd92..08f790d 100644
> --- a/arch/x86/kvm/Makefile
> +++ b/arch/x86/kvm/Makefile
> @@ -9,11 +9,11 @@ KVM := ../../../virt/kvm
>  
>  kvm-y+= $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o \
>   $(KVM)/eventfd.o $(KVM)/irqchip.o $(KVM)/vfio.o
> -kvm-$(CONFIG_KVM_DEVICE_ASSIGNMENT)  += $(KVM)/assigned-dev.o $(KVM)/iommu.o
>  kvm-$(CONFIG_KVM_ASYNC_PF)   += $(KVM)/async_pf.o
>  
>  kvm-y+= x86.o mmu.o emulate.o i8259.o irq.o lapic.o \
>  i8254.o ioapic.o irq_comm.o cpuid.o pmu.o
> +kvm-$(CONFIG_KVM_DEVICE_ASSIGNMENT)  += assigned-dev.o iommu.o
>  kvm-intel-y  += vmx.o
>  kvm-amd-y+= svm.o
>  
> diff --git a/virt/kvm/assigned-dev.c b/arch/x86/kvm/assigned-dev.c
> similarity index 100%
> rename from virt/kvm/assigned-dev.c
> rename to arch/x86/kvm/assigned-dev.c
> diff --git a/virt/kvm/iommu.c b/arch/x86/kvm/iommu.c
> similarity index 100%
> rename from virt/kvm/iommu.c
> rename to arch/x86/kvm/iommu.c
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 5337039..782e4ea 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -4007,7 +4007,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
>   }
>  
>   default:
> - ;
> + r = kvm_vm_ioctl_assigned_device(kvm, ioctl, arg);
>   }
>  out:
>   return r;
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index d2d4270..746e3ef 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -764,8 +764,6 @@ void kvm_free_irq_source_id(struct kvm *kvm, int 
> irq_source_id);
>  #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
>  int kvm_iommu_map_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
>  void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
> -int kvm_iommu_map_guest(struct kvm *kvm);
> -int kvm_iommu_unmap_guest(struct kvm *kvm);
>  int kvm_assign_device(struct kvm *kvm,
> struct kvm_assigned_dev_kernel *assigned_dev);
>  int kvm_deassign_device(struct kvm *kvm,
> @@ -781,11 +779,6 @@ static inline void kvm_iommu_unmap_pages(struct kvm *kvm,
>struct kvm_memory_slot *slot)
>  {
>  }
> -
> -static inline int kvm_iommu_unmap_guest(struct kvm *kvm)
> -{
> - return 0;
> -}
>  #endif
>  
>  static 

Re: [PATCH] Revert "staging: sm7xxfb: remove driver"

[Sudip Mukherjee]

On Sat, Nov 22, 2014 at 06:00:40AM -0800, Greg Kroah-Hartman wrote:
> On Sat, Nov 22, 2014 at 12:32:02PM +0530, Sudip Mukherjee wrote:
> > 2) most important - I do not have the hardware. So from the TODO list
> > dual head and 2D acceleration support will be tough without actually
> > checking on the hardware.
> 
> For a driver like this, if you don't have the hardware, I wouldn't
> recommend taking on the task of trying to fix it up and become the
> maintainer, sorry.
ofcourse. that is the reason i mentioned in my mail that i do not have the 
hardware.
I am trying to get a SM712 based display card.if i manage to get one i will 
mail you again.

thanks
sudip

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

Testing Only; Please Ignore

[Teo En Ming (Zhang Enming)]

Testing only, please ignore.

Many apologies for the inconvenience caused.

--
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore Citizen



Teo En Ming's 1st Communication to the United Nations Human Rights Council Dated 10 Oct 2014.pdf
Description: Adobe PDF document

Re: [PATCH] sony-laptop: add support for Sony Vaio Fit multi-flip laptop/presentation/tablet transformation

[Darren Hart]

On Thu, Nov 20, 2014 at 11:51:12AM +0300, Alexander Gavrilenko wrote:
> Current mode is exported via sysfs:
> /sys/devices/platform/sony-laptop/tablet
> 

Merging with your reply and a few updates from me, you OK with:

sony-laptop: Support Sony Vaio Fit multi-flip tablet transformations

Transformation events are sent through the ACPI bus as sony/hotkey
events. Tablet mode also triggers the SW_TABLET_MODE event via the
Sony Vaio Keys input device.

Current mode is exported via sysfs:
/sys/devices/platform/sony-laptop/tablet

It's important to keep the subject under 72 characters or so, or it
gets truncated for a lot of git users.

> Signed-off-by: Alexander Gavrilenko 
> ---
> --- linux-3.17.3/drivers/platform/x86/sony-laptop.c.orig  2014-11-19 
> 13:15:35.965048636 +0300
> +++ linux-3.17.3/drivers/platform/x86/sony-laptop.c   2014-11-19 
> 13:17:21.139166837 +0300
> @@ -135,6 +135,13 @@ MODULE_PARM_DESC(kbd_backlight_timeout,
>"meaningful values vary from 0 to 3 and their meaning depends "
>"on the model (default: no change from current value)");
>  
> +static int tablet_mode = 2;
> +module_param(tablet_mode, int, 0);
> +MODULE_PARM_DESC(tablet_mode,
> +  "set this if your laptop have different tablet mode value, "

s/have/has a/

Generally speaking module params requied for normal usage a frowned upon.

This looks like something we should be able to detect by the HID or at worst the
DMI strings. Maybe I'm missing something, why is this needed?

This particular driver has a few poor examples in place already, but let's not
extend that if we don't have to.

> +  "default is 2 (Sony Vaio Fit multi-flip), "
> +  "only affects SW_TABLET_MODE events");
> +
>  #ifdef CONFIG_PM_SLEEP
>  static void sony_nc_thermal_resume(void);
>  #endif
> @@ -181,6 +188,11 @@ static int sony_nc_touchpad_setup(struct
> unsigned int handle);
>  static void sony_nc_touchpad_cleanup(struct platform_device *pd);
>  
> +static int sony_nc_tablet_mode_setup(struct platform_device *pd,
> +   unsigned int handle);
> +static void sony_nc_tablet_mode_cleanup(struct platform_device *pd);
> +static int sony_nc_tablet_mode_update(void);
> +
>  enum sony_nc_rfkill {
>   SONY_WIFI,
>   SONY_BLUETOOTH,
> @@ -1198,7 +1210,8 @@ static int sony_nc_hotkeys_decode(u32 ev
>  enum event_types {
>   HOTKEY = 1,
>   KILLSWITCH,
> - GFX_SWITCH
> + GFX_SWITCH,
> + TABLET_MODE_SWITCH
>  };
>  static void sony_nc_notify(struct acpi_device *device, u32 event)
>  {
> @@ -1273,6 +1286,10 @@ static void sony_nc_notify(struct acpi_d
>   ev_type = GFX_SWITCH;
>   real_ev = __sony_nc_gfx_switch_status_get();
>   break;
> + case 0x016f:
> + ev_type = TABLET_MODE_SWITCH;
> + real_ev = sony_nc_tablet_mode_update();
> + break;
>   default:
>   dprintk("Unknown event 0x%x for handle 0x%x\n",
>   event, handle);
> @@ -1428,6 +1445,13 @@ static void sony_nc_function_setup(struc
>   pr_err("couldn't set up smart connect support 
> (%d)\n",
>   result);
>   break;
> + case 0x016f:
> + /* laptop/presentation/tablet transformation for Sony 
> Vaio Fit 11a/13a/14a/15a */

The comment can wrap to meet line length guidelines.

> + result = sony_nc_tablet_mode_setup(pf_device, handle);
> + if (result)
> + pr_err("couldn't set up tablet mode support 
> (%d)\n",
> + result);
> + break;
>   default:
>   continue;
>   }
> @@ -1507,6 +1531,9 @@ static void sony_nc_function_cleanup(str
>   case 0x0168:
>   sony_nc_smart_conn_cleanup(pd);
>   break;
> + case 0x016f:
> + sony_nc_tablet_mode_cleanup(pd);
> + break;
>   default:
>   continue;
>   }
> @@ -1547,6 +1574,12 @@ static void sony_nc_function_resume(void
>   case 0x0135:
>   sony_nc_rfkill_update();
>   break;
> + case 0x016f:
> + /* re-enable transformation events */
> + sony_call_snc_handle(handle, 0, );
> + 
> acpi_bus_generate_netlink_event(sony_nc_acpi_device->pnp.device_class,
> + dev_name(_nc_acpi_device->dev), 
> TABLET_MODE_SWITCH, sony_nc_tablet_mode_update());

Line length.

> + break;
>   default:
>  

Re: [PATCH 3/7] pinctrl: pinconf-generic: Allow driver to specify DT params

[Sören Brinkmann]

Hi Ivan,

On Fri, 2014-11-21 at 09:35AM +0200, Ivan T. Ivanov wrote:
> 
> On Thu, 2014-11-20 at 08:22 -0800, Sören Brinkmann wrote:
> > 
> > 
> > Also, I hope all my changes here don't break the current behavior. So,
> > those 27 driver should still be able to do what they currently do. But I
> > hope they could migrated over to use the generic bindings only in the
> > longer term, so that these custom properties disappear.
> > 
> > > > The pinctrl driver just assembles
> > > > some data structure that has the information regarding custom properties
> > > > and the core handles the rest.
> > > 
> > > Yup, that is nice. What will be really nice if it also handle custom,
> > > "function", "groups" and "pins" properties. Otherwise most of the drivers
> > > will not be able to benefit from this.
> > 
> > Why would you still need those? 
> 
> I don't need them :-). The point was that still majority of the drivers
> will have custom parsing functions. It would be nice if we could fix
> that too. I do understand that using custom "pins", "functions"... is
> something which is deprecated, but if core parsing functions allow
> passing custom strings for above purposes, in a similar way as your
> proposal, it will be easier for those drivers to migrate, I believe.

This does sound much more like a feature request than a fundamental
problem with the implementation, now. And like Laurent's feature
request, I'd like to turn this down. Otherwise this just gets hold up by
feature requests blocking pinctrl-zynq.
I think the interesting questions are:
1. Does it break any current user?
2. Is there anything fundamentally preventing adding your feature at
some later time as part of such a migration you describe?

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

Re: [PATCH] HID: usbhid: get/put around clearing needs_remote_wakeup

[Alan Stern]

On Sat, 22 Nov 2014, Alan Stern wrote:

> There is no USB wrapper for pm_runtime_idle calls, but one could be
> added.  Still, in the meantime can you check to see what happens if you
> add
> 
>   pm_runtime_idle(>intf->dev);
> 
> in usbhid_close() just after needs_remote_wakeup is set to 0?  You can 
> do the same thing in usbhid_stop() if you want.

Come to think of it, we probably need

pm_runtime_idle(usbhid->intf->dev->parent);

in addition to the function call above.  When a USB wrapper is written,
it can take care of these details.

Alan Stern

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

[PATCH 1/1] video: fbdev-LCDC: Deletion of an unnecessary check before the function call "vfree"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 22 Nov 2014 16:51:31 +0100

The vfree() function performs also input parameter validation.
Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/sh_mobile_lcdcfb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c 
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index 2bcc84a..cfde21d 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -2181,8 +2181,7 @@ sh_mobile_lcdc_channel_fb_cleanup(struct 
sh_mobile_lcdc_chan *ch)
if (!info || !info->device)
return;
 
-   if (ch->sglist)
-   vfree(ch->sglist);
+   vfree(ch->sglist);
 
fb_dealloc_cmap(>cmap);
framebuffer_release(info);
-- 
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/