Re: [RFC] mm: cma: move init_cma_reserved_pageblock to cma.c

[Joonsoo Kim]

On Wed, Jun 25, 2014 at 12:48:02AM +0200, Michal Nazarewicz wrote:
> With [f495d26: “generalize CMA reserved area management
> functionality”] patch CMA has its place under mm directory now so
> there is no need to shoehorn a highly CMA specific functions inside of
> page_alloc.c.
> 
> As such move init_cma_reserved_pageblock from mm/page_alloc.c to
> mm/cma.c, rename it to cma_init_reserved_pageblock and refactor
> a little.
> 
> Most importantly, if a !pfn_valid(pfn) is encountered, just
> return -EINVAL instead of warning and trying to continue the
> initialisation of the area.  It's not clear, to me at least, what good
> is continuing the work on a PFN that is known to be invalid.
> 
> Signed-off-by: Michal Nazarewicz 

Acked-by: Joonsoo Kim 

One question below.

> ---
>  include/linux/gfp.h |  3 --
>  mm/cma.c| 85 
> +
>  mm/page_alloc.c | 31 ---
>  3 files changed, 66 insertions(+), 53 deletions(-)
> 
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 5e7219d..107793e9 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -415,9 +415,6 @@ extern int alloc_contig_range(unsigned long start, 
> unsigned long end,
> unsigned migratetype);
>  extern void free_contig_range(unsigned long pfn, unsigned nr_pages);
>  
> -/* CMA stuff */
> -extern void init_cma_reserved_pageblock(struct page *page);
> -
>  #endif
>  
>  #endif /* __LINUX_GFP_H */
> diff --git a/mm/cma.c b/mm/cma.c
> index c17751c..843b2b6 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -28,11 +28,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  
> +#include "internal.h"
> +
>  struct cma {
>   unsigned long   base_pfn;
>   unsigned long   count;
> @@ -83,37 +86,81 @@ static void cma_clear_bitmap(struct cma *cma, unsigned 
> long pfn, int count)
>   mutex_unlock(>lock);
>  }
>  
> +/* Free whole pageblock and set its migration type to MIGRATE_CMA. */
> +static int __init cma_init_reserved_pageblock(struct zone *zone,
> +   unsigned long pageblock_pfn)
> +{
> + unsigned long pfn, nr_pages, i;
> + struct page *page, *p;
> + unsigned order;
> +
> + pfn = pageblock_pfn;
> + if (!pfn_valid(pfn))
> + goto invalid_pfn;
> + page = pfn_to_page(pfn);
> +
> + p = page;
> + i = pageblock_nr_pages;
> + do {
> + if (!pfn_valid(pfn))
> + goto invalid_pfn;
> +
> + /*
> +  * alloc_contig_range requires the pfn range specified to be
> +  * in the same zone. Make this simple by forcing the entire
> +  * CMA resv range to be in the same zone.
> +  */
> + if (page_zone(p) != zone) {
> + pr_err("pfn %lu belongs to %s, expecting %s\n",
> +pfn, page_zone(p)->name, zone->name);
> + return -EINVAL;
> + }
> +
> + __ClearPageReserved(p);
> + set_page_count(p, 0);
> + } while (++p, ++pfn, --i);

So, when we meet fail condition, __ClearPageReserved, set_page_count()
are already executed for some pages. Is that no problem?

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] HID: roccat: Drop cast

[Joe Perches]

On Fri, 2014-06-27 at 07:29 +0200, Julia Lawall wrote:
> On Thu, 26 Jun 2014, Joe Perches wrote:
> > The cast of a const void * to a void * was odd.
> > 
> > Maybe a mechanism to verify appropriateness of
> > loss of constness for any pointer might be useful.
> 
> I tried the following, but didn't find anything interesting:
> 
> @disable drop_cast@
> type T;
> const T e;
> @@
> 
> * (T)e

What code does this match?
Do you have an example match?

This doesn't find a cast of a void type like:

void func(const void * const p)
{
char *p2 = p;

p2[0] = 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 v3 04/13] mm, compaction: move pageblock checks up from isolate_migratepages_range()

[Joonsoo Kim]

On Wed, Jun 25, 2014 at 10:59:19AM +0200, Vlastimil Babka wrote:
> On 06/25/2014 02:53 AM, Joonsoo Kim wrote:
> >On Tue, Jun 24, 2014 at 05:42:50PM +0200, Vlastimil Babka wrote:
> >>On 06/24/2014 10:33 AM, Joonsoo Kim wrote:
> >>>On Fri, Jun 20, 2014 at 05:49:34PM +0200, Vlastimil Babka wrote:
> isolate_migratepages_range() is the main function of the compaction 
> scanner,
> called either on a single pageblock by isolate_migratepages() during 
> regular
> compaction, or on an arbitrary range by CMA's 
> __alloc_contig_migrate_range().
> It currently perfoms two pageblock-wide compaction suitability checks, and
> because of the CMA callpath, it tracks if it crossed a pageblock boundary 
> in
> order to repeat those checks.
> 
> However, closer inspection shows that those checks are always true for 
> CMA:
> - isolation_suitable() is true because CMA sets cc->ignore_skip_hint to 
> true
> - migrate_async_suitable() check is skipped because CMA uses sync 
> compaction
> 
> We can therefore move the checks to isolate_migratepages(), reducing 
> variables
> and simplifying isolate_migratepages_range(). The update_pageblock_skip()
> function also no longer needs set_unsuitable parameter.
> 
> Furthermore, going back to compact_zone() and compact_finished() when 
> pageblock
> is unsuitable is wasteful - the checks are meant to skip pageblocks 
> quickly.
> The patch therefore also introduces a simple loop into 
> isolate_migratepages()
> so that it does not return immediately on pageblock checks, but keeps 
> going
> until isolate_migratepages_range() gets called once. Similarily to
> isolate_freepages(), the function periodically checks if it needs to 
> reschedule
> or abort async compaction.
> 
> Signed-off-by: Vlastimil Babka 
> Cc: Minchan Kim 
> Cc: Mel Gorman 
> Cc: Joonsoo Kim 
> Cc: Michal Nazarewicz 
> Cc: Naoya Horiguchi 
> Cc: Christoph Lameter 
> Cc: Rik van Riel 
> Cc: David Rientjes 
> ---
>   mm/compaction.c | 112 
>  +---
>   1 file changed, 59 insertions(+), 53 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 3064a7f..ebe30c9 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -132,7 +132,7 @@ void reset_isolation_suitable(pg_data_t *pgdat)
>    */
>   static void update_pageblock_skip(struct compact_control *cc,
>   struct page *page, unsigned long nr_isolated,
> - bool set_unsuitable, bool migrate_scanner)
> + bool migrate_scanner)
>   {
>   struct zone *zone = cc->zone;
>   unsigned long pfn;
> @@ -146,12 +146,7 @@ static void update_pageblock_skip(struct 
> compact_control *cc,
>   if (nr_isolated)
>   return;
> 
> - /*
> -  * Only skip pageblocks when all forms of compaction will be known to
> -  * fail in the near future.
> -  */
> - if (set_unsuitable)
> - set_pageblock_skip(page);
> + set_pageblock_skip(page);
> 
>   pfn = page_to_pfn(page);
> 
> @@ -180,7 +175,7 @@ static inline bool isolation_suitable(struct 
> compact_control *cc,
> 
>   static void update_pageblock_skip(struct compact_control *cc,
>   struct page *page, unsigned long nr_isolated,
> - bool set_unsuitable, bool migrate_scanner)
> + bool migrate_scanner)
>   {
>   }
>   #endif /* CONFIG_COMPACTION */
> @@ -345,8 +340,7 @@ isolate_fail:
> 
>   /* Update the pageblock-skip if the whole pageblock was scanned 
>  */
>   if (blockpfn == end_pfn)
> - update_pageblock_skip(cc, valid_page, total_isolated, true,
> -   false);
> + update_pageblock_skip(cc, valid_page, total_isolated, false);
> 
>   count_compact_events(COMPACTFREE_SCANNED, nr_scanned);
>   if (total_isolated)
> @@ -474,14 +468,12 @@ unsigned long
>   isolate_migratepages_range(struct zone *zone, struct compact_control 
>  *cc,
>   unsigned long low_pfn, unsigned long end_pfn, bool 
>  unevictable)
>   {
> - unsigned long last_pageblock_nr = 0, pageblock_nr;
>   unsigned long nr_scanned = 0, nr_isolated = 0;
>   struct list_head *migratelist = >migratepages;
>   struct lruvec *lruvec;
>   unsigned long flags;
>   bool locked = false;
>   struct page *page = NULL, *valid_page = NULL;
> - bool set_unsuitable = true;
>   const isolate_mode_t mode = (cc->mode == MIGRATE_ASYNC ?
>   

Re: [PATCH] x86, vsmp: Remove is_vsmp_box() from apic_is_clustered_box()

[H. Peter Anvin]

On 06/26/2014 10:05 PM, Oren Twaig wrote:
> ping

This patch conflicts with the changes on the tip:x86/apic branch.  Could
you please rebase the patch on top of that branch?

-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: mm: shm: hang in shmem_fallocate

[Hugh Dickins]

[Cc Johannes: at the end I have a particular question for you]

On Thu, 26 Jun 2014, Vlastimil Babka wrote:
> On 06/26/2014 12:36 AM, Hugh Dickins wrote:
> > On Tue, 24 Jun 2014, Vlastimil Babka wrote:
> > 
> > Sorry for the slow response: I have got confused, learnt more, and
> > changed my mind, several times in the course of replying to you.
> > I think this reply will be stable... though not final.
> 
> Thanks a lot for looking into it!
> 
> > > 
> > > since this got a CVE,
> > 
> > Oh.  CVE-2014-4171.  Couldn't locate that yesterday but see it now.
> 
> Sorry, I should have mentioned it explicitly.
> 
> > Looks overrated to me
> 
> I'd bet it would pass unnoticed if you didn't use the sentence "but whether
> it's a serious matter in the scale of denials of service, I'm not so sure" in
> your first reply to Sasha's report :) I wouldn't be surprised if people grep
> for this.

Hah, you're probably right,
I better choose my words more carefully in future.

> 
> > (and amusing to see my pompous words about a
> > "range notification mechanism" taken too seriously), but of course
> > we do need to address it.
> > 
> > > I've been looking at backport to an older kernel where
> > 
> > Thanks a lot for looking into it.  I didn't think it was worth a
> > Cc: sta...@vger.kernel.org myself, but admit to being both naive
> > and inconsistent about that.
> > 
> > > fallocate(FALLOC_FL_PUNCH_HOLE) is not yet supported, and there's also no
> > > range notification mechanism yet. There's just madvise(MADV_REMOVE) and
> > > since
> > 
> > Yes, that mechanism could be ported back pre-v3.5,
> > but I agree with your preference not to.
> > 
> > > it doesn't guarantee anything, it seems simpler just to give up retrying
> > > to
> > 
> > Right, I don't think we have formally documented the instant of "full hole"
> > that I strove for there, and it's probably not externally verifiable, nor
> > guaranteed by other filesystems.  I just thought it a good QoS aim, but
> > it has given us this problem.
> > 
> > > truncate really everything. Then I realized that maybe it would work for
> > > current kernel as well, without having to add any checks in the page
> > > fault
> > > path. The semantics of fallocate(FALLOC_FL_PUNCH_HOLE) might look
> > > different
> > > from madvise(MADV_REMOVE), but it seems to me that as long as it does
> > > discard
> > > the old data from the range, it's fine from any information leak point of
> > > view.
> > > If someone races page faulting, it IMHO doesn't matter if he gets a new
> > > zeroed
> > > page before the parallel truncate has ended, or right after it has ended.
> > 
> > Yes.  I disagree with your actual patch, for more than one reason,
> > but it's in the right area; and I found myself growing to agree with
> > you, that's it's better to have one kind of fix for all these releases,
> > than one for v3.5..v3.15 and another for v3.1..v3.4.  (The CVE cites
> > v3.0 too, I'm sceptical about that, but haven't tried it as yet.)
> 
> I was looking at our 3.0 based kernel, but it could be due to backported
> patches on top.

And later you confirm that 3.0.101 vanilla is okay: thanks, that fits.

> 
> > If I'd realized that we were going to have to backport, I'd have spent
> > longer looking for a patch like yours originally.  So my inclination
> > now is to go your route, make a new patch for v3.16 and backports,
> > and revert the f00cdc6df7d7 that has already gone in.
> > 
> > > So I'm posting it here as a RFC. I haven't thought about the
> > > i915_gem_object_truncate caller yet. I think that this path wouldn't
> > > satisfy
> > 
> > My understanding is that i915_gem_object_truncate() is not a problem,
> > that i915's dev->struct_mutex serializes all its relevant transitions,
> > plus the object woudn't even be interestingly accessible to the user.
> > 
> > > the new "lstart < inode->i_size" condition, but I don't know if it's
> > > "vulnerable"
> > > to the problem.
> > 
> > I don't think i915 is vulnerable, but if it is, that condition would
> > be fine for it, as would be the patch I'm now thinking of.
> > 
> > > 
> > > -8<-
> > > From: Vlastimil Babka 
> > > Subject: [RFC PATCH] shmem: prevent livelock between page fault and hole
> > > punching
> > > 
> > > ---
> > >   mm/shmem.c | 19 +++
> > >   1 file changed, 19 insertions(+)
> > > 
> > > diff --git a/mm/shmem.c b/mm/shmem.c
> > > index f484c27..6d6005c 100644
> > > --- a/mm/shmem.c
> > > +++ b/mm/shmem.c
> > > @@ -476,6 +476,25 @@ static void shmem_undo_range(struct inode *inode,
> > > loff_t lstart, loff_t lend,
> > >   if (!pvec.nr) {
> > >   if (index == start || unfalloc)
> > >   break;
> > > +/*
> > > + * When this condition is true, it means we were
> > > + * called from fallocate(FALLOC_FL_PUNCH_HOLE).
> > > + * To prevent a livelock when 

Re: [PATCH v3 4/9] ACPI, x86: Extended error log driver for x86 platform

[Xie XiuQi]

On 2013/10/18 20:37, Naveen N. Rao wrote:
> On 10/18/2013 01:53 PM, Chen, Gong wrote:
>> This H/W error log driver (a.k.a eMCA driver) is implemented based on
>> http://www.intel.com/content/www/us/en/architecture-and-technology/enhanced-mca-logging-xeon-paper.html
>>
>> After errors are captured, more valuable information can be
>> got via this new enhanced H/W error log driver.
>>
>> v3 -> v2: fix a MACRO definition error and some cleanup
>> v2 -> v1: eliminate spin_lock & minor fixes suggested by Boris
>>
>> Signed-off-by: Chen, Gong 
>> ---
>>   arch/x86/include/asm/mce.h   |   5 +
>>   arch/x86/kernel/cpu/mcheck/mce.c |  20 +++
>>   drivers/acpi/Kconfig |  20 +++
>>   drivers/acpi/Makefile|   2 +

[...]

>> +}
>> +EXPORT_SYMBOL_GPL(unregister_elog_handler);
>> +
>>   /*
>>* Poll for corrected events or events that happened before reset.
>>* Those are just logged through /dev/mcelog.
>> @@ -624,6 +641,9 @@ void machine_check_poll(enum mcp_flags flags, 
>> mce_banks_t *b)
>>   (m.status & (mca_cfg.ser ? MCI_STATUS_S : MCI_STATUS_UC)))
>>   continue;
>>
>> +if (mce_ext_err_print)
>> +mce_ext_err_print(NULL, m.extcpu, i);
>> +
> 
> Can we use the notifier chain we already have: mce_register_decode_chain()? 
> EDAC uses this and I'm wondering if it is a good fit here. As an added bonus, 
> it seems to honor dont_log_ce option as well.

Hi everyone,

I have a question here, is it safe when we use printk in MCE context?

The call graph is like this,
do_machine_check
 -> mce_log
  -> atomic_notifier_call_chain(_mce_decoder_chain ...)
   -> ...
-> extlog_print
 -> print_extlog_rcd
  -> __print_extlog_rcd
   -> printk

There's a logbuf_lock in printk. If logbuf_lock is held by other cpu,
it'll lead to an infinity spin here. Isn't it?

--
Thanks,
XiuQi

> 
>>   mce_read_aux(, i);
>>
>>   if (!(flags & MCP_TIMESTAMP))
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 22327e6..c67ec61 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -372,4 +372,24 @@ config ACPI_BGRT
>>
>>   source "drivers/acpi/apei/Kconfig"
>>
>> +config ACPI_EXTLOG
>> +tristate "Extended Error Log support"
>> +depends on X86_MCE
...


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

[Julia Lawall]

On Thu, 26 Jun 2014, Joe Perches wrote:

> On Thu, 2014-06-26 at 22:58 +0530, Himangi Saraogi wrote:
> > This patch removes the cast on data of type void* as it is not needed.
> 
> Hi Himangi
> 
> The cast of a const void * to a void * was odd.
> 
> Maybe a mechanism to verify appropriateness of
> loss of constness for any pointer might be useful.

I tried the following, but didn't find anything interesting:

@disable drop_cast@
type T;
const T e;
@@

* (T)e

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

Re: [PATCH 2/2] usb: chipidea: Add support for zynq usb host and device controller

[Peter Chen]

On Fri, Jun 27, 2014 at 09:10:09AM +0530, Punnaiah Choudary Kalluri wrote:
> Zynq soc usb controller is a synopsys IP and it is compatible
> with the chipidea spec. So, reusing chipidea drivers for zynq usb
> controller.

What means "... usb controller is a synopsys IP", or it should be "uses
synopsys IP"?
> 
> Signed-off-by: Punnaiah Choudary Kalluri 
> ---
>  drivers/usb/chipidea/Makefile   |1 +
>  drivers/usb/chipidea/ci_hdrc_zynq.c |  115 
> +++
>  2 files changed, 116 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/usb/chipidea/ci_hdrc_zynq.c
> 
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 2f099c7..b0d6b6f 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -12,6 +12,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM)   += otg_fsm.o
>  
>  obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_msm.o
>  obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_zevio.o
> +obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_zynq.o
>  
>  # PCI doesn't provide stubs, need to check
>  ifneq ($(CONFIG_PCI),)
> diff --git a/drivers/usb/chipidea/ci_hdrc_zynq.c 
> b/drivers/usb/chipidea/ci_hdrc_zynq.c
> new file mode 100644
> index 000..b3667da
> --- /dev/null
> +++ b/drivers/usb/chipidea/ci_hdrc_zynq.c
> @@ -0,0 +1,115 @@
> +/*
> + * Copyright (C) 2014 Xilinx, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it 
> under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ci.h"
> +
> +#define ZYNQ_USB_DMA_MASK0xFFF0
> +
> +struct ci_hdrc_zynq_data {
> + struct platform_device *ci_pdev;
> + struct clk *clk;
> +};
> +
> +static struct ci_hdrc_platform_data pdata = {
> + .name   = "ci_hdrc_zynq",
> + .capoffset  = DEF_CAPOFFSET,
> + .flags  = CI_HDRC_REQUIRE_TRANSCEIVER
> +};
> +
> +static int ci_hdrc_zynq_probe(struct platform_device *pdev)
> +{
> + struct ci_hdrc_zynq_data *data;
> + int ret;
> +
> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> + if (!data) {
> + dev_err(>dev, "Failed to allocate ci_hdrc-imx data!\n");

hmm, you forget to delete "xxx-imx".

> + return -ENOMEM;
> + }
> +
> + data->clk = devm_clk_get(>dev, NULL);
> + if (IS_ERR(data->clk)) {
> + dev_err(>dev,
> + "Failed to get clock, err=%ld\n", PTR_ERR(data->clk));
> + return PTR_ERR(data->clk);
> + }
> +
> + ret = clk_prepare_enable(data->clk);
> + if (ret) {
> + dev_err(>dev,
> + "Failed to prepare or enable clock, err=%d\n", ret);
> + return ret;
> + }
> +
> + ret = dma_coerce_mask_and_coherent(>dev, ZYNQ_USB_DMA_MASK);
> + if (ret)
> + goto err_clk;
> +
> + data->ci_pdev = ci_hdrc_add_device(>dev,
> + pdev->resource, pdev->num_resources,
> + );
> + if (IS_ERR(data->ci_pdev)) {
> + ret = PTR_ERR(data->ci_pdev);
> + dev_err(>dev,
> + "Can't register ci_hdrc platform device, err=%d\n",
> + ret);
> + goto err_clk;
> + }
> +
> + platform_set_drvdata(pdev, data);
> +
> + pm_runtime_no_callbacks(>dev);
> + pm_runtime_enable(>dev);
> + return 0;
> +
> +err_clk:
> + clk_disable_unprepare(data->clk);
> + return ret;
> +}
> +
> +static int ci_hdrc_zynq_remove(struct platform_device *pdev)
> +{
> + struct ci_hdrc_zynq_data *data = platform_get_drvdata(pdev);
> +
> + pm_runtime_disable(>dev);
> + ci_hdrc_remove_device(data->ci_pdev);
> + clk_disable_unprepare(data->clk);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ci_hdrc_zynq_dt_ids[] = {
> + { .compatible = "xlnx,zynq-usb-2.20a" },
> + {},
> +};
> +
> +static struct platform_driver ci_hdrc_zynq_driver = {
> + .probe = ci_hdrc_zynq_probe,
> + .remove = ci_hdrc_zynq_remove,
> + .driver = {
> + .name = "zynq_usb",
> + .owner = THIS_MODULE,
> + .of_match_table = ci_hdrc_zynq_dt_ids,
> +  },
> +};
> +
> +module_platform_driver(ci_hdrc_zynq_driver);
> +
> +MODULE_ALIAS("platform:zynq_usb");
> +MODULE_DESCRIPTION("CI HDRC ZYNQ USB binding");
> +MODULE_AUTHOR("Xilinx Inc");
> +MODULE_LICENSE("GPL v2");
> -- 
> 1.7.4
> 
> 

-- 

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

Re: [PATCH 2/2] usb: chipidea: Add support for zynq usb host and device controller

[punnaiah choudary kalluri]

On Fri, Jun 27, 2014 at 9:09 AM, Peter Chen  wrote:
> On Fri, Jun 27, 2014 at 09:10:09AM +0530, Punnaiah Choudary Kalluri wrote:
>> Zynq soc usb controller is a synopsys IP and it is compatible
>> with the chipidea spec. So, reusing chipidea drivers for zynq usb
>> controller.
>
> What means "... usb controller is a synopsys IP", or it should be "uses
> synopsys IP"?

Zynq soc uses synopsys usb IP. I will correct it

>>
>> Signed-off-by: Punnaiah Choudary Kalluri 
>> ---
>>  drivers/usb/chipidea/Makefile   |1 +
>>  drivers/usb/chipidea/ci_hdrc_zynq.c |  115 
>> +++
>>  2 files changed, 116 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/usb/chipidea/ci_hdrc_zynq.c
>>
>> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
>> index 2f099c7..b0d6b6f 100644
>> --- a/drivers/usb/chipidea/Makefile
>> +++ b/drivers/usb/chipidea/Makefile
>> @@ -12,6 +12,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM)   += otg_fsm.o
>>
>>  obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_msm.o
>>  obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_zevio.o
>> +obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_zynq.o
>>
>>  # PCI doesn't provide stubs, need to check
>>  ifneq ($(CONFIG_PCI),)
>> diff --git a/drivers/usb/chipidea/ci_hdrc_zynq.c 
>> b/drivers/usb/chipidea/ci_hdrc_zynq.c
>> new file mode 100644
>> index 000..b3667da
>> --- /dev/null
>> +++ b/drivers/usb/chipidea/ci_hdrc_zynq.c
>> @@ -0,0 +1,115 @@
>> +/*
>> + * Copyright (C) 2014 Xilinx, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it 
>> under
>> + * the terms of the GNU General Public License version 2 as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "ci.h"
>> +
>> +#define ZYNQ_USB_DMA_MASK0xFFF0
>> +
>> +struct ci_hdrc_zynq_data {
>> + struct platform_device *ci_pdev;
>> + struct clk *clk;
>> +};
>> +
>> +static struct ci_hdrc_platform_data pdata = {
>> + .name   = "ci_hdrc_zynq",
>> + .capoffset  = DEF_CAPOFFSET,
>> + .flags  = CI_HDRC_REQUIRE_TRANSCEIVER
>> +};
>> +
>> +static int ci_hdrc_zynq_probe(struct platform_device *pdev)
>> +{
>> + struct ci_hdrc_zynq_data *data;
>> + int ret;
>> +
>> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
>> + if (!data) {
>> + dev_err(>dev, "Failed to allocate ci_hdrc-imx data!\n");
>
> hmm, you forget to delete "xxx-imx".

Oh! i will correct it and send you the v2.

Regards,
Punnaiah
>
>> + return -ENOMEM;
>> + }
>> +
>> + data->clk = devm_clk_get(>dev, NULL);
>> + if (IS_ERR(data->clk)) {
>> + dev_err(>dev,
>> + "Failed to get clock, err=%ld\n", PTR_ERR(data->clk));
>> + return PTR_ERR(data->clk);
>> + }
>> +
>> + ret = clk_prepare_enable(data->clk);
>> + if (ret) {
>> + dev_err(>dev,
>> + "Failed to prepare or enable clock, err=%d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = dma_coerce_mask_and_coherent(>dev, ZYNQ_USB_DMA_MASK);
>> + if (ret)
>> + goto err_clk;
>> +
>> + data->ci_pdev = ci_hdrc_add_device(>dev,
>> + pdev->resource, pdev->num_resources,
>> + );
>> + if (IS_ERR(data->ci_pdev)) {
>> + ret = PTR_ERR(data->ci_pdev);
>> + dev_err(>dev,
>> + "Can't register ci_hdrc platform device, err=%d\n",
>> + ret);
>> + goto err_clk;
>> + }
>> +
>> + platform_set_drvdata(pdev, data);
>> +
>> + pm_runtime_no_callbacks(>dev);
>> + pm_runtime_enable(>dev);
>> + return 0;
>> +
>> +err_clk:
>> + clk_disable_unprepare(data->clk);
>> + return ret;
>> +}
>> +
>> +static int ci_hdrc_zynq_remove(struct platform_device *pdev)
>> +{
>> + struct ci_hdrc_zynq_data *data = platform_get_drvdata(pdev);
>> +
>> + pm_runtime_disable(>dev);
>> + ci_hdrc_remove_device(data->ci_pdev);
>> + clk_disable_unprepare(data->clk);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id ci_hdrc_zynq_dt_ids[] = {
>> + { .compatible = "xlnx,zynq-usb-2.20a" },
>> + {},
>> +};
>> +
>> +static struct platform_driver ci_hdrc_zynq_driver = {
>> + .probe = ci_hdrc_zynq_probe,
>> + .remove = ci_hdrc_zynq_remove,
>> + .driver = {
>> + .name = "zynq_usb",
>> + .owner = THIS_MODULE,
>> + .of_match_table = ci_hdrc_zynq_dt_ids,
>> +  },
>> +};
>> +
>> +module_platform_driver(ci_hdrc_zynq_driver);
>> +
>> +MODULE_ALIAS("platform:zynq_usb");
>> +MODULE_DESCRIPTION("CI HDRC ZYNQ USB binding");
>> +MODULE_AUTHOR("Xilinx Inc");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 1.7.4
>>
>>
>
> --
>
> 

Re: [PATCH v2 07/12] usb: chipidea: add a generic driver

[Peter Chen]

On Fri, Jun 27, 2014 at 11:25:07AM +0800, Peter Chen wrote:
> On Tue, Jun 24, 2014 at 12:35:16PM +0200, Antoine Ténart wrote:
> > Add a generic ChipIdea driver, with optional PHY and clock, to support
> > ChipIdea controllers that doesn't need specific functions.
> > 
> > +   return 0;
> > +}
> > +
> > +static const struct of_device_id ci_hdrc_generic_of_match[] = {
> > +   { .compatible = "chipidea-usb" },
> > +   { }
> > +};
> 
> Even as a generic driver, you can also use your own compatible string.
> 
> > +MODULE_DEVICE_TABLE(of, ci_hdrc_generic_of_match);
> > +
> > +static struct platform_driver ci_hdrc_generic_driver = {
> > +   .probe  = ci_hdrc_generic_probe,
> > +   .remove = ci_hdrc_generic_remove,
> > +   .driver = {
> > +   .name   = "chipidea-usb",
> > +   .owner  = THIS_MODULE,
> > +   .of_match_table = ci_hdrc_generic_of_match,
> > +   },
> > +};
> > +module_platform_driver(ci_hdrc_generic_driver);
> > +
> > +MODULE_DESCRIPTION("Generic ChipIdea HDRC USB binding");
> > +MODULE_AUTHOR("Antoine Ténart ");
> > +MODULE_LICENSE("GPL");
> > -- 
> > 1.9.1
> > 
> 
> -- 
> 

Besides, I haven't seen dma_coerce_mask_and_coherent API calling,
where you set your dma mask?

-- 

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

linux-next: Tree for Jun 27

[Stephen Rothwell]

Hi all,

The powerpc allyesconfig is again broken more than usual.

Changes since 20140626:

New tree: usb-serial-fixes

The staging tree still had its build failure for which I disabled a driver.

The akpm-current tree its build failure (I applied a supplied patch).

Non-merge commits (relative to Linus' tree): 2430
 2378 files changed, 96549 insertions(+), 64800 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 222 trees (counting Linus' and 30 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (3493860c76eb Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block)
Merging fixes/master (4b660a7f5c80 Linux 3.15-rc6)
Merging kbuild-current/rc-fixes (c14105628b2e kbuild: fix a typo in a kbuild 
document)
Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4)
Merging arm-current/fixes (b8d8772e53f8 ARM: arm925: ensure assembly sets up 
writethrough mapping)
Merging m68k-current/for-linus (e8d6dc5ad26e m68k/hp300: Convert printk to 
pr_foo())
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging powerpc-merge/merge (6663a4fa6711 powerpc: Don't skip ePAPR spin-table 
CPUs)
Merging sparc/master (894e552cfaa3 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging net/master (d7933ab727ed Merge branch 'for-next' of 
git://git.samba.org/sfrench/cifs-2.6)
Merging ipsec/master (d7933ab727ed Merge branch 'for-next' of 
git://git.samba.org/sfrench/cifs-2.6)
Merging sound-current/for-linus (a07187c992be ALSA: hda - restore BCLK M/N 
values when resuming HSW/BDW display controller)
Merging pci-current/for-linus (d066c946a866 PCI: Fix unaligned access in AF 
transaction pending test)
Merging wireless/master (e055a6e20a91 Merge branch 'ath-current' of 
git://github.com/kvalo/ath)
Merging driver-core.current/driver-core-linus (206204a1162b lz4: ensure length 
does not wrap)
Merging tty.current/tty-linus (a497c3ba1d97 Linux 3.16-rc2)
Merging usb.current/usb-linus (d6236f6d1d88 xhci: Fix runtime suspended xhci 
from blocking system suspend.)
Merging usb-gadget-fixes/fixes (5d881802c407 usb: musb: core: Handle Babble 
condition only in HOST mode)
Merging usb-serial-fixes/usb-linus (660856948664 MAINTAINERS: update e-mail 
address)
Merging staging.current/staging-linus (a497c3ba1d97 Linux 3.16-rc2)
Merging char-misc.current/char-misc-linus (a497c3ba1d97 Linux 3.16-rc2)
Merging input-current/for-linus (31972f6e517d Input: ti_am335x_tsc - warn about 
incorrect spelling)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (cfe82d4f45c7 crypto: sha512_ssse3 - fix byte 
count to bit count conversion)
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (4b660a7f5c80 Linux 3.15-rc6)
Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting 
module removal.)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging drm-intel-fixes/for-linux-next-fixes (8525a235c96a drm/i915: 
vlv_prepare_pll is only needed in case of non DSI interfaces)
Merging asm-generic/master (fb9de7ebc3a2

Re: [PATCH] x86, vsmp: Remove is_vsmp_box() from apic_is_clustered_box()

[Oren Twaig]

ping
On 06/23/2014 08:35 AM, Oren Twaig wrote:
> Remove invalid code which caused TSC to be declared as "unstable" on vSMP
> Foundation box even if it was stable and let the kernel decide for itself.
>
> When a vSMP Foundation box is detected, the function apic_cluster_num() counts
> the number of APIC clusters found. If more than one found, a multi board
> configuration is assumed, and TSC marked as unstable. This behavior is
> incorrect as vSMP Foundation may use processors from single node only, 
> attached
> to memory of other nodes - and such node may have more than one APIC cluster
> (typically any recent intel box has more than single APIC_CLUSTERID(x)).
>
> To fix this, we simply remove the code which detects a vSMP Foundation box and
> affects apic_is_clusted_box() return value. This can be done because later the
> kernel checks by itself if the TSC is stable using the
> check_tsc_sync_[source|target]() functions and marks TSC as unstable if 
> needed.
>
> Signed-off-by: Oren Twaig 
> Acked-by: Shai Fultheim 
> ---
>  arch/x86/include/asm/apic.h |8 --
>  arch/x86/kernel/apic/apic.c |   60 
> +--
>  2 files changed, 1 insertion(+), 67 deletions(-)
>
> diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
> index 19b0eba..c100694 100644
> --- a/arch/x86/include/asm/apic.h
> +++ b/arch/x86/include/asm/apic.h
> @@ -85,14 +85,6 @@ static inline bool apic_from_smp_config(void)
>  #include 
>  #endif
> 
> -#ifdef CONFIG_X86_64
> -extern int is_vsmp_box(void);
> -#else
> -static inline int is_vsmp_box(void)
> -{
> -return 0;
> -}
> -#endif
>  extern int setup_profiling_timer(unsigned int);
> 
>  static inline void native_apic_mem_write(u32 reg, u32 v)
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index ad28db7..2b85bb9 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2451,51 +2451,6 @@ static void apic_pm_activate(void) { }
> 
>  #ifdef CONFIG_X86_64
> 
> -static int apic_cluster_num(void)
> -{
> -int i, clusters, zeros;
> -unsigned id;
> -u16 *bios_cpu_apicid;
> -DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);
> -
> -bios_cpu_apicid = early_per_cpu_ptr(x86_bios_cpu_apicid);
> -bitmap_zero(clustermap, NUM_APIC_CLUSTERS);
> -
> -for (i = 0; i < nr_cpu_ids; i++) {
> -/* are we being called early in kernel startup? */
> -if (bios_cpu_apicid) {
> -id = bios_cpu_apicid[i];
> -} else if (i < nr_cpu_ids) {
> -if (cpu_present(i))
> -id = per_cpu(x86_bios_cpu_apicid, i);
> -else
> -continue;
> -} else
> -break;
> -
> -if (id != BAD_APICID)
> -__set_bit(APIC_CLUSTERID(id), clustermap);
> -}
> -
> -/* Problem:  Partially populated chassis may not have CPUs in some of
> - * the APIC clusters they have been allocated.  Only present CPUs have
> - * x86_bios_cpu_apicid entries, thus causing zeroes in the bitmap.
> - * Since clusters are allocated sequentially, count zeros only if
> - * they are bounded by ones.
> - */
> -clusters = 0;
> -zeros = 0;
> -for (i = 0; i < NUM_APIC_CLUSTERS; i++) {
> -if (test_bit(i, clustermap)) {
> -clusters += 1 + zeros;
> -zeros = 0;
> -} else
> -++zeros;
> -}
> -
> -return clusters;
> -}
> -
>  static int multi_checked;
>  static int multi;
> 
> @@ -2540,20 +2495,7 @@ static void dmi_check_multi(void)
>  int apic_is_clustered_box(void)
>  {
>  dmi_check_multi();
> -if (multi)
> -return 1;
> -
> -if (!is_vsmp_box())
> -return 0;
> -
> -/*
> - * ScaleMP vSMPowered boxes have one cluster per board and TSCs are
> - * not guaranteed to be synced between boards
> - */
> -if (apic_cluster_num() > 1)
> -return 1;
> -
> -return 0;
> +return multi;
>  }
>  #endif
> 
>
>


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

Re: [PATCH resend #4] fcntl-linux.h: add new definitions and manual updates for open file description locks

[Michael Kerrisk (man-pages)]

On 06/26/2014 09:57 PM, Jeff Layton wrote:
> From: Jeff Layton 
> 
> Open file description locks have been merged into the Linux kernel for
> v3.15.  Add the appropriate command-value definitions and an update to
> the manual that describes their usage.

What's the hold-up here? Jeff's patches have been reviewed by at least
me and Carlos. It'd be nice if they made it in before the 2.20 code freeze...

Cheers,

Michael


> ChangeLog:
> 
> 2014-04-24  Jeff Layton  
> 
>   [BZ#16839]
>   * manual/llio.texi: add section about open file description locks
> 
>   * manual/examples/ofdlocks.c:
> example of open file description lock usage
> 
>   * sysdeps/unix/sysv/linux/bits/fcntl-linux.h:
> (F_OFD_GETLK, F_OFD_SETLK, F_OFD_SETLKW): New macros.
> ---
>  manual/examples/ofdlocks.c |  77 +
>  manual/llio.texi   | 241 
> -
>  sysdeps/unix/sysv/linux/bits/fcntl-linux.h |  17 ++
>  3 files changed, 332 insertions(+), 3 deletions(-)
>  create mode 100644 manual/examples/ofdlocks.c
> 
> diff --git a/manual/examples/ofdlocks.c b/manual/examples/ofdlocks.c
> new file mode 100644
> index ..85e193cdabe6
> --- /dev/null
> +++ b/manual/examples/ofdlocks.c
> @@ -0,0 +1,77 @@
> +/* Open File Description Locks Usage Example
> +   Copyright (C) 1991-2014 Free Software Foundation, Inc.
> +
> +   This program is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU General Public License
> +   as published by the Free Software Foundation; either version 2
> +   of the License, or (at your option) any later version.
> +
> +   This program is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +   GNU General Public License for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with this program; if not, see .
> +*/
> +
> +#define _GNU_SOURCE
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define FILENAME "/tmp/foo"
> +#define NUM_THREADS  3
> +#define ITERATIONS   5
> +
> +void *
> +thread_start (void *arg)
> +{
> +  int i, fd, len;
> +  long tid = (long) arg;
> +  char buf[256];
> +  struct flock lck = {
> +.l_whence = SEEK_SET,
> +.l_start = 0,
> +.l_len = 1,
> +  };
> +
> +  fd = open ("/tmp/foo", O_RDWR | O_CREAT, 0666);
> +
> +  for (i = 0; i < ITERATIONS; i++)
> +{
> +  lck.l_type = F_WRLCK;
> +  fcntl (fd, F_OFD_SETLKW, );
> +
> +  len = sprintf (buf, "%d: tid=%ld fd=%d\n", i, tid, fd);
> +
> +  lseek (fd, 0, SEEK_END);
> +  write (fd, buf, len);
> +  fsync (fd);
> +
> +  lck.l_type = F_UNLCK;
> +  fcntl (fd, F_OFD_SETLK, );
> +
> +  /* sleep to ensure lock is yielded to another thread */
> +  usleep (1);
> +}
> +  pthread_exit (NULL);
> +}
> +
> +int
> +main (int argc, char **argv)
> +{
> +  long i;
> +  pthread_t threads[NUM_THREADS];
> +
> +  truncate (FILENAME, 0);
> +
> +  for (i = 0; i < NUM_THREADS; i++)
> +pthread_create ([i], NULL, thread_start, (void *) i);
> +
> +  pthread_exit (NULL);
> +  return 0;
> +}
> diff --git a/manual/llio.texi b/manual/llio.texi
> index 6f8adfc607d7..864060dc7140 100644
> --- a/manual/llio.texi
> +++ b/manual/llio.texi
> @@ -57,6 +57,10 @@ directly.)
>   flags associated with open files.
>  * File Locks::  Fcntl commands for implementing
>   file locking.
> +* Open File Description Locks:: Fcntl commands for implementing
> + open file description locking.
> +* Open File Description Locks Example:: An example of open file description 
> lock
> + usage
>  * Interrupt Input:: Getting an asynchronous signal when
>   input arrives.
>  * IOCTLs::  Generic I/O Control operations.
> @@ -2890,7 +2894,7 @@ Get flags associated with the open file.  @xref{File 
> Status Flags}.
>  Set flags associated with the open file.  @xref{File Status Flags}.
>  
>  @item F_GETLK
> -Get a file lock.  @xref{File Locks}.
> +Test a file lock.  @xref{File Locks}.
>  
>  @item F_SETLK
>  Set or clear a file lock.  @xref{File Locks}.
> @@ -2898,6 +2902,18 @@ Set or clear a file lock.  @xref{File Locks}.
>  @item F_SETLKW
>  Like @code{F_SETLK}, but wait for completion.  @xref{File Locks}.
>  
> +@item F_OFD_GETLK
> +Test an open file description lock.  @xref{Open File Description Locks}.
> +Specific to Linux.
> +
> +@item F_OFD_SETLK
> +Set or clear an open file description lock.  @xref{Open File Description 
> Locks}.
> +Specific to Linux.
> +
> +@item F_OFD_SETLKW
> +Like 

Re: [PATCH v2 07/12] usb: chipidea: add a generic driver

[Peter Chen]

On Tue, Jun 24, 2014 at 12:35:16PM +0200, Antoine Ténart wrote:
> Add a generic ChipIdea driver, with optional PHY and clock, to support
> ChipIdea controllers that doesn't need specific functions.
> 
> Needed for the Marvell Berlin SoCs SUB controllers.
> 
> Signed-off-by: Antoine Ténart 
> ---
>  drivers/usb/chipidea/Makefile  |   1 +
>  drivers/usb/chipidea/ci_hdrc_generic.c | 108 
> +
>  2 files changed, 109 insertions(+)
>  create mode 100644 drivers/usb/chipidea/ci_hdrc_generic.c
> 
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 2f099c7df7b5..c705f0fe7a00 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -20,4 +20,5 @@ endif
>  
>  ifneq ($(CONFIG_OF),)
>   obj-$(CONFIG_USB_CHIPIDEA)  += usbmisc_imx.o ci_hdrc_imx.o
> + obj-$(CONFIG_USB_CHIPIDEA)  += ci_hdrc_generic.o
>  endif

As a generic driver, you may need to support both dt and non-dt
solution.

> diff --git a/drivers/usb/chipidea/ci_hdrc_generic.c 
> b/drivers/usb/chipidea/ci_hdrc_generic.c
> new file mode 100644
> index ..27520710a1f7
> --- /dev/null
> +++ b/drivers/usb/chipidea/ci_hdrc_generic.c
> @@ -0,0 +1,108 @@
> +/*
> + * Copyright (C) 2014 Marvell Technology Group Ltd.
> + *
> + * Antoine Ténart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ci.h"
> +
> +struct ci_hdrc_generic_priv {
> + struct platform_device  *ci_pdev;
> + struct clk  *clk;
> +};
> +
> +static int ci_hdrc_generic_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct ci_hdrc_generic_priv *priv;
> + struct ci_hdrc_platform_data ci_pdata = {
> + .name   = "ci_hdrc",

How about this using dev_name(>dev) for name?

> + .capoffset  = DEF_CAPOFFSET,
> + .flags  = CI_HDRC_REQUIRE_TRANSCEIVER |
> +   CI_HDRC_DISABLE_STREAMING,
> + };
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->clk = devm_clk_get(dev, NULL);
> + if (!IS_ERR(priv->clk)) {
> + ret = clk_prepare_enable(priv->clk);
> + if (ret) {
> + dev_err(dev, "failed to enable the clock: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + ci_pdata.phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 0);
> + if (IS_ERR(ci_pdata.phy))
> + /* PHY is optional */
> + ci_pdata.phy = NULL;
> +
> + priv->ci_pdev = ci_hdrc_add_device(dev, pdev->resource,
> +  pdev->num_resources, _pdata);
> + if (IS_ERR(priv->ci_pdev)) {
> + ret = PTR_ERR(priv->ci_pdev);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev,
> + "failed to register ci_hdrc platform device: 
> %d\n",
> + ret);
> + goto clk_err;
> + }
> +
> + platform_set_drvdata(pdev, priv);
> +
> + pm_runtime_no_callbacks(dev);
> + pm_runtime_enable(dev);
> +
> + return 0;
> +
> +clk_err:
> + clk_disable_unprepare(priv->clk);

You may need to add "if (!IS_ERR(priv->clk))"

> + return ret;
> +}
> +
> +static int ci_hdrc_generic_remove(struct platform_device *pdev)
> +{
> + struct ci_hdrc_generic_priv *priv = platform_get_drvdata(pdev);
> +
> + pm_runtime_disable(>dev);
> + ci_hdrc_remove_device(priv->ci_pdev);
> + clk_disable_unprepare(priv->clk);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ci_hdrc_generic_of_match[] = {
> + { .compatible = "chipidea-usb" },
> + { }
> +};

Even as a generic driver, you can also use your own compatible string.

> +MODULE_DEVICE_TABLE(of, ci_hdrc_generic_of_match);
> +
> +static struct platform_driver ci_hdrc_generic_driver = {
> + .probe  = ci_hdrc_generic_probe,
> + .remove = ci_hdrc_generic_remove,
> + .driver = {
> + .name   = "chipidea-usb",
> + .owner  = THIS_MODULE,
> + .of_match_table = ci_hdrc_generic_of_match,
> + },
> +};
> +module_platform_driver(ci_hdrc_generic_driver);
> +
> +MODULE_DESCRIPTION("Generic ChipIdea HDRC USB binding");
> +MODULE_AUTHOR("Antoine Ténart ");
> +MODULE_LICENSE("GPL");
> -- 
> 1.9.1
> 

-- 

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

Re: [PATCH v2] USB: ehci-pci: USB host controller support for Intel Quark X1000

[Jingoo Han]

On Friday, June 27, 2014 1:33 PM, Jingoo Han wrote:
> On Friday, June 27, 2014 8:25 PM, Alvin Chen wrote:
> >
> > From: Bryan O'Donoghue 
> >
> > The EHCI packet buffer in/out threshold is programmable for Intel Quark 
> > X1000 USB host
> > controller, and the default value is 0x20 dwords. The in/out threshold can 
> > be programmed
> > to 0x80 dwords, but only when isochronous/interrupt transactions are not 
> > initiated by
> > the USB host controller. This patch is to reconfigure the packet buffer 
> > in/out threshold
> > as maximal as possible, and it is 0x7F dwords since the USB host controller 
> > initiates
> > isochronous/interrupt transactions.
> 
> So, what is the reason to set the value as 0x80?
>   1. The default value 0x20 makes some problems such as...
>   2. To maximize the performance, ...
>   3. Both
> Please add the reason why 0x80 is necessary, as possible.
> 
> Then, 0x7F means 508 bytes? 'Intel Quark X1000 USB host controller'
> can support 0x80 (512bytes), however, in this case, isochronous/interrupt
> transactions cannot be initiated by 'Intel Quark X1000 USB host controller'.
> Right?
> 
> So, 0x79 (508bytes?) should be used, because the isochronous/interrupt
> transactions can be initiated by 'Intel Quark X1000 USB host controller'.
> Right?
> 
> >
> > Signed-off-by: Bryan O'Donoghue 
> > Signed-off-by: Alvin (Weike) Chen 
> > ---
> > changelog v2:
> > *Change the function name from 'usb_is_intel_qrk' to 
> > 'usb_is_intel_quark_x1000'.
> > *Move the functions 'usb_is_intel_quark_x1000' and 'usb_set_qrk_bulk_thresh'
> >  from 'pci-quirks.c' to 'ehci-pci.c'.
> > *Remove unnecessary kernel message in the function of 
> > 'usb_set_qrk_bulk_thresh'.
> > *Remove 'unlikely' in the functions of 'ehci_pci_reinit'.
> > *Add white space after 'if'.
> > *Update the descriptions to make it more clearly.
> > *Add Micros to avoid magic number.
> >
> >  drivers/usb/host/ehci-pci.c |   45 
> > +++
> >  1 file changed, 45 insertions(+)
> >
> > diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
> > index 3e86bf4..ca29f34 100644
> > --- a/drivers/usb/host/ehci-pci.c
> > +++ b/drivers/usb/host/ehci-pci.c
> > @@ -35,6 +35,47 @@ static const char hcd_name[] = "ehci-pci";
> >  #define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70
> >
> >  
> > /*-*/
> > +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
> > +static inline bool usb_is_intel_quark_x1000(struct pci_dev *pdev)
> > +{
> > +   return pdev->vendor == PCI_VENDOR_ID_INTEL &&
> > +   pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
> > +
> 
> Please don't add this unnecessary line.
> 
> > +}
> > +
> > +/* Register offset of in/out threshold */
> > +#define EHCI_INSNREG01 0x84
> > +/* The maximal threshold is 0x80 Dword */
> > +#define EHCI_MAX_THRESHOLD  0X80
> 
> s/0X80/0x80
> 
> 0x80 means 512 bytes. So, how about mentioning '0x80 means 512 bytes'
> in this comment or the commit message?
> 
> Maybe, how about the following?
> 
> /* The maximal threshold value is 0x80, which means 512 bytes */
> #define EHCI_THRESHOLD_512BYTES   0x80
> 
> > +/* Lower word is 'in' threshold, and higher word is 'out' threshold*/
> > +#define EHCI_INSNREG01_THRESH \
> > +   ((EHCI_MAX_THRESHOLD - 1)<<16 | (EHCI_MAX_THRESHOLD - 1))
> 
> Um, how about the following?
> 
> /* Register offset of in/out threshold */
> #define EHCI_INSNREG010x84
> /* The maximal threshold value is 0x80, which means 512 bytes */
> #define EHCI_THRESHOLD_512BYTES   0x80
> #define EHCI_THRESHOLD_508BYTES   0x79
> #define EHCI_THRESHOLD_OUT_SHIFT  16
> #define EHCI_THRESHOLD_IN_SHIFT   0
> 
>   ..
> 
>   /*
>* In order to support the isochronous/interrupt transactions,
>* 508 bytes should be used as max threshold values */
>*/
>   val =   ((EHCI_THRESHOLD_512BYTES - 1) << EHCI_THRESHOLD_OUT_SHIFT |
>   (EHCI_THRESHOLD_512BYTES - 1) << EHCI_THRESHOLD_IN_SHIFT);
>   writel(val, op_reg_base + EHCI_INSNREG01);

Sorry, please refer to the following.

/* Register offset of in/out threshold */
#define EHCI_INSNREG01  0x84
/* The maximal threshold value is 0x80, which means 512 bytes */
#define EHCI_THRESHOLD_512BYTES 0x80
#define EHCI_THRESHOLD_508BYTES 0x79
#define EHCI_THRESHOLD_OUT_SHIFT16
#define EHCI_THRESHOLD_IN_SHIFT 0

..

/*
 * In order to support the isochronous/interrupt transactions,
 * 508 bytes should be used as max threshold values */
 */
val =   (EHCI_THRESHOLD_508BYTES << EHCI_THRESHOLD_OUT_SHIFT |
(EHCI_THRESHOLD_508BYTES << EHCI_THRESHOLD_IN_SHIFT);
writel(val, op_reg_base + EHCI_INSNREG01);


> 
> 
> > +static void 

Re: [PATCH v2] USB: ehci-pci: USB host controller support for Intel Quark X1000

[Jingoo Han]

On Friday, June 27, 2014 8:25 PM, Alvin Chen wrote:
> 
> From: Bryan O'Donoghue 
> 
> The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000 
> USB host
> controller, and the default value is 0x20 dwords. The in/out threshold can be 
> programmed
> to 0x80 dwords, but only when isochronous/interrupt transactions are not 
> initiated by
> the USB host controller. This patch is to reconfigure the packet buffer 
> in/out threshold
> as maximal as possible, and it is 0x7F dwords since the USB host controller 
> initiates
> isochronous/interrupt transactions.

So, what is the reason to set the value as 0x80?
  1. The default value 0x20 makes some problems such as...
  2. To maximize the performance, ...
  3. Both
Please add the reason why 0x80 is necessary, as possible.

Then, 0x7F means 508 bytes? 'Intel Quark X1000 USB host controller'
can support 0x80 (512bytes), however, in this case, isochronous/interrupt
transactions cannot be initiated by 'Intel Quark X1000 USB host controller'.
Right?

So, 0x79 (508bytes?) should be used, because the isochronous/interrupt
transactions can be initiated by 'Intel Quark X1000 USB host controller'.
Right?

> 
> Signed-off-by: Bryan O'Donoghue 
> Signed-off-by: Alvin (Weike) Chen 
> ---
> changelog v2:
> *Change the function name from 'usb_is_intel_qrk' to 
> 'usb_is_intel_quark_x1000'.
> *Move the functions 'usb_is_intel_quark_x1000' and 'usb_set_qrk_bulk_thresh'
>  from 'pci-quirks.c' to 'ehci-pci.c'.
> *Remove unnecessary kernel message in the function of 
> 'usb_set_qrk_bulk_thresh'.
> *Remove 'unlikely' in the functions of 'ehci_pci_reinit'.
> *Add white space after 'if'.
> *Update the descriptions to make it more clearly.
> *Add Micros to avoid magic number.
> 
>  drivers/usb/host/ehci-pci.c |   45 
> +++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
> index 3e86bf4..ca29f34 100644
> --- a/drivers/usb/host/ehci-pci.c
> +++ b/drivers/usb/host/ehci-pci.c
> @@ -35,6 +35,47 @@ static const char hcd_name[] = "ehci-pci";
>  #define PCI_DEVICE_ID_INTEL_CE4100_USB   0x2e70
> 
>  /*-*/
> +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC  0x0939
> +static inline bool usb_is_intel_quark_x1000(struct pci_dev *pdev)
> +{
> + return pdev->vendor == PCI_VENDOR_ID_INTEL &&
> + pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
> +

Please don't add this unnecessary line.

> +}
> +
> +/* Register offset of in/out threshold */
> +#define EHCI_INSNREG01   0x84
> +/* The maximal threshold is 0x80 Dword */
> +#define EHCI_MAX_THRESHOLD  0X80

s/0X80/0x80

0x80 means 512 bytes. So, how about mentioning '0x80 means 512 bytes'
in this comment or the commit message?

Maybe, how about the following?

/* The maximal threshold value is 0x80, which means 512 bytes */
#define EHCI_THRESHOLD_512BYTES 0x80

> +/* Lower word is 'in' threshold, and higher word is 'out' threshold*/
> +#define EHCI_INSNREG01_THRESH \
> + ((EHCI_MAX_THRESHOLD - 1)<<16 | (EHCI_MAX_THRESHOLD - 1))

Um, how about the following?

/* Register offset of in/out threshold */
#define EHCI_INSNREG01  0x84
/* The maximal threshold value is 0x80, which means 512 bytes */
#define EHCI_THRESHOLD_512BYTES 0x80
#define EHCI_THRESHOLD_508BYTES 0x79
#define EHCI_THRESHOLD_OUT_SHIFT16
#define EHCI_THRESHOLD_IN_SHIFT 0

..

/*
 * In order to support the isochronous/interrupt transactions,
 * 508 bytes should be used as max threshold values */
 */
val =   ((EHCI_THRESHOLD_512BYTES - 1) << EHCI_THRESHOLD_OUT_SHIFT |
(EHCI_THRESHOLD_512BYTES - 1) << EHCI_THRESHOLD_IN_SHIFT);
writel(val, op_reg_base + EHCI_INSNREG01);


> +static void usb_set_qrk_bulk_thresh(struct pci_dev *pdev)

Please, use usb_set_qrk_bulk_threshold().
The 'threshold' looks better than 'thresh'.

> +{
> + void __iomem *base, *op_reg_base;
> + u8 cap_length;
> + u32 val;
> + u16 cmd;
> +
> + if (!pci_resource_start(pdev, 0))
> + return;
> +
> + if (pci_read_config_word(pdev, PCI_COMMAND, )
> + || !(cmd & PCI_COMMAND_MEMORY))
> + return;
> +
> + base = pci_ioremap_bar(pdev, 0);
> + if (base == NULL)
> + return;
> +
> + cap_length = readb(base);
> + op_reg_base = base + cap_length;
> +
> + val = EHCI_INSNREG01_THRESH;
> + writel(val, op_reg_base + EHCI_INSNREG01);
> +
> + iounmap(base);
> +}
> 
>  /* called after powerup, by probe or system-pm "wakeup" */
>  static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
> @@ -50,6 +91,10 @@ static int ehci_pci_reinit(struct ehci_hcd *ehci, struct 
> pci_dev *pdev)
>   if (!retval)
>   ehci_dbg(ehci, "MWI active\n");
> 
> + 

[PATCHv5 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC

[Chanwoo Choi]

This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.

Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC

Exynos3250 has additional 'sclk_adc' clock as following:
- 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC

Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
clock in FSYS_BLK.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 drivers/iio/adc/exynos_adc.c | 112 ++-
 1 file changed, 101 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 00d67fd..b63e882 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -81,9 +81,11 @@
 
 struct exynos_adc {
struct exynos_adc_data  *data;
+   struct device   *dev;
void __iomem*regs;
void __iomem*enable_reg;
struct clk  *clk;
+   struct clk  *sclk;
unsigned intirq;
struct regulator*vdd;
 
@@ -95,6 +97,7 @@ struct exynos_adc {
 
 struct exynos_adc_data {
int num_channels;
+   bool needs_sclk;
 
void (*init_hw)(struct exynos_adc *info);
void (*exit_hw)(struct exynos_adc *info);
@@ -102,6 +105,66 @@ struct exynos_adc_data {
void (*start_conv)(struct exynos_adc *info, unsigned long addr);
 };
 
+static void exynos_adc_unprepare_clk(struct exynos_adc *info)
+{
+   if (info->data->needs_sclk)
+   clk_unprepare(info->sclk);
+   clk_unprepare(info->clk);
+}
+
+static int exynos_adc_prepare_clk(struct exynos_adc *info)
+{
+   int ret;
+
+   ret = clk_prepare(info->clk);
+   if (ret) {
+   dev_err(info->dev, "failed preparing adc clock: %d\n", ret);
+   return ret;
+   }
+
+   if (info->data->needs_sclk) {
+   ret = clk_prepare(info->sclk);
+   if (ret) {
+   clk_unprepare(info->clk);
+   dev_err(info->dev,
+   "failed preparing sclk_adc clock: %d\n", ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+static void exynos_adc_disable_clk(struct exynos_adc *info)
+{
+   if (info->data->needs_sclk)
+   clk_disable(info->sclk);
+   clk_disable(info->clk);
+}
+
+static int exynos_adc_enable_clk(struct exynos_adc *info)
+{
+   int ret;
+
+   ret = clk_enable(info->clk);
+   if (ret) {
+   dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
+   return ret;
+   }
+
+   if (info->data->needs_sclk) {
+   ret = clk_enable(info->sclk);
+   if (ret) {
+   clk_disable(info->clk);
+   dev_err(info->dev,
+   "failed enabling sclk_adc clock: %d\n", ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
 static void exynos_adc_v1_init_hw(struct exynos_adc *info)
 {
u32 con1;
@@ -199,13 +262,20 @@ static void exynos_adc_v2_start_conv(struct exynos_adc 
*info,
writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
 }
 
+#define __EXYNOS_ADC_V2_DATA   \
+   .num_channels   = MAX_ADC_V2_CHANNELS,  \
+   .init_hw= exynos_adc_v2_init_hw,\
+   .exit_hw= exynos_adc_v2_exit_hw,\
+   .clear_irq  = exynos_adc_v2_clear_irq,  \
+   .start_conv = exynos_adc_v2_start_conv, \
+
 static struct exynos_adc_data const exynos_adc_v2_data = {
-   .num_channels   = MAX_ADC_V2_CHANNELS,
+   __EXYNOS_ADC_V2_DATA
+};
 
-   .init_hw= exynos_adc_v2_init_hw,
-   .exit_hw= exynos_adc_v2_exit_hw,
-   .clear_irq  = exynos_adc_v2_clear_irq,
-   .start_conv = exynos_adc_v2_start_conv,
+static struct exynos_adc_data const exynos3250_adc_v2_data = {
+   __EXYNOS_ADC_V2_DATA
+   .needs_sclk = true,
 };
 
 static const struct of_device_id exynos_adc_match[] = {
@@ -215,6 +285,9 @@ static const struct of_device_id exynos_adc_match[] = {
}, {
.compatible = "samsung,exynos-adc-v2",
.data = (void *)_adc_v2_data,
+   }, {
+   .compatible = "samsung,exynos3250-adc-v2",
+   .data = (void *)_adc_v2_data,
},
{},
 };
@@ -376,6 +449,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
}
 
info->irq = irq;
+   info->dev = >dev;
 
init_completion(>completion);
 
@@ -386,6 +460,16 @@ static int exynos_adc_probe(struct platform_device *pdev)
   

[PATCHv5 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC

[Chanwoo Choi]

This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_adc') for ADC which provide clock to internal ADC.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
Reviewed-by: Naveen Krishna Chatradhi 
---
 .../devicetree/bindings/arm/samsung/exynos-adc.txt | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..b87749a 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,14 +14,22 @@ Required properties:
for exynos4412/5250 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
+   Must be "samsung,exynos3250-adc-v2" for
+   for controllers compatible with ADC of
+   Exynos3250.
 - reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
 - interrupts:  Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the Samsung device uses.
 - #io-channel-cells = <1>; As ADC has multiple outputs
-- clocks   From common clock binding: handle to adc clock.
-- clock-names  From common clock binding: Shall be "adc".
+- clocks   From common clock bindings: handles to clocks specified
+   in "clock-names" property, in the same order.
+- clock-names  From common clock bindings: list of clock input names
+   used by ADC block:
+   - "adc" : ADC bus clock
+   - "sclk_adc" : ADC special clock (only for Exynos3250
+  and compatible ADC block)
 - vdd-supply   VDD input supply.
 
 Note: child nodes can be added for auto probing from device tree.
@@ -41,6 +49,20 @@ adc: adc@12D1 {
vdd-supply = <_reg>;
 };
 
+Example: adding device info in dtsi file for Exynos3250 with additional sclk
+
+adc: adc@126C {
+   compatible = "samsung,exynos3250-adc-v2";
+   reg = <0x126C 0x100>, <0x10020718 0x4>;
+   interrupts = <0 137 0>;
+   #io-channel-cells = <1>;
+   io-channel-ranges;
+
+   clocks = < CLK_TSADC>, < CLK_SCLK_TSADC>;
+   clock-names = "adc", "sclk_adc";
+
+   vdd-supply = <_reg>;
+};
 
 Example: Adding child nodes in dts file
 
-- 
1.8.0

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

[PATCHv5 1/4] iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability

[Chanwoo Choi]

This patchset add 'exynos_adc_data' structure which includes some functions
to control ADC operation and specific data according to ADC version (v1 or v2).

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
Reviewed-by: Naveen Krishna Chatradhi 
---
 drivers/iio/adc/exynos_adc.c | 226 ---
 1 file changed, 147 insertions(+), 79 deletions(-)

diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 010578f..00d67fd 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -39,11 +39,6 @@
 #include 
 #include 
 
-enum adc_version {
-   ADC_V1,
-   ADC_V2
-};
-
 /* EXYNOS4412/5250 ADC_V1 registers definitions */
 #define ADC_V1_CON(x)  ((x) + 0x00)
 #define ADC_V1_DLY(x)  ((x) + 0x08)
@@ -85,6 +80,7 @@ enum adc_version {
 #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
 
 struct exynos_adc {
+   struct exynos_adc_data  *data;
void __iomem*regs;
void __iomem*enable_reg;
struct clk  *clk;
@@ -97,43 +93,139 @@ struct exynos_adc {
unsigned intversion;
 };
 
-static const struct of_device_id exynos_adc_match[] = {
-   { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
-   { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
-   {},
+struct exynos_adc_data {
+   int num_channels;
+
+   void (*init_hw)(struct exynos_adc *info);
+   void (*exit_hw)(struct exynos_adc *info);
+   void (*clear_irq)(struct exynos_adc *info);
+   void (*start_conv)(struct exynos_adc *info, unsigned long addr);
 };
-MODULE_DEVICE_TABLE(of, exynos_adc_match);
 
-static inline unsigned int exynos_adc_get_version(struct platform_device *pdev)
+static void exynos_adc_v1_init_hw(struct exynos_adc *info)
 {
-   const struct of_device_id *match;
+   u32 con1;
 
-   match = of_match_node(exynos_adc_match, pdev->dev.of_node);
-   return (unsigned int)match->data;
+   writel(1, info->enable_reg);
+
+   /* set default prescaler values and Enable prescaler */
+   con1 =  ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+
+   /* Enable 12-bit ADC resolution */
+   con1 |= ADC_V1_CON_RES;
+   writel(con1, ADC_V1_CON(info->regs));
+}
+
+static void exynos_adc_v1_exit_hw(struct exynos_adc *info)
+{
+   u32 con;
+
+   writel(0, info->enable_reg);
+
+   con = readl(ADC_V1_CON(info->regs));
+   con |= ADC_V1_CON_STANDBY;
+   writel(con, ADC_V1_CON(info->regs));
+}
+
+static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
+{
+   writel(1, ADC_V1_INTCLR(info->regs));
 }
 
-static void exynos_adc_hw_init(struct exynos_adc *info)
+static void exynos_adc_v1_start_conv(struct exynos_adc *info,
+unsigned long addr)
+{
+   u32 con1;
+
+   writel(addr, ADC_V1_MUX(info->regs));
+
+   con1 = readl(ADC_V1_CON(info->regs));
+   writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info->regs));
+}
+
+static struct exynos_adc_data const exynos_adc_v1_data = {
+   .num_channels   = MAX_ADC_V1_CHANNELS,
+
+   .init_hw= exynos_adc_v1_init_hw,
+   .exit_hw= exynos_adc_v1_exit_hw,
+   .clear_irq  = exynos_adc_v1_clear_irq,
+   .start_conv = exynos_adc_v1_start_conv,
+};
+
+static void exynos_adc_v2_init_hw(struct exynos_adc *info)
 {
u32 con1, con2;
 
-   if (info->version == ADC_V2) {
-   con1 = ADC_V2_CON1_SOFT_RESET;
-   writel(con1, ADC_V2_CON1(info->regs));
+   writel(1, info->enable_reg);
 
-   con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
-   ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
-   writel(con2, ADC_V2_CON2(info->regs));
+   con1 = ADC_V2_CON1_SOFT_RESET;
+   writel(con1, ADC_V2_CON1(info->regs));
 
-   /* Enable interrupts */
-   writel(1, ADC_V2_INT_EN(info->regs));
-   } else {
-   /* set default prescaler values and Enable prescaler */
-   con1 =  ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+   con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
+   ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
+   writel(con2, ADC_V2_CON2(info->regs));
 
-   /* Enable 12-bit ADC resolution */
-   con1 |= ADC_V1_CON_RES;
-   writel(con1, ADC_V1_CON(info->regs));
-   }
+   /* Enable interrupts */
+   writel(1, ADC_V2_INT_EN(info->regs));
+}
+
+static void exynos_adc_v2_exit_hw(struct exynos_adc *info)
+{
+   u32 con;
+
+   writel(0, info->enable_reg);
+
+   con = readl(ADC_V2_CON1(info->regs));
+   con &= ~ADC_CON_EN_START;
+   writel(con, ADC_V2_CON1(info->regs));
+}
+
+static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
+{
+   writel(1, ADC_V2_INT_ST(info->regs));
+}
+
+static void exynos_adc_v2_start_conv(struct exynos_adc *info,
+  

[PATCHv5 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean

[Chanwoo Choi]

Changes from v4:
- Use 'exynos_adc_data' structure instead of 'exynos_adc_ops' structure
  and remove enum variable of ADC version
- Fix wrong name of special clock (sclk_tsadc -> sclk_adc)
- Add reviewed message by Naveen Krishna Chatradhi
- Add functions for ADC clock control

Changes from v3:
- Add new 'exynos_adc_ops' structure to improve readability according to
 Tomasz Figa comment[1]
 [1] https://lkml.org/lkml/2014/4/16/238
- Add new 'exynos3250-adc-v2' compatible string to support Exynos3250 ADC
- Fix wrong compaitlbe string of ADC in Exynos3250 dtsi file

Changes from v2:
- Check return value of clock function to deal with error exception
- Fix minor coding style to improve readability

Changes from v1:
- Add new "samsung,exynos-adc-v3" compatible to support Exynos3250 ADC
- Add a patch about DT binding documentation

Chanwoo Choi (4):
  iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability
  iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
  iio: devicetree: Add DT binding documentation for Exynos3250 ADC
  ARM: dts: Fix wrong compatible string for Exynos3250 ADC

 .../devicetree/bindings/arm/samsung/exynos-adc.txt |  26 +-
 arch/arm/boot/dts/exynos3250.dtsi  |   4 +-
 drivers/iio/adc/exynos_adc.c   | 326 +++--
 3 files changed, 268 insertions(+), 88 deletions(-)

-- 
1.8.0

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

[PATCHv5 4/4] ARM: dts: Fix wrong compatible string for Exynos3250 ADC

[Chanwoo Choi]

This patchset fix wrong compatible string for Exynos3250 ADC. Exynos3250 SoC
need to control only special clock for ADC. Exynos SoC except for Exynos3250
has not included special clock for ADC. The exynos ADC driver can control
special clock if compatible string is 'exynos3250-adc-v2'.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos3250.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 1a62a5a..57b1b95 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -404,10 +404,10 @@
};
 
adc: adc@126C {
-   compatible = "samsung,exynos-adc-v3";
+   compatible = "samsung,exynos3250-adc-v2";
reg = <0x126C 0x100>, <0x10020718 0x4>;
interrupts = <0 137 0>;
-   clock-names = "adc", "sclk_tsadc";
+   clock-names = "adc", "sclk_adc";
clocks = < CLK_TSADC>, < CLK_SCLK_TSADC>;
#io-channel-cells = <1>;
io-channel-ranges;
-- 
1.8.0

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

Re: Linux 3.15.2

[Greg KH]

On Thu, Jun 26, 2014 at 08:52:10PM -0700, Steven Noonan wrote:
> On Thu, Jun 26, 2014 at 5:23 PM, Josh Boyer  wrote:
> > On Thu, Jun 26, 2014 at 3:26 PM, Greg KH  wrote:
> >> I'm announcing the release of the 3.15.2 kernel.
> >>
> >> All users of the 3.15 kernel series must upgrade.
> >>
> >> The updated 3.15.y git tree can be found at:
> >> 
> >> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
> >> linux-3.15.y
> >> and can be browsed at the normal kernel.org git web browser:
> >> 
> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
> >
> > Is the patch for this stuck somewhere on kernel.org?  I see
> > patch-3.14.9.xz, but patch-3.15.2.xz is missing on both the kernel.org
> > front page and the 3.x http directory where we'd normally find it.
> >
> 
> Indeed, the patch for 3.10.45 is also missing.

I tried to push out the kernels from the Newark airport, and the emails
went out, and part of the tarballs / patches, but not everything before
my connection got dropped and I had to get on a plane back to Seattle.

I'll repush them again and they should show up soon.

sorry about that,

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: Linux 3.15.2

[Willy Tarreau]

On Thu, Jun 26, 2014 at 08:52:10PM -0700, Steven Noonan wrote:
> On Thu, Jun 26, 2014 at 5:23 PM, Josh Boyer  wrote:
> > On Thu, Jun 26, 2014 at 3:26 PM, Greg KH  wrote:
> >> I'm announcing the release of the 3.15.2 kernel.
> >>
> >> All users of the 3.15 kernel series must upgrade.
> >>
> >> The updated 3.15.y git tree can be found at:
> >> 
> >> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
> >> linux-3.15.y
> >> and can be browsed at the normal kernel.org git web browser:
> >> 
> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
> >
> > Is the patch for this stuck somewhere on kernel.org?  I see
> > patch-3.14.9.xz, but patch-3.15.2.xz is missing on both the kernel.org
> > front page and the 3.x http directory where we'd normally find it.
> >
> 
> Indeed, the patch for 3.10.45 is also missing.

Both are there now :

  https://www.kernel.org/pub/linux/kernel/v3.x/patch-3.15.2.xz
  https://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.45.xz

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] target: fix deadlock on unload

[Nicholas A. Bellinger]

Hi Mikulas,

On Mon, 2014-06-23 at 13:42 -0400, Mikulas Patocka wrote:
> target: fix deadlock on unload
> 
> On uniprocessor preemptible kernel, target core deadlocks on unload. The
> following events happen:
> * iscsit_del_np is called
> * it calls send_sig(SIGINT, np->np_thread, 1);
> * the scheduler switches to the np_thread
> * the np_thread is woken up, it sees that kthread_should_stop() returns
>   false, so it doesn't terminate
> * the np_thread clears signals with flush_signals(current); and goes back
>   to sleep in iscsit_accept_np
> * the scheduler switches back to iscsit_del_np
> * iscsit_del_np calls kthread_stop(np->np_thread);
> * the np_thread is waiting in iscsit_accept_np and it doesn't respond to
>   kthread_stop
> 
> The deadlock could be resolved if the administrator sends SIGINT signal to
> the np_thread with killall -INT iscsi_np
> 
> The reproducible deadlock was introduced in commit
> db6077fd0b7dd41dc6ff18329cec979379071f87, but the thread-stopping code was
> racy even before.
> 
> This patch fixes the problem. Using kthread_should_stop to stop the
> np_thread is unreliable, so we test np_thread_state instead. If
> np_thread_state equals ISCSI_NP_THREAD_SHUTDOWN, the thread exits.
> 
> Signed-off-by: Mikulas Patocka 
> Cc: sta...@vger.kernel.org
> 

Apologies for the delayed response..

Applied to target-pending/master and including in the next -rc3 PULL
request.

Also FYI, I've added '3.12+' to the stable tag to match how far back
commit db6077fd0 has been included in stable.

Thanks,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: wlan-ng/hfa384x_usb.c: add blank line after declarations

[Greg Kroah-Hartman]

On Thu, Jun 26, 2014 at 10:43:55PM +0800, Cheng-Wei Lee wrote:
> This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
> WARNING: Missing a blank line after declarations
> 
> Signed-off-by: Quentin Lee 
> ---
>  drivers/staging/wlan-ng/hfa384x_usb.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
> b/drivers/staging/wlan-ng/hfa384x_usb.c
> index 98343ff7..07cee56 100644
> --- a/drivers/staging/wlan-ng/hfa384x_usb.c
> +++ b/drivers/staging/wlan-ng/hfa384x_usb.c
> @@ -3705,6 +3705,7 @@ static void hfa384x_usbout_callback(struct urb *urb)
>   case -EPIPE:
>   {
>   hfa384x_t *hw = wlandev->priv;
> +
>   netdev_warn(hw->wlandev->netdev,
>   "%s tx pipe stalled: requesting 
> reset\n",
>   wlandev->netdev->name);
> -- 
> 1.7.9.5

You have sent a bunch of patches, and no "version" information as to
which ones to apply and which ones superseed others.

So I've deleted them all from my inbox, can you please resend the proper
ones that you wish to have applied?

thanks,

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/

[PATCH] dm-io: Prevent the danging point of the sync io callback function

[Minfei Huang]

BUG: unable to handle kernel NULL pointer dereference at 0046
IP: [] dec_count+0x5f/0x80 [dm_mod]
PGD 0
Oops:  [#1] SMP
last sysfs file: 
/sys/devices/pci:00/:00:02.2/:02:00.0/host0/scsi_host/host0/proc_name

Pid: 2708, comm: kcopyd Tainted: GW  --- H  
2.6.32-279.19.5.el6.ucloud.x86_64 #1 Dell Inc. PowerEdge R720xd/0DCWD1
RIP: 0010:[]  [] dec_count+0x5f/0x80 
[dm_mod]
RSP: 0018:880100603c30  EFLAGS: 00010246
RAX: 0046 RBX: 8817968a5c30 RCX: 
RDX:  RSI:  RDI: 8817968a5c00
RBP: 880100603c50 R08:  R09: 
R10: 880caa594cc0 R11:  R12: 8817968a5c80
R13: 81013963 R14: 1000 R15: 
FS:  () GS:88010060() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 0046 CR3: 00020c309000 CR4: 001426e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process kcopyd (pid: 2708, threadinfo 88180cd26000, task 881841c9aa80)
Stack:
 880100603c40 880aa8b32300  8817968a5c00
 880100603c80 a000a12a  880aa8b32300
  880caa594cc0 880100603c90 811bcf6d
Call Trace:
 
 [] endio+0x4a/0x70 [dm_mod]
 [] bio_endio+0x1d/0x40
 [] req_bio_endio+0x9b/0xe0
 [] blk_update_request+0x104/0x500
 [] ? blk_update_request+0x321/0x500
 [] blk_update_bidi_request+0x27/0xa0
 [] blk_end_bidi_request+0x2f/0x80
 [] blk_end_request+0x10/0x20
 [] scsi_io_completion+0xaf/0x6c0
 [] scsi_finish_command+0xc2/0x130
 [] scsi_softirq_done+0x145/0x170
 [] blk_done_softirq+0x8d/0xa0
 [] __do_softirq+0xdf/0x210
 [] call_softirq+0x1c/0x30
 [] do_softirq+0xad/0xe0
 [] irq_exit+0x95/0xa0
 [] do_IRQ+0x75/0xf0
 [] ret_from_intr+0x0/0x16

The value of rdi register(0x8817968a5c00) is the io pointer,
If the sync io, the address of io point must be alloc from stack.
SO
crash> struct thread_info 8817968a4000
struct thread_info {
  task = 0x88180cd9a580,
  exec_domain = 0x81a98ac0,
 ...
}

crash> struct task_struct 0x88180cd9a580
struct task_struct {
  state = 2,
  stack = 0x8817968a4000,
 ...
}

It shows value exactly when use the value of io address.

The io address in callback function will become the danging point,
cause by the thread of sync io wakes up by other threads
and return to relieve the io address,

Signed-off-by: Minfei Huang 
---
 drivers/md/dm-io.c |   19 +++
 1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c
index 3842ac7..f992913 100644
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
@@ -38,6 +38,7 @@ struct io {
void *context;
void *vma_invalidate_address;
unsigned long vma_invalidate_size;
+   atomic_t wakeup;
 } __attribute__((aligned(DM_IO_MAX_REGIONS)));
 
 static struct kmem_cache *_dm_io_cache;
@@ -121,10 +122,16 @@ static void dec_count(struct io *io, unsigned int region, 
int error)
invalidate_kernel_vmap_range(io->vma_invalidate_address,
 io->vma_invalidate_size);
 
-   if (io->sleeper)
-   wake_up_process(io->sleeper);
+   if (io->sleeper) {
+   struct task_struct *sleeper = io->sleeper;
 
-   else {
+   atomic_set(>wakeup, 1);
+/*
+ * The thread may be waked up by other threads,
+ * if then the sync io point will become the dangling pointer
+ */
+   wake_up_process(sleeper);
+   } else {
unsigned long r = io->error_bits;
io_notify_fn fn = io->callback;
void *context = io->context;
@@ -401,12 +408,14 @@ static int sync_io(struct dm_io_client *client, unsigned 
int num_regions,
io->vma_invalidate_address = dp->vma_invalidate_address;
io->vma_invalidate_size = dp->vma_invalidate_size;
 
+   atomic_set(>wakeup, 0);
+
dispatch_io(rw, num_regions, where, dp, io, 1);
 
while (1) {
set_current_state(TASK_UNINTERRUPTIBLE);
 
-   if (!atomic_read(>count))
+   if (atomic_read(>wakeup))
break;
 
io_schedule();
@@ -442,6 +451,8 @@ static int async_io(struct dm_io_client *client, unsigned 
int num_regions,
io->vma_invalidate_address = dp->vma_invalidate_address;
io->vma_invalidate_size = dp->vma_invalidate_size;
 
+   atomic_set(>wakeup, 0);
+
dispatch_io(rw, num_regions, where, dp, io, 0);
return 0;
 }
-- 
1.7.1


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

Re: [PATCH 1/3] staging: rtl8188eu: core: Remove unnecessary conditionals

[Greg KH]

On Sun, Jun 22, 2014 at 01:01:50PM +0200, Thomas Vegas wrote:
> The variable 'pxmitbuf' is already set to NULL when entering the
> function. We can remove the first conditional. When _rtw_queue_empty()
> returns false, 'pxmitbuf' if not NULL. We can merge the second and
> third conditional.
> 
> Signed-off-by: Thomas Vegas 
> ---
>  drivers/staging/rtl8188eu/core/rtw_xmit.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)

Due to changes by others in this file, your patches do not apply
anymore, sorry.

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/

[PATCH net-next v2] 6lowpan: mac802154: fix coding style issues

[Varka Bhadram]

This patch fixed the coding style issues reported by checkpatch.pl

following issues fixed:
CHECK: Alignment should match open parenthesis
WARNING: line over 80 characters
CHECK: Blank lines aren't necessary before a close brace '}'
WARNING: networking block comments don't use an empty /* line, use /* 
Comment...
WARNING: Missing a blank line after declarations
WARNING: networking block comments start with * on subsequent lines
CHECK: braces {} should be used on all arms of this statement

Signed-off-by: Varka Bhadram 
---
 net/ieee802154/6lowpan_iphc.c  |  113 ++--
 net/ieee802154/6lowpan_rtnl.c  |   16 +++---
 net/ieee802154/af_ieee802154.c |   26 +
 net/ieee802154/dgram.c |   28 +-
 net/ieee802154/ieee802154.h|2 +-
 net/ieee802154/netlink.c   |4 +-
 net/ieee802154/nl-mac.c|   48 +
 net/ieee802154/nl-phy.c|   23 
 net/ieee802154/raw.c   |   14 +++--
 net/ieee802154/reassembly.c|1 +
 net/ieee802154/wpan-class.c|   10 ++--
 net/mac802154/ieee802154_dev.c |4 +-
 net/mac802154/llsec.c  |1 +
 net/mac802154/mib.c|7 +--
 net/mac802154/tx.c |1 +
 15 files changed, 153 insertions(+), 145 deletions(-)

diff --git a/net/ieee802154/6lowpan_iphc.c b/net/ieee802154/6lowpan_iphc.c
index 211b568..511ddee 100644
--- a/net/ieee802154/6lowpan_iphc.c
+++ b/net/ieee802154/6lowpan_iphc.c
@@ -3,8 +3,7 @@
  * written by Alexander Smirnov 
  */
 
-/*
- * Based on patches from Jon Smirl 
+/* Based on patches from Jon Smirl 
  * Copyright (c) 2011 Jon Smirl 
  *
  * This program is free software; you can redistribute it and/or modify
@@ -58,16 +57,15 @@
 #include 
 #include 
 
-/*
- * Uncompress address function for source and
+/* Uncompress address function for source and
  * destination address(non-multicast).
  *
  * address_mode is sam value or dam value.
  */
 static int uncompress_addr(struct sk_buff *skb,
-   struct in6_addr *ipaddr, const u8 address_mode,
-   const u8 *lladdr, const u8 addr_type,
-   const u8 addr_len)
+  struct in6_addr *ipaddr, const u8 address_mode,
+  const u8 *lladdr, const u8 addr_type,
+  const u8 addr_len)
 {
bool fail;
 
@@ -140,13 +138,12 @@ static int uncompress_addr(struct sk_buff *skb,
return 0;
 }
 
-/*
- * Uncompress address function for source context
+/* Uncompress address function for source context
  * based address(non-multicast).
  */
 static int uncompress_context_based_src_addr(struct sk_buff *skb,
-   struct in6_addr *ipaddr,
-   const u8 sam)
+struct in6_addr *ipaddr,
+const u8 sam)
 {
switch (sam) {
case LOWPAN_IPHC_ADDR_00:
@@ -175,13 +172,13 @@ static int uncompress_context_based_src_addr(struct 
sk_buff *skb,
 }
 
 static int skb_deliver(struct sk_buff *skb, struct ipv6hdr *hdr,
-   struct net_device *dev, skb_delivery_cb deliver_skb)
+  struct net_device *dev, skb_delivery_cb deliver_skb)
 {
struct sk_buff *new;
int stat;
 
-   new = skb_copy_expand(skb, sizeof(struct ipv6hdr), skb_tailroom(skb),
-   GFP_ATOMIC);
+   new = skb_copy_expand(skb, sizeof(struct ipv6hdr),
+ skb_tailroom(skb), GFP_ATOMIC);
kfree_skb(skb);
 
if (!new)
@@ -196,7 +193,7 @@ static int skb_deliver(struct sk_buff *skb, struct ipv6hdr 
*hdr,
new->dev = dev;
 
raw_dump_table(__func__, "raw skb data dump before receiving",
-   new->data, new->len);
+  new->data, new->len);
 
stat = deliver_skb(new, dev);
 
@@ -210,8 +207,8 @@ static int skb_deliver(struct sk_buff *skb, struct ipv6hdr 
*hdr,
  */
 static int
 lowpan_uncompress_multicast_daddr(struct sk_buff *skb,
-   struct in6_addr *ipaddr,
-   const u8 dam)
+ struct in6_addr *ipaddr,
+ const u8 dam)
 {
bool fail;
 
@@ -314,8 +311,7 @@ uncompress_udp_header(struct sk_buff *skb, struct udphdr 
*uh)
fail |= lowpan_fetch_skb(skb, >check, 2);
}
 
-   /*
-* UDP lenght needs to be infered from the lower layers
+   /* UDP lenght needs to be infered from the lower layers
 * here, we obtain the hint from the remaining size of the
 * frame
 */
@@ -338,16 +334,17 @@ err:
 static const u8 lowpan_ttl_values[] = { 0, 1, 64, 255 };
 
 int 

Re: [PATCH 1/2 RESEND] staging: lirc: fix checkpath errors: blank lines

[Greg KH]

On Wed, Jun 25, 2014 at 09:14:30AM +0200, Raphael Poggi wrote:
> This patch fix checkpath "WARNING: Missing a blank line after declarations"
> 
> Signed-off-by: Raphaël Poggi 
> ---
>  drivers/staging/media/lirc/lirc_imon.c |3 +++

Please use scripts/get_maintainer.pl to find out who patches for this
file should be sent to (hint, it's not me...)

thanks,

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/13] leds: fix attribute-creation races

[Greg Kroah-Hartman]

On Wed, Jun 25, 2014 at 03:46:19PM -0700, Bryan Wu wrote:
> On Wed, Jun 25, 2014 at 10:08 AM, Johan Hovold  wrote:
> > LED-class device attributes should be created using the attribute groups
> > of struct device, rather than be added manually after the device has
> > been registered in order to avoid racing with userspace.
> >
> > The first patch adds an attribute groups field to struct led_classdev,
> > which is used during registration to add device attributes in a
> > race-free manner.
> >
> > The remaining patches convert the current racy LED-device attribute
> > creations to use the new facility. Hopefully my grep-patterns have
> > caught most instances. Note that this also tends to simplify probe error
> > paths.
> >
> > The lp55xx-common failed to remove the attribute group it is currently
> > creating, something which is fixed separately.
> >
> > Note that this series include one driver from drivers/input/keyboard.
> >
> > The individual led-driver patches have been compile tested only.
> >
> 
> Thanks a lot for driving this. I will applied this patchset into my
> -devel branch. After I got the Ack from Input guys, I will apply it to
> my for-next branch then.

Series looks good to me, Johan, thanks for doing this work.

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/

[PATCH 1/2] usb: chipidea: zynq: Add device tree binding information

[Punnaiah Choudary Kalluri]

Document device tree binding information as required by
the ZYNQ USB controller.

Signed-off-by: Punnaiah Choudary Kalluri 
---
 .../devicetree/bindings/usb/ci-hdrc-zynq.txt   |   23 
 1 files changed, 23 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt
new file mode 100644
index 000..54bb3b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt
@@ -0,0 +1,23 @@
+Xilinx Zynq usb controller based on synopsys usb IP(v2.20a)
+
+Required properties:
+- compatible:   should contain "xlnx,zynq-usb-2.20a"
+- clocks:   clock provider specifier
+- reg:  offset and length of the register set in the memory map
+- interrupt-parent: the phandle for the interrupt controller that services
+interrupts for this device.
+- interrupts:   interrupt-specifier for the controller interrupt.
+- phy_type: should be "ulpi"
+- dr_mode:  should be "peripheral" or "host"
+
+Examples:
+
+   usb@e0002000 {
+   clocks = < 28>;
+   compatible = "xlnx,zynq-usb-2.20a";
+   dr_mode = "host";
+   interrupt-parent = <_scugic_0>;
+   interrupts = <0 21 4>;
+   phy_type = "ulpi";
+   reg = <0xe0002000 0x1000>;
+   } ;
-- 
1.7.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 2/2] usb: chipidea: Add support for zynq usb host and device controller

[Punnaiah Choudary Kalluri]

Zynq soc usb controller is a synopsys IP and it is compatible
with the chipidea spec. So, reusing chipidea drivers for zynq usb
controller.

Signed-off-by: Punnaiah Choudary Kalluri 
---
 drivers/usb/chipidea/Makefile   |1 +
 drivers/usb/chipidea/ci_hdrc_zynq.c |  115 +++
 2 files changed, 116 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/chipidea/ci_hdrc_zynq.c

diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 2f099c7..b0d6b6f 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -12,6 +12,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM) += otg_fsm.o
 
 obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_msm.o
 obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zevio.o
+obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zynq.o
 
 # PCI doesn't provide stubs, need to check
 ifneq ($(CONFIG_PCI),)
diff --git a/drivers/usb/chipidea/ci_hdrc_zynq.c 
b/drivers/usb/chipidea/ci_hdrc_zynq.c
new file mode 100644
index 000..b3667da
--- /dev/null
+++ b/drivers/usb/chipidea/ci_hdrc_zynq.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (C) 2014 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it 
under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ci.h"
+
+#define ZYNQ_USB_DMA_MASK  0xFFF0
+
+struct ci_hdrc_zynq_data {
+   struct platform_device *ci_pdev;
+   struct clk *clk;
+};
+
+static struct ci_hdrc_platform_data pdata = {
+   .name   = "ci_hdrc_zynq",
+   .capoffset  = DEF_CAPOFFSET,
+   .flags  = CI_HDRC_REQUIRE_TRANSCEIVER
+};
+
+static int ci_hdrc_zynq_probe(struct platform_device *pdev)
+{
+   struct ci_hdrc_zynq_data *data;
+   int ret;
+
+   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   if (!data) {
+   dev_err(>dev, "Failed to allocate ci_hdrc-imx data!\n");
+   return -ENOMEM;
+   }
+
+   data->clk = devm_clk_get(>dev, NULL);
+   if (IS_ERR(data->clk)) {
+   dev_err(>dev,
+   "Failed to get clock, err=%ld\n", PTR_ERR(data->clk));
+   return PTR_ERR(data->clk);
+   }
+
+   ret = clk_prepare_enable(data->clk);
+   if (ret) {
+   dev_err(>dev,
+   "Failed to prepare or enable clock, err=%d\n", ret);
+   return ret;
+   }
+
+   ret = dma_coerce_mask_and_coherent(>dev, ZYNQ_USB_DMA_MASK);
+   if (ret)
+   goto err_clk;
+
+   data->ci_pdev = ci_hdrc_add_device(>dev,
+   pdev->resource, pdev->num_resources,
+   );
+   if (IS_ERR(data->ci_pdev)) {
+   ret = PTR_ERR(data->ci_pdev);
+   dev_err(>dev,
+   "Can't register ci_hdrc platform device, err=%d\n",
+   ret);
+   goto err_clk;
+   }
+
+   platform_set_drvdata(pdev, data);
+
+   pm_runtime_no_callbacks(>dev);
+   pm_runtime_enable(>dev);
+   return 0;
+
+err_clk:
+   clk_disable_unprepare(data->clk);
+   return ret;
+}
+
+static int ci_hdrc_zynq_remove(struct platform_device *pdev)
+{
+   struct ci_hdrc_zynq_data *data = platform_get_drvdata(pdev);
+
+   pm_runtime_disable(>dev);
+   ci_hdrc_remove_device(data->ci_pdev);
+   clk_disable_unprepare(data->clk);
+
+   return 0;
+}
+
+static const struct of_device_id ci_hdrc_zynq_dt_ids[] = {
+   { .compatible = "xlnx,zynq-usb-2.20a" },
+   {},
+};
+
+static struct platform_driver ci_hdrc_zynq_driver = {
+   .probe = ci_hdrc_zynq_probe,
+   .remove = ci_hdrc_zynq_remove,
+   .driver = {
+   .name = "zynq_usb",
+   .owner = THIS_MODULE,
+   .of_match_table = ci_hdrc_zynq_dt_ids,
+},
+};
+
+module_platform_driver(ci_hdrc_zynq_driver);
+
+MODULE_ALIAS("platform:zynq_usb");
+MODULE_DESCRIPTION("CI HDRC ZYNQ USB binding");
+MODULE_AUTHOR("Xilinx Inc");
+MODULE_LICENSE("GPL v2");
-- 
1.7.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 v4 13/13] ARM64 / ACPI: Enable ARM64 in Kconfig

[Hanjun Guo]

From: Graeme Gregory 

Add Kconfigs to build ACPI on ARM64, and make ACPI available on ARM64.

acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR
depend on X86 || IA64, and implement it on ARM64 in the future.

Reviewed-by: Grant Likely 
Signed-off-by: Graeme Gregory 
Signed-off-by: Al Stone 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/Kconfig   |2 ++
 drivers/acpi/Kconfig |5 +++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 102384e..314634f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -377,6 +377,8 @@ source "drivers/Kconfig"
 
 source "drivers/firmware/Kconfig"
 
+source "drivers/acpi/Kconfig"
+
 source "fs/Kconfig"
 
 source "arch/arm64/kvm/Kconfig"
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7de5e3f..33d6dbb 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -8,10 +8,10 @@ config ACPI_SCAN_BIOS_NOT_EFI
 menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
depends on !IA64_HP_SIM
-   depends on IA64 || X86
+   depends on IA64 || X86 || ARM64
depends on PCI
select PNP
-   default y
+   default y if !ARM64
help
  Advanced Configuration and Power Interface (ACPI) support for 
  Linux requires an ACPI-compliant platform (hardware/firmware),
@@ -161,6 +161,7 @@ config ACPI_PROCESSOR
tristate "Processor"
select THERMAL
select CPU_IDLE
+   depends on X86 || IA64
default y
help
  This driver installs ACPI as the idle handler for Linux and uses
-- 
1.7.9.5

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

[PATCH v4 10/13] ACPI: Make EC debugfs depend on X86 || IA64 in Kconfig

[Hanjun Guo]

Since EC (Embedded controller) needs SCI for the interupt which
is not available on ARM64, make the EC debugfs depend on X86 || IA64
only in the Kconfig file.

Reviewed-by: Grant Likely 
Signed-off-by: Hanjun Guo 
---
 drivers/acpi/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 0e6f72d..7de5e3f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -69,6 +69,7 @@ config ACPI_PROCFS_POWER
 
 config ACPI_EC_DEBUGFS
tristate "EC read/write access through /sys/kernel/debug/ec"
+   depends on X86 || IA64
default n
help
  Say N to disable Embedded Controller /sys/kernel/debug interface
-- 
1.7.9.5

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

[PATCH v4 09/13] ARM64 / ACPI: Introduce PCI functions for ACPI on ARM64

[Hanjun Guo]

CONFIG_ACPI depends CONFIG_PCI now, and ACPI provides ACPI based
PCI hotplug and PCI host bridge hotplug, introduce some PCI
functions to make ACPI core can be compiled, some of the functions
should be revisited when implemented on ARM64.

Reviewed-by: Grant Likely 
Originally-by: Graeme Gregory 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/include/asm/pci.h |6 ++
 arch/arm64/kernel/pci.c  |   28 
 2 files changed, 34 insertions(+)

diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
index d93576f..46501d4 100644
--- a/arch/arm64/include/asm/pci.h
+++ b/arch/arm64/include/asm/pci.h
@@ -21,6 +21,12 @@ struct pci_host_bridge *find_pci_host_bridge(struct pci_bus 
*bus);
 #define pcibios_assign_all_busses() \
(pci_has_flag(PCI_REASSIGN_ALL_BUS))
 
+static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
+{
+   /* no legacy IRQ on arm64 */
+   return -ENODEV;
+}
+
 /*
  * PCI address space differs from physical memory address space
  */
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 9f29c9a..1f7aedd 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -171,3 +172,30 @@ unsigned long pci_ioremap_io(const struct resource *res, 
phys_addr_t phys_addr)
/* return io_offset */
return start * PAGE_SIZE - res->start;
 }
+
+/*
+ * raw_pci_read - Platform-specific PCI config space access.
+ *
+ * Default empty implementation.  Replace with an architecture-specific setup
+ * routine, if necessary.
+ */
+int raw_pci_read(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 *val)
+{
+   return -EINVAL;
+}
+
+int raw_pci_write(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 val)
+{
+   return -EINVAL;
+}
+
+#ifdef CONFIG_ACPI
+/* Root bridge scanning */
+struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
+{
+   /* TODO: Should be revisited when implementing PCI on ACPI */
+   return NULL;
+}
+#endif
-- 
1.7.9.5

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

[PATCH v4 11/13] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64

[Hanjun Guo]

From: Al Stone 

ACPI reduced hardware mode is disabled by default, but ARM64
can only run properly in ACPI hardware reduced mode, so select
ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64.

Reviewed-by: Grant Likely 
Signed-off-by: Al Stone 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index db5190a..102384e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1,5 +1,6 @@
 config ARM64
def_bool y
+   select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_USE_CMPXCHG_LOCKREF
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
-- 
1.7.9.5

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

[PATCH v4 08/13] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Hanjun Guo]

arch_fix_phys_package_id() will be called in ACPI core to use
the slot number provided by ACPI to update the physical package
id, then we can get the right value in the "physical id" field
of /proc/cpuinfo.

Reviewed-by: Grant Likely 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/include/asm/topology.h |2 ++
 arch/arm64/kernel/topology.c  |   14 ++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/topology.h 
b/arch/arm64/include/asm/topology.h
index 7ebcd31..2b216d4 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
 void init_cpu_topology(void);
 void store_cpu_topology(unsigned int cpuid);
 const struct cpumask *cpu_coregroup_mask(int cpu);
+void arch_fix_phys_package_id(int num, u32 slot);
 
 #else
 
 static inline void init_cpu_topology(void) { }
 static inline void store_cpu_topology(unsigned int cpuid) { }
+static inline void arch_fix_phys_package_id(int num, u32 slot) { }
 
 #endif
 
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 43514f9..c547885 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
if (parse_dt_topology())
reset_cpu_topology();
 }
+
+/*
+ * Use the CPU slot number provided by ACPI to update the physical
+ * package id when cpuid_topo->cluster_id is not available, then we
+ * can get the right value in the "physical id" field of /proc/cpuinfo.
+ */
+void arch_fix_phys_package_id(int num, u32 slot)
+{
+   struct cpu_topology *cpuid_topo = _topology[num];
+
+   if (cpuid_topo->cluster_id == -1)
+   cpuid_topo->cluster_id = slot;
+}
+EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
-- 
1.7.9.5

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

Re: Linux 3.15.2

[Steven Noonan]

On Thu, Jun 26, 2014 at 5:23 PM, Josh Boyer  wrote:
> On Thu, Jun 26, 2014 at 3:26 PM, Greg KH  wrote:
>> I'm announcing the release of the 3.15.2 kernel.
>>
>> All users of the 3.15 kernel series must upgrade.
>>
>> The updated 3.15.y git tree can be found at:
>> 
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
>> linux-3.15.y
>> and can be browsed at the normal kernel.org git web browser:
>> 
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
>
> Is the patch for this stuck somewhere on kernel.org?  I see
> patch-3.14.9.xz, but patch-3.15.2.xz is missing on both the kernel.org
> front page and the 3.x http directory where we'd normally find it.
>

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

[PATCH v4 12/13] ARM64 / ACPI: if we chose to boot from acpi then disable FDT

[Hanjun Guo]

From: Graeme Gregory 

If the early boot methods of acpi are happy that we have valid ACPI
tables and acpi=off has not been passed. Then do not unflat devicetree
effectively disabling further hardware probing from DT.

Signed-off-by: Graeme Gregory 
---
 arch/arm64/kernel/setup.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 9dedb0b..487fd1f 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -394,7 +394,8 @@ void __init setup_arch(char **cmdline_p)
 
efi_idmap_init();
 
-   unflatten_device_tree();
+   if (acpi_disabled)
+   unflatten_device_tree();
 
psci_init();
 
-- 
1.7.9.5

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

[PATCH v4 04/13] ARM64 : Add dummy asm/cpu.h

[Hanjun Guo]

From: Graeme Gregory 

ACPI core requires a cpu.h, add a dummy one here temporarily.
This file will be updated in the future to add definitions for
arch_(un)register_cpu which are required for ACPI based physical
CPU hotplug when these standards have be ratified by the ASWG.

Reviewed-by: Grant Likely 
Signed-off-by: Graeme Gregory 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/include/asm/cpu.h |   11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 arch/arm64/include/asm/cpu.h

diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
new file mode 100644
index 000..cee7d3f
--- /dev/null
+++ b/arch/arm64/include/asm/cpu.h
@@ -0,0 +1,11 @@
+/*
+ *  Copyright (C) 2013-2014 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ASM_CPU_H
+#define __ASM_CPU_H
+
+#endif
-- 
1.7.9.5

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

[PATCH v4 06/13] ARM64 / ACPI: Introduce early_param for "acpi"

[Hanjun Guo]

From: Al Stone 

Introduce two early parameters for "acpi", one is the parameter
to disable ACPI on ARM64 and another one is acpi=strict to disable
out-of-spec workarounds.

Reviewed-by: Grant Likely 
Signed-off-by: Al Stone 
Signed-off-by: Graeme Gregory 
Signed-off-by: Hanjun Guo 
---
 Documentation/kernel-parameters.txt |3 ++-
 drivers/acpi/plat/arm-core.c|   21 +
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 8849049..b7e9fc0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -165,7 +165,7 @@ multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 
2^20, and 2^30
 bytes respectively. Such letter suffixes can also be entirely omitted.
 
 
-   acpi=   [HW,ACPI,X86]
+   acpi=   [HW,ACPI,X86,ARM]
Advanced Configuration and Power Interface
Format: { force | off | strict | noirq | rsdt }
force -- enable ACPI if default was off
@@ -175,6 +175,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
strictly ACPI specification compliant.
rsdt -- prefer RSDT over (default) XSDT
copy_dsdt -- copy DSDT to memory
+   For ARM64, ONLY "off" and "strict" are available.
 
See also Documentation/power/runtime_pm.txt, pci=noacpi
 
diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
index c6c7e03..cf46c25 100644
--- a/drivers/acpi/plat/arm-core.c
+++ b/drivers/acpi/plat/arm-core.c
@@ -108,3 +108,24 @@ void __init acpi_boot_table_init(void)
return;
}
 }
+
+static int __init parse_acpi(char *arg)
+{
+   if (!arg)
+   return -EINVAL;
+
+   /* "acpi=off" disables both ACPI table parsing and interpreter */
+   if (strcmp(arg, "off") == 0) {
+   disable_acpi();
+   }
+   /* acpi=strict disables out-of-spec workarounds */
+   else if (strcmp(arg, "strict") == 0) {
+   acpi_strict = 1;
+   } else {
+   /* Core will printk when we return error */
+   return -EINVAL;
+   }
+
+   return 0;
+}
+early_param("acpi", parse_acpi);
-- 
1.7.9.5

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

[PATCH v4 05/13] ARM64 / ACPI: Introduce arm-core.c and its related head file

[Hanjun Guo]

From: Al Stone 

ACPI core need lots extern variables and functions which should
be provided by arch dependent code to make itself compilable. so
introduce arm-core.c and its related header file here, we need:
  - asm/acenv.h for arch specific ACPICA environments and
implementation;
  - asm/acpi.h for arch specific variables and functions needed by
ACPI driver core;
  - arm-core.c for ARM64 related ACPI implementation for ACPI driver
core;

acpi_boot_table_init() will be called in setup_arch() before
paging_init(), so we should use eary_memremap() mechanism here
to get the RSDP and all the table pointers. with this patch,
we can get ACPI boot-time tables from firmware on ARM64.

Reviewed-by: Grant Likely 
Signed-off-by: Al Stone 
Signed-off-by: Graeme Gregory 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/include/asm/acenv.h |   18 +++
 arch/arm64/include/asm/acpi.h  |   49 ++
 arch/arm64/kernel/setup.c  |4 ++
 drivers/acpi/Makefile  |2 +
 drivers/acpi/plat/Makefile |1 +
 drivers/acpi/plat/arm-core.c   |  110 
 6 files changed, 184 insertions(+)
 create mode 100644 arch/arm64/include/asm/acenv.h
 create mode 100644 arch/arm64/include/asm/acpi.h
 create mode 100644 drivers/acpi/plat/Makefile
 create mode 100644 drivers/acpi/plat/arm-core.c

diff --git a/arch/arm64/include/asm/acenv.h b/arch/arm64/include/asm/acenv.h
new file mode 100644
index 000..3899ee6
--- /dev/null
+++ b/arch/arm64/include/asm/acenv.h
@@ -0,0 +1,18 @@
+/*
+ * ARM64 specific ACPICA environments and implementation
+ *
+ * Copyright (C) 2014, Linaro Ltd.
+ *   Author: Hanjun Guo 
+ *   Author: Graeme Gregory 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _ASM_ACENV_H
+#define _ASM_ACENV_H
+
+#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported on ARM64")
+
+#endif /* _ASM_ACENV_H */
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
new file mode 100644
index 000..3ea6b84
--- /dev/null
+++ b/arch/arm64/include/asm/acpi.h
@@ -0,0 +1,49 @@
+/*
+ *  Copyright (C) 2013-2014, Linaro Ltd.
+ * Author: Al Stone 
+ * Author: Graeme Gregory 
+ * Author: Hanjun Guo 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ */
+
+#ifndef _ASM_ACPI_H
+#define _ASM_ACPI_H
+
+/* Basic configuration for ACPI */
+#ifdef CONFIG_ACPI
+extern int acpi_disabled;
+extern int acpi_noirq;
+extern int acpi_pci_disabled;
+extern int acpi_strict;
+
+static inline void disable_acpi(void)
+{
+   acpi_disabled = 1;
+   acpi_pci_disabled = 1;
+   acpi_noirq = 1;
+}
+
+/*
+ * The ACPI processor driver for ACPI core code needs this macro.
+ * Temporarily define it to -1 so that the ACPI core can compile,
+ * but update it when we get the hardware ID from the MADT table.
+ */
+#define cpu_physical_id(cpu) -1
+
+static inline bool acpi_arch_is_smp(void)
+{
+   return 1;
+}
+
+#endif /* CONFIG_ACPI */
+
+#endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 46d1125..9dedb0b 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -385,6 +386,9 @@ void __init setup_arch(char **cmdline_p)
efi_init();
arm64_memblock_init();
 
+   /* Parse the ACPI tables for possible boot-time configuration */
+   acpi_boot_table_init();
+
paging_init();
request_standard_resources();
 
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b638e95..c50ea88 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -86,3 +86,5 @@ obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
 obj-$(CONFIG_ACPI_APEI)+= apei/
 
 obj-$(CONFIG_ACPI_EXTLOG)  += acpi_extlog.o
+
+obj-y  += plat/
diff --git a/drivers/acpi/plat/Makefile b/drivers/acpi/plat/Makefile
new file mode 100644
index 000..46bc65e
--- /dev/null
+++ b/drivers/acpi/plat/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ARM64)+= arm-core.o
diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
new file mode 100644
index 000..c6c7e03
--- /dev/null
+++ b/drivers/acpi/plat/arm-core.c
@@ -0,0 +1,110 @@
+/*
+ *  ARM/ARM64 Specific Low-Level ACPI Boot Support
+ *
+ *  

[PATCH v4 07/13] ARM64 / ACPI: Introduce lowlevel suspend function

[Hanjun Guo]

From: Graeme Gregory 

acpi_wakeup_address is used on x86 as the address bios jumps into
when machine wakes up from suspend. As arm64 does not have such a
bios this mechanism will be provided by other means. But the define
is still required inside the acpi core.

Introduce a null stub for acpi_suspend_lowlevel as this is also
required by core. This will be filled in when standards are
defined for arm64 ACPI global power states.

Reviewed-by: Grant Likely 
Signed-off-by: Graeme Gregory 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/include/asm/acpi.h |   12 
 drivers/acpi/plat/arm-core.c  |7 +++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 3ea6b84..a93e8ae 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -39,6 +39,18 @@ static inline void disable_acpi(void)
  */
 #define cpu_physical_id(cpu) -1
 
+/*
+ * Low-level suspend routine.
+ *
+ * ACPI S-states for ARM64 have to be defined
+ * and approved before doing anything else, maybe
+ * we need update the ACPI spec, here just we
+ * just introduce function and macro needed by
+ * ACPI core, and revisit them when the spec is ready.
+ */
+extern int (*acpi_suspend_lowlevel)(void);
+#define acpi_wakeup_address (0)
+
 static inline bool acpi_arch_is_smp(void)
 {
return 1;
diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
index cf46c25..0155a98 100644
--- a/drivers/acpi/plat/arm-core.c
+++ b/drivers/acpi/plat/arm-core.c
@@ -129,3 +129,10 @@ static int __init parse_acpi(char *arg)
return 0;
 }
 early_param("acpi", parse_acpi);
+
+/*
+ * acpi_suspend_lowlevel() - save kernel state and suspend.
+ *
+ * TBD when ARM/ARM64 starts to support suspend...
+ */
+int (*acpi_suspend_lowlevel)(void);
-- 
1.7.9.5

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

[PATCH v4 01/13] acpi: arm64 does not have a BIOS add config for BIOS table scan.

[Hanjun Guo]

From: Graeme Gregory 

With the addition of ARM64 that does not have a traditional BIOS to
scan, add a config option which is selected on x86 and ia64 to do
the traditional BIOS scanning for tables.

Signed-off-by: Graeme Gregory 
---
 arch/ia64/Kconfig|1 +
 arch/x86/Kconfig |1 +
 drivers/acpi/Kconfig |3 +++
 drivers/acpi/osl.c   |4 +++-
 4 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 2f3abcf..f82b352 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -47,6 +47,7 @@ config IA64
select MODULES_USE_ELF_RELA
select ARCH_USE_CMPXCHG_LOCKREF
select HAVE_ARCH_AUDITSYSCALL
+   select ACPI_SCAN_BIOS_NOT_EFI
default y
help
  The Itanium Processor Family is Intel's 64-bit successor to
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a8f749e..4865d44 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -131,6 +131,7 @@ config X86
select HAVE_CC_STACKPROTECTOR
select GENERIC_CPU_AUTOPROBE
select HAVE_ARCH_AUDITSYSCALL
+   select ACPI_SCAN_BIOS_NOT_EFI
 
 config INSTRUCTION_DECODER
def_bool y
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index a34a228..70eaf7a 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -2,6 +2,9 @@
 # ACPI Configuration
 #
 
+config ACPI_SCAN_BIOS_NOT_EFI
+   bool
+
 menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
depends on !IA64_HP_SIM
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index bad25b0..5ba0b74 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -259,12 +259,14 @@ acpi_physical_address __init 
acpi_os_get_root_pointer(void)
   "System description tables not found\n");
return 0;
}
-   } else {
+   } else if (IS_ENABLED(CONFIG_ACPI_SCAN_BIOS_NOT_EFI)) {
acpi_physical_address pa = 0;
 
acpi_find_root_pointer();
return pa;
}
+
+   return 0;
 }
 
 /* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
-- 
1.7.9.5

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

[PATCH v4 02/13] ACPI: Don't use acpi_lapic in ACPI core code

[Hanjun Guo]

From: Graeme Gregory 

Now ARM64 support is being added to ACPI so architecture specific
values can not be used in core ACPI code.

Following on the patch "ACPI / processor: Check if LAPIC is present
during initialization" which uses acpi_lapic in acpi_processor.c,
on ARM64 platform, GIC is used instead of local APIC, so acpi_lapic
is not a suitable value for ARM64.

What is actually important at this point is the SMPness of the system,
so introduce acpi_arch_is_smp() to be arch specific and generic.

Signed-off-by: Graeme Gregory 
Signed-off-by: Hanjun Guo 
---
 arch/ia64/include/asm/acpi.h  |5 +
 arch/x86/include/asm/acpi.h   |5 +
 drivers/acpi/acpi_processor.c |2 +-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
index 75dc59a..2fc0757 100644
--- a/arch/ia64/include/asm/acpi.h
+++ b/arch/ia64/include/asm/acpi.h
@@ -40,6 +40,11 @@ extern int acpi_lapic;
 #define acpi_noirq 0   /* ACPI always enabled on IA64 */
 #define acpi_pci_disabled 0 /* ACPI PCI always enabled on IA64 */
 #define acpi_strict 1  /* no ACPI spec workarounds on IA64 */
+
+static inline bool acpi_arch_is_smp(void)
+{
+   return acpi_lapic;
+}
 #endif
 #define acpi_processor_cstate_check(x) (x) /* no idle limits on IA64 :) */
 static inline void disable_acpi(void) { }
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index e06225e..939d377 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -121,6 +121,11 @@ static inline void arch_acpi_set_pdc_bits(u32 *buf)
buf[2] &= ~(ACPI_PDC_C_C2C3_FFH);
 }
 
+static inline bool acpi_arch_is_smp(void)
+{
+   return acpi_lapic;
+}
+
 #else /* !CONFIG_ACPI */
 
 #define acpi_lapic 0
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 1c08574..8622a0e 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -268,7 +268,7 @@ static int acpi_processor_get_info(struct acpi_device 
*device)
pr->apic_id = apic_id;
 
cpu_index = acpi_map_cpuid(pr->apic_id, pr->acpi_id);
-   if (!cpu0_initialized && !acpi_lapic) {
+   if (!cpu0_initialized && !acpi_arch_is_smp()) {
cpu0_initialized = 1;
/* Handle UP system running SMP kernel, with no LAPIC in MADT */
if ((cpu_index == -1) && (num_online_cpus() == 1))
-- 
1.7.9.5

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

[PATCH v4 00/13] Enable ACPI on ARM64 in Kconfig

[Hanjun Guo]

This patch set is the first part of ARM64 ACPI core patches to
running ACPI on ARM64, it just handle some compile errors when
ACPI is introduced to ARM64 platform and enable ACPI on ARM64
in Kconfig.

Following core patch sets for ACPI based SMP/GIC/Arch Timer
initialization to enable ACPI on ARM64 are under interally
review and will send out when ACPI 5.1 is released.

patch 1~3 are cleanups for ACPI core;
patch 4~13 are arch dependent code for ARM64 ACPI;

This patch set is based on linux-next branch of Rafael's linux-pm
tree, and PCI patches for ARM64 from Liviu:
Support for creating generic host_bridge from device tree
https://lkml.org/lkml/2014/3/14/279

Add support for PCI in AArch64
http://comments.gmane.org/gmane.linux.ports.arm.kernel/309392

Changes since v3:
- Introduce three new patches
- acpi: arm64 does not have a BIOS add config for BIOS table scan
- ACPI: Don't use acpi_lapic in ACPI core code
- ARM64 / ACPI: if we chose to boot from acpi then disable FDT
- Rebase on the latest linux-next branch of Rafael's tree, and
  introduce asm/acenv.h for ARM64;
- Introduce ARCH_HAS_ACPI_PDC to move all the _PDC related code
  to a single place and make x86 and ia64 select ARCH_HAS_ACPI_PDC;
- Fix some checpatch warning;
- Fix broken Signed-off-by chain;
- Remove duplicate interface macros for ACPICA pointed out by Mark
  Rutland and Zheng Lv;
- Redefine ACPI_FLUSH_CPU_CACHE();
- Stub out some PCI functions suggested by Arnd and already merged into 3.16

Comments still need to be addressed:
- Empty PCI implementation in arch/arm64 which suggested by Arnd;
- suspend and sleep on ARM64 platform pointed out by Lorenzo;

Changes since v2:
- Make ACPI depend on PCI on ARM64
- rework all the patches and seperate some of the patches
  into fine-grained, and add some comments and changelog to
  make it easier for review.

Al Stone (3):
  ARM64 / ACPI: Introduce arm-core.c and its related head file
  ARM64 / ACPI: Introduce early_param for "acpi"
  ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on
ARM64

Graeme Gregory (6):
  acpi: arm64 does not have a BIOS add config for BIOS table scan.
  ACPI: Don't use acpi_lapic in ACPI core code
  ARM64 : Add dummy asm/cpu.h
  ARM64 / ACPI: Introduce lowlevel suspend function
  ARM64 / ACPI: if we chose to boot from acpi then disable FDT
  ARM64 / ACPI: Enable ARM64 in Kconfig

Hanjun Guo (4):
  ACPI / processor: Introduce ARCH_HAS_ACPI_PDC
  ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology
  ARM64 / ACPI: Introduce PCI functions for ACPI on ARM64
  ACPI: Make EC debugfs depend on X86 || IA64 in Kconfig

 Documentation/kernel-parameters.txt |3 +-
 arch/arm64/Kconfig  |3 +
 arch/arm64/include/asm/acenv.h  |   18 +++
 arch/arm64/include/asm/acpi.h   |   61 +++
 arch/arm64/include/asm/cpu.h|   11 ++
 arch/arm64/include/asm/pci.h|6 +
 arch/arm64/include/asm/topology.h   |2 +
 arch/arm64/kernel/pci.c |   28 +
 arch/arm64/kernel/setup.c   |7 +-
 arch/arm64/kernel/topology.c|   14 +++
 arch/ia64/Kconfig   |2 +
 arch/ia64/include/asm/acpi.h|5 +
 arch/x86/Kconfig|2 +
 arch/x86/include/asm/acpi.h |5 +
 drivers/acpi/Kconfig|   19 +++-
 drivers/acpi/Makefile   |3 +
 drivers/acpi/acpi_processor.c   |2 +-
 drivers/acpi/internal.h |5 +
 drivers/acpi/osl.c  |4 +-
 drivers/acpi/plat/Makefile  |1 +
 drivers/acpi/plat/arm-core.c|  138 +++
 drivers/acpi/processor_core.c   |  198 -
 drivers/acpi/processor_pdc.c|  206 +++
 23 files changed, 539 insertions(+), 204 deletions(-)
 create mode 100644 arch/arm64/include/asm/acenv.h
 create mode 100644 arch/arm64/include/asm/acpi.h
 create mode 100644 arch/arm64/include/asm/cpu.h
 create mode 100644 drivers/acpi/plat/Makefile
 create mode 100644 drivers/acpi/plat/arm-core.c
 create mode 100644 drivers/acpi/processor_pdc.c

-- 
1.7.9.5

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

[PATCH v4 03/13] ACPI / processor: Introduce ARCH_HAS_ACPI_PDC

[Hanjun Guo]

The use of _PDC is deprecated in ACPI 3.0 in favor of _OSC,
as ARM platform is supported only in ACPI 5.0 or higher version,
_PDC will not be used in ARM platform, so make Make _PDC only for
platforms with Intel CPUs.

Introduce ARCH_HAS_ACPI_PDC and move _PDC related code in ACPI
processor driver into a single file processor_pdc.c, make x86
and ia64 select ARCH_HAS_ACPI_PDC when ACPI is enabled.

This patch also use pr_* to replace printk to fix the checkpatch
warning and factor acpi_processor_alloc_pdc() a little bit to
avoid duplicate pr_err() code.

Suggested-by: Robert Richter 
Signed-off-by: Hanjun Guo 
---
 arch/ia64/Kconfig |1 +
 arch/x86/Kconfig  |1 +
 drivers/acpi/Kconfig  |   10 ++
 drivers/acpi/Makefile |1 +
 drivers/acpi/internal.h   |5 +
 drivers/acpi/processor_core.c |  198 ---
 drivers/acpi/processor_pdc.c  |  206 +
 7 files changed, 224 insertions(+), 198 deletions(-)
 create mode 100644 drivers/acpi/processor_pdc.c

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index f82b352..cde2626 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -10,6 +10,7 @@ config IA64
select ARCH_MIGHT_HAVE_PC_SERIO
select PCI if (!IA64_HP_SIM)
select ACPI if (!IA64_HP_SIM)
+   select ARCH_HAS_ACPI_PDC if ACPI
select PM if (!IA64_HP_SIM)
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_IDE
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4865d44..d60cec7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -21,6 +21,7 @@ config X86_64
 ### Arch settings
 config X86
def_bool y
+   select ARCH_HAS_ACPI_PDC if ACPI
select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 70eaf7a..0e6f72d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -367,6 +367,16 @@ config ACPI_REDUCED_HARDWARE_ONLY
 
If you are unsure what to do, do not enable this option.
 
+config ARCH_HAS_ACPI_PDC
+   bool
+   help
+ The _PDC object provides OSPM a mechanism to convey to the platform
+ the capabilities supported by OSPM for processor power management.
+ This allows the platform to modify the ACPI namespace objects 
returning
+ configuration information for processor power management based on the
+ level of support provided by OSPM.The use of _PDC is deprecated in
+ ACPI 3.0 in favor of _OSC.
+
 source "drivers/acpi/apei/Kconfig"
 
 config ACPI_EXTLOG
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index ea55e01..b638e95 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -36,6 +36,7 @@ acpi-y+= scan.o
 acpi-y += resource.o
 acpi-y += acpi_processor.o
 acpi-y += processor_core.o
+acpi-$(CONFIG_ARCH_HAS_ACPI_PDC) += processor_pdc.o
 acpi-y += ec.o
 acpi-$(CONFIG_ACPI_DOCK)   += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 7de5b60..d7376ee 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -108,7 +108,12 @@ int acpi_power_transition(struct acpi_device *device, int 
state);
 int acpi_device_update_power(struct acpi_device *device, int *state_p);
 
 int acpi_wakeup_device_init(void);
+
+#ifdef CONFIG_ARCH_HAS_ACPI_PDC
 void acpi_early_processor_set_pdc(void);
+#else
+static inline void acpi_early_processor_set_pdc(void) {}
+#endif
 
 /* --
   Embedded Controller
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 71e2065..00f48d1 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -4,17 +4,11 @@
  *
  * Alex Chiang 
  * - Unified x86/ia64 implementations
- * Venkatesh Pallipadi 
- * - Added _PDC for platforms with Intel CPUs
  */
 #include 
-#include 
-#include 
 #include 
 #include 
 
-#include "internal.h"
-
 #define _COMPONENT ACPI_PROCESSOR_COMPONENT
 ACPI_MODULE_NAME("processor_core");
 
@@ -208,195 +202,3 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32 
acpi_id)
return acpi_map_cpuid(apic_id, acpi_id);
 }
 EXPORT_SYMBOL_GPL(acpi_get_cpuid);
-
-static bool __init processor_physically_present(acpi_handle handle)
-{
-   int cpuid, type;
-   u32 acpi_id;
-   acpi_status status;
-   acpi_object_type acpi_type;
-   unsigned long long tmp;
-   union acpi_object object = { 0 };
-   struct acpi_buffer buffer = { sizeof(union acpi_object),  };
-
-   status = acpi_get_type(handle, _type);
-   if 

Re: [PATCH v3] arch/score/include/uapi/asm/ptrace.h: Remove the macros which not be used currently

[Chen Gang]

On 06/27/2014 11:25 AM, Guenter Roeck wrote:
> On 06/26/2014 07:47 PM, Chen Gang wrote:
>> On 06/27/2014 10:11 AM, Lennox Wu wrote:
>>> Acked-by: Lennox Wu 
>>>
>>
>> OK, thank, and excuse me, I am not quite familiar with the version
>> merging of upstream kernel: "who will apply it, next, if it is past all
>> reviewers' checking".
>>
> 
> Normal procedure would be for Lennox (as maintainer) to send a pull
> request to Linus.
> 

OK, thank you for your information.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/26/2014 09:38 PM, Kevin Hilman wrote:
> Tushar Behera  writes:
> 
>> On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman  wrote:
>>> Doug Anderson  writes:
>>>
 Tushar,

 On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera  
 wrote:
> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
> As per the user manual, it should be CLK_MAU_EPLL.
>
> The problem surfaced when the bootloader in Peach-pit board set
> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
> we used to get a system hang during late boot if CLK_MAU_EPLL was
> disabled.
>
> Signed-off-by: Tushar Behera 
> Signed-off-by: Shaik Ameer Basha 
> Reported-by: Kevin Hilman 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

 I've tested this myself now as well.

 Tested-by: Doug Anderson 
>>>
>>> For me, this patch alone (on top of -next) doesn't solve the boot hang.
>>> I still need clk_ignore_unused for a successful boot.
>>>
>>> So, this patch might be correct, but it doesn't prevent a boot hang
>>> using a chain-loaded nv_uboot on peach-pi.  There's still another clock
>>> being disabled that causes a hang.
>>>
>>> Kevin
>>
>> Kevin,
>>
>> Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the
>> issue for you?
> 
> Yes, using patch 1/3 along with 2/3 fixes the issue.
> 

Okay, that adds some more reason to re-investigate patch 1/3.

Kevin,

Would you please provide me the environment setting of your u-boot?
U-boot environment on my board has been over-written, I would like to
set it same as yours and try to reproduce the issue at my end. With only
'sound init', I don't seem to hit this issue anymore.

>> Also can you please confirm that setting CLK_IGNORE_UNUSED flag
>> CLK_MAU_EPLL alone fixes the issue, without any need for
>> clk_ignore_unused in u-boot bootargs?
> 
> Yes, I have this patch[1] in my local branch which fixes the issue
> alone, without clk_ignore_unused on the command line.
> 
> Kevin
> 
> 
> [1]
> From ab1627127730ef4507ce96cbf95047d626bbb53f Mon Sep 17 00:00:00 2001
> From: Kevin Hilman 
> Date: Thu, 5 Jun 2014 17:12:28 -0700
> Subject: [PATCH] KJH: leave mau_epll enabled
> 
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index 61eccf0dd72f..ed175088ee7e 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -911,7 +911,7 @@ static struct samsung_gate_clock exynos5x_gate_clks[] 
> __initdata = {
>   SRC_MASK_TOP2, 24, 0, 0),
>  
>   GATE(CLK_MAU_EPLL, "mau_epll", "mout_mau_epll_clk",
> - SRC_MASK_TOP7, 20, 0, 0),
> + SRC_MASK_TOP7, 20, CLK_IGNORE_UNUSED, 0),
>  
>   /* sclk */
>   GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",
> 


-- 
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: Document Hisilicon hix5hd2 sata PHY

[zhangfei]

On 06/27/2014 04:53 AM, Arnd Bergmann wrote:

On Thursday 26 June 2014 21:48:54 zhangfei wrote:



Since you mention that this is a synopsys part, it may however be
good to also define a compatible string for the generic device,
to allow other SoCs to share this driver, and to make it easier
for people to find out that we already have one so they don't have
to write another driver for the same hardware.


http://www.synopsys.com/dw/ipdir.php?ds=dwc_sata_phy
name can be: dwc_sata_phy
However, not find register from the website, not sure whether the
register are totally same, or there is some change.
Other soc from hisilicon using the same ip can share this driver.


I found a list of versions under "Downloads and Documentation", but
unfortunately the actual downloads are not accessible without a
customer account.


Can you find out what the Synopsys/Designware product designation for
this PHY is? It would be good to rename the driver and binding
if possible. I would still recommend leaving the
"hisilicon,hix5hd2-sata-phy" string and the "hisilicon,peripheral-syscon"
property in place, since that indicates a minor variation of the
generic part.


"hisilicon,peripheral-syscon" is privide power supply, etc.

Do you mean change the compatible to "hisilicon,dwc-sata-phy" or
multiple compatible?


Multiple compatible strings.

"hisilicon,dwc-sata-phy" would be too generic anyway, it should include the
name of the chip that first implements this, or the exact version of the
IP block, preferably both.

Ideally if you can find out the version that hisilicon uses, it could
look something like

compatible = "hisilicon,hi15hd2-sata-phy", "snps,dwc-sata-phy-2.3a", 
""snps,dwc-sata-phy";

Note also the specific version of the hisilicon chip: you must not use
wildcards in compatible strings but should always use a real product number.
("1" instead of "x"). If multiple chips are mutually compatible, they
can all use the number of the first one here.



Sorry for the confusion.

The phy is rather an analog controller, without standard register.
Instead, the phy interface is just some pin / analog interface.
The register is in fact hix5hd2 register, controls all the analog 
output, including reset, power, speed, para tunning.


Even the same phy is used in other soc, they can not share this driver, 
since the connection must be different, as well as internal soc register 
layout.
Only if the same controller & phy are reused in other hisilicon soc, 
this driver can be shared.


Since what we control is hix5hd2 controller itself, so it may not 
suitable to put snps here.



And about hix5hd2 name: x is not wildcard.

Currently hix5hd2 is series of hi3716c v200, hi3719c v100, hi3718c v100.
They are same soc, except minus pin assembles different.

However, not all hi37x is in this series, for example hi3716c v100 is a 
different soc.


In the future hi3719m, hi3718m may also plan to add to hix5hd2 series.
The difference will be different cpu core number, different gpu core 
number. Also use different ethernet controller.



So we may still keep "hisilicon,hix5hd2-sata-phy" unchanged.
What do you think?

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 V4 00/42] use irqdomain to dynamically allocate IRQ for IOAPIC

[Yinghai Lu]

On Sat, Jun 21, 2014 at 2:08 PM, Thomas Gleixner  wrote:
> Jiang,
>
> On Mon, 9 Jun 2014, Jiang Liu wrote:
>
>> On x86 platforms, IRQ number are statically allocated to IOAPIC pins at boot.
>> There are two issues with this design. First it causes trouble to IOAPIC
>> hotplug because we need to allocate a block of IRQ numbers for each IOAPIC.
>> Second it may waste IRQ nubmers even if some IOAPIC pins are not used because
>> IRQ numbers are statically assigned.
>>
>> This patchset tries to enable dynamic IRQ number allocation for IOAPIC
>> by adopting the irqdomain framework, it solves the two issues mentioned
>> above. It also simplifies the IOAPIC driver by consolidating ways to
>> program IOAPIC pins with the irqdomain map interface.
>>
>> We will enhance the IOAPIC driver core to support ACPI based IOAPIC hotplug
>> once the IOAPIC driver has been converted to irqdomain.
>
> I merged the whole lot. Thanks for doing this and reacting on all the
> review comments. Very nice cleanup work!
>

I got following warning on RHEL 7.0 shutdown path.

[58018.128900] [ cut here ]
[58018.134081] WARNING: CPU: 21 PID: 1 at fs/proc/generic.c:521
remove_proc_entry+0x150/0x1a0()
[58018.143596] remove_proc_entry: removing non-empty directory
'irq/23', leaking at least 'ehci_hcd:usb2'
[58018.154001] Modules linked in:
[58018.157435] CPU: 21 PID: 1 Comm: systemd-shutdow Tainted: G
W 3.16.0-rc2-yh-00420-g6d62036-dirty #36
[58018.168716] Hardware name: Oracle Corporation ORACLE SERVER
[58018.179703]  0009 885e759bfb60 81f76520
885e759bfba8
[58018.188033]  885e759bfb98 8109d03d 88edf9fb9f00
0002
[58018.196358]  885e759bfc6e 88f07b3f4330 88edf9fb9fb9
885e759bfbf8
[58018.204682] Call Trace:
[58018.207432]  [] dump_stack+0x45/0x56
[58018.213186]  [] warn_slowpath_common+0x7d/0xa0
[58018.219903]  [] warn_slowpath_fmt+0x4c/0x50
[58018.226336]  [] remove_proc_entry+0x150/0x1a0
[58018.232963]  [] unregister_irq_proc+0xbf/0xd0
[58018.239589]  [] free_desc+0x31/0xa0
[58018.245240]  [] irq_free_descs+0x6c/0x80
[58018.251375]  [] irq_dispose_mapping+0x53/0x60
[58018.258011]  [] mp_unmap_irq+0xa0/0xc0
[58018.263960]  [] acpi_unregister_gsi_ioapic+0x2f/0x40
[58018.271263]  [] acpi_unregister_gsi+0x17/0x20
[58018.277896]  [] acpi_pci_irq_disable+0x5e/0x68
[58018.284619]  [] pcibios_disable_device+0x20/0x30
[58018.291536]  [] do_pci_disable_device+0x52/0x60
[58018.298350]  [] pci_disable_device+0x92/0xb0
[58018.304876]  [] usb_hcd_pci_shutdown+0x3f/0x50
[58018.311593]  [] pci_device_shutdown+0x36/0x70
[58018.318220]  [] device_shutdown+0x135/0x190
[58018.324651]  [] kernel_power_off+0x35/0x80
[58018.330980]  [] SyS_reboot+0x233/0x260
[58018.336919]  [] ? cpuacct_account_field+0x99/0xb0
[58018.343929]  [] ? cpuacct_account_field+0x5/0xb0
[58018.350843]  [] ? _raw_spin_unlock+0x27/0x30
[58018.357378]  [] ? trace_hardirqs_on_caller+0x16/0x260
[58018.364774]  [] ? trace_hardirqs_on+0xd/0x10
[58018.371302]  [] ? syscall_trace_enter+0x17c/0x1c0
[58018.378312]  [] tracesys+0xd4/0xd9
[58018.383867] ---[ end trace fade991312a6a2d9 ]---
[58018.389026]   free irq_desc for 23

Like to suggest attached patch that skip mp_unregister_gsi on shutdown path.

Thanks

Yinghai
---
 arch/x86/kernel/acpi/boot.c |6 ++
 1 file changed, 6 insertions(+)

Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===
--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
+++ linux-2.6/arch/x86/kernel/acpi/boot.c
@@ -659,6 +659,12 @@ static int acpi_register_gsi_ioapic(stru
 static void acpi_unregister_gsi_ioapic(u32 gsi)
 {
 #ifdef CONFIG_X86_IO_APIC
+	/* should not worry about shutdown path */
+	if (system_state == SYSTEM_HALT ||
+	system_state == SYSTEM_POWER_OFF ||
+	system_state == SYSTEM_RESTART)
+		return;
+
 	mp_unregister_gsi(gsi);
 #endif
 }

Re: [RFC PATCH] phy: micrel: make phy_has_fixups attribute read correctly

[Bo Shen]

Hi Florian,

On 06/27/2014 02:00 AM, Florian Fainelli wrote:

Hello,

2014-06-25 0:24 GMT-07:00 Bo Shen :

If the fixups parameters get from dtb, it won't set has_fixups
parameters, so when read phy_has_fixups attribute, it always
present as 0.
Add this patch to make phy_has_fixups attribute read correctly.


I am not entirely sure whether loading values from Device Tree should
be considered a PHY fixup per-se. They do override the hardware reset
default values, but I am not sure if we should consider that as a
fixup.


In old method, we will call phy_register_fixup_for_uid to update this 
configuration, which will set the phy_has_fixups as true, then it 
regards as fix up. So, can we also consider loading values from DTS also 
as fix up?



Assuming that you need to troubleshoot a given system, one of the
first things you will surely ask for is the DTS used by that platform,
and in that case you can quickly check whether the PHY default
settings are changed, right?


I am not sure I am fully understand here.

The value retrieve from DTS is used to overwrite the default value, so I 
think it is no need to check.




Signed-off-by: Bo Shen 
---
  drivers/net/phy/micrel.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index bc7c7d2..c384922 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -237,6 +237,8 @@ static int ksz9021_load_values_from_of(struct phy_device 
*phydev,

 if (!matches)
 return 0;
+   else
+   phydev->has_fixups = true;


There is no need for the else here



 if (matches < 4)
 newval = kszphy_extended_read(phydev, reg);
@@ -330,6 +332,8 @@ static int ksz9031_of_load_skew_values(struct phy_device 
*phydev,

 if (!matches)
 return 0;
+   else
+   phydev->has_fixups = true;


Same here



 if (matches < numfields)
 newval = ksz9031_extended_read(phydev, OP_DATA, 2, reg);
--
1.8.5.2


Best Regards,
Bo Shen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] USB: ehci-pci: Add support for Intel Quark X1000 USB host controller

[Chen, Alvin]

From: "Alvin (Weike) Chen" 

Hi,
Intel Quark X1000 consists of one USB host controller which can be PCI 
enumerated.
And the exsiting EHCI-PCI framework supports it with the default packet buffer 
in/out
threshold. We reconfigure the in/out threshold as maximal as possible.

Bryan O'Donoghue (1):
  USB: ehci-pci: USB host controller support for Intel Quark X1000

 drivers/usb/host/ehci-pci.c |   43 +++
 1 file changed, 43 insertions(+)

-- 
1.7.9.5

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

[PATCH v2] USB: ehci-pci: USB host controller support for Intel Quark X1000

[Chen, Alvin]

From: Bryan O'Donoghue 

The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000 
USB host
controller, and the default value is 0x20 dwords. The in/out threshold can be 
programmed
to 0x80 dwords, but only when isochronous/interrupt transactions are not 
initiated by
the USB host controller. This patch is to reconfigure the packet buffer in/out 
threshold
as maximal as possible, and it is 0x7F dwords since the USB host controller 
initiates
isochronous/interrupt transactions.

Signed-off-by: Bryan O'Donoghue 
Signed-off-by: Alvin (Weike) Chen 
---
changelog v2:
*Change the function name from 'usb_is_intel_qrk' to 'usb_is_intel_quark_x1000'.
*Move the functions 'usb_is_intel_quark_x1000' and 'usb_set_qrk_bulk_thresh'
 from 'pci-quirks.c' to 'ehci-pci.c'.
*Remove unnecessary kernel message in the function of 'usb_set_qrk_bulk_thresh'.
*Remove 'unlikely' in the functions of 'ehci_pci_reinit'.
*Add white space after 'if'.
*Update the descriptions to make it more clearly.
*Add Micros to avoid magic number.

 drivers/usb/host/ehci-pci.c |   45 +++
 1 file changed, 45 insertions(+)

diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 3e86bf4..ca29f34 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -35,6 +35,47 @@ static const char hcd_name[] = "ehci-pci";
 #define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70
 
 /*-*/
+#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
+static inline bool usb_is_intel_quark_x1000(struct pci_dev *pdev)
+{
+   return pdev->vendor == PCI_VENDOR_ID_INTEL &&
+   pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
+
+}
+
+/* Register offset of in/out threshold */
+#define EHCI_INSNREG01 0x84
+/* The maximal threshold is 0x80 Dword */
+#define EHCI_MAX_THRESHOLD  0X80
+/* Lower word is 'in' threshold, and higher word is 'out' threshold*/
+#define EHCI_INSNREG01_THRESH \
+   ((EHCI_MAX_THRESHOLD - 1)<<16 | (EHCI_MAX_THRESHOLD - 1))
+static void usb_set_qrk_bulk_thresh(struct pci_dev *pdev)
+{
+   void __iomem *base, *op_reg_base;
+   u8 cap_length;
+   u32 val;
+   u16 cmd;
+
+   if (!pci_resource_start(pdev, 0))
+   return;
+
+   if (pci_read_config_word(pdev, PCI_COMMAND, )
+   || !(cmd & PCI_COMMAND_MEMORY))
+   return;
+
+   base = pci_ioremap_bar(pdev, 0);
+   if (base == NULL)
+   return;
+
+   cap_length = readb(base);
+   op_reg_base = base + cap_length;
+
+   val = EHCI_INSNREG01_THRESH;
+   writel(val, op_reg_base + EHCI_INSNREG01);
+
+   iounmap(base);
+}
 
 /* called after powerup, by probe or system-pm "wakeup" */
 static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
@@ -50,6 +91,10 @@ static int ehci_pci_reinit(struct ehci_hcd *ehci, struct 
pci_dev *pdev)
if (!retval)
ehci_dbg(ehci, "MWI active\n");
 
+   /* Reset the threshold limit */
+   if (usb_is_intel_quark_x1000(pdev))
+   usb_set_qrk_bulk_thresh(pdev);
+
return 0;
 }
 
-- 
1.7.9.5

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

Re: [PATCH v3] arch/score/include/uapi/asm/ptrace.h: Remove the macros which not be used currently

[Guenter Roeck]

On 06/26/2014 07:47 PM, Chen Gang wrote:

On 06/27/2014 10:11 AM, Lennox Wu wrote:

Acked-by: Lennox Wu 



OK, thank, and excuse me, I am not quite familiar with the version
merging of upstream kernel: "who will apply it, next, if it is past all
reviewers' checking".



Normal procedure would be for Lennox (as maintainer) to send a pull request to 
Linus.

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/

Re: [PATCH v2 0/2] block,scsi: fixup blk_get_request dead queue scenarios

[Joe Lawrence]

On Thu, 26 Jun 2014, Jeff Moyer wrote:

> Jens Axboe  writes:
> 
> > On 2014-06-26 10:08, Jeff Moyer wrote:
> >> Joe Lawrence  writes:
> >>
> >>> v1->v2: incorporate Jeff's feedback in bsg_map_hdr() and Reviewed-by
> >>>  tags.
> >>>
> >>> Joe Lawrence (2):
> >>>block,scsi: verify return pointer from blk_get_request
> >>>block,scsi: convert and handle ERR_PTR from blk_get_request
> >>
> >> Jens,
> >>
> >> Can you pick this series up?  It actually fixes a NULL pointer
> >> dereference that can happen if (for example) a usb optical drive is
> >> removed while an application is using it.
> >
> > Yeah I'll pick it up, opening up the 3.17 branches soon.
> 
> Thanks, Jens.  Joe, the patches don't apply anymore... would you mind
> sending an updated set so Jens doesn't have to do the fixups?  I think
> you also need to convert blk_mq_alloc_request, I didn't see that in your
> patch.

Hi Jeff,

I have a new set that applies on top of 3.16-rc2... but before posting, I 
wasn't sure what needs to be converted w/regard to blk_mq_alloc_request.  
As far as I can tell, the new multi-queue block IO queueing implementation 
via blk_mq_alloc_request should be safe from this bug as it doesn't 
include any dead queue checks that introduce early exits.

Regards,

-- Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Filesystem lockup with CONFIG_PREEMPT_RT

[Mike Galbraith]

On Thu, 2014-06-26 at 17:07 -0700, Austin Schuh wrote:

> If I'm reading the rt patch correctly, wq_worker_sleeping was moved
> out of __schedule to sched_submit_work.  It looks like that changes
> the conditions under which wq_worker_sleeping is called.  It used to
> be called whenever a task was going to sleep (I think).  It looks like
> it is called now if the task is going to sleep, and if the task isn't
> blocked on a PI mutex (I think).

Re-entanglement does turn your killer into a happy camper, but that
patch is too lovely to just surrender without a squabble.

-Mike

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

LOAN OFFER

[Peter Tracey]

I am Peter Tracey a private lender located in USA.I can help you with a loan 
you are looking for @ 2% interest rate,For Urgent Response Email: 
peterstraceyloan...@gmail.com

Peter Tracey
Email: peterstraceyloan...@gmail.com
Telephone:408 713 0573
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 1/5 v2] tracing: Add trace_seq_buffer_ptr() helper function

[James Bottomley]

On Thu, 2014-06-26 at 21:06 -0400, Steven Rostedt wrote:
> As this patch is in my 3.17 queue and it touches the kvm and scsi
> tracepoint code, I figured I should at least do the courtesy of
> notifying the maintainers of those subsystems.
> 
> Do you have any issues with this going through my tree? If not, please
> give me an Acked-by.

Missing cc to linux-scsi added.

Hannes has a set of patches to move logging to trace points.  I don't
think there's a clash but I'd like him to comment before you do this.

James


> Thanks!
> 
> -- Steve
> 
> On Thu, 26 Jun 2014 17:49:02 -0400
> Steven Rostedt  wrote:
> 
> > From: "Steven Rostedt (Red Hat)" 
> > 
> > There's several locations in the kernel that open code the calculation
> > of the next location in the trace_seq buffer. This is usually done with
> > 
> >   p->buffer + p->len
> > 
> > Instead of having this open coded, supply a helper function in the
> > header to do it for them. This function is called trace_seq_buffer_ptr().
> > 
> > Signed-off-by: Steven Rostedt 
> > ---
> >  arch/x86/kvm/mmutrace.h |  2 +-
> >  drivers/scsi/scsi_trace.c   | 16 
> >  include/linux/trace_seq.h   | 15 +++
> >  kernel/trace/trace_output.c | 14 +++---
> >  4 files changed, 31 insertions(+), 16 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/mmutrace.h b/arch/x86/kvm/mmutrace.h
> > index 9d2e0ffcb190..2e5652b62fd6 100644
> > --- a/arch/x86/kvm/mmutrace.h
> > +++ b/arch/x86/kvm/mmutrace.h
> > @@ -22,7 +22,7 @@
> > __entry->unsync = sp->unsync;
> >  
> >  #define KVM_MMU_PAGE_PRINTK() ({   \
> > -   const char *ret = p->buffer + p->len;   \
> > +   const char *ret = trace_seq_buffer_ptr(p);  \
> > static const char *access_str[] = { \
> > "---", "--x", "w--", "w-x", "-u-", "-ux", "wu-", "wux"  \
> > };  \
> > diff --git a/drivers/scsi/scsi_trace.c b/drivers/scsi/scsi_trace.c
> > index 2bea4f0b684a..503594e5f76d 100644
> > --- a/drivers/scsi/scsi_trace.c
> > +++ b/drivers/scsi/scsi_trace.c
> > @@ -28,7 +28,7 @@ scsi_trace_misc(struct trace_seq *, unsigned char *, int);
> >  static const char *
> >  scsi_trace_rw6(struct trace_seq *p, unsigned char *cdb, int len)
> >  {
> > -   const char *ret = p->buffer + p->len;
> > +   const char *ret = trace_seq_buffer_ptr(p);
> > sector_t lba = 0, txlen = 0;
> >  
> > lba |= ((cdb[1] & 0x1F) << 16);
> > @@ -46,7 +46,7 @@ scsi_trace_rw6(struct trace_seq *p, unsigned char *cdb, 
> > int len)
> >  static const char *
> >  scsi_trace_rw10(struct trace_seq *p, unsigned char *cdb, int len)
> >  {
> > -   const char *ret = p->buffer + p->len;
> > +   const char *ret = trace_seq_buffer_ptr(p);
> > sector_t lba = 0, txlen = 0;
> >  
> > lba |= (cdb[2] << 24);
> > @@ -71,7 +71,7 @@ scsi_trace_rw10(struct trace_seq *p, unsigned char *cdb, 
> > int len)
> >  static const char *
> >  scsi_trace_rw12(struct trace_seq *p, unsigned char *cdb, int len)
> >  {
> > -   const char *ret = p->buffer + p->len;
> > +   const char *ret = trace_seq_buffer_ptr(p);
> > sector_t lba = 0, txlen = 0;
> >  
> > lba |= (cdb[2] << 24);
> > @@ -94,7 +94,7 @@ scsi_trace_rw12(struct trace_seq *p, unsigned char *cdb, 
> > int len)
> >  static const char *
> >  scsi_trace_rw16(struct trace_seq *p, unsigned char *cdb, int len)
> >  {
> > -   const char *ret = p->buffer + p->len;
> > +   const char *ret = trace_seq_buffer_ptr(p);
> > sector_t lba = 0, txlen = 0;
> >  
> > lba |= ((u64)cdb[2] << 56);
> > @@ -125,7 +125,7 @@ scsi_trace_rw16(struct trace_seq *p, unsigned char 
> > *cdb, int len)
> >  static const char *
> >  scsi_trace_rw32(struct trace_seq *p, unsigned char *cdb, int len)
> >  {
> > -   const char *ret = p->buffer + p->len, *cmd;
> > +   const char *ret = trace_seq_buffer_ptr(p), *cmd;
> > sector_t lba = 0, txlen = 0;
> > u32 ei_lbrt = 0;
> >  
> > @@ -180,7 +180,7 @@ out:
> >  static const char *
> >  scsi_trace_unmap(struct trace_seq *p, unsigned char *cdb, int len)
> >  {
> > -   const char *ret = p->buffer + p->len;
> > +   const char *ret = trace_seq_buffer_ptr(p);
> > unsigned int regions = cdb[7] << 8 | cdb[8];
> >  
> > trace_seq_printf(p, "regions=%u", (regions - 8) / 16);
> > @@ -192,7 +192,7 @@ scsi_trace_unmap(struct trace_seq *p, unsigned char 
> > *cdb, int len)
> >  static const char *
> >  scsi_trace_service_action_in(struct trace_seq *p, unsigned char *cdb, int 
> > len)
> >  {
> > -   const char *ret = p->buffer + p->len, *cmd;
> > +   const char *ret = trace_seq_buffer_ptr(p), *cmd;
> > sector_t lba = 0;
> > u32 alloc_len = 0;
> >  
> > @@ -247,7 +247,7 @@ scsi_trace_varlen(struct trace_seq *p, unsigned char 
> > *cdb, int len)
> >  static const char *
> >  scsi_trace_misc(struct trace_seq *p, unsigned char *cdb, int len)
> >  {
> > -   const char *ret = p->buffer + 

[PATCH RFC v3 1/4] nand: pl353: Add basic driver for arm pl353 smc nand interface

[Punnaiah Choudary Kalluri]

Add driver for arm pl353 static memory controller nand interface with
HW ECC support. This controller is used in xilinx zynq soc for interfacing
the nand flash memory.

Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v3:
 - implemented the proper error codes
 - further breakdown this patch to multiple sets
 - added the controller and driver details to Documentation section
 - updated the licenece to GPLv2
 - reorganized the pl353_nand_ecc_init function
Changes in v2:
 - use "depends on" rather than "select" option in kconfig
 - remove unused variable parts
 - remove dummy helper and use writel_relaxed directly
---
 drivers/mtd/nand/Kconfig  |7 +
 drivers/mtd/nand/Makefile |1 +
 drivers/mtd/nand/pl353_nand.c |  855 +
 3 files changed, 863 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/nand/pl353_nand.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index f1cf503..a3462e6 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -492,6 +492,13 @@ config MTD_NAND_NUC900
  This enables the driver for the NAND Flash on evaluation board based
  on w90p910 / NUC9xx.
 
+config MTD_NAND_PL353
+   tristate "ARM Pl353 NAND flash driver"
+   depends on MTD_NAND && ARM
+   depends on PL353_SMC
+   help
+ This enables access to the NAND flash device on PL353 SMC controller.
+
 config MTD_NAND_JZ4740
tristate "Support for JZ4740 SoC NAND controller"
depends on MACH_JZ4740
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 542b568..a4c2679 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -49,5 +49,6 @@ obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
 obj-$(CONFIG_MTD_NAND_XWAY)+= xway_nand.o
 obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)   += bcm47xxnflash/
+obj-$(CONFIG_MTD_NAND_PL353)   += pl353_nand.o
 
 nand-objs := nand_base.o nand_bbt.o
diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c
new file mode 100644
index 000..0be8ca2
--- /dev/null
+++ b/drivers/mtd/nand/pl353_nand.c
@@ -0,0 +1,855 @@
+/*
+ * ARM PL353 NAND Flash Controller Driver
+ *
+ * Copyright (C) 2009 - 2014 Xilinx, Inc.
+ *
+ * This driver is based on plat_nand.c and mxc_nand.c drivers
+ *
+ * This program is free software; you can redistribute it and/or modify it 
under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PL353_NAND_DRIVER_NAME "pl353-nand"
+
+/* NAND flash driver defines */
+#define PL353_NAND_CMD_PHASE   1   /* End command valid in command phase */
+#define PL353_NAND_DATA_PHASE  2   /* End command valid in data phase */
+#define PL353_NAND_ECC_SIZE512 /* Size of data for ECC operation */
+
+/* Flash memory controller operating parameters */
+
+#define PL353_NAND_ECC_CONFIG  (BIT(4)  |  /* ECC read at end of page */ \
+(0 << 5))  /* No Jumping */
+
+/* AXI Address definitions */
+#define START_CMD_SHIFT3
+#define END_CMD_SHIFT  11
+#define END_CMD_VALID_SHIFT20
+#define ADDR_CYCLES_SHIFT  21
+#define CLEAR_CS_SHIFT 21
+#define ECC_LAST_SHIFT 10
+#define COMMAND_PHASE  (0 << 19)
+#define DATA_PHASE BIT(19)
+
+#define PL353_NAND_ECC_LASTBIT(ECC_LAST_SHIFT) /* Set ECC_Last */
+#define PL353_NAND_CLEAR_CSBIT(CLEAR_CS_SHIFT) /* Clear chip select */
+
+#define ONDIE_ECC_FEATURE_ADDR 0x90
+#define PL353_NAND_ECC_BUSY_TIMEOUT(1 * HZ)
+#define PL353_NAND_DEV_BUSY_TIMEOUT(1 * HZ)
+#define PL353_NAND_LAST_TRANSFER_LENGTH4
+
+/**
+ * struct pl353_nand_command_format - Defines NAND flash command format
+ * @start_cmd: First cycle command (Start command)
+ * @end_cmd:   Second cycle command (Last command)
+ * @addr_cycles:   Number of address cycles required to send the address
+ * @end_cmd_valid: The second cycle command is valid for cmd or data phase
+ */
+struct pl353_nand_command_format {
+   int start_cmd;
+   int end_cmd;
+   u8 addr_cycles;
+   u8 end_cmd_valid;
+};
+
+/**
+ * struct pl353_nand_info - Defines the NAND flash driver instance
+ * @chip:  NAND chip information structure
+ * @mtd:   MTD information structure
+ * @nand_base: Virtual address of the NAND flash device
+ * @end_cmd_pending:   End command is pending
+ * @end_cmd:   End command
+ * @ecc_mode:  ECC mode
+ */
+struct pl353_nand_info {
+   struct nand_chip chip;
+  

[PATCH RFC v3 3/4] nand: pl353: Add ONDIE ECC support

[Punnaiah Choudary Kalluri]

Added ONDIE ECC support. Currently this ecc mode is supported for
specific micron parts with oob size 64 bytes.

Signed-off-by: Punnaiah Choudary Kalluri 
---
 drivers/mtd/nand/pl353_nand.c |  131 +++-
 1 files changed, 127 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c
index eca205f..4f56c7f 100644
--- a/drivers/mtd/nand/pl353_nand.c
+++ b/drivers/mtd/nand/pl353_nand.c
@@ -140,6 +140,48 @@ static struct nand_ecclayout nand_oob_64 = {
 .length = 50} }
 };
 
+static struct nand_ecclayout ondie_nand_oob_64 = {
+   .eccbytes = 32,
+
+   .eccpos = {
+   8, 9, 10, 11, 12, 13, 14, 15,
+   24, 25, 26, 27, 28, 29, 30, 31,
+   40, 41, 42, 43, 44, 45, 46, 47,
+   56, 57, 58, 59, 60, 61, 62, 63
+   },
+
+   .oobfree = {
+   { .offset = 4, .length = 4 },
+   { .offset = 20, .length = 4 },
+   { .offset = 36, .length = 4 },
+   { .offset = 52, .length = 4 }
+   }
+};
+
+/* Generic flash bbt decriptors */
+static uint8_t bbt_pattern[] = { 'B', 'b', 't', '0' };
+static uint8_t mirror_pattern[] = { '1', 't', 'b', 'B' };
+
+static struct nand_bbt_descr bbt_main_descr = {
+   .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
+   | NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+   .offs = 4,
+   .len = 4,
+   .veroffs = 20,
+   .maxblocks = 4,
+   .pattern = bbt_pattern
+};
+
+static struct nand_bbt_descr bbt_mirror_descr = {
+   .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
+   | NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+   .offs = 4,
+   .len = 4,
+   .veroffs = 20,
+   .maxblocks = 4,
+   .pattern = mirror_pattern
+};
+
 /**
  * pl353_nand_calculate_hwecc - Calculate Hardware ECC
  * @mtd:   Pointer to the mtd_info structure
@@ -816,15 +858,74 @@ static int pl353_nand_device_ready(struct mtd_info *mtd)
 }
 
 /**
+ * pl353_nand_detect_ondie_ecc - Get the flash ondie ecc state
+ * @mtd:   Pointer to the mtd_info structure
+ *
+ * This function enables the ondie ecc for the Micron ondie ecc capable devices
+ *
+ * Return: 1 on detect, 0 if fail to detect
+ */
+static int pl353_nand_detect_ondie_ecc(struct mtd_info *mtd)
+{
+   struct nand_chip *nand_chip = mtd->priv;
+   u8 maf_id, dev_id, i, get_feature;
+   u8 set_feature[4] = { 0x08, 0x00, 0x00, 0x00 };
+
+   /* Check if On-Die ECC flash */
+   nand_chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+   nand_chip->cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);
+
+   /* Read manufacturer and device IDs */
+   maf_id = readb(nand_chip->IO_ADDR_R);
+   dev_id = readb(nand_chip->IO_ADDR_R);
+
+   if ((maf_id == NAND_MFR_MICRON) &&
+   ((dev_id == 0xf1) || (dev_id == 0xa1) ||
+(dev_id == 0xb1) || (dev_id == 0xaa) ||
+(dev_id == 0xba) || (dev_id == 0xda) ||
+(dev_id == 0xca) || (dev_id == 0xac) ||
+(dev_id == 0xbc) || (dev_id == 0xdc) ||
+(dev_id == 0xcc) || (dev_id == 0xa3) ||
+(dev_id == 0xb3) ||
+(dev_id == 0xd3) || (dev_id == 0xc3))) {
+
+   nand_chip->cmdfunc(mtd, NAND_CMD_GET_FEATURES,
+  ONDIE_ECC_FEATURE_ADDR, -1);
+   get_feature = readb(nand_chip->IO_ADDR_R);
+
+   if (get_feature & 0x08) {
+   return 1;
+   } else {
+   nand_chip->cmdfunc(mtd, NAND_CMD_SET_FEATURES,
+  ONDIE_ECC_FEATURE_ADDR, -1);
+   for (i = 0; i < 4; i++)
+   writeb(set_feature[i], nand_chip->IO_ADDR_W);
+
+   ndelay(1000);
+
+   nand_chip->cmdfunc(mtd, NAND_CMD_GET_FEATURES,
+  ONDIE_ECC_FEATURE_ADDR, -1);
+   get_feature = readb(nand_chip->IO_ADDR_R);
+
+   if (get_feature & 0x08)
+   return 1;
+   }
+   }
+
+   return 0;
+}
+
+/**
  * pl353_nand_ecc_init - Initialize the ecc information as per the ecc mode
  * @mtd:   Pointer to the mtd_info structure
+ * @ondie_ecc_state:   ondie ecc status
  *
  * This function initializes the ecc block and functional pointers as per the
  * ecc mode
  *
  * Return: Zero on success and error on failure.
  */
-static int pl353_nand_ecc_init(struct mtd_info *mtd)
+static int pl353_nand_ecc_init(struct mtd_info *mtd, int ondie_ecc_state)
 {
struct nand_chip *nand_chip = mtd->priv;
struct pl353_nand_info *xnand =
@@ -838,12 +939,28 @@ static int pl353_nand_ecc_init(struct mtd_info *mtd)
 
switch (xnand->ecc_mode) {
case NAND_ECC_HW:
-   if (mtd->writesize > 2048) {
+   

[PATCH RFC v3 2/4] nand: pl353: Add software ecc support

[Punnaiah Choudary Kalluri]

Added software ecc support.

Signed-off-by: Punnaiah Choudary Kalluri 
---
 drivers/mtd/nand/pl353_nand.c |  163 +
 1 files changed, 163 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c
index 0be8ca2..eca205f 100644
--- a/drivers/mtd/nand/pl353_nand.c
+++ b/drivers/mtd/nand/pl353_nand.c
@@ -319,6 +319,71 @@ static int pl353_nand_write_oob(struct mtd_info *mtd, 
struct nand_chip *chip,
 }
 
 /**
+ * pl353_nand_read_page_raw - [Intern] read raw page data without ecc
+ * @mtd:   Pointer to the mtd info structure
+ * @chip:  Pointer to the NAND chip info structure
+ * @buf:   Pointer to the data buffer
+ * @oob_required:  Caller requires OOB data read to chip->oob_poi
+ * @page:  Page number to read
+ *
+ * Return: Always return zero
+ */
+static int pl353_nand_read_page_raw(struct mtd_info *mtd,
+   struct nand_chip *chip,
+   uint8_t *buf, int oob_required, int page)
+{
+   unsigned long data_phase_addr;
+   uint8_t *p;
+
+   chip->read_buf(mtd, buf, mtd->writesize);
+
+   p = chip->oob_poi;
+   chip->read_buf(mtd, p,
+   (mtd->oobsize - PL353_NAND_LAST_TRANSFER_LENGTH));
+   p += (mtd->oobsize - PL353_NAND_LAST_TRANSFER_LENGTH);
+
+   data_phase_addr = (unsigned long __force)chip->IO_ADDR_R;
+   data_phase_addr |= PL353_NAND_CLEAR_CS;
+   chip->IO_ADDR_R = (void __iomem * __force)data_phase_addr;
+
+   chip->read_buf(mtd, p, PL353_NAND_LAST_TRANSFER_LENGTH);
+   return 0;
+}
+
+/**
+ * pl353_nand_write_page_raw - [Intern] raw page write function
+ * @mtd:   Pointer to the mtd info structure
+ * @chip:  Pointer to the NAND chip info structure
+ * @buf:   Pointer to the data buffer
+ * @oob_required:  Caller requires OOB data read to chip->oob_poi
+ *
+ * Return: Always return zero
+ */
+static int pl353_nand_write_page_raw(struct mtd_info *mtd,
+   struct nand_chip *chip,
+   const uint8_t *buf, int oob_required)
+{
+   unsigned long data_phase_addr;
+   uint8_t *p;
+
+   chip->write_buf(mtd, buf, mtd->writesize);
+
+   p = chip->oob_poi;
+   chip->write_buf(mtd, p,
+   (mtd->oobsize - PL353_NAND_LAST_TRANSFER_LENGTH));
+   p += (mtd->oobsize - PL353_NAND_LAST_TRANSFER_LENGTH);
+
+   data_phase_addr = (unsigned long __force)chip->IO_ADDR_W;
+   data_phase_addr |= PL353_NAND_CLEAR_CS;
+   data_phase_addr |= (1 << END_CMD_VALID_SHIFT);
+   chip->IO_ADDR_W = (void __iomem * __force)data_phase_addr;
+
+   chip->write_buf(mtd, p, PL353_NAND_LAST_TRANSFER_LENGTH);
+
+   return 0;
+}
+
+/**
  * nand_write_page_hwecc - Hardware ECC based page write function
  * @mtd:   Pointer to the mtd info structure
  * @chip:  Pointer to the NAND chip info structure
@@ -384,6 +449,39 @@ static int pl353_nand_write_page_hwecc(struct mtd_info 
*mtd,
 }
 
 /**
+ * pl353_nand_write_page_swecc - [REPLACABLE] software ecc based page write
+ * function
+ * @mtd:   Pointer to the mtd info structure
+ * @chip:  Pointer to the NAND chip info structure
+ * @buf:   Pointer to the data buffer
+ * @oob_required:  Caller requires OOB data read to chip->oob_poi
+ *
+ * Return: Always return zero
+ */
+static int pl353_nand_write_page_swecc(struct mtd_info *mtd,
+   struct nand_chip *chip, const uint8_t *buf,
+   int oob_required)
+{
+   int i, eccsize = chip->ecc.size;
+   int eccbytes = chip->ecc.bytes;
+   int eccsteps = chip->ecc.steps;
+   uint8_t *ecc_calc = chip->buffers->ecccalc;
+   const uint8_t *p = buf;
+   uint32_t *eccpos = chip->ecc.layout->eccpos;
+
+   /* Software ecc calculation */
+   for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize)
+   chip->ecc.calculate(mtd, p, _calc[i]);
+
+   for (i = 0; i < chip->ecc.total; i++)
+   chip->oob_poi[eccpos[i]] = ecc_calc[i];
+
+   chip->ecc.write_page_raw(mtd, chip, buf, 1);
+
+   return 0;
+}
+
+/**
  * pl353_nand_read_page_hwecc - Hardware ECC based page read function
  * @mtd:   Pointer to the mtd info structure
  * @chip:  Pointer to the NAND chip info structure
@@ -465,6 +563,52 @@ static int pl353_nand_read_page_hwecc(struct mtd_info *mtd,
 }
 
 /**
+ * pl353_nand_read_page_swecc - [REPLACABLE] software ecc based page read
+ * function
+ * @mtd:   Pointer to the mtd info structure
+ * @chip:  Pointer to the NAND chip info structure
+ * @buf:   Pointer to the buffer to store read data
+ * @oob_required:  Caller requires OOB data read to chip->oob_poi
+ * @page:

[PATCH RFC v3 4/4] Documentation: nand: pl353: Add documentation for controller and driver

[Punnaiah Choudary Kalluri]

Added notes about the controller and driver

Signed-off-by: Punnaiah Choudary Kalluri 
---
 Documentation/mtd/nand/pl353-nand.txt |   92 +
 1 files changed, 92 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/mtd/nand/pl353-nand.txt

diff --git a/Documentation/mtd/nand/pl353-nand.txt 
b/Documentation/mtd/nand/pl353-nand.txt
new file mode 100644
index 000..4deac94
--- /dev/null
+++ b/Documentation/mtd/nand/pl353-nand.txt
@@ -0,0 +1,92 @@
+This documents provides some notes about the ARM pl353 smc controller used in
+Zynq SOC and confined to NAND specific details.
+
+Overview of the controller
+==
+   The SMC (PL353) supports two memory interfaces:
+   Interface 0 type SRAM.
+   Interface 1 type NAND.
+   This configuration supports the following configurable options:
+  . 32-bit or 64-bit AXI data width
+  . 8-bit, 16-bit, or 32-bit memory data width for interface 0
+  . 8-bit, or 16-bit memory data width for interface 1
+  . 1-4 chip selects on each interface
+  . SLC ECC block for interface 1
+
+For more information, refer the below link for TRM
+http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/
+DDI0380G_smc_pl350_series_r2p1_trm.pdf
+
+NAND memory accesses
+
+   . Two phase NAND accesses
+   . NAND command phase transfers
+   . NAND data phase transfers
+
+Two phase NAND accesses
+   The SMC defines two phases of commands when transferring data to or from
+NAND flash.
+
+Command phase
+   Commands and optional address information are written to the NAND flash.
+The command and address can be associated with either a data phase operation to
+write to or read from the array, or a status/ID register transfer.
+
+Data phase
+ Data is either written to or read from the NAND flash. This data can be either
+data transferred to or from the array, or status/ID register information.
+
+NAND AXI address setup
+   AXI address  Command phase  Data phase
+   [31:24] Chip address   Chip address
+   [23]NoOfAddCycles_2Reserved
+   [22]NoOfAddCycles_1Reserved
+   [21]NoOfAddCycles_0ClearCS
+   [20]End command valid  End command valid
+   [19]0  1
+   [18:11] End commandEnd command
+   [10:3]  Start command  [10] ECC Last
+  [9:3] Reserved
+   [2:0]   Reserved   Reserved
+
+ECC
+===
+It operates on a number of 512 byte blocks of NAND memory and can be
+programmed to store the ECC codes after the data in memory. For writes,
+the ECC is written to the spare area of the page. For reads, the result of
+a block ECC check are made available to the device driver.
+
+
+|   n * 512 blocks  | extra  | ecc| |
+|   | block  | codes  | |
+
+
+The ECC calculation uses a simple Hamming code, using 1-bit correction 2-bit
+detection. It starts when a valid read or write command with a 512 byte aligned
+address is detected on the memory interface.
+
+Driver details
+==
+   The NAND driver has dependancy with the pl353_smc memory controller
+driver for intializing the nand timing parameters, bus width, ECC modes,
+control and status information.
+
+Since the controller expects that the chipselect bit should be cleared for the
+last data transfer i.e last 4 data bytes, the existing nandbase page
+read/write routines for soft ecc and ecc none modes will not work. So, inorder
+to make this driver work, it always updates the ecc mode as HW ECC and
+implemented the page read/write functions for supporting the SW ECC.
+
+HW ECC mode:
+   Upto 2K page size is supported and beyond that it retuns
+-ENOSUPPORT error. If the flsh has ONDIE ecc controller then the
+priority has given to the ONDIE ecc controller. Also the current
+implementation has support for upto 64 byte oob area
+
+SW ECC mode:
+   It supports all the pgae sizes. But since, zynq soc bootrom uses
+HW ECC for the devices that have pgae size <=2K so, to avoid any ecc related
+issues during boot, prefer HW ECC over SW ECC.
+
+For devicetree binding information please refer the below dt binding file
+Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
-- 
1.7.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 RFC v3 0/4] Add arm pl353 smc nand driver for xilinx zynq soc

[Punnaiah Choudary Kalluri]

The following patches add arm pl353 static memory controller driver for
xilinx zynq soc. The arm pl353 smc supports two interfaces i.e nand and
nor/sram memory interfaces. The current implementation supports only a
single SMC instance and nand specific configuration.

xilinx zynq TRM link:
http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf

ARM pl353 smc TRM link:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/
DDI0380G_smc_pl350_series_r2p1_trm.pdf

Punnaiah Choudary Kalluri (4):
  nand: pl353: Add basic driver for arm pl353 smc nand interface
  nand: pl353: Add software ecc support
  nand: pl353: Add ONDIE ECC support
  Documentation: nand: pl353: Add documentation for controller and
driver

 Documentation/mtd/nand/pl353-nand.txt |   92 +++
 drivers/mtd/nand/Kconfig  |7 +
 drivers/mtd/nand/Makefile |1 +
 drivers/mtd/nand/pl353_nand.c | 1141 +
 4 files changed, 1241 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/mtd/nand/pl353-nand.txt
 create mode 100644 drivers/mtd/nand/pl353_nand.c

-- 
1.7.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 RFC v3 0/2] Add arm pl353 smc driver for xilinx zynq soc

[Punnaiah Choudary Kalluri]

The following patches add arm pl353 static memory controller driver for
xilinx zynq soc. The arm pl353 smc supports two interfaces i.e nand and
nor/sram memory interfaces. The current implementation supports only a
single SMC instance and nand specific configuration.

xilinx zynq TRM link:
http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf

ARM pl353 smc TRM link:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/
DDI0380G_smc_pl350_series_r2p1_trm.pdf

Punnaiah Choudary Kalluri (2):
  Devicetree: Add pl353 smc controller devicetree binding information
  memory: pl353: Add driver for arm pl353 static memory controller

 .../bindings/memory-controllers/pl353-smc.txt  |   53 ++
 drivers/memory/Kconfig |6 +
 drivers/memory/Makefile|1 +
 drivers/memory/pl353-smc.c |  569 
 include/linux/memory/pl353-smc.h   |   34 ++
 5 files changed, 663 insertions(+), 0 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
 create mode 100644 drivers/memory/pl353-smc.c
 create mode 100644 include/linux/memory/pl353-smc.h

-- 
1.7.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 RFC v3 2/2] memory: pl353: Add driver for arm pl353 static memory controller

[Punnaiah Choudary Kalluri]

Add driver for arm pl353 static memory controller. This controller is
used in xilinx zynq soc for interfacing the nand and nor/sram memory
devices.

Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v2:
 - Since now the timing parameters are in nano seconds, added logic to convert
   them to the cycles
---
 drivers/memory/Kconfig   |6 +
 drivers/memory/Makefile  |1 +
 drivers/memory/pl353-smc.c   |  569 ++
 include/linux/memory/pl353-smc.h |   34 +++
 4 files changed, 610 insertions(+), 0 deletions(-)
 create mode 100644 drivers/memory/pl353-smc.c
 create mode 100644 include/linux/memory/pl353-smc.h

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index c59e9c9..58c29a2 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -65,4 +65,10 @@ config FSL_IFC
bool
depends on FSL_SOC
 
+config PL353_SMC
+   bool "ARM PL353 Static Memory Controller(SMC) driver"
+   default y
+   depends on ARM
+   help
+ This driver is for the ARM PL353 Static Memory Controller(SMC) module.
 endif
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 71160a2..5040977 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
 obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)   += tegra20-mc.o
 obj-$(CONFIG_TEGRA30_MC)   += tegra30-mc.o
+obj-$(CONFIG_PL353_SMC)+= pl353-smc.o
diff --git a/drivers/memory/pl353-smc.c b/drivers/memory/pl353-smc.c
new file mode 100644
index 000..02221ba
--- /dev/null
+++ b/drivers/memory/pl353-smc.c
@@ -0,0 +1,569 @@
+/*
+ * ARM PL353 SMC Driver
+ *
+ * Copyright (C) 2012 - 2014 Xilinx, Inc.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Currently only a single SMC instance is supported.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register definitions */
+#define PL353_SMC_MEMC_STATUS_OFFS 0   /* Controller status reg, RO */
+#define PL353_SMC_CFG_CLR_OFFS 0xC /* Clear config reg, WO */
+#define PL353_SMC_DIRECT_CMD_OFFS  0x10/* Direct command reg, WO */
+#define PL353_SMC_SET_CYCLES_OFFS  0x14/* Set cycles register, WO */
+#define PL353_SMC_SET_OPMODE_OFFS  0x18/* Set opmode register, WO */
+#define PL353_SMC_ECC_STATUS_OFFS  0x400   /* ECC status register */
+#define PL353_SMC_ECC_MEMCFG_OFFS  0x404   /* ECC mem config reg */
+#define PL353_SMC_ECC_MEMCMD1_OFFS 0x408   /* ECC mem cmd1 reg */
+#define PL353_SMC_ECC_MEMCMD2_OFFS 0x40C   /* ECC mem cmd2 reg */
+#define PL353_SMC_ECC_VALUE0_OFFS  0x418   /* ECC value 0 reg */
+
+/* Controller status register specifc constants */
+#define PL353_SMC_MEMC_STATUS_RAW_INT_1_SHIFT  6
+
+/* Clear configuration register specific constants */
+#define PL353_SMC_CFG_CLR_INT_CLR_10x10
+#define PL353_SMC_CFG_CLR_ECC_INT_DIS_10x40
+#define PL353_SMC_CFG_CLR_INT_DIS_10x2
+#define PL353_SMC_CFG_CLR_DEFAULT_MASK (PL353_SMC_CFG_CLR_INT_CLR_1 | \
+PL353_SMC_CFG_CLR_ECC_INT_DIS_1 | \
+PL353_SMC_CFG_CLR_INT_DIS_1)
+
+/* Set cycles register specific constants */
+#define PL353_SMC_SET_CYCLES_T0_MASK   0xF
+#define PL353_SMC_SET_CYCLES_T0_SHIFT  0
+#define PL353_SMC_SET_CYCLES_T1_MASK   0xF
+#define PL353_SMC_SET_CYCLES_T1_SHIFT  4
+#define PL353_SMC_SET_CYCLES_T2_MASK   0x7
+#define PL353_SMC_SET_CYCLES_T2_SHIFT  8
+#define PL353_SMC_SET_CYCLES_T3_MASK   0x7
+#define PL353_SMC_SET_CYCLES_T3_SHIFT  11
+#define PL353_SMC_SET_CYCLES_T4_MASK   0x7
+#define PL353_SMC_SET_CYCLES_T4_SHIFT  14
+#define PL353_SMC_SET_CYCLES_T5_MASK   0x7
+#define PL353_SMC_SET_CYCLES_T5_SHIFT  17
+#define PL353_SMC_SET_CYCLES_T6_MASK   0xF
+#define PL353_SMC_SET_CYCLES_T6_SHIFT  20
+
+/* ECC status register specific constants */
+#define PL353_SMC_ECC_STATUS_BUSY  (1 << 6)
+
+/* ECC memory config register specific constants */
+#define PL353_SMC_ECC_MEMCFG_MODE_MASK 0xC
+#define PL353_SMC_ECC_MEMCFG_MODE_SHIFT2
+#define PL353_SMC_ECC_MEMCFG_PGSIZE_MASK   0xC
+
+#define PL353_SMC_DC_UPT_NAND_REGS ((4 << 23) |/* CS: NAND chip */ \
+(2 << 21)) /* UpdateRegs operation */
+
+#define PL353_NAND_ECC_CMD1((0x80)   | /* Write command */ \
+(0 << 8) | /* Read 

[PATCH RFC v3 1/2] Devicetree: Add pl353 smc controller devicetree binding information

[Punnaiah Choudary Kalluri]

Add pl353 static memory controller devicetree binding information.

Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v2:
 - modified timing binding info as per onfi timing parameters
 - add suffix nano second as timing unit
 - modified the clock names as per the IP spec
---
 .../bindings/memory-controllers/pl353-smc.txt  |   53 
 1 files changed, 53 insertions(+), 0 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt

diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt 
b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
new file mode 100644
index 000..c1f011d
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
@@ -0,0 +1,53 @@
+Device tree bindings for ARM PL353 static memory controller
+
+PL353 static memory controller supports two kinds of memory
+interfaces.i.e NAND and SRAM/NOR interfaces.
+The actual devices are instantiated from the child nodes of pl353 smc node.
+
+Required properties:
+- compatible   : Should be "arm,pl353-smc-r2p1"
+- reg  : Controller registers map and length.
+- clock-names  : List of input clock names - "memclk", "aclk"
+ (See clock bindings for details).
+- clocks   : Clock phandles (see clock bindings for details).
+- address-cells: Address cells, must be 1.
+- size-cells   : Size cells. Must be 1.
+
+Child nodes:
+ For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash" drivers are
+supported as child nodes.
+
+Mandatory timing properties for child nodes:
+- nand-tRC-ns  : Read cycle time.
+- nand-tWC-ns  : Write cycle time.
+- nand-tREA-ns : re_n assertion delay.
+- nand-tWP-ns  : we_n de-assertion delay.
+- nand-tCLR-ns : Status read time
+- nand-tAR-ns  : ID read time
+- nand-tRR-ns  : busy to re_n
+
+for nand partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+   pl353smcc_0: pl353smcc@e000e000 {
+   compatible = "arm,pl353-smcc-r2p1"
+   clock-names = "memclk", "aclk";
+   clocks = < 11>, < 44>;
+   reg = <0xe000e000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   nand_0: nand@e100 {
+   compatible = "arm,pl353-nand-r2p1"
+   reg = <0xe100 0x100>;
+   nand-tRC-ns = <40>;
+   nand-tWC-ns = <40>;
+   nand-tREA-ns = <10>;
+   nand-tWP-ns = <20>;
+   nand-tCLR-ns = <20>;
+   nand-tAR-ns = <20>;
+   nand-tRR-ns = <40>;
+   (...)
+   };
+   };
-- 
1.7.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] sysctl: Add a feature to drop caches selectively

[Dave Chinner]

On Thu, Jun 26, 2014 at 02:10:28PM +0200, Bernd Schubert wrote:
> On 06/26/2014 01:57 PM, Lukáš Czerner wrote:
> >On Thu, 26 Jun 2014, Artem Bityutskiy wrote:
> >>On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote:
> >>>On 06/26/2014 08:13 AM, Artem Bityutskiy wrote:
> On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote:
> >Your particular use case can be handled by directing your benchmark
> >at a filesystem mount point and unmounting the filesystem in between
> >benchmark runs. There is no ned to adding kernel functionality for
> >somethign that can be so easily acheived by other means, especially
> >in benchmark environments where *everything* is tightly controlled.
> 
> If I was a benchmark writer, I would not be willing running it as root
> to be able to mount/unmount, I would not be willing to require the
> customer creating special dedicated partitions for the benchmark,
> because this is too user-unfriendly. Or do I make incorrect assumptions?
> >>>
> >>>But why a sysctl then? And also don't see a point for that at all, why
> >>>can't the benchmark use posix_fadvise(POSIX_FADV_DONTNEED)?
> >>
> >>The latter question was answered - people want a way to drop caches for
> >>a file. They need a method which guarantees that the caches are dropped.
> >>They do not need an advisory method which does not give any guarantees.
> 
> I'm not sure if a benchmark really needs that so much that
> FADV_DONTNEED isn't sufficient.
> Personally I would also like to know if FADV_DONTNEED succeeded.
> I.e. 'ql-fstest' is to check if the written pattern went to the
> block device and currently it does not know if data really had been
> dropped from the page cache. As it reads files several times this is
> not critical, but only would be a nice to have - nothing worth to
> add a new syscall.

ql-test is not a benchmark, it's a data integrity test. The re-read
verification problem is easily solved by using direct IO to read the
files directly without going through the page cache. Indeed, direct
IO will invalidate cached pages over the range it reads before it
does the read, so the guarantee that you are after - no cached pages
when the read is done - is also fulfilled by the direct IO read...

I really don't understand why people keep trying to make cached IO
behave like uncached IO when we already have uncached IO
interfaces

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] sysctl: Add a feature to drop caches selectively

[Dave Chinner]

On Thu, Jun 26, 2014 at 09:13:19AM +0300, Artem Bityutskiy wrote:
> On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote:
> > Your particular use case can be handled by directing your benchmark
> > at a filesystem mount point and unmounting the filesystem in between 
> > benchmark runs. There is no ned to adding kernel functionality for
> > somethign that can be so easily acheived by other means, especially
> > in benchmark environments where *everything* is tightly controlled.
> 
> If I was a benchmark writer, I would not be willing running it as root
> to be able to mount/unmount, I would not be willing to require the
> customer creating special dedicated partitions for the benchmark,
> because this is too user-unfriendly. Or do I make incorrect assumptions?

Just add the dev/mntpt to /etc/fstab and add "user" to the
configuration and the need for root goes away.

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: ext4: total breakdown on USB hdd, 3.0 kernel

[Theodore Ts'o]

On Thu, Jun 26, 2014 at 10:50:49PM +0200, Pavel Machek wrote:
> 
> And for every bug in kernel, there's one in fsck: I did not expect it, but 
> fsck actually
> suceeded, and marked fs as clean. But second fsck had issues with 
> /lost+found...

I'd need the previous fsck transcript to have any idea what might have
happened.  I'll note though you are using an ancient version of e2fsck
(1.41.12, and there have been a huge number of bug fixes since
May 2010)

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arch/score/include/uapi/asm/ptrace.h: Remove the macros which not be used currently

[Chen Gang]

On 06/27/2014 10:11 AM, Lennox Wu wrote:
> Acked-by: Lennox Wu 
> 

OK, thank, and excuse me, I am not quite familiar with the version
merging of upstream kernel: "who will apply it, next, if it is past all
reviewers' checking".


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ext4: total breakdown on USB hdd, 3.0 kernel

[Theodore Ts'o]

On Thu, Jun 26, 2014 at 10:30:52PM +0200, Pavel Machek wrote:
> 
> It looks like the filesystem contains _way_ too many 0x's:

That sounds like it's a hardware issue.  It may be that the controller
did something insane while trying to do a write at the point when the
disk drive was disconnected (and so the drive suffered a power drop).

> I saved beggining of the filesystem using cat /dev/sdc4 | gzip -9 - > 
> /dev/sda3, but
> then ran out of patience. So there may be something for analysis, but...

The way to snapshot just the metadata blocks for analysis is:

e2image -r /dev/hdc4 | bzip2 > ~/hdc4.e2i.bz2

But in this case, it's I doubt it will be very helpful, because
fundamentally, this appears to be a hardware issue.

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

Cleanup of Kernel Bugzilla

[Nick Krause]

Hey Fellow Kernel Developers ,
I known this message is during the merge window of 3.16 -r3 so if you
get back to me after this window ,it's fine.
I seem to be finding lots of bugs on the kernel  Bugzilla that are now
fixed , it would be great if the maintainers or bug
reporters closed them. In addition most of them , seem to from the
years 2011 -2013. I have searched through assigned ,
reopened ,need info and new bug states on the kernel Bugzilla . The
bugs are up to date on assigned but the other open
states for bugs  need to be cleaned up a lot. It would be great if
when you guys have time if the bugs that are fixed
will be closed from these years that are now resolved.
Cheers ,
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: linux-next: the selinux tree needs cleaning up

[James Morris]

On 06/26/2014 08:12 AM, Stephen Rothwell wrote:

Hi James,

On Wed, 25 Jun 2014 20:51:43 +1000 James Morris  
wrote:


I haven't pulled in Paul's tree, I merged with the latest Linus release.


Ummm, yesterday your security tree
(git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
moved from commit 2fd4e6698f08 ("Merge branch 'smack-for-3.16' of
git://git.gitorious.org/smack-next/kernel into next") (which is
included in v3.16-rc1) to commit f01387d26938 ("Merge commit 'v3.15'
into next").  The commit between those 2 commits is 92953ff38ba5
("Merge branch 'next' of git://git.infradead.org/users/pcmoore/selinux
into next").



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

Re: [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0

[Viresh Kumar]

On 27 June 2014 05:36, Stephen Boyd  wrote:
> I gave it a spin. It looks mostly good except for the infinite loop:

Great !!

> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index b7ee67c4d1c0..6744321ae33d 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -138,8 +138,10 @@ try_again:
> }
>
> /* Try with "cpu-supply" */
> -   if (reg == reg_cpu0)
> +   if (reg == reg_cpu0) {
> +   reg = reg_cpu;
> goto try_again;
> +   }
>
> dev_warn(cpu_dev, "failed to get cpu%d regulator: %ld\n",
>  cpu, PTR_ERR(cpu_reg));

Awesome code, I wrote it. Thanks for fixing it.

> and I think we just want reg_cpu to be "cpu", not "cpu-supply" because I
> think the regulator core adds in the "-supply" part already.

Okay.

> After fixing that I can get cpufreq going. I'm currently working on
> populating the OPPs at runtime without relying on DT. So eventually I'll
> need this patch:

I see..

> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index b7ee67c4d1c0..6744321ae33d 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -239,11 +241,6 @@ static int cpu0_cpufreq_init(struct cpufreq_policy 
> *policy)
> }
>
> ret = of_init_opp_table(cpu_dev);
> -   if (ret) {
> -   dev_err(cpu_dev, "failed to init OPP table: %d\n", ret);
> -   goto out_put_node;
> -   }
> -
> ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table);
> if (ret) {
> dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
>
> which I hope is ok.

I need to see details of these routines once again, but will surely make
it work for you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0

[Viresh Kumar]

On 27 June 2014 07:23, Mike Turquette  wrote:
>> but it isn't future-proof if/when the clock framework starts returning
>> dynamically allocated clock pointers for each clk_get() invocation.
>> Maybe we need a function in the common clock framework that tells us if
>> the clocks are the same either via DT or by taking two clock pointers?
>
> I looked through the patch briefly and did not see why we would need to
> do this. Any hint?

We want to know which CPUs are sharing clock line, so that we can
fill affected-cpus field of cpufreq core.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arch/score/include/uapi/asm/ptrace.h: Remove the macros which not be used currently

[Lennox Wu]

Acked-by: Lennox Wu 

2014-06-27 7:28 GMT+08:00 Chen Gang :
>
>
> On 06/27/2014 05:56 AM, David Rientjes wrote:
>> On Thu, 26 Jun 2014, Chen Gang wrote:
>>
>>> 'COUNTER' and other same kind macros are too common to use, and easy to
>>> get conflict with other modules.
>>>
>>> At present, they are not used, so it is OK to simply remove them. And the
>>> related warning (allmodconfig with score):
>>>
>>> CC [M]  drivers/md/raid1.o
>>>   In file included from drivers/md/raid1.c:42:0:
>>>   drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined
>>>#define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX)
>>>^
>>>   In file included from ./arch/score/include/asm/ptrace.h:4:0,
>>>from include/linux/sched.h:31,
>>>from include/linux/blkdev.h:4,
>>>from drivers/md/raid1.c:36:
>>>   ./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the location 
>>> of the previous definition
>>>#define COUNTER  38
>>>
>>>
>>> Signed-off-by: Chen Gang 
>>
>> Acked-by: David Rientjes 
>>
>
> OK, thanks. And also thank all of you for your discussions.
>
> Thanks.
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scsi: bnx2i: bnx2i_iscsi.c: Fix variable which was set to the wrong value

[Mike Christie]

On 06/26/2014 12:10 PM, Rickard Strandqvist wrote:
> After some discussion, all agreed that the previous value was incorrect.
> 
> Signed-off-by: Rickard Strandqvist 

This is better but still sort of incorrect as userspace would be getting 2
bogus entries at indexes 0 and 1. be2iscsi is also broken but it actually
was telling userspace it had no entries when it had one. The patch below
fixes both drivers. Tested here with both drivers.


[PATCH] bnx2i, be2iscsi: fix custom stats length

The custom stats is an array with custom_length indicating the length
of the array. This patch fixes bnx2i and be2iscsi's setting of the
custom stats. They both just have the one, eh_abort_cnt, so that should
be in the first entry of the custom array and custom_length should then
be one.

Signed-off-by: Mike Christie 
Acked-by: Eddie Wai 

diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index fd284ff..8616281 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -914,7 +914,7 @@ void beiscsi_conn_get_stats(struct iscsi_cls_conn *cls_conn,
stats->r2t_pdus = conn->r2t_pdus_cnt;
stats->digest_err = 0;
stats->timeout_err = 0;
-   stats->custom_length = 0;
+   stats->custom_length = 1;
strcpy(stats->custom[0].desc, "eh_abort_cnt");
stats->custom[0].value = conn->eh_abort_cnt;
 }
diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
index 166543f..9bd9b81 100644
--- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
+++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
@@ -1643,12 +1643,11 @@ static void bnx2i_conn_get_stats(struct iscsi_cls_conn 
*cls_conn,
stats->r2t_pdus = conn->r2t_pdus_cnt;
stats->tmfcmd_pdus = conn->tmfcmd_pdus_cnt;
stats->tmfrsp_pdus = conn->tmfrsp_pdus_cnt;
-   stats->custom_length = 3;
-   strcpy(stats->custom[2].desc, "eh_abort_cnt");
-   stats->custom[2].value = conn->eh_abort_cnt;
stats->digest_err = 0;
stats->timeout_err = 0;
-   stats->custom_length = 0;
+   strcpy(stats->custom[0].desc, "eh_abort_cnt");
+   stats->custom[0].value = conn->eh_abort_cnt;
+   stats->custom_length = 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 2/2] cpufreq: cpu0: Extend support beyond CPU0

[Mike Turquette]

Quoting Stephen Boyd (2014-06-26 17:06:00)
> Finally, checking for equivalent pointers from clk_get() will work now,

Please don't do that. Even though it works for the current
implementation, comparing those pointers from a driver violates how
clkdev is supposed to work. The pointer returned by clk_get should only
be dereferenced by a driver to check if it is an error code. Anything
besides an error code is no business of the driver.

> but it isn't future-proof if/when the clock framework starts returning
> dynamically allocated clock pointers for each clk_get() invocation.
> Maybe we need a function in the common clock framework that tells us if
> the clocks are the same either via DT or by taking two clock pointers?

I looked through the patch briefly and did not see why we would need to
do this. Any hint?

Thanks,
Mike

> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

hung task without any output

[Sasha Levin]

Hi all,

While fuzzing with trinity I've recently observed a situation with has started
occurring rather frequently.

I have my configuration set to do a trigger_all_cpu_backtrace() before executing
panic(), and that's exactly what happens in some cases.

The new thing which I started seeing is the following:

[ 4806.833452] Kernel panic - not syncing: hung_task: blocked tasks
[ 4806.834701] CPU: 26 PID: 3252 Comm: khungtaskd Not tainted 
3.16.0-rc2-next-20140626-sasha-00023-g9256882-dirty #732
[ 4806.837672]  003ffcda 880bb2d6bd38 b1529940 
0001
[ 4806.839784]  b26fecef 880bb2d6bdb8 b151cb0f 
0001
[ 4806.840057]  0008 880bb2d6bdc8 880bb2d6bd68 
0001
[ 4806.840057] Call Trace:
[ 4806.840057]  [] dump_stack+0x4f/0x7c
[ 4806.840057]  [] panic+0xd2/0x217
[ 4806.840057]  [] watchdog+0x43f/0x620
[ 4806.840057]  [] ? watchdog+0x89/0x620
[ 4806.840057]  [] ? reset_hung_task_detector+0x20/0x20
[ 4806.840057]  [] kthread+0x108/0x110
[ 4806.840057]  [] ? kthread_create_on_node+0x260/0x260
[ 4806.840057]  [] ret_from_fork+0x7c/0xb0
[ 4806.840057]  [] ? kthread_create_on_node+0x260/0x260
[ 4806.840057] Dumping ftrace buffer:
[ 4806.840057](ftrace buffer empty)
[ 4806.840057] Kernel Offset: 0x2d00 from 0x8100 (relocation 
range: 0x8000-0xbfff)

Without anything else to accompany it.


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

Re: [RFC][PATCH 1/5 v2] tracing: Add trace_seq_buffer_ptr() helper function

[Steven Rostedt]

As this patch is in my 3.17 queue and it touches the kvm and scsi
tracepoint code, I figured I should at least do the courtesy of
notifying the maintainers of those subsystems.

Do you have any issues with this going through my tree? If not, please
give me an Acked-by.

Thanks!

-- Steve

On Thu, 26 Jun 2014 17:49:02 -0400
Steven Rostedt  wrote:

> From: "Steven Rostedt (Red Hat)" 
> 
> There's several locations in the kernel that open code the calculation
> of the next location in the trace_seq buffer. This is usually done with
> 
>   p->buffer + p->len
> 
> Instead of having this open coded, supply a helper function in the
> header to do it for them. This function is called trace_seq_buffer_ptr().
> 
> Signed-off-by: Steven Rostedt 
> ---
>  arch/x86/kvm/mmutrace.h |  2 +-
>  drivers/scsi/scsi_trace.c   | 16 
>  include/linux/trace_seq.h   | 15 +++
>  kernel/trace/trace_output.c | 14 +++---
>  4 files changed, 31 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/x86/kvm/mmutrace.h b/arch/x86/kvm/mmutrace.h
> index 9d2e0ffcb190..2e5652b62fd6 100644
> --- a/arch/x86/kvm/mmutrace.h
> +++ b/arch/x86/kvm/mmutrace.h
> @@ -22,7 +22,7 @@
>   __entry->unsync = sp->unsync;
>  
>  #define KVM_MMU_PAGE_PRINTK() ({ \
> - const char *ret = p->buffer + p->len;   \
> + const char *ret = trace_seq_buffer_ptr(p);  \
>   static const char *access_str[] = { \
>   "---", "--x", "w--", "w-x", "-u-", "-ux", "wu-", "wux"  \
>   };  \
> diff --git a/drivers/scsi/scsi_trace.c b/drivers/scsi/scsi_trace.c
> index 2bea4f0b684a..503594e5f76d 100644
> --- a/drivers/scsi/scsi_trace.c
> +++ b/drivers/scsi/scsi_trace.c
> @@ -28,7 +28,7 @@ scsi_trace_misc(struct trace_seq *, unsigned char *, int);
>  static const char *
>  scsi_trace_rw6(struct trace_seq *p, unsigned char *cdb, int len)
>  {
> - const char *ret = p->buffer + p->len;
> + const char *ret = trace_seq_buffer_ptr(p);
>   sector_t lba = 0, txlen = 0;
>  
>   lba |= ((cdb[1] & 0x1F) << 16);
> @@ -46,7 +46,7 @@ scsi_trace_rw6(struct trace_seq *p, unsigned char *cdb, int 
> len)
>  static const char *
>  scsi_trace_rw10(struct trace_seq *p, unsigned char *cdb, int len)
>  {
> - const char *ret = p->buffer + p->len;
> + const char *ret = trace_seq_buffer_ptr(p);
>   sector_t lba = 0, txlen = 0;
>  
>   lba |= (cdb[2] << 24);
> @@ -71,7 +71,7 @@ scsi_trace_rw10(struct trace_seq *p, unsigned char *cdb, 
> int len)
>  static const char *
>  scsi_trace_rw12(struct trace_seq *p, unsigned char *cdb, int len)
>  {
> - const char *ret = p->buffer + p->len;
> + const char *ret = trace_seq_buffer_ptr(p);
>   sector_t lba = 0, txlen = 0;
>  
>   lba |= (cdb[2] << 24);
> @@ -94,7 +94,7 @@ scsi_trace_rw12(struct trace_seq *p, unsigned char *cdb, 
> int len)
>  static const char *
>  scsi_trace_rw16(struct trace_seq *p, unsigned char *cdb, int len)
>  {
> - const char *ret = p->buffer + p->len;
> + const char *ret = trace_seq_buffer_ptr(p);
>   sector_t lba = 0, txlen = 0;
>  
>   lba |= ((u64)cdb[2] << 56);
> @@ -125,7 +125,7 @@ scsi_trace_rw16(struct trace_seq *p, unsigned char *cdb, 
> int len)
>  static const char *
>  scsi_trace_rw32(struct trace_seq *p, unsigned char *cdb, int len)
>  {
> - const char *ret = p->buffer + p->len, *cmd;
> + const char *ret = trace_seq_buffer_ptr(p), *cmd;
>   sector_t lba = 0, txlen = 0;
>   u32 ei_lbrt = 0;
>  
> @@ -180,7 +180,7 @@ out:
>  static const char *
>  scsi_trace_unmap(struct trace_seq *p, unsigned char *cdb, int len)
>  {
> - const char *ret = p->buffer + p->len;
> + const char *ret = trace_seq_buffer_ptr(p);
>   unsigned int regions = cdb[7] << 8 | cdb[8];
>  
>   trace_seq_printf(p, "regions=%u", (regions - 8) / 16);
> @@ -192,7 +192,7 @@ scsi_trace_unmap(struct trace_seq *p, unsigned char *cdb, 
> int len)
>  static const char *
>  scsi_trace_service_action_in(struct trace_seq *p, unsigned char *cdb, int 
> len)
>  {
> - const char *ret = p->buffer + p->len, *cmd;
> + const char *ret = trace_seq_buffer_ptr(p), *cmd;
>   sector_t lba = 0;
>   u32 alloc_len = 0;
>  
> @@ -247,7 +247,7 @@ scsi_trace_varlen(struct trace_seq *p, unsigned char 
> *cdb, int len)
>  static const char *
>  scsi_trace_misc(struct trace_seq *p, unsigned char *cdb, int len)
>  {
> - const char *ret = p->buffer + p->len;
> + const char *ret = trace_seq_buffer_ptr(p);
>  
>   trace_seq_printf(p, "-");
>   trace_seq_putc(p, 0);
> diff --git a/include/linux/trace_seq.h b/include/linux/trace_seq.h
> index dd85753e1bb0..ea6c9dea79e3 100644
> --- a/include/linux/trace_seq.h
> +++ b/include/linux/trace_seq.h
> @@ -25,6 +25,21 @@ trace_seq_init(struct trace_seq *s)
>   s->full = 0;
>  }
>  
> +/**
> + * 

Re: [PATCH] ring-buffer: Race when writing and swapping cpu buffer in parallel

[Steven Rostedt]

On Thu, 26 Jun 2014 09:58:31 -0400
Steven Rostedt  wrote:

> What we can do is force ring_buffer_swap_cpu() to only work for the CPU
> that it is on. As we have snapshot in per_cpu buffers, to make that
> work, we will need to change the per_cpu version of snapshot to do a
> smp_call_function_single() to the CPU that it wants to take a snapshot
> of, and run the swap there.
> 
> To force this, we can remove the cpu parameter from the
> ring_buffer_swap_cpu(). By doing this, we may be able to remove some of
> the CONFIG_RING_BUFFER_ALLOW_SWAP hacks too!
> 
> I'm not going to sacrifice the general performance of the ring buffer
> for a feature that is seldom (if ever) used.

Did you want to do the above, or do you want me to write something up?

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

Re: [PATCH] ring-buffer: Fix polling on trace_pipe

[Steven Rostedt]

On Thu, 26 Jun 2014 11:34:46 -0700
Martin Lau  wrote:

> Hi Steve,
> 
> Can the modified test program reproduce the problem in your test setup?

Ah sorry, got distracted by other work.

OK, I just tried it out, and here's my results:

I ran you code with my current kernel and this is what I got:

# ./ftrace-test-epoll-kafai 
   <...>-3183  [002] ...181.777891: tracing_mark_write:
some data 3183: waitting for more data..
3184: written more data

And it just hung there.


Then I applied your patch, compiled and booted it, and ran the test
again, and I got this:

# ./ftrace-test-epoll-kafai

It just hung there. No forward progress.

I don't think that was the result you intended.

-- Steve


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

Re: [PATCH v7 1/6] pci: Introduce pci_register_io_range() helper function.

[Rob Herring]

Adding Michael Simek...

On Thu, Jun 26, 2014 at 3:59 AM, Catalin Marinas
 wrote:
> (sorry for replying to a months old thread)
>
> On Mon, Apr 07, 2014 at 06:58:24PM +0100, Bjorn Helgaas wrote:
>> On Mon, Apr 7, 2014 at 5:36 AM, Arnd Bergmann  wrote:
>>
>> > I think migrating other architectures to use the same code should be
>> > a separate effort from adding a generic implementation that can be
>> > used by arm64. It's probably a good idea to have patches to convert
>> > arm32 and/or microblaze.
>>
>> Let me reiterate that I am 100% in favor of replacing arch-specific
>> code with more generic implementations.
>>
>> However, I am not 100% in favor of doing it as separate efforts
>> (although maybe I could be convinced).  The reasons I hesitate are
>> that (1) if only one architecture uses a new "generic" implementation,
>> we really don't know whether it is generic enough, (2) until I see the
>> patches to convert other architectures, I have to assume that I'm the
>> one who will write them, and (3) as soon as we add the code to
>> drivers/pci, it becomes partly my headache to maintain it, even if
>> only one arch benefits from it.
>
> I agree and understand your point.
>
>> Please don't think I'm questioning anyone's intent or good will.  It's
>> just that I understand the business pressures, and I know how hard it
>> can be to justify this sort of work to one's management, especially
>> after the immediate problem has been solved.
>
> But, unfortunately, that's something we failed to address in reasonable
> time (even though I was one of the proponents of the generic PCIe
> implementation). This work is very likely to slip further into the late
> part of this year and I am aware that several ARM partners are blocked
> on the (upstream) availability of PCIe support for the arm64 kernel.
>
> Although a bit late, I'm raising this now and hopefully we'll come to a
> conclusion soon. Delaying arm64 PCIe support even further is not a real
> option, which leaves us with:
>
> 1. Someone else (with enough PCIe knowledge) volunteering to take over
>soon or

Well, I might have 2 months ago, but now I'm pretty booked up.

> 2. Dropping Liviu's work and going for an arm64-specific implementation
>(most likely based on the arm32 implementation, see below)

3. Keeping Liviu's patches leaving some of the architecture specific
bits. I know Arnd and I both commented on it still needing more common
pieces, but compared to option 2 that would be way better.

Let's look at the patches in question:

3e71867 pci: Introduce pci_register_io_range() helper function.
6681dff pci: OF: Fix the conversion of IO ranges into IO resources.

Both OF patches. I'll happily merge them.


2d5dd85 pci: Create pci_host_bridge before its associated bus in
pci_create_root_bus.
f6f2854 pci: Introduce a domain number for pci_host_bridge.
524a9f5 pci: Export find_pci_host_bridge() function.

These don't seem to be too controversial.


fb75718 pci: of: Parse and map the IRQ when adding the PCI device.

6 LOC. Hardly controversial.


920a685 pci: Add support for creating a generic host_bridge from device tree

This function could be moved to drivers/of/of_pci.c if having it in
drivers/pci is too much maintenance burden. However, nearly the same
code is already being duplicated in every DT enabled ARM PCI host
driver and will continue as more PCI hosts are added. So this isn't
really a question of converting other architectures to common PCI host
infrastructure, but converting DT based PCI hosts to common
infrastructure. ARM is the only arch moving host drivers to
drivers/pci ATM. Until other architectures start doing that,
converting them is pointless.

bcf5c10 Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.

Seems like an independent fix that should be applied regardless.


7cfde80 arm64: Add architecture support for PCI

What is here is really just a function of which option we pick.


> First option is ideal but there is work to do as laid out by Arnd here:
>
> http://article.gmane.org/gmane.linux.kernel/1679304

I don't agree arm32 is harder than microblaze. Yes, converting ALL of
arm would be, but that is not necessary. With Liviu's latest branch
the hacks I previously needed are gone (thanks!), and this is all I
need to get Versatile PCI working (under QEMU):

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 3d23418..22b7529 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -178,6 +178,7 @@ static inline void __iomem *__typesafe_io(unsigned
long addr)

 /* PCI fixed i/o mapping */
 #define PCI_IO_VIRT_BASE   0xfee0
+#define PCI_IOBASE PCI_IO_VIRT_BASE

 #if defined(CONFIG_PCI)
 void pci_ioremap_set_mem_type(int mem_type);

Hum, so I guess now I've converted ARM...

Here's a branch with my changes[1]. And BTW, it also has
multi-platform support for Versatile as moving the PCI host to DT (and
drivers/pci/host) is about the last remaining obstacle.

Rob

[1] 

Re: [Patch] x86: intel-mid: fix conflicts between 78a3bb9e408b and 9f354b0252b8

[Jiang Liu]

Thanks, David!

On 2014/6/27 3:33, David Cohen wrote:
> On Mon, Jun 23, 2014 at 10:38:07AM -0700, David Cohen wrote:
>> Hi Jiang,
>>
>> On Mon, Jun 23, 2014 at 10:30:35AM +0800, Jiang Liu wrote:
>>> Commit 9f354b0252b8 "x86, irq: Clean up unused IOAPIC interface" kills
>>> interface io_apic_set_pci_routing(), so change arch/x86/platform/
>>> intel-mid/device_libs/platform_wdt.c to use new interfaces.
>>>
>>> Due to hardware resource restriction, this patch only passes compilation
>>> without functional tests.
>>
>> I'll test this patch.
> 
> It sounds good.
> Acked-by: David Cohen 
> 
>>
>> BR, David
>>
>>>
>>> Signed-off-by: Jiang Liu 
>>> ---
>>>  .../platform/intel-mid/device_libs/platform_wdt.c  |   22 
>>> ++--
>>>  1 file changed, 6 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/arch/x86/platform/intel-mid/device_libs/platform_wdt.c 
>>> b/arch/x86/platform/intel-mid/device_libs/platform_wdt.c
>>> index 973cf3bfa9fd..0b283d4d0ad7 100644
>>> --- a/arch/x86/platform/intel-mid/device_libs/platform_wdt.c
>>> +++ b/arch/x86/platform/intel-mid/device_libs/platform_wdt.c
>>> @@ -26,28 +26,18 @@ static struct platform_device wdt_dev = {
>>>  
>>>  static int tangier_probe(struct platform_device *pdev)
>>>  {
>>> -   int ioapic;
>>> -   int irq;
>>> +   int gsi;
>>> struct intel_mid_wdt_pdata *pdata = pdev->dev.platform_data;
>>> -   struct io_apic_irq_attr irq_attr = { 0 };
>>>  
>>> if (!pdata)
>>> return -EINVAL;
>>>  
>>> -   irq = pdata->irq;
>>> -   ioapic = mp_find_ioapic(irq);
>>> -   if (ioapic >= 0) {
>>> -   int ret;
>>> -   irq_attr.ioapic = ioapic;
>>> -   irq_attr.ioapic_pin = irq;
>>> -   irq_attr.trigger = 1;
>>> -   /* irq_attr.polarity = 0; -> Active high */
>>> -   ret = io_apic_set_pci_routing(NULL, irq, _attr);
>>> -   if (ret)
>>> -   return ret;
>>> -   } else {
>>> +   /* IOAPIC builds identity mapping between GSI and IRQ on MID */
>>> +   gsi = pdata->irq;
>>> +   if (mp_set_gsi_attr(gsi, 1, 0, cpu_to_node(0)) ||
>>> +   mp_map_gsi_to_irq(gsi, IOAPIC_MAP_ALLOC) <= 0) {
>>> dev_warn(>dev, "cannot find interrupt %d in ioapic\n",
>>> -irq);
>>> +gsi);
>>> return -EINVAL;
>>> }
>>>  
>>> -- 
>>> 1.7.10.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/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: cros_ec_spi: set wakeup capability

[Olof Johansson]

On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones  wrote:
>> Lee (-others),
>
> Re-CC'ing the list.
>
>> On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones  wrote:
>> >> From: Prathyush K 
>> >>
>> >> Set the device as wakeup capable and register the wakeup source.
>> >>
>> >> Note: Though it makes more sense to have the SPI framework do this,
>> >> (either via device tree or by board_info)
>> >> this change is as per an existing mail chain:
>> >> https://lkml.org/lkml/2009/8/27/291
>> >>
>> >> Signed-off-by: Prathyush K 
>> >> Signed-off-by: Doug Anderson 
>> >> ---
>> >> Note that I don't have suspend/resume actually working upstream, but I
>> >> see that /sys/bus/spi/drivers/cros-ec-spi/spi2.0/power/wakeup exists
>> >> with this patch and doesn't exist without it.
>> >
>> > Very well.  Applied, thanks.
>>
>> Thanks for applying!  ...did this go in some non-standard branch?  I
>> see another of my patches got committed to your "for-mfd-next" tree on
>> the 19th but I don't see this one...
>
> Patience Grasshopper.  When I say that it's applied, it means that I
> have done so locally only.  After I've collected a few local patches
> I'll usually then fix them all with with my SoB and push them out to
> the public MFD tree.
>
> BTW, it's always best to leave the ML in as CC, so others can see the
> answer to these types of questions.  It may save a few emails a year,
> but every little helps. :)

It's great to see this on the list, because I find your workflow as a
maintainer to be hard to follow as a developer.

You applying patches but taking several days to push out makes it
completely opaque for someone to know if you just accidentally missed
to apply the patch after all (it happens, I've done that myself). It's
pretty common to expect a "thanks, applied" patch to show up in
linux-next within one day or so depending on timing.

The fact that you had already pushed out a patch that you had replied
to even later makes for extra confusion. So I'm sorry Lee, but I don't
think Doug was unreasonable in asking for status here. Sometimes
maintainers forget to push, which is why it's a good idea to ping a
few days later if the patch hasn't showed up in -next.


-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 v6 02/10] x86, mpx: add MPX specific mmap interface

[Andy Lutomirski]

On Thu, Jun 26, 2014 at 5:19 PM, Dave Hansen  wrote:
> On 06/26/2014 04:15 PM, Andy Lutomirski wrote:
>> So here's my mental image of how I might do this if I were doing it
>> entirely in userspace: I'd create a file or memfd for the bound tables
>> and another for the bound directory.  These files would be *huge*: the
>> bound directory file would be 2GB and the bounds table file would be
>> 2^48 bytes or whatever it is.  (Maybe even bigger?)
>>
>> Then I'd just map pieces of those files wherever they'd need to be,
>> and I'd make the mappings sparse.  I suspect that you don't actually
>> want a vma for each piece of bound table that gets mapped -- the space
>> of vmas could end up incredibly sparse.  So I'd at least map (in the
>> vma sense, not the pte sense) and entire bound table at a time.  And
>> I'd probably just map the bound directory in one big piece.
>>
>> Then I'd populate it in the fault handler.
>>
>> This is almost what the code is doing, I think, modulo the files.
>>
>> This has one killer problem: these mappings need to be private (cowed
>> on fork).  So memfd is no good.
>
> This essentially uses the page cache's radix tree as a parallel data
> structure in order to keep a vaddr->mpx_vma map.  That's not a bad idea,
> but it is a parallel data structure that does not handle copy-on-write
> very well.
>
> I'm pretty sure we need the semantics that anonymous memory provides.
>
>> There's got to be an easyish way to
>> modify the mm code to allow anonymous maps with vm_ops.  Maybe a new
>> mmap_region parameter or something?  Maybe even a special anon_vma,
>> but I don't really understand how those work.
>
> Yeah, we very well might end up having to go down that path.
>
>> Also, egads: what happens when a bound table entry is associated with
>> a MAP_SHARED page?
>
> Bounds table entries are for pointers.  Do we keep pointers inside of
> MAP_SHARED-mapped things? :)

Sure, if it's MAP_SHARED | MAP_ANONYMOUS.  For example:

struct thing {
  struct thing *next;
};

struct thing *storage = mmap(..., MAP_SHARED | MAP_ANONYMOUS, ...);
storage[0].next = [1];
fork();

I'm not suggesting that this needs to *work* in the first incarnation of this :)

--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: Linux 3.15.2

[Josh Boyer]

On Thu, Jun 26, 2014 at 3:26 PM, Greg KH  wrote:
> I'm announcing the release of the 3.15.2 kernel.
>
> All users of the 3.15 kernel series must upgrade.
>
> The updated 3.15.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
> linux-3.15.y
> and can be browsed at the normal kernel.org git web browser:
> 
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

Is the patch for this stuck somewhere on kernel.org?  I see
patch-3.14.9.xz, but patch-3.15.2.xz is missing on both the kernel.org
front page and the 3.x http directory where we'd normally find it.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/10] x86, mpx: add MPX specific mmap interface

[Dave Hansen]

On 06/26/2014 04:15 PM, Andy Lutomirski wrote:
> So here's my mental image of how I might do this if I were doing it
> entirely in userspace: I'd create a file or memfd for the bound tables
> and another for the bound directory.  These files would be *huge*: the
> bound directory file would be 2GB and the bounds table file would be
> 2^48 bytes or whatever it is.  (Maybe even bigger?)
> 
> Then I'd just map pieces of those files wherever they'd need to be,
> and I'd make the mappings sparse.  I suspect that you don't actually
> want a vma for each piece of bound table that gets mapped -- the space
> of vmas could end up incredibly sparse.  So I'd at least map (in the
> vma sense, not the pte sense) and entire bound table at a time.  And
> I'd probably just map the bound directory in one big piece.
> 
> Then I'd populate it in the fault handler.
> 
> This is almost what the code is doing, I think, modulo the files.
> 
> This has one killer problem: these mappings need to be private (cowed
> on fork).  So memfd is no good.

This essentially uses the page cache's radix tree as a parallel data
structure in order to keep a vaddr->mpx_vma map.  That's not a bad idea,
but it is a parallel data structure that does not handle copy-on-write
very well.

I'm pretty sure we need the semantics that anonymous memory provides.

> There's got to be an easyish way to
> modify the mm code to allow anonymous maps with vm_ops.  Maybe a new
> mmap_region parameter or something?  Maybe even a special anon_vma,
> but I don't really understand how those work.

Yeah, we very well might end up having to go down that path.

> Also, egads: what happens when a bound table entry is associated with
> a MAP_SHARED page?

Bounds table entries are for pointers.  Do we keep pointers inside of
MAP_SHARED-mapped things? :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Filesystem lockup with CONFIG_PREEMPT_RT

[Austin Schuh]

On Thu, Jun 26, 2014 at 3:35 PM, Thomas Gleixner  wrote:
> On Thu, 26 Jun 2014, Austin Schuh wrote:
>> On Wed, May 21, 2014 at 12:33 AM, Richard Weinberger
>>  wrote:
>> > CC'ing RT folks
>> >
>> > On Wed, May 21, 2014 at 8:23 AM, Austin Schuh  
>> > wrote:
>> >> On Tue, May 13, 2014 at 7:29 PM, Austin Schuh  
>> >> wrote:
>> >>> Hi,
>> >>>
>> >>> I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
>> >>> patched kernel.  I have currently only triggered it using dpkg.  Dave
>> >>> Chinner on the XFS mailing list suggested that it was a rt-kernel
>> >>> workqueue issue as opposed to a XFS problem after looking at the
>> >>> kernel messages.
>>
>> I've got a 100% reproducible test case that doesn't involve a
>> filesystem.  I wrote a module that triggers the bug when the device is
>> written to, making it easy to enable tracing during the event and
>> capture everything.
>>
>> It looks like rw_semaphores don't trigger wq_worker_sleeping to run
>> when work goes to sleep on a rw_semaphore.  This only happens with the
>> RT patches, not with the mainline kernel.  I'm foreseeing a second
>> deadlock/bug coming into play shortly.  If a task holding the work
>> pool spinlock gets preempted, and we need to schedule more work from
>> another worker thread which was just blocked by a mutex, we'll then
>> end up trying to go to sleep on 2 locks at once.
>
> I remember vaguely, that I've seen and analyzed that quite some time
> ago. I can't page in all the gory details right now, but I have a look
> how the related code changed in the last couple of years tomorrow
> morning with an awake brain.
>
> Steven, you did some analysis on that IIRC, or was that just related
> to rw_locks?
>
> Thanks,
>
> tglx

If I'm reading the rt patch correctly, wq_worker_sleeping was moved
out of __schedule to sched_submit_work.  It looks like that changes
the conditions under which wq_worker_sleeping is called.  It used to
be called whenever a task was going to sleep (I think).  It looks like
it is called now if the task is going to sleep, and if the task isn't
blocked on a PI mutex (I think).

If I try the following experiment

 static inline void sched_submit_work(struct task_struct *tsk)
 {
+   if (tsk->state && tsk->flags & PF_WQ_WORKER) {
+ wq_worker_sleeping(tsk);
+ return;
+   }

and then remove the call later in the function, I am able to pass my test.

Unfortunately, I then get a recursive pool spinlock BUG_ON after a
while (as I would expect), and it all blows up.

I'm not sure where to go from there.  Any changes to the workpool to
try to fix that will be hard, or could affect latency significantly.

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

linux-next: bad commits in the ext4 tree

[Stephen Rothwell]

Hi Ted,

I noticed commit 14b02deff1ae ("[regression] fix 32-bit breakage in
block device read(2)") in the ext4 tree today.  This commit is commited
by you, but has not Signed-off-by from you ... it is also in Linus'
tree today.

Commit e43bb4e612b4 ("ext4: decrement free clusters/inodes
counters when block group declared bad") also has no S-o-b from you.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0

[Stephen Boyd]

On 06/26/14 03:52, Viresh Kumar wrote:
> On 26 June 2014 00:32, Stephen Boyd  wrote:
>> I don't think this driver should be using regulator_get_optional() (Mark
>> B. please correct me if I'm wrong). I doubt a supply is actually
>> optional for CPUs, just some DTs aren't specifying them. In those cases,
>> the regulator core will insert a dummy supply and the code will work
>> without having to check for probe defer and error pointers.
> Hi Stephen,
>
> Thanks for your comments.
>
> Leaving the above one, I have tried to fix all you mentioned. And it surely
> looks much better now.
>
> I would like to wait for a day or two before sending V2, as people might
> be reviewing it and the above issue is still wide open..
>
> But in case you wanna test it (completely changed I must say, but
> for good), its here:
>
> git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v2

I gave it a spin. It looks mostly good except for the infinite loop:

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index b7ee67c4d1c0..6744321ae33d 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -138,8 +138,10 @@ try_again:
}
 
/* Try with "cpu-supply" */
-   if (reg == reg_cpu0)
+   if (reg == reg_cpu0) {
+   reg = reg_cpu;
goto try_again;
+   }
 
dev_warn(cpu_dev, "failed to get cpu%d regulator: %ld\n",
 cpu, PTR_ERR(cpu_reg));

and I think we just want reg_cpu to be "cpu", not "cpu-supply" because I
think the regulator core adds in the "-supply" part already.

After fixing that I can get cpufreq going. I'm currently working on
populating the OPPs at runtime without relying on DT. So eventually I'll
need this patch:

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index b7ee67c4d1c0..6744321ae33d 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -239,11 +241,6 @@ static int cpu0_cpufreq_init(struct cpufreq_policy *policy)
}
 
ret = of_init_opp_table(cpu_dev);
-   if (ret) {
-   dev_err(cpu_dev, "failed to init OPP table: %d\n", ret);
-   goto out_put_node;
-   }
-
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table);
if (ret) {
dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);

which I hope is ok.

Finally, checking for equivalent pointers from clk_get() will work now,
but it isn't future-proof if/when the clock framework starts returning
dynamically allocated clock pointers for each clk_get() invocation.
Maybe we need a function in the common clock framework that tells us if
the clocks are the same either via DT or by taking two clock pointers?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ibmvfc: fix little endian issues

[Tyrel Datwyler]

Added big endian annotations to relevant data structure fields, and necessary
byte swappings to support little endian builds.

Signed-off-by: Brian King 
Signed-off-by: Tyrel Datwyler 
---
 drivers/scsi/ibmvscsi/ibmvfc.c | 473 +
 drivers/scsi/ibmvscsi/ibmvfc.h | 268 +++
 2 files changed, 374 insertions(+), 367 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 8dd4768..aaee066 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -166,13 +166,13 @@ static void ibmvfc_trc_start(struct ibmvfc_event *evt)
switch (entry->fmt) {
case IBMVFC_CMD_FORMAT:
entry->op_code = vfc_cmd->iu.cdb[0];
-   entry->scsi_id = vfc_cmd->tgt_scsi_id;
+   entry->scsi_id = be64_to_cpu(vfc_cmd->tgt_scsi_id);
entry->lun = scsilun_to_int(_cmd->iu.lun);
entry->tmf_flags = vfc_cmd->iu.tmf_flags;
-   entry->u.start.xfer_len = vfc_cmd->iu.xfer_len;
+   entry->u.start.xfer_len = be32_to_cpu(vfc_cmd->iu.xfer_len);
break;
case IBMVFC_MAD_FORMAT:
-   entry->op_code = mad->opcode;
+   entry->op_code = be32_to_cpu(mad->opcode);
break;
default:
break;
@@ -199,18 +199,18 @@ static void ibmvfc_trc_end(struct ibmvfc_event *evt)
switch (entry->fmt) {
case IBMVFC_CMD_FORMAT:
entry->op_code = vfc_cmd->iu.cdb[0];
-   entry->scsi_id = vfc_cmd->tgt_scsi_id;
+   entry->scsi_id = be64_to_cpu(vfc_cmd->tgt_scsi_id);
entry->lun = scsilun_to_int(_cmd->iu.lun);
entry->tmf_flags = vfc_cmd->iu.tmf_flags;
-   entry->u.end.status = vfc_cmd->status;
-   entry->u.end.error = vfc_cmd->error;
+   entry->u.end.status = be16_to_cpu(vfc_cmd->status);
+   entry->u.end.error = be16_to_cpu(vfc_cmd->error);
entry->u.end.fcp_rsp_flags = vfc_cmd->rsp.flags;
entry->u.end.rsp_code = vfc_cmd->rsp.data.info.rsp_code;
entry->u.end.scsi_status = vfc_cmd->rsp.scsi_status;
break;
case IBMVFC_MAD_FORMAT:
-   entry->op_code = mad->opcode;
-   entry->u.end.status = mad->status;
+   entry->op_code = be32_to_cpu(mad->opcode);
+   entry->u.end.status = be16_to_cpu(mad->status);
break;
default:
break;
@@ -270,14 +270,14 @@ static int ibmvfc_get_err_result(struct ibmvfc_cmd 
*vfc_cmd)
 {
int err;
struct ibmvfc_fcp_rsp *rsp = _cmd->rsp;
-   int fc_rsp_len = rsp->fcp_rsp_len;
+   int fc_rsp_len = be32_to_cpu(rsp->fcp_rsp_len);
 
if ((rsp->flags & FCP_RSP_LEN_VALID) &&
((fc_rsp_len && fc_rsp_len != 4 && fc_rsp_len != 8) ||
 rsp->data.info.rsp_code))
return DID_ERROR << 16;
 
-   err = ibmvfc_get_err_index(vfc_cmd->status, vfc_cmd->error);
+   err = ibmvfc_get_err_index(be16_to_cpu(vfc_cmd->status), 
be16_to_cpu(vfc_cmd->error));
if (err >= 0)
return rsp->scsi_status | (cmd_status[err].result << 16);
return rsp->scsi_status | (DID_ERROR << 16);
@@ -807,7 +807,7 @@ static void ibmvfc_fail_request(struct ibmvfc_event *evt, 
int error_code)
evt->cmnd->result = (error_code << 16);
evt->done = ibmvfc_scsi_eh_done;
} else
-   evt->xfer_iu->mad_common.status = IBMVFC_MAD_DRIVER_FAILED;
+   evt->xfer_iu->mad_common.status = 
cpu_to_be16(IBMVFC_MAD_DRIVER_FAILED);
 
list_del(>queue);
del_timer(>timer);
@@ -955,7 +955,7 @@ static void ibmvfc_get_host_speed(struct Scsi_Host *shost)
 
spin_lock_irqsave(shost->host_lock, flags);
if (vhost->state == IBMVFC_ACTIVE) {
-   switch (vhost->login_buf->resp.link_speed / 100) {
+   switch (be64_to_cpu(vhost->login_buf->resp.link_speed) / 100) {
case 1:
fc_host_speed(shost) = FC_PORTSPEED_1GBIT;
break;
@@ -976,7 +976,7 @@ static void ibmvfc_get_host_speed(struct Scsi_Host *shost)
break;
default:
ibmvfc_log(vhost, 3, "Unknown port speed: %lld Gbit\n",
-  vhost->login_buf->resp.link_speed / 100);
+  
be64_to_cpu(vhost->login_buf->resp.link_speed) / 100);
fc_host_speed(shost) = FC_PORTSPEED_UNKNOWN;
break;
}
@@ -1171,21 +1171,21 @@ static void ibmvfc_set_login_info(struct ibmvfc_host 
*vhost)
 
memset(login_info, 0, sizeof(*login_info));
 
-   login_info->ostype = IBMVFC_OS_LINUX;
-   login_info->max_dma_len = IBMVFC_MAX_SECTORS << 9;
-   

Re: [PATCH 0/3] ARM: DTS: create common dtsi for Peach pit and pi boards

[Doug Anderson]

Naveen,

On Thu, Jun 26, 2014 at 9:38 AM, Naveen Krishna Ch
 wrote:
> Will wait for few more opinions and make a fragment instead of common dtsi.
> Thank you a lot for the information and the references.

Just in case you're waiting for my opinion, I'll say that I'm of the
opinion that fragments will work better.

-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] kthread: Fix the race condition when kthread is parked

[Thomas Gleixner]

On Thu, 26 Jun 2014, Subbaraman Narayanamurthy wrote:
> On 06/25/14 17:43, Thomas Gleixner wrote:
> > The kthread park/unpark logic has the following issue:
> > 
> > Task   CPU 0CPU 1
> > 
> > T1 unplug cpu1
> > kthread_park(T2)
> > set_bit(KTHREAD_SHOULD_PARK);
> >   wait_for_completion()
> > T2  parkme(X)
> >   __set_current_state(TASK_PARKED);
> >   while
> > (test_bit(KTHREAD_SHOULD_PARK)) {
> > if
> > (!test_and_set_bit(KTHREAD_IS_PARKED))
> >   complete();
> > schedule();
> > T1   plug cpu1
> > 
> > --> premature wakeup of T2, i.e. before unpark, so T2 gets scheduled on
> >  CPU 0

> I understood the explanation above. But still I don't understand how this
> premature wakeup of T2 is happening/possible?

Come on. You have a machine which reproduces the issue. So some
moderate tracing should tell you that ...

Without using my lost crystal ball, I bet that it's a premature per
cpu timer interrupt.

> Also, what will happen if the task state is not in TASK_PARKED when
> __kthread_unpark is called?  __kthread_bind will fail silently
> causing the same problem.

Right you are, but thinking more about it:

Nothing is supposed to wakeup a parked thread except the unpark
machinery. So the real question is: What causes the premature wakeup?

Darn, I should have thought about that before, but you tricked my
overloaded brain into believing that this is a real issue.

No, it's not.

The parked state is not any different from creating a new kthread,
advertise the thread to possible wakers and then do the bind.

So yes, the code is fine and the BUG_ON() is rightfully asserting
here.

> Thanks for the patch. I've tested (running hotplug tests) it for sometime and
> looks good so far. Can you please submit it?

So you have a legitimate question about the correctness of the patch
and then you ask me to apply it?

Again, we do not apply patches which "fix" an issue just because we do
not observe it anymore. We apply them when the problem at hand is
fully understood and the solution solves all aspects.

Thanks,

tglx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] block: flush queued bios when the process blocks

[Mikulas Patocka]

Hi Jens

Would you please consider applying this patch?

Regarding your idea about merging bio and request plugging - I think this 
could be done later when it is properly designed by Kent Overstreet or 
someone else.

We need this patch to fix the deadlock in dm snapshot.

Mikulas


-- Forwarded message --
Date: Tue, 27 May 2014 11:03:36 -0400 (EDT)
From: Mikulas Patocka 
To: Jens Axboe , Kent Overstreet 
Cc: linux-kernel@vger.kernel.org, dm-de...@redhat.com,
Alasdair G. Kergon , Mike Snitzer 
Subject: [PATCH] block: flush queued bios when the process blocks

The block layer uses per-process bio list to avoid recursion in
generic_make_request. When generic_make_request is called recursively, the
bio is added to current->bio_list and the function returns immediatelly.
The top-level instance of generic_make_requests takes bios from
current->bio_list and processes them.

This bio queuing can result in deadlocks. The following deadlock was
observed:

1) Process A sends one-page read bio to the dm-snapshot target. The bio
spans snapshot chunk boundary and so it is split to two bios by device
mapper.

2) Device mapper creates the first sub-bio and sends it to the snapshot
driver.

3) The function snapshot_map calls track_chunk (that allocates a structure
dm_snap_tracked_chunk and adds it to tracked_chunk_hash) and then it
remaps the bio to the underlying linear target and exits with
DM_MAPIO_REMAPPED.

4) The remapped bio is submitted with generic_make_request, but it isn't
processed - it is added to current->bio_list instead.

5) Meanwhile, process B executes pending_complete for the affected chunk,
it takes down_write(>lock) and then loops in
__check_for_conflicting_io, waiting for dm_snap_tracked_chunk created in
step 3) to be released.

6) Process A continues, it creates a new bio for the rest of the original
bio.

7) snapshot_map is called for this new bio, it waits on
down_write(>lock) that is held in step 5).

The resulting deadlock:
* bio added to current->bio_list at step 4) waits until the function in
  step 7) finishes
* the function in step 7) waits until s->lock held in step 5) is released
* the process in step 5) waits until the bio queued in step 4) finishes

The general problem is that queuing bios on current->bio_list introduces
additional lock dependencies. If a device mapper target sends a bio to
some block device, it assumes that the bio only takes locks of the target
block device or devices that are below the target device. However, if the
bio is added to queue on current->bio_list, it creates artifical locking
dependency on locks taken by other bios that are on current->bio_list. In
the above scenario, this artifical locking dependency results in
deadlock.

Kent Overstreet already created a workqueue for every bio set and there is
a code that tries to resolve some low-memory deadlocks by redirecting bios
queued on current->bio_list to the workqueue if the system is low on
memory. However, other deadlocks (as described above) may happen without
any low memory condition.

This patch generalizes Kent's concept, it redirects bios on
current->bio_list to the bio_set's workqueue on every schedule call.
Consequently, when the process blocks on a mutex, the bios queued on
current->bio_list are dispatched to independent workqueus and they can
complete without waiting for the mutex to be available.

Bios allocated with bio_kmalloc do not have bio_set, so they are not
redirected, however bio_kmalloc shouldn't be used by stacking drivers (it
is currently used by raid1.c and raid10.c, we need to change it to
bio_set).


Note to stable kernel maintainers: before backporting this patch, you also
need to backport df2cb6daa4cbc34406bc4b1ac9b9335df1083a72.

Signed-off-by: Mikulas Patocka 
Cc: sta...@vger.kernel.org

---
 fs/bio.c   |   84 ++---
 include/linux/blkdev.h |7 +++-
 kernel/sched/core.c|7 
 3 files changed, 37 insertions(+), 61 deletions(-)

Index: linux-3.15-rc5/fs/bio.c
===
--- linux-3.15-rc5.orig/fs/bio.c2014-05-26 19:02:47.0 +0200
+++ linux-3.15-rc5/fs/bio.c 2014-05-27 00:00:13.0 +0200
@@ -342,35 +342,34 @@ static void bio_alloc_rescue(struct work
}
 }
 
-static void punt_bios_to_rescuer(struct bio_set *bs)
+/**
+ * blk_flush_bio_list
+ *
+ * Pop bios queued on current->bio_list and submit each of them to
+ * their rescue workqueue.
+ *
+ * If the bio doesn't have a bio_set, we leave it on current->bio_list.
+ * However, stacking drivers should use bio_set, so this shouldn't be
+ * an issue.
+ */
+void blk_flush_bio_list(void)
 {
-   struct bio_list punt, nopunt;
struct bio *bio;
+   struct bio_list list = *current->bio_list;
+   bio_list_init(current->bio_list);
 
-   /*
-* In order to guarantee forward progress we must punt only bios that
-* were allocated from 

Re: [PATCH v8 4/4] printk: allow increasing the ring buffer depending on the number of CPUs

[Luis R. Rodriguez]

On Thu, Jun 26, 2014 at 4:20 PM, Andrew Morton
 wrote:
> On Fri, 27 Jun 2014 01:16:30 +0200 "Luis R. Rodriguez"  
> wrote:
>
>> > > Another note --  since this option depends on SMP and !BASE_SMALL 
>> > > technically
>> > > num_possible_cpus() won't ever return something smaller than or equal to 
>> > > 1
>> > > but because of the default values chosen the -1 on the compuation does 
>> > > affect
>> > > whether or not this will trigger on > 64 CPUs or >= 64 CPUs, keeping the
>> > > -1 means we require > 64 CPUs.
>> >
>> > hm, that sounds like more complexity.
>> >
>> > > This all can be changed however we like but the language and explained 
>> > > logic
>> > > would just need to be changed.
>> >
>> > Let's start out simple.  What's wrong with doing
>> >
>> > log buf len = max(__LOG_BUF_LEN, nr_possible_cpus * per-cpu log buf 
>> > len)
>>
>> Sure, you already took in the patch series though so how would you like to
>> handle a respin, you just drop the last patch and we respin it?
>
> A fresh patch would suit.  That's if you think it is a reasonable
> approach - you've thought about this stuff more than I have!

The way its implemented now makes more technical sense, in short it
assumes the first boot (and CPU) gets the full default kernel ring
buffer size, the extra size is for the gibberish that each extra CPU
is expected to spew out in the worst case. What you propose makes the
explanation simpler and easier to understand but sends the wrong
message about exactly how the growth of the kernel ring buffer is
expected scale with the addition of more CPUs.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arch/score/include/uapi/asm/ptrace.h: Remove the macros which not be used currently

[Chen Gang]

On 06/27/2014 05:56 AM, David Rientjes wrote:
> On Thu, 26 Jun 2014, Chen Gang wrote:
> 
>> 'COUNTER' and other same kind macros are too common to use, and easy to
>> get conflict with other modules.
>>
>> At present, they are not used, so it is OK to simply remove them. And the
>> related warning (allmodconfig with score):
>>
>> CC [M]  drivers/md/raid1.o
>>   In file included from drivers/md/raid1.c:42:0:
>>   drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined
>>#define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX)
>>^
>>   In file included from ./arch/score/include/asm/ptrace.h:4:0,
>>from include/linux/sched.h:31,
>>from include/linux/blkdev.h:4,
>>from drivers/md/raid1.c:36:
>>   ./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the location of 
>> the previous definition
>>#define COUNTER  38
>>
>>
>> Signed-off-by: Chen Gang 
> 
> Acked-by: David Rientjes 
> 

OK, thanks. And also thank all of you for your discussions.

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] CMA page migration failure due to buffers on bh_lru

[Gioh Kim]

2014-06-27 오전 12:57, Michal Nazarewicz 쓴 글:

On Tue, Jun 24 2014, Gioh Kim  wrote:

Hello,

I am trying to apply CMA feature for my platform.
My kernel version, 3.10.x, is not allocating memory from CMA area so that I 
applied
a Joonsoo Kim's patch (https://lkml.org/lkml/2014/5/28/64).
Now my platform can use CMA area effectively.

But I have many failures to allocate memory from CMA area.
I found the same situation to Laura Abbott's patch descrbing,
https://lkml.org/lkml/2012/8/31/313,
that releases buffer-heads attached at CPU's LRU list.

If Joonsoo's patch is applied and/or CMA feature is applied more and more,
buffer-heads problem is going to be serious definitely.

Please look into the Laura's patch again.
I think it must be applied with Joonsoo's patch.


Just to make sure I understood you correctly, you're saying Laura's
patch at  fixes your issue?



Yes, it is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v8 4/4] printk: allow increasing the ring buffer depending on the number of CPUs

[Andrew Morton]

On Fri, 27 Jun 2014 01:16:30 +0200 "Luis R. Rodriguez"  wrote:

> > > Another note --  since this option depends on SMP and !BASE_SMALL 
> > > technically 
> > > num_possible_cpus() won't ever return something smaller than or equal to 1
> > > but because of the default values chosen the -1 on the compuation does 
> > > affect
> > > whether or not this will trigger on > 64 CPUs or >= 64 CPUs, keeping the
> > > -1 means we require > 64 CPUs.
> > 
> > hm, that sounds like more complexity.
> > 
> > > This all can be changed however we like but the language and explained 
> > > logic
> > > would just need to be changed.
> > 
> > Let's start out simple.  What's wrong with doing
> > 
> > log buf len = max(__LOG_BUF_LEN, nr_possible_cpus * per-cpu log buf len)
> 
> Sure, you already took in the patch series though so how would you like to
> handle a respin, you just drop the last patch and we respin it?

A fresh patch would suit.  That's if you think it is a reasonable 
approach - you've thought about this stuff more than I have!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/