Re: [PATCH v2] crypto: more robust crypto_memneq

[Daniel Borkmann]

On 11/25/2013 11:35 PM, Cesar Eduardo Barros wrote:

Disabling compiler optimizations can be fragile, since a new
optimization could be added to -O0 or -Os that breaks the assumptions
the code is making.

Instead of disabling compiler optimizations, use a dummy inline assembly
(based on RELOC_HIDE) to block the problematic kinds of optimization,
while still allowing other optimizations to be applied to the code.

The dummy inline assembly is added after every OR, and has the
accumulator variable as its input and output. The compiler is forced to
assume that the dummy inline assembly could both depend on the
accumulator variable and change the accumulator variable, so it is
forced to compute the value correctly before the inline assembly, and
cannot assume anything about its value after the inline assembly.

This change should be enough to make crypto_memneq work correctly (with
data-independent timing) even if it is inlined at its call sites. That
can be done later in a followup patch.

Compile-tested on x86_64.

Signed-off-by: Cesar Eduardo Barros 


Acked-by: Daniel Borkmann 

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

Re: [PATCH] sysfs: handle duplicate removal attempts in sysfs_remove_group()

[Gwendal Grignou]

Rafael,

As you pointed out, ata_tport_delete() should be after
scsi_remove_host(), consistent with ata_tport_add() currently before
ata_scsi_add_host().
Thanks for fixing it,

Gwendal.

On Mon, Nov 25, 2013 at 2:41 AM, Rafael J. Wysocki  wrote:
>
> On Monday, November 25, 2013 12:11:54 PM Mika Westerberg wrote:
> > On Sun, Nov 24, 2013 at 02:09:09AM +0100, Rafael J. Wysocki wrote:
> > > On Sunday, November 24, 2013 12:36:03 AM Rafael J. Wysocki wrote:
> > > > On Saturday, November 23, 2013 03:07:01 PM Greg Kroah-Hartman wrote:
> > > > > On Sun, Nov 24, 2013 at 12:12:59AM +0100, Rafael J. Wysocki wrote:
> > > > > > On Saturday, November 23, 2013 02:53:58 PM Greg Kroah-Hartman wrote:
> > >
> > > [...]
> > >
> > > > > > >
> > > > > > > I can revert Mika's patch, as it would be good to catch these 
> > > > > > > kinds of
> > > > > > > errors.
> > > > > >
> > > > > > Then we'll need to untangle the SATA/SCSI mess triggered by Bjorn in
> > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=65281. ;-)
> > > > >
> > > > > I have no objection to fixing that, the scsi sysfs handling is "odd" 
> > > > > to
> > > > > say the least...
> > > > >
> > > > > If someone can unwind it, that would be great to see happen...
> > > >
> > > > Well, if I'm bored to death during the xmas holidays, I may look into 
> > > > that.
> > >
> > > In fact, I'm not exactly sure why ata_port_detach() calls 
> > > ata_tport_delete()
> > > before scsi_remove_host()?  Is there any particular reason?  Because that
> > > doesn't seem to be exactly right ...
> >
> > I tried so that I have your 'PCI: Move device_del() from pci_stop_dev() to
> > pci_destroy_dev()' applied and then I did following change as you
> > suggested.
> >
> > diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> > index 81a94a3919db..07a03f93d640 100644
> > --- a/drivers/ata/libata-core.c
> > +++ b/drivers/ata/libata-core.c
> > @@ -6304,10 +6304,10 @@ static void ata_port_detach(struct ata_port *ap)
> >   for (i = 0; i < SATA_PMP_MAX_PORTS; i++)
> >   ata_tlink_delete(>pmp_link[i]);
> >   }
> > - ata_tport_delete(ap);
> > -
> >   /* remove the associated SCSI host */
> >   scsi_remove_host(ap->scsi_host);
> > +
> > + ata_tport_delete(ap);
> >  }
> >
> >  /**
> >
> > After both patches are applied the warnings are gone :) However, looks like
> > both are needed since if I only apply one or another, I still get warnings.
>
> Yes, they are both needed. :-)
>
> OK, I'll submit the above upstream if you don't mind.
>
> Cheers, R.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 7/9] mm: thrash detection-based file cache sizing

[Andrew Morton]

On Sun, 24 Nov 2013 18:38:26 -0500 Johannes Weiner  wrote:

> ...
>
> + *   Access frequency and refault distance
> + *
> + * A workload is trashing when its pages are frequently used but they
> + * are evicted from the inactive list every time before another access
> + * would have promoted them to the active list.
> + *
> + * In cases where the average access distance between thrashing pages
> + * is bigger than the size of memory there is nothing that can be
> + * done - the thrashing set could never fit into memory under any
> + * circumstance.
> + *
> + * However, the average access distance could be bigger than the
> + * inactive list, yet smaller than the size of memory.  In this case,
> + * the set could fit into memory if it weren't for the currently
> + * active pages - which may be used more, hopefully less frequently:
> + *
> + *  +-memory available to cache-+
> + *  |   |
> + *  +-inactive--+-active+
> + *  a b | c d e f g h i | J K L M N |
> + *  +---+---+

So making the inactive list smaller will worsen this problem?

If so, don't we have a conflict with this objective:

> Right now we have a fixed ratio (50:50) between inactive and active
> list but we already have complaints about working sets exceeding half
> of memory being pushed out of the cache by simple streaming in the
> background.  Ultimately, we want to adjust this ratio and allow for a
> much smaller inactive list.

?

> + * It is prohibitively expensive to accurately track access frequency
> + * of pages.  But a reasonable approximation can be made to measure
> + * thrashing on the inactive list, after which refaulting pages can be
> + * activated optimistically to compete with the existing active pages.
> + *
> + * Approximating inactive page access frequency - Observations:
> + *
> + * 1. When a page is accesed for the first time, it is added to the

"accessed"

> + *head of the inactive list, slides every existing inactive page
> + *towards the tail by one slot, and pushes the current tail page
> + *out of memory.
> + *
>
> ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/9] mm: keep page cache radix tree nodes in check

[Dave Chinner]

On Sun, Nov 24, 2013 at 06:38:28PM -0500, Johannes Weiner wrote:
> Previously, page cache radix tree nodes were freed after reclaim
> emptied out their page pointers.  But now reclaim stores shadow
> entries in their place, which are only reclaimed when the inodes
> themselves are reclaimed.  This is problematic for bigger files that
> are still in use after they have a significant amount of their cache
> reclaimed, without any of those pages actually refaulting.  The shadow
> entries will just sit there and waste memory.  In the worst case, the
> shadow entries will accumulate until the machine runs out of memory.
> 
> To get this under control, the VM will track radix tree nodes
> exclusively containing shadow entries on a per-NUMA node list.  A
> simple shrinker will reclaim these nodes on memory pressure.
> 
> A few things need to be stored in the radix tree node to implement the
> shadow node LRU and allow tree deletions coming from the list:
> 
> 1. There is no index available that would describe the reverse path
>from the node up to the tree root, which is needed to perform a
>deletion.  To solve this, encode in each node its offset inside the
>parent.  This can be stored in the unused upper bits of the same
>member that stores the node's height at no extra space cost.
> 
> 2. The number of shadow entries needs to be counted in addition to the
>regular entries, to quickly detect when the node is ready to go to
>the shadow node LRU list.  The current entry count is an unsigned
>int but the maximum number of entries is 64, so a shadow counter
>can easily be stored in the unused upper bits.
> 
> 3. Tree modification needs the lock, which is located in the address
>space, so store a backpointer to it.  The parent pointer is in a
>union with the 2-word rcu_head, so the backpointer comes at no
>extra cost as well.
> 
> 4. The node needs to be linked to an LRU list, which requires a list
>head inside the node.  This does increase the size of the node, but
>it does not change the number of objects that fit into a slab page.
> 
> Signed-off-by: Johannes Weiner 
> ---
>  fs/super.c|   4 +-
>  fs/xfs/xfs_buf.c  |   2 +-
>  fs/xfs/xfs_qm.c   |   2 +-
>  include/linux/list_lru.h  |   2 +-
>  include/linux/radix-tree.h|  30 +++---
>  include/linux/swap.h  |   1 +
>  include/linux/vm_event_item.h |   1 +
>  lib/radix-tree.c  |  36 +++-
>  mm/filemap.c  |  70 
>  mm/list_lru.c |   4 +-
>  mm/truncate.c |  19 ++-
>  mm/vmstat.c   |   2 +
>  mm/workingset.c   | 124 
> ++
>  13 files changed, 255 insertions(+), 42 deletions(-)
> 
> diff --git a/fs/super.c b/fs/super.c
> index 0225c20..a958d52 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -196,9 +196,9 @@ static struct super_block *alloc_super(struct 
> file_system_type *type, int flags)
>   INIT_HLIST_BL_HEAD(>s_anon);
>   INIT_LIST_HEAD(>s_inodes);
>  
> - if (list_lru_init(>s_dentry_lru))
> + if (list_lru_init(>s_dentry_lru, NULL))
>   goto err_out;
> - if (list_lru_init(>s_inode_lru))
> + if (list_lru_init(>s_inode_lru, NULL))
>   goto err_out_dentry_lru;

rather than modifying all the callers of list_lru_init(), can you
add a new function list_lru_init_key() and implement list_lru_init()
as a wrapper around it?

[snip radix tree modifications I didn't look at]

>  static int page_cache_tree_insert(struct address_space *mapping,
> struct page *page, void **shadowp)
>  {

> + radix_tree_replace_slot(slot, page);
> + if (node) {
> + node->count++;
> + /* Installed page, can't be shadow-only anymore */
> + if (!list_empty(>lru))
> + list_lru_del(_shadow_nodes, >lru);
> + }
> + return 0;

Hm - what's the overhead of direct management of LRU removal
here? Most list_lru code uses lazy removal (i.e. via the shrinker)
to avoid having to touch the LRU when adding new references to an
object.

> +
> +/*
> + * Page cache radix tree nodes containing only shadow entries can grow
> + * excessively on certain workloads.  That's why they are tracked on
> + * per-(NUMA)node lists and pushed back by a shrinker, but with a
> + * slightly higher threshold than regular shrinkers so we don't
> + * discard the entries too eagerly - after all, during light memory
> + * pressure is exactly when we need them.
> + *
> + * The list_lru lock nests inside the IRQ-safe mapping->tree_lock, so
> + * we have to disable IRQs for any list_lru operation as well.
> + */
> +
> +struct list_lru workingset_shadow_nodes;
> +
> +static unsigned long count_shadow_nodes(struct shrinker *shrinker,
> +   

Re: [PATCH] use -fstack-protector-strong

[Kees Cook]

On Mon, Nov 25, 2013 at 3:16 PM, H. Peter Anvin  wrote:
> On 11/25/2013 02:14 PM, Kees Cook wrote:
>> Build the kernel with -fstack-protector-strong when it is available
>> (gcc 4.9 and later). This increases the coverage of the stack protector
>> without the heavy performance hit of -fstack-protector-all.
>
> What is the difference between the various options?

-fstack-protector-all:
Adds the stack-canary saving prefix and stack-canary checking suffix
to _all_ function entry and exit. Results in substantial use of stack
space for saving the canary for deep stack users (e.g. historically
xfs), and measurable (though shockingly still low) performance hit due
to all the saving/checking. Really not suitable for sane systems, and
was entirely removed as an option from the kernel many years ago.

-fstack-protector:
Adds the canary save/check to functions that define an 8
(--param=ssp-buffer-size=N, N=8 by default) or more byte local char
array. Traditionally, stack overflows happened with string-based
manipulations, so this was a way to find those functions. Very few
total functions actually get the canary; no measurable performance or
size overhead.

-fstack-protector-strong
Adds the canary for a wider set of functions, since it's not just
those with strings that have ultimately been vulnerable to
stack-busting. With this superset, more functions end up with a
canary, but it still remains small compared to all functions with no
measurable change in performance. Based on the original design
document, a function gets the canary when it contains any of:
- local variable's address used as part of the RHS of an assignment or
function argument
- local variable is an array (or union containing an array),
regardless of array type or length
- uses register local variables
https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU

Chrome OS has been using -fstack-protector-strong for its kernel
builds for the last 8 months with no problems.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Setting stack NUMA policy?

[Andy Lutomirski]

On Mon, Nov 25, 2013 at 3:35 PM, Andy Lutomirski  wrote:
> I'm trying to arrange for a process to have a different memory policy
> on its stack as compared to everything else (e.g. mapped libraries).
> Before I start looking for kludges, is there any clean way to do this?
>
> So far, the best I can come up with is to either parse /proc/self/maps
> on startup or to deduce the stack range from the stack pointer and
> then call mbind.  Then, for added fun, I'll need to hook mmap so that
> I can mbind MAP_STACK vmas that are created for threads.
>
> This is awful.  Is there something better?
>
> (What I really want is a separate policy for MAP_SHARED vs MAP_PRIVATE.)

After a bit more thought, I think that what I *really* want is for the
stack for a thread that has affinity for a single NUMA node to
automatically end up on that node.  This seems like a straightforward
win if it's implementable.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series

[Doug Anderson]

Naveen,

On Mon, Nov 18, 2013 at 10:18 PM, Naveen Krishna Chatradhi
 wrote:
> For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
> on a fixed 66 MHz peripheral clock, and therefore is completely
> independent of the cpu frequency.
> Thus, registering for a CPU freq notifier is very wasteful.
>
> This patch modifes the code such that, i2c bus registers to
> cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.
>
> This change should save a bunch of cpufreq transitions calls
> which does not apply to exynos SoCs.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Acked-by: Kyungmin Park 
> Reviewed-by: Doug Anderson 
> ---
> Changes since v2:
> None, Rebased on for-next of linux-i2c git repo.
>
> Changes since v1:
> Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ & !CONFIG_EXYNOS)
> As commented by Tomasz
>
>  drivers/i2c/busses/i2c-s3c2410.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Can you please spin this with comments from
?  Thanks!

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] ACPICA: Linux: Cleanup wrong ACPICA inclusions.

[Rafael J. Wysocki]

On Saturday, November 23, 2013 07:27:27 AM Lv Zheng wrote:
> From: Lv Zheng 
> 
> The header file  is the top level header for other kernel
> subsystems to include.  It contains environemnt settings and architecture
> specific implementation that should be included before including other
> ACPICA headers in order to keep a consistent build environment for ACPICA
> users.  All following internal ACPICA header files thus should be included
> from  and not included by other kernel files:
>   
>   
>   
>   
>   
>   
>   
>   
>   : included by 
>   
>   
>   : included by 
>   : included by 
>   : included by 
>   
>   : included by 
> This patch cleans up inclusions of above files from non ACPICA source
> files.
> 
> Signed-off-by: Lv Zheng 

Applied with slightly modified subject/changelog.

Thanks!

> ---
>  drivers/acpi/nvs.c   |1 -
>  drivers/hwmon/asus_atk0110.c |1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/drivers/acpi/nvs.c b/drivers/acpi/nvs.c
> index 266bc58..386a9fe 100644
> --- a/drivers/acpi/nvs.c
> +++ b/drivers/acpi/nvs.c
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  /* ACPI NVS regions, APEI may use it */
>  
> diff --git a/drivers/hwmon/asus_atk0110.c b/drivers/hwmon/asus_atk0110.c
> index 1d7ff46..dafc63c 100644
> --- a/drivers/hwmon/asus_atk0110.c
> +++ b/drivers/hwmon/asus_atk0110.c
> @@ -18,7 +18,6 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  
> 
-- 
I speak only for myself.
Rafael J. Wysocki, 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: Request to add chromeos platform tree to -next

[Stephen Rothwell]

Hi Olof,

On Mon, 25 Nov 2013 11:41:16 -0800 Olof Johansson  wrote:
>
> I'm starting a git repo for the chromeos platform glue (x86 and ARM down
> the road, so far just x86 contents). Can you please add to linux-next?
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/olof/chrome-platform.git
> 
> Branch is for-next.

Added from today with just you as the contact.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
 * submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
 * posted to the relevant mailing list,
 * reviewed by you (or another maintainer of your subsystem tree),
 * successfully unit tested, and 
 * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
s...@canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.


pgpfhbU_dFNkv.pgp
Description: PGP signature

Re: [PATCH 2/2] rtc: add hym8563 rtc-driver

[Heiko Stübner]

Am Montag, 25. November 2013, 13:01:25 schrieb Mark Rutland:
> [...]
> 
> > +static int hym8563_probe(struct i2c_client *client,
> > +const struct i2c_device_id *id)
> > +{
> > +   struct hym8563 *hym8563;
> > +   int ret, gpio_int;
> > +
> > +   hym8563 = devm_kzalloc(>dev, sizeof(hym8563),
> > GFP_KERNEL); +   if (!hym8563)
> > +   return -ENOMEM;
> > +
> > +   hym8563->client = client;
> > +   i2c_set_clientdata(client, hym8563);
> > +
> > +   device_set_wakeup_capable(>dev, true);
> > +
> > +   gpio_int = of_get_gpio(client->dev.of_node, 0);
> > +   if (!gpio_is_valid(gpio_int)) {
> > +   dev_err(>dev, "failed to get interrupt gpio\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   ret = devm_gpio_request_one(>dev, gpio_int,
> > + GPIOF_DIR_IN, "hym8563_int");
> > +   if (ret) {
> > +   dev_err(>dev, "request of gpio %d failed, %d\n",
> > +   gpio_int, ret);
> > +   return ret;
> > +   }
> 
> From here on the gpio is never used or even stashed away anywhere.
> What's the point in requesting it and then leaking it?

As I understand it, requesting gpio also is useful as a mechanism to mark them 
as used and therefore prevent a gpio from wrongly being used multiple times.

So, I guess it would be better to either ignore client->irq and just use 
gpio_to_irq or use client->irq alone, without the gpio-functions at all.

But what would be preferrable?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9 v2] pci:msi: add weak function for returning msi region info

[Bjorn Helgaas]

On Tue, Nov 19, 2013 at 10:47:05AM +0530, Bharat Bhushan wrote:
> In Aperture type of IOMMU (like FSL PAMU), VFIO-iommu system need to know
> the MSI region to map its window in h/w. This patch just defines the
> required weak functions only and will be used by followup patches.
> 
> Signed-off-by: Bharat Bhushan 
> ---
> v1->v2
>  - Added description on "struct msi_region" 
> 
>  drivers/pci/msi.c   |   22 ++
>  include/linux/msi.h |   14 ++
>  2 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index d5f90d6..2643a29 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -67,6 +67,28 @@ int __weak arch_msi_check_device(struct pci_dev *dev, int 
> nvec, int type)
>   return chip->check_device(chip, dev, nvec, type);
>  }
>  
> +int __weak arch_msi_get_region_count(void)
> +{
> + return 0;
> +}
> +
> +int __weak arch_msi_get_region(int region_num, struct msi_region *region)
> +{
> + return 0;
> +}
> +
> +int msi_get_region_count(void)
> +{
> + return arch_msi_get_region_count();
> +}
> +EXPORT_SYMBOL(msi_get_region_count);
> +
> +int msi_get_region(int region_num, struct msi_region *region)
> +{
> + return arch_msi_get_region(region_num, region);
> +}
> +EXPORT_SYMBOL(msi_get_region);
> +
>  int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>  {
>   struct msi_desc *entry;
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index b17ead8..ade1480 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -51,6 +51,18 @@ struct msi_desc {
>  };
>  
>  /*
> + * This structure is used to get
> + * - physical address
> + * - size
> + * of a msi region
> + */
> +struct msi_region {
> + int region_num; /* MSI region number */
> + dma_addr_t addr; /* Address of MSI region */
> + size_t size; /* Size of MSI region */
> +};
> +
> +/*
>   * The arch hooks to setup up msi irqs. Those functions are
>   * implemented as weak symbols so that they /can/ be overriden by
>   * architecture specific code if needed.
> @@ -64,6 +76,8 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
>  
>  void default_teardown_msi_irqs(struct pci_dev *dev);
>  void default_restore_msi_irqs(struct pci_dev *dev, int irq);
> +int arch_msi_get_region_count(void);
> +int arch_msi_get_region(int region_num, struct msi_region *region);

It doesn't look like any of this (struct msi_region, msi_get_region(),
msi_get_region_count()) is actually used by drivers/pci/msi.c, so I don't
think it needs to be declared in generic code.  It looks like it's only
used in drivers/vfio/vfio_iommu_fsl_pamu.c, where you already know you have
an FSL IOMMU, and you can just call FSL-specific interfaces directly.

Bjorn

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

[PATCH v2] watchdog: s3c2410_wdt: Only register for cpufreq on ARM_S3C24XX_CPUFREQ

[Doug Anderson]

On modern SoCs the watchdog timer is parented on a clock that doesn't
change every time we have a cpufreq change.  That means we don't need
to constantly adjust the watchdog timer, so avoid registering for and
dealing with cpufreq transitions unless we've actually got
CONFIG_ARM_S3C24XX_CPUFREQ defined.

Note that this is more than just an optimization.  The s3c2410
watchdog driver actually pats the watchdog on every CPU frequency
change.  On modern systems these happen many times per second (even in
a system where "nothing" is happening).  That effectively makes any
userspace watchdog program useless (the watchdog is constantly patted
by the kernel).  If we need ARM_S3C24XX_CPUFREQ defined on a
multiplatform kernel we'll need to make sure that kernel supports
common clock and change this to user common clock framework.

Signed-off-by: Doug Anderson 
---
Changes in v2:
- Use the updated config name.

 drivers/watchdog/s3c2410_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..c1ada33 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param)
return IRQ_HANDLED;
 }
 
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_S3C24XX_CPUFREQ
 
 static int s3c2410wdt_cpufreq_transition(struct notifier_block *nb,
  unsigned long val, void *data)
-- 
1.8.4.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/

Setting stack NUMA policy?

[Andy Lutomirski]

I'm trying to arrange for a process to have a different memory policy
on its stack as compared to everything else (e.g. mapped libraries).
Before I start looking for kludges, is there any clean way to do this?

So far, the best I can come up with is to either parse /proc/self/maps
on startup or to deduce the stack range from the stack pointer and
then call mbind.  Then, for added fun, I'll need to hook mmap so that
I can mbind MAP_STACK vmas that are created for threads.

This is awful.  Is there something better?

(What I really want is a separate policy for MAP_SHARED vs MAP_PRIVATE.)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Tomasz Figa]

On Monday 25 of November 2013 15:28:29 Doug Anderson wrote:
> Guenter,
> 
> On Mon, Nov 25, 2013 at 3:23 PM, Guenter Roeck  wrote:
> > On 11/25/2013 02:55 PM, Doug Anderson wrote:
> >>
> >> On modern SoCs the watchdog timer is parented on a clock that doesn't
> >> change every time we have a cpufreq change.  That means we don't need
> >> to constantly adjust the watchdog timer, so avoid registering for and
> >> dealing with cpufreq transitions unless we've actually got
> >> CPU_FREQ_S3C24XX defined.
> >>
> >> Note that this is more than just an optimization.  The s3c2410
> >> watchdog driver actually pats the watchdog on every CPU frequency
> >> change.  On modern systems these happen many times per second (even in
> >> a system where "nothing" is happening).  That effectively makes any
> >> userspace watchdog program useless (the watchdog is constantly patted
> >> by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
> >> multiplatform kernel we'll need to make sure that kernel supports
> >> common clock and change this to user common clock framework.
> >>
> >> Signed-off-by: Doug Anderson 
> >> ---
> >>   drivers/watchdog/s3c2410_wdt.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/watchdog/s3c2410_wdt.c
> >> b/drivers/watchdog/s3c2410_wdt.c
> >> index 7d8fd04..4980f84 100644
> >> --- a/drivers/watchdog/s3c2410_wdt.c
> >> +++ b/drivers/watchdog/s3c2410_wdt.c
> >> @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void
> >> *param)
> >> return IRQ_HANDLED;
> >>   }
> >>
> >> -#ifdef CONFIG_CPU_FREQ
> >> +#ifdef CONFIG_CPU_FREQ_S3C24XX
> >>
> > Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it
> > in the current upstream kernel, so it appears that this depends on some
> > out-of-tree changes.
> 
> Whoops!  I guess I just trusted another patch and didn't dig.  I was
> basing this on https://patchwork.kernel.org/patch/3023421/
> 
> Ah, I see that Tomasz just found the answer.  I'll update my patch.

Seems like I originally gave you the wrong symbol name, looking at our
internal 3.10 tree, where the rename is not present yet, and nobody
noticed. Sorry for that.

Best regards,
Tomasz

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

Race in check_stack_guard_page?

[Andy Lutomirski]

I was looking at the stack expansion code, and I'm not convinced it's
safe.  Aside from the obvious scariness of down_read(_sem) not
actually preventing vma changes, I think there's a real race.  Suppose
that you have a VM_GROWSDOWN vma above a VM_GROWSUP vma with a
single-page gap between them.  Suppose further that they have
different anon_vma roots.

If one ends up in expand_downwards and the other ends up in
expand_upwards at the same time, then each one can take
page_table_lock without re-checking that there's still room to expand.
 The result will be two vmas that share a page.

(This is presumably only possible on ia64.)

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

Re: [PATCH v3 1/3] msi: free msi_desc entry only after we've released the kobject

[Greg Kroah-Hartman]

On Mon, Nov 25, 2013 at 04:12:48PM -0700, Bjorn Helgaas wrote:
> On Tue, Oct 29, 2013 at 11:30:30AM +0100, Veaceslav Falico wrote:
> > Currently, we first do kobject_put(>kobj) and the kfree(entry),
> > however kobject_put() doesn't guarantee us that it was the last reference
> > and that the kobj isn't used currently by someone else, so after we
> > kfree(entry) with the struct kobject - other users will begin using the
> > freed memory, instead of the actual kobject.
> > 
> > Fix this by using the kobject->release callback, which is called last when
> > the kobject is indeed not used and is cleaned up - it's msi_kobj_release(),
> > which can do the kfree(entry) safely (kobject_put/cleanup doesn't use the
> > kobj itself after ->release() was called, so we're safe).
> > 
> > In case we've failed to create the sysfs directories - just kfree()
> > it - cause we don't have the kobjects attached.
> > 
> > Also, remove the same functionality from populate_msi_sysfs(), cause on
> > failure we anyway call free_msi_irqs(), which will take care of all the
> > kobjects properly.
> > 
> > And add the forgotten pci_dev_put(pdev) in case of failure to register the
> > kobject in populate_msi_sysfs().
> > 
> > CC: Bjorn Helgaas 
> > CC: Neil Horman 
> > CC: Greg Kroah-Hartman 
> > CC: linux-...@vger.kernel.org
> > CC: linux-kernel@vger.kernel.org
> > Signed-off-by: Veaceslav Falico 
> 
> I'm still hoping that Greg (or somebody else; Greg already posted the bulk
> of the work) will finish up the conversion to attributes, and that Neil
> will confirm that works with no changes to irqbalance.  So I'm going to
> drop these patches for now.  Poke me if we need to revive them.

Ah, sorry about that.  I'll redo my series, dropping the existing format
and using the attribute-only code.  Give me a day or so, thanks for the
reminder.

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

Re: [PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Tomasz Figa]

On Monday 25 of November 2013 15:23:27 Guenter Roeck wrote:
> On 11/25/2013 02:55 PM, Doug Anderson wrote:
> > On modern SoCs the watchdog timer is parented on a clock that doesn't
> > change every time we have a cpufreq change.  That means we don't need
> > to constantly adjust the watchdog timer, so avoid registering for and
> > dealing with cpufreq transitions unless we've actually got
> > CPU_FREQ_S3C24XX defined.
> >
> > Note that this is more than just an optimization.  The s3c2410
> > watchdog driver actually pats the watchdog on every CPU frequency
> > change.  On modern systems these happen many times per second (even in
> > a system where "nothing" is happening).  That effectively makes any
> > userspace watchdog program useless (the watchdog is constantly patted
> > by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
> > multiplatform kernel we'll need to make sure that kernel supports
> > common clock and change this to user common clock framework.
> >
> > Signed-off-by: Doug Anderson 
> > ---
> >   drivers/watchdog/s3c2410_wdt.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> > index 7d8fd04..4980f84 100644
> > --- a/drivers/watchdog/s3c2410_wdt.c
> > +++ b/drivers/watchdog/s3c2410_wdt.c
> > @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void 
> > *param)
> > return IRQ_HANDLED;
> >   }
> >
> > -#ifdef CONFIG_CPU_FREQ
> > +#ifdef CONFIG_CPU_FREQ_S3C24XX
> >
> Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it
> in the current upstream kernel, so it appears that this depends on some
> out-of-tree changes.

Seems like it got renamed to ARM_S3C24XX_CPUFREQ by f023f8dd59.

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Doug Anderson]

Guenter,

On Mon, Nov 25, 2013 at 3:23 PM, Guenter Roeck  wrote:
> On 11/25/2013 02:55 PM, Doug Anderson wrote:
>>
>> On modern SoCs the watchdog timer is parented on a clock that doesn't
>> change every time we have a cpufreq change.  That means we don't need
>> to constantly adjust the watchdog timer, so avoid registering for and
>> dealing with cpufreq transitions unless we've actually got
>> CPU_FREQ_S3C24XX defined.
>>
>> Note that this is more than just an optimization.  The s3c2410
>> watchdog driver actually pats the watchdog on every CPU frequency
>> change.  On modern systems these happen many times per second (even in
>> a system where "nothing" is happening).  That effectively makes any
>> userspace watchdog program useless (the watchdog is constantly patted
>> by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
>> multiplatform kernel we'll need to make sure that kernel supports
>> common clock and change this to user common clock framework.
>>
>> Signed-off-by: Doug Anderson 
>> ---
>>   drivers/watchdog/s3c2410_wdt.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/watchdog/s3c2410_wdt.c
>> b/drivers/watchdog/s3c2410_wdt.c
>> index 7d8fd04..4980f84 100644
>> --- a/drivers/watchdog/s3c2410_wdt.c
>> +++ b/drivers/watchdog/s3c2410_wdt.c
>> @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void
>> *param)
>> return IRQ_HANDLED;
>>   }
>>
>> -#ifdef CONFIG_CPU_FREQ
>> +#ifdef CONFIG_CPU_FREQ_S3C24XX
>>
> Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it
> in the current upstream kernel, so it appears that this depends on some
> out-of-tree changes.

Whoops!  I guess I just trusted another patch and didn't dig.  I was
basing this on https://patchwork.kernel.org/patch/3023421/

Ah, I see that Tomasz just found the answer.  I'll update my patch.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST

[Richard Weinberger]

On Mon, Nov 25, 2013 at 7:36 AM, Shawn Landden  wrote:
> Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
> added an internal flag MSG_SENDPAGE_NOTLAST, similar to
> MSG_MORE.
>
> algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
> and need to see the new flag as identical to MSG_MORE.
>
> This fixes sendfile() on AF_ALG.
>
> v3: also fix udp
>
> Cc: Tom Herbert 
> Cc: Eric Dumazet 
> Cc: David S. Miller 
> Cc:  # 3.4.x + 3.2.x
> Reported-and-tested-by: Shawn Landden 
> Original-patch: Richard Weinberger 
> Signed-off-by: Shawn Landden 

May I ask why you took over the my patch without even CC'in me nor
replying to the original
thread "[PATCH] pipe_to_sendpage: Ensure that MSG_MORE is set if we
set MSG_SENDPAGE_NOTLAST"?
You are acting very rude.

The discussion at the original thread is not done.
Does skcipher_sendpage() really also need fixing? or UDP?
I didn't send another patch because I'm waiting for Eric's answer first.

Thanks,
//richard

> ---
>  crypto/algif_hash.c | 3 +++
>  crypto/algif_skcipher.c | 3 +++
>  net/ipv4/udp.c  | 3 +++
>  3 files changed, 9 insertions(+)
>
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index ef5356c..8502462 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -114,6 +114,9 @@ static ssize_t hash_sendpage(struct socket *sock, struct 
> page *page,
> struct hash_ctx *ctx = ask->private;
> int err;
>
> +   if (flags & MSG_SENDPAGE_NOTLAST)
> +   flags |= MSG_MORE;
> +
> lock_sock(sk);
> sg_init_table(ctx->sgl.sg, 1);
> sg_set_page(ctx->sgl.sg, page, size, offset);
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index 6a6dfc0..a19c027 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -378,6 +378,9 @@ static ssize_t skcipher_sendpage(struct socket *sock, 
> struct page *page,
> struct skcipher_sg_list *sgl;
> int err = -EINVAL;
>
> +   if (flags & MSG_SENDPAGE_NOTLAST)
> +   flags |= MSG_MORE;
> +
> lock_sock(sk);
> if (!ctx->more && ctx->used)
> goto unlock;
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 5944d7d..8bd04df 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1098,6 +1098,9 @@ int udp_sendpage(struct sock *sk, struct page *page, 
> int offset,
> struct udp_sock *up = udp_sk(sk);
> int ret;
>
> +   if (flags & MSG_SENDPAGE_NOTLAST)
> +   flags |= MSG_MORE;
> +
> if (!up->pending) {
> struct msghdr msg = {   .msg_flags = flags|MSG_MORE };
>
> --
> 1.8.4.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



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

RE: [PATCH] ARM: dts: Add max77686 RTC interrupt to cros5250-common

[Kukjin Kim]

Olof Johansson wrote:
> 
> On Mon, Nov 25, 2013 at 3:11 PM, Doug Anderson 
> wrote:
> > Olof or Kukjin,
> >
> > On Wed, Oct 23, 2013 at 6:11 AM, Doug Anderson 
> wrote:
> >> Without the interrupt you'll get problems if you enable
> >> CONFIG_RTC_DRV_MAX77686.  Setup the interrupt properly in the device
> >> tree.
> >>
> >> Signed-off-by: Doug Anderson 
> >> ---
> >>  arch/arm/boot/dts/cros5250-common.dtsi | 12 
> >>  1 file changed, 12 insertions(+)
> >
> > Would one of you be interested in applying this to your tree, with
> > Marc's "Tested-by"?  I know there are lots more things to fixup in the
> > dts, but this is one that I know works.  ;)
> 
> Yes, I'll apply this to fixes for 3.13, and mark it for stable 3.12 at
> least.
> 
Olof, thanks.

Please add my ack on this if you want.

- Kukjin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3 v3] mips: remove panic_timeout settings

[Jason Baron]

From: Ralf Baechle 

Now that we have a CONFIG_PANIC_TIMEOUT=x setting, remove the mips settings. The
default is 0, which means don't reboot on panic.

Signed-off-by: Ralf Baechle 
Acked-by: Shinya Kuribayashi 
Signed-off-by: Jason Baron 
---
 arch/mips/ar7/setup.c   | 1 -
 arch/mips/emma/markeins/setup.c | 3 ---
 arch/mips/netlogic/xlp/setup.c  | 1 -
 arch/mips/netlogic/xlr/setup.c  | 1 -
 arch/mips/sibyte/swarm/setup.c  | 2 --
 5 files changed, 8 deletions(-)

diff --git a/arch/mips/ar7/setup.c b/arch/mips/ar7/setup.c
index 9a357ff..820b7a3 100644
--- a/arch/mips/ar7/setup.c
+++ b/arch/mips/ar7/setup.c
@@ -92,7 +92,6 @@ void __init plat_mem_setup(void)
_machine_restart = ar7_machine_restart;
_machine_halt = ar7_machine_halt;
pm_power_off = ar7_machine_power_off;
-   panic_timeout = 3;
 
io_base = (unsigned long)ioremap(AR7_REGS_BASE, 0x1);
if (!io_base)
diff --git a/arch/mips/emma/markeins/setup.c b/arch/mips/emma/markeins/setup.c
index d710058..9100122 100644
--- a/arch/mips/emma/markeins/setup.c
+++ b/arch/mips/emma/markeins/setup.c
@@ -111,9 +111,6 @@ void __init plat_mem_setup(void)
iomem_resource.start = EMMA2RH_IO_BASE;
iomem_resource.end = EMMA2RH_ROM_BASE - 1;
 
-   /* Reboot on panic */
-   panic_timeout = 180;
-
markeins_sio_setup();
 }
 
diff --git a/arch/mips/netlogic/xlp/setup.c b/arch/mips/netlogic/xlp/setup.c
index 6d981bb..54e75c7 100644
--- a/arch/mips/netlogic/xlp/setup.c
+++ b/arch/mips/netlogic/xlp/setup.c
@@ -92,7 +92,6 @@ static void __init xlp_init_mem_from_bars(void)
 
 void __init plat_mem_setup(void)
 {
-   panic_timeout   = 5;
_machine_restart = (void (*)(char *))nlm_linux_exit;
_machine_halt   = nlm_linux_exit;
pm_power_off= nlm_linux_exit;
diff --git a/arch/mips/netlogic/xlr/setup.c b/arch/mips/netlogic/xlr/setup.c
index 214d123..921be5f 100644
--- a/arch/mips/netlogic/xlr/setup.c
+++ b/arch/mips/netlogic/xlr/setup.c
@@ -92,7 +92,6 @@ static void nlm_linux_exit(void)
 
 void __init plat_mem_setup(void)
 {
-   panic_timeout   = 5;
_machine_restart = (void (*)(char *))nlm_linux_exit;
_machine_halt   = nlm_linux_exit;
pm_power_off= nlm_linux_exit;
diff --git a/arch/mips/sibyte/swarm/setup.c b/arch/mips/sibyte/swarm/setup.c
index 41707a2..3462c83 100644
--- a/arch/mips/sibyte/swarm/setup.c
+++ b/arch/mips/sibyte/swarm/setup.c
@@ -134,8 +134,6 @@ void __init plat_mem_setup(void)
 #error invalid SiByte board configuration
 #endif
 
-   panic_timeout = 5;  /* For debug.  */
-
board_be_handler = swarm_be_handler;
 
if (xicor_probe())
-- 
1.8.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 3/3 v3] powerpc: cleanup panic_timeout

[Jason Baron]

Default CONFIG_PANIC_TIMEOUT to 180 seconds on powerpc. The pSeries continue
to set the timeout to 10 seconds at run-time. Thus, there's a small window
where we don't have the correct value on pSeries, but if this is only run-time
discoverable we don't have a better option. In any case, if the user changes
the default setting of 180 seconds, we honor that user setting.

Signed-off-by: Jason Baron 
---
 arch/powerpc/Kconfig   | 4 
 arch/powerpc/include/asm/setup.h   | 1 +
 arch/powerpc/kernel/setup_32.c | 3 ---
 arch/powerpc/kernel/setup_64.c | 3 ---
 arch/powerpc/platforms/pseries/setup.c | 2 +-
 5 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b44b52c..b2be8e8 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -147,6 +147,10 @@ config EARLY_PRINTK
bool
default y
 
+config PANIC_TIMEOUT
+   int
+   default 180
+
 config COMPAT
bool
default y if PPC64
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 703a841..11ba86e 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -26,6 +26,7 @@ extern void reloc_got2(unsigned long);
 void check_for_initrd(void);
 void do_init_bootmem(void);
 void setup_panic(void);
+#define ARCH_PANIC_TIMEOUT 180
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index b903dc5..2b0da27 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -296,9 +296,6 @@ void __init setup_arch(char **cmdline_p)
if (cpu_has_feature(CPU_FTR_UNIFIED_ID_CACHE))
ucache_bsize = icache_bsize = dcache_bsize;
 
-   /* reboot on panic */
-   panic_timeout = 180;
-
if (ppc_md.panic)
setup_panic();
 
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4085aaa..856dd4e 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -588,9 +588,6 @@ void __init setup_arch(char **cmdline_p)
dcache_bsize = ppc64_caches.dline_size;
icache_bsize = ppc64_caches.iline_size;
 
-   /* reboot on panic */
-   panic_timeout = 180;
-
if (ppc_md.panic)
setup_panic();
 
diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index c1f1908..6f76ae4 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -470,7 +470,7 @@ static long pseries_little_endian_exceptions(void)
 
 static void __init pSeries_setup_arch(void)
 {
-   panic_timeout = 10;
+   set_arch_panic_timeout(10, ARCH_PANIC_TIMEOUT);
 
/* Discover PIC type and setup ppc_md accordingly */
pseries_discover_pic();
-- 
1.8.2

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

Re: [PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Guenter Roeck]

On 11/25/2013 02:55 PM, Doug Anderson wrote:

On modern SoCs the watchdog timer is parented on a clock that doesn't
change every time we have a cpufreq change.  That means we don't need
to constantly adjust the watchdog timer, so avoid registering for and
dealing with cpufreq transitions unless we've actually got
CPU_FREQ_S3C24XX defined.

Note that this is more than just an optimization.  The s3c2410
watchdog driver actually pats the watchdog on every CPU frequency
change.  On modern systems these happen many times per second (even in
a system where "nothing" is happening).  That effectively makes any
userspace watchdog program useless (the watchdog is constantly patted
by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
multiplatform kernel we'll need to make sure that kernel supports
common clock and change this to user common clock framework.

Signed-off-by: Doug Anderson 
---
  drivers/watchdog/s3c2410_wdt.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..4980f84 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param)
return IRQ_HANDLED;
  }

-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_CPU_FREQ_S3C24XX


Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it
in the current upstream kernel, so it appears that this depends on some
out-of-tree changes.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3 v3] panic: Make panic_timeout configurable

[Jason Baron]

The panic_timeout value can be set via the command line option 'panic=x', or via
/proc/sys/kernel/panic, however that is not sufficient when the panic occurs
before we are able to set up these values. Thus, add a CONFIG_PANIC_TIMEOUT
so that we can set the desired value from the .config.

The default panic_timeout value continues to be 0 - wait forever. Also adds
set_arch_panic_timeout(new_timeout, arch_default_timeout), which is intended
to be used by arches in arch_setup(). The idea being that the new_timeout
is only set if the user hasn't changed from the arch_default_timeout.

Signed-off-by: Jason Baron 
---
 include/linux/kernel.h | 9 +
 kernel/panic.c | 2 +-
 lib/Kconfig.debug  | 9 +
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d4e98d1..2ac0277 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -393,6 +393,15 @@ extern int panic_on_oops;
 extern int panic_on_unrecovered_nmi;
 extern int panic_on_io_nmi;
 extern int sysctl_panic_on_stackoverflow;
+/*
+ * Only to be used by arch init code. If the user over-wrote the default
+ * CONFIG_PANIC_TIMEOUT, honor it.
+ */
+static inline void set_arch_panic_timeout(int timeout, int 
arch_default_timeout)
+{
+   if (panic_timeout == arch_default_timeout)
+   panic_timeout = timeout;
+}
 extern const char *print_tainted(void);
 enum lockdep_ok {
LOCKDEP_STILL_OK,
diff --git a/kernel/panic.c b/kernel/panic.c
index c00b4ce..6d63003 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -33,7 +33,7 @@ static int pause_on_oops;
 static int pause_on_oops_flag;
 static DEFINE_SPINLOCK(pause_on_oops_lock);
 
-int panic_timeout;
+int panic_timeout = CONFIG_PANIC_TIMEOUT;
 EXPORT_SYMBOL_GPL(panic_timeout);
 
 ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index db25707..6982094 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -761,6 +761,15 @@ config PANIC_ON_OOPS_VALUE
default 0 if !PANIC_ON_OOPS
default 1 if PANIC_ON_OOPS
 
+config PANIC_TIMEOUT
+   int "panic timeout"
+   default 0
+   help
+ Set the timeout value (in seconds) until a reboot occurs when the
+ the kernel panics. If n = 0, then we wait forever. A timeout
+ value n > 0 will wait n seconds before rebooting, while a timeout
+ value n < 0 will reboot immediately.
+
 config SCHED_DEBUG
bool "Collect scheduler debugging info"
depends on DEBUG_KERNEL && PROC_FS
-- 
1.8.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 0/3 v3] build in panic_timeout value

[Jason Baron]

Hi,

I've now separated out the arch bits into separate patches. Hopefully, it makes
review easier. I also didn't address moving the 'panic_timeout' command-line
parameter up as an 'early_param()'. I think it might make sense to move it up,
especially for distro kernels, but its not a need here, so I didn't want to just
shove it in. If needed, I think it can come in separately, as it shoudn't
affect this series.

Thanks,

-Jason 


v3:
 -separate arch bits
 -drop mips settings of panic_timeout as per Ralf Baechle

v2:
 -restrict arch defaults to arch/ code
 -add set_arch_panic_timeout(), in case .config specifies a non-default timeout

Jason Baron (2):
  panic: Make panic_timeout configurable
  powerpc: cleanup panic_timeout

Ralf Baechle (1):
  mips: remove panic_timeout settings.

 arch/mips/ar7/setup.c  | 1 -
 arch/mips/emma/markeins/setup.c| 3 ---
 arch/mips/netlogic/xlp/setup.c | 1 -
 arch/mips/netlogic/xlr/setup.c | 1 -
 arch/mips/sibyte/swarm/setup.c | 2 --
 arch/powerpc/Kconfig   | 4 
 arch/powerpc/include/asm/setup.h   | 1 +
 arch/powerpc/kernel/setup_32.c | 3 ---
 arch/powerpc/kernel/setup_64.c | 3 ---
 arch/powerpc/platforms/pseries/setup.c | 2 +-
 include/linux/kernel.h | 9 +
 kernel/panic.c | 2 +-
 lib/Kconfig.debug  | 9 +
 13 files changed, 25 insertions(+), 16 deletions(-)

-- 
1.8.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] mips: Fix build error seen in some configurations

[Guenter Roeck]

The following build error is seen if CONFIG_32BIT is undefined,
CONFIG_64BIT is defined, and CONFIG_MIPS32_O32 is undefined.

asm/syscall.h: In function 'mips_get_syscall_arg':
arch/mips/include/asm/syscall.h:32:16: error: unused variable 'usp' 
[-Werror=unused-variable]
cc1: all warnings being treated as errors

Fixes: c0ff3c53d4f9 ('MIPS: Enable HAVE_ARCH_TRACEHOOK')
Signed-off-by: Guenter Roeck 
---
 arch/mips/include/asm/syscall.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/syscall.h b/arch/mips/include/asm/syscall.h
index 81c8913..33e8dbf 100644
--- a/arch/mips/include/asm/syscall.h
+++ b/arch/mips/include/asm/syscall.h
@@ -29,7 +29,7 @@ static inline long syscall_get_nr(struct task_struct *task,
 static inline unsigned long mips_get_syscall_arg(unsigned long *arg,
struct task_struct *task, struct pt_regs *regs, unsigned int n)
 {
-   unsigned long usp = regs->regs[29];
+   unsigned long usp __maybe_unused = regs->regs[29];
 
switch (n) {
case 0: case 1: case 2: case 3:
-- 
1.7.9.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] mm + fs: store shadow entries in page cache

[Dave Chinner]

On Sun, Nov 24, 2013 at 06:38:25PM -0500, Johannes Weiner wrote:
> Reclaim will be leaving shadow entries in the page cache radix tree
> upon evicting the real page.  As those pages are found from the LRU,
> an iput() can lead to the inode being freed concurrently.  At this
> point, reclaim must no longer install shadow pages because the inode
> freeing code needs to ensure the page tree is really empty.
> 
> Add an address_space flag, AS_EXITING, that the inode freeing code
> sets under the tree lock before doing the final truncate.  Reclaim
> will check for this flag before installing shadow pages.
> 
> Signed-off-by: Johannes Weiner 

> @@ -545,10 +546,25 @@ static void evict(struct inode *inode)
>*/
>   inode_wait_for_writeback(inode);
>  
> + /*
> +  * Page reclaim can not do iput() and thus can race with the
> +  * inode teardown.  Tell it when the address space is exiting,
> +  * so that it does not install eviction information after the
> +  * final truncate has begun.
> +  *
> +  * As truncation uses a lockless tree lookup, acquire the
> +  * spinlock to make sure any ongoing tree modification that
> +  * does not see AS_EXITING is completed before starting the
> +  * final truncate.
> +  */
> + spin_lock_irq(>i_data.tree_lock);
> + mapping_set_exiting(>i_data);
> + spin_unlock_irq(>i_data.tree_lock);
> +
>   if (op->evict_inode) {
>   op->evict_inode(inode);
>   } else {
> - if (inode->i_data.nrpages)
> + if (inode->i_data.nrpages || inode->i_data.nrshadows)
>   truncate_inode_pages(>i_data, 0);
>   clear_inode(inode);
>   }

Ok, so what I see here is that we need a wrapper function that
handles setting the AS_EXITING flag and doing the "final"
truncate_inode_pages() call, and the locking for the AS_EXITING flag
moved into mapping_set_exiting()

That is, because this AS_EXITING flag and it's locking constraints
are directly related to the upcoming truncate_inode_pages() call,
I'd prefer to see a helper that captures that relationship used
in all the filesystem code. e.g:

void truncate_inode_pages_final(struct address_space *mapping)
{
spin_lock_irq(>tree_lock);
mapping_set_exiting(mapping);
spin_unlock_irq(>tree_lock);
if (inode->i_data.nrpages || inode->i_data.nrshadows)
truncate_inode_pages_range(mapping, 0, (loff_t)-1);
}

And document it in Documentation/filesystems/porting as a mandatory
function to be called from ->evict_inode() implementations before
calling clear_inode().  You can then replace all the direct calls to
truncate_inode_pages() in the evict_inode() path with a call to
truncate_inode_pages_final().

As it is, I'd really like to see that unconditional irq disable go
away from this code - disabling and enabling interrupts for every
single inode we reclaim is going to add significant overhead to this
hot code path. And given that:

> +static inline void mapping_set_exiting(struct address_space *mapping)
> +{
> + set_bit(AS_EXITING, >flags);
> +}
> +
> +static inline int mapping_exiting(struct address_space *mapping)
> +{
> + return test_bit(AS_EXITING, >flags);
> +}

these atomic bit ops, why do we need to take the tree_lock and
disable irqs in evict() to set this bit if there's nothing to
truncate on the inode? i.e. something like this:

void truncate_inode_pages_final(struct address_space *mapping)
{
mapping_set_exiting(mapping);
if (inode->i_data.nrpages || inode->i_data.nrshadows) {
/*
 * spinlock barrier to ensure all modifications are
 * complete before we do the final truncate
 */
spin_lock_irq(>tree_lock);
spin_unlock_irq(>tree_lock);
truncate_inode_pages_range(mapping, 0, (loff_t)-1);
}

and thereby avoiding the mapping lock altogether for inodes that do
not require it to be taken?

Cheers,

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

Re: [PATCH] use -fstack-protector-strong

[H. Peter Anvin]

On 11/25/2013 02:14 PM, Kees Cook wrote:
> Build the kernel with -fstack-protector-strong when it is available
> (gcc 4.9 and later). This increases the coverage of the stack protector
> without the heavy performance hit of -fstack-protector-all.

What is the difference between the various options?

-hpa


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

Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate

[Rafael J. Wysocki]

On Monday, November 25, 2013 07:41:41 PM Viresh Kumar wrote:
> 
> This patch adds cpufreq callbacks to dpm_{suspend|resume}() for handling
> suspend/resume of cpufreq governors. This is required for early suspend and
> late resume of governors and cpufreq core.
> 
> There are multiple problems that are fixed by this patch:
> - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His 
> board 
>   wasn't working well with suspend/resume as calls for removing non-boot CPUs
>   was turning out into a call to drivers ->target() which then tries to play
>   with regulators. But regulators and their I2C bus were already suspended and
>   this resulted in a failure. Many platforms have such problems, samsung,
>   tegra, etc.. They solved it with driver specific PM notifiers where they
>   used to disable their driver's ->target() routine.
> 
> - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
> 
>   tunables configuration for clusters/sockets with non-boot CPUs was getting
>   lost after suspend/resume, as we were notifying governors with
>   CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
>   deallocating memory for tunables. This is also fixed with this patch as 
> don't
>   allow any operation on Governors during suspend/resume now.
> 
> Reported-by: Lan Tianyu 
> Reported-by: Nishanth Menon 
> Reported-by: Jinhyuk Choi 
> Signed-off-by: Viresh Kumar 
> 
> ---
> drivers/base/power/main.c |  5 +
> 
>  drivers/cpufreq/cpufreq.c | 50
>  +++ include/linux/cpufreq.h  
>  |  3 +++
>  3 files changed, 58 insertions(+)
> 
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 1b41fca..c9fbb9d 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -29,6 +29,7 @@
> 
>  #include 
>  #include 
>  #include 
> 
> +#include 
> 
>  #include 
>  #include 
> 
> @@ -789,6 +790,8 @@ void dpm_resume(pm_message_t state)
> 
>   mutex_unlock(_list_mtx);
>   async_synchronize_full();
>   dpm_show_time(starttime, state, NULL);
> 
> +
> + cpufreq_resume();
> 
>  }
>  
>  /**
> 
> @@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
> 
>   might_sleep();
> 
> + cpufreq_suspend();
> +
> 
>   mutex_lock(_list_mtx);
>   pm_transition = state;
>   async_error = 0;

Shouldn't it do cpufreq_resume() on errors?

> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 02d534d..b6c7821 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -26,6 +26,7 @@
> 
>  #include 
>  #include 
>  #include 
> 
> +#include 
> 
>  #include 
>  #include 
>  #include 
> 
> @@ -47,6 +48,9 @@ static LIST_HEAD(cpufreq_policy_list);
> 
>  static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
>  #endif
> 
> +/* Flag to suspend/resume CPUFreq governors */
> +static bool cpufreq_suspended;
> +
> 
>  static inline bool has_target(void)
>  {
>  
>   return cpufreq_driver->target_index || cpufreq_driver->target;
> 
> @@ -1462,6 +1466,48 @@ static struct subsys_interface cpufreq_interface = {
> 
>   .remove_dev = cpufreq_remove_dev,
>  
>  };
> 
> +/*
> + * Callbacks for suspending/resuming governors as some platforms can't
> change + * frequency after this point in suspend cycle. Because some of the
> devices + * (like: i2c, regulators, etc) they use for changing frequency
> are suspended + * quickly after this point.
> + */
> +void cpufreq_suspend(void)
> +{
> + struct cpufreq_policy *policy;
> +
> + if (!has_target())
> + return;
> +
> + pr_debug("%s: Suspending Governors\n", __func__);
> +
> + list_for_each_entry(policy, _policy_list, policy_list)
> + if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
> + pr_err("%s: Failed to stop governor for policy: %p\n",
> + __func__, policy);

This appears to be racy.  Is it really racy, or just seemingly?

> +
> + cpufreq_suspended = true;
> +}
> +
> +void cpufreq_resume(void)
> +{
> + struct cpufreq_policy *policy;
> +
> + if (!has_target())
> + return;
> +
> + pr_debug("%s: Resuming Governors\n", __func__);
> +
> + cpufreq_suspended = false;
> +
> + list_for_each_entry(policy, _policy_list, policy_list)
> + if (__cpufreq_governor(policy, CPUFREQ_GOV_START) ||
> + __cpufreq_governor(policy,
> + CPUFREQ_GOV_LIMITS))
> + pr_err("%s: Failed to start governor for policy: %p\n",
> + __func__, policy);
> +}
> +
> 
>  /**
>  
>   * cpufreq_bp_suspend - Prepare the boot CPU for system suspend.
>   *
> 
> @@ -1764,6 +1810,10 @@ static int __cpufreq_governor(struct cpufreq_policy
> *policy,> 
>   struct cpufreq_governor *gov = NULL;
>  
>  #endif
> 
> + /* Don't start any governor operations if we 

Re: [PATCH] ARM: dts: Add max77686 RTC interrupt to cros5250-common

[Olof Johansson]

On Mon, Nov 25, 2013 at 3:11 PM, Doug Anderson  wrote:
> Olof or Kukjin,
>
> On Wed, Oct 23, 2013 at 6:11 AM, Doug Anderson  wrote:
>> Without the interrupt you'll get problems if you enable
>> CONFIG_RTC_DRV_MAX77686.  Setup the interrupt properly in the device
>> tree.
>>
>> Signed-off-by: Doug Anderson 
>> ---
>>  arch/arm/boot/dts/cros5250-common.dtsi | 12 
>>  1 file changed, 12 insertions(+)
>
> Would one of you be interested in applying this to your tree, with
> Marc's "Tested-by"?  I know there are lots more things to fixup in the
> dts, but this is one that I know works.  ;)

Yes, I'll apply this to fixes for 3.13, and mark it for stable 3.12 at least.


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

Re: [PATCH v3 1/3] msi: free msi_desc entry only after we've released the kobject

[Bjorn Helgaas]

On Tue, Oct 29, 2013 at 11:30:30AM +0100, Veaceslav Falico wrote:
> Currently, we first do kobject_put(>kobj) and the kfree(entry),
> however kobject_put() doesn't guarantee us that it was the last reference
> and that the kobj isn't used currently by someone else, so after we
> kfree(entry) with the struct kobject - other users will begin using the
> freed memory, instead of the actual kobject.
> 
> Fix this by using the kobject->release callback, which is called last when
> the kobject is indeed not used and is cleaned up - it's msi_kobj_release(),
> which can do the kfree(entry) safely (kobject_put/cleanup doesn't use the
> kobj itself after ->release() was called, so we're safe).
> 
> In case we've failed to create the sysfs directories - just kfree()
> it - cause we don't have the kobjects attached.
> 
> Also, remove the same functionality from populate_msi_sysfs(), cause on
> failure we anyway call free_msi_irqs(), which will take care of all the
> kobjects properly.
> 
> And add the forgotten pci_dev_put(pdev) in case of failure to register the
> kobject in populate_msi_sysfs().
> 
> CC: Bjorn Helgaas 
> CC: Neil Horman 
> CC: Greg Kroah-Hartman 
> CC: linux-...@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Veaceslav Falico 

I'm still hoping that Greg (or somebody else; Greg already posted the bulk
of the work) will finish up the conversion to attributes, and that Neil
will confirm that works with no changes to irqbalance.  So I'm going to
drop these patches for now.  Poke me if we need to revive them.

Bjorn

> ---
>  drivers/pci/msi.c | 31 ---
>  1 file changed, 12 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index d5f90d6..5d70f49 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -374,19 +374,22 @@ static void free_msi_irqs(struct pci_dev *dev)
>   iounmap(entry->mask_base);
>   }
>  
> + list_del(>list);
> +
>   /*
>* Its possible that we get into this path
>* When populate_msi_sysfs fails, which means the entries
>* were not registered with sysfs.  In that case don't
> -  * unregister them.
> +  * unregister them, and just free. Otherwise the
> +  * kobject->release will take care of freeing the entry via
> +  * msi_kobj_release().
>*/
>   if (entry->kobj.parent) {
>   kobject_del(>kobj);
>   kobject_put(>kobj);
> + } else {
> + kfree(entry);
>   }
> -
> - list_del(>list);
> - kfree(entry);
>   }
>  }
>  
> @@ -509,6 +512,7 @@ static void msi_kobj_release(struct kobject *kobj)
>   struct msi_desc *entry = to_msi_desc(kobj);
>  
>   pci_dev_put(entry->dev);
> + kfree(entry);
>  }
>  
>  static struct kobj_type msi_irq_ktype = {
> @@ -522,7 +526,6 @@ static int populate_msi_sysfs(struct pci_dev *pdev)
>   struct msi_desc *entry;
>   struct kobject *kobj;
>   int ret;
> - int count = 0;
>  
>   pdev->msi_kset = kset_create_and_add("msi_irqs", NULL, >dev.kobj);
>   if (!pdev->msi_kset)
> @@ -534,23 +537,13 @@ static int populate_msi_sysfs(struct pci_dev *pdev)
>   pci_dev_get(pdev);
>   ret = kobject_init_and_add(kobj, _irq_ktype, NULL,
>"%u", entry->irq);
> - if (ret)
> - goto out_unroll;
> -
> - count++;
> + if (ret) {
> + pci_dev_put(pdev);
> + return ret;
> + }
>   }
>  
>   return 0;
> -
> -out_unroll:
> - list_for_each_entry(entry, >msi_list, list) {
> - if (!count)
> - break;
> - kobject_del(>kobj);
> - kobject_put(>kobj);
> - count--;
> - }
> - return ret;
>  }
>  
>  /**
> -- 
> 1.8.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: Add max77686 RTC interrupt to cros5250-common

[Doug Anderson]

Olof or Kukjin,

On Wed, Oct 23, 2013 at 6:11 AM, Doug Anderson  wrote:
> Without the interrupt you'll get problems if you enable
> CONFIG_RTC_DRV_MAX77686.  Setup the interrupt properly in the device
> tree.
>
> Signed-off-by: Doug Anderson 
> ---
>  arch/arm/boot/dts/cros5250-common.dtsi | 12 
>  1 file changed, 12 insertions(+)

Would one of you be interested in applying this to your tree, with
Marc's "Tested-by"?  I know there are lots more things to fixup in the
dts, but this is one that I know works.  ;)

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: Do not use PCI ID macros in quirk names

[Bjorn Helgaas]

On Mon, Nov 11, 2013 at 6:40 AM, Michal Marek  wrote:
> Pasting the verbatim PCI_(VENDOR|DEVICE)_* macros in the __pci_fixup_*
> symbol names results in insanely long names such as
>
> __pci_fixup_resumePCI_VENDOR_ID_SERVERWORKSPCI_DEVICE_ID_SERVERWORKS_HT1000SBquirk_disable_broadcom_boot_interrupt
>
> When LTO adds its numeric suffix to such symbol, it overflows the
> namebuf[KSYM_NAME_LEN] array. Use the line number instead to create
> (nearly) unique symbol names.
>
> Reported-by: Joe Mario 
> Cc: Bjorn Helgaas 
> Cc: linux-...@vger.kernel.org
> Cc: Andi Kleen 
> Cc: Joe Mario 
> Signed-off-by: Michal Marek 

Applied to my for-linus branch for v3.13, thanks.

> ---
>  include/linux/pci.h | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index da172f9..1ff4dec 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1557,65 +1557,65 @@ enum pci_fixup_pass {
>  /* Anonymous variables would be nice... */
>  #define DECLARE_PCI_FIXUP_SECTION(section, name, vendor, device, class,  
>   \
>   class_shift, hook)\
> -   static const struct pci_fixup __pci_fixup_##name __used \
> +   static const struct pci_fixup __PASTE(__pci_fixup_##name,__LINE__) 
> __used   \
> __attribute__((__section__(#section), aligned((sizeof(void *)\
> = { vendor, device, class, class_shift, hook };
>
>  #define DECLARE_PCI_FIXUP_CLASS_EARLY(vendor, device, class,   \
>  class_shift, hook) \
> DECLARE_PCI_FIXUP_SECTION(.pci_fixup_early, \
> -   vendor##device##hook, vendor, device, class, class_shift, 
> hook)
> +   hook, vendor, device, class, class_shift, hook)
>  #define DECLARE_PCI_FIXUP_CLASS_HEADER(vendor, device, class,  \
>  class_shift, hook) \
> DECLARE_PCI_FIXUP_SECTION(.pci_fixup_header,\
> -   vendor##device##hook, vendor, device, class, class_shift, 
> hook)
> +   hook, vendor, device, class, class_shift, hook)
>  #define DECLARE_PCI_FIXUP_CLASS_FINAL(vendor, device, class,   \
>  class_shift, hook) \
> DECLARE_PCI_FIXUP_SECTION(.pci_fixup_final, \
> -   vendor##device##hook, vendor, device, class, class_shift, 
> hook)
> +   hook, vendor, device, class, class_shift, hook)
>  #define DECLARE_PCI_FIXUP_CLASS_ENABLE(vendor, device, class,  \
>  class_shift, hook) \
> DECLARE_PCI_FIXUP_SECTION(.pci_fixup_enable,\
> -   vendor##device##hook, vendor, device, class, class_shift, 
> hook)
> +   hook, vendor, device, class, class_shift, hook)
>  #define DECLARE_PCI_FIXUP_CLASS_RESUME(vendor, device, class,  \
>  class_shift, hook) \
> DECLARE_PCI_FIXUP_SECTION(.pci_fixup_resume,\
> -   resume##vendor##device##hook, vendor, device, class,\
> +   resume##hook, vendor, device, class,\
> class_shift, hook)
>  #define DECLARE_PCI_FIXUP_CLASS_RESUME_EARLY(vendor, device, class,\
>  class_shift, hook) \
> DECLARE_PCI_FIXUP_SECTION(.pci_fixup_resume_early,  \
> -   resume_early##vendor##device##hook, vendor, device, \
> +   resume_early##hook, vendor, device, \
> class, class_shift, hook)
>  #define DECLARE_PCI_FIXUP_CLASS_SUSPEND(vendor, device, class, \
>  class_shift, hook) \
> DECLARE_PCI_FIXUP_SECTION(.pci_fixup_suspend,   \
> -   suspend##vendor##device##hook, vendor, device, class,   \
> +   suspend##hook, vendor, device, class,   \
> class_shift, hook)
>
>  #define DECLARE_PCI_FIXUP_EARLY(vendor, device, hook)  \
> DECLARE_PCI_FIXUP_SECTION(.pci_fixup_early, \
> -   vendor##device##hook, vendor, device, PCI_ANY_ID, 0, hook)
> +   hook, vendor, device, PCI_ANY_ID, 0, hook)
>  #define DECLARE_PCI_FIXUP_HEADER(vendor, device, hook) \
> DECLARE_PCI_FIXUP_SECTION(.pci_fixup_header,\
> -   vendor##device##hook, vendor, device, PCI_ANY_ID, 0, hook)
> +   hook, vendor, device, PCI_ANY_ID, 0, hook)
>  #define DECLARE_PCI_FIXUP_FINAL(vendor, device, hook)  \
> DECLARE_PCI_FIXUP_SECTION(.pci_fixup_final, \
> -   

Re: [PATCH 0/6] Platform: x86: chromeos_laptop - Deferring and Haswell

[Benson Leung]

Hi Olof,


On Mon, Nov 25, 2013 at 1:13 PM, Olof Johansson  wrote:
> I've applied patch 1-3. Since the naming seems to still be up in the
> air on the i2c side, I can't apply 4-6 yet.
>
> I also switched the subject to platform/chrome: ... since that's what
> I've picked to use on the other patches in the same directory.


Sounds good to me. Thanks for applying the patches.

-- 
Benson Leung
Software Engineer, Chrom* OS
ble...@chromium.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: Do not use PCI ID macros in quirk names

[Andi Kleen]

> What's LTO?  I guess it's Link Time Optimization?  Is there any

Yes. Link Time Optimization with modern gcc.

> documentation about how it works or how to use it?

It's still a separate tree, but bits'n'pieces are slowly
making it into the kernel.

https://github.com/andikleen/linux-misc/tree/lto-3.12

https://github.com/andikleen/linux-misc/blob/5a18e33264321b01816a220ab14207a5f26ae16e/Documentation/lto-build

http://halobates.de/kernel-lto.pdf

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Doug Anderson]

On modern SoCs the watchdog timer is parented on a clock that doesn't
change every time we have a cpufreq change.  That means we don't need
to constantly adjust the watchdog timer, so avoid registering for and
dealing with cpufreq transitions unless we've actually got
CPU_FREQ_S3C24XX defined.

Note that this is more than just an optimization.  The s3c2410
watchdog driver actually pats the watchdog on every CPU frequency
change.  On modern systems these happen many times per second (even in
a system where "nothing" is happening).  That effectively makes any
userspace watchdog program useless (the watchdog is constantly patted
by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
multiplatform kernel we'll need to make sure that kernel supports
common clock and change this to user common clock framework.

Signed-off-by: Doug Anderson 
---
 drivers/watchdog/s3c2410_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..4980f84 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param)
return IRQ_HANDLED;
 }
 
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_CPU_FREQ_S3C24XX
 
 static int s3c2410wdt_cpufreq_transition(struct notifier_block *nb,
  unsigned long val, void *data)
-- 
1.8.4.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] acpi: Add BayTrail SoC GPIO and LPSS ACPI IDs

[Rafael J. Wysocki]

On Monday, November 25, 2013 02:15:55 PM Paul Drews wrote:
> This adds the new ACPI ID (INT33FC) for the BayTrail GPIO
> banks as seen on a BayTrail M System-On-Chip platform.  This
> ACPI ID is used by the BayTrail GPIO (pinctrl) driver to
> manage the Low Power Subsystem (LPSS).
> 
> Signed-off-by: Paul Drews 

Am I supposed to take this (in which case I need an ACK from the pinctrl
maintainer)?

Or is it supposed to go through the pinctrl subsystem?  In which case feel free
to add

Acked-by: Rafael J. Wysocki  # for the ACPI part

to the patch.

Thanks!

> ---
>  drivers/acpi/acpi_lpss.c   | 1 +
>  drivers/pinctrl/pinctrl-baytrail.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index 6745fe1..e603905 100644
> --- a/drivers/acpi/acpi_lpss.c
> +++ b/drivers/acpi/acpi_lpss.c
> @@ -162,6 +162,7 @@ static const struct acpi_device_id acpi_lpss_device_ids[] 
> = {
>   { "80860F14", (unsigned long)_sdio_dev_desc },
>   { "80860F41", (unsigned long)_i2c_dev_desc },
>   { "INT33B2", },
> + { "INT33FC", },
>  
>   { "INT3430", (unsigned long)_dev_desc },
>   { "INT3431", (unsigned long)_dev_desc },
> diff --git a/drivers/pinctrl/pinctrl-baytrail.c 
> b/drivers/pinctrl/pinctrl-baytrail.c
> index 2832576..114f5ef 100644
> --- a/drivers/pinctrl/pinctrl-baytrail.c
> +++ b/drivers/pinctrl/pinctrl-baytrail.c
> @@ -512,6 +512,7 @@ static const struct dev_pm_ops byt_gpio_pm_ops = {
>  
>  static const struct acpi_device_id byt_gpio_acpi_match[] = {
>   { "INT33B2", 0 },
> + { "INT33FC", 0 },
>   { }
>  };
>  MODULE_DEVICE_TABLE(acpi, byt_gpio_acpi_match);
> 
-- 
I speak only for myself.
Rafael J. Wysocki, 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/

[PATCH v2] crypto: more robust crypto_memneq

[Cesar Eduardo Barros]

Disabling compiler optimizations can be fragile, since a new
optimization could be added to -O0 or -Os that breaks the assumptions
the code is making.

Instead of disabling compiler optimizations, use a dummy inline assembly
(based on RELOC_HIDE) to block the problematic kinds of optimization,
while still allowing other optimizations to be applied to the code.

The dummy inline assembly is added after every OR, and has the
accumulator variable as its input and output. The compiler is forced to
assume that the dummy inline assembly could both depend on the
accumulator variable and change the accumulator variable, so it is
forced to compute the value correctly before the inline assembly, and
cannot assume anything about its value after the inline assembly.

This change should be enough to make crypto_memneq work correctly (with
data-independent timing) even if it is inlined at its call sites. That
can be done later in a followup patch.

Compile-tested on x86_64.

Signed-off-by: Cesar Eduardo Barros 
---

v2: Moved the macro to include/linux/compiler*.h as suggested by Daniel
Borkmann.

 crypto/Makefile|  5 ---
 crypto/memneq.c| 79 +-
 include/linux/compiler-gcc.h   |  3 ++
 include/linux/compiler-intel.h |  7 
 include/linux/compiler.h   |  4 +++
 5 files changed, 68 insertions(+), 30 deletions(-)

diff --git a/crypto/Makefile b/crypto/Makefile
index 989c510..b29402a 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -2,11 +2,6 @@
 # Cryptographic API
 #
 
-# memneq MUST be built with -Os or -O0 to prevent early-return optimizations
-# that will defeat memneq's actual purpose to prevent timing attacks.
-CFLAGS_REMOVE_memneq.o := -O1 -O2 -O3
-CFLAGS_memneq.o := -Os
-
 obj-$(CONFIG_CRYPTO) += crypto.o
 crypto-y := api.o cipher.o compress.o memneq.o
 
diff --git a/crypto/memneq.c b/crypto/memneq.c
index cd01622..570f6f3 100644
--- a/crypto/memneq.c
+++ b/crypto/memneq.c
@@ -72,6 +72,7 @@ __crypto_memneq_generic(const void *a, const void *b, size_t 
size)
 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
while (size >= sizeof(unsigned long)) {
neq |= *(unsigned long *)a ^ *(unsigned long *)b;
+   OPTIMIZER_HIDE_VAR(neq);
a += sizeof(unsigned long);
b += sizeof(unsigned long);
size -= sizeof(unsigned long);
@@ -79,6 +80,7 @@ __crypto_memneq_generic(const void *a, const void *b, size_t 
size)
 #endif /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
while (size > 0) {
neq |= *(unsigned char *)a ^ *(unsigned char *)b;
+   OPTIMIZER_HIDE_VAR(neq);
a += 1;
b += 1;
size -= 1;
@@ -89,33 +91,60 @@ __crypto_memneq_generic(const void *a, const void *b, 
size_t size)
 /* Loop-free fast-path for frequently used 16-byte size */
 static inline unsigned long __crypto_memneq_16(const void *a, const void *b)
 {
+   unsigned long neq = 0;
+
 #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
-   if (sizeof(unsigned long) == 8)
-   return ((*(unsigned long *)(a)   ^ *(unsigned long *)(b))
- | (*(unsigned long *)(a+8) ^ *(unsigned long *)(b+8)));
-   else if (sizeof(unsigned int) == 4)
-   return ((*(unsigned int *)(a)^ *(unsigned int *)(b))
-  | (*(unsigned int *)(a+4)  ^ *(unsigned int *)(b+4))
- | (*(unsigned int *)(a+8)  ^ *(unsigned int *)(b+8))
- | (*(unsigned int *)(a+12) ^ *(unsigned int *)(b+12)));
-   else
+   if (sizeof(unsigned long) == 8) {
+   neq |= *(unsigned long *)(a)   ^ *(unsigned long *)(b);
+   OPTIMIZER_HIDE_VAR(neq);
+   neq |= *(unsigned long *)(a+8) ^ *(unsigned long *)(b+8);
+   OPTIMIZER_HIDE_VAR(neq);
+   } else if (sizeof(unsigned int) == 4) {
+   neq |= *(unsigned int *)(a)^ *(unsigned int *)(b);
+   OPTIMIZER_HIDE_VAR(neq);
+   neq |= *(unsigned int *)(a+4)  ^ *(unsigned int *)(b+4);
+   OPTIMIZER_HIDE_VAR(neq);
+   neq |= *(unsigned int *)(a+8)  ^ *(unsigned int *)(b+8);
+   OPTIMIZER_HIDE_VAR(neq);
+   neq |= *(unsigned int *)(a+12) ^ *(unsigned int *)(b+12);
+   OPTIMIZER_HIDE_VAR(neq);
+   } else {
 #endif /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
-   return ((*(unsigned char *)(a)^ *(unsigned char *)(b))
- | (*(unsigned char *)(a+1)  ^ *(unsigned char *)(b+1))
- | (*(unsigned char *)(a+2)  ^ *(unsigned char *)(b+2))
- | (*(unsigned char *)(a+3)  ^ *(unsigned char *)(b+3))
- | (*(unsigned char *)(a+4)  ^ *(unsigned char *)(b+4))
- | (*(unsigned char *)(a+5)  ^ *(unsigned char *)(b+5))
- | (*(unsigned char *)(a+6)  ^ *(unsigned char *)(b+6))

[PATCH 5/5] bcache: generic_make_request() handles large bios now

[Kent Overstreet]

So we get to delete our hacky workaround.

Signed-off-by: Kent Overstreet 
---
 drivers/md/bcache/bcache.h|  18 
 drivers/md/bcache/io.c| 100 +-
 drivers/md/bcache/journal.c   |   4 +-
 drivers/md/bcache/request.c   |  16 +++
 drivers/md/bcache/super.c |  32 +-
 drivers/md/bcache/util.h  |   5 ++-
 drivers/md/bcache/writeback.c |   4 +-
 7 files changed, 18 insertions(+), 161 deletions(-)

diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
index 964353c..8f65331 100644
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -241,19 +241,6 @@ struct keybuf {
DECLARE_ARRAY_ALLOCATOR(struct keybuf_key, freelist, KEYBUF_NR);
 };
 
-struct bio_split_pool {
-   struct bio_set  *bio_split;
-   mempool_t   *bio_split_hook;
-};
-
-struct bio_split_hook {
-   struct closure  cl;
-   struct bio_split_pool   *p;
-   struct bio  *bio;
-   bio_end_io_t*bi_end_io;
-   void*bi_private;
-};
-
 struct bcache_device {
struct closure  cl;
 
@@ -286,8 +273,6 @@ struct bcache_device {
int (*cache_miss)(struct btree *, struct search *,
  struct bio *, unsigned);
int (*ioctl) (struct bcache_device *, fmode_t, unsigned, unsigned long);
-
-   struct bio_split_pool   bio_split_hook;
 };
 
 struct io {
@@ -465,8 +450,6 @@ struct cache {
atomic_long_t   meta_sectors_written;
atomic_long_t   btree_sectors_written;
atomic_long_t   sectors_written;
-
-   struct bio_split_pool   bio_split_hook;
 };
 
 struct gc_stat {
@@ -901,7 +884,6 @@ void bch_bbio_endio(struct cache_set *, struct bio *, int, 
const char *);
 void bch_bbio_free(struct bio *, struct cache_set *);
 struct bio *bch_bbio_alloc(struct cache_set *);
 
-void bch_generic_make_request(struct bio *, struct bio_split_pool *);
 void __bch_submit_bbio(struct bio *, struct cache_set *);
 void bch_submit_bbio(struct bio *, struct cache_set *, struct bkey *, 
unsigned);
 
diff --git a/drivers/md/bcache/io.c b/drivers/md/bcache/io.c
index fa028fa..86a0bb8 100644
--- a/drivers/md/bcache/io.c
+++ b/drivers/md/bcache/io.c
@@ -11,104 +11,6 @@
 
 #include 
 
-static unsigned bch_bio_max_sectors(struct bio *bio)
-{
-   struct request_queue *q = bdev_get_queue(bio->bi_bdev);
-   struct bio_vec bv;
-   struct bvec_iter iter;
-   unsigned ret = 0, seg = 0;
-
-   if (bio->bi_rw & REQ_DISCARD)
-   return min(bio_sectors(bio), q->limits.max_discard_sectors);
-
-   bio_for_each_segment(bv, bio, iter) {
-   struct bvec_merge_data bvm = {
-   .bi_bdev= bio->bi_bdev,
-   .bi_sector  = bio->bi_iter.bi_sector,
-   .bi_size= ret << 9,
-   .bi_rw  = bio->bi_rw,
-   };
-
-   if (seg == min_t(unsigned, BIO_MAX_PAGES,
-queue_max_segments(q)))
-   break;
-
-   if (q->merge_bvec_fn &&
-   q->merge_bvec_fn(q, , ) < (int) bv.bv_len)
-   break;
-
-   seg++;
-   ret += bv.bv_len >> 9;
-   }
-
-   ret = min(ret, queue_max_sectors(q));
-
-   WARN_ON(!ret);
-   ret = max_t(int, ret, bio_iovec(bio).bv_len >> 9);
-
-   return ret;
-}
-
-static void bch_bio_submit_split_done(struct closure *cl)
-{
-   struct bio_split_hook *s = container_of(cl, struct bio_split_hook, cl);
-
-   s->bio->bi_end_io = s->bi_end_io;
-   s->bio->bi_private = s->bi_private;
-   bio_endio_nodec(s->bio, 0);
-
-   closure_debug_destroy(>cl);
-   mempool_free(s, s->p->bio_split_hook);
-}
-
-static void bch_bio_submit_split_endio(struct bio *bio, int error)
-{
-   struct closure *cl = bio->bi_private;
-   struct bio_split_hook *s = container_of(cl, struct bio_split_hook, cl);
-
-   if (error)
-   clear_bit(BIO_UPTODATE, >bio->bi_flags);
-
-   bio_put(bio);
-   closure_put(cl);
-}
-
-void bch_generic_make_request(struct bio *bio, struct bio_split_pool *p)
-{
-   struct bio_split_hook *s;
-   struct bio *n;
-
-   if (!bio_has_data(bio) && !(bio->bi_rw & REQ_DISCARD))
-   goto submit;
-
-   if (bio_sectors(bio) <= bch_bio_max_sectors(bio))
-   goto submit;
-
-   s = mempool_alloc(p->bio_split_hook, GFP_NOIO);
-   closure_init(>cl, NULL);
-
-   s->bio  = bio;
-   s->p= p;
-   s->bi_end_io= bio->bi_end_io;
-   s->bi_private   = bio->bi_private;
-   bio_get(bio);
-
-   do {
-   n = bio_next_split(bio, bch_bio_max_sectors(bio),
-  GFP_NOIO, s->p->bio_split);
-
-   n->bi_end_io= 

Re: [PATCH] crypto: more robust crypto_memneq

[Cesar Eduardo Barros]

Em 25-11-2013 14:26, Daniel Borkmann escreveu:

On 11/25/2013 04:59 PM, James Yonan wrote:

This approach using __asm__ ("" : "=r" (var) : "0" (var)) to try to
prevent compiler optimizations of var is interesting.

I like the fact that it's finer-grained than -Os and doesn't preclude
inlining.


Agreed. This looks much better than the Makefile workaround. Do we have
a hard guarantee that in future, this will not be detected and optimized
away by the compiler?


That guarantee is something only the compiler people can give you. But 
given that RELOC_HIDE will break if that ever changes, and there are 
other constructs depending on the optimization-blocking behavior of 
inline assembly (like the many kinds of barriers in the kernel), I am 
not worried about that.


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

[PATCH 2/5] mtip32xx: handle arbitrary size bios

[Kent Overstreet]

We get a measurable performance increase by handling this in the driver when
we're already looping over the biovec, instead of handling it separately in
generic_make_request() (or bio_add_page() originally)

Signed-off-by: Kent Overstreet 
Cc: Jens Axboe 
Cc: Asai Thambi S P 
Cc: Sam Bradshaw 
---
 drivers/block/mtip32xx/mtip32xx.c | 47 ---
 1 file changed, 14 insertions(+), 33 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 1b3dfee..2b142eb 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -2648,24 +2648,6 @@ static void mtip_hw_submit_io(struct driver_data *dd, 
sector_t sector,
 }
 
 /*
- * Release a command slot.
- *
- * @dd  Pointer to the driver data structure.
- * @tag Slot tag
- *
- * return value
- *  None
- */
-static void mtip_hw_release_scatterlist(struct driver_data *dd, int tag,
-   int unaligned)
-{
-   struct semaphore *sem = unaligned ? >port->cmd_slot_unal :
-   >port->cmd_slot;
-   release_slot(dd->port, tag);
-   up(sem);
-}
-
-/*
  * Obtain a command slot and return its associated scatter list.
  *
  * @dd  Pointer to the driver data structure.
@@ -3969,8 +3951,6 @@ static void mtip_make_request(struct request_queue 
*queue, struct bio *bio)
 
blk_queue_bounce(queue, );
 
-   blk_queue_split(queue, , q->bio_split);
-
if (unlikely(dd->dd_flag & MTIP_DDF_STOP_IO)) {
if (unlikely(test_bit(MTIP_DDF_REMOVE_PENDING_BIT,
>dd_flag))) {
@@ -4020,21 +4000,22 @@ static void mtip_make_request(struct request_queue 
*queue, struct bio *bio)
 
sg = mtip_hw_get_scatterlist(dd, , unaligned);
if (likely(sg != NULL)) {
-   if (unlikely((bio)->bi_vcnt > MTIP_MAX_SG)) {
-   dev_warn(>pdev->dev,
-   "Maximum number of SGL entries exceeded\n");
-   bio_io_error(bio);
-   mtip_hw_release_scatterlist(dd, tag, unaligned);
-   return;
-   }
-
/* Create the scatter list for this bio. */
bio_for_each_segment(bvec, bio, iter) {
-   sg_set_page([nents],
-   bvec.bv_page,
-   bvec.bv_len,
-   bvec.bv_offset);
-   nents++;
+   if (unlikely(nents == MTIP_MAX_SG)) {
+   struct bio *split = bio_clone(bio, GFP_NOIO);
+
+   split->bi_iter = iter;
+   bio->bi_iter.bi_size -= iter.bi_size;
+   bio_chain(split, bio);
+   generic_make_request(split);
+   break;
+   }
+
+   sg_set_page([nents++],
+   bvec.bv_page,
+   bvec.bv_len,
+   bvec.bv_offset);
}
 
/* Issue the read/write. */
-- 
1.8.4.3

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

[PATCH 3/5] block: Gut bio_add_page()

[Kent Overstreet]

Since generic_make_request() can now handle arbitrary size bios, all we
have to do is make sure the bvec array doesn't overflow.

Signed-off-by: Kent Overstreet 
Cc: Jens Axboe 
---
 fs/bio.c | 137 ++-
 1 file changed, 57 insertions(+), 80 deletions(-)

diff --git a/fs/bio.c b/fs/bio.c
index 75c49a3..da27557 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -690,9 +690,23 @@ int bio_get_nr_vecs(struct block_device *bdev)
 }
 EXPORT_SYMBOL(bio_get_nr_vecs);
 
-static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page
- *page, unsigned int len, unsigned int offset,
- unsigned int max_sectors)
+/**
+ * bio_add_pc_page -   attempt to add page to bio
+ * @q: the target queue
+ * @bio: destination bio
+ * @page: page to add
+ * @len: vec entry length
+ * @offset: vec entry offset
+ *
+ * Attempt to add a page to the bio_vec maplist. This can fail for a
+ * number of reasons, such as the bio being full or target block device
+ * limitations. The target block device must allow bio's up to PAGE_SIZE,
+ * so it is always possible to add a single page to an empty bio.
+ *
+ * This should only be used by REQ_PC bios.
+ */
+int bio_add_pc_page(struct request_queue *q, struct bio *bio, struct page
+   *page, unsigned int len, unsigned int offset)
 {
int retried_segments = 0;
struct bio_vec *bvec;
@@ -703,7 +717,7 @@ static int __bio_add_page(struct request_queue *q, struct 
bio *bio, struct page
if (unlikely(bio_flagged(bio, BIO_CLONED)))
return 0;
 
-   if (((bio->bi_iter.bi_size + len) >> 9) > max_sectors)
+   if (((bio->bi_iter.bi_size + len) >> 9) > queue_max_hw_sectors(q))
return 0;
 
/*
@@ -716,28 +730,7 @@ static int __bio_add_page(struct request_queue *q, struct 
bio *bio, struct page
 
if (page == prev->bv_page &&
offset == prev->bv_offset + prev->bv_len) {
-   unsigned int prev_bv_len = prev->bv_len;
prev->bv_len += len;
-
-   if (q->merge_bvec_fn) {
-   struct bvec_merge_data bvm = {
-   /* prev_bvec is already charged in
-  bi_size, discharge it in order to
-  simulate merging updated prev_bvec
-  as new bvec. */
-   .bi_bdev = bio->bi_bdev,
-   .bi_sector = bio->bi_iter.bi_sector,
-   .bi_size = bio->bi_iter.bi_size -
-   prev_bv_len,
-   .bi_rw = bio->bi_rw,
-   };
-
-   if (q->merge_bvec_fn(q, , prev) < 
prev->bv_len) {
-   prev->bv_len -= len;
-   return 0;
-   }
-   }
-
goto done;
}
}
@@ -768,31 +761,6 @@ static int __bio_add_page(struct request_queue *q, struct 
bio *bio, struct page
bvec->bv_len = len;
bvec->bv_offset = offset;
 
-   /*
-* if queue has other restrictions (eg varying max sector size
-* depending on offset), it can specify a merge_bvec_fn in the
-* queue to get further control
-*/
-   if (q->merge_bvec_fn) {
-   struct bvec_merge_data bvm = {
-   .bi_bdev = bio->bi_bdev,
-   .bi_sector = bio->bi_iter.bi_sector,
-   .bi_size = bio->bi_iter.bi_size,
-   .bi_rw = bio->bi_rw,
-   };
-
-   /*
-* merge_bvec_fn() returns number of bytes it can accept
-* at this offset
-*/
-   if (q->merge_bvec_fn(q, , bvec) < bvec->bv_len) {
-   bvec->bv_page = NULL;
-   bvec->bv_len = 0;
-   bvec->bv_offset = 0;
-   return 0;
-   }
-   }
-
/* If we may be able to merge these biovecs, force a recount */
if (bio->bi_vcnt && (BIOVEC_PHYS_MERGEABLE(bvec-1, bvec)))
bio->bi_flags &= ~(1 << BIO_SEG_VALID);
@@ -803,28 +771,6 @@ static int __bio_add_page(struct request_queue *q, struct 
bio *bio, struct page
bio->bi_iter.bi_size += len;
return len;
 }
-
-/**
- * bio_add_pc_page -   attempt to add page to bio
- * @q: the target queue
- * @bio: destination bio
- * @page: page to add
- * @len: vec entry length
- * @offset: vec entry offset
- *
- * Attempt to add a page to the bio_vec 

[PATCH 4/5] blk-lib.c: generic_make_request() handles large bios now

[Kent Overstreet]

generic_make_request() will now do for us what the code in blk-lib.c was
doing manually, with the bio_batch stuff - we still need some looping in
case we're trying to discard/zeroout more than around a gigabyte, but
when we can submit that much at a time doing the submissions in parallel
really shouldn't matter.

Signed-off-by: Kent Overstreet 
Cc: Jens Axboe 
---
 block/blk-lib.c | 175 ++--
 1 file changed, 30 insertions(+), 145 deletions(-)

diff --git a/block/blk-lib.c b/block/blk-lib.c
index 2da76c9..368c36a 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -9,23 +9,6 @@
 
 #include "blk.h"
 
-struct bio_batch {
-   atomic_tdone;
-   unsigned long   flags;
-   struct completion   *wait;
-};
-
-static void bio_batch_end_io(struct bio *bio, int err)
-{
-   struct bio_batch *bb = bio->bi_private;
-
-   if (err && (err != -EOPNOTSUPP))
-   clear_bit(BIO_UPTODATE, >flags);
-   if (atomic_dec_and_test(>done))
-   complete(bb->wait);
-   bio_put(bio);
-}
-
 /**
  * blkdev_issue_discard - queue a discard
  * @bdev:  blockdev to issue discard for
@@ -40,15 +23,10 @@ static void bio_batch_end_io(struct bio *bio, int err)
 int blkdev_issue_discard(struct block_device *bdev, sector_t sector,
sector_t nr_sects, gfp_t gfp_mask, unsigned long flags)
 {
-   DECLARE_COMPLETION_ONSTACK(wait);
struct request_queue *q = bdev_get_queue(bdev);
int type = REQ_WRITE | REQ_DISCARD;
-   unsigned int max_discard_sectors, granularity;
-   int alignment;
-   struct bio_batch bb;
struct bio *bio;
int ret = 0;
-   struct blk_plug plug;
 
if (!q)
return -ENXIO;
@@ -56,78 +34,28 @@ int blkdev_issue_discard(struct block_device *bdev, 
sector_t sector,
if (!blk_queue_discard(q))
return -EOPNOTSUPP;
 
-   /* Zero-sector (unknown) and one-sector granularities are the same.  */
-   granularity = max(q->limits.discard_granularity >> 9, 1U);
-   alignment = (bdev_discard_alignment(bdev) >> 9) % granularity;
-
-   /*
-* Ensure that max_discard_sectors is of the proper
-* granularity, so that requests stay aligned after a split.
-*/
-   max_discard_sectors = min(q->limits.max_discard_sectors, UINT_MAX >> 9);
-   max_discard_sectors -= max_discard_sectors % granularity;
-   if (unlikely(!max_discard_sectors)) {
-   /* Avoid infinite loop below. Being cautious never hurts. */
-   return -EOPNOTSUPP;
-   }
-
if (flags & BLKDEV_DISCARD_SECURE) {
if (!blk_queue_secdiscard(q))
return -EOPNOTSUPP;
type |= REQ_SECURE;
}
 
-   atomic_set(, 1);
-   bb.flags = 1 << BIO_UPTODATE;
-   bb.wait = 
-
-   blk_start_plug();
while (nr_sects) {
-   unsigned int req_sects;
-   sector_t end_sect, tmp;
-
bio = bio_alloc(gfp_mask, 1);
-   if (!bio) {
-   ret = -ENOMEM;
-   break;
-   }
-
-   req_sects = min_t(sector_t, nr_sects, max_discard_sectors);
-
-   /*
-* If splitting a request, and the next starting sector would be
-* misaligned, stop the discard at the previous aligned sector.
-*/
-   end_sect = sector + req_sects;
-   tmp = end_sect;
-   if (req_sects < nr_sects &&
-   sector_div(tmp, granularity) != alignment) {
-   end_sect = end_sect - alignment;
-   sector_div(end_sect, granularity);
-   end_sect = end_sect * granularity + alignment;
-   req_sects = end_sect - sector;
-   }
+   if (!bio)
+   return -ENOMEM;
 
-   bio->bi_iter.bi_sector = sector;
-   bio->bi_end_io = bio_batch_end_io;
bio->bi_bdev = bdev;
-   bio->bi_private = 
+   bio->bi_iter.bi_sector = sector;
+   bio->bi_iter.bi_size = min_t(sector_t, nr_sects, 1 << 20) << 9;
 
-   bio->bi_iter.bi_size = req_sects << 9;
-   nr_sects -= req_sects;
-   sector = end_sect;
+   sector += bio_sectors(bio);
+   nr_sects -= bio_sectors(bio);
 
-   atomic_inc();
-   submit_bio(type, bio);
+   ret = submit_bio_wait(type, bio);
+   if (ret)
+   break;
}
-   blk_finish_plug();
-
-   /* Wait for bios in-flight */
-   if (!atomic_dec_and_test())
-   wait_for_completion_io();
-
-   if (!test_bit(BIO_UPTODATE, ))
-   ret = -EIO;
 
return ret;
 }
@@ -148,61 +76,37 @@ int 

[PATCH 1/5] block: Make generic_make_request handle arbitrary sized bios

[Kent Overstreet]

The way the block layer is currently written, it goes to great lengths
to avoid having to split bios; upper layer code (such as bio_add_page())
checks what the underlying device can handle and tries to always create
bios that don't need to be split.

But this approach becomes unwieldy and eventually breaks down with
stacked devices and devices with dynamic limits, and it adds a lot of
complexity. If the block layer could split bios as needed, we could
eliminate a lot of complexity elsewhere - particularly in stacked
drivers. Code that creates bios can then create whatever size bios are
convenient, and more importantly stacked drivers don't have to deal with
both their own bio size limitations and the limitations of the
(potentially multiple) devices underneath them.  In the future this will
let us delete merge_bvec_fn and a bunch of other code.

We do this by adding calls to blk_queue_split() to the various
make_request functions that need it - a few can already handle arbitrary
size bios. Note that we add the call _after_ any call to blk_queue_bounce();
this means that blk_queue_split() and blk_recalc_rq_segments() don't need to be
concerned with bouncing affecting segment merging.

Some make_request_fns were simple enough to audit and verify they don't
need blk_queue_split() calls. The skipped ones are:

 * nfhd_make_request (arch/m68k/emu/nfblock.c)
 * axon_ram_make_request (arch/powerpc/sysdev/axonram.c)
 * simdisk_make_request (arch/xtensa/platforms/iss/simdisk.c)
 * brd_make_request (ramdisk - drivers/block/brd.c)
 * loop_make_request
 * null_queue_bio
 * bcache's make_request fns

Some others are almost certainly safe to remove now, but will be left for future
patches.

Signed-off-by: Kent Overstreet 
Cc: Jens Axboe 
Cc: Neil Brown 
Cc: Alasdair Kergon 
Cc: dm-de...@redhat.com
---
 block/blk-core.c|  19 ++--
 block/blk-merge.c   | 150 ++--
 block/blk-mq.c  |   2 +
 drivers/block/drbd/drbd_req.c   |   2 +
 drivers/block/mtip32xx/mtip32xx.c   |   6 +-
 drivers/block/nvme-core.c   |   2 +
 drivers/block/pktcdvd.c |   6 +-
 drivers/block/ps3vram.c |   2 +
 drivers/block/rsxx/dev.c|   2 +
 drivers/block/umem.c|   2 +
 drivers/md/dm.c |   2 +
 drivers/md/md.c |   2 +
 drivers/s390/block/dcssblk.c|   2 +
 drivers/s390/block/xpram.c  |   2 +
 drivers/staging/lustre/lustre/llite/lloop.c |   2 +
 drivers/staging/zram/zram_drv.c |   2 +
 include/linux/blkdev.h  |   3 +
 17 files changed, 185 insertions(+), 23 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 5da8e90..5cc7171 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -566,6 +566,10 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, 
int node_id)
if (q->id < 0)
goto fail_c;
 
+   q->bio_split = bioset_create(4, 0);
+   if (!q->bio_split)
+   goto fail_id;
+
q->backing_dev_info.ra_pages =
(VM_MAX_READAHEAD * 1024) / PAGE_CACHE_SIZE;
q->backing_dev_info.state = 0;
@@ -575,7 +579,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, 
int node_id)
 
err = bdi_init(>backing_dev_info);
if (err)
-   goto fail_id;
+   goto fail_split;
 
setup_timer(>backing_dev_info.laptop_mode_wb_timer,
laptop_mode_timer_fn, (unsigned long) q);
@@ -620,6 +624,8 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, 
int node_id)
 
 fail_bdi:
bdi_destroy(>backing_dev_info);
+fail_split:
+   bioset_free(q->bio_split);
 fail_id:
ida_simple_remove(_queue_ida, q->id);
 fail_c:
@@ -1472,6 +1478,8 @@ void blk_queue_bio(struct request_queue *q, struct bio 
*bio)
struct request *req;
unsigned int request_count = 0;
 
+   blk_queue_split(q, , q->bio_split);
+
/*
 * low level driver can indicate that it wants pages above a
 * certain limit bounced to low memory (ie for highmem, or even
@@ -1694,15 +1702,6 @@ generic_make_request_checks(struct bio *bio)
goto end_io;
}
 
-   if (likely(bio_is_rw(bio) &&
-  nr_sectors > queue_max_hw_sectors(q))) {
-   printk(KERN_ERR "bio too big device %s (%u > %u)\n",
-  bdevname(bio->bi_bdev, b),
-  bio_sectors(bio),
-  queue_max_hw_sectors(q));
-   goto end_io;
-   }
-
part = bio->bi_bdev->bd_part;
if (should_fail_request(part, bio->bi_iter.bi_size) ||
should_fail_request(_to_disk(part)->part0,
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 05c17be..4a0ac34 100644
--- 

[PATCH] Make generic_make_request() handle arbitrary size bios

[Kent Overstreet]

This builds off of immutable biovecs; it's a small enough patch series that I'd
like to try to get it into 3.14 but it is a pretty significant change in
behaviour for the block layer so it should definitely be considered separately
from that series.

What the series does is pretty simple - like the title says, you can now pass
generic_make_request arbitrary size bios - you no longer have to care about
device limits, and we can start deleting a ton of code.

This is done by splitting bios as needed. The idea is to push the splitting
lower and lower over time, and in many cases we eventually won't have to
actually split the bios at all - it'll happen implicitly - for now though, we do
it the simple easy way, with a new function (blk_queue_split()) that mimics the
old behaviour of bio_add_page().

This series only starts with the obvious easy things - bio_add_page(), and the
stuff in blk-lib.c. There's a lot more coming - with the new bio_split() that
can split arbitrary size bios the various virtual block drivers (md, dm, drbd,
etc.) should all either be capable of handling arbitrary size bios now or mostly
need minor changes, so we can delete merge_bvec_fn.

This patch series doesn't with REQ_TYPE_BLOCK_PC bios - bio_add_pc_page() and
the blk_execute_rq() codepath are unchanged. I'd like to get rid of direct
request submission eventually, but that is a different patch series.

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

Re: [PATCH] crypto: more robust crypto_memneq

[Cesar Eduardo Barros]

Em 25-11-2013 13:59, James Yonan escreveu:

On 24/11/2013 14:12, Cesar Eduardo Barros wrote:

Disabling compiler optimizations can be fragile, since a new
optimization could be added to -O0 or -Os that breaks the assumptions
the code is making.

Instead of disabling compiler optimizations, use a dummy inline assembly
(based on RELOC_HIDE) to block the problematic kinds of optimization,
while still allowing other optimizations to be applied to the code.

The dummy inline assembly is added after every OR, and has the
accumulator variable as its input and output. The compiler is forced to
assume that the dummy inline assembly could both depend on the
accumulator variable and change the accumulator variable, so it is
forced to compute the value correctly before the inline assembly, and
cannot assume anything about its value after the inline assembly.

This change should be enough to make crypto_memneq work correctly (with
data-independent timing) even if it is inlined at its call sites. That
can be done later in a followup patch.

Compile-tested on x86_64.

Signed-off-by: Cesar Eduardo Barros 


This approach using __asm__ ("" : "=r" (var) : "0" (var)) to try to
prevent compiler optimizations of var is interesting.


It is not novel; I copied it from RELOC_HIDE.


I like the fact that it's finer-grained than -Os and doesn't preclude
inlining.

One concern would be that __asm__ could be optimized out unless
__volatile__ is present.


It cannot be optimized out, because the __asm__'s output is used. Of 
course, if the __asm__ output is never used, it could be optimized out, 
but that is the desired result in this case (it means the result of 
crypto_memneq is being ignored, so the whole function should be elided).


AFAIK, __volatile__ also has the side effect that it forces ordering 
with everything (this fact is used in the definition of the barrier() 
macro). This level of barrier is not needed for crypto_memneq; ordering 
on "neq" is more than enough.


--
Cesar Eduardo Barros
ces...@cesarb.eti.br
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] ARM: OMAP4: hwmod: add hwmod data for DES IP

[Joel Fernandes]

On 11/25/2013 04:11 PM, Tony Lindgren wrote:
> * Joel Fernandes  [131125 13:45]:
>> +
>> +static struct omap_hwmod_addr_space omap4_des_addrs[] = {
>> +{
>> +.pa_start   = 0x480A4000,
>> +.pa_end = 0x481A4000,
>> +.flags  = ADDR_TYPE_RT
>> +},
>> +{ }
>> +};
> 
> Let's not add new address space entries. The address
> space should be already coming from device tree.
> 
Sorry, yes. that's true - I'll drop these.

thanks,

-Joel

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

Re: [PATCH 0/7] AES/DES hwmod data and dmtimer fix

[Joel Fernandes]

On 11/25/2013 04:12 PM, Tony Lindgren wrote:
> * Joel Fernandes  [131125 13:46]:
>> Here are patches adding hwmod for AES/DES crypto modules for OMAP4, DRA7 
>> SoCs.
>>
>> Also included is a fix that disables POSTED mode when dmtimer is requested.
>>
>> Joel Fernandes (7):
>>   ARM: OMAP: hwmod: Add SYSC offsets for AES IP
>>   ARM: DRA7xx: hwmod: Add hwmod data for DES IP
>>   ARM: DRA7xx: hwmod: Add hwmod data for AES IP
>>   ARM: OMAP4: hwmod: Add hwmod data for AES IP
>>   ARM: OMAP4: hwmod: add hwmod data for DES IP
>>   ARM: OMAP: Disable POSTED mode for errata i103 and i767
>>   OMAP: AM33xx: hwmod: Correct AES module SYSC type
>>
>>  arch/arm/mach-omap2/omap_hwmod.h   |  11 +++
>>  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |   1 +
>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 101 
>> +
>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  78 
>>  arch/arm/mach-omap2/omap_hwmod_common_data.c   |  10 ++
>>  arch/arm/plat-omap/include/plat/dmtimer.h  |   5 +-
>>  6 files changed, 205 insertions(+), 1 deletion(-)
> 
> To me it seems we should wait on these until we have the clocks
> coming from device tree. That leaves out some parts of this
> patchset.
> 

Ok, sure. Let me see which parts can go in now till DT entries are available. If
it doesn't make sense to apply these now, I'll revise and post them again later
once clock data is merged.

thanks,

-Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: i2c-hid: disable interrupt on suspend

[Jiri Kosina]

On Mon, 25 Nov 2013, Benjamin Tissoires wrote:

> > When an I2C HID device is powered of during system sleep, as a result of
> > removing its power resources (by the ACPI core) the interrupt line might go
> > low as well. This results inadvertent interrupt and wakes the system from
> > sleep immediately.
> > 
> > To prevent this we disable the device interrupt in the drivers suspend
> > method and enable it on resume. The device can still wake the system up if
> > it is wake capable (this also means that not all of its power will be
> > removed to keep the interrupt line high).
> > 
> > Reported-by: Jerome Blin 
> > Signed-off-by: Mika Westerberg 
> > ---
> 
> Jiri, just FYI, I still do not have any final consumer ready i2c-hid
> hardware. So I can not test/debug anything related to the suspend-resume.
> 
> If Mika tested it properly (which I expect), you may consider pulling
> this one.

Understood, thanks guys.

Applied now.

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

Re: [PATCH 1/2] PCI: Do not use PCI ID macros in quirk names

[Bjorn Helgaas]

On Tue, Nov 12, 2013 at 1:40 AM, Michal Marek  wrote:
> On 11.11.2013 14:40, Michal Marek wrote:
>> Pasting the verbatim PCI_(VENDOR|DEVICE)_* macros in the __pci_fixup_*
>> symbol names results in insanely long names such as
>>
>> __pci_fixup_resumePCI_VENDOR_ID_SERVERWORKSPCI_DEVICE_ID_SERVERWORKS_HT1000SBquirk_disable_broadcom_boot_interrupt
>>
>> When LTO adds its numeric suffix to such symbol, it overflows the
>> namebuf[KSYM_NAME_LEN] array. Use the line number instead to create
>
> "... the namebuf[KSYM_NAME_LEN] array in kernel/kallsyms.c."

What's LTO?  I guess it's Link Time Optimization?  Is there any
documentation about how it works or how to use it?

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

Re: [PATCH 6/7] ARM: OMAP: Disable POSTED mode for errata i103 and i767

[Joel Fernandes]

On 11/25/2013 04:14 PM, Tony Lindgren wrote:
> * Joel Fernandes  [131125 13:46]:
>> Enabling of Posted mode is seen to cause problems on dmtimer modules on 
>> AM33xx
>> (much like other OMAPs).  Reference discussions on forums [1] [2]. Earlier
>> patch solving this on other OMAPs [3].
>>
>> For OMAP SoCs with this errata, the fix has been to not enable Posted mode.
>> However, on some SoCs (atleast AM33xx) which carry this errata, Posted mode
>> is enabled on reset. So we not only need to ignore enabling of the POSTED bit
>> when the timer is requested, but also disable Posted mode if errata is 
>> present.
> 
> This could explain some occasional lost timers I saw a while back when
> testing things.. We most likely should merge for the -rc series with cc 
> stable.

Sure, I agree.

> 
> Does this depend on the other patches in this series?
> 

No it doesn't depend.


thanks,

-Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] acpi: Add BayTrail SoC GPIO and LPSS ACPI IDs

[Paul Drews]

This adds the new ACPI ID (INT33FC) for the BayTrail GPIO
banks as seen on a BayTrail M System-On-Chip platform.  This
ACPI ID is used by the BayTrail GPIO (pinctrl) driver to
manage the Low Power Subsystem (LPSS).

Signed-off-by: Paul Drews 
---
 drivers/acpi/acpi_lpss.c   | 1 +
 drivers/pinctrl/pinctrl-baytrail.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 6745fe1..e603905 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -162,6 +162,7 @@ static const struct acpi_device_id acpi_lpss_device_ids[] = 
{
{ "80860F14", (unsigned long)_sdio_dev_desc },
{ "80860F41", (unsigned long)_i2c_dev_desc },
{ "INT33B2", },
+   { "INT33FC", },
 
{ "INT3430", (unsigned long)_dev_desc },
{ "INT3431", (unsigned long)_dev_desc },
diff --git a/drivers/pinctrl/pinctrl-baytrail.c 
b/drivers/pinctrl/pinctrl-baytrail.c
index 2832576..114f5ef 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -512,6 +512,7 @@ static const struct dev_pm_ops byt_gpio_pm_ops = {
 
 static const struct acpi_device_id byt_gpio_acpi_match[] = {
{ "INT33B2", 0 },
+   { "INT33FC", 0 },
{ }
 };
 MODULE_DEVICE_TABLE(acpi, byt_gpio_acpi_match);
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] use -fstack-protector-strong

[Kees Cook]

Build the kernel with -fstack-protector-strong when it is available
(gcc 4.9 and later). This increases the coverage of the stack protector
without the heavy performance hit of -fstack-protector-all.

On a Chrome OS kernel build, this grows the uncompressed kernel image
by less than 0.16% on x86:

  -rwxr-xr-x 1 keescook portage 118219343 Apr 17 12:26 vmlinux.old
  -rwxr-xr-x 1 keescook portage 118407919 Apr 19 15:00 vmlinux

ARM's compressed boot code now triggers stack protection, so a static
guard was added. Since this is only used during decompression and was
never used before, the exposure here is very small. Once it switches to
the full kernel, the stack guard is back to normal.

Signed-off-by: Kees Cook 
---
 arch/arm/Makefile   |3 ++-
 arch/arm/boot/compressed/misc.c |   14 ++
 arch/x86/Makefile   |2 +-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c99b1086d83d..c6d3ea1c063e 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -41,7 +41,8 @@ KBUILD_CFLAGS +=-fno-omit-frame-pointer -mapcs 
-mno-sched-prolog
 endif
 
 ifeq ($(CONFIG_CC_STACKPROTECTOR),y)
-KBUILD_CFLAGS  +=-fstack-protector
+KBUILD_CFLAGS  += $(call cc-option,-fstack-protector-strong,-fstack-protector)
+
 endif
 
 ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 31bd43b82095..d4f891f56996 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -127,6 +127,18 @@ asmlinkage void __div0(void)
error("Attempting division by 0!");
 }
 
+unsigned long __stack_chk_guard;
+
+void __stack_chk_guard_setup(void)
+{
+   __stack_chk_guard = 0x000a0dff;
+}
+
+void __stack_chk_fail(void)
+{
+   error("stack-protector: Kernel stack is corrupted\n");
+}
+
 extern int do_decompress(u8 *input, int len, u8 *output, void (*error)(char 
*x));
 
 
@@ -137,6 +149,8 @@ decompress_kernel(unsigned long output_start, unsigned long 
free_mem_ptr_p,
 {
int ret;
 
+   __stack_chk_guard_setup();
+
output_data = (unsigned char *)output_start;
free_mem_ptr= free_mem_ptr_p;
free_mem_end_ptr= free_mem_ptr_end_p;
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 41250fb33985..4ebb054cc323 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -86,7 +86,7 @@ endif
 ifdef CONFIG_CC_STACKPROTECTOR
cc_has_sp := $(srctree)/scripts/gcc-x86_$(BITS)-has-stack-protector.sh
 ifeq ($(shell $(CONFIG_SHELL) $(cc_has_sp) $(CC) $(KBUILD_CPPFLAGS) 
$(biarch)),y)
-stackp-y := -fstack-protector
+stackp-y := $(call 
cc-option,-fstack-protector-strong,-fstack-protector)
 KBUILD_CFLAGS += $(stackp-y)
 else
 $(warning stack protector enabled but no compiler support)
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] ARM: OMAP: Disable POSTED mode for errata i103 and i767

[Tony Lindgren]

* Joel Fernandes  [131125 13:46]:
> Enabling of Posted mode is seen to cause problems on dmtimer modules on AM33xx
> (much like other OMAPs).  Reference discussions on forums [1] [2]. Earlier
> patch solving this on other OMAPs [3].
> 
> For OMAP SoCs with this errata, the fix has been to not enable Posted mode.
> However, on some SoCs (atleast AM33xx) which carry this errata, Posted mode
> is enabled on reset. So we not only need to ignore enabling of the POSTED bit
> when the timer is requested, but also disable Posted mode if errata is 
> present.

This could explain some occasional lost timers I saw a while back when
testing things.. We most likely should merge for the -rc series with cc stable.

Does this depend on the other patches in this series?

Regards,

Tony
 
> [1] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/285744.aspx
> [2] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/270632.aspx
> [3] http://www.spinics.net/lists/linux-omap/msg81770.html
> 
> Reported-by: Russ Dill 
> Cc: Santosh Shilimkar 
> Signed-off-by: Joel Fernandes 
> ---
>  arch/arm/plat-omap/include/plat/dmtimer.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h 
> b/arch/arm/plat-omap/include/plat/dmtimer.h
> index fb92abb..2861b15 100644
> --- a/arch/arm/plat-omap/include/plat/dmtimer.h
> +++ b/arch/arm/plat-omap/include/plat/dmtimer.h
> @@ -336,8 +336,11 @@ static inline void __omap_dm_timer_enable_posted(struct 
> omap_dm_timer *timer)
>   if (timer->posted)
>   return;
>  
> - if (timer->errata & OMAP_TIMER_ERRATA_I103_I767)
> + if (timer->errata & OMAP_TIMER_ERRATA_I103_I767) {
> + timer->posted = OMAP_TIMER_NONPOSTED;
> + __omap_dm_timer_write(timer, OMAP_TIMER_IF_CTRL_REG, 0, 0);
>   return;
> + }
>  
>   __omap_dm_timer_write(timer, OMAP_TIMER_IF_CTRL_REG,
> OMAP_TIMER_CTRL_POSTED, 0);
> -- 
> 1.8.1.2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 15/23] usb: musb: raw read and write endian fix

[Felipe Balbi]

Hi,

On Mon, Nov 25, 2013 at 04:07:49PM -0600, Felipe Balbi wrote:
> On Sat, Nov 16, 2013 at 02:01:18AM +0200, Taras Kondratiuk wrote:
> > From: Victor Kamensky 
> > 
> > All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> > Need to use endian neutral functions to read/write h/w registers.
> > I.e instead of __raw_read[lw] and __raw_write[lw] functions code
> > need to use read[lw]_relaxed and write[lw]_relaxed functions.
> > If the first simply reads/writes register, the second will byteswap
> > it if host operates in BE mode.
> > 
> > Changes are trivial sed like replacement of __raw_xxx functions
> > with xxx_relaxed variant.
> > 
> > Signed-off-by: Victor Kamensky 
> > Signed-off-by: Taras Kondratiuk 
> > ---
> >  drivers/usb/musb/musb_io.h |   18 +-
> >  1 file changed, 9 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
> > index eebeed7..76f4d2a 100644
> > --- a/drivers/usb/musb/musb_io.h
> > +++ b/drivers/usb/musb/musb_io.h
> > @@ -42,17 +42,17 @@
> >  /* NOTE:  these offsets are all in bytes */
> >  
> >  static inline u16 musb_readw(const void __iomem *addr, unsigned offset)
> > -   { return __raw_readw(addr + offset); }
> > +   { return readw_relaxed(addr + offset); }
> 
> x86 doesn't provide any of the write?_relaxed methods so this breaks
> build on x86 at least.

here's an untested patch which would "solve" the problem:

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34f69cb..b6ad164 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -73,6 +73,9 @@ build_mmio_write(__writel, "l", unsigned int, "r", )
 #define __raw_readw __readw
 #define __raw_readl __readl
 
+#define writeb_relaxed(d, a) __writeb(d, a)
+#define writew_relaxed(d, a) __writew(d, a)
+#define writel_relaxed(d, a) __writel(d, a)
 #define __raw_writeb __writeb
 #define __raw_writew __writew
 #define __raw_writel __writel
@@ -85,6 +88,7 @@ build_mmio_read(readq, "q", unsigned long, "=r", :"memory")
 build_mmio_write(writeq, "q", unsigned long, "r", :"memory")
 
 #define readq_relaxed(a)   readq(a)
+#define writeq_relaxed(d, a)   writeq(d, a)
 
 #define __raw_readq(a) readq(a)
 #define __raw_writeq(val, addr)writeq(val, addr)


I'm not sure if it's correct though. Someone would have to tell me if
it's correct or not. For now, I have dropped $subject from my
testing/next branch.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] procfs: also fix proc_reg_get_unmapped_area() for !MMU case

[Andrew Morton]

On Mon, 25 Nov 2013 16:22:31 + "Jan Beulich"  wrote:

> Commit fad1a86e ("procfs: call default get_unmapped_area on MMU-present
> architectures"), as its title says, took care of only the MMU case,
> leaving the !MMU side still in the regressed state (returning -EIO in
> all cases where pde->proc_fops->get_unmapped_area is NULL).

The changelog is rather mystifying unless the reader goes off and finds
the fad1a86e changelog, so let's do that for them by adding this:

>From the fad1a86e changelog:

: Commit c4fe24485729 ("sparc: fix PCI device proc file mmap(2)") added
: proc_reg_get_unmapped_area in proc_reg_file_ops and
: proc_reg_file_ops_no_compat, by which now mmap always returns EIO if
: get_unmapped_area method is not defined for the target procfs file, which
: causes regression of mmap on /proc/vmcore.
: 
: To address this issue, like get_unmapped_area(), call default
: current->mm->get_unmapped_area on MMU-present architectures if
: pde->proc_fops->get_unmapped_area, i.e.  the one in actual file operation
: in the procfs file, is not defined.

> Signed-off-by: Jan Beulich 
> Cc: HATAYAMA Daisuke 
> Cc: Alexey Dobriyan 
> Cc: David S. Miller  

I tagged this with

Cc: [3.12.x]

OK?

> +++ 3.13-rc1-proc-get-unmapped-area/fs/proc/inode.c
> @@ -292,16 +292,19 @@ proc_reg_get_unmapped_area(struct file *
>  {
>   struct proc_dir_entry *pde = PDE(file_inode(file));
>   unsigned long rv = -EIO;
> - unsigned long (*get_area)(struct file *, unsigned long, unsigned long,
> -   unsigned long, unsigned long) = NULL;
> +
>   if (use_pde(pde)) {
> + typeof(proc_reg_get_unmapped_area) *get_area
>  #ifdef CONFIG_MMU
> - get_area = current->mm->get_unmapped_area;
> + = pde->proc_fops->get_unmapped_area
> +   ?: current->mm->get_unmapped_area;
> +#else
> + = pde->proc_fops->get_unmapped_area;
>  #endif
> - if (pde->proc_fops->get_unmapped_area)
> - get_area = pde->proc_fops->get_unmapped_area;
> - if (get_area)
> - rv = get_area(file, orig_addr, len, pgoff, flags);
> +
> + rv = get_area
> +  ? get_area(file, orig_addr, len, pgoff, flags)
> +  : orig_addr;
>   unuse_pde(pde);
>   }
>   return rv;

That function has gone from bad to worse :(

How does this version look?

It would be acceptable and beneficial to create a new get_unmapped_area_t.

: static unsigned long
: proc_reg_get_unmapped_area(struct file *file, unsigned long orig_addr,
:  unsigned long len, unsigned long pgoff,
:  unsigned long flags)
: {
:   struct proc_dir_entry *pde = PDE(file_inode(file));
:   unsigned long rv = -EIO;
: 
:   if (use_pde(pde)) {
:   typeof(proc_reg_get_unmapped_area) *get_area;
: 
:   get_area = pde->proc_fops->get_unmapped_area;
: #ifdef CONFIG_MMU
:   if (!get_area)
:   get_area = current->mm->get_unmapped_area;
: #endif
: 
:   if (get_area)
:   rv = get_area(file, orig_addr, len, pgoff, flags);
:   else
:   rv = orig_addr;
:   unuse_pde(pde);
:   }
:   return rv;
: }

--- 
a/fs/proc/inode.c~procfs-also-fix-proc_reg_get_unmapped_area-for-mmu-case-fix
+++ a/fs/proc/inode.c
@@ -294,17 +294,18 @@ proc_reg_get_unmapped_area(struct file *
unsigned long rv = -EIO;
 
if (use_pde(pde)) {
-   typeof(proc_reg_get_unmapped_area) *get_area
+   typeof(proc_reg_get_unmapped_area) *get_area;
+
+   get_area = pde->proc_fops->get_unmapped_area;
 #ifdef CONFIG_MMU
-   = pde->proc_fops->get_unmapped_area
- ?: current->mm->get_unmapped_area;
-#else
-   = pde->proc_fops->get_unmapped_area;
+   if (!get_area)
+   get_area = current->mm->get_unmapped_area;
 #endif
 
-   rv = get_area
-? get_area(file, orig_addr, len, pgoff, flags)
-: orig_addr;
+   if (get_area)
+   rv = get_area(file, orig_addr, len, pgoff, flags);
+   else
+   rv = orig_addr;
unuse_pde(pde);
}
return rv;
_

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regmap: use IS_ERR() to check clk_get() results

[Stephen Warren]

From: Stephen Warren 

clk_get() returns an error pointer, or a valid token to pass back to the
clock API. Hence, the result must be checked with IS_ERR(), not by
comparison against NULL.

Signed-off-by: Stephen Warren 
---
 drivers/base/regmap/regmap-mmio.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/base/regmap/regmap-mmio.c 
b/drivers/base/regmap/regmap-mmio.c
index 98745dd77e8c..81f977510775 100644
--- a/drivers/base/regmap/regmap-mmio.c
+++ b/drivers/base/regmap/regmap-mmio.c
@@ -40,7 +40,7 @@ static int regmap_mmio_gather_write(void *context,
 
BUG_ON(reg_size != 4);
 
-   if (ctx->clk) {
+   if (!IS_ERR(ctx->clk)) {
ret = clk_enable(ctx->clk);
if (ret < 0)
return ret;
@@ -73,7 +73,7 @@ static int regmap_mmio_gather_write(void *context,
offset += ctx->val_bytes;
}
 
-   if (ctx->clk)
+   if (!IS_ERR(ctx->clk))
clk_disable(ctx->clk);
 
return 0;
@@ -96,7 +96,7 @@ static int regmap_mmio_read(void *context,
 
BUG_ON(reg_size != 4);
 
-   if (ctx->clk) {
+   if (!IS_ERR(ctx->clk)) {
ret = clk_enable(ctx->clk);
if (ret < 0)
return ret;
@@ -129,7 +129,7 @@ static int regmap_mmio_read(void *context,
offset += ctx->val_bytes;
}
 
-   if (ctx->clk)
+   if (!IS_ERR(ctx->clk))
clk_disable(ctx->clk);
 
return 0;
@@ -139,7 +139,7 @@ static void regmap_mmio_free_context(void *context)
 {
struct regmap_mmio_context *ctx = context;
 
-   if (ctx->clk) {
+   if (!IS_ERR(ctx->clk)) {
clk_unprepare(ctx->clk);
clk_put(ctx->clk);
}
@@ -209,6 +209,7 @@ static struct regmap_mmio_context 
*regmap_mmio_gen_context(struct device *dev,
 
ctx->regs = regs;
ctx->val_bytes = config->val_bits / 8;
+   ctx->clk = ERR_PTR(-ENODEV);
 
if (clk_id == NULL)
return ctx;
-- 
1.8.1.5

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

Re: [PATCH 0/7] AES/DES hwmod data and dmtimer fix

[Tony Lindgren]

* Joel Fernandes  [131125 13:46]:
> Here are patches adding hwmod for AES/DES crypto modules for OMAP4, DRA7 SoCs.
> 
> Also included is a fix that disables POSTED mode when dmtimer is requested.
> 
> Joel Fernandes (7):
>   ARM: OMAP: hwmod: Add SYSC offsets for AES IP
>   ARM: DRA7xx: hwmod: Add hwmod data for DES IP
>   ARM: DRA7xx: hwmod: Add hwmod data for AES IP
>   ARM: OMAP4: hwmod: Add hwmod data for AES IP
>   ARM: OMAP4: hwmod: add hwmod data for DES IP
>   ARM: OMAP: Disable POSTED mode for errata i103 and i767
>   OMAP: AM33xx: hwmod: Correct AES module SYSC type
> 
>  arch/arm/mach-omap2/omap_hwmod.h   |  11 +++
>  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |   1 +
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 101 
> +
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  78 
>  arch/arm/mach-omap2/omap_hwmod_common_data.c   |  10 ++
>  arch/arm/plat-omap/include/plat/dmtimer.h  |   5 +-
>  6 files changed, 205 insertions(+), 1 deletion(-)

To me it seems we should wait on these until we have the clocks
coming from device tree. That leaves out some parts of this
patchset.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] ARM: OMAP4: hwmod: add hwmod data for DES IP

[Tony Lindgren]

* Joel Fernandes  [131125 13:45]:
> +
> +static struct omap_hwmod_addr_space omap4_des_addrs[] = {
> + {
> + .pa_start   = 0x480A4000,
> + .pa_end = 0x481A4000,
> + .flags  = ADDR_TYPE_RT
> + },
> + { }
> +};

Let's not add new address space entries. The address
space should be already coming from device tree.

Regards,

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

Re: [RFC 15/23] usb: musb: raw read and write endian fix

[Felipe Balbi]

On Sat, Nov 16, 2013 at 02:01:18AM +0200, Taras Kondratiuk wrote:
> From: Victor Kamensky 
> 
> All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> Need to use endian neutral functions to read/write h/w registers.
> I.e instead of __raw_read[lw] and __raw_write[lw] functions code
> need to use read[lw]_relaxed and write[lw]_relaxed functions.
> If the first simply reads/writes register, the second will byteswap
> it if host operates in BE mode.
> 
> Changes are trivial sed like replacement of __raw_xxx functions
> with xxx_relaxed variant.
> 
> Signed-off-by: Victor Kamensky 
> Signed-off-by: Taras Kondratiuk 
> ---
>  drivers/usb/musb/musb_io.h |   18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
> index eebeed7..76f4d2a 100644
> --- a/drivers/usb/musb/musb_io.h
> +++ b/drivers/usb/musb/musb_io.h
> @@ -42,17 +42,17 @@
>  /* NOTE:  these offsets are all in bytes */
>  
>  static inline u16 musb_readw(const void __iomem *addr, unsigned offset)
> - { return __raw_readw(addr + offset); }
> + { return readw_relaxed(addr + offset); }

x86 doesn't provide any of the write?_relaxed methods so this breaks
build on x86 at least.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/5] mm: compaction: encapsulate defer reset logic

[Rik van Riel]

On 11/25/2013 09:26 AM, Vlastimil Babka wrote:

Currently there are several functions to manipulate the deferred compaction
state variables. The remaining case where the variables are touched directly
is when a successful allocation occurs in direct compaction, or is expected
to be successful in the future by kswapd. Here, the lowest order that is
expected to fail is updated, and in the case of direct compaction, the deferred
status is reset completely.

Create a new function compaction_defer_reset() to encapsulate this
functionality and make it easier to understand the code. No functional change.

Cc: Mel Gorman 
Cc: Rik van Riel 
Signed-off-by: Vlastimil Babka 


Reviewed-by: Rik van Riel 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: Move device_del() from pci_stop_dev() to pci_destroy_dev()

[Rafael J. Wysocki]

On Monday, November 25, 2013 02:59:44 PM Bjorn Helgaas wrote:
> On Sat, Nov 23, 2013 at 5:17 PM, Rafael J. Wysocki  wrote:
> > From: Rafael J. Wysocki 
> >
> > After commit bcdde7e221a8 (sysfs: make __sysfs_remove_dir() recursive)
> > I'm seeing traces analogous to the one below in Thunderbolt testing:

[...]

> > (Mika Westerberg sees them too in his tests).
> >
> > Some investigation documented in kernel bug #65281 lead me to the
> > conclusion that the source of the problem is the device_del() in
> > pci_stop_dev() as it now causes the sysfs directory of the device
> > to be removed recursively along with all of its subdirectories.
> > That includes the sysfs directory of the device's subordinate
> > bus (dev->subordinate) and its "power" group.
> >
> > Consequently, when pci_remove_bus() is called for dev->subordinate
> > in pci_remove_bus_device(), it calls device_unregister(>dev),
> > but at this point the sysfs directory of bus->dev doesn't exist any
> > more and its "power" group doesn't exist either.  Thus, when
> > dpm_sysfs_remove() called from device_del() tries to remove that
> > group, it triggers the above warning.
> >
> > That indicates a logical mistake in the design of
> > pci_stop_and_remove_bus_device(), which causes bus device objects
> > to be left behind their parents (bridge device objects) and can be
> > fixed by moving the device_del() from pci_stop_dev() into
> > pci_destroy_dev(), so pci_remove_bus() can be called for the
> > device's subordinate bus before the device itself is unregistered
> > from the hierarchy.  Still, the driver, if any, should be detached
> > from the device in pci_stop_dev(), so use device_release_driver()
> > directly from there.
> >
> > References: https://bugzilla.kernel.org/show_bug.cgi?id=65281#c6
> > Reported-by: Mika Westerberg 
> > Signed-off-by: Rafael J. Wysocki 
> 
> Applied to for-linus for v3.13.  Thanks a lot for all your work on this issue!

Thanks, and no problem! :-)

Rafael

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

Re: [PATCH] selinux: fix possible memory leak

[Paul Moore]

On Sunday, November 24, 2013 08:37:01 AM Geyslan G. Bem wrote:
> Free 'ctx_str' when necessary.
> 
> Signed-off-by: Geyslan G. Bem 
> ---
>  security/selinux/xfrm.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)

Nice catch, applied.

> diff --git a/security/selinux/xfrm.c b/security/selinux/xfrm.c
> index a91d205..cf79a45 100644
> --- a/security/selinux/xfrm.c
> +++ b/security/selinux/xfrm.c
> @@ -327,19 +327,22 @@ int selinux_xfrm_state_alloc_acquire(struct xfrm_state
> *x, return rc;
> 
>   ctx = kmalloc(sizeof(*ctx) + str_len, GFP_ATOMIC);
> - if (!ctx)
> - return -ENOMEM;
> + if (!ctx) {
> + rc = -ENOMEM;
> + goto out;
> + }
> 
>   ctx->ctx_doi = XFRM_SC_DOI_LSM;
>   ctx->ctx_alg = XFRM_SC_ALG_SELINUX;
>   ctx->ctx_sid = secid;
>   ctx->ctx_len = str_len;
>   memcpy(ctx->ctx_str, ctx_str, str_len);
> - kfree(ctx_str);
> 
>   x->security = ctx;
>   atomic_inc(_xfrm_refcount);
> - return 0;
> +out:
> + kfree(ctx_str);
> + return rc;
>  }
> 
>  /*

-- 
paul moore
www.paul-moore.com

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

3.12.0: sda2: WRITE SAME failed. Manually zeroing. with 3w-xxxx driver

[Justin Piszcz]

Hello,

Using 3.12.0 and ext4fs with 2 x SSDs in a RAID-1 configuration on a
3ware HW RAID card, no md/dm, I noticed the following recently:
[178339.353565] sda2: WRITE SAME failed. Manually zeroing.

It seems to be similar to this issue here:
http://permalink.gmane.org/gmane.linux.kernel/1494512

Relevant logs:
[178339.353519] 3w-sas: scsi0: ERROR: (0x03:0x0101): Invalid command
opcode:opcode=0x41.
[178339.353565] sda2: WRITE SAME failed. Manually zeroing.

Is this something I should be worried about?
I am running a database on the host, could that be the cause of it?
(in the related post, he was also running a DB).

Justin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: Move device_del() from pci_stop_dev() to pci_destroy_dev()

[Bjorn Helgaas]

On Sat, Nov 23, 2013 at 5:17 PM, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> After commit bcdde7e221a8 (sysfs: make __sysfs_remove_dir() recursive)
> I'm seeing traces analogous to the one below in Thunderbolt testing:
>
> WARNING: CPU: 3 PID: 76 at /scratch/rafael/work/linux-pm/fs/sysfs/group.c:214 
> sysfs_remove_group+0x59/0xe0()
>  sysfs group 81c6c500 not found for kobject ':08'
>  Modules linked in: fuse hidp af_packet xt_tcpudp xt_pkttype xt_LOG xt_limit 
> ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT 
> iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns 
> nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables 
> xt_conntrack nf_conntrack rfcomm ip6table_filter bnep ip6_tables x_tables 
> arc4 ath9k mac80211 x86_pkg_temp_thermal intel_powerclamp coretemp 
> crct10dif_pclmul crc32_pclmul iTCO_wdt crc32c_intel iTCO_vendor_support 
> ghash_clmulni_intel aesni_intel ablk_helper acer_wmi sparse_keymap 
> ath9k_common ath9k_hw cryptd lrw gf128mul ath3k glue_helper aes_x86_64 btusb 
> microcode ath pcspkr joydev uvcvideo serio_raw videobuf2_core i2c_i801 
> videodev snd_hda_codec_hdmi cfg80211 videobuf2_vmalloc tg3 videobuf2_memops 
> sg ptp pps_core lpc_ich mfd_core snd_hda_codec_realtek bluetooth 
> hid_logitech_dj rfkill snd_hda_intel snd_hda_codec shpchp battery ac wmi 
> acpi_cpufreq edd snd_usb_audio snd_pcm snd_page_alloc snd_hwdep snd_u
 sbmidi_lib
> snd_rawmidi snd_seq snd_timer snd_seq_device snd soundcore autofs4 xhci_hcd 
> processor scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_dh
>  CPU: 3 PID: 76 Comm: kworker/u16:7 Not tainted 3.13.0-rc1+ #76
>  Hardware name: Acer Aspire S5-391/Venus, BIOS V1.02 05/29/2012
>  Workqueue: kacpi_hotplug acpi_hotplug_work_fn
>   0009 8801644b9ac8 816b23bf 0007
>   8801644b9b18 8801644b9b08 81046607 88016925b800
>    81c6c500 88016924f928 88016924f800
>  Call Trace:
>   [] dump_stack+0x4e/0x71
>   [] warn_slowpath_common+0x87/0xb0
>   [] warn_slowpath_fmt+0x41/0x50
>   [] ? sysfs_get_dirent_ns+0x6f/0x80
>   [] sysfs_remove_group+0x59/0xe0
>   [] dpm_sysfs_remove+0x3b/0x50
>   [] device_del+0x58/0x1c0
>   [] device_unregister+0x48/0x60
>   [] pci_remove_bus+0x6e/0x80
>   [] pci_remove_bus_device+0x38/0x110
>   [] pci_remove_bus_device+0x4d/0x110
>   [] pci_stop_and_remove_bus_device+0x19/0x20
>   [] disable_slot+0x20/0xe0
>   [] acpiphp_check_bridge+0xa8/0xd0
>   [] hotplug_event+0x17d/0x220
>   [] hotplug_event_work+0x30/0x70
>   [] acpi_hotplug_work_fn+0x18/0x24
>   [] process_one_work+0x261/0x450
>   [] worker_thread+0x21e/0x370
>   [] ? rescuer_thread+0x300/0x300
>   [] kthread+0xd2/0xe0
>   [] ? flush_kthread_worker+0x70/0x70
>   [] ret_from_fork+0x7c/0xb0
>   [] ? flush_kthread_worker+0x70/0x70
>
> (Mika Westerberg sees them too in his tests).
>
> Some investigation documented in kernel bug #65281 lead me to the
> conclusion that the source of the problem is the device_del() in
> pci_stop_dev() as it now causes the sysfs directory of the device
> to be removed recursively along with all of its subdirectories.
> That includes the sysfs directory of the device's subordinate
> bus (dev->subordinate) and its "power" group.
>
> Consequently, when pci_remove_bus() is called for dev->subordinate
> in pci_remove_bus_device(), it calls device_unregister(>dev),
> but at this point the sysfs directory of bus->dev doesn't exist any
> more and its "power" group doesn't exist either.  Thus, when
> dpm_sysfs_remove() called from device_del() tries to remove that
> group, it triggers the above warning.
>
> That indicates a logical mistake in the design of
> pci_stop_and_remove_bus_device(), which causes bus device objects
> to be left behind their parents (bridge device objects) and can be
> fixed by moving the device_del() from pci_stop_dev() into
> pci_destroy_dev(), so pci_remove_bus() can be called for the
> device's subordinate bus before the device itself is unregistered
> from the hierarchy.  Still, the driver, if any, should be detached
> from the device in pci_stop_dev(), so use device_release_driver()
> directly from there.
>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=65281#c6
> Reported-by: Mika Westerberg 
> Signed-off-by: Rafael J. Wysocki 

Applied to for-linus for v3.13.  Thanks a lot for all your work on this issue!

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

Re: Possible regression with cgroups in 3.11

[Bjorn Helgaas]

On Wed, Nov 20, 2013 at 9:47 PM, Bjorn Helgaas  wrote:
> [+cc Jiri]
>
> On Wed, Nov 20, 2013 at 9:26 PM, Sasha Levin  wrote:
>> On 11/18/2013 03:39 PM, Bjorn Helgaas wrote:
>>>
>>> On Mon, Nov 18, 2013 at 11:29:32AM -0800, Yinghai Lu wrote:

 On Mon, Nov 18, 2013 at 10:14 AM, Bjorn Helgaas 
 wrote:
>>
>> A bit of comment here would be nice but yeah I think this should work.
>> Can you please also queue the revert of c2fda509667b ("workqueue:
>> allow work_on_cpu() to be called recursively") after this patch?
>> Please feel free to add my acked-by.
>
>
> OK, below are the two patches (Alex's fix + the revert) I propose to
> merge.  Unless there are objections, I'll ask Linus to pull these
> before v3.13-rc1.
>
>
>
> commit 84f23f99b507c2c9247f47d3db0f71a3fd65e3a3
> Author: Alexander Duyck 
> Date:   Mon Nov 18 10:59:59 2013 -0700
>
>  PCI: Avoid unnecessary CPU switch when calling driver .probe()
> method
>
>  If we are already on a CPU local to the device, call the driver
> .probe()
>  method directly without using work_on_cpu().
>
>  This is a workaround for a lockdep warning in the following
> scenario:
>
>pci_call_probe
>  work_on_cpu(cpu, local_pci_probe, ...)
>driver .probe
>  pci_enable_sriov
>...
>  pci_bus_add_device
>...
>  pci_call_probe
>work_on_cpu(cpu, local_pci_probe, ...)
>
>  It would be better to fix PCI so we don't call VF driver .probe()
> methods
>  from inside a PF driver .probe() method, but that's a bigger
> project.
>
>  [bhelgaas: disable preemption, open bugzilla, rework comments &
> changelog]
>  Link: https://bugzilla.kernel.org/show_bug.cgi?id=65071
>  Link:
> http://lkml.kernel.org/r/CAE9FiQXYQEAZ=0sg6+2odffbqfls9mpon1xvirr9adbxpxc...@mail.gmail.com
>  Link:
> http://lkml.kernel.org/r/20130624195942.40795.27292.st...@ahduyck-cp1.jf.intel.com
>  Signed-off-by: Alexander Duyck 
>  Signed-off-by: Bjorn Helgaas 
>  Acked-by: Tejun Heo 


 Tested-by: Yinghai Lu 
 Acked-by: Yinghai Lu 
>>>
>>>
>>> Thanks, I added these and pushed my for-linus branch for -next to
>>> pick up before I ask Linus to pull them.
>>
>>
>> Hi guys,
>>
>> This patch seems to be causing virtio (wouldn't it happen with any other
>> driver too?) to give
>> the following spew:
>
> Yep, Jiri Slaby reported this earlier.  I dropped those patches for
> now.  Yinghai and I both tested this without incident, but we must
> have tested quite the same scenario you did.
>
> I'll look at this more tomorrow.  My first thought is that it's
> probably silly to worry about preemption when checking the node.  It's
> unlikely that we'd be preempted (probably not even possible except at
> hot add-time), and the worst that can happen is we run the .probe()
> method on the wrong node, which means worse performance but correct
> functionality.

I dropped the preempt_disable() and re-added this to my for-linus
branch.  Let me know if you see any more issues.

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

[PATCH] regulator: core: Use postcore_initcall(regulator_init_complete)

[Fabio Estevam]

From: Fabio Estevam 

Commit 22c1 (pwm-backlight: Add power supply support) introduced the usage
of regulator API into the pwm backlight driver and caused a regression on some 
boards like mx28evk and mx6qsabresd, resulting in blank display output:

pwm-backlight backlight.18: dummy supplies not allowed

Calling regulator_init_complete via late_initcall can be too 'late' for the 
regulator to be available for the pwm backlight driver.

Call regulator_init_complete with postcore_initcall level instead.

Signed-off-by: Fabio Estevam 
---
 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 3fe1313..d908a95 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3850,4 +3850,4 @@ unlock:
 
return 0;
 }
-late_initcall(regulator_init_complete);
+postcore_initcall(regulator_init_complete);
-- 
1.8.1.2

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

[GIT PULL] Immutable biovecs

[Kent Overstreet]

Jens - here's immutable biovecs, rebased and ready for 3.14. Changes since the
last version of the series:

 * bio_clone_bioset() retains the old behaviour, as previously discussed -
   bio_clone_fast() is being used by bcache, dm and the new bio_split().

   There aren't that many users of the old bio_clone() and we should eventually
   convert all the users that don't actually need it (for a couple of reasons),
   but that can be left to future cleanups.

 * refactoring patches to use submit_bio_wait() and bio_for_each_segment()

Regarding the bio chaining stuff, I'm not terribly happy with all the
bio_endio_nodec() calls but I want to keep that stuff simple for now - Mike
Snitzer had a good suggestion for that though. But I am seeing more and more
ways we can use that functionality to clean other stuff up - also, we should be
able to drop bi_cnt eventually, bi_remaining seems like it can be used to
replace the various bio_get() uses.

The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:

  Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)

are available in the git repository at:

  git://evilpiepirate.org/~kent/linux-bcache.git for-jens

for you to fetch changes up to 4b1faf931650d4a35b2a570318862821d6a962e3:

  block: Kill bio_pair_split() (2013-11-23 22:33:57 -0800)


Kent Overstreet (25):
  block: submit_bio_wait() conversions
  block: Convert various code to bio_for_each_segment()
  bcache: Kill unaligned bvec hack
  block: Abstract out bvec iterator
  dm: Use bvec_iter for dm_bio_record()
  block: Convert bio_iovec() to bvec_iter
  block: Convert bio_for_each_segment() to bvec_iter
  block: Immutable bio vecs
  block: Convert bio_copy_data() to bvec_iter
  bio-integrity: Convert to bvec_iter
  block: Kill bio_segments()/bi_vcnt usage
  block: Convert drivers to immutable biovecs
  aoe: Convert to immutable biovecs
  ceph: Convert to immutable biovecs
  block: Kill bio_iovec_idx(), __bio_iovec()
  block: Refactor bio_clone_bioset() for immutable biovecs
  block: Add bio_clone_fast()
  rbd: Refactor bio cloning
  dm: Refactor for new bio cloning/splitting
  block: Don't save/copy bvec array anymore
  block: Remove bi_idx hacks
  block: Generic bio chaining
  block: Rename bio_split() -> bio_pair_split()
  block: Introduce new bio_split()
  block: Kill bio_pair_split()

 Documentation/block/biodoc.txt  |   7 +-
 Documentation/block/biovecs.txt | 111 ++
 arch/m68k/emu/nfblock.c |  13 +-
 arch/powerpc/sysdev/axonram.c   |  21 +-
 block/blk-core.c|  40 +--
 block/blk-flush.c   |  21 +-
 block/blk-integrity.c   |  40 ++-
 block/blk-lib.c |  12 +-
 block/blk-map.c |   6 +-
 block/blk-merge.c   |  66 ++--
 block/blk-mq.c  |   2 +-
 block/blk-throttle.c|  14 +-
 block/elevator.c|   2 +-
 drivers/block/aoe/aoe.h |  10 +-
 drivers/block/aoe/aoecmd.c  | 153 -
 drivers/block/brd.c |  16 +-
 drivers/block/drbd/drbd_actlog.c|   2 +-
 drivers/block/drbd/drbd_bitmap.c|   2 +-
 drivers/block/drbd/drbd_main.c  |  27 +-
 drivers/block/drbd/drbd_receiver.c  |  19 +-
 drivers/block/drbd/drbd_req.c   |   6 +-
 drivers/block/drbd/drbd_req.h   |   2 +-
 drivers/block/drbd/drbd_worker.c|   8 +-
 drivers/block/floppy.c  |  16 +-
 drivers/block/loop.c|  27 +-
 drivers/block/mtip32xx/mtip32xx.c   |  20 +-
 drivers/block/nbd.c |  14 +-
 drivers/block/nvme-core.c   | 142 ++--
 drivers/block/pktcdvd.c | 182 +-
 drivers/block/ps3disk.c |  17 +-
 drivers/block/ps3vram.c |  12 +-
 drivers/block/rbd.c |  91 +
 drivers/block/rsxx/dev.c|   6 +-
 drivers/block/rsxx/dma.c|  15 +-
 drivers/block/umem.c|  53 ++-
 drivers/block/xen-blkback/blkback.c |   2 +-
 drivers/block/xen-blkfront.c|   2 +-
 drivers/md/bcache/bcache.h  |   2 -
 drivers/md/bcache/btree.c   |   8 +-
 drivers/md/bcache/debug.c   |  21 +-
 drivers/md/bcache/io.c  | 196 ++-
 drivers/md/bcache/journal.c |  12 +-
 drivers/md/bcache/movinggc.c|   4 +-
 drivers/md/bcache/request.c | 131 +++-
 drivers/md/bcache/super.c   |  20 +-
 

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Sebastian Reichel]

Hi,

On Mon, Nov 25, 2013 at 08:32:46PM +0200, Ивайло Димитров wrote:
> So, AIUI there are 2 options:
> 
> 1. charger driver polls the battery driver every n (60?) seconds.
> 2. battery driver sends PSY_EVENT_PROP_CHANGED on every degree
>up or down.
>  
> In both cases if the temperature is outside of the safe margins, the
> charging should be stopped.

ACK.

> 2 seems more generic to me, but as rx51-battery is missing the
> functionality to send events on temperature change, I guess 1 will
> be easier to implement.

The temperature must be polled anyway, if the ADC does not support
interrupts.

> And I think there should be some method (sysfs entry?, /dev/bqxxx
> opened?) to tell the charger driver to stop polling the battery 
> driver once (and if) the userspace has started to take care of the 
> battery temperature - makes no sense to duplicate the checks IMO.

I would just cache the temperature value in the battery driver for a
couple of seconds. Then userspace can check for very high temperatures
(-> system shutdown) and the charging driver can check for
temperatures, which are critical for charging.

-- Sebastian


signature.asc
Description: Digital signature

[PATCH 3/7] ARM: DRA7xx: hwmod: Add hwmod data for AES IP

[Joel Fernandes]

DRA7xx SoC has an AES IP found also on OMAP4. Add hwmod data for the same.

Signed-off-by: Joel Fernandes 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index efae736..5831ac6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -561,6 +561,17 @@ static struct omap_hwmod_class dra7xx_gpio_hwmod_class = {
.rev= 2,
 };
 
+static struct omap_hwmod_class_sysconfig dra7xx_aes_sysc = {
+   .rev_offs   = 0x0080,
+   .sysc_offs  = 0x0084,
+   .syss_offs  = 0x0088,
+   .sysc_flags = (SYSC_HAS_AUTOIDLE |
+  SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSS_HAS_RESET_STATUS),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= _hwmod_sysc_type4,
+};
+
 static struct omap_hwmod_class_sysconfig dra7xx_des_sysc = {
.rev_offs   = 0x0030,
.sysc_offs  = 0x0034,
@@ -572,6 +583,12 @@ static struct omap_hwmod_class_sysconfig dra7xx_des_sysc = 
{
.sysc_fields= _hwmod_sysc_type4,
 };
 
+static struct omap_hwmod_class dra7xx_aes_hwmod_class = {
+   .name   = "aes",
+   .sysc   = _aes_sysc,
+   .rev= 2,
+};
+
 static struct omap_hwmod_class dra7xx_des_hwmod_class = {
.name   = "des",
.sysc   = _des_sysc,
@@ -767,6 +784,19 @@ static struct omap_hwmod dra7xx_gpio8_hwmod = {
.dev_attr   = _dev_attr,
 };
 
+static struct omap_hwmod dra7xx_aes_hwmod = {
+   .name   = "aes",
+   .class  = _aes_hwmod_class,
+   .clkdm_name = "l4sec_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4SEC_AES1_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4SEC_AES1_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
+   },
+   },
+};
+
 static struct omap_hwmod dra7xx_des_hwmod = {
.name   = "des",
.class  = _des_hwmod_class,
@@ -2119,6 +2149,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi = 
{
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l3_main_1 -> aes */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__aes = {
+   .master = _l3_main_1_hwmod,
+   .slave  = _aes_hwmod,
+   .clk= "l3_iclk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
{
.pa_start   = 0x48078000,
@@ -2695,6 +2733,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
_l3_main_1__dss,
_l3_main_1__dispc,
_l3_main_1__hdmi,
+   _l3_main_1__aes,
_l4_per1__elm,
_l4_wkup__gpio1,
_l4_per1__gpio2,
-- 
1.8.1.2

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

[PATCH 4/7] ARM: OMAP4: hwmod: Add hwmod data for AES IP

[Joel Fernandes]

Crypto modules AES0/1 belong to:
PD_L4_PER power domain
CD_L4_SEC clock domain
On the L3, the AES modules are mapped to
L3_CLK2: Peripherals and multimedia sub clock domain

We add hwmod data for the same.

Signed-off-by: Joel Fernandes 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1e5b12c..664b2c6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4791,6 +4791,59 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__emif2 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/*
+Crypto modules AES0/1 belong to:
+   PD_L4_PER power domain
+   CD_L4_SEC clock domain
+   On the L3, the AES modules are mapped to
+   L3_CLK2: Peripherals and multimedia sub clock domain
+*/
+
+static struct omap_hwmod_class_sysconfig omap4_aes1_sysc = {
+   .rev_offs   = 0x80,
+   .sysc_offs  = 0x84,
+   .syss_offs  = 0x88,
+   .sysc_flags = SYSS_HAS_RESET_STATUS,
+   .sysc_fields= _hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class omap4_aes1_hwmod_class = {
+   .name   = "aes1",
+   .sysc   = _aes1_sysc,
+};
+
+static struct omap_hwmod omap4_aes1_hwmod = {
+   .name   = "aes",
+   .class  = _aes1_hwmod_class,
+   .clkdm_name = "l4_secure_clkdm",
+   .main_clk   = "aes1_fck",
+   .prcm   = {
+   .omap4  = {
+   .clkctrl_offs = OMAP4_CM_L4SEC_AES1_CLKCTRL_OFFSET,
+   .context_offs = OMAP4_RM_L4SEC_AES1_CONTEXT_OFFSET,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/* l3_main_2 -> aes1 */
+static struct omap_hwmod_addr_space omap4_aes1_addrs[] = {
+   {
+   .pa_start   = 0x4B50,
+   .pa_end = 0x4B50 + SZ_1M - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
+static struct omap_hwmod_ocp_if omap4_l3_main_2__aes1 = {
+   .master = _l3_main_2_hwmod,
+   .slave  = _aes1_hwmod,
+   .clk= "aes1_fck",
+   .addr   = omap4_aes1_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
_l3_main_1__dmm,
_mpu__dmm,
@@ -4945,6 +4998,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] 
__initdata = {
_l4_abe__wd_timer3_dma,
_mpu__emif1,
_mpu__emif2,
+   _l3_main_2__aes1,
NULL,
 };
 
-- 
1.8.1.2

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

[PATCH 7/7] OMAP: AM33xx: hwmod: Correct AES module SYSC type

[Joel Fernandes]

Use the newly added sysc type4 for AES module.

Signed-off-by: Joel Fernandes 
---
 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 0f17862..7f97863 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -209,6 +209,7 @@ static struct omap_hwmod_class_sysconfig am33xx_aes0_sysc = 
{
.sysc_offs  = 0x84,
.syss_offs  = 0x88,
.sysc_flags = SYSS_HAS_RESET_STATUS,
+   .sysc_fields= _hwmod_sysc_type4,
 };
 
 static struct omap_hwmod_class am33xx_aes0_hwmod_class = {
-- 
1.8.1.2

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

[PATCH 6/7] ARM: OMAP: Disable POSTED mode for errata i103 and i767

[Joel Fernandes]

Enabling of Posted mode is seen to cause problems on dmtimer modules on AM33xx
(much like other OMAPs).  Reference discussions on forums [1] [2]. Earlier
patch solving this on other OMAPs [3].

For OMAP SoCs with this errata, the fix has been to not enable Posted mode.
However, on some SoCs (atleast AM33xx) which carry this errata, Posted mode
is enabled on reset. So we not only need to ignore enabling of the POSTED bit
when the timer is requested, but also disable Posted mode if errata is present.

[1] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/285744.aspx
[2] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/270632.aspx
[3] http://www.spinics.net/lists/linux-omap/msg81770.html

Reported-by: Russ Dill 
Cc: Santosh Shilimkar 
Signed-off-by: Joel Fernandes 
---
 arch/arm/plat-omap/include/plat/dmtimer.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h 
b/arch/arm/plat-omap/include/plat/dmtimer.h
index fb92abb..2861b15 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -336,8 +336,11 @@ static inline void __omap_dm_timer_enable_posted(struct 
omap_dm_timer *timer)
if (timer->posted)
return;
 
-   if (timer->errata & OMAP_TIMER_ERRATA_I103_I767)
+   if (timer->errata & OMAP_TIMER_ERRATA_I103_I767) {
+   timer->posted = OMAP_TIMER_NONPOSTED;
+   __omap_dm_timer_write(timer, OMAP_TIMER_IF_CTRL_REG, 0, 0);
return;
+   }
 
__omap_dm_timer_write(timer, OMAP_TIMER_IF_CTRL_REG,
  OMAP_TIMER_CTRL_POSTED, 0);
-- 
1.8.1.2

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

[PATCH 5/7] ARM: OMAP4: hwmod: add hwmod data for DES IP

[Joel Fernandes]

OMAP4 has a DES IP for DES and 3DES encryption, Add hwmod data for the same.

Signed-off-by: Joel Fernandes 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 664b2c6..e0992d3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4844,6 +4844,52 @@ static struct omap_hwmod_ocp_if omap4_l3_main_2__aes1 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* DES3DES */
+static struct omap_hwmod_class_sysconfig omap4_des_sysc = {
+   .rev_offs   = 0x30,
+   .sysc_offs  = 0x34,
+   .syss_offs  = 0x38,
+   .sysc_flags = SYSS_HAS_RESET_STATUS,
+   .sysc_fields= _hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class omap4_des_hwmod_class = {
+   .name   = "des",
+   .sysc   = _des_sysc,
+};
+
+
+static struct omap_hwmod omap4_des_hwmod = {
+   .name   = "des",
+   .class  = _des_hwmod_class,
+   .clkdm_name = "l4_secure_clkdm",
+   .main_clk   = "des_fck",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = OMAP4_CM_L4SEC_DES3DES_CLKCTRL_OFFSET,
+   .context_offs = OMAP4_RM_L4SEC_DES3DES_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+static struct omap_hwmod_addr_space omap4_des_addrs[] = {
+   {
+   .pa_start   = 0x480A4000,
+   .pa_end = 0x481A4000,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
+static struct omap_hwmod_ocp_if omap4_l4_per__des = {
+   .master = _l4_per_hwmod,
+   .slave  = _des_hwmod,
+   .clk= "des_fck",
+   .addr   = omap4_des_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
_l3_main_1__dmm,
_mpu__dmm,
@@ -4999,6 +5045,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] 
__initdata = {
_mpu__emif1,
_mpu__emif2,
_l3_main_2__aes1,
+   _l4_per__des,
NULL,
 };
 
-- 
1.8.1.2

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

[PATCH 0/7] AES/DES hwmod data and dmtimer fix

[Joel Fernandes]

Here are patches adding hwmod for AES/DES crypto modules for OMAP4, DRA7 SoCs.

Also included is a fix that disables POSTED mode when dmtimer is requested.

Joel Fernandes (7):
  ARM: OMAP: hwmod: Add SYSC offsets for AES IP
  ARM: DRA7xx: hwmod: Add hwmod data for DES IP
  ARM: DRA7xx: hwmod: Add hwmod data for AES IP
  ARM: OMAP4: hwmod: Add hwmod data for AES IP
  ARM: OMAP4: hwmod: add hwmod data for DES IP
  ARM: OMAP: Disable POSTED mode for errata i103 and i767
  OMAP: AM33xx: hwmod: Correct AES module SYSC type

 arch/arm/mach-omap2/omap_hwmod.h   |  11 +++
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |   1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 101 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  78 
 arch/arm/mach-omap2/omap_hwmod_common_data.c   |  10 ++
 arch/arm/plat-omap/include/plat/dmtimer.h  |   5 +-
 6 files changed, 205 insertions(+), 1 deletion(-)

-- 
1.8.1.2

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

[PATCH 2/7] ARM: DRA7xx: hwmod: Add hwmod data for DES IP

[Joel Fernandes]

DRA7xx SoC has a DES module. Add hwmod data for the same.

Signed-off-by: Joel Fernandes 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index db32d53..efae736 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -561,6 +561,23 @@ static struct omap_hwmod_class dra7xx_gpio_hwmod_class = {
.rev= 2,
 };
 
+static struct omap_hwmod_class_sysconfig dra7xx_des_sysc = {
+   .rev_offs   = 0x0030,
+   .sysc_offs  = 0x0034,
+   .syss_offs  = 0x0038,
+   .sysc_flags = (SYSC_HAS_AUTOIDLE |
+  SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSS_HAS_RESET_STATUS),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO),
+   .sysc_fields= _hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class dra7xx_des_hwmod_class = {
+   .name   = "des",
+   .sysc   = _des_sysc,
+   .rev= 2,
+};
+
 /* gpio dev_attr */
 static struct omap_gpio_dev_attr gpio_dev_attr = {
.bank_width = 32,
@@ -750,6 +767,19 @@ static struct omap_hwmod dra7xx_gpio8_hwmod = {
.dev_attr   = _dev_attr,
 };
 
+static struct omap_hwmod dra7xx_des_hwmod = {
+   .name   = "des",
+   .class  = _des_hwmod_class,
+   .clkdm_name = "l4sec_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4SEC_DES3DES_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4SEC_DES3DES_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
+   },
+   },
+};
+
 /*
  * 'gpmc' class
  *
@@ -2171,6 +2201,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio8 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_per1 -> des */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__des = {
+   .master = _l4_per1_hwmod,
+   .slave  = _des_hwmod,
+   .clk= "l3_iclk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_addr_space dra7xx_gpmc_addrs[] = {
{
.pa_start   = 0x5000,
@@ -2705,6 +2743,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
_l4_per1__uart4,
_l4_per1__uart5,
_l4_per1__uart6,
+   _l4_per1__des,
_l4_per3__usb_otg_ss1,
_l4_per3__usb_otg_ss2,
_l4_per3__usb_otg_ss3,
-- 
1.8.1.2

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

[PATCH 1/7] ARM: OMAP: hwmod: Add SYSC offsets for AES IP

[Joel Fernandes]

The AES IP has the SIDLE offset by 2 and not 3, to allow SIDLE modes
to work for AES, we add a new SYSC type to hwmod.

Signed-off-by: Joel Fernandes 
---
 arch/arm/mach-omap2/omap_hwmod.h | 11 +++
 arch/arm/mach-omap2/omap_hwmod_common_data.c | 10 ++
 2 files changed, 21 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 0f97d63..b2efcc8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -41,6 +41,7 @@ struct omap_device;
 extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type1;
 extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type2;
 extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
+extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4;
 
 /*
  * OCP SYSCONFIG bit shifts/masks TYPE1. These are for IPs compliant
@@ -81,6 +82,16 @@ extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
 #define SYSC_TYPE3_MIDLEMODE_SHIFT 2
 #define SYSC_TYPE3_MIDLEMODE_MASK  (0x3 << SYSC_TYPE3_MIDLEMODE_SHIFT)
 
+/*
+ * OCP SYSCONFIG bit shifts/masks TYPE4.
+ */
+#define SYSC_TYPE4_SIDLEMODE_SHIFT 2
+#define SYSC_TYPE4_SIDLEMODE_MASK  (0x3 << SYSC_TYPE4_SIDLEMODE_SHIFT)
+#define SYSC_TYPE4_SOFTRESET_SHIFT 1
+#define SYSC_TYPE4_SOFTRESET_MASK  (1 << SYSC_TYPE4_SOFTRESET_SHIFT)
+#define SYSC_TYPE4_AUTOIDLE_SHIFT  0
+#define SYSC_TYPE4_AUTOIDLE_MASK   (1 << SYSC_TYPE4_AUTOIDLE_SHIFT)
+
 /* OCP SYSSTATUS bit shifts/masks */
 #define SYSS_RESETDONE_SHIFT   0
 #define SYSS_RESETDONE_MASK(1 << SYSS_RESETDONE_SHIFT)
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c 
b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 79d623b..7443dc0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -59,6 +59,16 @@ struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3 = {
.sidle_shift= SYSC_TYPE3_SIDLEMODE_SHIFT,
 };
 
+/**
+ * struct omap_hwmod_sysc_type4 - TYPE4 sysconfig scheme.
+ * Used by some IPs on AM33xx
+ */
+struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4 = {
+   .sidle_shift= SYSC_TYPE4_SIDLEMODE_SHIFT,
+   .srst_shift = SYSC_TYPE4_SOFTRESET_SHIFT,
+   .autoidle_shift = SYSC_TYPE4_AUTOIDLE_SHIFT,
+};
+
 struct omap_dss_dispc_dev_attr omap2_3_dss_dispc_dev_attr = {
.manager_count  = 2,
.has_framedonetv_irq= 0
-- 
1.8.1.2

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

Re: [PATCH V3 0/6] cpufreq: suspend early/resume late

[Nishanth Menon]

On 11/25/2013 08:11 AM, Viresh Kumar wrote:
> This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling
> suspend/resume of cpufreq governors and core. This is required for early 
> suspend
> and late resume of governors and cpufreq core.
> 
> There are multiple problems that are fixed by this patch:
> - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His 
> board
>   wasn't working well with suspend/resume as calls for removing non-boot CPUs
>   was turning out into a call to drivers ->target() which then tries to play
>   with regulators. But regulators and their I2C bus were already suspended and
>   this resulted in a failure. Many platforms have such problems, samsung, 
> tegra,
>   etc.. They solved it with driver specific PM notifiers where they used to
>   disable their driver's ->target() routine. Most of these are updated in this
>   patchset to use new infrastructure.
> 
> - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
>   tunables configuration for clusters/sockets with non-boot CPUs was getting
>   lost after suspend/resume, as we were notifying governors with
>   CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
>   deallocating memory for tunables. This is also fixed with this patch as 
> don't
>   allow any operation on Governors during suspend/resume now.
> 
> 
> So to solve these issues we introduce early suspend and late resume callbacks
> which would remove need of cpufreq drivers to implement PM notifiers to 
> disable
> transition after suspend and before resume.
> 
> @Nishanth: Can you please test V2 as well and confirm that suspend_noirq()
> doesn't work for you. I am sure it will not, but would be better if you 
> confirm
> that.
> 
> Viresh Kumar (6):
>   cpufreq: suspend governors on system suspend/hibernate
>   cpufreq: call driver's suspend/resume for each policy
patches 1-2,
Tested-by: Nishanth Menon 
http://pastebin.mozilla.org/3670932

Prior to these two patches: http://pastebin.mozilla.org/3670933
cpufreq driver used: cpufreq_cpu0


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

Re: [PATCH v2 1/7] usb: dwc3: get "usb_phy" only if the platform indicates the presence of PHY's

[Felipe Balbi]

Hi,

On Mon, Nov 11, 2013 at 08:06:12PM +0530, Kishon Vijay Abraham I wrote:
> >> diff --git a/drivers/usb/dwc3/platform_data.h 
> >> b/drivers/usb/dwc3/platform_data.h
> >> index 7db34f0..49ffa6d 100644
> >> --- a/drivers/usb/dwc3/platform_data.h
> >> +++ b/drivers/usb/dwc3/platform_data.h
> >> @@ -24,4 +24,6 @@ struct dwc3_platform_data {
> >>enum usb_device_speed maximum_speed;
> >>enum usb_dr_mode dr_mode;
> >>bool tx_fifo_resize;
> >> +  bool usb2_phy;
> >> +  bool usb3_phy;
> > 
> > This would look better as a quirks flag, then we could:
> > 
> > unsigned long quirks;
> > #define DWC3_QUIRK_NO_USB3_PHY  BIT(0)
> > #define DWC3_QUIRK_NO_USB2_PHY  BIT(1)
> 
> Should this quirk be used for dt also? Currently we find if it has usb3 phy or
> usb2 phy from the dt data only. But if we add a quirk, we'll have to add a
> property to populate the quirk no?

either we use the quirk, or use the fact that no <_phy> phandle is
defined, would work both ways, no ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [GIT PULL v3] ima: bug fixes for Linus

[Mimi Zohar]

On Mon, 2013-11-25 at 13:54 -0700, Shuah Khan wrote:
> Mimi,
> 
> Do you have fix for the following build error as well.
> 
>   CC  security/integrity/digsig.o
> security/integrity/digsig.c:70:5: error: redefinition of
> ‘integrity_init_keyring’
>  int integrity_init_keyring(const unsigned int id)
>  ^
> In file included from security/integrity/digsig.c:22:0:
> security/integrity/integrity.h:149:12: note: previous definition of
> ‘integrity_init_keyring’ was here
>  static int integrity_init_keyring(const unsigned int id)
> ^
> security/integrity/integrity.h:149:12: warning:
> ‘integrity_init_keyring’ defined but not used [-Wunused-function]
> make[2]: *** [security/integrity/digsig.o] Error 1
> make[1]: *** [security/integrity] Error 2
> make: *** [security] Error 2
> 
> I noticed the problem in linux-next and sent patch to fix it:
> 
> https://lkml.org/lkml/2013/11/8/441
> 
> I think It has been noticed in 3.13-rc1 as well.

Thanks, Shuah.  As much as I wanted to extend the UEFI secure boot
signature chain of trust to IMA-appraisal, there are still a couple of
trusted keyring issues that need to be addressed.  For now, Linus has
reverted this patch.

thanks,

Mimi

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

Re: [PATCH V2 1/2] cpufreq: suspend governors on system suspend/hibernate

[Nishanth Menon]

On 11/22/2013 05:29 AM, Viresh Kumar wrote:
> This patch adds cpufreq callbacks to dpm_{suspend|resume}_noirq() for handling
> suspend/resume of cpufreq governors. This is required for early suspend and 
> late
> resume of governors.
> 
> There are multiple problems that are fixed by this patch:
> - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His 
> board
>   wasn't working well with suspend/resume as calls for removing non-boot CPUs
>   was turning out into a call to drivers ->target() which then tries to play
>   with regulators. But regulators and their I2C bus were already suspended and
>   this resulted in a failure. This is why we need a PM notifier here.
> - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
>   tunables configuration for clusters/sockets with non-boot CPUs was getting
>   lost after suspend/resume, as we were notifying governors with
>   CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
>   deallocating memory for tunables.
> 
> Reported-by: Lan Tianyu 
> Reported-by: Nishanth Menon 
> Reported-by: Jinhyuk Choi 
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/base/power/main.c |  3 +++
>  drivers/cpufreq/cpufreq.c | 62 
> +++
>  include/linux/cpufreq.h   |  3 +++
>  3 files changed, 68 insertions(+)
yes, this seems to work for me as well.
http://pastebin.mozilla.org/3670909 - no cpufreq attempts to
transition were triggered.

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

[tip:irq/urgent] irq: Enable all irqs unconditionally in irq_resume

[tip-bot for Laxman Dewangan]

Commit-ID:  ac01810c9d2814238f08a227062e66a35a0e1ea2
Gitweb: http://git.kernel.org/tip/ac01810c9d2814238f08a227062e66a35a0e1ea2
Author: Laxman Dewangan 
AuthorDate: Mon, 25 Nov 2013 19:39:47 +0530
Committer:  Thomas Gleixner 
CommitDate: Mon, 25 Nov 2013 22:20:02 +0100

irq: Enable all irqs unconditionally in irq_resume

When the system enters suspend, it disables all interrupts in
suspend_device_irqs(), including the interrupts marked EARLY_RESUME.

On the resume side things are different. The EARLY_RESUME interrupts
are reenabled in sys_core_ops->resume and the non EARLY_RESUME
interrupts are reenabled in the normal system resume path.

When suspend_noirq() failed or suspend is aborted for any other
reason, we might omit the resume side call to sys_core_ops->resume()
and therefor the interrupts marked EARLY_RESUME are not reenabled and
stay disabled forever.

To solve this, enable all irqs unconditionally in irq_resume()
regardless whether interrupts marked EARLY_RESUMEhave been already
enabled or not.

This might try to reenable already enabled interrupts in the non
failure case, but the only affected platform is XEN and it has been
confirmed that it does not cause any side effects.

[ tglx: Massaged changelog. ]

Signed-off-by: Laxman Dewangan 
Acked-by-and-tested-by: Konrad Rzeszutek Wilk 
Acked-by: Heiko Stuebner 
Reviewed-by: Pavel Machek 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: sta...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1385388587-16442-1-git-send-email-ldewan...@nvidia.com
Signed-off-by: Thomas Gleixner 
---
 kernel/irq/pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index cb228bf..abcd6ca 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -50,7 +50,7 @@ static void resume_irqs(bool want_early)
bool is_early = desc->action &&
desc->action->flags & IRQF_EARLY_RESUME;
 
-   if (is_early != want_early)
+   if (!is_early && want_early)
continue;
 
raw_spin_lock_irqsave(>lock, flags);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Allow MUSB DSPS to use "force host" mode

[Felipe Balbi]

Hi,

On Fri, Nov 22, 2013 at 03:55:59PM +, Mark Jackson wrote:
> The IDDIG input pin is normally used to determine the USB mode
> (i.e. HOST or DEVICE).
> 
> On some systems (e.g. AM335x) leaving this pin floating allows
> the USB mode to be set via software.
> 
> This patch adds support for this via the device tree.
> 
> Signed-off-by: Mark Jackson 
> ---
>  .../devicetree/bindings/usb/am33xx-usb.txt |2 ++
>  drivers/usb/musb/musb_dsps.c   |   14 ++
>  include/linux/usb/musb.h   |1 +
>  3 files changed, 17 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
> b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> index 20c2ff2..560b7ff 100644
> --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> @@ -47,6 +47,8 @@ USB
>  - dmas: specifies the dma channels
>  - dma-names: specifies the names of the channels. Use "rxN" for receive
>and "txN" for transmit endpoints. N specifies the endpoint number.
> +- ti,force-host: specifies that the IDDIG input be ignored and the device be
> +  put into host mode regardless.
>  
>  The controller should have an "usb" alias numbered properly in the alias
>  node.
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> index 1901f6f..6439809 100644
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -105,6 +105,7 @@ struct dsps_musb_wrapper {
>   unsignedotg_disable:5;
>  
>   /* bit positions for mode */
> + unsignediddig_mux:5;
>   unsignediddig:5;
>   /* miscellaneous stuff */
>   u8  poll_seconds;
> @@ -387,6 +388,15 @@ static int dsps_musb_init(struct musb *musb)
>  
>   musb->isr = dsps_interrupt;
>  
> + /* Force host mode, rather than relying on IDDIG input */
> + if (musb->config->force_host) {
> + val = dsps_readl(reg_base, wrp->mode);
> + /* clear IDDIG bit, set IDDIG_MUX bit */
> + val &= ~(1 << wrp->iddig);
> + val |= (1 << wrp->iddig_mux);
> + dsps_writel(musb->ctrl_base, wrp->mode, val);
> + }
> +
>   /* reset the otgdisable bit, needed for host mode to work */
>   val = dsps_readl(reg_base, wrp->phy_utmi);
>   val &= ~(1 << wrp->otg_disable);
> @@ -512,6 +522,9 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
>   pdata.power = get_int_prop(dn, "mentor,power") / 2;
>   config->multipoint = of_property_read_bool(dn, "mentor,multipoint");
>  
> + if (of_property_read_bool(dn, "ti,force-host"))
> + config->force_host = true;
> +
>   ret = platform_device_add_data(musb, , sizeof(pdata));
>   if (ret) {
>   dev_err(dev, "failed to add platform_data\n");
> @@ -607,6 +620,7 @@ static const struct dsps_musb_wrapper am33xx_driver_data 
> = {
>   .mode   = 0xe8,
>   .reset  = 0,
>   .otg_disable= 21,
> + .iddig_mux  = 7,

I recently sent a patch to make this work, I'm attaching it here in case
it didn't reach mailing list.

-- 
balbi
From 5edc4b78bbfdc5fcff2cba46c7dbeebd2efddb76 Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Tue, 29 Oct 2013 12:17:16 -0500
Subject: [PATCH 1/2] usb: musb: dsps: implement ->set_mode()

this will let us support broken designs such
as AM335x EVM SK where ID pin isn't routed
anywhere on a host port.

With this we can toggle internal IDDIG signal
and make sure MUSB goes into host mode as
necessary.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/musb/musb_dsps.c | 51 
 1 file changed, 51 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..ce7ec01 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -106,6 +106,7 @@ struct dsps_musb_wrapper {
 
 	/* bit positions for mode */
 	unsigned	iddig:5;
+	unsigned	iddig_mux:5;
 	/* miscellaneous stuff */
 	u8		poll_seconds;
 };
@@ -406,6 +407,54 @@ static int dsps_musb_exit(struct musb *musb)
 	return 0;
 }
 
+static int dsps_musb_set_mode(struct musb *musb, u8 mode)
+{
+	struct device *dev = musb->controller;
+	struct dsps_glue *glue = dev_get_drvdata(dev->parent);
+	const struct dsps_musb_wrapper *wrp = glue->wrp;
+	void __iomem *ctrl_base = musb->ctrl_base;
+	void __iomem *base = musb->mregs;
+	u32 reg;
+
+	reg = dsps_readl(base, wrp->mode);
+
+	switch (mode) {
+	case MUSB_HOST:
+		reg &= ~(1 << wrp->iddig);
+
+		/*
+		 * if we're setting mode to host-only or device-only, we're
+		 * going to ignore whatever the PHY sends us and just force
+		 * ID pin status by SW
+		 */
+		reg |= (1 << wrp->iddig_mux);
+
+		dsps_writel(base, wrp->mode, reg);
+		dsps_writel(ctrl_base, wrp->phy_utmi, 0x02);
+		break;
+	case MUSB_PERIPHERAL:
+		reg |= (1 << wrp->iddig);
+
+		/*
+		 * if we're 

Re: [PATCH] platform/chrome: Make i2c_adapter_names static

[Benson Leung]

On Mon, Nov 25, 2013 at 1:14 PM, Olof Johansson  wrote:
> Not used outside of the file, so declaration should be static. Picked up by
> sparse:
>
> drivers/platform/chrome/chromeos_laptop.c:44:12: warning: symbol
> 'i2c_adapter_names' was not declared. Should it be static?
>
> Signed-off-by: Olof Johansson 
> Cc: Benson Leung 

Reviewed-by: Benson Leung 

Thanks,

-- 
Benson Leung
Software Engineer, Chrom* OS
ble...@chromium.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-next 0/4] fwserial changes for 3.14

[Greg Kroah-Hartman]

On Mon, Nov 25, 2013 at 04:00:23PM -0500, Peter Hurley wrote:
> On 11/25/2013 03:43 PM, Greg Kroah-Hartman wrote:
> >On Fri, Nov 22, 2013 at 01:06:07PM -0500, Peter Hurley wrote:
> >>**This patchset requires 'Halve tty buffer memory consumption' patchset **
> >
> >Requires it to build or just work properly?
> >
> >I'm trying to figure out what tree to take this in, (tty-next or
> >staging-next).
> 
> To build.
> 
> The 'Halve tty buffer memory consumption' patchset exports new
> methods that allow the driver to configure the maximum memory
> consumption by the tty buffers.
> 
> This fwserial patchset uses that new interface to rely on tty
> buffers to provide adequate rx buffering, rather than add'l rx
> buffering being done by the driver.
> 
> By halving the buffer memory consumption, I don't feel so
> guilty about doubling the limit :)

Ok, thanks, I'll take it through my tty-next tree then.

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

Re: [patch 00/12 v4] kexec kernel efi runtime support v v4] efi: export more efi table variable to sysfs

[H. Peter Anvin]

On 11/25/2013 12:56 AM, dyo...@redhat.com wrote:
> 
> For efi runtime mapping I add a new directory /sys/firmware/efi/
> runtime-map/ like below
> [dave@darkstar ~]$ tree /sys/firmware/efi/runtime-map/
> /sys/firmware/efi/runtime-map/
> ├── 0
> │   ├── attribute
> │   ├── num_pages
> │   ├── phys_addr
> │   ├── type
> │   └── virt_addr
> ├── 1
> │   ├── attribute
> │   ├── num_pages
> │   ├── phys_addr
> │   ├── type
> │   └── virt_addr
> [snip]
>  

These patches came through severely corrupted, the above is typical...

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY

[Felipe Balbi]

On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote:
> There can be systems which does not have an external phy, so get
> phy only if no quirks are added that indicates the PHY is not present.
> Introduced two quirk flags to indicate the *absence* of usb2 phy and
> usb3 phy. Also remove checking if return value is -ENXIO since it's now
> changed to always enable usb_phy layer.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/usb/dwc3/Kconfig |1 +
>  drivers/usb/dwc3/core.c  |   93 
> --
>  drivers/usb/dwc3/core.h  |   15 ++
>  drivers/usb/dwc3/platform_data.h |5 ++
>  4 files changed, 69 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index 70fc430..8e385b4 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -1,6 +1,7 @@
>  config USB_DWC3
>   tristate "DesignWare USB3 DRD Core Support"
>   depends on (USB || USB_GADGET) && HAS_DMA
> + select USB_PHY

no more selects, we've already had too many problems caused by bogus
usage of select.

> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 986674f..f20f4a1 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -351,13 +352,28 @@ static void dwc3_core_exit(struct dwc3 *dwc)
>  
>  #define DWC3_ALIGN_MASK  (16 - 1)
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id of_dwc3_match[] = {
> + {
> + .compatible = "snps,dwc3"
> + },
> + {
> + .compatible = "synopsys,dwc3"
> + },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, of_dwc3_match);
> +#endif
> +

you can split this patch a little bit just to make it easier to review
because there are a few changes which are really obvious:

a) move of_device_id higher in source code so you can use it from probe.
while at that, aso use of_match_device() and return early if it
doesn't match anything.

b) introduce struct dwc3_data.

c) initialize of_id->data field.

d) start using struct dwc3_data

this will make to put all obvious changes (a-c) in separate patches so
review can focus on (d).

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

[Kevin Bracey]

On 25/11/2013 16:34, Linus Walleij wrote:

On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park  wrote:

On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren  wrote:

I think that last point should be addressed by having a driver that owns
the GPIO set it to the desired output level, and the implementation of

Some pins are not connected (NC). At that cases, there's no drivers to
handle it. To reduce power leakage, it sets proper configuration with
values instead of reset values.

This is correspondant to the PIN_CONFIG_OUTPUT from
include/linux/pinctrl/pinconf-generic.h


Indeed it is - I was waiting for someone to point that out. Now we've 
got there...


I've been working on extending the shmobile PFC driver to provide 
"gpio-mode" and implement PIN_CONFIG_OUTPUT as described by 
Documentation/pinctrl.txt, primarily to handle sleep states, but I have 
begun to wonder about the initial state problem, as discussed here.


As far as I can see, we can't currently specify "fallback" states for 
pins, which is one of Tomasz' key requirements.


We can specify "hog" states, and we can specify "default for a driver", 
but not "default before/in absence of a driver" or "sleep in absence of 
a driver". Having a hog precludes any finer driver control, AFAICT.


Some of our existing pre-pinconf board files have a "unused pins" table 
which is used to claim and pull GPIOs. I've converted that to "hog" 
pinconf, but that only works because the table omits all pins used by 
drivers. And, unsurprisingly, that's been error-prone; if those tables 
originally covered all unused pins, they don't any more.


I'd like confidence that we can get every pin into the correct state by 
having a fully-populated table containing all pins, that can be used 
regardless of which drivers start. I think what we're lacking is a "weak 
hog". Whatever you call that. :)


That would also specify the state to fallback to when a group is 
released (where we currently do pinmux_disable_setting).


Thoughts?

Kevin


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

[PATCH] platform/chrome: Make i2c_adapter_names static

[Olof Johansson]

Not used outside of the file, so declaration should be static. Picked up by
sparse:

drivers/platform/chrome/chromeos_laptop.c:44:12: warning: symbol
'i2c_adapter_names' was not declared. Should it be static?

Signed-off-by: Olof Johansson 
Cc: Benson Leung 
---
 drivers/platform/chrome/chromeos_laptop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/chrome/chromeos_laptop.c 
b/drivers/platform/chrome/chromeos_laptop.c
index 1c2747f119d1..446ef0f9c256 100644
--- a/drivers/platform/chrome/chromeos_laptop.c
+++ b/drivers/platform/chrome/chromeos_laptop.c
@@ -41,7 +41,7 @@ static struct i2c_client *als;
 static struct i2c_client *tp;
 static struct i2c_client *ts;
 
-const char *i2c_adapter_names[] = {
+static const char *i2c_adapter_names[] = {
"SMBus I801 adapter",
"i915 gmbus vga",
"i915 gmbus panel",
-- 
1.8.4.1.601.g02b3b1d

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

Re: [PATCH 0/6] Platform: x86: chromeos_laptop - Deferring and Haswell

[Olof Johansson]

Hi Benson,

On Sun, Oct 20, 2013 at 8:58 PM, Benson Leung  wrote:
> The following patch series refactors the dmi check system and
> returns -EPROBE_DEFER when an expected i2c adapter is not present
> at probe time.
>
> This will allow the touchpad, touchscreen, and light sensors on
> Pixel to load even if the i915 DDC and PANEL buses are instantiated
> after chromeos_laptop.
>
> The deferred probing patches were sent previously, and have been cleaned up
> slightly since.
>
> Also one patch to clean up the placement of __initdata for the dmi_table.
>
> Finally, add support for the Haswell generation Chromebook systems'
> peripherals over the new native i2c-designware-pci busses.
>
> The last three patches depend on this patch series :
> https://lkml.org/lkml/2013/10/20/136
>
> [PATCH 1/6] Platform: x86: chromeos_laptop - Restructure device associations
> [PATCH 2/6] Platform: x86: chromeos_laptop - Use deferred probing
> [PATCH 3/6] Platform: x86: chromeos_laptop - fix incorrect placement of 
> __initdata tag
> [PATCH 4/6] Platform: x86: chromeos_laptop - Add names of Haswell ULT i2c 
> busses
> [PATCH 5/6] Platform: x86: chromeos_laptop - Add HP Chromebook 14
> [PATCH 6/6] Platform: x86: chromeos_laptop - Add Acer C720

I've applied patch 1-3. Since the naming seems to still be up in the
air on the i2c side, I can't apply 4-6 yet.

I also switched the subject to platform/chrome: ... since that's what
I've picked to use on the other patches in the same directory.


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

Re: [PATCH] Add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8

[One Thousand Gnomes]

> Reported-by: Nicholas 
> Signed-off-by: Michele Baldessari 
> Tested-by: Nicholas 

Acked-by: Alan Cox 

Going for a dig in google turns this up against multiple controllers,
multiple kernels, multiple distros..


> ---
>  drivers/ata/libata-core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 81a94a3..f6b0892 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -4156,6 +4156,9 @@ static const struct ata_blacklist_entry 
> ata_device_blacklist [] = {
>   { "ST3320[68]13AS", "SD1[5-9]", ATA_HORKAGE_NONCQ |
>   ATA_HORKAGE_FIRMWARE_WARN },
>  
> + /* Seagate Momentus SpinPoint M8 seem to have FPMDA_AA issues */
> + { "ST1000LM024 HN-M101MBB", "2AR10001", ATA_HORKAGE_BROKEN_FPDMA_AA },
> +
>   /* Blacklist entries taken from Silicon Image 3124/3132
>  Windows driver .inf file - also several Linux problem reports */
>   { "HTS541060G9SA00","MB3OC60D", ATA_HORKAGE_NONCQ, },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] regulator updates for v3.13-rc1

[Linus Torvalds]

On Mon, Nov 25, 2013 at 9:40 AM, Mark Brown  wrote:
>
> Mark Brown (4):
>   Merge remote-tracking branch 'regulator/fix/arizona' into 
> regulator-linus
>   Merge remote-tracking branch 'regulator/fix/fixed' into regulator-linus
>   Merge remote-tracking branch 'regulator/fix/gpio' into regulator-linus
>   Merge remote-tracking branch 'regulator/fix/pfuze100' into 
> regulator-linus

Btw, I suspect you could/should have just used an "octopus merge" to
merge these kinds of small independent branches in one go. Just list
all the branches you want to merge for one single "git merge", and
you're done.

I don't necessarily recommend doing that in general, but octopus
merges are actually quite nice for this kind of situation in that it
avoids having excessive empty merge commits. Now we end up having your
four merges, and then my one merge on top: so we have five merges for
four actual fixes. Octopus merges can end up making the history more
readable by avoiding that kind of somewhat excessive merge activity
that you otherwise easily get from having lots of small topic
branches.

But it's up to you. I like seeing topic branches, and that part is
absolutely a good git habit to get into. Octopus merges then have the
upside that they then avoid having lots of pointless small merge
commits to tie them all together, but they can make it slightly more
challenging to figure out what went wrong if problems happen. So in
this case, one option might have been to merge the three independent
driver fixes with one single octopus merge, and then merge the core
fix separately as a normal merge.

Whatever. Not a big deal, I just thought I'd mention it if you perhaps
didn't realize that git happily merges multiple branches at once..

  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 v6 5/5] usb: dwc3: implement gadget's quirk ep_out_align_size

[Felipe Balbi]

Hi,

On Tue, Nov 12, 2013 at 01:04:46PM -0800, David Cohen wrote:
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 5452c0fce360..7c2d36f6ad4b 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1130,6 +1130,14 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep, 
> struct usb_request *request,
>   dev_vdbg(dwc->dev, "queing request %p to %s length %d\n",
>   request, ep->name, request->length);
>  
> + /* If ep out, roundup request->length to epout maxpacketsize */
> + if (!(dep->number & 1)) {

we have a direction field in the dep structure, please use that.

> + unsigned int aligned = roundup(request->length,
> +ep->desc->wMaxPacketSize);
> + req->pad = aligned - request->length;
> + request->length = aligned;

this is quite dangerous. You really don't know the size that gadget
driver allocated. What if we're using SLOB and gadget driver allocated
exactly 31 bytes (think MSC's CBW) ? Then you change request->length to
512-bytes (or 1024 if USB SS), and host happens to be buggy (or
exploited somehow) and sends more than 31-bytes ? You told dwc3 you
could receive more than 31-bytes even though you don't know what follows
your 31-byte buffer.

This is why I have been saying that gadget driver *must* be the one
hadnling this issue based on the quirk flag.

-- 
balbi


signature.asc
Description: Digital signature

Re: disappearing listen()ed SO_REUSEPORT sockets across fork() when using epoll

[Shawn Landden]

On Mon, Nov 25, 2013 at 12:05 PM, Mateusz Guzik  wrote:
> On Mon, Nov 25, 2013 at 11:53:24AM -0800, Shawn Landden wrote:
>> On Mon, Nov 25, 2013 at 10:05 AM, Jason Baron  wrote:
>> > On 11/22/2013 12:53 PM, Shawn Landden wrote:
>> >> Hello, when running the attached program on 3.12 child processes
>> >> are missing a socket fd opened, set with SO_REUSEPORT, listen()ed to,
>> >> and added to epoll_ctl().
>> >>
>> >> This is the output I get when pointing "wget http://localhost:/;
>> >> at the attached program:
>> >>
>> >> main PID 31591
>> >> PID 31634 started
>> >> PID 31634 accept()ed connection
>> >> PID 31635 started
>> >> PID 31636 started
>> >> PID 31635 accept() failed: Bad file descriptor
>> >> PID 31636 accept() failed: Bad file descriptor
>> >> PID 31634 accept()ed connection
>> >> PID 31634 accept()ed connection
>> >> PID 31634 accept()ed connection
>> >> PID 31634 accept()ed connection
>> >>
>> >>
>> >> While I would expect something like:
>> >>
>> >> main PID 31591
>> >> PID 31634 started
>> >> PID 31634 accept()ed connection
>> >> PID 31635 started
>> >> PID 31636 started
>> >> PID 31635 accept()ed connection
>> >> PID 31636 accept()ed connection
>> >>
>> >> -more new processes, but inversely proportional to number of listening 
>> >> processes
>> >> -accept() always returns successfully
>> >>
>> >>
>> >
>> > The 'close(sockfd);' looks to be racing with the accept() calls. Removing 
>> > seems
>> > to get the result you are looking for.
>> Interesting. That works, but it shouldn't. The close() is operating in
>> the parent, so it shouldn't affect the child,
>> there is a leak here of process separation.
>>
>
> You fork, then close sockfd in the parent. Thus, the very first child
> can accept connectins just fine.
>
> Subsequent forks give you children without sockfd, thus accept fails.
> The first child continues to work just fine.
Now I feel like an idiot.



-- 

---
Shawn Landden
+1 360 389 3001 (SMS preferred)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: Make sure CPU is running on a freq from freq-table

[Rafael J. Wysocki]

On Monday, November 25, 2013 09:43:59 AM Dirk Brandewie wrote:
> On 11/25/2013 09:01 AM, Viresh Kumar wrote:
> > On 25 November 2013 22:08, Dirk Brandewie  wrote:
> >> IMHO this issue should be fixed in the scaling driver for the platform.
> >>
> >> The scaling driver sets policy->cur and fills in the frequency table and 
> >> has
> >
> > Not anymore, policy->cur is set in the core for most of the drivers now.
> > Drivers just provide ->get() callbacks.
> >
> >> the ability to adjust the frequency of the CPU.
> >
> > I believe this kind of decisions should stay with the core, drivers should
> > just provide the backend instead of intelligence..
> >
> 
> 
> This is a platform specific bug fix AFAICT and belongs in a platform
> specific piece of code
> 
> 
> >> Letting this leak up into the core
> >> is wrong IMHO and just widens the window where the CPU will be running at
> >> the wrong frequency set by the bootloader.
> >
> > It doesn't stay there for long enough.. we get to this point in
> > cpufreq core just
> > after calling ->init(), and if the CPU is working without issues until
> > now, it will
> > stay stable for few more milliseconds.
> >
> 
> And this is where the scaling driver should detect and fix the issue in 
> ->init()
> on platforms we know about today, What happens if platforms in the future are
> more sensitive to the issue?

So what should the core do if the driver is careless and lets the bug slip
through?  Should it blindly trust the driver and let go?

Honestly, I don't think so.

> >> Shouldn't there be a check to see if the problem exists at all?  Otherwise
> >> the core is setting a policy for ALL platform even those where the issue
> >> does
> >> not exist.
> >
> > That is taken care of by __cpufreq_driver_target(). It checks if we are
> > already running at requested frequency or not (after getting the next
> > higher frequency)... If current freq is present in table,
> > cpufreq_frequency_table_target() will return current frequency only for
> > policy->cur -1. And so we will not end up configuring hardware
> > unnecessarily.
> >
> 
> The core should not be working around bootloader bugs IMHO.  Silently
> fixing it is evil IMHO at a minimum the core should complain LOUDLY
> about this happening otherwise the bootloaders will have no incentive to
> get their act together.

Yes, we can add a WARN_ON() there.  Still, though, the core's responsibility
is to ensure that (a) either we can continue safely or (b) we can't, in which
case it should just fail the initialization.  Whether or not it should panic()
I'm not sure.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, 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 staging-next 0/4] fwserial changes for 3.14

[Peter Hurley]

On 11/25/2013 03:43 PM, Greg Kroah-Hartman wrote:

On Fri, Nov 22, 2013 at 01:06:07PM -0500, Peter Hurley wrote:

**This patchset requires 'Halve tty buffer memory consumption' patchset **


Requires it to build or just work properly?

I'm trying to figure out what tree to take this in, (tty-next or
staging-next).


To build.

The 'Halve tty buffer memory consumption' patchset exports new
methods that allow the driver to configure the maximum memory
consumption by the tty buffers.

This fwserial patchset uses that new interface to rely on tty
buffers to provide adequate rx buffering, rather than add'l rx
buffering being done by the driver.

By halving the buffer memory consumption, I don't feel so
guilty about doubling the limit :)

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/5] futex: Misc cleanups

[Thomas Gleixner]

From: Jason Low 

- Remove unnecessary head variables.
- Delete unused parameter in queue_unlock().

Signed-off-by: Jason Low 
Signed-off-by: Davidlohr Bueso 
Link: http://lkml.kernel.org/r/1385168197-8612-2-git-send-email-davidl...@hp.com
Signed-off-by: Thomas Gleixner 
---
 kernel/futex.c |   40 
 1 file changed, 12 insertions(+), 28 deletions(-)

Index: linux-2.6/kernel/futex.c
===
--- linux-2.6.orig/kernel/futex.c
+++ linux-2.6/kernel/futex.c
@@ -597,13 +597,10 @@ lookup_pi_state(u32 uval, struct futex_h
 {
struct futex_pi_state *pi_state = NULL;
struct futex_q *this, *next;
-   struct plist_head *head;
struct task_struct *p;
pid_t pid = uval & FUTEX_TID_MASK;
 
-   head = >chain;
-
-   plist_for_each_entry_safe(this, next, head, list) {
+   plist_for_each_entry_safe(this, next, >chain, list) {
if (match_futex(>key, key)) {
/*
 * Another waiter already exists - bump up
@@ -985,7 +982,6 @@ futex_wake(u32 __user *uaddr, unsigned i
 {
struct futex_hash_bucket *hb;
struct futex_q *this, *next;
-   struct plist_head *head;
union futex_key key = FUTEX_KEY_INIT;
int ret;
 
@@ -998,9 +994,8 @@ futex_wake(u32 __user *uaddr, unsigned i
 
hb = hash_futex();
spin_lock(>lock);
-   head = >chain;
 
-   plist_for_each_entry_safe(this, next, head, list) {
+   plist_for_each_entry_safe(this, next, >chain, list) {
if (match_futex (>key, )) {
if (this->pi_state || this->rt_waiter) {
ret = -EINVAL;
@@ -1033,7 +1028,6 @@ futex_wake_op(u32 __user *uaddr1, unsign
 {
union futex_key key1 = FUTEX_KEY_INIT, key2 = FUTEX_KEY_INIT;
struct futex_hash_bucket *hb1, *hb2;
-   struct plist_head *head;
struct futex_q *this, *next;
int ret, op_ret;
 
@@ -1081,9 +1075,7 @@ retry_private:
goto retry;
}
 
-   head = >chain;
-
-   plist_for_each_entry_safe(this, next, head, list) {
+   plist_for_each_entry_safe(this, next, >chain, list) {
if (match_futex (>key, )) {
if (this->pi_state || this->rt_waiter) {
ret = -EINVAL;
@@ -1096,10 +1088,8 @@ retry_private:
}
 
if (op_ret > 0) {
-   head = >chain;
-
op_ret = 0;
-   plist_for_each_entry_safe(this, next, head, list) {
+   plist_for_each_entry_safe(this, next, >chain, list) {
if (match_futex (>key, )) {
if (this->pi_state || this->rt_waiter) {
ret = -EINVAL;
@@ -1269,7 +1259,6 @@ static int futex_requeue(u32 __user *uad
int drop_count = 0, task_count = 0, ret;
struct futex_pi_state *pi_state = NULL;
struct futex_hash_bucket *hb1, *hb2;
-   struct plist_head *head1;
struct futex_q *this, *next;
u32 curval2;
 
@@ -1392,8 +1381,7 @@ retry_private:
}
}
 
-   head1 = >chain;
-   plist_for_each_entry_safe(this, next, head1, list) {
+   plist_for_each_entry_safe(this, next, >chain, list) {
if (task_count - nr_wake >= nr_requeue)
break;
 
@@ -1492,8 +1480,7 @@ static inline struct futex_hash_bucket *
return hb;
 }
 
-static inline void
-queue_unlock(struct futex_q *q, struct futex_hash_bucket *hb)
+static inline void queue_unlock(struct futex_hash_bucket *hb)
__releases(>lock)
 {
spin_unlock(>lock);
@@ -1866,7 +1853,7 @@ retry_private:
ret = get_futex_value_locked(, uaddr);
 
if (ret) {
-   queue_unlock(q, *hb);
+   queue_unlock(*hb);
 
ret = get_user(uval, uaddr);
if (ret)
@@ -1880,7 +1867,7 @@ retry_private:
}
 
if (uval != val) {
-   queue_unlock(q, *hb);
+   queue_unlock(*hb);
ret = -EWOULDBLOCK;
}
 
@@ -2028,7 +2015,7 @@ retry_private:
 * Task is exiting and we just wait for the
 * exit to complete.
 */
-   queue_unlock(, hb);
+   queue_unlock(hb);
put_futex_key();
cond_resched();
goto retry;
@@ -2080,7 +2067,7 @@ retry_private:
goto out_put_key;
 
 out_unlock_put_key:
-   queue_unlock(, hb);
+   queue_unlock(hb);
 
 out_put_key:
put_futex_key();
@@ -2090,7 +2077,7 @@ out:
return ret != -EINTR ? ret : -ERESTARTNOINTR;
 
 uaddr_faulted:
-   queue_unlock(, hb);
+   queue_unlock(hb);
 
ret = fault_in_user_writeable(uaddr);
if (ret)
@@ 

[RFC patch 0/5] futex: Allow lockless empty check of hashbucket plist in futex_wake()

[Thomas Gleixner]

The patch set from Davidlohr [1] tried to attempt the same via an
atomic counter of waiters in a hash bucket. The atomic counter access
provided enough serialization for x86 so that a failure is not
observable in testing, but does not provide any guarantees.

The same can be achieved with a smp_mb() pair including proper
guarantees for all architectures.

The following series provides an incremental approach to this and adds
documentation of the ordering guarantees of futexes.

Note, this is RFC and needs a lot of review, testing and proper
performance numbers for the following scenarios:

1) Test case where a single waiter is about to queue itself, i.e. the
   test case Davidlohr used to gather his numbers.

2) Test case where the hash bucket is always not empty. This allows us
   to determine the smp_mb() overhead for cases which are not
   optimized by the singler waiter per bucket.

These tests need to be done on x86 AND on other architectures where
the smp_mb() might be more expensive than on x86.

Thanks,

tglx

---
[1] http://lkml.kernel.org/r/1385168197-8612-5-git-send-email-davidl...@hp.com


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

[RFC patch 3/5] futex: Split out unlock from queue_me()

[Thomas Gleixner]

Preparatory patch for a lockless empty check of the hash bucket plist
in futex_wake().

No functional change.

Signed-off-by: Thomas Gleixner 
---
 kernel/futex.c |   24 
 1 file changed, 16 insertions(+), 8 deletions(-)

Index: linux-2.6/kernel/futex.c
===
--- linux-2.6.orig/kernel/futex.c
+++ linux-2.6/kernel/futex.c
@@ -1548,15 +1548,14 @@ static inline void queue_unlock(struct f
  * @q: The futex_q to enqueue
  * @hb:The destination hash bucket
  *
- * The hb->lock must be held by the caller, and is released here. A call to
- * queue_me() is typically paired with exactly one call to unqueue_me().  The
- * exceptions involve the PI related operations, which may use unqueue_me_pi()
- * or nothing if the unqueue is done as part of the wake process and the 
unqueue
- * state is implicit in the state of woken task (see futex_wait_requeue_pi() 
for
- * an example).
+ * The hb->lock must be held by the caller. A call to queue_me() is
+ * typically paired with exactly one call to unqueue_me(). The
+ * exceptions involve the PI related operations, which may use
+ * unqueue_me_pi() or nothing if the unqueue is done as part of the
+ * wake process and the unqueue state is implicit in the state of
+ * woken task (see futex_wait_requeue_pi() for an example).
  */
 static inline void queue_me(struct futex_q *q, struct futex_hash_bucket *hb)
-   __releases(>lock)
 {
int prio;
 
@@ -1573,7 +1572,6 @@ static inline void queue_me(struct futex
plist_node_init(>list, prio);
plist_add(>list, >chain);
q->task = current;
-   spin_unlock(>lock);
 }
 
 /**
@@ -1834,6 +1832,11 @@ static void futex_wait_queue_me(struct f
 */
set_current_state(TASK_INTERRUPTIBLE);
queue_me(q, hb);
+   /*
+* Unlock _AFTER_ we queued ourself. See the comment describing
+* the futex ordering guarantees on top of this file.
+*/
+   queue_unlock(hb);
 
/* Arm the timer */
if (timeout) {
@@ -2085,6 +2088,11 @@ retry_private:
 * Only actually queue now that the atomic ops are done:
 */
queue_me(, hb);
+   /*
+* Unlock _AFTER_ we queued ourself. See the comment describing
+* the futex ordering guarantees on top of this file.
+*/
+   queue_unlock(hb);
 
WARN_ON(!q.pi_state);
/*


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] futex: Enqueue waiter before user space check

[Thomas Gleixner]

This changes the queue ordering on the waiter side from 

 lock(hash_bucket);
 validate user space value();
 queue();
 unlock(hash_bucket);

to
 lock(hash_bucket);
 queue();
 validate user space value();
 unlock(hash_bucket);

This is a preparatory patch for a lockless empty check of the hash
bucket plist.

No functional implication. All futex operations are still serialized
via the hasb bucket lock.

Signed-off-by: Thomas Gleixner 
---
 kernel/futex.c |   84 +
 1 file changed, 49 insertions(+), 35 deletions(-)

Index: linux-2.6/kernel/futex.c
===
--- linux-2.6.orig/kernel/futex.c
+++ linux-2.6/kernel/futex.c
@@ -107,22 +107,26 @@
  * and the waker did not find the waiter in the hash bucket queue.
  * The spinlock serializes that:
  *
+ *
  * CPU 0   CPU 1
  * val = *futex;
  * sys_futex(WAIT, futex, val);
  *   futex_wait(futex, val);
  *   lock(hash_bucket(futex));
+ *   queue();
  *   uval = *futex;
  * *futex = newval;
  * sys_futex(WAKE, futex);
  *   futex_wake(futex);
  *   lock(hash_bucket(futex));
  *   if (uval == val)
- *  queue();
  * unlock(hash_bucket(futex));
  * schedule();   if (!queue_empty())
  * wake_waiters(futex);
  *   unlock(hash_bucket(futex));
+ *
+ * The futex_lock_pi ordering is similar to that, but it has the queue
+ * operation right before unlocking hash bucket lock and scheduling.
  */
 
 int __read_mostly futex_cmpxchg_enabled;
@@ -1575,6 +1579,19 @@ static inline void queue_me(struct futex
 }
 
 /**
+ * unqueue_and_unlock() - Dequeue the futex_q and release hash bucket lock
+ * @q: The futex_q to dequeue
+ * @hb:The hash bucket
+ */
+static inline void
+unqueue_and_unlock(struct futex_q *q, struct futex_hash_bucket *hb)
+   __releases(>lock)
+{
+   plist_del(>list, >chain);
+   spin_unlock(>lock);
+}
+
+/**
  * unqueue_me() - Remove the futex_q from its futex_hash_bucket
  * @q: The futex_q to unqueue
  *
@@ -1816,28 +1833,12 @@ out:
 }
 
 /**
- * futex_wait_queue_me() - queue_me() and wait for wakeup, timeout, or signal
- * @hb:the futex hash bucket, must be locked by the caller
+ * __futex_wait() - wait for wakeup, timeout, or signal
  * @q: the futex_q to queue up on
  * @timeout:   the prepared hrtimer_sleeper, or null for no timeout
  */
-static void futex_wait_queue_me(struct futex_hash_bucket *hb, struct futex_q 
*q,
-   struct hrtimer_sleeper *timeout)
+static void __futex_wait(struct futex_q *q, struct hrtimer_sleeper *timeout)
 {
-   /*
-* The task state is guaranteed to be set before another task can
-* wake it. set_current_state() is implemented using set_mb() and
-* queue_me() calls spin_unlock() upon completion, both serializing
-* access to the hash list and forcing another memory barrier.
-*/
-   set_current_state(TASK_INTERRUPTIBLE);
-   queue_me(q, hb);
-   /*
-* Unlock _AFTER_ we queued ourself. See the comment describing
-* the futex ordering guarantees on top of this file.
-*/
-   queue_unlock(hb);
-
/* Arm the timer */
if (timeout) {
hrtimer_start_expires(>timer, HRTIMER_MODE_ABS);
@@ -1897,10 +1898,6 @@ static int futex_wait_setup(u32 __user *
 * would open a race condition where we could block indefinitely with
 * cond(var) false, which would violate the guarantee.
 *
-* On the other hand, we insert q and release the hash-bucket only
-* after testing *uaddr.  This guarantees that futex_wait() will NOT
-* absorb a wakeup if *uaddr does not match the desired values
-* while the syscall executes.
 */
 retry:
ret = get_futex_key(uaddr, flags & FLAGS_SHARED, >key, VERIFY_READ);
@@ -1910,10 +1907,15 @@ retry:
 retry_private:
*hb = queue_lock(q);
 
+   /*
+* We queue the futex before validating the user space value.
+*/
+   queue_me(q, *hb);
+
ret = get_futex_value_locked(, uaddr);
 
if (ret) {
-   queue_unlock(*hb);
+   unqueue_and_unlock(q, *hb);
 
ret = get_user(uval, uaddr);
if (ret)
@@ -1927,13 +1929,25 @@ retry_private:
}
 
if (uval != val) {
-   queue_unlock(*hb);
+   unqueue_and_unlock(q, *hb);
ret = -EWOULDBLOCK;
}
 
 out:
-   if (ret)
+   if (!ret) {
+   /*
+* If we sucessfully queued ourself, set the state to
+* TASK_INTERRUPTIBLE. A potential waker