Re: [PATCH] sched/numa: Restore sched feature NUMA to its earlier avatar.

[Srikar Dronamraju]

> So I find the patch, the description and the comments in the code conflicting 
> and 
> confusing.
> 
> The patch does this:
> 
> @@ -5676,10 +5676,10 @@ static int migrate_degrades_locality(struct 
> task_struct *p, struct lb_env *env)
> unsigned long src_faults, dst_faults;
> int src_nid, dst_nid;
> 
> -   if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
> +   if (!sched_feat(NUMA) || !sched_feat(NUMA_FAVOUR_HIGHER))
> return -1;
> 
> -   if (!sched_feat(NUMA))
> +   if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
> return -1;
> 
> src_nid = cpu_to_node(env->src_cpu);
> 
> 
> while the default for 'NUMA' is 0, 'NUMA_FAVOUR_HIGHER' is 1.
> 
> Which in itself is confusing: WTH do we have a generic switch called 'NUMA' 
> and 
> then have it disabled?

NUMA feature gets enabled on multi-node boxes because of

start_kernel() -> numa_policy_init() -> check_numabalancing_enable() ->
 set_numabalancing_state() -> sched_feat_set("NUMA");

> 
> Secondly, and more importantly, this patch is equivalent to adding this (for 
> the 
> default case):
> 
>   return -1;

This is true on only UMA box. On a numa box, the NUMA feature would be
enabled, so it wouldnt return -1 by default.

> 
> i.e. it's in essence a revert of 8a9e62a!
> 

While 8a9e62a did miss the part where we would enable NUMA on numa
boxes, this commit doesnt completely revert 8a9e62a.

> And it provides no explanation whatsoever. Why did we do the original change 
> (8a9e62a) which was well argued but apparently broken in some fashion, and 
> why do 
> we want to change it back now?

The original change "8a9e62a" gives preference to numa hotness compared
to cache hotness. The rational being, for numa workloads tasks are
better of looking at numa convergence than be spread based on cache
hotness.  migrate_swap/migrate_task_to already move tasks without
bothering about cache hotness so that convergence is achieved.

> 
> I.e. this patch sucks on multiple grounds, and 8a9e62a probably sucks as 
> well. And 
> you added a Reviewed-by while you should have noticed at least 2-3 flaws in 
> the 
> patch and its approach. Not good.
> 

-- 
Thanks and Regards
Srikar Dronamraju

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

[RESEND PATCH-v2] rtc: 88pm80x: add device tree support

[Vaibhav Hiremath]

Along with DT support, this patch also cleans up the unnecessary
code around 'rtc_wakeup' initialization.

Signed-off-by: Chao Xie 
Signed-off-by: Vaibhav Hiremath 
---
 drivers/rtc/rtc-88pm80x.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
index 7df0579..8f66519 100644
--- a/drivers/rtc/rtc-88pm80x.c
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -251,17 +251,26 @@ static SIMPLE_DEV_PM_OPS(pm80x_rtc_pm_ops, 
pm80x_rtc_suspend, pm80x_rtc_resume);
 static int pm80x_rtc_probe(struct platform_device *pdev)
 {
struct pm80x_chip *chip = dev_get_drvdata(pdev->dev.parent);
-   struct pm80x_platform_data *pm80x_pdata =
-   dev_get_platdata(pdev->dev.parent);
-   struct pm80x_rtc_pdata *pdata = NULL;
+   struct pm80x_rtc_pdata *pdata = dev_get_platdata(&pdev->dev);
struct pm80x_rtc_info *info;
+   struct device_node *node = pdev->dev.of_node;
struct rtc_time tm;
unsigned long ticks = 0;
int ret;
 
-   pdata = dev_get_platdata(&pdev->dev);
-   if (pdata == NULL)
-   dev_warn(&pdev->dev, "No platform data!\n");
+   if (!pdata && !node) {
+   dev_err(&pdev->dev,
+   "pm80x-rtc requires platform data or of_node\n");
+   return -EINVAL;
+   }
+
+   if (!pdata) {
+   pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   dev_err(&pdev->dev, "failed to allocate memory\n");
+   return -ENOMEM;
+   }
+   }
 
info =
devm_kzalloc(&pdev->dev, sizeof(struct pm80x_rtc_info), GFP_KERNEL);
@@ -327,11 +336,8 @@ static int pm80x_rtc_probe(struct platform_device *pdev)
regmap_update_bits(info->map, PM800_RTC_CONTROL, PM800_RTC1_USE_XO,
   PM800_RTC1_USE_XO);
 
-   if (pm80x_pdata) {
-   pdata = pm80x_pdata->rtc;
-   if (pdata)
-   info->rtc_dev->dev.platform_data = &pdata->rtc_wakeup;
-   }
+   /* remeber whether this power up is caused by PMIC RTC or not */
+   info->rtc_dev->dev.platform_data = &pdata->rtc_wakeup;
 
device_init_wakeup(&pdev->dev, 1);
 
-- 
1.9.1

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

Re: [PATCH] IOMMU-Tegra: gart: Delete an unnecessary check before the function call "vfree"

[SF Markus Elfring]

> From: Markus Elfring 
> Date: Thu, 5 Feb 2015 17:54:16 +0100
> 
> The vfree() function performs also input parameter validation.
> Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/iommu/tegra-gart.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
> index f722a0c..07a795a 100644
> --- a/drivers/iommu/tegra-gart.c
> +++ b/drivers/iommu/tegra-gart.c
> @@ -404,8 +404,7 @@ static int tegra_gart_remove(struct platform_device *pdev)
>   struct gart_device *gart = platform_get_drvdata(pdev);
>  
>   writel(0, gart->regs + GART_CONFIG);
> - if (gart->savedata)
> - vfree(gart->savedata);
> + vfree(gart->savedata);
>   gart_handle = NULL;
>   return 0;
>  }
> 

Would you like to integrate this update suggestion
into another source code repository?

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

Re: [PATCH v2 5/6] blk-mq: fix freeze queue race

[Ming Lei]

On Thu,  2 Jul 2015 23:29:56 +0900
Akinobu Mita  wrote:

> There are several race conditions while freezing queue.
> 
> When unfreezing queue, there is a small window between decrementing
> q->mq_freeze_depth to zero and percpu_ref_reinit() call with
> q->mq_usage_counter.  If the other calls blk_mq_freeze_queue_start()
> in the window, q->mq_freeze_depth is increased from zero to one and
> percpu_ref_kill() is called with q->mq_usage_counter which is already
> killed.  percpu refcount should be re-initialized before killed again.
> 
> Also, there is a race condition while switching to percpu mode.
> percpu_ref_switch_to_percpu() and percpu_ref_kill() must not be
> executed at the same time as the following scenario is possible:
> 
> 1. q->mq_usage_counter is initialized in atomic mode.
>(atomic counter: 1)
> 
> 2. After the disk registration, a process like systemd-udev starts
>accessing the disk, and successfully increases refcount successfully
>by percpu_ref_tryget_live() in blk_mq_queue_enter().
>(atomic counter: 2)
> 
> 3. In the final stage of initialization, q->mq_usage_counter is being
>switched to percpu mode by percpu_ref_switch_to_percpu() in
>blk_mq_finish_init().  But if CONFIG_PREEMPT_VOLUNTARY is enabled,
>the process is rescheduled in the middle of switching when calling
>wait_event() in __percpu_ref_switch_to_percpu().
>(atomic counter: 2)
> 
> 4. CPU hotplug handling for blk-mq calls percpu_ref_kill() to freeze
>request queue.  q->mq_usage_counter is decreased and marked as
>DEAD.  Wait until all requests have finished.
>(atomic counter: 1)
> 
> 5. The process rescheduled in the step 3. is resumed and finishes
>all remaining work in __percpu_ref_switch_to_percpu().
>A bias value is added to atomic counter of q->mq_usage_counter.
>(atomic counter: PERCPU_COUNT_BIAS + 1)
> 
> 6. A request issed in the step 2. is finished and q->mq_usage_counter
>is decreased by blk_mq_queue_exit().  q->mq_usage_counter is DEAD,
>so atomic counter is decreased and no release handler is called.
>(atomic counter: PERCPU_COUNT_BIAS)
> 
> 7. CPU hotplug handling in the step 4. will wait forever as
>q->mq_usage_counter will never be zero.
> 
> Also, percpu_ref_reinit() and percpu_ref_kill() must not be executed
> at the same time.  Because both functions could call
> __percpu_ref_switch_to_percpu() which adds the bias value and
> initialize percpu counter.
> 
> Fix those races by serializing with per-queue mutex.

This patch looks fine since at least changing DEAD state of percpu ref
state should have been synchronized by caller.

Also looks __percpu_ref_switch_to_percpu() need to check if the refcount
becomes dead after current switching, and seems something like following
is needed:

diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c
index 6111bcb..2532949 100644
--- a/lib/percpu-refcount.c
+++ b/lib/percpu-refcount.c
@@ -235,6 +235,10 @@ static void __percpu_ref_switch_to_percpu(struct 
percpu_ref *ref)
 
wait_event(percpu_ref_switch_waitq, !ref->confirm_switch);
 
+   /* dying or dead ref can't be switched to percpu mode w/o reinit */
+   if (ref->percpu_count_ptr & __PERCPU_REF_DEAD)
+   return;
+
atomic_long_add(PERCPU_COUNT_BIAS, &ref->count);
 
/*


> 
> Signed-off-by: Akinobu Mita 
> Cc: Jens Axboe 
> Cc: Ming Lei 
> ---
>  block/blk-core.c   | 1 +
>  block/blk-mq-sysfs.c   | 2 ++
>  block/blk-mq.c | 8 
>  include/linux/blkdev.h | 6 ++
>  4 files changed, 17 insertions(+)
> 
> diff --git a/block/blk-core.c b/block/blk-core.c
> index bbf67cd..f3c5ae2 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -687,6 +687,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t 
> gfp_mask, int node_id)
>   __set_bit(QUEUE_FLAG_BYPASS, &q->queue_flags);
>  
>   init_waitqueue_head(&q->mq_freeze_wq);
> + mutex_init(&q->mq_freeze_lock);
>   mutex_init(&q->mq_sysfs_lock);
>  
>   if (blkcg_init_queue(q))
> diff --git a/block/blk-mq-sysfs.c b/block/blk-mq-sysfs.c
> index 79a3e8d..8448513 100644
> --- a/block/blk-mq-sysfs.c
> +++ b/block/blk-mq-sysfs.c
> @@ -413,7 +413,9 @@ static void blk_mq_sysfs_init(struct request_queue *q)
>  /* see blk_register_queue() */
>  void blk_mq_finish_init(struct request_queue *q)
>  {
> + mutex_lock(&q->mq_freeze_lock);
>   percpu_ref_switch_to_percpu(&q->mq_usage_counter);
> + mutex_unlock(&q->mq_freeze_lock);
>  }
>  
>  int blk_mq_register_disk(struct gendisk *disk)
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index ad07373..f31de35 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -115,11 +115,15 @@ void blk_mq_freeze_queue_start(struct request_queue *q)
>  {
>   int freeze_depth;
>  
> + mutex_lock(&q->mq_freeze_lock);
> +
>   freeze_depth = atomic_inc_return(&q->mq_freeze_depth);
>   if (freeze_depth == 1) {
>   percpu_ref_kill(&q->mq_usage_counter);
>  

Re: [PATCH] cxl: Destroy cxl_adapter_idr on module_exit

[Johannes Thumshirn]

Ian Munsie  writes:

> Acked-by: Ian Munsie 
>
> We are probably also missing an idr_destroy(&afu->contexts_idr); in
> cxl_release_afu() as well if you wanted to send a patch for that.
>
> Cheers,
> -Ian
>

Correct, patch is going out today. Thanks for the hint.

-- 
Johannes Thumshirn   Storage
jthumsh...@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] uio: Destroy uio_idr on module exit

[Johannes Thumshirn]

Greg Kroah-Hartman  writes:

> On Wed, Jul 08, 2015 at 05:24:46PM +0200, Johannes Thumshirn wrote:
>> Destroy uio_idr on module exit, reclaiming the allocated memory.
>> 
>> This was detected by the following semantic patch (written by Luis Rodriguez
>> )
>> 
>> @ defines_module_init @
>> declarer name module_init, module_exit;
>> declarer name DEFINE_IDR;
>> identifier init;
>> @@
>> 
>> module_init(init);
>> 
>> @ defines_module_exit @
>> identifier exit;
>> @@
>> 
>> module_exit(exit);
>> 
>> @ declares_idr depends on defines_module_init && defines_module_exit @
>> identifier idr;
>> @@
>> 
>> DEFINE_IDR(idr);
>> 
>> @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
>> identifier declares_idr.idr, defines_module_exit.exit;
>> @@
>> 
>> exit(void)
>> {
>>  ...
>>  idr_destroy(&idr);
>>  ...
>> }
>> 
>> @ missing_module_idr_destroy depends on declares_idr && defines_module_exit 
>> && !on_exit_calls_destroy @
>> identifier declares_idr.idr, defines_module_exit.exit;
>> @@
>> 
>> exit(void)
>> {
>>  ...
>>  +idr_destroy(&idr);
>> }
>> 
>> 
>> 
>> Signed-off-by: Johannes Thumshirn 
>
> Nice work.  Shouldn't we do the same thing for ida_destroy() as well?  I
> see 4 USB drivers that need this same fix for that structure.
>

Can you tell me which? I've send overall 13 patches for this (no series
as get_maintainers.pl for the series spit out > 30 Recipients so I
refused to send spam).

Maybe/probably I forgot one (or two).

Johannes

-- 
Johannes Thumshirn   Storage
jthumsh...@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] KVM: x86: Add host physical address width capability

[Laszlo Ersek]

On 07/09/15 08:09, Paolo Bonzini wrote:
> 
> 
> On 09/07/2015 00:36, Bandan Das wrote:
>> Let userspace inquire the maximum physical address width
>> of the host processors; this can be used to identify maximum
>> memory that can be assigned to the guest.
>>
>> Reported-by: Laszlo Ersek 
>> Signed-off-by: Bandan Das 
>> ---
>>  arch/x86/kvm/x86.c   | 3 +++
>>  include/uapi/linux/kvm.h | 1 +
>>  2 files changed, 4 insertions(+)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index bbaf44e..97d6746 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -2683,6 +2683,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
>> ext)
>>  case KVM_CAP_NR_MEMSLOTS:
>>  r = KVM_USER_MEM_SLOTS;
>>  break;
>> +case KVM_CAP_PHY_ADDR_WIDTH:
>> +r = boot_cpu_data.x86_phys_bits;
>> +break;
> 
> Userspace can just use CPUID, can't it?

I believe KVM's cooperation is necessary, for the following reason:

The truncation only occurs when the guest-phys <-> host-phys translation
is done in hardware, *and* the phys bits of the host processor are
insufficient to represent the highest guest-phys address that the guest
will ever face.

The first condition (of course) means that the truncation depends on EPT
being enabled. (I didn't test on AMD so I don't know if RVI has the same
issue.) If EPT is disabled, either because the host processor lacks it,
or because the respective kvm_intel module parameter is set so, then the
issue cannot be experienced.

Therefore I believe a KVM patch is necessary.

However, this specific patch doesn't seem sufficient; it should also
consider whether EPT is enabled. (And the ioctl should be perhaps
renamed to reflect that -- what QEMU needs to know is not the raw
physical address width of the host processor, but whether that width
will cause EPT to silently truncate high guest-phys addresses.)

Thanks
Laszlo

> 
> Paolo
> 
>>  case KVM_CAP_PV_MMU:/* obsolete */
>>  r = 0;
>>  break;
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 716ad4a..e7949a1 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -817,6 +817,7 @@ struct kvm_ppc_smmu_info {
>>  #define KVM_CAP_DISABLE_QUIRKS 116
>>  #define KVM_CAP_X86_SMM 117
>>  #define KVM_CAP_MULTI_ADDRESS_SPACE 118
>> +#define KVM_CAP_PHY_ADDR_WIDTH 119
>>  
>>  #ifdef KVM_CAP_IRQ_ROUTING
>>  
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-sunxi] Re: [PATCH v10 4/5] crypto: Add Allwinner Security System crypto accelerator

[LABBE Corentin]

On Tue, Jul 07, 2015 at 09:49:36PM +0800, Herbert Xu wrote:
> On Mon, Jul 06, 2015 at 09:10:47PM +0200, LABBE Corentin wrote:
> >
> > +int sun4i_hash_init(struct ahash_request *areq)
> > +{
> > +   const char *hash_type;
> > +   struct sun4i_req_ctx *op = ahash_request_ctx(areq);
> > +   struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
> > +   struct ahash_alg *alg = __crypto_ahash_alg(tfm->base.__crt_alg);
> > +   struct sun4i_ss_alg_template *algt;
> > +   struct sun4i_ss_ctx *ss;
> > +
> > +   memset(op, 0, sizeof(struct sun4i_req_ctx));
> > +
> > +   algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash);
> > +   ss = algt->ss;
> > +   op->ss = algt->ss;
> > +
> > +   hash_type = crypto_tfm_alg_name(areq->base.tfm);
> > +
> > +   if (strcmp(hash_type, "sha1") == 0)
> > +   op->mode = SS_OP_SHA1;
> > +   else if (strcmp(hash_type, "md5") == 0)
> > +   op->mode = SS_OP_MD5;
> 
> Please store these modes in algt and then you wouldn't need to do
> the strcmp.
> 

thanks, that's better

> > +int sun4i_hash_import_md5(struct ahash_request *areq, const void *in)
> > +{
> > +   struct sun4i_req_ctx *op = ahash_request_ctx(areq);
> > +   const struct md5_state *ictx = in;
> > +   int i;
> 
> You need to initialise op->ss here.  Ditto for SHA.
> 

Ok

> > +   /* get the partial hash only if something was written */
> > +   if (op->mode == SS_OP_SHA1) {
> > +   for (i = 0; i < 5; i++)
> > +   op->hash[i] = readl(ss->base + SS_MD0 + i * 4);
> > +   } else {
> > +   for (i = 0; i < 4; i++)
> > +   op->hash[i] = readl(ss->base + SS_MD0 + i * 4);
> > +   }
> 
> You can avoid the op->mode check by storing the hash size in algt.
> 

It seems that I can use crypto_ahash_digestsize() that do the same thing.

> > +int sun4i_hash_finup(struct ahash_request *areq)
> > +{
> > +   int err;
> > +
> > +   err = sun4i_hash_update(areq);
> > +   if (err != 0)
> > +   return err;
> > +
> > +   return sun4i_hash_final(areq);
> 
> You can drop finup since the API provides a default finup that's
> exactly the same as this.  You only need to provide finup if it
> can optimise on this.
> 
> Ditto for digest.

If I remove digest(), loading the driver crash the kernel with:

Unable to handle kernel NULL pointer dereference at virtual address 
pgd = c0004000
[] *pgd=
Internal error: Oops: 8007 [#1] PREEMPT SMP ARM
CPU: 0 PID: 10120 Comm: cryptomgr_test Tainted: GE   4.2.0-rc1+ #78
LR is at crypto_ahash_op+0x30/0x68

For using the default one does I need to do something particular ?

Thanks

LABBE Corentin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] 3c59x: Fix shared IRQ handling

[David Miller]

From: Denys Vlasenko 
Date: Tue,  7 Jul 2015 20:48:55 +0200

> As its first order of business, boomerang_interrupt() checks whether
> the device really has any pending interrupts. If it does not,
> it does nothing and returns, but it still returns IRQ_HANDLED.
> 
> This is wrong: interrupt was not handled, IRQ handlers of other
> devices sharing this IRQ line need to be called.
> 
> vortex_interrupt() has it right: it returns IRQ_NONE in this case
> via IRQ_RETVAL(0).
> 
> Do the same in boomerang_interrupt().
> 
> Signed-off-by: Denys Vlasenko 

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

Re: [PATCH v2 2/2] arm: kernel: implement cpuidle_ops with psci backend

[Jisheng Zhang]

Dear Lorenzo,

On Wed, 8 Jul 2015 18:34:58 +0100
Lorenzo Pieralisi  wrote:

> On Wed, Jul 08, 2015 at 01:51:08PM +0100, Jisheng Zhang wrote:
> > This patch implements cpuidle_ops using psci. After this patch, we can
> > use cpuidle-arm.c with psci backend for both arm and arm64.
> > 
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  arch/arm/kernel/Makefile   |  1 +
> >  arch/arm/kernel/psci_cpuidle.c | 29 +
> >  2 files changed, 30 insertions(+)
> >  create mode 100644 arch/arm/kernel/psci_cpuidle.c
> > 
> > diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
> > index 3b995f5..96383d8 100644
> > --- a/arch/arm/kernel/Makefile
> > +++ b/arch/arm/kernel/Makefile
> > @@ -91,6 +91,7 @@ obj-$(CONFIG_ARM_VIRT_EXT)+= hyp-stub.o
> >  ifeq ($(CONFIG_ARM_PSCI),y)
> >  obj-y  += psci-call.o
> >  obj-$(CONFIG_SMP)  += psci_smp.o
> > +obj-$(CONFIG_CPU_IDLE) += psci_cpuidle.o
> >  endif
> >  
> >  extra-y := $(head-y) vmlinux.lds
> > diff --git a/arch/arm/kernel/psci_cpuidle.c b/arch/arm/kernel/psci_cpuidle.c
> > new file mode 100644
> > index 000..ae85d97
> > --- /dev/null
> > +++ b/arch/arm/kernel/psci_cpuidle.c
> > @@ -0,0 +1,29 @@
> > +/*
> > + * Copyright (C) 2015 Marvell Technology Group Ltd.
> > + * Author: Jisheng Zhang 
> > + *
> > + * 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +static int psci_cpuidle_suspend(int cpu, unsigned long arg)
> > +{
> > +   return cpu_psci_cpu_suspend(arg);
> > +}
> > +
> > +static int psci_cpuidle_init(struct device_node *node, int cpu)
> > +{
> > +   return cpu_psci_cpu_init_idle(cpu);
> > +}
> 
> It probably makes sense to change the prototypes now that there is
> just one cpuidle ops merged for arm, better now than later.

Good idea. I will do as you suggested.

Thanks a lot,
Jisheng

> 
> I am not too fussed about leaving these shims, but I think this can
> save us some time in the future.
> 
> Daniel what do you think ?
> 
> Lorenzo
> 
> > +
> > +static struct cpuidle_ops psci_cpuidle_ops __initdata = {
> > +   .suspend = psci_cpuidle_suspend,
> > +   .init = psci_cpuidle_init,
> > +};
> > +CPUIDLE_METHOD_OF_DECLARE(psci_cpuidle, "psci", &psci_cpuidle_ops);
> > -- 
> > 2.1.4
> > 

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

Re: [PATCH v4 1/3] dt-bindings: pwm: add MediaTek display PWM bindings

[YH Huang]

On Thu, 2015-07-09 at 12:47 +0800, Daniel Kurtz wrote:
> On Thu, Jul 9, 2015 at 10:45 AM, YH Huang  wrote:
> >
> > On Wed, 2015-07-08 at 20:11 +0800, Daniel Kurtz wrote:
> > > On Mon, Jul 6, 2015 at 9:29 PM, YH Huang  wrote:
> > > > Document the device-tree binding of MediatTek display PWM.
> > > > The PWM has one channel to control the backlight brightness for display.
> > > > It supports MT8173 and MT6595.
> > > >
> > > > Signed-off-by: YH Huang 
> > > > ---
> > > >  .../devicetree/bindings/pwm/pwm-mtk-disp.txt   | 24 
> > > > ++
> > > >  1 file changed, 24 insertions(+)
> > > >  create mode 100644 
> > > > Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt 
> > > > b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > > new file mode 100644
> > > > index 000..757b974
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > > @@ -0,0 +1,24 @@
> > > > +MediaTek display PWM controller
> > > > +
> > > > +Required properties:
> > > > + - compatible: should be "mediatek,-disp-pwm"
> > > > +   - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> > > > +   - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> > > > + - reg: physical base address and length of the controller's registers
> > > > + - #pwm-cells: must be 2. See pwm.txt in this directory for a 
> > > > description of
> > > > +   the cell format
> > > > + - clocks: phandle and clock specifier of the PWM reference clock
> > > > + - clock-names: must contain the following
> > > > +   - "main": clock used to generate PWM signals
> > > > +   - "mm": sync signals from the modules of mmsys

- pinctrl-names: Must contain a "default" entry.
- pinctrl-0: One property must exist for each entry in pinctrl-names.
  See pinctrl/pinctrl-bindings.txt for details of the property values.

> > > > +
> > > > +Example:
> > > > +   pwm0: pwm@1401e000 {
> > > > +   compatible = "mediatek,mt8173-disp-pwm",
> > > > +"mediatek,mt6595-disp-pwm";
> > > > +   reg = <0 0x1401e000 0 0x1000>;
> > > > +   #pwm-cells = <2>;
> > > > +   clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> > > > +<&mmsys CLK_MM_DISP_PWM0MM>;
> > > > +   clock-names = "main", "mm";

pio: pinctrl@10005000 {
...

   disp_pwm0_pins: disp_pwm0_pins {
pins1 {
pinmux = ;
bias-pull-up;
};
   };

...
}

pwm0: pwm@1401e000 {
compatible = "mediatek,mt8173-disp-pwm";
reg = <0 0x1401e000 0 0x1000>;
#pwm-cells = <2>;
clocks = <&mmsys CLK_MM_DISP_PWM0MM>,
 <&mmsys CLK_MM_DISP_PWM026M>;
clock-names = "mm", "main";
pinctrl-names = "default";
pinctrl-0 = <&disp_pwm0_pins>;
status = "disabled";
};

So should I change dtsi like this?

Regards,
YH Huang

> > >
> > > Should we include the pinctrl settings here to enable the PWM output?
> > >
> >
> > Since we use pwm-backlight driver to control backlight, we should enable
> > PWM output in the backlight node.
> >
> > Ref:
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> >
> 
> The pwm-backlight binding specifies which pwm the backlight driver
> should use, and how to use it.
> 
> I believe actually configuring the output pin for the pwm via pinctl
> belongs to the pwm binding.
> 
> Regards,
> 0Dan
> 
> >
> > Regards,
> > YH Huang
> >


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] regulator: pwm-regulator: Introduce continuous-mode

[Boris Brezillon]

Hi Lee,

I'm interested in this feature (so as Doug is), could you add us in Cc
of your next submission ?

On Tue,  7 Jul 2015 16:06:44 +0100
Lee Jones  wrote:

> This patch-set has been rebased on to topic/pwm.
>   
> Continuous mode uses the PWM regulator's maximum and minimum supplied
> voltages specified in the regulator-{min,max}-microvolt properties to
> calculate appropriate duty-cycle values.  This allows for a much more
> fine grained solution when compared with voltage-table mode, which
> this driver already supports.  This solution does make an assumption
> that a %50 duty-cycle value will cause the regulator voltage to run
> at half way between the supplied max_uV and min_uV values.

Well, I'm not sure this assumption works for all pwm driven regulators.
What if your regulator does not react linearly to the PWM duty-cycle
config ?

How about addressing that by using all the entries of the
voltage<->duty table association and doing the linear interpolation
between the provided points instead of doing it on the min -> max
range ?

Best Regards,

Boris

> 
> Lee Jones (9):
>   ARM: multi_v7_defconfig: Enable ST's PWM driver
>   ARM: multi_v7_defconfig: Enable ST's Power Reset driver
>   ARM: multi_v7_defconfig: Enable support for PWM Regulators
>   ARM: STi: STiH407: Move PWM nodes STiH407 => STiH407-family
>   ARM: STi: STiH407: Add PWM Regulator node
>   regulator: pwm-regulator: Re-write bindings
>   regulator: pwm-regulator: Add support for continuous-voltage
>   regulator: pwm-regulator: Simplify voltage to duty-cycle call
>   regulator: pwm-regulator: Don't assign structure attributes right away
> 
>  .../bindings/regulator/pwm-regulator.txt   |  68 ++---
>  arch/arm/boot/dts/stih407-family.dtsi  |  41 
>  arch/arm/boot/dts/stih407.dtsi |  28 --
>  arch/arm/configs/multi_v7_defconfig|   3 +
>  drivers/regulator/pwm-regulator.c  | 109 
> ++---
>  5 files changed, 198 insertions(+), 51 deletions(-)
> 



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

Re: [PATCH] sched/numa: Restore sched feature NUMA to its earlier avatar.

[Ingo Molnar]

* Rik van Riel  wrote:

> On 07/08/2015 09:56 AM, Ingo Molnar wrote:
> > 
> > * Srikar Dronamraju  wrote:
> > 
> >> In commit:8a9e62a "sched/numa: Prefer NUMA hotness over cache hotness"
> >> sched feature NUMA was always set to true. However this sched feature was
> >> suppose to be enabled on NUMA boxes only thro set_numabalancing_state().
> >>
> >> To get back to the above behaviour, bring back NUMA_FAVOUR_HIGHER feature.
> > 
> > Three typos and a non-standard commit ID reference.
> > 
> >>  /*
> >> + * NUMA_FAVOUR_HIGHER will favor moving tasks towards nodes where a
> >> + * higher number of hinting faults are recorded during active load
> >> + * balancing. It will resist moving tasks towards nodes where a lower
> >> + * number of hinting faults have been recorded.
> >>   */
> >> -SCHED_FEAT(NUMA,  true)
> >> +SCHED_FEAT(NUMA_FAVOUR_HIGHER, true)
> >>  #endif
> >>
> > 
> > So the comment spells 'favor' American, the constant you introduce is 
> > British 
> > spelling via 'FAVOUR'? Please use it consistently!
> > 
> > Also, this name is totally non-intuitive.
> > 
> > Make it something like NUMA_FAVOR_BUSY_NODES or so?
> 
> It is not about relocating tasks to busier nodes. The scheduler still
> moves tasks from busier nodes to idler nodes.
> 
> This code makes the scheduler more prone to move tasks from nodes where
> they have fewer NUMA faults, to nodes where they have more.
> 
> Not sure what a good name would be to describe that...

So I find the patch, the description and the comments in the code conflicting 
and 
confusing.

The patch does this:

@@ -5676,10 +5676,10 @@ static int migrate_degrades_locality(struct task_struct 
*p, struct lb_env *env)
unsigned long src_faults, dst_faults;
int src_nid, dst_nid;

-   if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
+   if (!sched_feat(NUMA) || !sched_feat(NUMA_FAVOUR_HIGHER))
return -1;

-   if (!sched_feat(NUMA))
+   if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
return -1;

src_nid = cpu_to_node(env->src_cpu);


while the default for 'NUMA' is 0, 'NUMA_FAVOUR_HIGHER' is 1.

Which in itself is confusing: WTH do we have a generic switch called 'NUMA' and 
then have it disabled?

Secondly, and more importantly, this patch is equivalent to adding this (for 
the 
default case):

return -1;

i.e. it's in essence a revert of 8a9e62a!

And it provides no explanation whatsoever. Why did we do the original change 
(8a9e62a) which was well argued but apparently broken in some fashion, and why 
do 
we want to change it back now?

I.e. this patch sucks on multiple grounds, and 8a9e62a probably sucks as well. 
And 
you added a Reviewed-by while you should have noticed at least 2-3 flaws in the 
patch and its approach. Not good.

Thanks,

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

Re: [PATCH v2] Staging: android: ion: fixed a blank line after declarations coding style issue

[Sudip Mukherjee]

On Thu, Jul 09, 2015 at 11:39:11AM +0530, Ronit Halder wrote:
> Fixed a coding style issue.
> 
> Signed-off-by: Ronit Halder 
Greg has commented in your v1 that it is a false positive. See that:
#define DEFINE_DMA_BUF_EXPORT_INFO(a)   \
struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }

so blank line will not be required here.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND 2/6] drm/exynos/mixer: fix interrupt clearing

[Andrzej Hajda]

The driver used incorrect flags to clear interrupt status.
The patch fixes it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index cae98db..0686484 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -718,6 +718,9 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
 
/* handling VSYNC */
if (val & MXR_INT_STATUS_VSYNC) {
+   /* vsync interrupt use different bit for read and clear */
+   val |= MXR_INT_CLEAR_VSYNC;
+
/* interlace scan need to check shadow register */
if (ctx->interlace) {
base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
@@ -743,11 +746,6 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
 
 out:
/* clear interrupts */
-   if (~val & MXR_INT_EN_VSYNC) {
-   /* vsync interrupt use different bit for read and clear */
-   val &= ~MXR_INT_EN_VSYNC;
-   val |= MXR_INT_CLEAR_VSYNC;
-   }
mixer_reg_write(res, MXR_INT_STATUS, val);
 
spin_unlock(&res->reg_slock);
-- 
1.9.1

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

[PATCH RESEND 6/6] drm/exynos/mixer: replace MXR_INT_EN register cache with flag

[Andrzej Hajda]

Driver uses only VSYNC interrupts, so we need to cache VSYNC bit state only.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 453b6bb..7e57409 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -71,6 +71,7 @@ enum mixer_version_id {
 
 enum mixer_flag_bits {
MXR_BIT_POWERED,
+   MXR_BIT_VSYNC,
 };
 
 struct mixer_context {
@@ -84,7 +85,6 @@ struct mixer_context {
boolinterlace;
boolvp_enabled;
boolhas_sclk;
-   u32 int_en;
 
struct mixer_resources  mixer_res;
enum mixer_version_id   mxr_ver;
@@ -902,10 +902,9 @@ static int mixer_enable_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
struct mixer_resources *res = &mixer_ctx->mixer_res;
 
-   if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags)) {
-   mixer_ctx->int_en |= MXR_INT_EN_VSYNC;
+   __set_bit(MXR_BIT_VSYNC, &mixer_ctx->flags);
+   if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags))
return 0;
-   }
 
/* enable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
@@ -919,10 +918,10 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
struct mixer_resources *res = &mixer_ctx->mixer_res;
 
-   if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags)) {
-   mixer_ctx->int_en &= MXR_INT_EN_VSYNC;
+   __clear_bit(MXR_BIT_VSYNC, &mixer_ctx->flags);
+
+   if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags))
return;
-   }
 
/* disable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
@@ -1035,9 +1034,10 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
 
mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);
 
-   if (ctx->int_en & MXR_INT_EN_VSYNC)
+   if (test_bit(MXR_BIT_VSYNC, &ctx->flags)) {
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, 
MXR_INT_CLEAR_VSYNC);
-   mixer_reg_write(res, MXR_INT_EN, ctx->int_en);
+   mixer_reg_writemask(res, MXR_INT_EN, ~0, MXR_INT_EN_VSYNC);
+   }
mixer_win_reset(ctx);
 }
 
@@ -1056,8 +1056,6 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
for (i = 0; i < MIXER_WIN_NR; i++)
mixer_win_disable(crtc, i);
 
-   ctx->int_en = mixer_reg_read(res, MXR_INT_EN);
-
clear_bit(MXR_BIT_POWERED, &ctx->flags);
 
clk_disable_unprepare(res->hdmi);
-- 
1.9.1

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

[PATCH RESEND 5/6] drm/exynos/mixer: simplify poweron flag

[Andrzej Hajda]

The driver uses bool protected by mutex to track power state.
The patch replaces this combo with single bit and atomic bitops.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 52 ++-
 1 file changed, 14 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 53bcb70..453b6bb 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -69,6 +69,10 @@ enum mixer_version_id {
MXR_VER_128_0_0_184,
 };
 
+enum mixer_flag_bits {
+   MXR_BIT_POWERED,
+};
+
 struct mixer_context {
struct platform_device *pdev;
struct device   *dev;
@@ -76,13 +80,12 @@ struct mixer_context {
struct exynos_drm_crtc  *crtc;
struct exynos_drm_plane planes[MIXER_WIN_NR];
int pipe;
+   unsigned long   flags;
boolinterlace;
-   boolpowered;
boolvp_enabled;
boolhas_sclk;
u32 int_en;
 
-   struct mutexmixer_mutex;
struct mixer_resources  mixer_res;
enum mixer_version_id   mxr_ver;
wait_queue_head_t   wait_vsync_queue;
@@ -899,7 +902,7 @@ static int mixer_enable_vblank(struct exynos_drm_crtc *crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
struct mixer_resources *res = &mixer_ctx->mixer_res;
 
-   if (!mixer_ctx->powered) {
+   if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags)) {
mixer_ctx->int_en |= MXR_INT_EN_VSYNC;
return 0;
}
@@ -916,7 +919,7 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
struct mixer_resources *res = &mixer_ctx->mixer_res;
 
-   if (!mixer_ctx->powered) {
+   if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags)) {
mixer_ctx->int_en &= MXR_INT_EN_VSYNC;
return;
}
@@ -932,12 +935,8 @@ static void mixer_win_commit(struct exynos_drm_crtc *crtc, 
unsigned int win)
 
DRM_DEBUG_KMS("win: %d\n", win);
 
-   mutex_lock(&mixer_ctx->mixer_mutex);
-   if (!mixer_ctx->powered) {
-   mutex_unlock(&mixer_ctx->mixer_mutex);
+   if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags))
return;
-   }
-   mutex_unlock(&mixer_ctx->mixer_mutex);
 
if (win > 1 && mixer_ctx->vp_enabled)
vp_video_buffer(mixer_ctx, win);
@@ -953,12 +952,8 @@ static void mixer_win_disable(struct exynos_drm_crtc 
*crtc, unsigned int win)
 
DRM_DEBUG_KMS("win: %d\n", win);
 
-   mutex_lock(&mixer_ctx->mixer_mutex);
-   if (!mixer_ctx->powered) {
-   mutex_unlock(&mixer_ctx->mixer_mutex);
+   if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags))
return;
-   }
-   mutex_unlock(&mixer_ctx->mixer_mutex);
 
spin_lock_irqsave(&res->reg_slock, flags);
mixer_vsync_set_update(mixer_ctx, false);
@@ -974,12 +969,8 @@ static void mixer_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
int err;
 
-   mutex_lock(&mixer_ctx->mixer_mutex);
-   if (!mixer_ctx->powered) {
-   mutex_unlock(&mixer_ctx->mixer_mutex);
+   if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags))
return;
-   }
-   mutex_unlock(&mixer_ctx->mixer_mutex);
 
err = drm_vblank_get(mixer_ctx->drm_dev, mixer_ctx->pipe);
if (err < 0) {
@@ -1007,13 +998,8 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
struct mixer_resources *res = &ctx->mixer_res;
int ret;
 
-   mutex_lock(&ctx->mixer_mutex);
-   if (ctx->powered) {
-   mutex_unlock(&ctx->mixer_mutex);
+   if (test_bit(MXR_BIT_POWERED, &ctx->flags))
return;
-   }
-
-   mutex_unlock(&ctx->mixer_mutex);
 
pm_runtime_get_sync(ctx->dev);
 
@@ -1045,9 +1031,7 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
}
}
 
-   mutex_lock(&ctx->mixer_mutex);
-   ctx->powered = true;
-   mutex_unlock(&ctx->mixer_mutex);
+   set_bit(MXR_BIT_POWERED, &ctx->flags);
 
mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);
 
@@ -1063,12 +1047,8 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
struct mixer_resources *res = &ctx->mixer_res;
int i;
 
-   mutex_lock(&ctx->mixer_mutex);
-   if (!ctx->powered) {
-   mutex_unlock(&ctx->mixer_mutex);
+   if (!test_bit(MXR_BIT_POWERED, &ctx->flags))
return;
-   }
-   mutex_unlock(&ctx->mixer_mutex);
 
mixer_stop(ctx);
mixer_regs_dump(ctx);
@@ -1078,9 +1058,7 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
 
ctx->

[PATCH RESEND 4/6] drm/exynos/mixer: always update INT_EN cache

[Andrzej Hajda]

INT_EN cache field was updated only by mixer_enable_vblank.
The patch adds update also by mixer_disable_vblank function.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index b338a10..53bcb70 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -916,6 +916,11 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
struct mixer_resources *res = &mixer_ctx->mixer_res;
 
+   if (!mixer_ctx->powered) {
+   mixer_ctx->int_en &= MXR_INT_EN_VSYNC;
+   return;
+   }
+
/* disable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
-- 
1.9.1

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

[PATCH RESEND 1/6] drm/exynos/hdmi: fix edid memory leak

[Andrzej Hajda]

edid returned by drm_get_edid should be freed.
The patch fixes it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 99e2864..4a00990 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1064,6 +1064,7 @@ static int hdmi_get_modes(struct drm_connector *connector)
 {
struct hdmi_context *hdata = ctx_from_connector(connector);
struct edid *edid;
+   int ret;
 
if (!hdata->ddc_adpt)
return -ENODEV;
@@ -1079,7 +1080,11 @@ static int hdmi_get_modes(struct drm_connector 
*connector)
 
drm_mode_connector_update_edid_property(connector, edid);
 
-   return drm_add_edid_modes(connector, edid);
+   ret = drm_add_edid_modes(connector, edid);
+
+   kfree(edid);
+
+   return ret;
 }
 
 static int hdmi_find_phy_conf(struct hdmi_context *hdata, u32 pixel_clock)
-- 
1.9.1

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

[PATCH RESEND 3/6] drm/exynos/mixer: correct vsync configuration sequence

[Andrzej Hajda]

Specification advises to clear vsync indicator before configuring vsync.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 0686484..b338a10 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -905,8 +905,8 @@ static int mixer_enable_vblank(struct exynos_drm_crtc *crtc)
}
 
/* enable vsync interrupt */
-   mixer_reg_writemask(res, MXR_INT_EN, MXR_INT_EN_VSYNC,
-   MXR_INT_EN_VSYNC);
+   mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
+   mixer_reg_writemask(res, MXR_INT_EN, ~0, MXR_INT_EN_VSYNC);
 
return 0;
 }
@@ -917,6 +917,7 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_resources *res = &mixer_ctx->mixer_res;
 
/* disable vsync interrupt */
+   mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
 }
 
@@ -1045,6 +1046,8 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
 
mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);
 
+   if (ctx->int_en & MXR_INT_EN_VSYNC)
+   mixer_reg_writemask(res, MXR_INT_STATUS, ~0, 
MXR_INT_CLEAR_VSYNC);
mixer_reg_write(res, MXR_INT_EN, ctx->int_en);
mixer_win_reset(ctx);
 }
-- 
1.9.1

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

[PATCH RESEND 0/6] drm/exynos: HDMI related fixes

[Andrzej Hajda]

Andrzej Hajda (6):
  drm/exynos/hdmi: fix edid memory leak
  drm/exynos/mixer: fix interrupt clearing
  drm/exynos/mixer: correct vsync configuration sequence
  drm/exynos/mixer: always update INT_EN cache
  drm/exynos/mixer: simplify poweron flag
  drm/exynos/mixer: replace MXR_INT_EN register cache with flag

 drivers/gpu/drm/exynos/exynos_hdmi.c  |  7 ++-
 drivers/gpu/drm/exynos/exynos_mixer.c | 80 +--
 2 files changed, 36 insertions(+), 51 deletions(-)

-- 
1.9.1

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

[PATCH REBASED RESEND] tty/early: make serial8250_early_{in,out} static again

[Vineet Gupta]

Commit ed71871bed719 ("tty/8250_early: Turn serial_in/serial_out into
weak symbols") made these routines weak to allow platform specific
Big endian override

However recent updates to core, specifically ebc5e20082 ("serial:
of_serial: Support big-endian register accesses") and 6e63be3fee14
("serial: earlycon: Add support for big-endian MMIO accesses") means
that round about way to overide the early serial accessors is no longer
needed.

Cc: 
Cc: 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Peter Hurley 
Cc: Rob Herring 
Cc: Kevin Cernekee 
Cc: Noam Camus 
Signed-off-by: Vineet Gupta 
---
 drivers/tty/serial/8250/8250_early.c | 4 ++--
 include/linux/serial_8250.h  | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_early.c 
b/drivers/tty/serial/8250/8250_early.c
index 771dda29a0f8..faed05f25bc2 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -35,7 +35,7 @@
 #include 
 #include 
 
-unsigned int __weak __init serial8250_early_in(struct uart_port *port, int 
offset)
+static unsigned int __init serial8250_early_in(struct uart_port *port, int 
offset)
 {
switch (port->iotype) {
case UPIO_MEM:
@@ -51,7 +51,7 @@ unsigned int __weak __init serial8250_early_in(struct 
uart_port *port, int offse
}
 }
 
-void __weak __init serial8250_early_out(struct uart_port *port, int offset, 
int value)
+static void __init serial8250_early_out(struct uart_port *port, int offset, 
int value)
 {
switch (port->iotype) {
case UPIO_MEM:
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index ba82c07feb95..9075712db8d8 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -136,8 +136,6 @@ void serial8250_resume_port(int line);
 
 extern int early_serial_setup(struct uart_port *port);
 
-extern unsigned int serial8250_early_in(struct uart_port *port, int offset);
-extern void serial8250_early_out(struct uart_port *port, int offset, int 
value);
 extern int early_serial8250_setup(struct earlycon_device *device,
 const char *options);
 extern void serial8250_do_set_termios(struct uart_port *port,
-- 
1.9.1

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

Re: [PATCH 0/1] Add support for esdhc0 on Vybrid.

[Stefan Agner]

On 2015-07-09 08:07, Holger Schurig wrote:
>> Cory Tusar (1):
>>   ARM: dts: vfxxx: Include support for esdhc0 functionality.
>>
>>  arch/arm/boot/dts/vfxxx.dtsi | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> --
>> 2.3.6
> 
> Your patch looks empty.

This is a cover letter which provides overview over a whole patchset.
The patch is a separate reply message of this mail (PATCH 1/1). 

@Cory
However, it is unusual to use a cover letter when there is only a single
patch. If you want to add additional comments which should not be part
of the commit message, you can edit the patch and insert text after the
three dashes, just before the diffstat. This text won't be part of the
commit when applied later.

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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?] Livelock in pick_next_task_fair() / idle_balance()

[Stefan Ekenberg]

Hi,

I tested the patch on a setup with 7 devices, all running the same troublesome 
use-case in parallel (same use-case as we used to produce the crash dumps). 
This use-case was previously able to reproduce the problem about 21 times 
during 24 hours. After including the patch the setup ran perfectly for 48 
hours. So to summarize, patch tested OK.

Tested-by: Stefan Ekenberg 

On Mon, Jul 06, 2015 at 12:11:51AM +0200, Yuyang Du wrote:
> On Fri, Jul 03, 2015 at 06:39:28PM +0200, Peter Zijlstra wrote:
> > On Thu, Jul 02, 2015 at 07:25:11AM +0800, Yuyang Du wrote:
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index 40a7fcb..f7cc1ef 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -5898,6 +5898,10 @@ static int detach_tasks(struct lb_env *env)
> > > return 0;
> > >
> > > while (!list_empty(tasks)) {
> > > +
> > > +   if (env->idle == CPU_NEWLY_IDLE && env->src_rq->nr_running <= 
> > > 1)
> >
> > Should we make that ->idle != CPU_NOT_IDLE ?
> 
> I think including CPU_IDLE is good.
> 
> --
> Subject: [PATCH] sched: Avoid pulling all tasks in idle balancing
> 
> In idle balancing where a CPU going idle pulls tasks from another CPU,
> a livelock may happen if the CPU pulls all tasks from another, makes
> it idle, and this iterates. So just avoid this.
> 
> Reported-by: Rabin Vincent 
> Signed-off-by: Yuyang Du 
> ---
>  kernel/sched/fair.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 40a7fcb..769d591 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5898,6 +5898,13 @@ static int detach_tasks(struct lb_env *env)
> return 0;
> 
> while (!list_empty(tasks)) {
> +   /*
> +* We don't want to steal all, otherwise we may be treated 
> likewise,
> +* which could at worst lead to a livelock crash.
> +*/
> +   if (env->idle != CPU_NOT_IDLE && env->src_rq->nr_running <= 1)
> +   break;
> +
> p = list_first_entry(tasks, struct task_struct, 
> se.group_node);
> 
> env->loop++;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] KVM: x86: Add host physical address width capability

[Paolo Bonzini]

On 09/07/2015 00:36, Bandan Das wrote:
> Let userspace inquire the maximum physical address width
> of the host processors; this can be used to identify maximum
> memory that can be assigned to the guest.
> 
> Reported-by: Laszlo Ersek 
> Signed-off-by: Bandan Das 
> ---
>  arch/x86/kvm/x86.c   | 3 +++
>  include/uapi/linux/kvm.h | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index bbaf44e..97d6746 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2683,6 +2683,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
> ext)
>   case KVM_CAP_NR_MEMSLOTS:
>   r = KVM_USER_MEM_SLOTS;
>   break;
> + case KVM_CAP_PHY_ADDR_WIDTH:
> + r = boot_cpu_data.x86_phys_bits;
> + break;

Userspace can just use CPUID, can't it?

Paolo

>   case KVM_CAP_PV_MMU:/* obsolete */
>   r = 0;
>   break;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 716ad4a..e7949a1 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -817,6 +817,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_DISABLE_QUIRKS 116
>  #define KVM_CAP_X86_SMM 117
>  #define KVM_CAP_MULTI_ADDRESS_SPACE 118
> +#define KVM_CAP_PHY_ADDR_WIDTH 119
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Staging: android: ion: fixed a blank line after declarations coding style issue

[Ronit Halder]

Fixed a coding style issue.

Signed-off-by: Ronit Halder 
---
 drivers/staging/android/ion/ion.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 6f48112..e44f5e6 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1106,6 +1106,7 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
*client,
struct ion_buffer *buffer;
struct dma_buf *dmabuf;
bool valid_handle;
+
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
 
mutex_lock(&client->lock);
-- 
1.9.1

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

[PATCH v2] HID: Wacom: Delete unnecessary checks before the function call "input_free_device"

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 9 Jul 2015 08:00:10 +0200

The input_free_device() function tests whether its argument is NULL and
then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/hid/wacom_sys.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 4c0ffca..936ad77 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1149,12 +1149,9 @@ static void wacom_free_inputs(struct wacom *wacom)
 {
struct wacom_wac *wacom_wac = &(wacom->wacom_wac);
 
-   if (wacom_wac->pen_input)
-   input_free_device(wacom_wac->pen_input);
-   if (wacom_wac->touch_input)
-   input_free_device(wacom_wac->touch_input);
-   if (wacom_wac->pad_input)
-   input_free_device(wacom_wac->pad_input);
+   input_free_device(wacom_wac->pen_input);
+   input_free_device(wacom_wac->touch_input);
+   input_free_device(wacom_wac->pad_input);
wacom_wac->pen_input = NULL;
wacom_wac->touch_input = NULL;
wacom_wac->pad_input = NULL;
-- 
2.4.5

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

Re: [PATCH 0/1] Add support for esdhc0 on Vybrid.

[Holger Schurig]

> Cory Tusar (1):
>   ARM: dts: vfxxx: Include support for esdhc0 functionality.
>
>  arch/arm/boot/dts/vfxxx.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
>
> --
> 2.3.6

Your patch looks empty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 36/36] PCI: Don't set flags to 0 when assign resource fail

[Wei Yang]

This one is on top of the last one ? or replace the last one?

On Wed, Jul 08, 2015 at 10:01:47PM -0700, Yinghai Lu wrote:
>On Wed, Jul 8, 2015 at 8:30 PM, Wei Yang  wrote:
>> Hi, Yinghai
>>
>> This patch may introduce some problem.
>>
>> On my P8 machine, after applying this patch, I see following error:
>>
>> [0.589948] pnv_ioda_setup_pe_seg: trigger IO SEG 0
>> [0.589992] pnv_ioda_setup_pe_seg: res[io  0x1000-0x3fff] 100
>>
>> The last 0x100 is the res->flags, which indicates the UNSET and DISABLED bit
>> is not set.
>
>Maybe we should introduce resource_disabled() for that.
>
>Please check if attached patch would fix the problem.
>
>Thanks
>
>Yinghai

>Subject: [PATCH] PCI: Introduce resource_disabled()
>
>so we can cover !flags and IORESOURCE_DISABLED both.
>
>Signed-off-by: Yinghai Lu 
>
>diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
>index 82f738e..91a7153 100644
>--- a/arch/alpha/kernel/pci.c
>+++ b/arch/alpha/kernel/pci.c
>@@ -282,7 +282,7 @@ pcibios_claim_one_bus(struct pci_bus *b)
>   for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>   struct resource *r = &dev->resource[i];
> 
>-  if (r->parent || !r->start || !r->flags)
>+  if (r->parent || !r->start || resource_disabled(r))
>   continue;
>   if (pci_has_flag(PCI_PROBE_ONLY) ||
>   (r->flags & IORESOURCE_PCI_FIXED)) {
>diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
>index 7cc3be9..cc293ea 100644
>--- a/arch/ia64/pci/pci.c
>+++ b/arch/ia64/pci/pci.c
>@@ -501,7 +501,7 @@ void pcibios_fixup_device_resources(struct pci_dev *dev)
>   for (idx = 0; idx < PCI_BRIDGE_RESOURCES; idx++) {
>   struct resource *r = &dev->resource[idx];
> 
>-  if (!r->flags || r->parent || !r->start)
>+  if (resource_disabled(r) || r->parent || !r->start)
>   continue;
> 
>   pci_claim_resource(dev, idx);
>@@ -519,7 +519,7 @@ static void pcibios_fixup_bridge_resources(struct pci_dev 
>*dev)
>   for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
>   struct resource *r = &dev->resource[idx];
> 
>-  if (!r->flags || r->parent || !r->start)
>+  if (resource_disabled(r) || r->parent || !r->start)
>   continue;
> 
>   pci_claim_bridge_resource(dev, idx);
>diff --git a/arch/microblaze/pci/pci-common.c 
>b/arch/microblaze/pci/pci-common.c
>index ae838ed..67848f8 100644
>--- a/arch/microblaze/pci/pci-common.c
>+++ b/arch/microblaze/pci/pci-common.c
>@@ -705,7 +705,7 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
>   }
>   for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
>   struct resource *res = dev->resource + i;
>-  if (!res->flags)
>+  if (resource_disabled(res))
>   continue;
>   if (res->start == 0) {
>   pr_debug("PCI:%s Resource %d %016llx-%016llx [%x]",
>@@ -806,7 +806,7 @@ static void pcibios_fixup_bridge(struct pci_bus *bus)
>   pci_bus_for_each_resource(bus, res, i) {
>   if (!res)
>   continue;
>-  if (!res->flags)
>+  if (resource_disabled(res))
>   continue;
>   if (i >= 3 && bus->self->transparent)
>   continue;
>@@ -993,7 +993,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus 
>*bus)
>pci_domain_nr(bus), bus->number);
> 
>   pci_bus_for_each_resource(bus, res, i) {
>-  if (!res || !res->flags
>+  if (!res || resource_disabled(res)
>   || res->start > res->end || res->parent)
>   continue;
>   if (bus->parent == NULL)
>@@ -1095,7 +1095,8 @@ static void __init pcibios_allocate_resources(int pass)
>   r = &dev->resource[idx];
>   if (r->parent)  /* Already allocated */
>   continue;
>-  if (!r->flags || (r->flags & IORESOURCE_UNSET))
>+  if (resource_disabled(r) ||
>+  (r->flags & IORESOURCE_UNSET))
>   continue;   /* Not assigned at all */
>   /* We only allocate ROMs on pass 1 just in case they
>* have been screwed up by firmware
>@@ -1226,7 +1227,7 @@ void pcibios_claim_one_bus(struct pci_bus *bus)
>   for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>   struct resource *r = &dev->resource[i];
> 
>-  if (r->parent || !r->start || !r->flags)
>+  if (r->parent || !r->start || resource_disabled(r))
>   continue;
> 
>   pr_debug("PCI: Claiming %s: ", pci_name(dev));
>@@ -1286,7 +1287,7 @@ static void pcib

Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state

[Shreyas B Prabhu]

On 07/09/2015 10:11 AM, Daniel Axtens wrote:
>> I recommend creating an alias or script that does:
>>
>> $ git log --pretty=fixes -n 1 $commit | xclip
>>
> 
> FWIW, having finally got around to doing this, I found I first needed
> the following snippet in ~/.gitconfig from
> https://www.kernel.org/doc/Documentation/SubmittingPatches
> 
> 
>   [core]
>   abbrev = 12
>   [pretty]
>   fixes = Fixes: %h (\"%s\")
> 
> Otherwise git doesn't know what the pretty format is.
>


Right, thanks for the pointer!

Thanks,
Shreyas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64:Modify the dump mem for 64 bit addresses

[Maninder Singh]

From: Rohit Thapliyal 

On 64bit kernel, the dump_mem gives 32 bit addresses
on the stack dump. This gives unorganized information regarding
the 64bit values on the stack. Hence, modified to get a complete 64bit memory
dump.

With patch:
[   93.534801] Process insmod (pid: 1587, stack limit = 0xffc976be4058)
[   93.541441] Stack: (0xffc976be7cf0 to 0xffc976be8000)
[   93.547136] 7ce0:   ffc976be7d00 
ffc8163c
[   93.554898] 7d00: ffc976be7d40 ffcf8a44 ffc00098ef38 
ffbffc88
[   93.562659] 7d20: ffc00098ef50 ffbffcc0 0001 
ffbffc70
[   93.570419] 7d40: ffc976be7e40 ffcf935c  
2b424090
[   93.578179] 7d60: 2b424010 007facc555f4 8000 
0015
[   93.585937] 7d80: 0116 0069 ffc00097b000 
ffc976be4000
[   93.593694] 7da0: 0064 0072 006e 
003f
[   93.601453] 7dc0: feff fff1 ffbffc002028 
0124
[   93.609211] 7de0: ffc976be7e10 0001 ff80 
ffbb
[   93.616969] 7e00: ffc976be7e60   

[   93.624726] 7e20:    

[   93.632484] 7e40: 007fcc474550 ffc841ec 2b424010 
007facda0710
[   93.640241] 7e60:  ffcbe6dc ff80007d2000 
0001c010
[   93.647999] 7e80: ff80007e0ae0 ff80007e09d0 ff80007edf70 
0288
[   93.655757] 7ea0: 02e8   
001c001b
[   93.663514] 7ec0: 0009 0007 2b424090 
0001c010
[   93.671272] 7ee0: 2b424010 007faccd3a48  

[   93.679030] 7f00: 007fcc4743f8 007fcc4743f8 0069 
0003
[   93.686787] 7f20: 0101010101010101 0004 0020 
03f3
[   93.694544] 7f40: 007facb95664 007facda7030 007facc555d0 
00498378
[   93.702301] 7f60:  2b424010 007facda0710 
2b424090
[   93.710058] 7f80: 007fcc474698 00498000 007fcc474ebb 
00474f58
[   93.717815] 7fa0: 00498000   
007fcc474550
[   93.725573] 7fc0: 004104bc 007fcc474430 007facc555f4 
8000
[   93.70] 7fe0: 2b424090 0069 0950020128000244 
41040804
[   93.741084] Call trace:

The above output makes a debugger life a lot more easier.

Signed-off-by: Rohit Thapliyal 
Signed-off-by: Maninder Singh 
---
v1: added new function dump_mem64
v2: remove seprate function, modified dump_mem
v3: Changelog modified
v4: Used compat_user_mode() for setting width to 4 or 8

 arch/arm64/kernel/traps.c |   31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 1ef2940..97e6208 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -52,11 +52,12 @@ int show_unhandled_signals = 1;
  * Dump out the contents of some memory nicely...
  */
 static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
-unsigned long top)
+unsigned long top, bool wide)
 {
unsigned long first;
mm_segment_t fs;
int i;
+   unsigned int width = wide ? 4 : 8;
 
/*
 * We need to switch to kernel mode so that we can use __get_user
@@ -75,13 +76,22 @@ static void dump_mem(const char *lvl, const char *str, 
unsigned long bottom,
memset(str, ' ', sizeof(str));
str[sizeof(str) - 1] = '\0';
 
-   for (p = first, i = 0; i < 8 && p < top; i++, p += 4) {
+   for (p = first, i = 0; i < (32 / width)
+   && p < top; i++, p += width) {
if (p >= bottom && p < top) {
-   unsigned int val;
-   if (__get_user(val, (unsigned int *)p) == 0)
-   sprintf(str + i * 9, " %08x", val);
-   else
-   sprintf(str + i * 9, " ");
+   unsigned long val;
+
+   if (width == 8) {
+   if (__get_user(val, (unsigned long *)p) 
== 0)
+   sprintf(str + i * 17, " 
%016lx", val);
+   else
+   sprintf(str + i * 17, " 
");
+   } else {
+   if (__get_user(val, (unsigned int *)p) 

Re: [PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue

[Greg KH]

On Thu, Jul 09, 2015 at 08:20:57AM +0530, rcodin wrote:
> From: Ronit Halder 
> 
> Fixed a coding style issue.
> 
> Signed-off-by: Ronit Halder 
> ---
>  drivers/staging/android/ion/ion.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 6f48112..e44f5e6 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -1106,6 +1106,7 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
> *client,
>   struct ion_buffer *buffer;
>   struct dma_buf *dmabuf;
>   bool valid_handle;
> +
>   DEFINE_DMA_BUF_EXPORT_INFO(exp_info);

This is a false positive and has been rejected so many times it's really
getting old...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

[Ingo Molnar]

* Ingo Molnar  wrote:

> > Without something like that, we'll be in the awkward position of having 
> > some 
> > of the selectors (DS, ES, FS, and GS) in both the normal pt_regs slot and 
> > in 
> > the extended hardware frame during execution of normal vm86-unaware kernel 
> > code.  If, on the other hand, we copied the selectors across in 
> > enter_from_user_mode and prepare_return_from_usermode, then pt_regs would 
> > work 
> > normally even for tasks that are running in v8086 mode.
> > 
> > regs->flags & X86_EFLAGS_VM will be true regardless, so all of the asm that 
> > decides to invoke those helpers should work fine.
> 
> Btw., has anyone considered an entirely different approach: using KVM's 
> instruction emulator to emulate vm86 16-bit code execution? Basically the 
> vm86 
> system call would be kept compatible, but fully emulated, the CPU never 
> enters 
> true 16-bit mode, just iterates pt_regs as if it had.
> 
> This approach has four main advantages:
> 
>  - we could remove the fragile vm86 code from the entry code
> 
>  - it might even be faster for certain workloads than faulting in and out all 
>the time and using ancient, fragile hardware mode of the CPU. (For example 
> it 
>could detect the VGA screen write patterns and accelerate them.)
> 
>  - it could be made to work on 64-bit as well, FWIIW
> 
>  - it would provide another angle of testing for the KVM emulator

So there's a fifth advantage as well that I think needs to be stressed:

   - it's an _obviously_ much more secure design, as we only iterate user-space
 pt_regs and never truly touch any security relevant CPU state. The whole
 nested pt_regs and different hw frame entry complications would go away
 entirely. All CPU semantics would not be just assumed implicitly, but would
 be very much present in the CPU emulator and would be reviewable.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: android: ion: fixed a blank line after declarations coding style issue

[Ronit Halder]

On Thu, 2015-07-09 at 11:05 +0530, Sudip Mukherjee wrote:
> On Thu, Jul 09, 2015 at 08:20:57AM +0530, rcodin wrote:
> > From: Ronit Halder 
> 
> You do not need a From: here. Please fix your gitconfig file and
> git send-email will give your name correctly in the email header.
> 
> regards
> sudip
thanks for pointing it sudip.
Sorry for the stupid mistake, version 2 of the patch is coming.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

[Ingo Molnar]

* Andy Lutomirski  wrote:

> >> I look forward to it.
> >>
> >> However: I imagine that, if you do this, you may need to be quite careful 
> >> about an x86_32-ism.  Currently, if you have a pt_regs pointer for the 
> >> current entry and user_mode(regs) returns true, then regs == 
> >> current_pt_regs().  If you let user mode run with EFLAGS.VM set with the 
> >> normal tss.sp0, then this will no longer be true, as the extra-long 
> >> entry-from-v8086 frame will shift pt_regs by a few bytes. I don't know 
> >> whether this matters, but I can imagine it causing do_signal to explode.  
> >> *shudder*
> >
> > I am aware that pt_regs is in a fixed location on the stack.  What I plan 
> > to 
> > do is increase the padding at the top of the stack if VM86 is configured, 
> > to 
> > reserve space for the extra segment registers.  Then it will move tss.sp0 
> > up 
> > 16 bytes when entering vm86 mode so that the longer IRET frame is in the 
> > right 
> > place.
> >
> 
> Hmm, should work.
> 
> I wonder if the right way to do this is to set a TIF_VM86 flag and do the 
> fixups 
> in enter_from_user_mode and prepare_return_to_usermode. See the patches I 
> just 
> sent (and tip/x88/asm, which they apply to).
> 
> Without something like that, we'll be in the awkward position of having some 
> of 
> the selectors (DS, ES, FS, and GS) in both the normal pt_regs slot and in the 
> extended hardware frame during execution of normal vm86-unaware kernel code.  
> If, on the other hand, we copied the selectors across in enter_from_user_mode 
> and prepare_return_from_usermode, then pt_regs would work normally even for 
> tasks that are running in v8086 mode.
> 
> regs->flags & X86_EFLAGS_VM will be true regardless, so all of the asm that 
> decides to invoke those helpers should work fine.

Btw., has anyone considered an entirely different approach: using KVM's 
instruction emulator to emulate vm86 16-bit code execution? Basically the vm86 
system call would be kept compatible, but fully emulated, the CPU never enters 
true 16-bit mode, just iterates pt_regs as if it had.

This approach has four main advantages:

 - we could remove the fragile vm86 code from the entry code

 - it might even be faster for certain workloads than faulting in and out all 
the
   time and using ancient, fragile hardware mode of the CPU. (For example it 
could
   detect the VGA screen write patterns and accelerate them.)

 - it could be made to work on 64-bit as well, FWIIW

 - it would provide another angle of testing for the KVM emulator

Hm?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: dts: mediatek: add mt6795 support

[Mars Cheng]

> > +   chosen {
> > +   bootargs = "console=ttyS0,921600n8 earlyprintk";
> 
> PLease get rid of bootargs here; earlyprintk doesn't do anything on
> arm64 (it's earlycon these days), and you can specify the serial
> configuration in stdout-path, so please use that instead.
> 
Got it. Will remove bootargs & use stdout-path only.
> > +   stdout-path = &uart0;
> > +   };
> > +};
> > +
> > +&uart0 {
> > +   status = "okay";
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi 
> > b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> > new file mode 100644
> > index 000..832be20
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> > @@ -0,0 +1,164 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Mars.C 
> > + *
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +/ {
> > +   compatible = "mediatek,mt6795";
> > +   interrupt-parent = <&sysirq>;
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +
> > +   cpus {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   cpu0: cpu@0 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x000>;
> > +   };
> > +
> > +   cpu1: cpu@1 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x001>;
> > +   };
> 
> No enable-method? Does your FW patch that in?
This patch only provides single core to boot.The proper enable-method
for SMP boot is under discussion in our site. Will complete
enable-method when providing our solution to SMP boot in the other patch
set.
> 
> > +
> > +   cpu2: cpu@2 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x002>;
> > +   };
> > +
> > +   cpu3: cpu@3 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x003>;
> > +   };
> > +
> > +   cpu4: cpu@4 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x100>;
> > +   };
> 
> The unit-address should match the reg (e.g. this should be cpu@100).
Got it. Will fix this.
> 
> > +
> > +   cpu5: cpu@5 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x101>;
> > +   };
> > +
> > +   cpu6: cpu@6 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x102>;
> > +   };
> > +
> > +   cpu7: cpu@7 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x103>;
> > +   };
> > +   };
> > +
> > +   clocks {
> > +   system_clk: dummy13m {
> > +   compatible = "fixed-clock";
> > +   clock-frequency = <1300>;
> > +   #clock-cells = <0>;
> > +   };
> > +
> > +   rtc_clk: dummy32k {
> > +   compatible = "fixed-clock";
> > +   clock-frequency = <32000>;
> > +   #clock-cells = <0>;
> > +   };
> > +
> > +   uart_clk: dummy26m {
> > +   compatible = "fixed-clock";
> > +   clock-frequency = <2600>;
> > +   #clock-cells = <0>;
> > +   };
> > +   };
> 
> Get rid of the clocks node and place these directly under the root node.
Got it. Will fix it.
> 
> > +
> > +   timer {
> > +   compatible = "arm,armv8-timer";
> > +   interrupt-parent = <&gic>;
> > +   interrupts =  > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > +   };
> 
> The mask is wrong.
They should be GIC_CPU_MASK_SIMPLE(8). Will fix these.

Thanks for your suggestions.
> 
> Thanks,
> Mark.


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

Re: [RFT PATCH 1/2] i2c: tegra: update CONFIG_LOAD for new conifiguration

[Laxman Dewangan]

On Thursday 09 July 2015 02:06 AM, Stephen Warren wrote:

On 06/30/2015 04:54 AM, Laxman Dewangan wrote:



Signed-off-by: Laxman Dewangan 
Signed-off-by: Chaitanya Bandi 


I'm not sure why Chaitanya's S-o-b is there and listed last if he's 
not the patch author. If he wrote the patch, he should be the git 
author and his S-o-b should be first. If he didn't and you simply 
based this patch on work by Chaitanya, then his S-o-b probably 
shouldn't be present, and yours would be last since you're submitting 
the patch.


The patch I created is based on Chaitanya's work, edited on his work to 
match with mainline.





---
Stephen/Andrew,
I need help on testing this on other platform. I tested this on T210.


I'm puzzled how this was tested on T210, since it isn't supported 
upstream yet.


We tested this as:
- K318 kernel release + i2c subsystem from linux-next in downstream boards.
- Chrome-OS team on smaug with their tree.



The series,
Tested-by: Stephen Warren 


Thanks for testing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: android: ion: fixed a blank line after declarations coding style issue

[Sudip Mukherjee]

On Thu, Jul 09, 2015 at 08:20:57AM +0530, rcodin wrote:
> From: Ronit Halder 

You do not need a From: here. Please fix your gitconfig file and
git send-email will give your name correctly in the email header.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: 8250: Allow to skip autoconfig_irq() for a console

[Taichi Kageyama]

Hi Peter and Prarit,

On 2015/07/08 23:00, Prarit Bhargava wrote:
>
>
> On 07/08/2015 09:51 AM, Peter Hurley wrote:
>> Hi Prarit,
>>
>> On 07/08/2015 08:53 AM, Prarit Bhargava wrote:
>>>
>>>
>>> On 07/08/2015 07:55 AM, Peter Hurley wrote:
 Hi Taichi,

 On 06/05/2015 06:03 AM, Taichi Kageyama wrote:
> This patch provides a new parameter as a workaround of the following
> problem. It allows us to skip autoconfig_irq() and to use a well-known irq
> number for a console even if CONFIG_SERIAL_8250_DETECT_IRQ is defined.
>
> There're cases where autoconfig_irq() fails during boot.
> In these cases, the console doesn't work in interrupt mode,
> the mode cannot be changed anymore, and "input overrun"
> (which can make operation mistakes) happens easily.
> This problem happens with high rate every boot once it occurs
> because the boot sequence is always almost same.
>
> autoconfig_irq() assumes that a CPU can handle an interrupt from a serial
> during the waiting time, but there're some cases where the CPU cannot
> handle the interrupt for longer than the time. It completely depends on
> how other functions work on the CPU. Ideally, autoconfig_irq() should be
> fixed


Thank you for your comments.

 It completely depends on how long some other driver has interrupts 
 disabled,

Agree.

 which is a problem that needs fixed _in that driver_. autoconfig_irq() 
 does not
 need fixing.

Peter, ideally, you're right.
However, we cannot assume how long other drivers disable interrupts.
That's why I introduced this workaround.
In my opinion, a console is important and always should be available
even if other drivers have a bad behavior.


 A typical cause of this behavior is printk spew from overly-instrumented
 debugging of some driver (trace_printk is better suited to heavy 
 instrumentation).

>>>
>>> Peter, I understand what you're saying, however the problem is that this is 
>>> the
>>> serial driver which is one of, if not _the_ main debug output mechanism in 
>>> the
>>> kernel.

I tried fixing the one of them, 8250 driver.
  "[PATCH 1/2] serial: 8250: Fix autoconfig_irq() to avoid race conditions".
  https://lkml.org/lkml/2015/6/5/218

The problem can happen when the drivers show just info level message during 
boot.
It depends on the timing completely.

>>>
>>> I'm not sure I agree with doing this patch, but perhaps an easier approach 
>>> would
>>> be to add a debug kernel parameter like "serial.force_irq=4" to force the 
>>> irq to
>>> a previously known good value?  That way the issue of the broken driver can 
>>> be
>>> debugged.

Prarit, I think it's good if the serial id can be also specified.

I thought adding irq option to "console" kernel parameter before,
but it was not good idea because the impact was not small
and passing irq# was not required in most cases.
- PnP serial device can get valid irq#
- Most on-board serial for console use legacy fixed irq#, like irq3, irq4.

So, I designed this patch like below.
  - It allows console serial to skip autoconfig_irq.
Actually I assumes console serial uses a typical irq# in old_serial_port[],
but it's the same case where CONFIG_SERIAL_8250_DETECT_IRQ is not defined.
  - It allows non-console serial to kick autoconfig_irq.
setserial command can try it again later if it fails on boot time.

>>
>> For debugging purposes, can you use a kernel built with
>> CONFIG_SERIAL_8250_DETECT_IRQ=n?

I know "CONFIG_SERIAL_8250_DETECT_IRQ=n" is one of solutions
because autoconfig_irq() is not used on boot time in this case.
However, I know some Linux distributions actually use this config
and I assume someone may require it.

>>
>> What is the platform and device type?
>>
>
> Taichi?

I saw the original problem on x86-64 platforms with RHEL6.6.
The serial was SOL(serial over LAN), not registered as PnP device.


Thanks,
Taichi


>
> P.
>
>> Regards,
>> Peter Hurley
>>
>>
>>> P.
>>>
 Regards,
 Peter Hurley


> to control these cases but as long as auto_irq algorithm is used,
> it's hard to know which CPU can handle an interrupt from a serial and
> to assure the interrupt of the CPU is enabled during auto_irq.
> Meanwhile for legacy consoles, they actually don't require auto_irq
> because they basically use well-known irq number.
> For non-console serials, this workaround is not required
> because setserial command can kick autoconfig_irq() again for them.
>
> Signed-off-by: Taichi Kageyama 
> Cc: Naoya Horiguchi 
> ---
>drivers/tty/serial/8250/8250_core.c |   17 +
>1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c 
> b/drivers/tty/serial/8250/8250_core.c
> index 6bf31f2..60fda28 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c

[PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue

[Ronit Halder]

Fixed a coding style issue.

Signed-off-by: Ronit Halder 
---
 drivers/staging/android/ion/ion.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 6f48112..e44f5e6 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1106,6 +1106,7 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
*client,
struct ion_buffer *buffer;
struct dma_buf *dmabuf;
bool valid_handle;
+
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
 
mutex_lock(&client->lock);
-- 
1.9.1

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

Re: [PATCH 1/7] pinctrl: UniPhier: add UniPhier pinctrl core support

[Masahiro Yamada]

Hi Paul,

2015-07-09 5:39 GMT+09:00 Paul Bolle :
> Hi Masahiro,
>
> On wo, 2015-07-08 at 14:01 +0900, Masahiro Yamada wrote:
>> Actually, most of pinctrl drivers are boolean, but most of them
>> conventionally have MODULE_AUTHOR, THIS_MODULE, etc.
>>
>> I do not think it looks so weird.  Thought?
>
> It's a rather common pattern, but I think it's an anti-pattern
> nevertheless. See the discussion that Shobhit Kumar, Paul Gortmaker, and
> I had starting in https://lkml.org/lkml/2015/6/20/63 .
>
> Please let me know if you're unconvinced by the arguments brought
> forward by both Pauls in that discussion.
>


After I read your references and thought a bit more,
I am now considering to change the bool into tristate.

Pinctrl drivers usually contain quite big pin tables, so
it sounds somewhat reasonable to make it loadable,
given that minimal pin-settings could be done in the boot-loader.
Actually, some of pinctrl drivers in the mainline are already tristate.

I will send v2 later with some other fixes I have noticed.


Is this OK with you?


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

Re: [PATCH v5 2/2] cpufreq: mediatek: Add MT8173 cpufreq driver

[Viresh Kumar]

On 09-07-15, 09:55, Pi-Cheng Chen wrote:
> That's what I did in previous version. But the reason I use the device-
> driver model is to handle the defer probing issue. Since there's no
> arch/arm64/mach-mediatek/ directory to hold the device registration
> code anymore, no device tree way to match cpufreq driver
> (please correct me if there's any), and initcall seems not handle
> defer probing either, therefore I put both device and driver
> registration in this function. I know it's crappy. :(
> Do you have any suggestion to do it right and handle defer probing
> properly?

Sounds reasonable. Just add proper comment in code to explain that.

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

[RFC] drivers: dma-coherent: Change order of allocation to PAGE_SIZE

[Sricharan R]

dma_alloc_from_coherent uses get_order(size) which makes carve-out
allocations not aligned on order boundaries to fail even though
they are page aligned. So wanted to know why is it required to have
the size aligned on order boundary. Changing it to get_order(PAGE_SIZE)
makes the non aligned carve-out allocations to go through.

Signed-off-by: Sricharan R 
---
 drivers/base/dma-coherent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 55b8398..72bdc6f 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -156,7 +156,7 @@ int dma_alloc_from_coherent(struct device *dev, ssize_t 
size,
   dma_addr_t *dma_handle, void **ret)
 {
struct dma_coherent_mem *mem;
-   int order = get_order(size);
+   int order = get_order(PAGE_SIZE);
unsigned long flags;
int pageno;
 
-- 
QUALCOMM INDIA, on behalf of 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/

Re: [PATCH] cpufreq: Allow accessing freq_table for offline CPUs

[Viresh Kumar]

On 09-07-15, 02:40, Rafael J. Wysocki wrote:
> The above sentence is completely unclear to anyone unfamiliar with the
> code in question.
> 
> The fix is to access the policy data structure for the given CPU directly
> (which also returns a valid policy for offline CPUs), but the policy
> itself has to be active (meaning that at least one CPU using it is online)
> for the frequency table to be returned.
> 
> Right?

Yeah..

---8<
Message-Id: 
<9c37b9a711b6dc6e419e256fd62fcc93a29db4e4.1436418686.git.viresh.ku...@linaro.org>
From: Viresh Kumar 
Date: Wed, 8 Jul 2015 12:53:03 +0530
Subject: [PATCH V3] cpufreq: Allow accessing freq_table for offline CPUs

Users of freq table may want to access it for any CPU from
policy->related_cpus mask. One such user is cpu-cooling layer. It gets a
list of 'clip_cpus' (equivalent to policy->related_cpus) during
registration and tries to get freq_table for the first CPU of this mask.

If the CPU, for which it tries to fetch freq_table, is offline,
cpufreq_frequency_get_table() fails. This happens because it relies on
cpufreq_cpu_get_raw() for its functioning which returns policy only for
online CPUs.

The fix is to access the policy data structure for the given CPU
directly (which also returns a valid policy for offline CPUs), but the
policy itself has to be active (meaning that at least one CPU using it
is online) for the frequency table to be returned.

Because we will be using 'cpufreq_cpu_data' now, which is internal to
cpufreq-core, lets also move cpufreq_frequency_get_table() to cpufreq.c
file.

Reported-and-tested-by: Pi-Cheng Chen 
Signed-off-by: Viresh Kumar 
---
V3-> Changelog improvement suggested by Rafael.

 drivers/cpufreq/cpufreq.c| 9 +
 drivers/cpufreq/freq_table.c | 9 -
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 36e97a5a7e20..a7b6ac6e048e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -169,6 +169,15 @@ struct kobject *get_governor_parent_kobj(struct 
cpufreq_policy *policy)
 }
 EXPORT_SYMBOL_GPL(get_governor_parent_kobj);
 
+struct cpufreq_frequency_table *cpufreq_frequency_get_table(unsigned int cpu)
+{
+   struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
+
+   return policy && !policy_is_inactive(policy) ?
+   policy->freq_table : NULL;
+}
+EXPORT_SYMBOL_GPL(cpufreq_frequency_get_table);
+
 static inline u64 get_cpu_idle_time_jiffy(unsigned int cpu, u64 *wall)
 {
u64 idle_time;
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index df14766a8e06..dfbbf981ed56 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -297,15 +297,6 @@ int cpufreq_table_validate_and_show(struct cpufreq_policy 
*policy,
 }
 EXPORT_SYMBOL_GPL(cpufreq_table_validate_and_show);
 
-struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu);
-
-struct cpufreq_frequency_table *cpufreq_frequency_get_table(unsigned int cpu)
-{
-   struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
-   return policy ? policy->freq_table : NULL;
-}
-EXPORT_SYMBOL_GPL(cpufreq_frequency_get_table);
-
 MODULE_AUTHOR("Dominik Brodowski ");
 MODULE_DESCRIPTION("CPUfreq frequency table helpers");
 MODULE_LICENSE("GPL");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] driver-core: add asynchronous probing support for drivers

[Dan Williams]

On Wed, Jul 8, 2015 at 9:44 PM, Dmitry Torokhov
 wrote:
> On Wed, Jul 08, 2015 at 06:00:41PM -0700, Dan Williams wrote:
>> On Wed, Jul 8, 2015 at 5:49 PM, Dmitry Torokhov
>>  wrote:
>> > On Wed, Jul 08, 2015 at 05:36:04PM -0700, Dan Williams wrote:
>> >> On Mon, Jul 6, 2015 at 4:40 PM, Dmitry Torokhov
>> >>  wrote:
>> >> > On Tue, Jul 07, 2015 at 01:23:15AM +0200, Luis R. Rodriguez wrote:
>> >> >> On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote:
>> >> >> > On Fri, Jul 3, 2015 at 11:30 AM, Luis R. Rodriguez  
>> >> >> > wrote:
>> >> >> > > On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote:
>> >> >> > >> On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov
>> >> >> > >>  wrote:
>> >> >> > >> > Some devices take a long time when initializing, and not all 
>> >> >> > >> > drivers are
>> >> >> > >> > suited to initialize their devices when they are open. For 
>> >> >> > >> > example,
>> >> >> > >> > input drivers need to interrogate their devices in order to 
>> >> >> > >> > publish
>> >> >> > >> > device's capabilities before userspace will open them. When 
>> >> >> > >> > such drivers
>> >> >> > >> > are compiled into kernel they may stall entire kernel 
>> >> >> > >> > initialization.
>> >> >> > >> >
>> >> >> > >> > This change allows drivers request for their probe functions to 
>> >> >> > >> > be
>> >> >> > >> > called asynchronously during driver and device registration 
>> >> >> > >> > (manual
>> >> >> > >> > binding is still synchronous). Because async_schedule is used 
>> >> >> > >> > to perform
>> >> >> > >> > asynchronous calls module loading will still wait for the 
>> >> >> > >> > probing to
>> >> >> > >> > complete.
>> >> >> > >> >
>> >> >> > >> > Note that the end goal is to make the probing asynchronous by 
>> >> >> > >> > default,
>> >> >> > >> > so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a 
>> >> >> > >> > temporary
>> >> >> > >> > measure that allows us to speed up boot process while we 
>> >> >> > >> > validating and
>> >> >> > >> > fixing the rest of the drivers and preparing userspace.
>> >> >> > >> >
>> >> >> > >> > This change is based on earlier patch by "Luis R. Rodriguez"
>> >> >> > >> > 
>> >> >> > >> >
>> >> >> > >> > Signed-off-by: Dmitry Torokhov 
>> >> >> > >> > ---
>> >> >> > >> >  drivers/base/base.h|   1 +
>> >> >> > >> >  drivers/base/bus.c |  31 +++---
>> >> >> > >> >  drivers/base/dd.c  | 149 
>> >> >> > >> > ++---
>> >> >> > >> >  include/linux/device.h |  28 ++
>> >> >> > >> >  4 files changed, 182 insertions(+), 27 deletions(-)
>> >> >> > >>
>> >> >> > >> Just noticed this patch.  It caught my eye because I had a hard 
>> >> >> > >> time
>> >> >> > >> getting an open coded implementation of asynchronous probing to 
>> >> >> > >> work
>> >> >> > >> in the new libnvdimm subsystem.  Especially the messy races of 
>> >> >> > >> tearing
>> >> >> > >> things down while probing is still in flight.  I ended up 
>> >> >> > >> implementing
>> >> >> > >> asynchronous device registration which eliminated a lot of 
>> >> >> > >> complexity
>> >> >> > >> and of course the bugs.  In general I tend to think that async
>> >> >> > >> registration is less risky than async probe since it keeps wider
>> >> >> > >> portions of the traditional device model synchronous
>> >> >> > >
>> >> >> > > but its not see -DEFER_PROBE even before async probe.
>> >> >> >
>> >> >> > Except in that case you know probe has been seen by the driver at
>> >> >> > least once.  So I see that as less of a surprise, but point taken.
>> >> >> >
>> >> >> > >> and leverages the
>> >> >> > >> fact that the device model is already well prepared for 
>> >> >> > >> asynchronous
>> >> >> > >> arrival of devices due to hotplug.
>> >> >> > >
>> >> >> > > I think this sounds reasonable, do you have your code upstream or 
>> >> >> > > posted?
>> >> >> >
>> >> >> > Yes, see nd_device_register() in drivers/nvdimm/bus.c
>> >> >>
>> >> >> It should be I think rather easy for Dmitry to see if he can convert 
>> >> >> this input
>> >> >> driver (not yet upstream) to this API and see if the same issues are 
>> >> >> fixed.
>> >> >
>> >> > No, I would rather not as it means we lose error handling on device
>> >> > registration.
>> >> >
>> >>
>> >> I think this is a red herring as I don't see how async probing is any
>> >> better at handling device registration errors.  The error is logged
>> >> and "handled" by the fact that a device fails to appear, what other
>> >> action would you take?  In fact libnvdimm does detect registration
>> >> failures and reports that in a parent device attribute (at least for a
>> >> region device and their namespace child devices).
>> >
>> > What is libnvdimm behavior if you try to unload a module that tries to
>> > register a device but it failed? Memory leak or crash, right?
>>
>> No, in the case of the "region" driver it is part of the core
>> libnvdimm and it is pinned while any region device is active

Re: [PATCH] cpufreq: Initialize the governor again while restoring policy

[Viresh Kumar]

On 09-07-15, 02:33, Rafael J. Wysocki wrote:
> > We also missed marking policy->governor as NULL while restoring the
> > policy. Because of that, we call __cpufreq_governor(CPUFREQ_GOV_LIMITS)
> 
> How exactly does that happen?

Should have mentioned that in detail, sorry for being lazy. Hopefully
this will look better:

---8<---

Message-Id: 
<5f17361741c009a7f0d8488f7f94bab80d9317fd.1436418101.git.viresh.ku...@linaro.org>
From: Viresh Kumar 
Date: Wed, 8 Jul 2015 10:45:53 +0530
Subject: [PATCH V2] cpufreq: Initialize the governor again while restoring 
policy

When all CPUs of a policy are hot-unplugged, we EXIT the governor but
don't mark policy->governor as NULL. This was done in order to keep last
used governor's information intact in sysfs, while the CPUs are offline.

But we also marking policy->governor as NULL while restoring the policy.

Because policy->governor still points to the last governor while policy
is restored, following sequence of event happens:
- cpufreq_init_policy() called while restoring policy
- find_governor() matches last_governor string for present governors and
  returns last used governor's pointer, say ondemand. policy->governor
  already has the same address, unless the governor was removed in
  between.
- cpufreq_set_policy() is called with both old/new policies governor set
  as ondemand.
- Because governors matched, we skip governor initialization and return
  after calling __cpufreq_governor(CPUFREQ_GOV_LIMITS). Because the
  governor wasn't initialized for this policy, it returned -EBUSY.
- cpufreq_init_policy() exits the policy on this error, but doesn't
  destroy it properly (should be fixed separately).
- And so we enter a scenario where the policy isn't completely
  initialized but used.

Fix this by setting policy->governor to NULL while restoring the policy.

Reported-and-tested-by: Pi-Cheng Chen 
Reported-and-tested-by: "Jon Medhurst (Tixy)" 
Tested-by: Steven Rostedt 
Fixes: 18bf3a124ef8 ("cpufreq: Mark policy->governor = NULL for inactive 
policies")
Signed-off-by: Viresh Kumar 
---
V2: Detailed changelog

 drivers/cpufreq/cpufreq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b612411655f9..2c22e3902e72 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1132,6 +1132,7 @@ static struct cpufreq_policy 
*cpufreq_policy_restore(unsigned int cpu)
 
down_write(&policy->rwsem);
policy->cpu = cpu;
+   policy->governor = NULL;
up_write(&policy->rwsem);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] um: umid: Use strdup to simplify code

[Christophe JAILLET]

Replace a malloc+strcpy by an equivalent strdup in order to improve
readability.

Signed-off-by: Christophe JAILLET 
---
 arch/um/os-Linux/umid.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/um/os-Linux/umid.c b/arch/um/os-Linux/umid.c
index b514ead..cc9ac2e 100644
--- a/arch/um/os-Linux/umid.c
+++ b/arch/um/os-Linux/umid.c
@@ -48,12 +48,11 @@ static int __init make_uml_dir(void)
strlcat(dir, "/", sizeof(dir));
 
err = -ENOMEM;
-   uml_dir = malloc(strlen(dir) + 1);
+   uml_dir = strdup(dir);
if (uml_dir == NULL) {
-   printf("make_uml_dir : malloc failed, errno = %d\n", errno);
+   printf("make_uml_dir : strdup failed, errno = %d\n", errno);
goto err;
}
-   strcpy(uml_dir, dir);
 
if ((mkdir(uml_dir, 0777) < 0) && (errno != EEXIST)) {
printf("Failed to mkdir '%s': %s\n", uml_dir, strerror(errno));
-- 
2.1.4

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

[PATCH 1/2] um: umid: Use tab instead of spaces

[Christophe JAILLET]

Turn some spaces into a tab to be consistent with the rest of the code.

Signed-off-by: Christophe JAILLET 
---
 arch/um/os-Linux/umid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/os-Linux/umid.c b/arch/um/os-Linux/umid.c
index c1dc892..b514ead 100644
--- a/arch/um/os-Linux/umid.c
+++ b/arch/um/os-Linux/umid.c
@@ -56,7 +56,7 @@ static int __init make_uml_dir(void)
strcpy(uml_dir, dir);
 
if ((mkdir(uml_dir, 0777) < 0) && (errno != EEXIST)) {
-   printf("Failed to mkdir '%s': %s\n", uml_dir, strerror(errno));
+   printf("Failed to mkdir '%s': %s\n", uml_dir, strerror(errno));
err = -errno;
goto err_free;
}
-- 
2.1.4

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

Re: [PATCH v7 0/3] Add arm pl353 smc nand driver for xilinx zynq soc

[Michal Simek]

On 07/08/2015 09:40 PM, Josh Cartwright wrote:
> On Mon, Jun 08, 2015 at 11:38:35PM +0530, Punnaiah Choudary Kalluri wrote:
>> 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.
> 
> What's the integration plan for this guy?  Looks like we missed 4.2.
> It'd be swell to get have NAND support land for Zynq in 4.3.
> 
> Assuming there is nothing else holding it back:
> 
> Brian- I'm assuming you'll want to take this through your tree.
> 
> It looks like most of the stuff in drivers/memory have historically gone
> through arm-soc/drivers, Michal- does it make sense for you to pick up
> http://lkml.kernel.org/r/1433786857-32575-1-git-send-email-punn...@xilinx.com?

I am happy to take this via zynq tree and arm-soc tree if this is the
right way.

Josh: Also none can stop you to give us you ACK or Tested-by line.

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

Re: [PATCH] net: systemport: Use eth_hw_addr_random

[Florian Fainelli]

Le 07/07/15 22:19, Vaishali Thakkar a écrit :
> Use eth_hw_addr_random() instead of calling random_ether_addr().
> Here, this change is setting addr_assign_type to NET_ADDR_RANDOM.
> 
> The Coccinelle semantic patch that performs this transformation
> is as follows:
> 
> @@
> identifier a,b;
> @@
> 
> -random_ether_addr(a->b);
> +eth_hw_addr_random(a);
> 
> Signed-off-by: Vaishali Thakkar 
> ---
> Note that this patch is compile tested only and I have used file
> drivers/net/ethernet/hisilicon/hix5hd2_gmac.c as a reference.
> Also, original call didn't make assignment to NET_ADDR_RANDOM. So,
> it would be good if someone can test this change.

Thanks, I will give this a try and report.

> ---
>  drivers/net/ethernet/broadcom/bcmsysport.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c 
> b/drivers/net/ethernet/broadcom/bcmsysport.c
> index 909ad7a..4566cdf 100644
> --- a/drivers/net/ethernet/broadcom/bcmsysport.c
> +++ b/drivers/net/ethernet/broadcom/bcmsysport.c
> @@ -1793,7 +1793,7 @@ static int bcm_sysport_probe(struct platform_device 
> *pdev)
>   macaddr = of_get_mac_address(dn);
>   if (!macaddr || !is_valid_ether_addr(macaddr)) {
>   dev_warn(&pdev->dev, "using random Ethernet MAC\n");
> - random_ether_addr(dev->dev_addr);
> + eth_hw_addr_random(dev);
>   } else {
>   ether_addr_copy(dev->dev_addr, macaddr);
>   }
> 


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

Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail

[Yinghai Lu]

On Wed, Jul 8, 2015 at 8:30 PM, Wei Yang  wrote:
> Hi, Yinghai
>
> This patch may introduce some problem.
>
> On my P8 machine, after applying this patch, I see following error:
>
> [0.589948] pnv_ioda_setup_pe_seg: trigger IO SEG 0
> [0.589992] pnv_ioda_setup_pe_seg: res[io  0x1000-0x3fff] 100
>
> The last 0x100 is the res->flags, which indicates the UNSET and DISABLED bit
> is not set.

Maybe we should introduce resource_disabled() for that.

Please check if attached patch would fix the problem.

Thanks

Yinghai
Subject: [PATCH] PCI: Introduce resource_disabled()

so we can cover !flags and IORESOURCE_DISABLED both.

Signed-off-by: Yinghai Lu 

diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 82f738e..91a7153 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -282,7 +282,7 @@ pcibios_claim_one_bus(struct pci_bus *b)
 		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
 			struct resource *r = &dev->resource[i];
 
-			if (r->parent || !r->start || !r->flags)
+			if (r->parent || !r->start || resource_disabled(r))
 continue;
 			if (pci_has_flag(PCI_PROBE_ONLY) ||
 			(r->flags & IORESOURCE_PCI_FIXED)) {
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 7cc3be9..cc293ea 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -501,7 +501,7 @@ void pcibios_fixup_device_resources(struct pci_dev *dev)
 	for (idx = 0; idx < PCI_BRIDGE_RESOURCES; idx++) {
 		struct resource *r = &dev->resource[idx];
 
-		if (!r->flags || r->parent || !r->start)
+		if (resource_disabled(r) || r->parent || !r->start)
 			continue;
 
 		pci_claim_resource(dev, idx);
@@ -519,7 +519,7 @@ static void pcibios_fixup_bridge_resources(struct pci_dev *dev)
 	for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
 		struct resource *r = &dev->resource[idx];
 
-		if (!r->flags || r->parent || !r->start)
+		if (resource_disabled(r) || r->parent || !r->start)
 			continue;
 
 		pci_claim_bridge_resource(dev, idx);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index ae838ed..67848f8 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -705,7 +705,7 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
 	}
 	for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
 		struct resource *res = dev->resource + i;
-		if (!res->flags)
+		if (resource_disabled(res))
 			continue;
 		if (res->start == 0) {
 			pr_debug("PCI:%s Resource %d %016llx-%016llx [%x]",
@@ -806,7 +806,7 @@ static void pcibios_fixup_bridge(struct pci_bus *bus)
 	pci_bus_for_each_resource(bus, res, i) {
 		if (!res)
 			continue;
-		if (!res->flags)
+		if (resource_disabled(res))
 			continue;
 		if (i >= 3 && bus->self->transparent)
 			continue;
@@ -993,7 +993,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
 		 pci_domain_nr(bus), bus->number);
 
 	pci_bus_for_each_resource(bus, res, i) {
-		if (!res || !res->flags
+		if (!res || resource_disabled(res)
 		|| res->start > res->end || res->parent)
 			continue;
 		if (bus->parent == NULL)
@@ -1095,7 +1095,8 @@ static void __init pcibios_allocate_resources(int pass)
 			r = &dev->resource[idx];
 			if (r->parent)		/* Already allocated */
 continue;
-			if (!r->flags || (r->flags & IORESOURCE_UNSET))
+			if (resource_disabled(r) ||
+			(r->flags & IORESOURCE_UNSET))
 continue;	/* Not assigned at all */
 			/* We only allocate ROMs on pass 1 just in case they
 			 * have been screwed up by firmware
@@ -1226,7 +1227,7 @@ void pcibios_claim_one_bus(struct pci_bus *bus)
 		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
 			struct resource *r = &dev->resource[i];
 
-			if (r->parent || !r->start || !r->flags)
+			if (r->parent || !r->start || resource_disabled(r))
 continue;
 
 			pr_debug("PCI: Claiming %s: ", pci_name(dev));
@@ -1286,7 +1287,7 @@ static void pcibios_setup_phb_resources(struct pci_controller *hose,
 	res->start = (res->start + io_offset) & 0xu;
 	res->end = (res->end + io_offset) & 0xu;
 
-	if (!res->flags) {
+	if (resource_disabled(res)) {
 		pr_warn("PCI: I/O resource not set for host ");
 		pr_cont("bridge %s (domain %d)\n",
 			hose->dn->full_name, hose->global_number);
@@ -1306,7 +1307,7 @@ static void pcibios_setup_phb_resources(struct pci_controller *hose,
 	/* Hookup PHB Memory resources */
 	for (i = 0; i < 3; ++i) {
 		res = &hose->mem_resources[i];
-		if (!res->flags) {
+		if (resource_disabled(res)) {
 			if (i > 0)
 continue;
 			pr_err("PCI: Memory resource 0 not set for ");
diff --git a/arch/mn10300/unit-asb2305/pci-asb2305.c b/arch/mn10300/unit-asb2305/pci-asb2305.c
index b5b036f..a249821 100644
--- a/arch/mn10300/unit-asb2305/pci-asb2305.c
+++ b/arch/mn10300/unit-asb2305/pci-asb2305.c
@@ -103,7 +103,7 @@ static void __init pcibios_allocate_bus_resources(struct list_head *bus_list)
 			 idx < PCI_NUM_RESOURCES;
 			 idx++) {
 r = &dev->resource[idx];
-if (!r->flags)
+if (resource_disabled(r))

Re: Linux 4.2-rc1

[Ming Lei]

On Thu, Jul 9, 2015 at 11:17 AM, Linus Torvalds
 wrote:
> On Wed, Jul 8, 2015 at 5:58 PM, Ming Lei  wrote:
>> On Thu, Jul 9, 2015 at 1:29 AM, Linus Torvalds
>>  wrote:
>>> Also, it looks like you need to hold the "fw_lock" to even look at
>>> that pointer, since the buffer can get reallocated etc.
>>
>> Yes, the above code with holding 'fw_lock' is right fix for the issue since
>> sysfs read can happen anytime, and there is one race between firmware
>> request abort and reading uevent of sysfs.
>
> So if fw_priv->buf is NULL, what should we do?
>
> Should we skip the TIMEOUT= and ASYNC= fields too?

When the request is aborted, the firmware device will be removed,
so it is OK to skip the two fields.

>
> Something like the attached, perhaps?

Looks it is fine.

>
> Shuah, how reproducible is this? Does this (completely untested) patch
> make any difference?
>
>   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] cpufreq: Add ->get_rate() driver callback

[Viresh Kumar]

On 09-07-15, 01:41, Rafael J. Wysocki wrote:
> On Wednesday, July 08, 2015 04:07:32 PM Viresh Kumar wrote:
> > CPUFreq drivers today support a ->get(cpu) callback, which returns
> > current rate of a CPU. The problem with ->get() is that it takes a cpu
> > number as parameter and this unnecessarily makes things complex.
> > 
> > Firstly the core gets the cpu number by doing operation 'policy->cpu' on
> > the policy and then many drivers need to get the policy back and so do
> > cpufreq_cpu_get(cpu) on the passed cpu.
> > 
> > As cpufreq core works on policies, it would be better if we pass them
> > 'policy' directly and drivers can use policy->cpu if that's all they
> > need.
> > 
> > Hence, this patch adds in another callback, ->get_rate() which does
> > exactly the same work as ->get(), just that we pass 'policy' as
> > parameter instead of 'cpu'.
> > 
> > The plan is to migrate all drivers to this new callback and remove
> > ->get() after that.
> > 
> > Signed-off-by: Viresh Kumar 
> > ---
> > Hi Rafael,
> > 
> > I hope you are fine with this stuff :), once you approve I will get
> > other patches to migrate existing drivers to this interface.
> 
> I'm generally fine with it, but please target it at 4.4 at the earliest.

Sure, but I was a bit curious on why 4.4 and not 4.3 ? as we are still
at 4.2-rc1 today, and these patches can be done fairly quickly.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG] Kernel splat when taking CPUs offline

[Viresh Kumar]

On 09-07-15, 00:25, Steven Rostedt wrote:
> On Thu, 9 Jul 2015 09:34:45 +0530
> Viresh Kumar  wrote:
> 
> 
> > I think it might be related to what I chased down yesterday:
> > 
> > http://marc.info/?l=linux-kernel&m=143633485824975&w=2
> > 
> > @Steven: Can you please give this a try ?
> > 
> 
> Yes that seems to fix my issue as well.
> 
> Tested-by: Steven Rostedt 

Awesome, so the problem was that cpufreq_set_policy() was failing
because of the latest bug I planted :), and that caused ->exit() but
didn't free the policy completely. (I have fixed that as well in a
separate patch).

And so you are hitting a policy which has already exited. Sorry about
that :)

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: let __sched_period() use rq cfs's nr_running

[Byungchul Park]

On Wed, Jul 08, 2015 at 09:19:14AM +0900, Byungchul Park wrote:
> On Tue, Jul 07, 2015 at 01:28:18PM -0700, Cong Wang wrote:
> > On Mon, Jul 6, 2015 at 9:40 PM,   wrote:
> > > From: Byungchul Park 
> > >
> > > __sched_period() returns a period which a rq can have. the period has to 
> > > be
> > > stretched by the number of task *the rq has*, when nr_running > 
> > > nr_latency.
> > > otherwise, task slice can be very smaller than 
> > > sysctl_sched_min_granularity
> > > depending on the position of tg hierarchy when CONFIG_FAIR_GROUP_SCHED.
> > 
> > 
> > Hmm, rq_of(cfs_rq)->cfs should point to the root cfs_rq whose
> > ->nr_running is number of running entities at root level? This
> > doesn't look right.
> 
> hello, cong wang,
> 
> __sched_period() returns a root level period now. stretching the period with
> a local task group's nr_running is meaningless for getting this period.
> is there something i missed? :)

i am very sorry for my wrong patch, with which i cannot achieve what i intend.

what i intended is to use rq_of(cfs_rq)'s nr_number, not rq_of(cfs_rq)->cfs's,
so that __sched_period() returns a period which a rq can have. i need resend 
patch :( but i wonder what do you think about my basic concern?

thank you,
byungchul

> 
> thank you,
> byungchul
> 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 00/56] 4.1.2-stable review

[Sudip Mukherjee]

On Wed, Jul 08, 2015 at 12:34:49AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.1.2 release.
> There are 56 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 10 07:31:19 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32. No errors in dmesg.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] neterion: s2io: Use module_pci_driver

[Vaishali Thakkar]

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

A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:

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

@b depends on a@
identifier e, a.x;
statement S;
@@
-static e(...) {
-pci_unregister_driver(&x);
-DBG_PRINT(INIT_DBG,"S");
- }

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

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

Signed-off-by: Vaishali Thakkar 
---
 drivers/net/ethernet/neterion/s2io.c | 26 +-
 drivers/net/ethernet/neterion/s2io.h |  2 --
 2 files changed, 1 insertion(+), 27 deletions(-)

diff --git a/drivers/net/ethernet/neterion/s2io.c 
b/drivers/net/ethernet/neterion/s2io.c
index c281117..2d1b942 100644
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -8226,31 +8226,7 @@ static void s2io_rem_nic(struct pci_dev *pdev)
pci_disable_device(pdev);
 }
 
-/**
- * s2io_starter - Entry point for the driver
- * Description: This function is the entry point for the driver. It verifies
- * the module loadable parameters and initializes PCI configuration space.
- */
-
-static int __init s2io_starter(void)
-{
-   return pci_register_driver(&s2io_driver);
-}
-
-/**
- * s2io_closer - Cleanup routine for the driver
- * Description: This function is the cleanup routine for the driver. It
- * unregisters the driver.
- */
-
-static __exit void s2io_closer(void)
-{
-   pci_unregister_driver(&s2io_driver);
-   DBG_PRINT(INIT_DBG, "cleanup done\n");
-}
-
-module_init(s2io_starter);
-module_exit(s2io_closer);
+module_pci_driver(s2io_driver);
 
 static int check_L2_lro_capable(u8 *buffer, struct iphdr **ip,
struct tcphdr **tcp, struct RxD_t *rxdp,
diff --git a/drivers/net/ethernet/neterion/s2io.h 
b/drivers/net/ethernet/neterion/s2io.h
index d89b6ed..6c5997d 100644
--- a/drivers/net/ethernet/neterion/s2io.h
+++ b/drivers/net/ethernet/neterion/s2io.h
@@ -1085,8 +1085,6 @@ static void s2io_txpic_intr_handle(struct s2io_nic *sp);
 static void tx_intr_handler(struct fifo_info *fifo_data);
 static void s2io_handle_errors(void * dev_id);
 
-static int s2io_starter(void);
-static void s2io_closer(void);
 static void s2io_tx_watchdog(struct net_device *dev);
 static void s2io_set_multicast(struct net_device *dev);
 static int rx_osm_handler(struct ring_info *ring_data, struct RxD_t * rxdp);
-- 
1.9.1

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

Re: [PATCH v4 1/3] dt-bindings: pwm: add MediaTek display PWM bindings

[Daniel Kurtz]

On Thu, Jul 9, 2015 at 10:45 AM, YH Huang  wrote:
>
> On Wed, 2015-07-08 at 20:11 +0800, Daniel Kurtz wrote:
> > On Mon, Jul 6, 2015 at 9:29 PM, YH Huang  wrote:
> > > Document the device-tree binding of MediatTek display PWM.
> > > The PWM has one channel to control the backlight brightness for display.
> > > It supports MT8173 and MT6595.
> > >
> > > Signed-off-by: YH Huang 
> > > ---
> > >  .../devicetree/bindings/pwm/pwm-mtk-disp.txt   | 24 
> > > ++
> > >  1 file changed, 24 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt 
> > > b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > new file mode 100644
> > > index 000..757b974
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > @@ -0,0 +1,24 @@
> > > +MediaTek display PWM controller
> > > +
> > > +Required properties:
> > > + - compatible: should be "mediatek,-disp-pwm"
> > > +   - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> > > +   - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> > > + - reg: physical base address and length of the controller's registers
> > > + - #pwm-cells: must be 2. See pwm.txt in this directory for a 
> > > description of
> > > +   the cell format
> > > + - clocks: phandle and clock specifier of the PWM reference clock
> > > + - clock-names: must contain the following
> > > +   - "main": clock used to generate PWM signals
> > > +   - "mm": sync signals from the modules of mmsys
> > > +
> > > +Example:
> > > +   pwm0: pwm@1401e000 {
> > > +   compatible = "mediatek,mt8173-disp-pwm",
> > > +"mediatek,mt6595-disp-pwm";
> > > +   reg = <0 0x1401e000 0 0x1000>;
> > > +   #pwm-cells = <2>;
> > > +   clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> > > +<&mmsys CLK_MM_DISP_PWM0MM>;
> > > +   clock-names = "main", "mm";
> >
> > Should we include the pinctrl settings here to enable the PWM output?
> >
>
> Since we use pwm-backlight driver to control backlight, we should enable
> PWM output in the backlight node.
>
> Ref:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>

The pwm-backlight binding specifies which pwm the backlight driver
should use, and how to use it.

I believe actually configuring the output pin for the pwm via pinctl
belongs to the pwm binding.

Regards,
0Dan

>
> Regards,
> YH Huang
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] driver-core: add asynchronous probing support for drivers

[Dmitry Torokhov]

On Wed, Jul 08, 2015 at 06:00:41PM -0700, Dan Williams wrote:
> On Wed, Jul 8, 2015 at 5:49 PM, Dmitry Torokhov
>  wrote:
> > On Wed, Jul 08, 2015 at 05:36:04PM -0700, Dan Williams wrote:
> >> On Mon, Jul 6, 2015 at 4:40 PM, Dmitry Torokhov
> >>  wrote:
> >> > On Tue, Jul 07, 2015 at 01:23:15AM +0200, Luis R. Rodriguez wrote:
> >> >> On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote:
> >> >> > On Fri, Jul 3, 2015 at 11:30 AM, Luis R. Rodriguez  
> >> >> > wrote:
> >> >> > > On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote:
> >> >> > >> On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov
> >> >> > >>  wrote:
> >> >> > >> > Some devices take a long time when initializing, and not all 
> >> >> > >> > drivers are
> >> >> > >> > suited to initialize their devices when they are open. For 
> >> >> > >> > example,
> >> >> > >> > input drivers need to interrogate their devices in order to 
> >> >> > >> > publish
> >> >> > >> > device's capabilities before userspace will open them. When such 
> >> >> > >> > drivers
> >> >> > >> > are compiled into kernel they may stall entire kernel 
> >> >> > >> > initialization.
> >> >> > >> >
> >> >> > >> > This change allows drivers request for their probe functions to 
> >> >> > >> > be
> >> >> > >> > called asynchronously during driver and device registration 
> >> >> > >> > (manual
> >> >> > >> > binding is still synchronous). Because async_schedule is used to 
> >> >> > >> > perform
> >> >> > >> > asynchronous calls module loading will still wait for the 
> >> >> > >> > probing to
> >> >> > >> > complete.
> >> >> > >> >
> >> >> > >> > Note that the end goal is to make the probing asynchronous by 
> >> >> > >> > default,
> >> >> > >> > so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a 
> >> >> > >> > temporary
> >> >> > >> > measure that allows us to speed up boot process while we 
> >> >> > >> > validating and
> >> >> > >> > fixing the rest of the drivers and preparing userspace.
> >> >> > >> >
> >> >> > >> > This change is based on earlier patch by "Luis R. Rodriguez"
> >> >> > >> > 
> >> >> > >> >
> >> >> > >> > Signed-off-by: Dmitry Torokhov 
> >> >> > >> > ---
> >> >> > >> >  drivers/base/base.h|   1 +
> >> >> > >> >  drivers/base/bus.c |  31 +++---
> >> >> > >> >  drivers/base/dd.c  | 149 
> >> >> > >> > ++---
> >> >> > >> >  include/linux/device.h |  28 ++
> >> >> > >> >  4 files changed, 182 insertions(+), 27 deletions(-)
> >> >> > >>
> >> >> > >> Just noticed this patch.  It caught my eye because I had a hard 
> >> >> > >> time
> >> >> > >> getting an open coded implementation of asynchronous probing to 
> >> >> > >> work
> >> >> > >> in the new libnvdimm subsystem.  Especially the messy races of 
> >> >> > >> tearing
> >> >> > >> things down while probing is still in flight.  I ended up 
> >> >> > >> implementing
> >> >> > >> asynchronous device registration which eliminated a lot of 
> >> >> > >> complexity
> >> >> > >> and of course the bugs.  In general I tend to think that async
> >> >> > >> registration is less risky than async probe since it keeps wider
> >> >> > >> portions of the traditional device model synchronous
> >> >> > >
> >> >> > > but its not see -DEFER_PROBE even before async probe.
> >> >> >
> >> >> > Except in that case you know probe has been seen by the driver at
> >> >> > least once.  So I see that as less of a surprise, but point taken.
> >> >> >
> >> >> > >> and leverages the
> >> >> > >> fact that the device model is already well prepared for 
> >> >> > >> asynchronous
> >> >> > >> arrival of devices due to hotplug.
> >> >> > >
> >> >> > > I think this sounds reasonable, do you have your code upstream or 
> >> >> > > posted?
> >> >> >
> >> >> > Yes, see nd_device_register() in drivers/nvdimm/bus.c
> >> >>
> >> >> It should be I think rather easy for Dmitry to see if he can convert 
> >> >> this input
> >> >> driver (not yet upstream) to this API and see if the same issues are 
> >> >> fixed.
> >> >
> >> > No, I would rather not as it means we lose error handling on device
> >> > registration.
> >> >
> >>
> >> I think this is a red herring as I don't see how async probing is any
> >> better at handling device registration errors.  The error is logged
> >> and "handled" by the fact that a device fails to appear, what other
> >> action would you take?  In fact libnvdimm does detect registration
> >> failures and reports that in a parent device attribute (at least for a
> >> region device and their namespace child devices).
> >
> > What is libnvdimm behavior if you try to unload a module that tries to
> > register a device but it failed? Memory leak or crash, right?
> 
> No, in the case of the "region" driver it is part of the core
> libnvdimm and it is pinned while any region device is active.

No, not quite. Let's take a look for example at nd_btt_probe(). It calls
__nd_btt_create() which in turn calls __nd_device_register() which
returns void and 

Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state

[Daniel Axtens]

> I recommend creating an alias or script that does:
> 
> $ git log --pretty=fixes -n 1 $commit | xclip
> 

FWIW, having finally got around to doing this, I found I first needed
the following snippet in ~/.gitconfig from
https://www.kernel.org/doc/Documentation/SubmittingPatches


[core]
abbrev = 12
[pretty]
fixes = Fixes: %h (\"%s\")

Otherwise git doesn't know what the pretty format is.

-- 
Regards,
Daniel


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

Re: New suspicious RCU usage in 4.2.0-rc1 plus patch

[Paul E. McKenney]

On Thu, Jul 09, 2015 at 02:50:25AM +0200, Rafael J. Wysocki wrote:
> Hi Paul,
> 
> Something seems to have changed in RCU in 4.2-rc1, as it is now complaining
> about a tracepoint in tick_freeze() like this:
> 
> [   66.340508] ===
> [   66.340509] [ INFO: suspicious RCU usage. ]
> [   66.340512] 4.2.0-rc1+ #1691 Not tainted
> [   66.340513] ---
> [   66.340515] /scratch/rafael/work/linux-pm/include/trace/events/power.h:193 
> suspicious rcu_dereference_check() usage!
> [   66.340517] 
> other info that might help us debug this:
> 
> [   66.340519] 
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> [   66.340520] RCU used illegally from extended quiescent state!
> [   66.340522] 1 lock held by swapper/0/0:
> [   66.340538]  #0:  (tick_freeze_lock){..}, at: [] 
> tick_freeze+0x19/0x230
> [   66.340539] 
> stack backtrace:
> [   66.340543] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc1+ #1691
> [   66.340544] Hardware name: TOSHIBA PORTEGE R500/Portable PC, BIOS Version 
> 1.60 03/04/2008
> [   66.340550]  0001 81c03e48 817ab99d 
> 0004
> [   66.340555]  81c10500 81c03e78 810a2dd7 
> 0003
> [   66.340560]   81a6b2c7 a00b3090 
> 81c03ea8
> [   66.340561] Call Trace:
> [   66.340567]  [] dump_stack+0x4f/0x7b
> [   66.340573]  [] lockdep_rcu_suspicious+0xe7/0x120
> [   66.340577]  [] tick_freeze+0x188/0x230
> [   66.340582]  [] cpuidle_enter_freeze+0x30/0x80
> [   66.340586]  [] cpu_startup_entry+0x455/0x490
> [   66.340591]  [] rest_init+0x132/0x140
> [   66.340595]  [] ? csum_partial_copy_generic+0x170/0x170
> [   66.340601]  [] start_kernel+0x484/0x491
> [   66.340604]  [] ? set_init_arg+0x58/0x58
> [   66.340608]  [] x86_64_start_reservations+0x2a/0x2c
> [   66.340611]  [] x86_64_start_kernel+0xe7/0xeb
> 
> It didn't complained about it before, AFAICS, but in any case the simplest
> way to deal with it seems to be to put tick_freeze() under RCU_NONIDLE()
> like in the patch below.

The above warning won't show up unless you have lockdep enabled, so
maybe that is what changed?  (Recent RCU changes could expose additional
uses of RCU from offline CPUs, but shouldn't be any change from idle
CPUs.  Famous last words!)

> I wonder what you think about it?

Reviewed-by: Paul E. McKenney 

> Thanks,
> Rafael
> 
> 
> ---
> From: Rafael J. Wysocki 
> Subject: cpuidle / s2i: Prevent RCU from complaining about tick_freeze()
> 
> Put tick_freeze() under RCU_NONIDLE() to prevent RCU from complaining
> about suspicious RCU usage in idle by trace_suspend_resume() called
> from there.
> 
> While at it, fix a comment related to another usage of RCU_NONIDLE()
> in enter_freeze_proper().
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpuidle/cpuidle.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> Index: linux-pm/drivers/cpuidle/cpuidle.c
> ===
> --- linux-pm.orig/drivers/cpuidle/cpuidle.c
> +++ linux-pm/drivers/cpuidle/cpuidle.c
> @@ -112,7 +112,12 @@ int cpuidle_find_deepest_state(struct cp
>  static void enter_freeze_proper(struct cpuidle_driver *drv,
>   struct cpuidle_device *dev, int index)
>  {
> - tick_freeze();
> + /*
> +  * trace_suspend_resume() called by tick_freeze() for the last CPU
> +  * executing it contains RCU usage regarded as invalid in the idle
> +  * context, so tell RCU about that.
> +  */
> + RCU_NONIDLE(tick_freeze());
>   /*
>* The state used here cannot be a "coupled" one, because the "coupled"
>* cpuidle mechanism enables interrupts and doing that with timekeeping
> @@ -122,7 +127,7 @@ static void enter_freeze_proper(struct c
>   WARN_ON(!irqs_disabled());
>   /*
>* timekeeping_resume() that will be called by tick_unfreeze() for the
> -  * last CPU executing it calls functions containing RCU read-side
> +  * first CPU executing it calls functions containing RCU read-side
>* critical sections, so tell RCU about that.
>*/
>   RCU_NONIDLE(tick_unfreeze());
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG] Kernel splat when taking CPUs offline

[Steven Rostedt]

On Thu, 9 Jul 2015 09:34:45 +0530
Viresh Kumar  wrote:


> I think it might be related to what I chased down yesterday:
> 
> http://marc.info/?l=linux-kernel&m=143633485824975&w=2
> 
> @Steven: Can you please give this a try ?
> 

Yes that seems to fix my issue as well.

Tested-by: Steven Rostedt 

Thanks!

-- 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 4.0 00/55] 4.0.8-stable review

[Sudip Mukherjee]

On Wed, Jul 08, 2015 at 12:34:35AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.0.8 release.
> There are 55 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 10 07:31:26 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32. No errors in dmesg.

But when tried sudo make kselftest, it gave:
Makefile:29: *** missing separator.  Stop.
make: *** [kselftest] Error 2

gcc version is 4.8.2

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

Re: [patch v3 3/3] mm, oom: do not panic for oom kills triggered from sysrq

[Hillf Danton]

> Sysrq+f is used to kill a process either for debug or when the VM is
> otherwise unresponsive.
> 
> It is not intended to trigger a panic when no process may be killed.
> 
> Avoid panicking the system for sysrq+f when no processes are killed.
> 
> Suggested-by: Michal Hocko 
> Signed-off-by: David Rientjes 
> ---
>  v2: no change
>  v3: fix title per Hillf
> 
>  Documentation/sysrq.txt | 3 ++-
>  mm/oom_kill.c   | 7 +--
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt
> --- a/Documentation/sysrq.txt
> +++ b/Documentation/sysrq.txt
> @@ -75,7 +75,8 @@ On all -  write a character to /proc/sysrq-trigger.  e.g.:
> 
>  'e' - Send a SIGTERM to all processes, except for init.
> 
> -'f'  - Will call oom_kill to kill a memory hog process.
> +'f'  - Will call the oom killer to kill a memory hog process, but do not
> +   panic if nothing can be killed.
> 
>  'g'  - Used by kgdb (kernel debugger)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -607,6 +607,9 @@ void check_panic_on_oom(struct oom_control *oc, enum 
> oom_constraint constraint,
>   if (constraint != CONSTRAINT_NONE)
>   return;
>   }
> + /* Do not panic for oom kills triggered by sysrq */
> + if (oc->order == -1)
> + return;
>   dump_header(oc, NULL, memcg);
>   panic("Out of memory: %s panic_on_oom is enabled\n",
>   sysctl_panic_on_oom == 2 ? "compulsory" : "system-wide");
> @@ -686,11 +689,11 @@ bool out_of_memory(struct oom_control *oc)
> 
>   p = select_bad_process(oc, &points, totalpages);
>   /* Found nothing?!?! Either we hang forever, or we panic. */
> - if (!p) {
> + if (!p && oc->order != -1) {
>   dump_header(oc, NULL, NULL);
>   panic("Out of memory and no killable processes...\n");
>   }

Given sysctl_panic_on_oom checked, AFAICU there seems
no chance for panic, no matter -1 or not.

> - if (p != (void *)-1UL) {
> + if (p && p != (void *)-1UL) {
>   oom_kill_process(oc, p, points, totalpages, NULL,
>"Out of memory");
>   killed = 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/

linux-next: Tree for Jul 9

[Stephen Rothwell]

Hi all,

Changes since 20150708:

The drm-intel tree gained conflicts against Linus' and the drm-intel-fixes
trees.

The tip tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1275
 1128 files changed, 68969 insertions(+), 20637 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,
a multi_v7_defconfig for arm and a native build of tools/perf. 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 223 trees (counting Linus' and 32 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 (45820c294fe1 Fix broken audit tests for exec arg len)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (11b8b25ce4f8 ARM: fix lockdep unannotated irqs-off 
warning)
Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg())
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (9958084a5275 powerpc: Update MAINTAINERS to point 
at shared tree)
Merging powerpc-merge-mpe/fixes (a8956a7b7232 powerpc/powernv: Fix opal-elog 
interrupt handler)
Merging powerpc-merge-benh/merge (c517d838eb7d Linux 4.0-rc1)
Merging sparc/master (4a10a91756ef Merge branch 'upstream' of 
git://git.infradead.org/users/pcmoore/audit)
Merging net/master (142b942a75cb rhashtable: fix for resize events during table 
walk)
Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at 
start of day.)
Merging sound-current/for-linus (e828b23734bf ALSA: hda - add codec ID for 
Broxton display audio codec)
Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during 
alignment reordering)
Merging wireless-drivers/master (38fe44e61a89 Merge tag 
'iwlwifi-for-kalle-2015-05-28' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (d770e558e219 Linux 4.2-rc1)
Merging tty.current/tty-linus (d770e558e219 Linux 4.2-rc1)
Merging usb.current/usb-linus (d4669bb1427c Merge tag 'fixes-for-v4.2-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (b2e2c94b878b usb: gadget: f_midi: fix error 
recovery path)
Merging usb-serial-fixes/usb-linus (f98a7aa81eee USB: cp210x: add ID for Aruba 
Networks controllers)
Merging staging.current/staging-linus (cbe4f4434ded staging:lustre: remove 
irq.h from socklnd.h)
Merging char-misc.current/char-misc-linus (d770e558e219 Linux 4.2-rc1)
Merging input-current/for-linus (539c4b88146c Input: elan_i2c - change the 
hover event from MT to ST)
Merging crypto-current/master (030f4e968741 crypto: nx - Fix reentrancy bugs)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (758556bdc1c8 module: Fix load_module() error path)
Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible 
timeout)
Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER while requesting the PWM)
Merging drm-intel-fixes/for-linux-next-fixes (de

Re: [PATCH] Revert: audit: Fix check of return value of strnlen_user()

[Steven Rostedt]

On Wed, 8 Jul 2015 12:29:43 -0400
Steven Rostedt  wrote:

> I tested the following patch. Feel free to author it yourself and just
> add my reported/tested-by tags, or give it to me. Either way, I don't
> care. I just want it fixed so that it doesn't make my own tests fail.
> 

OK, you posted your version of the patch, and you just had to include
the quote from me that happened to have a grammar mistake:

  As reported by Steven Rostedt:

 "Yes, strnlen_user() returns 0 on fault, but if you look at what len is
  set to, than you would notice that on fault len would be -1"

Ug, my "than" stupidity is forever carved in the git stone logs.

At least you didn't stick a "(sic)" in there.

-- 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: [BUG] Kernel splat when taking CPUs offline

[Viresh Kumar]

On 09-07-15, 02:13, Rafael J. Wysocki wrote:
> So the cpufreq driver's ->get() callback returns 0 for the given CPU and
> that's what triggers the WARN_ON().  And it most likely returns 0, because
> its internal data structure for that CPU is not present.
> 
> I *guess* that before the above commit policy was NULL in 
> cpufreq_update_policy()
> and we didn't get to the point where ->get() was called.

I am not sure if that behavior should have changed at all.. Earlier we
were clearing per-cpu cpufreq_cpu_data for offline CPUs and so policy
would have been NULL for offline CPUs.

Now that per-cpu variable isn't cleared, but cpufreq_cpu_get() does
check if the CPU is part of policy->cpus or not, i.e. if it is
offline. And so policy should still be NULL for offline CPUs.

I think it might be related to what I chased down yesterday:

http://marc.info/?l=linux-kernel&m=143633485824975&w=2

@Steven: Can you please give this a try ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/11] soc: qcom: Add device tree binding for SMEM

[Andy Gross]

On Wed, Jul 08, 2015 at 04:56:34PM -0700, Stephen Boyd wrote:
> On 06/26/2015 02:50 PM, bj...@kryo.se wrote:
> > += EXAMPLE
> > +The following example shows the SMEM setup for MSM8974, with a main SMEM 
> > region
> > +at 0xfa0 and an auxiliary region at 0xfc428000:
> > +
> > +   reserved-memory {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges;
> > +
> > +   smem_region: smem@fa0 {
> > +   reg = <0xfa0 0x20>;
> > +   no-map;
> > +   };
> > +   };
> > +
> > +   smem@fa0 {
> 
> This should be smem@fc428000 matching the first reg property. It's weird
> though, because if smem is using a secondary region it will be under the
> SoC node and have a reg property. Otherwise it would be directly under
> the root node and only have a memory-region. It would be nice if we
> could somehow move the rpm message ram (0xfc428000) into the
> reserved-memory node so that we could use memory-region for both regions.

The memory-region is just used to describe 'real' memory.  The RPM message is IO
memory and part of the SOC.  Thats my take at least.

> 
> > +   compatible = "qcom,smem";
> > +
> > +   memory-region = <&smem_region>;
> > +   reg = <0xfc428000 0x4000>;
> > +
> > +   hwlocks = <&tcsr_mutex 3>;
> > +   };

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[ANN] Linux Security Summit 2015 - Schedule Published

[James Morris]

The schedule for the 2015 Linux Security Summit in Seattle is now 
published.

The refereed talks are:

* CC3: An Identity Attested Linux Security Supervisor Architecture
   - Greg Wettstein, IDfusion

* SELinux in Android Lollipop and Android M
   - Stephen Smalley, NSA

* Linux Incident Response
- Mike Scutt and Tim Stiller, Rapid7

* Assembling Secure OS Images
- Elena Reshetova, Intel

* Linux and Mobile Device Encryption
- Paul Lawrence and Mike Halcrow, Google

* Security Framework for Constraining Application Privileges
- Lukasz Wojciechowski, Samsung

* IMA/EVM: Real Applications for Embedded Networking Systems
- Petko Manolov, Konsulko Group, and Mark Baushke, Juniper Networks

* Ioctl Command Whitelisting in SELinux
- Jeffrey Vander Stoep, Google

* IMA/EVM on Android Device
- Dmitry Kasatkin, Huawei Technologies

There will be several discussion sessions:

* Core Infrastructure Initiative
- Emily Ratliff, Linux Foundation

* Linux Security Module Stacking Next Steps
- Casey Schaufler, Intel

* Discussion: Rethinking Audit
- Paul Moore, Red Hat

Also featured are brief updates on kernel security subsystems, including 
SELinux, Smack, AppArmor, Integrity, Capabilities, and Seccomp.

The keynote speaker will be Konstantin Ryabitsev, sysadmin for kernel.org.  
Check out his Reddit AMA! [1]

See the schedule for full details, and any updates:

http://kernsec.org/wiki/index.php/Linux_Security_Summit_2015#Schedule

This year’s summit will take place on the 20th and 21st of August, in 
Seattle, USA, as a LinuxCon co-located event.  As such, all Linux Security 
Summit attendees must be registered for LinuxCon. Attendees are welcome to 
attend the Weds 19th August reception.

Hope to see you there!

- James (on behalf of the program committee).


[1]
http://www.reddit.com/r/linux/comments/2xqn12/im_part_of_the_sysadmin_team_behind_kernelorg_and/


-- 
James Morris

Re: [BUG] Kernel splat when taking CPUs offline

[Steven Rostedt]

On Thu, 09 Jul 2015 02:13:45 +0200
"Rafael J. Wysocki"  wrote:


> > Initializing CPU#1
> > [ cut here ]
> > WARNING: CPU: 0 PID: 1609 at 
> > /home/rostedt/work/git/linux-trace.git/drivers/cpufreq/cpufreq.c:2350 
> > cpufreq_update_policy+0xc8/0x139()
> 
> So the cpufreq driver's ->get() callback returns 0 for the given CPU and
> that's what triggers the WARN_ON().  And it most likely returns 0, because
> its internal data structure for that CPU is not present.
> 
> I *guess* that before the above commit policy was NULL in 
> cpufreq_update_policy()
> and we didn't get to the point where ->get() was called.

Just some more info. That ->get() is get_cur_freq_on_cpu() (I added a
printk to find out what that was).

Also, adding more printks() (patch of printk's added below) I got this:

 # trace-cmd start -p mmiotrace  # offlines all but one CPU
 # trace-cmd start -p nop# onlines the CPUs
 # trace-cmd start -p mmiotrace  # again offlines all but one CPU
 # trace-cmd start -p nop# again onlines the CPUs

produces:


in mmio_trace_init
mmiotrace: Disabling non-boot CPUs...
smpboot: CPU 1 is now offline
exit free f252c180 (1)
mmiotrace: CPU1 is down.
Broke affinity for irq 28
smpboot: CPU 2 is now offline
exit free f252c260 (2)
mmiotrace: CPU2 is down.
Broke affinity for irq 4
Broke affinity for irq 25
Broke affinity for irq 26
Broke affinity for irq 27
Broke affinity for irq 28
smpboot: CPU 3 is now offline
exit free f252c280 (3)
mmiotrace: CPU3 is down.
mmiotrace: enabled.
in mmio_trace_start
in mmio_trace_reset
mmiotrace: Re-enabling CPUs...
x86: Booting SMP configuration:
smpboot: Booting Node 0 Processor 1 APIC 0x2
Initializing CPU#1
INIT data = f05a6b40 (1)
data=f05a6b40
data-acpi_data=f3539634
data-freq_table_data=f2073b00
exit free f05a6b40 (1)
mmiotrace: enabled CPU1.
smpboot: Booting Node 0 Processor 2 APIC 0x1
Initializing CPU#2
INIT data = efe567a0 (2)
data=efe567a0
data-acpi_data=f368b634
data-freq_table_data=ef849100
exit free efe567a0 (2)
mmiotrace: enabled CPU2.
smpboot: Booting Node 0 Processor 3 APIC 0x3
Initializing CPU#3
INIT data = efe56760 (3)
data=efe56760
data-acpi_data=f37dd634
data-freq_table_data=ef840600
exit free efe56760 (3)
mmiotrace: enabled CPU3.
mmiotrace: disabled.
in mmio_trace_init
mmiotrace: Disabling non-boot CPUs...
cpufreq: __cpufreq_remove_dev_prepare: Failed to stop governor
smpboot: CPU 1 is now offline
mmiotrace: CPU1 is down.
cpufreq: __cpufreq_remove_dev_prepare: Failed to stop governor
Broke affinity for irq 28
smpboot: CPU 2 is now offline
mmiotrace: CPU2 is down.
cpufreq: __cpufreq_remove_dev_prepare: Failed to stop governor
Broke affinity for irq 28
smpboot: CPU 3 is now offline
mmiotrace: CPU3 is down.
mmiotrace: enabled.
in mmio_trace_start
in mmio_trace_reset
mmiotrace: Re-enabling CPUs...
x86: Booting SMP configuration:
smpboot: Booting Node 0 Processor 1 APIC 0x2
Initializing CPU#1
get=get_cur_freq_on_cpu+0x0/0xe9
data=  (null)
[ cut here ]
WARNING: CPU: 0 PID: 1994 at 
/home/rostedt/work/git/linux-trace.git/drivers/cpufreq/cpufreq.c:2351 
cpufreq_update_policy+0xe8/0x159()
Modules linked in: ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 
ip6table_filter ip6_tables ipv6 microcode r8169 ppdev parport_pc parport
CPU: 0 PID: 1994 Comm: trace-cmd Not tainted 4.2.0-rc1-test+ #30
Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
   efa11b54 c0cd0386 c10d4414 efa11b84 c0440fbe c101046c
  07ca c10d4414 092f c0a6db4a c0a6db4a f146cc00 
 efa11d60 efa11b94 c0440ff7 0009  efa11d6c c0a6db4a c10d4e15
Call Trace:
 [] dump_stack+0x41/0x52
 [] warn_slowpath_common+0x9d/0xb4
 [] ? cpufreq_update_policy+0xe8/0x159
 [] ? cpufreq_update_policy+0xe8/0x159
 [] warn_slowpath_null+0x22/0x24
 [] cpufreq_update_policy+0xe8/0x159
 [] ? extract_freq+0xa1/0xa1
 [] ? cpufreq_update_policy+0x159/0x159
 [] ? cpufreq_update_policy+0x3b/0x159
 [] ? cpufreq_freq_transition_begin+0x97/0xd9
 [] ? __wake_up+0x1a/0x47
 [] acpi_processor_ppc_has_changed+0x54/0x5d
 [] acpi_cpu_soft_notify+0xb0/0xf1
 [] ? compute_batch_value+0xd/0x22
 [] ? percpu_counter_hotcpu_callback+0x11/0x80
 [] notifier_call_chain+0x68/0x91
 [] __raw_notifier_call_chain+0x1e/0x23
 [] __cpu_notify+0x24/0x39
 [] _cpu_up+0xef/0x105
 [] cpu_up+0x4e/0x5f
 [] ? find_next_bit+0x1a/0x20
 [] disable_mmiotrace+0xd4/0x13e
 [] mmio_trace_reset+0x36/0x5e
 [] tracing_set_tracer+0xb1/0x155
 [] ? _copy_from_user+0x42/0x57
 [] tracing_set_trace_write+0x6a/0x80
 [] ? handle_mm_fault+0x75b/0xc42
 [] ? file_start_write+0x27/0x29
 [] ? tracing_set_tracer+0x155/0x155
 [] __vfs_write+0x24/0x9b
 [] ? file_start_write+0x27/0x29
 [] ? rw_verify_area+0xce/0xef
 [] ? __do_page_fault+0x2be/0x3be
 [] vfs_write+0x7a/0xc4
 [] SyS_write+0x54/0x7f
 [] sysenter_do_call+0x12/0x12
---[ end trace 47cc28ca9538eb2d ]---
mmiotrace: enabled CPU1.
smpboot: Booting Node 0 Processor 2 APIC 0x1
Initializing CPU#2
get=get_

[PATCH v2] arm64: dts: mt8173: Add afe device node

[Koro Chen]

This adds afe (audio front end) device node to the MT8173 dtsi file.

Signed-off-by: Koro Chen 
---
This patch is based on Matthias's tree:
https://github.com/mbgg/linux-mediatek
branch: v4.2-next/arm64

Changes since v1:
- change node name to afe: audio-controller@1122
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 0696f8f..ce9255a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "mt8173-pinfunc.h"
 
@@ -393,6 +394,37 @@
#size-cells = <0>;
status = "disabled";
};
+
+   afe: audio-controller@1122  {
+   compatible = "mediatek,mt8173-afe-pcm";
+   reg = <0 0x1122 0 0x1000>;
+   interrupts = ;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_AUDIO>;
+   clocks = <&infracfg CLK_INFRA_AUDIO>,
+<&topckgen CLK_TOP_AUDIO_SEL>,
+<&topckgen CLK_TOP_AUD_INTBUS_SEL>,
+<&topckgen CLK_TOP_APLL1_DIV0>,
+<&topckgen CLK_TOP_APLL2_DIV0>,
+<&topckgen CLK_TOP_I2S0_M_SEL>,
+<&topckgen CLK_TOP_I2S1_M_SEL>,
+<&topckgen CLK_TOP_I2S2_M_SEL>,
+<&topckgen CLK_TOP_I2S3_M_SEL>,
+<&topckgen CLK_TOP_I2S3_B_SEL>;
+   clock-names = "infra_sys_audio_clk",
+ "top_pdn_audio",
+ "top_pdn_aud_intbus",
+ "bck0",
+ "bck1",
+ "i2s0_m",
+ "i2s1_m",
+ "i2s2_m",
+ "i2s3_m",
+ "i2s3_b";
+   assigned-clocks = <&topckgen CLK_TOP_AUD_1_SEL>,
+ <&topckgen CLK_TOP_AUD_2_SEL>;
+   assigned-clock-parents = <&topckgen CLK_TOP_APLL1>,
+<&topckgen CLK_TOP_APLL2>;
+   };
};
 };
 
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 36/36] PCI: Don't set flags to 0 when assign resource fail

[Wei Yang]

Hi, Yinghai

This patch may introduce some problem.

On my P8 machine, after applying this patch, I see following error:

[0.589948] pnv_ioda_setup_pe_seg: trigger IO SEG 0
[0.589992] pnv_ioda_setup_pe_seg: res[io  0x1000-0x3fff] 100

The last 0x100 is the res->flags, which indicates the UNSET and DISABLED bit
is not set.

On P8, we don't have IO window, which means the IO BAR will not be assigned.
And those io_segmap is not allocated. The following trace is printed since the
io_segmap is accessed, while it is NULL.

[0.590050] Unable to handle kernel paging request for data at address 
0x
[0.590115] Faulting instruction address: 0xc00759b8
[0.590172] Oops: Kernel access of bad area, sig: 11 [#1]
[0.590216] SMP NR_CPUS=1024 NUMA PowerNV
[0.590262] Modules linked in:
[0.590309] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc1eeh_refactor+ 
#244
[0.590375] task: c02ff438 ti: c02ff6084000 task.ti: 
c02ff6084000
[0.590440] NIP: c00759b8 LR: c0075960 CTR: 3004a1bc
[0.590506] REGS: c02ff6087620 TRAP: 0300   Not tainted  
(4.2.0-rc1eeh_refactor+)
[0.590572] MSR: 90009032   CR: 2228  XER: 
2000
[0.590727] CFAR: c0008468 DAR:  DSISR: 4200 
SOFTE: 1 
GPR00: c0075960 c02ff60878a0 c1534f00 0031 
GPR04: 0001 0003   
GPR08: 0006   03f2 
GPR12: 2222 cfda c0b82c88  
GPR16: 3fff  1000 c0b82cc8 
GPR20: c0b82c50 c0b82c70 c1452148 c02fffb2d900 
GPR24: c0923c40 c02fffb4c810 c02fffb4c300 00102000 
GPR28: c02fffb40720 c01ff42aa500 c02fffb4c580  
[0.591603] NIP [c00759b8] .pnv_pci_ioda_fixup+0xaa8/0xb20
[0.591658] LR [c0075960] .pnv_pci_ioda_fixup+0xa50/0xb20
[0.591713] Call Trace:
[0.591736] [c02ff60878a0] [c0075960] 
.pnv_pci_ioda_fixup+0xa50/0xb20 (unreliable)
[0.591824] [c02ff6087a40] [c0caf0a8] 
.pcibios_resource_survey+0x3a8/0x404
[0.591901] [c02ff6087b60] [c0cae7f0] .pcibios_init+0xa0/0xd4
[0.591968] [c02ff6087bf0] [c000ad30] 
.do_one_initcall+0x110/0x280
[0.592045] [c02ff6087ce0] [c0ca45c4] 
.kernel_init_freeable+0x274/0x35c
[0.592122] [c02ff6087db0] [c000b5e4] .kernel_init+0x24/0x140
[0.592188] [c02ff6087e30] [c00094e8] 
.ret_from_kernel_thread+0x58/0x70
[0.592265] Instruction dump:
[0.592298] 7d3107b4 7f084840 7e525214 7fb09040 4099f7b8 419cf7b4 e93e0180 
811c0024 
[0.592408] 7a2a1764 38a3 7a270420 38c0 <7d09512e> a09c0026 e87e0018 
4bff1c59 
[0.592524] ---[ end trace 856c9d223a60380c ]---
[0.593584] 
[2.593742] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[2.593742] 
[2.605223] Rebooting in 10 seconds..


On Mon, Jul 06, 2015 at 04:39:26PM -0700, Yinghai Lu wrote:
>make flags take IORESOURCE_UNSET | IORESOURCE_DISABLED instead.
>
>Signed-off-by: Yinghai Lu 
>---
> drivers/pci/setup-bus.c | 52 +
> drivers/pci/setup-res.c | 11 +++
> 2 files changed, 38 insertions(+), 25 deletions(-)
>
>diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>index 9b27e15..e82655b 100644
>--- a/drivers/pci/setup-bus.c
>+++ b/drivers/pci/setup-bus.c
>@@ -255,7 +255,8 @@ static void pdev_check_resources(struct pci_dev *dev,
>   if (r->flags & IORESOURCE_PCI_FIXED)
>   continue;
>
>-  if (!(r->flags) || r->parent)
>+  if (!r->flags || r->parent ||
>+  (r->flags & IORESOURCE_DISABLED))
>   continue;
>
>   r_align = __pci_resource_alignment(dev, r, realloc_head);
>@@ -296,13 +297,6 @@ static void __dev_check_resources(struct pci_dev *dev,
>   pdev_check_resources(dev, realloc_head, head);
> }
>
>-static inline void reset_resource(struct resource *res)
>-{
>-  res->start = 0;
>-  res->end = 0;
>-  res->flags = 0;
>-}
>-
> static void __sort_resources(struct list_head *head)
> {
>   struct pci_dev_resource *res1, *tmp_res, *res2;
>@@ -387,7 +381,7 @@ static void reassign_resources_sorted(struct list_head 
>*realloc_head,
>   list_for_each_entry_safe(add_res, tmp, realloc_head, list) {
>   res = add_res->res;
>   /* skip resource that has been reset */
>-  if (!res->flags)
>+  if (res->flags & IORESOURCE_DISABLED)
>   goto out;
>
>   /* skip this resource if not found in head list */
>@@ -405,7 +399,7 @@ static void reassign_resources_sorted(struct list_head 
>*realloc_head,
>   res->st

[PATCH V4 3/7] i2c: qup: Add V2 tags support

[Sricharan R]

QUP from version 2.1.1 onwards, supports a new format of
i2c command tags. Tag codes instructs the controller to
perform a operation like read/write. This new tagging version
supports bam dma and transfers of more than 256 bytes without 'stop'
in between. Adding the support for the same.

For each block a data_write/read tag and data_len tag is added to
the output fifo. For the final block of data write_stop/read_stop
tag is used.

Signed-off-by: Andy Gross 
Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 330 ++-
 1 file changed, 323 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 131dc28..a4e20d9 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -43,6 +43,8 @@
 #define QUP_I2C_CLK_CTL0x400
 #define QUP_I2C_STATUS 0x404
 
+#define QUP_I2C_MASTER_GEN 0x408
+
 /* QUP States and reset values */
 #define QUP_RESET_STATE0
 #define QUP_RUN_STATE  1
@@ -69,6 +71,8 @@
 #define QUP_CLOCK_AUTO_GATEBIT(13)
 #define I2C_MINI_CORE  (2 << 8)
 #define I2C_N_VAL  15
+#define I2C_N_VAL_V2   7
+
 /* Most significant word offset in FIFO port */
 #define QUP_MSW_SHIFT  (I2C_N_VAL + 1)
 
@@ -79,6 +83,7 @@
 #define QUP_PACK_ENBIT(15)
 
 #define QUP_REPACK_EN  (QUP_UNPACK_EN | QUP_PACK_EN)
+#define QUP_V2_TAGS_EN 1
 
 #define QUP_OUTPUT_BLOCK_SIZE(x)(((x) >> 0) & 0x03)
 #define QUP_OUTPUT_FIFO_SIZE(x)(((x) >> 2) & 0x07)
@@ -91,6 +96,13 @@
 #define QUP_TAG_STOP   (3 << 8)
 #define QUP_TAG_REC(4 << 8)
 
+/* QUP v2 tags */
+#define QUP_TAG_V2_START   0x81
+#define QUP_TAG_V2_DATAWR  0x82
+#define QUP_TAG_V2_DATAWR_STOP 0x83
+#define QUP_TAG_V2_DATARD  0x85
+#define QUP_TAG_V2_DATARD_STOP 0x87
+
 /* Status, Error flags */
 #define I2C_STATUS_WR_BUFFER_FULL  BIT(0)
 #define I2C_STATUS_BUS_ACTIVE  BIT(8)
@@ -102,6 +114,15 @@
 #define RESET_BIT  0x0
 #define ONE_BYTE   0x1
 
+struct qup_i2c_block {
+   int count;
+   int pos;
+   int tx_tag_len;
+   int rx_tag_len;
+   int data_len;
+   u8  tags[6];
+};
+
 struct qup_i2c_dev {
struct device   *dev;
void __iomem*base;
@@ -117,6 +138,7 @@ struct qup_i2c_dev {
int in_blk_sz;
 
unsigned long   one_byte_t;
+   struct qup_i2c_blockblk;
 
struct i2c_msg  *msg;
/* Current posion in user message buffer */
@@ -126,6 +148,14 @@ struct qup_i2c_dev {
/* QUP core errors */
u32 qup_err;
 
+   int use_v2_tags;
+
+   int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
+struct i2c_msg *msg);
+
+   int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
+   struct i2c_msg *msg);
+
struct completion   xfer;
 };
 
@@ -266,7 +296,7 @@ static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int 
op, bool val,
 static void qup_i2c_set_write_mode(struct qup_i2c_dev *qup, struct i2c_msg 
*msg)
 {
/* Number of entries to shift out, including the start */
-   int total = msg->len + 1;
+   int total = msg->len + qup->blk.tx_tag_len;
 
if (total < qup->out_fifo_sz) {
/* FIFO mode */
@@ -324,6 +354,134 @@ static int qup_i2c_issue_write(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
return ret;
 }
 
+static void qup_i2c_get_blk_data(struct qup_i2c_dev *qup,
+struct i2c_msg *msg)
+{
+   memset(&qup->blk, 0, sizeof(qup->blk));
+
+   if (!qup->use_v2_tags) {
+   if (!(msg->flags & I2C_M_RD))
+   qup->blk.tx_tag_len = 1;
+   return;
+   }
+
+   qup->blk.data_len = msg->len;
+   qup->blk.count = (msg->len + QUP_READ_LIMIT - 1) / QUP_READ_LIMIT;
+
+   /* 4 bytes for first block and 2 writes for rest */
+   qup->blk.tx_tag_len = 4 + (qup->blk.count - 1) * 2;
+
+   /* There are 2 tag bytes that are read in to fifo for every block */
+   if (msg->flags & I2C_M_RD)
+   qup->blk.rx_tag_len = qup->blk.count * 2;
+}
+
+static int qup_i2c_send_data(struct qup_i2c_dev *qup, int tlen, u8 *tbuf,
+int dlen, u8 *dbuf)
+{
+   u32 val = 0, idx = 0, pos = 0, i = 0, t;
+   int  len = tlen + dlen;
+   u8 *buf = tbuf;
+   int ret = 0;
+
+   while (len > 0) {
+   ret = qup_i2c_wait_ready(qup, QUP_OUT_FULL,
+RESET_BIT, 4 * ONE_BYTE);
+   if (ret) {
+   dev_err(qup->dev, "timeout for fifo out full");
+   return ret;
+   }
+
+ 

[PATCH V4 5/7] i2c: qup: Add bam dma capabilities

[Sricharan R]

QUP cores can be attached to a BAM module, which acts as a dma engine for the
QUP core. When DMA with BAM is enabled, the BAM consumer pipe transmitted data
is written to the output FIFO and the BAM producer pipe received data is read
from the input FIFO.

With BAM capabilities, qup-i2c core can transfer more than 256 bytes, without a
'stop' which is not possible otherwise.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 431 +--
 1 file changed, 415 insertions(+), 16 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index c0757d9..810b021 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -24,6 +24,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 /* QUP Registers */
 #define QUP_CONFIG 0x000
@@ -33,6 +38,7 @@
 #define QUP_OPERATIONAL0x018
 #define QUP_ERROR_FLAGS0x01c
 #define QUP_ERROR_FLAGS_EN 0x020
+#define QUP_OPERATIONAL_MASK   0x028
 #define QUP_HW_VERSION 0x030
 #define QUP_MX_OUTPUT_CNT  0x100
 #define QUP_OUT_FIFO_BASE  0x110
@@ -53,6 +59,7 @@
 
 #define QUP_STATE_VALIDBIT(2)
 #define QUP_I2C_MAST_GEN   BIT(4)
+#define QUP_I2C_FLUSH  BIT(6)
 
 #define QUP_OPERATIONAL_RESET  0x000ff0
 #define QUP_I2C_STATUS_RESET   0xfc
@@ -78,7 +85,10 @@
 
 /* Packing/Unpacking words in FIFOs, and IO modes */
 #define QUP_OUTPUT_BLK_MODE(1 << 10)
+#define QUP_OUTPUT_BAM_MODE(3 << 10)
 #define QUP_INPUT_BLK_MODE (1 << 12)
+#define QUP_INPUT_BAM_MODE (3 << 12)
+#define QUP_BAM_MODE   (QUP_OUTPUT_BAM_MODE | QUP_INPUT_BAM_MODE)
 #define QUP_UNPACK_EN  BIT(14)
 #define QUP_PACK_ENBIT(15)
 
@@ -95,6 +105,8 @@
 #define QUP_TAG_DATA   (2 << 8)
 #define QUP_TAG_STOP   (3 << 8)
 #define QUP_TAG_REC(4 << 8)
+#define QUP_BAM_INPUT_EOT  0x93
+#define QUP_BAM_FLUSH_STOP 0x96
 
 /* QUP v2 tags */
 #define QUP_TAG_V2_START   0x81
@@ -115,6 +127,12 @@
 #define ONE_BYTE   0x1
 #define QUP_I2C_MX_CONFIG_DURING_RUN   BIT(31)
 
+#define MX_TX_RX_LEN   SZ_64K
+#define MX_BLOCKS  (MX_TX_RX_LEN / QUP_READ_LIMIT)
+
+/* Max timeout in ms for 32k bytes */
+#define TOUT_MAX   300
+
 struct qup_i2c_block {
int count;
int pos;
@@ -125,6 +143,23 @@ struct qup_i2c_block {
int config_run;
 };
 
+struct qup_i2c_tag {
+   u8 *start;
+   dma_addr_t addr;
+};
+
+struct qup_i2c_bam_rx {
+   struct  qup_i2c_tag scratch_tag;
+   struct  dma_chan *dma_rx;
+   struct  scatterlist *sg_rx;
+};
+
+struct qup_i2c_bam_tx {
+   struct  qup_i2c_tag footer_tag;
+   struct  dma_chan *dma_tx;
+   struct  scatterlist *sg_tx;
+};
+
 struct qup_i2c_dev {
struct device   *dev;
void __iomem*base;
@@ -154,14 +189,20 @@ struct qup_i2c_dev {
 
int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
 struct i2c_msg *msg);
+   int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
+   struct i2c_msg *msg);
+
/* Current i2c_msg in i2c_msgs */
int cmsg;
/* total num of i2c_msgs */
int num;
 
-   int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
-   struct i2c_msg *msg);
-
+   /* dma parameters */
+   boolis_dma;
+   struct  dma_pool *dpool;
+   struct  qup_i2c_tag start_tag;
+   struct  qup_i2c_bam_rx brx;
+   struct  qup_i2c_bam_tx btx;
struct completion   xfer;
 };
 
@@ -238,6 +279,14 @@ static int qup_i2c_poll_state(struct qup_i2c_dev *qup, u32 
req_state)
return qup_i2c_poll_state_mask(qup, req_state, QUP_STATE_MASK);
 }
 
+static void qup_i2c_flush(struct qup_i2c_dev *qup)
+{
+   u32 val = readl(qup->base + QUP_STATE);
+
+   val |= QUP_I2C_FLUSH;
+   writel(val, qup->base + QUP_STATE);
+}
+
 static int qup_i2c_poll_state_valid(struct qup_i2c_dev *qup)
 {
return qup_i2c_poll_state_mask(qup, 0, 0);
@@ -437,12 +486,15 @@ static int qup_i2c_get_data_len(struct qup_i2c_dev *qup)
 }
 
 static int qup_i2c_get_tags(u8 *tags, struct qup_i2c_dev *qup,
-   struct i2c_msg *msg)
+   struct i2c_msg *msg, int is_dma)
 {
u16 addr = (msg->addr << 1) | ((msg->flags & I2C_M_RD) == I2C_M_RD);
int len = 0;
int data_len;
 
+   int last = (qup->blk.pos == (qup->blk.count - 1)) &&
+   (qup->cmsg == (qup->num - 1));
+
if (qup->blk.pos == 0) {
tags[len++] = QUP_TAG_V2_START;
tags[len++] = addr & 0xff;
@@ -452,8 +504,7 

Re: [PATCH v2] power_supply: rt9455_charger: Properly notify userspace about charging events

[Sebastian Reichel]

Hi,

On Tue, Jul 07, 2015 at 03:25:53PM +0300, Anda-Maria Nicolae wrote:
> Charging events this patch refers to are:
> - charger is connected to/disconnected from the power source
> - battery is reconnected to the charger, after it was absent.
> 
> When the charger is connected to/disconnected from the power source, CHRVPI
> interrupt occurs and PWR_RDY bit is either set or cleared. PWR_RDY bit is
> updated after 1-2 seconds CHRVPI interrupt has occurred.
> power_supply_changed() should be called after PWR_RDY bit is updated.
> /sys/class/power_supply/rt9455-charger/online file displays the value of
> PWR_RDY bit.
> This way, if the userspace is notified that a charging event has occurred
> and the userspace reads /sys/class/power_supply/rt9455-charger/online file,
> this file is properly updated when the userspace reads it.
> This is the reason why power_supply_changed() is called in
> rt9455_pwr_rdy_work_callback(), instead of being called in interrupt
> handler.
> 
> Since no interrupt is triggered when the battery is reconnected to the
> charger, the userspace is never notified that the battery is reconnected.
> This is why power_supply_changed() is called in
> rt9455_max_charging_time_work_callback(), so that the userspace is notified
> that the battery is reconnected.
> 
> Signed-off-by: Anda-Maria Nicolae 

Thanks, queued with Kzrysztof's Reviewed-By.

-- Sebastian


signature.asc
Description: Digital signature

[PATCH V4 7/7] dts: msm8974: Add dma channels for blsp2_i2c1 node

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index f138202..17dcda3 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -284,6 +284,8 @@
clock-names = "core", "iface";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <&blsp2_dma 20>, <&blsp2_dma 21>;
+   dma-names = "tx", "rx";
};
 
spmi_bus: spmi@fc4cf000 {
-- 
QUALCOMM INDIA, on behalf of 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 V4 4/7] i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit

[Sricharan R]

The definition of i2c_msg says that

"If this is the last message in a group, it is followed by a STOP.
Otherwise it is followed by the next @i2c_msg transaction segment,
beginning with a (repeated) START"

So the expectation is that there is no 'STOP' bit inbetween individual
i2c_msg segments with repeated 'START'. The QUP i2c hardware has no way
to inform that there should not be a 'STOP' at the end of transaction.
The only way to implement this is to coalesce all the i2c_msg in i2c_msgs
in to one transaction and transfer them. Adding the support for the same.

This is required for some clients like touchscreen which keeps
incrementing counts across individual transfers and 'STOP' bit inbetween
resets the counter, which is not required.

This patch adds the support in non-dma mode.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 40 ++--
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index a4e20d9..c0757d9 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -113,6 +113,7 @@
 #define SET_BIT0x1
 #define RESET_BIT  0x0
 #define ONE_BYTE   0x1
+#define QUP_I2C_MX_CONFIG_DURING_RUN   BIT(31)
 
 struct qup_i2c_block {
int count;
@@ -121,6 +122,7 @@ struct qup_i2c_block {
int rx_tag_len;
int data_len;
u8  tags[6];
+   int config_run;
 };
 
 struct qup_i2c_dev {
@@ -152,6 +154,10 @@ struct qup_i2c_dev {
 
int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
 struct i2c_msg *msg);
+   /* Current i2c_msg in i2c_msgs */
+   int cmsg;
+   /* total num of i2c_msgs */
+   int num;
 
int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
struct i2c_msg *msg);
@@ -278,7 +284,8 @@ static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int 
op, bool val,
status = readl(qup->base + QUP_I2C_STATUS);
 
if (((opflags & op) >> shift) == val) {
-   if (op == QUP_OUT_NOT_EMPTY) {
+   if ((op == QUP_OUT_NOT_EMPTY) &&
+   (qup->cmsg == (qup->num - 1))) {
if (!(status & I2C_STATUS_BUS_ACTIVE))
return 0;
} else {
@@ -301,12 +308,14 @@ static void qup_i2c_set_write_mode(struct qup_i2c_dev 
*qup, struct i2c_msg *msg)
if (total < qup->out_fifo_sz) {
/* FIFO mode */
writel(QUP_REPACK_EN, qup->base + QUP_IO_MODE);
-   writel(total, qup->base + QUP_MX_WRITE_CNT);
+   writel(total | qup->blk.config_run,
+  qup->base + QUP_MX_WRITE_CNT);
} else {
/* BLOCK mode (transfer data on chunks) */
writel(QUP_OUTPUT_BLK_MODE | QUP_REPACK_EN,
   qup->base + QUP_IO_MODE);
-   writel(total, qup->base + QUP_MX_OUTPUT_CNT);
+   writel(total | qup->blk.config_run,
+  qup->base + QUP_MX_OUTPUT_CNT);
}
 }
 
@@ -374,6 +383,9 @@ static void qup_i2c_get_blk_data(struct qup_i2c_dev *qup,
/* There are 2 tag bytes that are read in to fifo for every block */
if (msg->flags & I2C_M_RD)
qup->blk.rx_tag_len = qup->blk.count * 2;
+
+   if (qup->cmsg)
+   qup->blk.config_run = QUP_I2C_MX_CONFIG_DURING_RUN;
 }
 
 static int qup_i2c_send_data(struct qup_i2c_dev *qup, int tlen, u8 *tbuf,
@@ -440,7 +452,8 @@ static int qup_i2c_get_tags(u8 *tags, struct qup_i2c_dev 
*qup,
}
 
/* Send _STOP commands for the last block */
-   if (qup->blk.pos == (qup->blk.count - 1)) {
+   if (qup->blk.pos == (qup->blk.count - 1)
+   && (qup->cmsg == (qup->num - 1))) {
if (msg->flags & I2C_M_RD)
tags[len++] = QUP_TAG_V2_DATARD_STOP;
else
@@ -571,7 +584,6 @@ static int qup_i2c_write(struct qup_i2c_dev *qup, struct 
i2c_msg *msg)
goto err;
 
ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, RESET_BIT, ONE_BYTE);
-
 err:
disable_irq(qup->irq);
qup->msg = NULL;
@@ -584,18 +596,19 @@ static void qup_i2c_set_read_mode(struct qup_i2c_dev 
*qup, int len)
int tx_len = qup->blk.tx_tag_len;
 
len += qup->blk.rx_tag_len;
+   tx_len |= qup->blk.config_run;
 
if (len < qup->in_fifo_sz) {
/* FIFO mode */
writel(QUP_REPACK_EN, qup->base + QUP_IO_MODE);
-   writel(len, qup->base + QUP_MX_READ_CNT);
writel(tx_len, qup->base + QUP_MX_WRITE_CNT);
+   writel(len | qup->blk.config_run, qup->base + QUP_MX_READ_CNT);
} else {
/* BLOCK mo

[PATCH V4 1/7] i2c: qup: Change qup_wait_writeready function to use for all timeouts

[Sricharan R]

qup_wait_writeready waits only on a output fifo empty event.
Change the same function to accept the event and data length
to wait as parameters. This way the same function can be used for
timeouts in otherplaces as well.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 67 +++-
 1 file changed, 48 insertions(+), 19 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index fdcbdab..81ed120 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -98,6 +98,9 @@
 #define QUP_STATUS_ERROR_FLAGS 0x7c
 
 #define QUP_READ_LIMIT 256
+#define SET_BIT0x1
+#define RESET_BIT  0x0
+#define ONE_BYTE   0x1
 
 struct qup_i2c_dev {
struct device   *dev;
@@ -221,26 +224,42 @@ static int qup_i2c_change_state(struct qup_i2c_dev *qup, 
u32 state)
return 0;
 }
 
-static int qup_i2c_wait_writeready(struct qup_i2c_dev *qup)
+/**
+ * qup_i2c_wait_ready - wait for a give number of bytes in tx/rx path
+ * @qup: The qup_i2c_dev device
+ * @op: The bit/event to wait on
+ * @val: value of the bit to wait on, 0 or 1
+ * @len: The length the bytes to be transferred
+ */
+static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int op, bool val,
+ int len)
 {
unsigned long timeout;
u32 opflags;
u32 status;
+   u32 shift = __ffs(op);
 
-   timeout = jiffies + HZ;
+   len *= qup->one_byte_t;
+   /* timeout after a wait of twice the max time */
+   timeout = jiffies + len * 4;
 
for (;;) {
opflags = readl(qup->base + QUP_OPERATIONAL);
status = readl(qup->base + QUP_I2C_STATUS);
 
-   if (!(opflags & QUP_OUT_NOT_EMPTY) &&
-   !(status & I2C_STATUS_BUS_ACTIVE))
-   return 0;
+   if (((opflags & op) >> shift) == val) {
+   if (op == QUP_OUT_NOT_EMPTY) {
+   if (!(status & I2C_STATUS_BUS_ACTIVE))
+   return 0;
+   } else {
+   return 0;
+   }
+   }
 
if (time_after(jiffies, timeout))
return -ETIMEDOUT;
 
-   usleep_range(qup->one_byte_t, qup->one_byte_t * 2);
+   usleep_range(len, len * 2);
}
 }
 
@@ -261,13 +280,13 @@ static void qup_i2c_set_write_mode(struct qup_i2c_dev 
*qup, struct i2c_msg *msg)
}
 }
 
-static void qup_i2c_issue_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int qup_i2c_issue_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
 {
u32 addr = msg->addr << 1;
u32 qup_tag;
-   u32 opflags;
int idx;
u32 val;
+   int ret = 0;
 
if (qup->pos == 0) {
val = QUP_TAG_START | addr;
@@ -279,9 +298,10 @@ static void qup_i2c_issue_write(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
 
while (qup->pos < msg->len) {
/* Check that there's space in the FIFO for our pair */
-   opflags = readl(qup->base + QUP_OPERATIONAL);
-   if (opflags & QUP_OUT_FULL)
-   break;
+   ret = qup_i2c_wait_ready(qup, QUP_OUT_FULL, RESET_BIT,
+4 * ONE_BYTE);
+   if (ret)
+   return ret;
 
if (qup->pos == msg->len - 1)
qup_tag = QUP_TAG_STOP;
@@ -300,6 +320,8 @@ static void qup_i2c_issue_write(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
qup->pos++;
idx++;
}
+
+   return ret;
 }
 
 static int qup_i2c_write_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
@@ -325,7 +347,9 @@ static int qup_i2c_write_one(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
if (ret)
goto err;
 
-   qup_i2c_issue_write(qup, msg);
+   ret = qup_i2c_issue_write(qup, msg);
+   if (ret)
+   goto err;
 
ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
if (ret)
@@ -347,7 +371,7 @@ static int qup_i2c_write_one(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
} while (qup->pos < msg->len);
 
/* Wait for the outstanding data in the fifo to drain */
-   ret = qup_i2c_wait_writeready(qup);
+   ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, RESET_BIT, ONE_BYTE);
 
 err:
disable_irq(qup->irq);
@@ -384,18 +408,19 @@ static void qup_i2c_issue_read(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
 }
 
 
-static void qup_i2c_read_fifo(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int qup_i2c_read_fifo(struct qup_i2c_dev *qup, struct i2c_msg *msg)
 {
-   u32 opflags;
u32 val = 0;
int

[PATCH V4 6/7] dts: msm8974: Add blsp2_bam dma node

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 37b47b5..f138202 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-#include 
+#include 
 #include 
 #include "skeleton.dtsi"
 
@@ -301,5 +301,15 @@
interrupt-controller;
#interrupt-cells = <4>;
};
+
+   blsp2_dma: dma-controller@f9944000 {
+   compatible = "qcom,bam-v1.4.0";
+   reg = <0xf9944000 0x19000>;
+   interrupts = ;
+   clocks = <&gcc GCC_BLSP2_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   };
};
 };
-- 
QUALCOMM INDIA, on behalf of 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 V4 2/7] qup: i2c: factor out common code for reuse

[Sricharan R]

The qup_i2c_write/read_one functions can be split to have
the common initialization code and function to loop around
the data bytes separately. This way the initialization code
can be reused while adding v2 tags functionality.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 147 +--
 1 file changed, 87 insertions(+), 60 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 81ed120..131dc28 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -324,53 +324,72 @@ static int qup_i2c_issue_write(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
return ret;
 }
 
-static int qup_i2c_write_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int qup_i2c_wait_for_complete(struct qup_i2c_dev *qup,
+struct i2c_msg *msg)
 {
unsigned long left;
-   int ret;
-
-   qup->msg = msg;
-   qup->pos = 0;
+   int ret = 0;
 
-   enable_irq(qup->irq);
+   left = wait_for_completion_timeout(&qup->xfer, HZ);
+   if (!left) {
+   writel(1, qup->base + QUP_SW_RESET);
+   ret = -ETIMEDOUT;
+   }
 
-   qup_i2c_set_write_mode(qup, msg);
+   if (qup->bus_err || qup->qup_err) {
+   if (qup->bus_err & QUP_I2C_NACK_FLAG) {
+   dev_err(qup->dev, "NACK from %x\n", msg->addr);
+   ret = -EIO;
+   }
+   }
 
-   ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
-   if (ret)
-   goto err;
+   return ret;
+}
 
-   writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL);
+static int qup_i2c_write_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+{
+   int ret = 0;
 
do {
ret = qup_i2c_change_state(qup, QUP_PAUSE_STATE);
if (ret)
-   goto err;
+   return ret;
 
ret = qup_i2c_issue_write(qup, msg);
if (ret)
-   goto err;
+   return ret;
 
ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
if (ret)
-   goto err;
-
-   left = wait_for_completion_timeout(&qup->xfer, HZ);
-   if (!left) {
-   writel(1, qup->base + QUP_SW_RESET);
-   ret = -ETIMEDOUT;
-   goto err;
-   }
+   return ret;
 
-   if (qup->bus_err || qup->qup_err) {
-   if (qup->bus_err & QUP_I2C_NACK_FLAG)
-   dev_err(qup->dev, "NACK from %x\n", msg->addr);
-   ret = -EIO;
-   goto err;
-   }
+   ret = qup_i2c_wait_for_complete(qup, msg);
+   if (ret)
+   return ret;
} while (qup->pos < msg->len);
 
-   /* Wait for the outstanding data in the fifo to drain */
+   return ret;
+}
+
+static int qup_i2c_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+{
+   int ret;
+
+   qup->msg = msg;
+   qup->pos = 0;
+   enable_irq(qup->irq);
+   qup_i2c_set_write_mode(qup, msg);
+
+   ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
+   if (ret)
+   goto err;
+
+   writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL);
+
+   ret = qup_i2c_write_one(qup, msg);
+   if (ret)
+   goto err;
+
ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, RESET_BIT, ONE_BYTE);
 
 err:
@@ -436,51 +455,59 @@ static int qup_i2c_read_fifo(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
 
 static int qup_i2c_read_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
 {
-   unsigned long left;
-   int ret;
+   int ret = 0;
 
-   qup->msg = msg;
-   qup->pos  = 0;
+   /*
+* The QUP block will issue a NACK and STOP on the bus when reaching
+* the end of the read, the length of the read is specified as one byte
+* which limits the possible read to 256 (QUP_READ_LIMIT) bytes.
+*/
+   if (msg->len > QUP_READ_LIMIT) {
+   dev_err(qup->dev, "HW not capable of reads over %d bytes\n",
+   QUP_READ_LIMIT);
+   return -EINVAL;
+   }
 
-   enable_irq(qup->irq);
+   ret = qup_i2c_change_state(qup, QUP_PAUSE_STATE);
+   if (ret)
+   return ret;
 
-   qup_i2c_set_read_mode(qup, msg->len);
+   qup_i2c_issue_read(qup, msg);
 
ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
if (ret)
-   goto err;
+   return ret;
 
-   writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL);
+   do {
+   ret = qup_i2c_wait_for_complete(qup, msg);
+   if (ret)
+   return ret;
+   ret = qup_i2c_read_fifo(qup, msg);
+   if (ret)
+   re

[PATCH V4 0/7] i2c: qup: Add support for v2 tags and bam dma

[Sricharan R]

QUP from version 2.1.1 onwards, supports a new format of i2c command tags.
Tag codes instructs the controller to perform a operation like read/write.
This new tagging version supports and is required for adding bam dma
capabilities. V2 tags supports transfer of more than 256 bytes in a single
i2c transaction. Also adding bam dma support facilitates transferring each
i2c_msg in i2c_msgs without a 'stop' bit in between which is required for some
of the clients.

Tested this series on apq8074 dragon board eeprom client on i2c bus1

[V4] Added a patch to factor out some common code.
 Removed support for freq > 400KHZ as per comments.
 Addressed comments from Ivan T. Ivanov to keep the code for
 V2 support in a separate path. 
 Changed the authorship of V2 tags support patch.

[V3] Added support to coalesce each i2c_msg in i2c_msgs for fifo and
 block mode in Patch 2. Also addressed further code comments.

 http://comments.gmane.org/gmane.linux.drivers.i2c/22497

[V2] Addressed comments from Ivan T. Ivanov, Andy Gross [v1] Initial Version

Sricharan R (7):
  i2c: qup: Change qup_wait_writeready function to use for all timeouts
  qup: i2c: factor out common code for reuse
  i2c: qup: Add V2 tags support
  i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit
  i2c: qup: Add bam dma capabilities
  dts: msm8974: Add blsp2_bam dma node
  dts: msm8974: Add dma channels for blsp2_i2c1 node

 arch/arm/boot/dts/qcom-msm8974.dtsi |  14 +-
 drivers/i2c/busses/i2c-qup.c| 943 +---
 2 files changed, 880 insertions(+), 77 deletions(-)

-- 
QUALCOMM INDIA, on behalf of 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/

Re: [PATCH] kthread: export park/unpark facility

[Peter Hurley]

On 07/08/2015 08:40 PM, Jean Tourrilhes wrote:
>   Hi,
> 
>   The kthread park/unpark facility is not used in the kernel

kernel/smpboot.c ?


> , so one would assume that it's made for kernel modules. This patch should
> definitely help most modules.
>   Patch untested, at your own risks...
>   Regards,
> 
>   Jean
> 
> Signed-off-by: Jean Tourrilhes 
> 
> diff -u -p linux-3.18.17/kernel/kthread.j2.c linux-3.18.17/kernel/kthread.c
> --- linux-3.18.17/kernel/kthread.j2.c 2015-07-08 17:01:39.010554169 -0700
> +++ linux-3.18.17/kernel/kthread.c2015-07-08 17:09:13.016096189 -0700
> @@ -97,6 +97,7 @@ bool kthread_should_park(void)
>  {
>   return test_bit(KTHREAD_SHOULD_PARK, &to_kthread(current)->flags);
>  }
> +EXPORT_SYMBOL(kthread_should_park);
>  
>  /**
>   * kthread_freezable_should_stop - should this freezable kthread return now?
> @@ -171,6 +172,7 @@ void kthread_parkme(void)
>  {
>   __kthread_parkme(to_kthread(current));
>  }
> +EXPORT_SYMBOL(kthread_parkme);
>  
>  static int kthread(void *_create)
>  {
> @@ -411,6 +413,7 @@ void kthread_unpark(struct task_struct *
>   if (kthread)
>   __kthread_unpark(k, kthread);
>  }
> +EXPORT_SYMBOL(kthread_unpark);
>  
>  /**
>   * kthread_park - park a thread created by kthread_create().
> @@ -441,6 +444,7 @@ int kthread_park(struct task_struct *k)
>   }
>   return ret;
>  }
> +EXPORT_SYMBOL(kthread_park);
>  
>  /**
>   * kthread_stop - stop a thread created by kthread_create().

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

[Linus Torvalds]

On Wed, Jul 8, 2015 at 5:58 PM, Ming Lei  wrote:
> On Thu, Jul 9, 2015 at 1:29 AM, Linus Torvalds
>  wrote:
>> Also, it looks like you need to hold the "fw_lock" to even look at
>> that pointer, since the buffer can get reallocated etc.
>
> Yes, the above code with holding 'fw_lock' is right fix for the issue since
> sysfs read can happen anytime, and there is one race between firmware
> request abort and reading uevent of sysfs.

So if fw_priv->buf is NULL, what should we do?

Should we skip the TIMEOUT= and ASYNC= fields too?

Something like the attached, perhaps?

Shuah, how reproducible is this? Does this (completely untested) patch
make any difference?

  Linus
 drivers/base/firmware_class.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 9c4288362a8e..894bda114224 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -563,10 +563,8 @@ static void fw_dev_release(struct device *dev)
kfree(fw_priv);
 }
 
-static int firmware_uevent(struct device *dev, struct kobj_uevent_env *env)
+static int do_firmware_uevent(struct firmware_priv *fw_priv, struct 
kobj_uevent_env *env)
 {
-   struct firmware_priv *fw_priv = to_firmware_priv(dev);
-
if (add_uevent_var(env, "FIRMWARE=%s", fw_priv->buf->fw_id))
return -ENOMEM;
if (add_uevent_var(env, "TIMEOUT=%i", loading_timeout))
@@ -577,6 +575,18 @@ static int firmware_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+static int firmware_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+   struct firmware_priv *fw_priv = to_firmware_priv(dev);
+   int err = 0;
+
+   mutex_lock(&fw_lock);
+   if (fw_priv->buf)
+   err = do_firmware_uevent(fw_priv, env);
+   mutex_unlock(&fw_lock);
+   return err;
+}
+
 static struct class firmware_class = {
.name   = "firmware",
.class_attrs= firmware_class_attrs,

[PATCH V3 1/1] usb:serial:f81534 add F81532/534 driver

[Peter Hung]

This driver is for Fintek F81532/F81534 USB to Serial Ports IC.

Features:
1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC
2. Support Baudrate from B50 to B150 (excluding B100).
3. The RTS signal can be transformed their behavior with
   configuration by default ioctl TIOCGRS485/TIOCSRS485
   (for RS232/RS485/RS422 with transceiver)

   If the driver setting with SER_RS485_ENABLED, the RTS signal will
   high with not in TX and low with in TX.

   If the driver setting with SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND,
   the RTS signal will low with not in TX and high with in TX.

4. There are 4x3 output-only ic pins to control transceiver mode.
   It's can be controlled via gpiolib. We could found the gpio
   number from /sys/class/tty/ttyUSB[x]/device/gpiochap[yyy] where
   x is F81532/534 serial port and yyy is gpiochip number.

   After we found chip number, we can export 3 gpios(M2/M1/M0) per
   serial port by
  echo yyy > /sys/class/gpio/export
  echo yyy+1 > /sys/class/gpio/export
  echo yyy+2 > /sys/class/gpio/export

   then we can control it with
  echo [M0 value] > /sys/class/gpio/gpio[yyy]/value
  echo [M1 value] > /sys/class/gpio/gpio[yyy+1]/value
  echo [M2 value] > /sys/class/gpio/gpio[yyy+2]/value
   which M0/M1/M2 as your desired value, value is only 0 or 1.

   When configure complete, It's a must to free all gpio by
  echo yyy > /sys/class/gpio/unexport
  echo yyy+1 > /sys/class/gpio/unexport
  echo yyy+2 > /sys/class/gpio/unexport

   The driver will "save" gpio configure after we release
   all gpio of a serial port.

   For examples to change mode & gpio with F81532/534
   Evalaution Board.

   F81532 EVB
  port0: F81437 (RS232 only)
  port1: F81439 (RS232/RS485/RS422 ... etc.)
   F81534 EVB
  port0/1: F81437 (RS232 only)
  port2/3: F81439 (RS232/RS485/RS422 ... etc.)

  1. RS232 Mode (Default IC Mode)
 1. Set struct serial_rs485 flags "without" SER_RS485_ENABLED
(control F81532/534 RTS control)
 2. Set M2/M1/M0 as 0/0/1
(control F81532/534 output pin to control transceiver mode)

  2. RS485 Mode (RTS Low when TX Mode)
 1. Set struct serial_rs485 flags with SER_RS485_ENABLED
 2. Set M2/M1/M0 as 0/1/0

  3. RS485 Mode (RTS High when TX Mode)
 1. Set struct serial_rs485 flags with SER_RS485_ENABLED and
SER_RS485_RTS_ON_SEND
 2. Set M2/M1/M0 as 0/1/1

  4. RS422 Mode
 1. The RTS mode is dont care.
 2. Set M2/M1/M0 as 0/0/0

   Please reference https://bitbucket.org/hpeter/fintek-general/src/
   with f81534/tools to get set_gpio.c & set_mode.c. Please use it
   carefully.

Changelog
v3
1. Migrate read, write and some routine from custom code to usbserial
   subsystem callback function.
2. Use more defines to replece magic numbers to make it meaningful
3. Make more comments as document in source code.

v2
1. v1 version submit to staging tree, but Greg KH advised me to
   cleanup source code & re-submit it to correct subsystem
2. Remove all custom ioctl commands

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/Kconfig  |   10 +
 drivers/usb/serial/Makefile |1 +
 drivers/usb/serial/f81534.c | 3316 +++
 3 files changed, 3327 insertions(+)
 create mode 100644 drivers/usb/serial/f81534.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 56ecb8b..0642864 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -255,6 +255,16 @@ config USB_SERIAL_F81232
  To compile this driver as a module, choose M here: the
  module will be called f81232.
 
+config USB_SERIAL_F8153X
+   tristate "USB Fintek F81532/534 Multi-Ports Serial Driver"
+   help
+ Say Y here if you want to use the Fintek F81532/534 Multi-Ports
+ usb to serial adapter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called f81534.
+
+
 config USB_SERIAL_GARMIN
tristate "USB Garmin GPS driver"
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 349d9df..9e43b7b 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_USB_SERIAL_EDGEPORT) += io_edgeport.o
 obj-$(CONFIG_USB_SERIAL_EDGEPORT_TI)   += io_ti.o
 obj-$(CONFIG_USB_SERIAL_EMPEG) += empeg.o
 obj-$(CONFIG_USB_SERIAL_F81232)+= f81232.o
+obj-$(CONFIG_USB_SERIAL_F8153X)+= f81534.o
 obj-$(CONFIG_USB_SERIAL_FTDI_SIO)  += ftdi_sio.o
 obj-$(CONFIG_USB_SERIAL_GARMIN)+= garmin_gps.o
 obj-$(CONFIG_USB_SERIAL_IPAQ)  += ipaq.o
diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
new file mode 100644
index 000..8aa0b51
--- /dev/null
+++ b/drivers/usb/serial/f81534.c
@@ -

[PATCH] m32r: Add ioreadXX/iowriteXX big-endian mmio accessors

[Peter Hurley]

commit c627f2ceb692 ("serial: 8250: Add support for big-endian MMIO accesses")
added support for 32-bit big-endian mmio to the 8250 driver. Support for
ioreadXXbe/iowriteXXbe io accessors was missing from m32r arch, which caused
build errors.

Add trivial macro mmio accessors.

Reported-by: Fengguang Wu 
Cc: Kevin Cernekee 
Signed-off-by: Peter Hurley 
---
 arch/m32r/include/asm/io.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 9cc00db..d7a034d 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -173,6 +173,11 @@ static inline void _writel(unsigned long l, unsigned long 
addr)
 #define iowrite16 writew
 #define iowrite32 writel
 
+#define ioread16be(addr)   be16_to_cpu(readw(addr))
+#define ioread32be(addr)   be32_to_cpu(readl(addr))
+#define iowrite16be(v, addr)   writew(cpu_to_be16(v), (addr))
+#define iowrite32be(v, addr)   writel(cpu_to_be32(v), (addr))
+
 #define mmiowb()
 
 #define flush_write_buffers() do { } while (0)  /* M32R_FIXME */
-- 
2.4.5

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

[PATCH] ASoC: mediatek: Use platform_of_node for machine drivers

[Koro Chen]

This replaces the platform_name in snd_soc_dai_link by device tree node.

Signed-off-by: Koro Chen 
---
 .../devicetree/bindings/sound/mt8173-max98090.txt |  2 ++
 .../bindings/sound/mt8173-rt5650-rt5676.txt   |  2 ++
 sound/soc/mediatek/mt8173-max98090.c  | 17 +
 sound/soc/mediatek/mt8173-rt5650-rt5676.c | 19 +++
 4 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/mt8173-max98090.txt 
b/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
index 829bd26..519e97c 100644
--- a/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
+++ b/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
@@ -3,11 +3,13 @@ MT8173 with MAX98090 CODEC
 Required properties:
 - compatible : "mediatek,mt8173-max98090"
 - mediatek,audio-codec: the phandle of the MAX98090 audio codec
+- mediatek,platform: the phandle of MT8173 ASoC platform
 
 Example:
 
sound {
compatible = "mediatek,mt8173-max98090";
mediatek,audio-codec = <&max98090>;
+   mediatek,platform = <&afe>;
};
 
diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt 
b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt
index 61e98c9..f205ce9 100644
--- a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt
+++ b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt
@@ -3,11 +3,13 @@ MT8173 with RT5650 RT5676 CODECS
 Required properties:
 - compatible : "mediatek,mt8173-rt5650-rt5676"
 - mediatek,audio-codec: the phandles of rt5650 and rt5676 codecs
+- mediatek,platform: the phandle of MT8173 ASoC platform
 
 Example:
 
sound {
compatible = "mediatek,mt8173-rt5650-rt5676";
mediatek,audio-codec = <&rt5650 &rt5676>;
+   mediatek,platform = <&afe>;
};
 
diff --git a/sound/soc/mediatek/mt8173-max98090.c 
b/sound/soc/mediatek/mt8173-max98090.c
index 4d44b58..2d2536a 100644
--- a/sound/soc/mediatek/mt8173-max98090.c
+++ b/sound/soc/mediatek/mt8173-max98090.c
@@ -103,7 +103,6 @@ static struct snd_soc_dai_link mt8173_max98090_dais[] = {
.name = "MAX98090 Playback",
.stream_name = "MAX98090 Playback",
.cpu_dai_name = "DL1",
-   .platform_name = "1122.mt8173-afe-pcm",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
.trigger = {SND_SOC_DPCM_TRIGGER_POST, 
SND_SOC_DPCM_TRIGGER_POST},
@@ -114,7 +113,6 @@ static struct snd_soc_dai_link mt8173_max98090_dais[] = {
.name = "MAX98090 Capture",
.stream_name = "MAX98090 Capture",
.cpu_dai_name = "VUL",
-   .platform_name = "1122.mt8173-afe-pcm",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
.trigger = {SND_SOC_DPCM_TRIGGER_POST, 
SND_SOC_DPCM_TRIGGER_POST},
@@ -125,7 +123,6 @@ static struct snd_soc_dai_link mt8173_max98090_dais[] = {
{
.name = "Codec",
.cpu_dai_name = "I2S",
-   .platform_name = "1122.mt8173-afe-pcm",
.no_pcm = 1,
.codec_dai_name = "HiFi",
.init = mt8173_max98090_init,
@@ -152,9 +149,21 @@ static struct snd_soc_card mt8173_max98090_card = {
 static int mt8173_max98090_dev_probe(struct platform_device *pdev)
 {
struct snd_soc_card *card = &mt8173_max98090_card;
-   struct device_node *codec_node;
+   struct device_node *codec_node, *platform_node;
int ret, i;
 
+   platform_node = of_parse_phandle(pdev->dev.of_node,
+"mediatek,platform", 0);
+   if (!platform_node) {
+   dev_err(&pdev->dev, "Property 'platform' missing or invalid\n");
+   return -EINVAL;
+   }
+   for (i = 0; i < card->num_links; i++) {
+   if (mt8173_max98090_dais[i].platform_name)
+   continue;
+   mt8173_max98090_dais[i].platform_of_node = platform_node;
+   }
+
codec_node = of_parse_phandle(pdev->dev.of_node,
  "mediatek,audio-codec", 0);
if (!codec_node) {
diff --git a/sound/soc/mediatek/mt8173-rt5650-rt5676.c 
b/sound/soc/mediatek/mt8173-rt5650-rt5676.c
index 0940553..6f52eca 100644
--- a/sound/soc/mediatek/mt8173-rt5650-rt5676.c
+++ b/sound/soc/mediatek/mt8173-rt5650-rt5676.c
@@ -138,7 +138,6 @@ static struct snd_soc_dai_link mt8173_rt5650_rt5676_dais[] 
= {
.name = "rt5650_rt5676 Playback",
.stream_name = "rt5650_rt5676 Playback",
.cpu_dai_name = "DL1",
-   .platform_name = "1122.mt8173-afe-pcm",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
  

[PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue

[rcodin]

From: Ronit Halder 

Fixed a coding style issue.

Signed-off-by: Ronit Halder 
---
 drivers/staging/android/ion/ion.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 6f48112..e44f5e6 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1106,6 +1106,7 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
*client,
struct ion_buffer *buffer;
struct dma_buf *dmabuf;
bool valid_handle;
+
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
 
mutex_lock(&client->lock);
-- 
1.9.1

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

Re: Significant performance difference for postgres w/o sched_autogroup

[Mike Galbraith]

On Wed, 2015-07-08 at 17:45 +0200, Andres Freund wrote:

> Workload:
> 
> postgresql (multi-process via shared memory SQL server) and benchmark
> client (pgbench, multi threaded) running on the same server. Connected
> using unix sockets.  The statements are relatively simple (~1.5ms on
> average), forcing frequent back/forth between server processes and
> pgbench threads.
> 
> I found that disabling sched_autogroup *significantly* reduces
> throughput. Even when both server and client are started from the same
> terminal and thus should be in the same group!
> 
> There's a significant difference in how %sys with autogroups
> enabled/disabled. ~8% v ~27%. That sounds too much.

Seems reasonable to me.  1(tg)/2(tgs) > 1(task)/N(tasks), throughput is
what the server can sustain on its given budget, larger budget means
less client blockage, thus less %sys.

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

Re: [PATCH v4 1/3] dt-bindings: pwm: add MediaTek display PWM bindings

[YH Huang]

On Wed, 2015-07-08 at 20:11 +0800, Daniel Kurtz wrote:
> On Mon, Jul 6, 2015 at 9:29 PM, YH Huang  wrote:
> > Document the device-tree binding of MediatTek display PWM.
> > The PWM has one channel to control the backlight brightness for display.
> > It supports MT8173 and MT6595.
> >
> > Signed-off-by: YH Huang 
> > ---
> >  .../devicetree/bindings/pwm/pwm-mtk-disp.txt   | 24 
> > ++
> >  1 file changed, 24 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt 
> > b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > new file mode 100644
> > index 000..757b974
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > @@ -0,0 +1,24 @@
> > +MediaTek display PWM controller
> > +
> > +Required properties:
> > + - compatible: should be "mediatek,-disp-pwm"
> > +   - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> > +   - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> > + - reg: physical base address and length of the controller's registers
> > + - #pwm-cells: must be 2. See pwm.txt in this directory for a description 
> > of
> > +   the cell format
> > + - clocks: phandle and clock specifier of the PWM reference clock
> > + - clock-names: must contain the following
> > +   - "main": clock used to generate PWM signals
> > +   - "mm": sync signals from the modules of mmsys
> > +
> > +Example:
> > +   pwm0: pwm@1401e000 {
> > +   compatible = "mediatek,mt8173-disp-pwm",
> > +"mediatek,mt6595-disp-pwm";
> > +   reg = <0 0x1401e000 0 0x1000>;
> > +   #pwm-cells = <2>;
> > +   clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> > +<&mmsys CLK_MM_DISP_PWM0MM>;
> > +   clock-names = "main", "mm";
> 
> Should we include the pinctrl settings here to enable the PWM output?
> 

Since we use pwm-backlight driver to control backlight, we should enable
PWM output in the backlight node.

Ref:
https://www.kernel.org/doc/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt

Regards,
YH Huang

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

Re: [PATCH 2/4] KVM: SVM: use NPT page attributes

[Xiao Guangrong]

On 07/08/2015 07:19 PM, Paolo Bonzini wrote:



On 08/07/2015 07:59, Xiao Guangrong wrote:



On 07/07/2015 09:45 PM, Paolo Bonzini wrote:

Right now, NPT page attributes are not used, and the final page
attribute depends solely on gPAT (which however is not synced
correctly), the guest MTRRs and the guest page attributes.

However, we can do better by mimicking what is done for VMX.
In the absence of PCI passthrough, the guest PAT can be ignored
and the page attributes can be just WB.  If passthrough is being
used, instead, keep respecting the guest PAT, and emulate the guest
MTRRs through the PAT field of the nested page tables.

The only snag is that WP memory cannot be emulated correctly,
because Linux's default PAT setting only includes the other types.

Signed-off-by: Paolo Bonzini 
---
   arch/x86/kvm/svm.c | 47 ++-
   1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 602b974a60a6..0f125c1860ec 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1085,6 +1085,47 @@ static u64 svm_compute_tsc_offset(struct
kvm_vcpu *vcpu, u64 target_tsc)
   return target_tsc - tsc;
   }

+static void svm_set_guest_pat(struct vcpu_svm *svm, u64 *g_pat)
+{
+struct kvm_vcpu *vcpu = &svm->vcpu;
+
+/* Unlike Intel, AMD takes the guest's CR0.CD into account.


I noticed this code in svm_set_cr0():

 if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_CD_NW_CLEARED))
 cr0 &= ~(X86_CR0_CD | X86_CR0_NW);

gCR0.CD is hidden to CPU if KVM_QUIRK_CD_NW_CLEARED is not set and looks
like
it is the normal case after grepping Qemu code.



How about this one? I still do not know how SVM properly emulates CR0.CD? :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND 2][PATCH v4] hexdump: fix for non-aligned buffers

[Andrew Morton]

On Thu, 9 Jul 2015 03:36:02 +0200 "H. Mijail"  wrote:

> 
> > On 09 Jul 2015, at 02:03, Andrew Morton  wrote:
> > 
> > On Thu, 9 Jul 2015 01:44:18 +0200 Horacio Mijail Ant__n Quiles 
> >  wrote:
> > 
> >> An hexdump with a buf not aligned to the groupsize causes
> >> non-naturally-aligned memory accesses. This was causing a kernel panic on
> >> the processor BlackFin BF527, when such an unaligned buffer was fed by the
> >> function ubifs_scanned_corruption in fs/ubifs/scan.c .
> >> 
> >> To fix this, if the buffer is not aligned to groupsize in a platform which
> >> does not define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, then change the
> >> groupsize to 1, so alignment is no longer a problem.
> >> This behavior is coherent with the way the function currently deals with
> >> inappropriate parameter combinations, which is to fall back to safe
> >> "defaults", even if that means changing the output format and the implicit
> >> access patterns that could have been expected.
> > 
> > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS seems inappropriate for this. 
> > Having this unset means "can do unaligned accesses, but they're
> > inefficient".  It doesn't mean "unaligned accesses go oops".
> > 
> > But I can't the appropriate config knob.  There's a
> > CONFIG_CPU_HAS_NO_UNALIGNED, but that's an m68k-private thing.
> 
> I'm only a newbie, but I will argue that the lesser evil is checking
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS - until a new configure variable
> is defined.
> 
> In Documentation/unaligned-memory-access.txt, an undefined
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is taken as if to mean 'the 
> hardware isn't able to access memory on arbitrary boundaries'.

hm, yes, OK, CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is a poor name.

> The other alternative in Documentation/unaligned-memory-access.txt is the
> macro get_unaligned() from asm/unaligned.h. However, using get_unaligned()
> would mean a much more intrusive patch, since each case of the groupsize 
> would be changed, and anyway we would still need to check 
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to avoid penalising everyone.

Actually, I think using get_unaligned() would be a better solution. 
For architectures which have CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y,
get_unaligned() should be fast - just one instruction.

This way we avoid having different-appearing output on different
architectures.  

> >> Resent on 8 Jul because of no answers.
> >> 
> >> Resent on 29 Jun because of no answers.
> > 
> > During the merge window.  So I have everything sitting there in my
> > patches-to-process pile.  The backlog is excessive this time (700+
> > emails) so I'm thinking I'll change things so I'll henceforth be
> > processing patches-for-the-next-cycle during this-cycle, while keeping
> > patches-for-next-cycle out of linux-next.
> 
> No problem for me - if I should squelch the next version of this patch
> for some time, please let me know.

The merge window has ended ;)

> > 
> > But as mentioned above, that's different from "architectures which do
> > not support them efficently"!  Maybe we need a new config variable.
> > 
> > Or maybe blackfin should be handling the unaligned access trap and
> > transparently handling it, like sparc?
> > 
> 
> I'll wait for anyone else to weight in'

Possibly blackfin *could* emulate unaligned accesses.  But according to
the documentation, hex_dump_to_buffer() needs to be altered anyway
because we cannot rely on the architecture handling such accesses.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: add missing rcu_read_lock for task_pgrp

[Peter Hurley]

On 06/29/2015 07:59 PM, Patrick Donnelly wrote:
> task_pgrp requires an rcu or tasklist lock to be obtained if the returned pid
> is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the
> duration of use.

Reviewed-by: Peter Hurley 

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

Re: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

[Dave Chinner]

On Wed, Jul 08, 2015 at 10:06:10PM +0800, juncheng bai wrote:
> Hi, All
> 
> As far as I know, the patch b3f03bac8132207a20286d5602eda64500c19724
> solves one case which big directory size.
> 
> I am not very familiar with xfs, but I think why can't we use vmalloc
> when kmalloc fails?

Because vmalloc space is greatly limited on 32 bit machines and
hence we can't just use vmalloc blindly in these situations.

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] cxl: Destroy cxl_adapter_idr on module_exit

[Ian Munsie]

Acked-by: Ian Munsie 

We are probably also missing an idr_destroy(&afu->contexts_idr); in
cxl_release_afu() as well if you wanted to send a patch for that.

Cheers,
-Ian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v9 5/8] PCI: Add pci_iomap_wc() variants

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

PCI BARs tell us whether prefetching is safe, but they don't say
anything about write combining (WC). WC changes ordering rules and
allows writes to be collapsed, so it's not safe in general to use it on
a prefetchable region.

Add pci_iomap_wc() and pci_iomap_wc_range() so drivers can take advantage
of write combining when they know it's safe.

On architectures that don't fully support WC, e.g., x86 without PAT,
drivers for legacy framebuffers may get some of the benefit by using
arch_phys_wc_add() in addition to pci_iomap_wc().  But arch_phys_wc_add()
is unreliable and should be avoided in general.  On x86, it uses MTRRs,
which are limited in number and size, so the results will vary based on
driver loading order.

The goals of adding pci_iomap_wc() are to:

- Give drivers an architecture-independent way to use WC so they can stop
  using interfaces like mtrr_add() (on x86, pci_iomap_wc() uses
  PAT when available).

- Move toward using _PAGE_CACHE_MODE_UC, not _PAGE_CACHE_MODE_UC_MINUS,
  on x86 on ioremap_nocache() (see de33c442ed2a ("x86 PAT: fix
  performance drop for glx, use UC minus for ioremap(), ioremap_nocache()
  and pci_mmap_page_range()").

Signed-off-by: Luis R. Rodriguez 
Acked-by: Arnd Bergmann 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Antonino Daplas 
Cc: Arnd Bergmann 
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Bjorn Helgaas 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Dave Hansen 
Cc: Davidlohr Bueso 
Cc: david.vra...@citrix.com
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: jbeul...@suse.com
Cc: Jean-Christophe Plagniol-Villard 
Cc: Juergen Gross 
Cc: konrad.w...@oracle.com
Cc: linux-a...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mel Gorman 
Cc: "Michael S. Tsirkin" 
Cc: Roger Pau Monné 
Cc: Rusty Russell 
Cc: Stefan Bader 
Cc: Suresh Siddha 
Cc: Thomas Gleixner 
Cc: Tomi Valkeinen 
Cc: Toshi Kani 
Cc: venkatesh.pallip...@intel.com
Cc: Ville Syrjälä 
Cc: Vlastimil Babka 
Link: 
http://lkml.kernel.org/r/1426893517-2511-6-git-send-email-mcg...@do-not-panic.com
Link: 
http://lkml.kernel.org/r/1435195342-26879-6-git-send-email-mcg...@do-not-panic.com
[ Move IORESOURCE_IO check up, space out statements for better readability. ]
Signed-off-by: Borislav Petkov 
---
 include/asm-generic/pci_iomap.h | 14 +
 lib/pci_iomap.c | 66 +
 2 files changed, 80 insertions(+)

diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index 7389c87116a0..b1e17fcee2d0 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -15,9 +15,13 @@ struct pci_dev;
 #ifdef CONFIG_PCI
 /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
 extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long 
max);
+extern void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long 
max);
 extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
 unsigned long offset,
 unsigned long maxlen);
+extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+   unsigned long offset,
+   unsigned long maxlen);
 /* Create a virtual mapping cookie for a port on a given PCI device.
  * Do not call this directly, it exists to make it easier for architectures
  * to override */
@@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev, 
int bar, unsigned lon
return NULL;
 }
 
+static inline void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, 
unsigned long max)
+{
+   return NULL;
+}
 static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen)
 {
return NULL;
 }
+static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+  unsigned long offset,
+  unsigned long maxlen)
+{
+   return NULL;
+}
 #endif
 
 #endif /* __ASM_GENERIC_IO_H */
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index bcce5f149310..5f5d24d1d53f 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -52,6 +52,51 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
 EXPORT_SYMBOL(pci_iomap_range);
 
 /**
+ * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @offset: map memory at the given offset in BAR
+ * @maxlen: max length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the corre

Re: [PATCH v5 2/2] cpufreq: mediatek: Add MT8173 cpufreq driver

[Pi-Cheng Chen]

Hi Viresh,

On Wed, Jul 8, 2015 at 7:34 PM, Viresh Kumar  wrote:
> On 01-07-15, 10:16, Pi-Cheng Chen wrote:
>> This patch implements MT8173 cpufreq driver.
>
> Now that you are going to resend this patchset, a few more comments.
>
> Please describe your SoC a bit here, so that reviewers know what are
> we going to implement.

Yes. I will add it.

>
>> +static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
>> +{
>> + struct device *cpu_dev;
>> + struct regulator *proc_reg = ERR_PTR(-ENODEV);
>> + struct regulator *sram_reg = ERR_PTR(-ENODEV);
>> + struct clk *cpu_clk = ERR_PTR(-ENODEV);
>> + struct clk *inter_clk = ERR_PTR(-ENODEV);
>> + struct dev_pm_opp *opp;
>> + unsigned long rate;
>> + int ret;
>> +
>> + cpu_dev = get_cpu_device(cpu);
>> + if (!cpu_dev) {
>> + pr_err("failed to get cpu%d device\n", cpu);
>> + return -ENODEV;
>> + }
>> +
>> + ret = of_init_opp_table(cpu_dev);
>> + if (ret) {
>> + pr_warn("no OPP table for cpu%d\n", cpu);
>> + return ret;
>> + }
>
> Initialize opp table only when you know other resources are available.
> i.e. we aren't going to abort due to EPROBE_DEFER.

Will do it.

>
>> + cpu_clk = clk_get(cpu_dev, "cpu");
>> + if (IS_ERR(cpu_clk)) {
>> + if (PTR_ERR(cpu_clk) == -EPROBE_DEFER)
>> + pr_warn("cpu clk for cpu%d not ready, retry.\n", cpu);
>> + else
>> + pr_err("failed to get cpu clk for cpu%d\n", cpu);
>> +
>> + ret = PTR_ERR(cpu_clk);
>> + goto out_free_opp_table;
>> + }
>> +}
>
>
>> +static int mt8173_cpufreq_probe(struct platform_device *pdev)
>> +{
>> + int ret;
>> +
>> + ret = cpufreq_register_driver(&mt8173_cpufreq_driver);
>> + if (ret)
>> + pr_err("failed to register mtk cpufreq driver\n");
>> +
>> + return ret;
>> +}
>> +
>> +static struct platform_driver mt8173_cpufreq_platdrv = {
>> + .driver = {
>> + .name   = "mt8173-cpufreq",
>> + },
>> + .probe  = mt8173_cpufreq_probe,
>> +};
>> +
>> +static int mt8173_cpufreq_driver_init(void)
>> +{
>> + struct platform_device *pdev;
>> + int err;
>> +
>> + if (!of_machine_is_compatible("mediatek,mt8173"))
>> + return -ENODEV;
>
> Why do you need to check this ? Its going to be the right SoC, others
> can't even compile it.

Originally I was thinking this driver should be generic to other Mediatek
SoCs, so I add this check to filter out those SoCs that are not yet
confirmed with this driver supported. Since it's targeted to MT8173 only
now, I will remove this check.

>
>> + err = platform_driver_register(&mt8173_cpufreq_platdrv);
>> + if (err)
>> + return err;
>> +
>> + pdev = platform_device_register_simple("mt8173-cpufreq", -1, NULL, 0);
>> + if (IS_ERR(pdev)) {
>> + pr_err("failed to register mtk-cpufreq platform device\n");
>> + return PTR_ERR(pdev);
>> + }
>
> This is simply crap. You register the driver and then its device from
> the same function. If you are so sure that this driver is required,
> then why to get into the shit of device-driver model ?
>
> Just call cpufreq_register_driver() from here :), no device/driver
> required.

That's what I did in previous version. But the reason I use the device-
driver model is to handle the defer probing issue. Since there's no
arch/arm64/mach-mediatek/ directory to hold the device registration
code anymore, no device tree way to match cpufreq driver
(please correct me if there's any), and initcall seems not handle
defer probing either, therefore I put both device and driver
registration in this function. I know it's crappy. :(
Do you have any suggestion to do it right and handle defer probing
properly?

Thanks.

Best Regards,
Pi-Cheng

>
> --
> viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v9 7/8] drivers/video/fbdev/s3fb: Use arch_phys_wc_add() and pci_iomap_wc()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

This driver uses the same area for MTRR as for the ioremap().

Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure the ioremapped area is requested as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available.

b) Help bury MTRR code away, MTRR is architecture-specific and on
   x86 it is being replaced by PAT.

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()").

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message about
when MTRR fails and doing nothing when we didn't get an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Signed-off-by: Luis R. Rodriguez 
Acked-by: Tomi Valkeinen 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Antonino Daplas 
Cc: Arnd Bergmann 
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Geert Uytterhoeven 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Jingoo Han 
Cc: Juergen Gross 
Cc: "Lad, Prabhakar" 
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Rickard Strandqvist 
Cc: Suresh Siddha 
Cc: Thomas Gleixner 
Cc: toshi.k...@hp.com
Link: 
http://lkml.kernel.org/r/1435195342-26879-9-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov 
---
 drivers/video/fbdev/s3fb.c | 35 ++-
 1 file changed, 6 insertions(+), 29 deletions(-)

diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index f0ae61a37f04..13b109073c63 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -28,13 +28,9 @@
 #include 
 #include 
 
-#ifdef CONFIG_MTRR
-#include 
-#endif
-
 struct s3fb_info {
int chip, rev, mclk_freq;
-   int mtrr_reg;
+   int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -154,11 +150,7 @@ static const struct svga_timing_regs s3_timing_regs = {
 
 
 static char *mode_option;
-
-#ifdef CONFIG_MTRR
 static int mtrr = 1;
-#endif
-
 static int fasttext = 1;
 
 
@@ -170,11 +162,8 @@ module_param(mode_option, charp, 0444);
 MODULE_PARM_DESC(mode_option, "Default video mode ('640x480-8@60', etc)");
 module_param_named(mode, mode_option, charp, 0444);
 MODULE_PARM_DESC(mode, "Default video mode ('640x480-8@60', etc) 
(deprecated)");
-
-#ifdef CONFIG_MTRR
 module_param(mtrr, int, 0444);
 MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable, 
default=1)");
-#endif
 
 module_param(fasttext, int, 0644);
 MODULE_PARM_DESC(fasttext, "Enable S3 fast text mode (1=enable, 0=disable, 
default=1)");
@@ -1168,7 +1157,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
info->fix.smem_len = pci_resource_len(dev, 0);
 
/* Map physical IO memory address into kernel space */
-   info->screen_base = pci_iomap(dev, 0, 0);
+   info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -1365,12 +1354,9 @@ static int s3_pci_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
 
-#ifdef CONFIG_MTRR
-   if (mtrr) {
-   par->mtrr_reg = -1;
-   par->mtrr_reg = mtrr_add(info->fix.smem_start, 
info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
-   }
-#endif
+   if (mtrr)
+  

Re: [PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller

[Shawn Guo]

On Wed, Jul 08, 2015 at 10:32:54AM -0400, Bill Pringlemeir wrote:
> 
> On  8 Jul 2015, shawn...@kernel.org wrote:
> > On Fri, Jun 19, 2015 at 12:58:37AM +0200, Stefan Agner wrote:
> >> Enable the NAND Flash Controller driver which is part of the Vybrid
> >> SoC by default.
> >>
> >> Signed-off-by: Stefan Agner 
> >> ---
> >> arch/arm/mach-imx/Kconfig | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> >> index 3a3d3e9..9358135 100644
> >> --- a/arch/arm/mach-imx/Kconfig
> >> +++ b/arch/arm/mach-imx/Kconfig
>  -589,6 +589,7 @@ config SOC_VF610
> >>select PINCTRL_VF610
> >>select PL310_ERRATA_769419 if CACHE_L2X0
> >>select SMP_ON_UP if SMP
> >> +  select HAVE_NAND_VF610_NFC
> 
> > I'm not sure about the benefit of having this option, except we have
> > to have this additional architecture patch.
> 
> For other SOC, like the PowerPC or ColdFire CPUs with this controller,
> it was a way to mark the controller as populated.  Otherwise, the
> Kconfig entry to select the controller will pop up for everybody.

IMHO, having the option pop up for everybody isn't really a problem.  On
the other hand, we can even compile test the driver on any architecture
without the COMPILE_TEST dependency.

But if MTD maintainer has a different opinion, we can still have a
'depends on SOC_VF610' to save this patch.

Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: move CONFIG_PINCTRL to drivers/Makefile

[Masahiro Yamada]

Kbuild should descend into drivers/pinctrl/ only when CONFIG_PINCTRL
is enabled because everything under that directory depends on
CONFIG_PINCTRL.

We can avoid the conditional, ifeq ($(CONFIG_OF),y) ... endif.

Signed-off-by: Masahiro Yamada 
---

 drivers/Makefile | 2 +-
 drivers/pinctrl/Makefile | 6 ++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index b64b49f..e4b260e 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -11,7 +11,7 @@ obj-y += bus/
 obj-$(CONFIG_GENERIC_PHY)  += phy/
 
 # GPIO must come after pinctrl as gpios may need to mux pins etc
-obj-y  += pinctrl/
+obj-$(CONFIG_PINCTRL)  += pinctrl/
 obj-y  += gpio/
 obj-y  += pwm/
 obj-$(CONFIG_PCI)  += pci/
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f6710a8..76ba976 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -2,12 +2,10 @@
 
 subdir-ccflags-$(CONFIG_DEBUG_PINCTRL) += -DDEBUG
 
-obj-$(CONFIG_PINCTRL)  += core.o pinctrl-utils.o
+obj-y  += core.o pinctrl-utils.o
 obj-$(CONFIG_PINMUX)   += pinmux.o
 obj-$(CONFIG_PINCONF)  += pinconf.o
-ifeq ($(CONFIG_OF),y)
-obj-$(CONFIG_PINCTRL)  += devicetree.o
-endif
+obj-$(CONFIG_OF)   += devicetree.o
 obj-$(CONFIG_GENERIC_PINCONF)  += pinconf-generic.o
 obj-$(CONFIG_PINCTRL_ADI2) += pinctrl-adi2.o
 obj-$(CONFIG_PINCTRL_AS3722)   += pinctrl-as3722.o
-- 
1.9.1

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

[PATCH v9 8/8] drivers/video/fbdev/vt8623fb: Use arch_phys_wc_add() and pci_iomap_wc()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

This driver uses the same area for MTRR as for the ioremap().

Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure the ioremapped area is requested as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available.

b) Help bury MTRR code away, MTRR is architecture-specific and on
   x86 it is being replaced by PAT.

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()").

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message about
when MTRR fails and doing nothing when we didn't get an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Signed-off-by: Luis R. Rodriguez 
Acked-by: Tomi Valkeinen 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Antonino Daplas 
Cc: Arnd Bergmann 
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Jingoo Han 
Cc: Juergen Gross 
Cc: "Lad, Prabhakar" 
Cc: Laurent Pinchart 
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Rob Clark 
Cc: Suresh Siddha 
Cc: Thomas Gleixner 
Cc: toshi.k...@hp.com
Link: 
http://lkml.kernel.org/r/1435195342-26879-10-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov 
---
 drivers/video/fbdev/vt8623fb.c | 31 ++-
 1 file changed, 6 insertions(+), 25 deletions(-)

diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index 8bac309c24b9..dd0f18e42d3e 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -26,13 +26,9 @@
 #include  /* Why should fb driver call console functions? 
because console_lock() */
 #include 
 
-#ifdef CONFIG_MTRR
-#include 
-#endif
-
 struct vt8623fb_info {
char __iomem *mmio_base;
-   int mtrr_reg;
+   int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -99,10 +95,7 @@ static struct svga_timing_regs vt8623_timing_regs = {
 /* Module parameters */
 
 static char *mode_option = "640x480-8@60";
-
-#ifdef CONFIG_MTRR
 static int mtrr = 1;
-#endif
 
 MODULE_AUTHOR("(c) 2006 Ondrej Zajicek ");
 MODULE_LICENSE("GPL");
@@ -112,11 +105,8 @@ module_param(mode_option, charp, 0644);
 MODULE_PARM_DESC(mode_option, "Default video mode ('640x480-8@60', etc)");
 module_param_named(mode, mode_option, charp, 0);
 MODULE_PARM_DESC(mode, "Default video mode e.g. '648x480-8@60' (deprecated)");
-
-#ifdef CONFIG_MTRR
 module_param(mtrr, int, 0444);
 MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable, 
default=1)");
-#endif
 
 
 /* - */
@@ -710,7 +700,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
info->fix.mmio_len = pci_resource_len(dev, 1);
 
/* Map physical IO memory address into kernel space */
-   info->screen_base = pci_iomap(dev, 0, 0);
+   info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -781,12 +771,9 @@ static int vt8623_pci_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
 
-#ifdef CONFIG_MTRR
-   if (mtrr) {
-   par->mtrr_reg = -1;
-   par->mtrr_reg = mtrr_add(i