Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

[Alexander E. Patrakov]

11.09.2014 03:10, Luis R. Rodriguez wrote:

Tom, thanks for reviewing this! My reply below!

On Tue, Sep 9, 2014 at 11:46 PM, Tom Gundersen  wrote:

On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez
 wrote:

On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley
 wrote:

On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:

On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
 wrote:

If we want to sort out some sync/async mechanism for probing devices, as
an agreement between the init systems and the kernel, that's fine, but
its a to-be negotiated enhancement.


Unfortunately as Tejun notes the train has left which already made
assumptions on this.


Well, that's why it's a bug.  It's a material regression impacting
users.


Indeed. I believe the issue with this regression however was that the
original commit e64fae55 (January 2012) was only accepted by *kernel
folks* to be a real regression until recently.


Just for the record, this only caused user-visible problems after
kernel commit 786235ee (November 2013), right?


Another one was cxgb4:

https://bugzilla.novell.com/show_bug.cgi?id=877622

SLE12 does not yet have commit 786235ee merged. Benjamim did some hard
work to debug this and trace the kill down to systemd-udev. A debug
kernel build has been provided now to try to pick up exactly on the
place where the kill was received, but its at least clear this came
from systemd.


More than two years
have gone by on growing design and assumptions on top of that original
commit. I'm not sure if *systemd folks* yet believe its was a design
regression?


I don't think so. udev should not allow its workers to run for an
unbounded length of time. Whether the upper bound should be 30, 60,
180 seconds or something else is up for debate (currently it is 60,
but if that is too short for some drivers we could certainly revisit
that).


That's the thing -- the timeout was put in place under the assumption
probe was asyncronous and its not, the driver core issues both module
init *and* probe together, the loader has to wait. That alone makes
the timeout a design flaw, and then systemd carried on top of that
design over two years after that. Its not systemd's fault, its just
that we never spoke about this as a design thing broadly and we should
have, and I will mention that even when the first issues creeped up,
the issue was still tossed back a driver problems. It was only until
recently that we realized that both init and probe run together that
we've been thinking about this problem differently. Systemd was trying
to ensure init on driver don't take long but its not init that is
taking long, its probe, and probe gets then penalized as the driver
core batches both init and probe synchronously before finishing module
loading. Furthermore as clarified by Tejun random userland is known to
exist that will wait indefinitely for module loading under the simple
assumption things *are done synchronously*, and its precisely why we
can't just blindly enable async probe upstream through a new driver
boolean as it can be unfair to this old userland. What is being
evaluated is to enable aync probe for *all* drivers through a new
general system-wide option. We cannot regress old userspace and
assumptions but we can create a new shiny universe.


Moreover, it seems from this discussion that the aim is (still)
that insmod should be near-instantaneous (i.e., not wait for probe),


The only reason that is being discussed is that systemd has not
accepted the timeout as a system design despite me pointing out the
original design flaw recently and at this point even if was accepted
as a design flaw it seems its too late. The approach taken to help
make all drivers async is simply an afterthought to give systemd what
it *thought* was in place, and it by no measure should be considered
the proper fix to the regression introduced by systemd, it may perhaps
be the right step long term for systemd systems given it goes with
what it assumed was there, but the timeout was flawed. Its not clear
if systemd can help with old kernels, it seems the ship has sailed and
there seems no options but for folks to work around that -- unless of
course some reasonable solution is found which doesn't break current
systemd design?


so it seems to me that the basic design is correct and all we need is
some temporary work-around and a way to better detect misbehaving
drivers?


As part of this series I addressed hunting for the  "misbehaving
drivers" in-kernel as I saw no progress on the systemd side of things
to non-fatally detect "misbehaving drivers" despite my original RFCs
and request for advice. I quote  "misbehaving drivers" as its a flawed
view to consider them misbehaving now in light of clarifications of
how the driver core works in that it batches both init and probe
together always and we can't be penalizing long probes due to the fact
long probes are simply fine. My patch to pick up "misbehaving drivers"
drivers on the kernel front by picking up 

Re: [PATCH] mm: softdirty: unmapped addresses between VMAs are clean

[Peter Feiner]

On Wed, Sep 10, 2014 at 04:36:28PM -0700, Andrew Morton wrote:
> On Wed, 10 Sep 2014 16:24:46 -0700 Peter Feiner  wrote:
> > @@ -1048,32 +1048,51 @@ static int pagemap_pte_range(pmd_t *pmd, unsigned 
> > long addr, unsigned long end,
> > +   while (1) {
> > +   unsigned long vm_start = end;
> 
> Did you really mean to do that?  If so, perhaps a little comment to
> explain how it works?

It's the same idea that I used in the pagemap_pte_hole patch that I submitted
today: if vma is NULL, then we fill in the pagemap from (addr) to (end) with
non-present pagemap entries. 

Should I submit a v2 with a comment?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: fsl_ssi: refine ipg clock usage in this module

[Shengjiu Wang]

Move the ipg clock enable and disable operation to startup and shutdown,
that is only enable ipg clock when ssi is working. Keep clock is disabled
when ssi is in idle.
otherwise, _fsl_ssi_set_dai_fmt function need to be called in probe,
so add ipg clock control for it.

Signed-off-by: Shengjiu Wang 
---

change log
v2: update patch according to maintainer's review comments.

 sound/soc/fsl/fsl_ssi.c |   39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 2fc3e66..4447f95 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -530,6 +530,11 @@ static int fsl_ssi_startup(struct snd_pcm_substream 
*substream,
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct fsl_ssi_private *ssi_private =
snd_soc_dai_get_drvdata(rtd->cpu_dai);
+   int ret;
+
+   ret = clk_prepare_enable(ssi_private->clk);
+   if (ret)
+   return ret;
 
/* When using dual fifo mode, it is safer to ensure an even period
 * size. If appearing to an odd number while DMA always starts its
@@ -544,6 +549,21 @@ static int fsl_ssi_startup(struct snd_pcm_substream 
*substream,
 }
 
 /**
+ * fsl_ssi_shutdown: shutdown the SSI
+ *
+ */
+static void fsl_ssi_shutdown(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct fsl_ssi_private *ssi_private =
+   snd_soc_dai_get_drvdata(rtd->cpu_dai);
+
+   clk_disable_unprepare(ssi_private->clk);
+
+}
+
+/**
  * fsl_ssi_set_bclk - configure Digital Audio Interface bit clock
  *
  * Note: This function can be only called when using SSI as DAI master
@@ -771,6 +791,7 @@ static int _fsl_ssi_set_dai_fmt(struct fsl_ssi_private 
*ssi_private,
struct regmap *regs = ssi_private->regs;
u32 strcr = 0, stcr, srcr, scr, mask;
u8 wm;
+   int ret;
 
ssi_private->dai_fmt = fmt;
 
@@ -779,6 +800,10 @@ static int _fsl_ssi_set_dai_fmt(struct fsl_ssi_private 
*ssi_private,
return -EINVAL;
}
 
+   ret = clk_prepare_enable(ssi_private->clk);
+   if (ret)
+   return ret;
+
fsl_ssi_setup_reg_vals(ssi_private);
 
regmap_read(regs, CCSR_SSI_SCR, );
@@ -811,6 +836,7 @@ static int _fsl_ssi_set_dai_fmt(struct fsl_ssi_private 
*ssi_private,
ssi_private->i2s_mode |= CCSR_SSI_SCR_I2S_MODE_SLAVE;
break;
default:
+   clk_disable_unprepare(ssi_private->clk);
return -EINVAL;
}
 
@@ -836,6 +862,7 @@ static int _fsl_ssi_set_dai_fmt(struct fsl_ssi_private 
*ssi_private,
ssi_private->i2s_mode |= CCSR_SSI_SCR_I2S_MODE_NORMAL;
break;
default:
+   clk_disable_unprepare(ssi_private->clk);
return -EINVAL;
}
scr |= ssi_private->i2s_mode;
@@ -859,6 +886,7 @@ static int _fsl_ssi_set_dai_fmt(struct fsl_ssi_private 
*ssi_private,
strcr ^= CCSR_SSI_STCR_TFSI;
break;
default:
+   clk_disable_unprepare(ssi_private->clk);
return -EINVAL;
}
 
@@ -877,6 +905,7 @@ static int _fsl_ssi_set_dai_fmt(struct fsl_ssi_private 
*ssi_private,
scr &= ~CCSR_SSI_SCR_SYS_CLK_EN;
break;
default:
+   clk_disable_unprepare(ssi_private->clk);
return -EINVAL;
}
 
@@ -925,6 +954,7 @@ static int _fsl_ssi_set_dai_fmt(struct fsl_ssi_private 
*ssi_private,
if (fmt & SND_SOC_DAIFMT_AC97)
fsl_ssi_setup_ac97(ssi_private);
 
+   clk_disable_unprepare(ssi_private->clk);
return 0;
 
 }
@@ -1043,6 +1073,7 @@ static int fsl_ssi_dai_probe(struct snd_soc_dai *dai)
 
 static const struct snd_soc_dai_ops fsl_ssi_dai_ops = {
.startup= fsl_ssi_startup,
+   .shutdown   = fsl_ssi_shutdown,
.hw_params  = fsl_ssi_hw_params,
.hw_free= fsl_ssi_hw_free,
.set_fmt= fsl_ssi_set_dai_fmt,
@@ -1175,12 +1206,6 @@ static int fsl_ssi_imx_probe(struct platform_device 
*pdev,
return ret;
}
 
-   ret = clk_prepare_enable(ssi_private->clk);
-   if (ret) {
-   dev_err(>dev, "clk_prepare_enable failed: %d\n", ret);
-   return ret;
-   }
-
/* For those SLAVE implementations, we ingore non-baudclk cases
 * and, instead, abandon MASTER mode that needs baud clock.
 */
@@ -1236,7 +1261,6 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev,
return 0;
 
 error_pcm:
-   clk_disable_unprepare(ssi_private->clk);
 
return ret;
 }
@@ -1246,7 +1270,6 @@ static void fsl_ssi_imx_clean(struct platform_device 
*pdev,
 {
if 

[PATCH v5 3/7] kvm: Make init_rmode_identity_map() return 0 on success.

[Tang Chen]

In init_rmode_identity_map(), there two variables indicating the return
value, r and ret, and it return 0 on error, 1 on success. The function
is only called by vmx_create_vcpu(), and r is redundant.

This patch removes the redundant variable r, and make init_rmode_identity_map()
return 0 on success, -errno on failure.

Signed-off-by: Tang Chen 
---
 arch/x86/kvm/vmx.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 953d529..63c4c3e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3939,45 +3939,42 @@ out:
 
 static int init_rmode_identity_map(struct kvm *kvm)
 {
-   int i, idx, r, ret = 0;
+   int i, idx, ret = 0;
pfn_t identity_map_pfn;
u32 tmp;
 
if (!enable_ept)
-   return 1;
+   return 0;
 
/* Protect kvm->arch.ept_identity_pagetable_done. */
mutex_lock(>slots_lock);
 
-   if (likely(kvm->arch.ept_identity_pagetable_done)) {
-   ret = 1;
+   if (likely(kvm->arch.ept_identity_pagetable_done))
goto out2;
-   }
 
identity_map_pfn = kvm->arch.ept_identity_map_addr >> PAGE_SHIFT;
 
-   r = alloc_identity_pagetable(kvm);
-   if (r)
+   ret = alloc_identity_pagetable(kvm);
+   if (ret)
goto out2;
 
idx = srcu_read_lock(>srcu);
-   r = kvm_clear_guest_page(kvm, identity_map_pfn, 0, PAGE_SIZE);
-   if (r < 0)
+   ret = kvm_clear_guest_page(kvm, identity_map_pfn, 0, PAGE_SIZE);
+   if (ret)
goto out;
/* Set up identity-mapping pagetable for EPT in real mode */
for (i = 0; i < PT32_ENT_PER_PAGE; i++) {
tmp = (i << 22) + (_PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
_PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
-   r = kvm_write_guest_page(kvm, identity_map_pfn,
+   ret = kvm_write_guest_page(kvm, identity_map_pfn,
, i * sizeof(tmp), sizeof(tmp));
-   if (r < 0)
+   if (ret)
goto out;
}
kvm->arch.ept_identity_pagetable_done = true;
-   ret = 1;
+
 out:
srcu_read_unlock(>srcu, idx);
-
 out2:
mutex_unlock(>slots_lock);
return ret;
@@ -7645,7 +7642,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, 
unsigned int id)
kvm->arch.ept_identity_map_addr =
VMX_EPT_IDENTITY_PAGETABLE_ADDR;
err = -ENOMEM;
-   if (!init_rmode_identity_map(kvm))
+   if (init_rmode_identity_map(kvm))
goto free_vmcs;
}
 
-- 
1.8.3.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: [RFC/PATCH v2 02/10] x86_64: add KASan support

[Andrey Ryabinin]

On 09/11/2014 08:01 AM, H. Peter Anvin wrote:
> On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
>> This patch add arch specific code for kernel address sanitizer.
>>
>> 16TB of virtual addressed used for shadow memory.
>> It's located in range [0x8000 - 0x9000]
>> Therefore PAGE_OFFSET has to be changed from 0x8800
>> to 0x9000.
> 
> NAK on this.
> 
> 0x8800 is the lowest usable address because we have agreed
> to leave 0x8000-0x8800 for the hypervisor or
> other non-OS uses.
> 
> Bumping PAGE_OFFSET seems needlessly messy, why not just designate a
> zone higher up in memory?
> 

I already answered to Dave why I choose to place shadow bellow PAGE_OFFSET 
(answer copied bellow).
In short - yes, shadow could be higher. But for some sort of kernel bugs we 
could have confusing oopses in kasan kernel.

On 09/11/2014 12:30 AM, Andrey Ryabinin wrote:
> 2014-09-10 19:46 GMT+04:00 Dave Hansen :
>>
>> Is there a reason this has to be _below_ the linear map?  Couldn't we
>> just carve some space out of the vmalloc() area for the kasan area?
>>
>
> Yes, there is a reason for this. For inline instrumentation we need to
> catch access to userspace without any additional check.
> This means that we need shadow of 1 << 61 bytes and we don't have so
> many addresses available. However, we could use
> hole between userspace and kernelspace for that. For any address
> between [0 - 0x8000], shadow address will be
> in this hole, so checking shadow value will produce general protection
> fault (GPF). We may even try handle GPF in a special way
> and print more user-friendly report (this will be under CONFIG_KASAN of 
> course).
>
> But now I realized that we even if we put shadow in vmalloc, shadow
> addresses  corresponding to userspace addresses
> still will be in between userspace - kernelspace, so we also will get GPF.
> There is the only problem I see now in such approach. Lets consider
> that because of some bug in kernel we are trying to access
> memory slightly bellow 0x8000. In this case kasan will try
> to check some shadow which in fact is not a shadow byte at all.
> It's not a big deal though, kernel will crash anyway. In only means
> that debugging of such problems could be a little more complex
> than without kasan.
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 7/7] kvm, mem-hotplug: Unpin and remove nested_vmx->apic_access_page.

[Tang Chen]

Just like we removed kvm_arch->apic_access_page, nested_vmx->apic_access_page
becomes useless for the same reason. This patch removes 
nested_vmx->apic_access_page,
and use gfn_to_page() to pin it in memory when we need it, and unpin it after 
then.

Signed-off-by: Tang Chen 
---
 arch/x86/kvm/vmx.c | 31 +--
 1 file changed, 9 insertions(+), 22 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 058c373..4aa73cb 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -374,11 +374,6 @@ struct nested_vmx {
u64 vmcs01_tsc_offset;
/* L2 must run next, and mustn't decide to exit to L1. */
bool nested_run_pending;
-   /*
-* Guest pages referred to in vmcs02 with host-physical pointers, so
-* we must keep them pinned while L2 runs.
-*/
-   struct page *apic_access_page;
u64 msr_ia32_feature_control;
 
struct hrtimer preemption_timer;
@@ -6154,11 +6149,6 @@ static void free_nested(struct vcpu_vmx *vmx)
nested_release_vmcs12(vmx);
if (enable_shadow_vmcs)
free_vmcs(vmx->nested.current_shadow_vmcs);
-   /* Unpin physical memory we referred to in current vmcs02 */
-   if (vmx->nested.apic_access_page) {
-   nested_release_page(vmx->nested.apic_access_page);
-   vmx->nested.apic_access_page = 0;
-   }
 
nested_free_all_saved_vmcss(vmx);
 }
@@ -7983,28 +7973,31 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu, 
struct vmcs12 *vmcs12)
exec_control |= vmcs12->secondary_vm_exec_control;
 
if (exec_control & SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES) {
+   struct page *page;
/*
 * Translate L1 physical address to host physical
 * address for vmcs02. Keep the page pinned, so this
 * physical address remains valid. We keep a reference
 * to it so we can release it later.
 */
-   if (vmx->nested.apic_access_page) /* shouldn't happen */
-   
nested_release_page(vmx->nested.apic_access_page);
-   vmx->nested.apic_access_page =
-   nested_get_page(vcpu, vmcs12->apic_access_addr);
+   page = nested_get_page(vcpu, vmcs12->apic_access_addr);
/*
 * If translation failed, no matter: This feature asks
 * to exit when accessing the given address, and if it
 * can never be accessed, this feature won't do
 * anything anyway.
 */
-   if (!vmx->nested.apic_access_page)
+   if (!page)
exec_control &=
  ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
else
vmcs_write64(APIC_ACCESS_ADDR,
- page_to_phys(vmx->nested.apic_access_page));
+page_to_phys(page));
+   /*
+* Do not pin nested vm's apic access page in memory so
+* that memory hotplug process is able to migrate it.
+*/
+   put_page(page);
} else if (vm_need_virtualize_apic_accesses(vmx->vcpu.kvm)) {
struct page *page = gfn_to_page(vmx->vcpu.kvm,
APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
@@ -8807,12 +8800,6 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 
exit_reason,
/* This is needed for same reason as it was needed in prepare_vmcs02 */
vmx->host_rsp = 0;
 
-   /* Unpin physical memory we referred to in vmcs02 */
-   if (vmx->nested.apic_access_page) {
-   nested_release_page(vmx->nested.apic_access_page);
-   vmx->nested.apic_access_page = 0;
-   }
-
/*
 * Do not call kvm_reload_apic_access_page() because we are now
 * running, mmu_notifier will force to reload the page's hpa for L2
-- 
1.8.3.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] f2fs: Fix recover when nid of non-inode dnode < nid of inode

[Jaegeuk Kim]

On Wed, Sep 10, 2014 at 07:08:32PM +0800, huang ying wrote:
> On Wed, Sep 10, 2014 at 3:21 PM, Jaegeuk Kim  wrote:
> 
> > On Tue, Sep 09, 2014 at 07:31:49PM +0800, huang ying wrote:
> > > On Tue, Sep 9, 2014 at 3:09 PM, Jaegeuk Kim  wrote:
> > >
> > > > Hi,
> > > >
> > > > On Tue, Sep 09, 2014 at 01:39:30PM +0800, Huang Ying wrote:
> > > > > On Mon, 2014-09-08 at 22:23 -0700, Jaegeuk Kim wrote:
> > > > > > Hi Huang,
> > > > > >
> > > > > > On Mon, Sep 08, 2014 at 07:38:26PM +0800, Huang Ying wrote:
> > > > > > > For fsync, if the nid of a non-inode dnode < nid of inode and the
> > > > > > > inode is not checkpointed.  The non-inode dnode may be written
> > before
> > > > > > > inode.  So in find_fsync_dnodes, f2fs_iget will fail, cause the
> > > > > > > recovery fail.
> > > > > > >
> > > > > > > Usually, inode will be allocated before non-inode dnode, so the
> > nid
> > > > of
> > > > > > > inode < nid of non-inode dnode.  But it is possible for the
> > reverse.
> > > > > > > For example, because of alloc_nid_failed.
> > > > > > >
> > > > > > > This is fixed via ignoring non-inode dnode before inode dnode in
> > > > > > > find_fsync_dnodes.
> > > > > > >
> > > > > > > The patch was tested via allocating nid reversely via a debugging
> > > > > > > patch, that is, from big number to small number.
> > > > > > >
> > > > > > > Signed-off-by: Huang, Ying 
> > > > > > > ---
> > > > > > >  fs/f2fs/recovery.c |7 ---
> > > > > > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > > > > >
> > > > > > > --- a/fs/f2fs/recovery.c
> > > > > > > +++ b/fs/f2fs/recovery.c
> > > > > > > @@ -172,8 +172,8 @@ static int find_fsync_dnodes(struct f2fs
> > > > > > >   if (IS_INODE(page) && is_dent_dnode(page))
> > > > > > >   set_inode_flag(F2FS_I(entry->inode),
> > > > > > >   FI_INC_LINK);
> > > > > > > - } else {
> > > > > > > - if (IS_INODE(page) && is_dent_dnode(page)) {
> > > > > >
> > > > > > If this is not inode block, we should add this inode to recover its
> > > > data blocks.
> > > > >
> > > > > Is it possible that there is only non-inode dnode but no inode when
> > > > > find_fsync_dnodes checking dnodes?  Per my understanding, any
> > changes to
> > > > > file will cause inode page dirty (for example, mtime changed), so
> > that
> > > > > we will write inode block.  Is it right?  If so, the solution in this
> > > > > patch should work too.
> > > >
> > > > Your description says that f2fs_iget will fail, which causes the
> > recovery
> > > > fail.
> > > > So, I thought it would be better to handle the f2fs_iget failure
> > directly.
> > > >
> > >
> > > Yes.  That is another way to fix the issue.
> > >
> > >
> > > > In addition, we cannot guarantee the write order of dnode and inode.
> > > > For exmaple,
> > > > 1. the inode is written by flusher or kswapd, then,
> > > > 2. f2fs_sync_file writes its dnode.
> > > >
> > > > In that case, we can get only non-inode dnode in the node chain, since
> > the
> > > > inode
> > > > has not fsync_mark.
> > > >
> > >
> > > I think your solution is better here, but does not fix all scenarios.  If
> > > the inode is checkpointed, the file can be recovered, although the inode
> > > information may be not up to date.  But if the inode is not checkpointed,
> > > f2fs_iget will fail too and recover will fail.
> >
> > Ok, let me consider your scenarios.
> >
> > Term: F: fsync_mark, D: dentry_mark
> >
> > 1. inode(x) | CP | inode(x) | dnode(F)
> >  -> Lose the latest inode(x). Need to fix.
> >
> > 2. inode(x) | CP | dnode(F) | inode(x)
> >  -> Impossible, but recover latest dnode(F)
> >
> > 3. CP | inode(x) | dnode(F)
> >  -> Need to write inode(DF) in f2fs_sync_file.
> >
> > 4. CP | dnode(F) | inode(DF)
> >  -> If f2fs_iget fails, then goto next.
> >
> > 5. CP | dnode(F) | inode(x)
> >  -> If f2fs_iget fails, then goto next. But, this is an impossible
> > scenario.
> > Drop this dnode(F).
> >
> > Indeed, there were some missing scenarios.
> >
> > So, how about this patch?
> >
> > From 552dc68c5f07a335d7b55c197bab531efb135521 Mon Sep 17 00:00:00 2001
> > From: Jaegeuk Kim 
> > Date: Wed, 10 Sep 2014 00:16:34 -0700
> > Subject: [PATCH] f2fs: fix roll-forward missing scenarios
> >
> > We can summarize the roll forward recovery scenarios as follows.
> >
> > [Term] F: fsync_mark, D: dentry_mark
> >
> > 1. inode(x) | CP | inode(x) | dnode(F)
> > -> Update the latest inode(x).
> >
> > 2. inode(x) | CP | inode(F) | dnode(F)
> > -> No problem.
> >
> > 3. inode(x) | CP | dnode(F) | inode(x)
> > -> Impossible, but recover latest dnode(F)
> >
> 
> I think this is possible.  If f2fs_sync_file runs concurrently with
> writeback. f2fs_sync_file written dnode(F), then writeback written inode(x).

If the inode(x) was written, f2fs_sync_file will do write the inode again with
fsync_mark. So, dnode(F) | inode(x) | inode(F) should be shown.

In f2fs_sync_file,
...

[PATCH v5 2/7] kvm: Remove ept_identity_pagetable from struct kvm_arch.

[Tang Chen]

kvm_arch->ept_identity_pagetable holds the ept identity pagetable page. But
it is never used to refer to the page at all.

In vcpu initialization, it indicates two things:
1. indicates if ept page is allocated
2. indicates if a memory slot for identity page is initialized

Actually, kvm_arch->ept_identity_pagetable_done is enough to tell if the ept
identity pagetable is initialized. So we can remove ept_identity_pagetable.

NOTE: In the original code, ept identity pagetable page is pinned in memroy.
  As a result, it cannot be migrated/hot-removed. After this patch, since
  kvm_arch->ept_identity_pagetable is removed, ept identity pagetable page
  is no longer pinned in memory. And it can be migrated/hot-removed.

Signed-off-by: Tang Chen 
Reviewed-by: Gleb Natapov 
---
 arch/x86/include/asm/kvm_host.h |  1 -
 arch/x86/kvm/vmx.c  | 50 -
 arch/x86/kvm/x86.c  |  2 --
 3 files changed, 25 insertions(+), 28 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7c492ed..35171c7 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -580,7 +580,6 @@ struct kvm_arch {
 
gpa_t wall_clock;
 
-   struct page *ept_identity_pagetable;
bool ept_identity_pagetable_done;
gpa_t ept_identity_map_addr;
 
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4b80ead..953d529 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -743,6 +743,7 @@ static u32 vmx_segment_access_rights(struct kvm_segment 
*var);
 static void vmx_sync_pir_to_irr_dummy(struct kvm_vcpu *vcpu);
 static void copy_vmcs12_to_shadow(struct vcpu_vmx *vmx);
 static void copy_shadow_to_vmcs12(struct vcpu_vmx *vmx);
+static int alloc_identity_pagetable(struct kvm *kvm);
 
 static DEFINE_PER_CPU(struct vmcs *, vmxarea);
 static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
@@ -3938,21 +3939,27 @@ out:
 
 static int init_rmode_identity_map(struct kvm *kvm)
 {
-   int i, idx, r, ret;
+   int i, idx, r, ret = 0;
pfn_t identity_map_pfn;
u32 tmp;
 
if (!enable_ept)
return 1;
-   if (unlikely(!kvm->arch.ept_identity_pagetable)) {
-   printk(KERN_ERR "EPT: identity-mapping pagetable "
-   "haven't been allocated!\n");
-   return 0;
+
+   /* Protect kvm->arch.ept_identity_pagetable_done. */
+   mutex_lock(>slots_lock);
+
+   if (likely(kvm->arch.ept_identity_pagetable_done)) {
+   ret = 1;
+   goto out2;
}
-   if (likely(kvm->arch.ept_identity_pagetable_done))
-   return 1;
-   ret = 0;
+
identity_map_pfn = kvm->arch.ept_identity_map_addr >> PAGE_SHIFT;
+
+   r = alloc_identity_pagetable(kvm);
+   if (r)
+   goto out2;
+
idx = srcu_read_lock(>srcu);
r = kvm_clear_guest_page(kvm, identity_map_pfn, 0, PAGE_SIZE);
if (r < 0)
@@ -3970,6 +3977,9 @@ static int init_rmode_identity_map(struct kvm *kvm)
ret = 1;
 out:
srcu_read_unlock(>srcu, idx);
+
+out2:
+   mutex_unlock(>slots_lock);
return ret;
 }
 
@@ -4019,31 +4029,23 @@ out:
 
 static int alloc_identity_pagetable(struct kvm *kvm)
 {
-   struct page *page;
+   /*
+* In init_rmode_identity_map(), kvm->arch.ept_identity_pagetable_done
+* is checked before calling this function and set to true after the
+* calling. The access to kvm->arch.ept_identity_pagetable_done should
+* be protected by kvm->slots_lock.
+*/
+
struct kvm_userspace_memory_region kvm_userspace_mem;
int r = 0;
 
-   mutex_lock(>slots_lock);
-   if (kvm->arch.ept_identity_pagetable)
-   goto out;
kvm_userspace_mem.slot = IDENTITY_PAGETABLE_PRIVATE_MEMSLOT;
kvm_userspace_mem.flags = 0;
kvm_userspace_mem.guest_phys_addr =
kvm->arch.ept_identity_map_addr;
kvm_userspace_mem.memory_size = PAGE_SIZE;
r = __kvm_set_memory_region(kvm, _userspace_mem);
-   if (r)
-   goto out;
 
-   page = gfn_to_page(kvm, kvm->arch.ept_identity_map_addr >> PAGE_SHIFT);
-   if (is_error_page(page)) {
-   r = -EFAULT;
-   goto out;
-   }
-
-   kvm->arch.ept_identity_pagetable = page;
-out:
-   mutex_unlock(>slots_lock);
return r;
 }
 
@@ -7643,8 +7645,6 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, 
unsigned int id)
kvm->arch.ept_identity_map_addr =
VMX_EPT_IDENTITY_PAGETABLE_ADDR;
err = -ENOMEM;
-   if (alloc_identity_pagetable(kvm) != 0)
-   goto free_vmcs;
if (!init_rmode_identity_map(kvm))
goto free_vmcs;
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8f1e22d..e05bd58 100644

[PATCH v5 1/7] kvm: Use APIC_DEFAULT_PHYS_BASE macro as the apic access page address.

[Tang Chen]

We have APIC_DEFAULT_PHYS_BASE defined as 0xfee0, which is also the address 
of
apic access page. So use this macro.

Signed-off-by: Tang Chen 
Reviewed-by: Gleb Natapov 
---
 arch/x86/kvm/svm.c | 3 ++-
 arch/x86/kvm/vmx.c | 6 +++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index ddf7427..1d941ad 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1257,7 +1257,8 @@ static struct kvm_vcpu *svm_create_vcpu(struct kvm *kvm, 
unsigned int id)
svm->asid_generation = 0;
init_vmcb(svm);
 
-   svm->vcpu.arch.apic_base = 0xfee0 | MSR_IA32_APICBASE_ENABLE;
+   svm->vcpu.arch.apic_base = APIC_DEFAULT_PHYS_BASE |
+  MSR_IA32_APICBASE_ENABLE;
if (kvm_vcpu_is_bsp(>vcpu))
svm->vcpu.arch.apic_base |= MSR_IA32_APICBASE_BSP;
 
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index bfe11cf..4b80ead 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3999,13 +3999,13 @@ static int alloc_apic_access_page(struct kvm *kvm)
goto out;
kvm_userspace_mem.slot = APIC_ACCESS_PAGE_PRIVATE_MEMSLOT;
kvm_userspace_mem.flags = 0;
-   kvm_userspace_mem.guest_phys_addr = 0xfee0ULL;
+   kvm_userspace_mem.guest_phys_addr = APIC_DEFAULT_PHYS_BASE;
kvm_userspace_mem.memory_size = PAGE_SIZE;
r = __kvm_set_memory_region(kvm, _userspace_mem);
if (r)
goto out;
 
-   page = gfn_to_page(kvm, 0xfee00);
+   page = gfn_to_page(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
if (is_error_page(page)) {
r = -EFAULT;
goto out;
@@ -4477,7 +4477,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu)
 
vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val();
kvm_set_cr8(>vcpu, 0);
-   apic_base_msr.data = 0xfee0 | MSR_IA32_APICBASE_ENABLE;
+   apic_base_msr.data = APIC_DEFAULT_PHYS_BASE | MSR_IA32_APICBASE_ENABLE;
if (kvm_vcpu_is_bsp(>vcpu))
apic_base_msr.data |= MSR_IA32_APICBASE_BSP;
apic_base_msr.host_initiated = true;
-- 
1.8.3.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 v5 0/7] kvm, mem-hotplug: Do not pin ept identity pagetable and apic access page.

[Tang Chen]

ept identity pagetable and apic access page in kvm are pinned in memory.
As a result, they cannot be migrated/hot-removed.

But actually they don't need to be pinned in memory.

[For ept identity page]
Just do not pin it. When it is migrated, guest will be able to find the
new page in the next ept violation.

[For apic access page]
The hpa of apic access page is stored in VMCS APIC_ACCESS_ADDR pointer.
When apic access page is migrated, we update VMCS APIC_ACCESS_ADDR pointer
for each vcpu in addition.

NOTE: Tested with -cpu xxx,-x2apic option.
  But since nested vm pins some other pages in memory, if user uses nested
  vm, memory hot-remove will not work.

Change log v4 -> v5:
1. Patch 5/7: Call kvm_reload_apic_access_page() unconditionally in 
nested_vmx_vmexit().
   (From Gleb Natapov )
2. Patch 6/7: Remove kvm_arch->apic_access_page. (From Gleb Natapov 
)
3. Patch 7/7: Remove nested_vmx->apic_access_page.

Tang Chen (7):
  kvm: Use APIC_DEFAULT_PHYS_BASE macro as the apic access page address.
  kvm: Remove ept_identity_pagetable from struct kvm_arch.
  kvm: Make init_rmode_identity_map() return 0 on success.
  kvm, mem-hotplug: Reload L1' apic access page on migration in
vcpu_enter_guest().
  kvm, mem-hotplug: Reload L1's apic access page on migration when L2 is
running.
  kvm, mem-hotplug: Unpin and remove kvm_arch->apic_access_page.
  kvm, mem-hotplug: Unpin and remove nested_vmx->apic_access_page.

 arch/x86/include/asm/kvm_host.h |   4 +-
 arch/x86/kvm/svm.c  |   9 ++-
 arch/x86/kvm/vmx.c  | 139 ++--
 arch/x86/kvm/x86.c  |  24 +--
 include/linux/kvm_host.h|   2 +
 virt/kvm/kvm_main.c |  13 
 6 files changed, 122 insertions(+), 69 deletions(-)

-- 
1.8.3.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 v5 4/7] kvm, mem-hotplug: Reload L1' apic access page on migration in vcpu_enter_guest().

[Tang Chen]

apic access page is pinned in memory. As a result, it cannot be 
migrated/hot-removed.
Actually, it is not necessary to be pinned.

The hpa of apic access page is stored in VMCS APIC_ACCESS_ADDR pointer. When
the page is migrated, kvm_mmu_notifier_invalidate_page() will invalidate the
corresponding ept entry. This patch introduces a new vcpu request named
KVM_REQ_APIC_PAGE_RELOAD, and makes this request to all the vcpus at this time,
and force all the vcpus exit guest, and re-enter guest till they updates the 
VMCS
APIC_ACCESS_ADDR pointer to the new apic access page address, and updates
kvm->arch.apic_access_page to the new page.

Signed-off-by: Tang Chen 
---
 arch/x86/include/asm/kvm_host.h |  1 +
 arch/x86/kvm/svm.c  |  6 ++
 arch/x86/kvm/vmx.c  |  6 ++
 arch/x86/kvm/x86.c  | 15 +++
 include/linux/kvm_host.h|  2 ++
 virt/kvm/kvm_main.c | 12 
 6 files changed, 42 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 35171c7..514183e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -739,6 +739,7 @@ struct kvm_x86_ops {
void (*hwapic_isr_update)(struct kvm *kvm, int isr);
void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
void (*set_virtual_x2apic_mode)(struct kvm_vcpu *vcpu, bool set);
+   void (*set_apic_access_page_addr)(struct kvm *kvm, hpa_t hpa);
void (*deliver_posted_interrupt)(struct kvm_vcpu *vcpu, int vector);
void (*sync_pir_to_irr)(struct kvm_vcpu *vcpu);
int (*set_tss_addr)(struct kvm *kvm, unsigned int addr);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 1d941ad..f2eacc4 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3619,6 +3619,11 @@ static void svm_set_virtual_x2apic_mode(struct kvm_vcpu 
*vcpu, bool set)
return;
 }
 
+static void svm_set_apic_access_page_addr(struct kvm *kvm, hpa_t hpa)
+{
+   return;
+}
+
 static int svm_vm_has_apicv(struct kvm *kvm)
 {
return 0;
@@ -4373,6 +4378,7 @@ static struct kvm_x86_ops svm_x86_ops = {
.enable_irq_window = enable_irq_window,
.update_cr8_intercept = update_cr8_intercept,
.set_virtual_x2apic_mode = svm_set_virtual_x2apic_mode,
+   .set_apic_access_page_addr = svm_set_apic_access_page_addr,
.vm_has_apicv = svm_vm_has_apicv,
.load_eoi_exitmap = svm_load_eoi_exitmap,
.hwapic_isr_update = svm_hwapic_isr_update,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 63c4c3e..da6d55d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7093,6 +7093,11 @@ static void vmx_set_virtual_x2apic_mode(struct kvm_vcpu 
*vcpu, bool set)
vmx_set_msr_bitmap(vcpu);
 }
 
+static void vmx_set_apic_access_page_addr(struct kvm *kvm, hpa_t hpa)
+{
+   vmcs_write64(APIC_ACCESS_ADDR, hpa);
+}
+
 static void vmx_hwapic_isr_update(struct kvm *kvm, int isr)
 {
u16 status;
@@ -8910,6 +8915,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
.enable_irq_window = enable_irq_window,
.update_cr8_intercept = update_cr8_intercept,
.set_virtual_x2apic_mode = vmx_set_virtual_x2apic_mode,
+   .set_apic_access_page_addr = vmx_set_apic_access_page_addr,
.vm_has_apicv = vmx_vm_has_apicv,
.load_eoi_exitmap = vmx_load_eoi_exitmap,
.hwapic_irr_update = vmx_hwapic_irr_update,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e05bd58..96f4188 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5989,6 +5989,19 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
kvm_apic_update_tmr(vcpu, tmr);
 }
 
+static void vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
+{
+   /*
+* apic access page could be migrated. When the page is being migrated,
+* GUP will wait till the migrate entry is replaced with the new pte
+* entry pointing to the new page.
+*/
+   vcpu->kvm->arch.apic_access_page = gfn_to_page(vcpu->kvm,
+   APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
+   kvm_x86_ops->set_apic_access_page_addr(vcpu->kvm,
+   page_to_phys(vcpu->kvm->arch.apic_access_page));
+}
+
 /*
  * Returns 1 to let __vcpu_run() continue the guest execution loop without
  * exiting to the userspace.  Otherwise, the value will be returned to the
@@ -6049,6 +6062,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
kvm_deliver_pmi(vcpu);
if (kvm_check_request(KVM_REQ_SCAN_IOAPIC, vcpu))
vcpu_scan_ioapic(vcpu);
+   if (kvm_check_request(KVM_REQ_APIC_PAGE_RELOAD, vcpu))
+   vcpu_reload_apic_access_page(vcpu);
}
 
if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) {
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index a4c33b3..8be076a 100644
--- 

[PATCH v5 5/7] kvm, mem-hotplug: Reload L1's apic access page on migration when L2 is running.

[Tang Chen]

This patch only handle "L1 and L2 vm share one apic access page" situation.

When L1 vm is running, if the shared apic access page is migrated, mmu_notifier 
will
request all vcpus to exit to L0, and reload apic access page physical address 
for
all the vcpus' vmcs (which is done by patch 5/6). And when it enters L2 vm, 
L2's vmcs
will be updated in prepare_vmcs02() called by nested_vm_run(). So we need to do
nothing.

When L2 vm is running, if the shared apic access page is migrated, mmu_notifier 
will
request all vcpus to exit to L0, and reload apic access page physical address 
for
all L2 vmcs. And this patch requests apic access page reload in L2->L1 vmexit.

Signed-off-by: Tang Chen 
---
 arch/x86/kvm/vmx.c  | 7 +++
 virt/kvm/kvm_main.c | 1 +
 2 files changed, 8 insertions(+)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index da6d55d..e7704b2 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8796,6 +8796,13 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 
exit_reason,
}
 
/*
+* Do not call kvm_reload_apic_access_page() because we are now
+* running, mmu_notifier will force to reload the page's hpa for L2
+* vmcs. Need to reload it for L1 before entering L1.
+*/
+   kvm_reload_apic_access_page(vcpu->kvm);
+
+   /*
 * Exiting from L2 to L1, we're now back to L1 which thinks it just
 * finished a VMLAUNCH or VMRESUME instruction, so we need to set the
 * success or failure flag accordingly.
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d8280de..784127e 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -214,6 +214,7 @@ void kvm_reload_apic_access_page(struct kvm *kvm)
 {
make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD);
 }
+EXPORT_SYMBOL_GPL(kvm_reload_apic_access_page);
 
 int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)
 {
-- 
1.8.3.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 v5 6/7] kvm, mem-hotplug: Unpin and remove kvm_arch->apic_access_page.

[Tang Chen]

To make apic access page migratable, we do not pin it in memory now.
When it is migrated, we should reload its physical address for all
vmcses. But when we tried to do this, all vcpu will access
kvm_arch->apic_access_page without any locking. This is not safe.

Actually, we do not need kvm_arch->apic_access_page anymore. Since
apic access page is not pinned in memory now, we can remove
kvm_arch->apic_access_page. When we need to write its physical address
into vmcs, use gfn_to_page() to get its page struct, which will also
pin it. And unpin it after then.

Suggested-by: Gleb Natapov 
Signed-off-by: Tang Chen 
---
 arch/x86/include/asm/kvm_host.h |  2 +-
 arch/x86/kvm/vmx.c  | 32 +---
 arch/x86/kvm/x86.c  | 15 +--
 3 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 514183e..70f0d2d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -576,7 +576,7 @@ struct kvm_arch {
struct kvm_apic_map *apic_map;
 
unsigned int tss_addr;
-   struct page *apic_access_page;
+   bool apic_access_page_done;
 
gpa_t wall_clock;
 
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e7704b2..058c373 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4002,7 +4002,7 @@ static int alloc_apic_access_page(struct kvm *kvm)
int r = 0;
 
mutex_lock(>slots_lock);
-   if (kvm->arch.apic_access_page)
+   if (kvm->arch.apic_access_page_done)
goto out;
kvm_userspace_mem.slot = APIC_ACCESS_PAGE_PRIVATE_MEMSLOT;
kvm_userspace_mem.flags = 0;
@@ -4018,7 +4018,12 @@ static int alloc_apic_access_page(struct kvm *kvm)
goto out;
}
 
-   kvm->arch.apic_access_page = page;
+   /*
+* Do not pin apic access page in memory so that memory hotplug
+* process is able to migrate it.
+*/
+   put_page(page);
+   kvm->arch.apic_access_page_done = true;
 out:
mutex_unlock(>slots_lock);
return r;
@@ -4536,9 +4541,16 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu)
vmcs_write32(TPR_THRESHOLD, 0);
}
 
-   if (vm_need_virtualize_apic_accesses(vmx->vcpu.kvm))
-   vmcs_write64(APIC_ACCESS_ADDR,
-
page_to_phys(vmx->vcpu.kvm->arch.apic_access_page));
+   if (vm_need_virtualize_apic_accesses(vmx->vcpu.kvm)) {
+   struct page *page = gfn_to_page(vmx->vcpu.kvm,
+   APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
+   vmcs_write64(APIC_ACCESS_ADDR, page_to_phys(page));
+   /*
+* Do not pin apic access page in memory so that memory
+* hotplug process is able to migrate it.
+*/
+   put_page(page);
+   }
 
if (vmx_vm_has_apicv(vcpu->kvm))
memset(>pi_desc, 0, sizeof(struct pi_desc));
@@ -7994,10 +8006,16 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu, 
struct vmcs12 *vmcs12)
vmcs_write64(APIC_ACCESS_ADDR,
  page_to_phys(vmx->nested.apic_access_page));
} else if (vm_need_virtualize_apic_accesses(vmx->vcpu.kvm)) {
+   struct page *page = gfn_to_page(vmx->vcpu.kvm,
+   APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
exec_control |=
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
-   vmcs_write64(APIC_ACCESS_ADDR,
-   page_to_phys(vcpu->kvm->arch.apic_access_page));
+   vmcs_write64(APIC_ACCESS_ADDR, page_to_phys(page));
+   /*
+* Do not pin apic access page in memory so that memory
+* hotplug process is able to migrate it.
+*/
+   put_page(page);
}
 
vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_control);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 96f4188..6da0b93 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5991,15 +5991,20 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
 
 static void vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
 {
+   struct page *page;
+
/*
 * apic access page could be migrated. When the page is being migrated,
 * GUP will wait till the migrate entry is replaced with the new pte
 * entry pointing to the new page.
 */
-   vcpu->kvm->arch.apic_access_page = gfn_to_page(vcpu->kvm,
-   APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
-   kvm_x86_ops->set_apic_access_page_addr(vcpu->kvm,
-   page_to_phys(vcpu->kvm->arch.apic_access_page));
+   page = 

Re: [RFC/PATCH v2 02/10] x86_64: add KASan support

[Andrey Ryabinin]

On 09/11/2014 08:46 AM, Andi Kleen wrote:
> On Wed, Sep 10, 2014 at 09:33:11PM -0700, H. Peter Anvin wrote:
>> On 09/10/2014 09:29 PM, Sasha Levin wrote:
>>> On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
 Except you just broke PVop kernels.
>>>
>>> So is this why v2 refuses to boot on my KVM guest? (was digging
>>> into that before I send a mail out).
>>>
>>
>> No, KVM should be fine.  It is Xen PV which ends up as a smoldering crater.
> 
> Just exclude it in Kconfig? I assume PV will eventually go away anyways.
> 
> -Andi
> 

That's done already in this patch:

--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -135,6 +135,7 @@ config X86
select HAVE_ACPI_APEI if ACPI
select HAVE_ACPI_APEI_NMI if ACPI
select ACPI_LEGACY_TABLES_LOOKUP if ACPI
+   select HAVE_ARCH_KASAN if X86_64 && !XEN

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

[Chuck Ebbert]

On Wed, 10 Sep 2014 23:59:08 +0200
Andi Kleen  wrote:

> > # addr2line -i -e ivb-ep-build/vmlinux 81025f18
> > 
> > arch/x86/include/asm/bitops.h:318
> > arch/x86/kernel/cpu/perf_event_intel_uncore.c:3339
> 
> i == zero  (ok)
> c points to some kernel looking address
> hwc->idx is 64
> 
>  /* fastpath, try to reuse previous register */
> for (i = 0; i < n; i++) {
> hwc = >event_list[i]->hw;
> c = hwc->constraint;
> 
> /* never assigned */
> if (hwc->idx == -1)
> break;
> 
> /* constraint still honored */
> if (!test_bit(hwc->idx, c->idxmsk))
> break;
> 

hwc->idx is not 64 -- it's 0xd64

The bt insn is causing a page fault 27 MB past c->idxmsk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] dt-bindings: Adding compatible attribute for SKY81452 regulator

[Gyungoh Yoo]

On Sat, Sep 06, 2014 at 03:38:28PM +0100, Mark Brown wrote:
> On Fri, Sep 05, 2014 at 10:55:07AM +0900, Gyungoh Yoo wrote:
> > On Mon, Sep 01, 2014 at 11:31:58AM +0100, Mark Brown wrote:
> 
> > > Why is this a good idea - can this driver be used for anything other
> > > than a sky81452?
> 
> > Yes. There is a possibility that this driver will be used by similar
> > device with SKY81452.
> 
> OK, so tha was slightly the wrong question.  What added information is
> forcing the user to create a subnode and specify a compatible string
> providing?  This driver is specifying a block of multiple regulators
> with absolute register addresses hard coded into it, there's no real
> ability to use the driver in a different configuration here.  As soon as
> we see the parent device we already know everything there is to know
> about the IP block, having a separate compatible string just forces the
> user to do more typing for no gain.

Thank you for your comments.

By the way,
I knew that compatible string is used for binding a driver.
http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property

And, from kernel 3.6, MFD core has a mechanism for binding of_node
to the driver with of_compatible.

Can I have a question about if it is possible to assign compatible string
for binding driver independently with reusability?

Thanks,
Gyungoh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 0/9] KVM-VFIO IRQ forward control

[Alex Williamson]

On Thu, 2014-09-11 at 05:10 +0200, Christoffer Dall wrote:
> On Tue, Sep 02, 2014 at 03:05:41PM -0600, Alex Williamson wrote:
> > On Mon, 2014-09-01 at 14:52 +0200, Eric Auger wrote:
> > > This RFC proposes an integration of "ARM: Forwarding physical
> > > interrupts to a guest VM" (http://lwn.net/Articles/603514/) in
> > > KVM.
> > > 
> > > It enables to transform a VFIO platform driver IRQ into a forwarded
> > > IRQ. The direct benefit is that, for a level sensitive IRQ, a VM
> > > switch can be avoided on guest virtual IRQ completion. Before this
> > > patch, a maintenance IRQ was triggered on the virtual IRQ completion.
> > > 
> > > When the IRQ is forwarded, the VFIO platform driver does not need to
> > > disable the IRQ anymore. Indeed when returning from the IRQ handler
> > > the IRQ is not deactivated. Only its priority is lowered. This means
> > > the same IRQ cannot hit before the guest completes the virtual IRQ
> > > and the GIC automatically deactivates the corresponding physical IRQ.
> > > 
> > > Besides, the injection still is based on irqfd triggering. The only
> > > impact on irqfd process is resamplefd is not called anymore on
> > > virtual IRQ completion since this latter becomes "transparent".
> > > 
> > > The current integration is based on an extension of the KVM-VFIO
> > > device, previously used by KVM to interact with VFIO groups. The
> > > patch serie now enables KVM to directly interact with a VFIO
> > > platform device. The VFIO external API was extended for that purpose.
> > > 
> > > Th KVM-VFIO device can get/put the vfio platform device, check its
> > > integrity and type, get the IRQ number associated to an IRQ index.
> > > 
> > > The IRQ forward programming is architecture specific (virtual interrupt
> > > controller programming basically). However the whole infrastructure is
> > > kept generic.
> > > 
> > > from a user point of view, the functionality is provided through new
> > > KVM-VFIO device commands, KVM_DEV_VFIO_DEVICE_(UN)FORWARD_IRQ
> > > and the capability can be checked with KVM_HAS_DEVICE_ATTR.
> > > Assignment can only be changed when the physical IRQ is not active.
> > > It is the responsability of the user to do this check.
> > > 
> > > This patch serie has the following dependencies:
> > > - "ARM: Forwarding physical interrupts to a guest VM"
> > >   (http://lwn.net/Articles/603514/) in
> > > - [PATCH v3] irqfd for ARM
> > > - and obviously the VFIO platform driver serie:
> > >   [RFC PATCH v6 00/20] VFIO support for platform devices on ARM
> > >   https://www.mail-archive.com/kvm@vger.kernel.org/msg103247.html
> > > 
> > > Integrated pieces can be found at
> > > ssh://git.linaro.org/people/eric.auger/linux.git
> > > on branch 3.17rc3_irqfd_forward_integ_v2
> > > 
> > > This was was tested on Calxeda Midway, assigning the xgmac main IRQ.
> > > 
> > > v1 -> v2:
> > > - forward control is moved from architecture specific file into generic
> > >   vfio.c module.
> > >   only kvm_arch_set_fwd_state remains architecture specific
> > > - integrate Kim's patch which enables KVM-VFIO for ARM
> > > - fix vgic state bypass in vgic_queue_hwirq
> > > - struct kvm_arch_forwarded_irq moved from arch/arm/include/uapi/asm/kvm.h
> > >   to include/uapi/linux/kvm.h
> > >   also irq_index renamed into index and guest_irq renamed into gsi
> > > - ASSIGN/DEASSIGN renamed into FORWARD/UNFORWARD
> > > - vfio_external_get_base_device renamed into vfio_external_base_device
> > > - vfio_external_get_type removed
> > > - kvm_vfio_external_get_base_device renamed into 
> > > kvm_vfio_external_base_device
> > > - __KVM_HAVE_ARCH_KVM_VFIO renamed into __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> > > 
> > > Eric Auger (8):
> > >   KVM: ARM: VGIC: fix multiple injection of level sensitive forwarded
> > > IRQ
> > >   KVM: ARM: VGIC: add forwarded irq rbtree lock
> > >   VFIO: platform: handler tests whether the IRQ is forwarded
> > >   KVM: KVM-VFIO: update user API to program forwarded IRQ
> > >   VFIO: Extend external user API
> > >   KVM: KVM-VFIO: add new VFIO external API hooks
> > >   KVM: KVM-VFIO: generic KVM_DEV_VFIO_DEVICE command and IRQ forwarding
> > > control
> > >   KVM: KVM-VFIO: ARM forwarding control
> > > 
> > > Kim Phillips (1):
> > >   ARM: KVM: Enable the KVM-VFIO device
> > > 
> > >  Documentation/virtual/kvm/devices/vfio.txt |  26 ++
> > >  arch/arm/include/asm/kvm_host.h|   7 +
> > >  arch/arm/kvm/Kconfig   |   1 +
> > >  arch/arm/kvm/Makefile  |   4 +-
> > >  arch/arm/kvm/kvm_vfio_arm.c|  85 +
> > >  drivers/vfio/platform/vfio_platform_irq.c  |   7 +-
> > >  drivers/vfio/vfio.c|  24 ++
> > >  include/kvm/arm_vgic.h |   1 +
> > >  include/linux/kvm_host.h   |  27 ++
> > >  include/linux/vfio.h   |   3 +
> > >  include/uapi/linux/kvm.h   |   9 +
> > >  virt/kvm/arm/vgic.c|  59 

Re: [RFC v2 8/9] KVM: KVM-VFIO: generic KVM_DEV_VFIO_DEVICE command and IRQ forwarding control

[Alex Williamson]

On Thu, 2014-09-11 at 05:10 +0200, Christoffer Dall wrote:
> On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
> > This patch introduces a new KVM_DEV_VFIO_DEVICE attribute.
> > 
> > This is a new control channel which enables KVM to cooperate with
> > viable VFIO devices.
> > 
> > The kvm-vfio device now holds a list of devices (kvm_vfio_device)
> > in addition to a list of groups (kvm_vfio_group). The new
> > infrastructure enables to check the validity of the VFIO device
> > file descriptor, get and hold a reference to it.
> > 
> > The first concrete implemented command is IRQ forward control:
> > KVM_DEV_VFIO_DEVICE_FORWARD_IRQ, KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ.
> > 
> > It consists in programing the VFIO driver and KVM in a consistent manner
> > so that an optimized IRQ injection/completion is set up. Each
> > kvm_vfio_device holds a list of forwarded IRQ. When putting a
> > kvm_vfio_device, the implementation makes sure the forwarded IRQs
> > are set again in the normal handling state (non forwarded).
> 
> 'putting a kvm_vfio_device' sounds to like you're golf'ing :)
> 
> When a kvm_vfio_device is released?
> 
> > 
> > The forwarding programmming is architecture specific, embodied by the
> > kvm_arch_set_fwd_state function. Its implementation is given in a
> > separate patch file.
> 
> I would drop the last sentence and instead indicate that this is handled
> properly when the architecture does not support such a feature.
> 
> > 
> > The forwarding control modality is enabled by the
> > __KVM_HAVE_ARCH_KVM_VFIO_FORWARD define.
> > 
> > Signed-off-by: Eric Auger 
> > 
> > ---
> > 
> > v1 -> v2:
> > - __KVM_HAVE_ARCH_KVM_VFIO renamed into __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> > - original patch file separated into 2 parts: generic part moved in vfio.c
> >   and ARM specific part(kvm_arch_set_fwd_state)
> > ---
> >  include/linux/kvm_host.h |  27 +++
> >  virt/kvm/vfio.c  | 452 
> > ++-
> >  2 files changed, 477 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index a4c33b3..24350dc 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -1065,6 +1065,21 @@ struct kvm_device_ops {
> >   unsigned long arg);
> >  };
> >  
> > +enum kvm_fwd_irq_action {
> > +   KVM_VFIO_IRQ_SET_FORWARD,
> > +   KVM_VFIO_IRQ_SET_NORMAL,
> > +   KVM_VFIO_IRQ_CLEANUP,
> 
> This is KVM internal API, so it would probably be good to document this.
> Especially the CLEANUP bit worries me, see below.

This also doesn't match the user API, which is simply FORWARD/UNFORWARD.
Extra states worry me too.

> > +};
> > +
> > +/* internal structure describing a forwarded IRQ */
> > +struct kvm_fwd_irq {
> > +   struct list_head link;
> 
> this list entry is local to the kvm vfio device, right? that means you
> probably want a struct with just the below fields, and then have a
> containing struct in the generic device file, private to it's logic.

Yes, this is part of the abstraction problem.

> > +   __u32 index; /* platform device irq index */

This is a vfio_device irq_index, but vfio_devices support indexes and
sub-indexes.  At this level the API should match vfio, not the specifics
of platform devices not supporting sub-index.

> > +   __u32 hwirq; /*physical IRQ */
> > +   __u32 gsi; /* virtual IRQ */
> > +   struct kvm_vcpu *vcpu; /* vcpu to inject into*/

Not sure I understand why vcpu is necessary.  Also I see a 'get' in the
code below, but not a 'put'.

> > +};
> > +
> >  void kvm_device_get(struct kvm_device *dev);
> >  void kvm_device_put(struct kvm_device *dev);
> >  struct kvm_device *kvm_device_from_filp(struct file *filp);
> > @@ -1075,6 +1090,18 @@ extern struct kvm_device_ops kvm_vfio_ops;
> >  extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
> >  extern struct kvm_device_ops kvm_flic_ops;
> >  
> > +#ifdef __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> > +int kvm_arch_set_fwd_state(struct kvm_fwd_irq *pfwd,
> 
> what's the 'p' in pfwd?

p is for pointer?

> > +  enum kvm_fwd_irq_action action);
> > +
> > +#else
> > +static inline int kvm_arch_set_fwd_state(struct kvm_fwd_irq *pfwd,
> > +enum kvm_fwd_irq_action action)
> > +{
> > +   return 0;
> > +}
> > +#endif
> > +
> >  #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
> >  
> >  static inline void kvm_vcpu_set_in_spin_loop(struct kvm_vcpu *vcpu, bool 
> > val)
> > diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> > index 76dc7a1..e4a81c4 100644
> > --- a/virt/kvm/vfio.c
> > +++ b/virt/kvm/vfio.c
> > @@ -18,14 +18,24 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  struct kvm_vfio_group {
> > struct list_head node;
> > struct vfio_group *vfio_group;
> >  };
> >  
> > +struct kvm_vfio_device {
> > +   struct list_head node;
> > +   struct vfio_device *vfio_device;
> > +   /* list of forwarded IRQs for that VFIO device */
> > +   struct 

Re: [RFC/PATCH v2 02/10] x86_64: add KASan support

[H. Peter Anvin]

On 09/10/2014 09:46 PM, Andi Kleen wrote:
> On Wed, Sep 10, 2014 at 09:33:11PM -0700, H. Peter Anvin wrote:
>> On 09/10/2014 09:29 PM, Sasha Levin wrote:
>>> On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
 Except you just broke PVop kernels.
>>>
>>> So is this why v2 refuses to boot on my KVM guest? (was digging
>>> into that before I send a mail out).
>>>
>>
>> No, KVM should be fine.  It is Xen PV which ends up as a smoldering crater.
> 
> Just exclude it in Kconfig? I assume PV will eventually go away anyways.
> 

That would be nice...

-hpa


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

Re: [RFC/PATCH v2 02/10] x86_64: add KASan support

[Andi Kleen]

On Wed, Sep 10, 2014 at 09:33:11PM -0700, H. Peter Anvin wrote:
> On 09/10/2014 09:29 PM, Sasha Levin wrote:
> > On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
> >> Except you just broke PVop kernels.
> > 
> > So is this why v2 refuses to boot on my KVM guest? (was digging
> > into that before I send a mail out).
> > 
> 
> No, KVM should be fine.  It is Xen PV which ends up as a smoldering crater.

Just exclude it in Kconfig? I assume PV will eventually go away anyways.

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

Re: [PATCH] mmc: dw_mmc: add support for ARM64

[Jaehoon Chung]

Hi, Alim.

On 09/11/2014 11:35 AM, Alim Akhtar wrote:
> Hi Jaehoon,
> On Sep 11, 2014 11:18 AM, "Jaehoon Chung"  > wrote:
>>
>> On 09/09/2014 08:31 PM, Alim Akhtar wrote:
>> > Hi Ulf,
>> >
>> > On Tue, Sep 9, 2014 at 12:21 PM, Ulf Hansson > > > wrote:
>> >> On 29 August 2014 12:24, Alim Akhtar > >> > wrote:
>> >>> There are upcoming ARM64 SoCs with dw_mmc host controller.
>> >>>
>> >>> Signed-off-by: Alim Akhtar > >>> >
>> >>> ---
>> >>>  drivers/mmc/host/Kconfig |2 +-
>> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>>
>> >>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>> >>> index a43295c..72dd6c2 100644
>> >>> --- a/drivers/mmc/host/Kconfig
>> >>> +++ b/drivers/mmc/host/Kconfig
>> >>> @@ -580,7 +580,7 @@ config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND
>> >>>  config MMC_DW
>> >>> tristate "Synopsys DesignWare Memory Card Interface"
>> >>> depends on HAS_DMA
>> >>> -   depends on ARC || ARM || MIPS || COMPILE_TEST
>> >>> +   depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
>> >>
>> >> Before enabling this, wouldn't it be better to add the needed support
>> >> in dw_mmc first? Or there are no changes needed?
>> >>
>> >> There are also ongoing development and discussions for exynos7, which
>> >> I guess relates to this?
>> >> http://www.spinics.net/lists/linux-mmc/msg28294.html
>> > Thanks for looking into this.
>> >
>> > Yes, this patch is being tested on exynos7 platform which is ongoing
>> > development.
>> > The above link is one of them.
>> > I feel this patch is too generic in nature and we now known at least
>> > exynos7 is going to use this.
>> > I don't know if there are any other ARM64 platform with dw_mmc controller.
>>
>> If we need to prepare the ARM64, the above patch(linked patch) has to merge, 
>> why not?
> I am not in hurry to merge this now, as I said, its upto the maintainers to 
> decide when to take this and I am ok with that.
>> But it needs to test for other SoCs and rework it.
> What rework you are anticipating here?

Sorry for confusing you. (I didn't see the above URL.)
You need to use this patch 
(http://www.spinics.net/lists/linux-mmc/msg21742.html), right?
Then need to rework it.

Best Regards,
Jaehoon Chung
> 
> Thanks.
>>
>> Best Regards,
>> Jaehoon Chung
>>
>> >
>> > So, I am going to leave this upto you to decide when to take this
>> > patch, incase you decided to take it after exynos7 support lands, I
>> > will send a reminder for this.
>> >>
>> >> Kind regards
>> >> Uffe
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> >> the body of a message to majord...@vger.kernel.org 
>> >> 
>> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>> >
>> >
>>
> 

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

Re: [PATCH v10 20/21] ext4: Add DAX functionality

[Dave Chinner]

On Wed, Sep 10, 2014 at 07:49:40PM +0300, Boaz Harrosh wrote:
> On 09/03/2014 02:13 PM, Dave Chinner wrote:
> <>
> > 
> > When direct IO fails ext4 falls back to buffered IO, right? And
> > dax_do_io() can return partial writes, yes?
> > 
> 
> There is no buffered writes with DAX. .I.E buffered writes are always
> direct as well. (No page cache)

Yes, I know. But you didn't actually read the code I pointed out,
did you?

> > So that means if you get, say, ENOSPC part way through a DAX write,
> > ext4 can start dirtying the page cache from
> > __generic_file_write_iter() because the DAX write didn't wholly
> > complete? And say this ENOSPC races with space being freed from
> > another inode, then the buffered write will succeed and we'll end up
> > with coherency issues, right?
> > 
> > This is not an idle question - XFS if firing asserts all over the
> > place when doing ENOSPC testing because DAX is returning partial
> > writes and the XFS direct IO code is expecting them to either wholly
> > complete or wholly fail. I can make the DAX variant do allow partial
> > writes, but I'm not going to add a useless fallback to buffered IO
> > for XFS when the (fully featured) direct allocation fails.
> > 
> 
> Right, no fall back.

And so ext4 is buggy, because what ext4 does 

> Because a fallback is just a retry, because in any
> way DAX assumes there is never a page_cache_page for a written data

... is not a retry - it falls back to a fundamentally different
code path. i.e:

sys_write()

new_sync_write
  ext4_file_write_iter
__generic_file_write_iter(O_DIRECT)
  written = generic_file_direct_write()
  if (error || complete write)
return
  /* short write! do buffered IO to finish! */
  generic_perform_write()
loop {
ext4_write_begin
ext4_write_end
}

and so we allocate pages in the page cache and do buffered IO into
them because DAX doesn't hook ->writebegin/write_end as we are
supposed to intercept all buffered IO at a higher level.

This causes data corruption when tested at ENOSPC on DAX enabled
ext4 filesystems. I think that it's an oversight and hence a bug
that needs to be fixed but I'm first asking Willy to see if it was
intentional or not because maybe I missed sometihng in the past 4
months since I've paid really close attention to the DAX code.

And in saying that, Boaz, I'd suggest you spend some time looking at
the history of the DAX patchset. Pay careful note to who came up
with the original idea and architecture that led to the IO path you
are so stridently defending.

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] cpufreq, release policy->rwsem on error

[Viresh Kumar]

On 10 September 2014 19:42, Prarit Bhargava  wrote:
> I have not been able to reliably reproduce the hardware failure that caused
> the warning.  In order to reproduce this I resorted to (sorry for the
> cut-and-paste)
>
> diff --git a/drivers/cpufreq/pcc-cpufreq.c 
> b/drivers/cpufreq/pcc-cpufreq.c
> index 728a2d8..c7724d2 100644
> --- a/drivers/cpufreq/pcc-cpufreq.c
> +++ b/drivers/cpufreq/pcc-cpufreq.c
> @@ -146,6 +146,8 @@ static unsigned int pcc_get_freq(unsigned int cpu)
> u32 input_buffer;
> u32 output_buffer;
>
> +   return 0;
> +
> spin_lock(_lock);
>
> pr_debug("get: get_freq for CPU %d\n", cpu);
>
> to simulate the cpufreq_driver->get() hardware failure.
>
> ---8<---
>
> While debugging a cpufreq-related hardware failure on a system I saw the
> following lockdep warning:
>
>  =
>  [ BUG: held lock freed! ] 3.17.0-rc4+ #1 Tainted: GE
>  -
>  insmod/2247 is freeing memory 88006e1b1400-88006e1b17ff, with a lock 
> still held there!
>   (>rwsem){+.+...}, at: [] 
> __cpufreq_add_dev.isra.21+0x47d/0xb80
>  3 locks held by insmod/2247:
>   #0:  (subsys mutex#5){+.+.+.}, at: [] 
> subsys_interface_register+0x69/0x120
>   #1:  (cpufreq_rwsem){.+.+.+}, at: [] 
> __cpufreq_add_dev.isra.21+0x73/0xb80
>   #2:  (>rwsem){+.+...}, at: [] 
> __cpufreq_add_dev.isra.21+0x47d/0xb80
>
>  stack backtrace:
>  CPU: 0 PID: 2247 Comm: insmod Tainted: GE  3.17.0-rc4+ #1
>  Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 08/24/2013
>    8f3063c4 88006f87bb30 8171b358
>   88006bcf3750 88006f87bb68 810e09e1 88006e1b1400
>   ea0001b86c00 8156d327 880073003500 0246
>  Call Trace:
>   [] dump_stack+0x4d/0x66
>   [] debug_check_no_locks_freed+0x171/0x180
>   [] ? __cpufreq_add_dev.isra.21+0x427/0xb80
>   [] kfree+0xab/0x2b0
>   [] __cpufreq_add_dev.isra.21+0x427/0xb80
>   [] ? _raw_spin_unlock+0x27/0x40
>   [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
>   [] cpufreq_add_dev+0xe/0x10
>   [] subsys_interface_register+0xc1/0x120
>   [] cpufreq_register_driver+0x112/0x340
>   [] ? kfree+0xda/0x2b0
>   [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
>   [] pcc_cpufreq_init+0x4af/0xe81 [pcc_cpufreq]
>   [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
>   [] do_one_initcall+0xd4/0x210
>   [] ? __vunmap+0xd2/0x120
>   [] load_module+0x1315/0x1b70
>   [] ? store_uevent+0x70/0x70
>   [] ? copy_module_from_fd.isra.44+0x129/0x180
>   [] SyS_finit_module+0xa6/0xd0
>   [] system_call_fastpath+0x16/0x1b
>  cpufreq: __cpufreq_add_dev: ->get() failed
> insmod: ERROR: could not insert module pcc-cpufreq.ko: No such device
>
> The warning occurs in the __cpufreq_add_dev() code which does
>
> down_write(>rwsem);
> ...
> if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {
> policy->cur = cpufreq_driver->get(policy->cpu);
> if (!policy->cur) {
> pr_err("%s: ->get() failed\n", __func__);
> goto err_get_freq;
> }
>
> If cpufreq_driver->get(policy->cpu) returns an error we execute the
> code at err_get_freq, which does not up the policy->rwsem.  This causes
> the lockdep warning.
>
> Trivial patch to up the policy->rwsem in the error path.
>
> After the patch has been applied, and an error occurs in the
> cpufreq_driver->get(policy->cpu) call we will now see
>
> cpufreq: __cpufreq_add_dev: ->get() failed
> cpufreq: __cpufreq_add_dev: ->get() failed
> modprobe: ERROR: could not insert 'pcc_cpufreq': No such device
>
> Signed-off-by: Prarit Bhargava 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org
> ---
>  drivers/cpufreq/cpufreq.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index d9fdedd..aadaed0 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1289,6 +1289,8 @@ err_get_freq:
> per_cpu(cpufreq_cpu_data, j) = NULL;
> write_unlock_irqrestore(_driver_lock, flags);
>
> +   up_write(>rwsem);
> +
> if (cpufreq_driver->exit)
> cpufreq_driver->exit(policy);
>  err_set_policy_cpu:

Fixes: "4e97b63 cpufreq: Initialize governor for a new policy under
policy->rwsem"
Stable: 3.14+

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

Re: [RFC/PATCH v2 02/10] x86_64: add KASan support

[H. Peter Anvin]

On 09/10/2014 09:29 PM, Sasha Levin wrote:
> On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
>> Except you just broke PVop kernels.
> 
> So is this why v2 refuses to boot on my KVM guest? (was digging
> into that before I send a mail out).
> 

No, KVM should be fine.  It is Xen PV which ends up as a smoldering crater.

-hpa


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

Re: [RFC/PATCH v2 02/10] x86_64: add KASan support

[H. Peter Anvin]

On 09/10/2014 09:29 PM, Sasha Levin wrote:
> On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
>> Except you just broke PVop kernels.
> 
> So is this why v2 refuses to boot on my KVM guest? (was digging
> into that before I send a mail out).
> 

No, KVM should be fine.  It is Xen PV which ends up as a smoldering crater.

-hpa


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

[PATCH] ARM: dts: Switch i2c0 to 400kHz on rk3288-evb-rk808

[Doug Anderson]

We should be able to talk to the PMIC at 400kHz.  No need to talk at
the slow 100kHz.

As measured by ftrace (with a bunch of extra patches, since cpufreq
for rk808 hasn't landed yet):
  before this change: cpu0_set_target() => ~500us
  after this change:  cpu0_set_target() => ~300us

Signed-off-by: Doug Anderson 
---
 arch/arm/boot/dts/rk3288-evb-rk808.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts 
b/arch/arm/boot/dts/rk3288-evb-rk808.dts
index 36db177..ff522f8 100644
--- a/arch/arm/boot/dts/rk3288-evb-rk808.dts
+++ b/arch/arm/boot/dts/rk3288-evb-rk808.dts
@@ -18,6 +18,7 @@
 };
 
  {
+   clock-frequency = <40>;
status = "okay";
 
rk808: pmic@1b {
-- 
2.1.0.rc2.206.gedb03e5

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

Re: [RFC/PATCH v2 02/10] x86_64: add KASan support

[Sasha Levin]

On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
> Except you just broke PVop kernels.

So is this why v2 refuses to boot on my KVM guest? (was digging
into that before I send a mail out).


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

Re: linux-3.16.2 queue (3.16.1+)

[Jeff Mahoney]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/6/14, 11:18 PM, Greg KH wrote:
> On Sun, Sep 07, 2014 at 02:47:55AM +0200, Matt wrote:
>> On Thu, Aug 28, 2014 at 9:18 PM, Matt 
>> wrote:
>>> On Thu, Aug 28, 2014 at 5:32 PM, Greg KH
>>>  wrote:
 On Thu, Aug 28, 2014 at 05:27:27PM +0200, Matt wrote:
> On Thu, Aug 28, 2014 at 5:22 PM, Greg KH
>  wrote:
>> On Thu, Aug 28, 2014 at 05:16:58PM +0200, Matt wrote:
>>> Hi Greg,
>>> 
>>> 
>>> please consider adding the following 2 patches to
>>> 3.16.2:
>>> 
>>> Jan Kara (1): reiserfs: Fix use after free in journal
>>> teardown
>>> 
>>> Jeff Mahoney (1): reiserfs: fix corruption introduced
>>> by balance_leaf refactor
>>> 
>>> 
>>> 
>>> Reason/Related:
>>> 
>>> https://bugzilla.kernel.org/show_bug.cgi?id=83121
>>> 
>>> https://bugzilla.kernel.org/show_bug.cgi?id=83321
>>> 
>>> http://forums.gentoo.org/viewtopic-t-998538-postdays-0-postorder-asc-start-0.html
>>>
>>>
>>>
>>> 
Many thanks in advance
>> 
>> I need git commit ids of these patches in Linus's tree,
>> can you provide those please?
>> 
>> thanks,
>> 
>> greg k-h
> 
> 
> Sure:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d
>
> 
reiserfs: fix corruption introduced by balance_leaf refactor
> 
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01777836c87081e4f68c4a43c9abe6114805f91e
>
> 
reiserfs: Fix use after free in journal teardown
> 
> 
> 
> are checkpatch warnings usually also fixed within stable
> releases ?
 
 No, not at all, please read
 Documentation/stable_kernel_patches.txt for what is
 acceptable for stable kernel patches.
 
 thanks,
 
 greg k-h
>>> 
>>> 
>>> okay, will do
>>> 
>>> thanks for pointing that out
>>> 
>>> 
>>> Regards
>>> 
>>> Matt
>> 
>> Hi Greg,
>> 
>> could you please add the above mentioned two patches
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d
>>
>> 
reiserfs: fix corruption introduced by balance_leaf refactor
>> 
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01777836c87081e4f68c4a43c9abe6114805f91e
>>
>> 
reiserfs: Fix use after free in journal teardown
>> 
>> in next stable (3.16.3) kernel ?
>> 
>> more and more people seem to be affected by the data corruption 
>> introduced by the recent changes.
>> 
>> 
>> Reading through Documentation/stable_kernel_rules.txt, 
>> http://cwe.mitre.org/data/definitions/416.html and 
>> http://www.hpenterprisesecurity.com/vulncat/en/vulncat/cpp/use_after_free.html
>>
>>
>> 
both patches seem relevant enough (concerning data integrity
>> filesystem-wise and security) to be included for the stable
>> branch
> 
> I'll queue this up when I get a chance, there are over 300 patches 
> pending for the stable kernels right now :(
> 
> Also, in the future, always cc sta...@vger.kernel.org for any
> stable requests so that they don't get lost.

Hi Greg -

27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d
Author: Jeff Mahoney 
Date:   Mon Aug 4 19:51:47 2014 -0400

reiserfs: fix corruption introduced by balance_leaf refactor

Commits f1f007c308e (reiserfs: balance_leaf refactor, pull out
balance_leaf_insert_left) and cf22df182bf (reiserfs: balance_leaf
refactor, pull out balance_leaf_paste_left) missed that the `body'
pointer was getting repositioned. Subsequent users of the pointer
would expect it to be repositioned, and as a result, parts of the
tree would get overwritten. The most common observed corruption
is indirect block pointers being overwritten.

Since the body value isn't actually used anymore in the called
routines,
we can pass back the offset it should be shifted. We constify the body
and ih pointers in the balance_leaf as a mostly-free preventative
measure.

Cc:  # 3.16
Reported-and-tested-by: Jeff Chua 
Signed-off-by: Jeff Mahoney 
Signed-off-by: Jan Kara 

Should there have been more? I thought it was enough to add the Cc
tag. This one has been in the tree, with the tags and with
"corruption" in the Subject since 13 Aug. I know you're busy but this
seems like a pretty obvious candidate for stable inclusion.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iQIcBAEBAgAGBQJUESUpAAoJEB57S2MheeWyt9oQAIEnvZPojErvzzv4IcvVheSI
Ju1XChkU4YDRW3W2e8PEjAhiPd1dMP7aEJvfq6AxlKYAYENaS/S2LdSbBbeVctFa
1VwBVakDkmHduVcb2hl3ldIQlHRW0w/q/fSk+NKZavANS/maIK/mj2HE8S3Op17C
iGsGZiluqaYp56yPHJK7XDorpWFoCVXIPlHUbec8lIxnyPqeytHo2W5UtfZZVeN3
BfGICzR57i7YjOtQ/lsmusiUjp7Ym4REKX1GGnIcZ1Po5F8oX4phMVaUR0gR1NSA
eYBcTyH245iWTQBFqE9D5AR0pHLnmi6EySEbNIWU3w0OYffDCBpqU7A7Dm5O2kng

Re: [RFC/PATCH v2 02/10] x86_64: add KASan support

[H. Peter Anvin]

Except you just broke PVop kernels.

Sent from my tablet, pardon any formatting problems.

> On Sep 10, 2014, at 15:45, Dave Hansen  wrote:
> 
>> On 09/10/2014 01:30 PM, Andrey Ryabinin wrote:
>> Yes, there is a reason for this. For inline instrumentation we need to
>> catch access to userspace without any additional check.
>> This means that we need shadow of 1 << 61 bytes and we don't have so
>> many addresses available.
> 
> That sounds reasonable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sgi-xp: Do not use BUG_ON(!spin_is_locked())

[Sharma, Sanjeev]

-Original Message-
From: Sanjeev Sharma [mailto:sanjeev_sha...@mentor.com] 
Sent: Wednesday, August 20, 2014 11:06 AM
To: c...@sgi.com; robinmh...@gmail.com
Cc: linux-kernel@vger.kernel.org; Sharma, Sanjeev; Sharma, Sanjeev
Subject: [PATCH v2] sgi-xp: Do not use BUG_ON(!spin_is_locked())

on some architecture spin_is_locked() always return false in uniprocessor 
configuration and can therefore not be used with BUG_ON.it would be advise to 
replace with lockdep_assert_held().

Signed-off-by: Sanjeev Sharma 
---
Changes in v2:
  - corrected the typo

 drivers/misc/sgi-xp/xpc_channel.c | 6 +++---
 drivers/misc/sgi-xp/xpc_sn2.c | 2 +-
 drivers/misc/sgi-xp/xpc_uv.c  | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/sgi-xp/xpc_channel.c 
b/drivers/misc/sgi-xp/xpc_channel.c
index 128d561..611d34f 100644
--- a/drivers/misc/sgi-xp/xpc_channel.c
+++ b/drivers/misc/sgi-xp/xpc_channel.c
@@ -28,7 +28,7 @@ xpc_process_connect(struct xpc_channel *ch, unsigned long 
*irq_flags)  {
enum xp_retval ret;
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
if (!(ch->flags & XPC_C_OPENREQUEST) ||
!(ch->flags & XPC_C_ROPENREQUEST)) { @@ -82,7 +82,7 @@ 
xpc_process_disconnect(struct xpc_channel *ch, unsigned long *irq_flags)
struct xpc_partition *part = _partitions[ch->partid];
u32 channel_was_connected = (ch->flags & XPC_C_WASCONNECTED);
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
if (!(ch->flags & XPC_C_DISCONNECTING))
return;
@@ -758,7 +758,7 @@ xpc_disconnect_channel(const int line, struct xpc_channel 
*ch,  {
u32 channel_was_connected = (ch->flags & XPC_C_CONNECTED);
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
if (ch->flags & (XPC_C_DISCONNECTING | XPC_C_DISCONNECTED))
return;
diff --git a/drivers/misc/sgi-xp/xpc_sn2.c b/drivers/misc/sgi-xp/xpc_sn2.c 
index 7d71c04..9d3b113 100644
--- a/drivers/misc/sgi-xp/xpc_sn2.c
+++ b/drivers/misc/sgi-xp/xpc_sn2.c
@@ -1674,7 +1674,7 @@ xpc_teardown_msg_structures_sn2(struct xpc_channel *ch)  {
struct xpc_channel_sn2 *ch_sn2 = >sn.sn2;
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
ch_sn2->remote_msgqueue_pa = 0;
 
diff --git a/drivers/misc/sgi-xp/xpc_uv.c b/drivers/misc/sgi-xp/xpc_uv.c index 
95c8944..828733c 100644
--- a/drivers/misc/sgi-xp/xpc_uv.c
+++ b/drivers/misc/sgi-xp/xpc_uv.c
@@ -1183,7 +1183,7 @@ xpc_teardown_msg_structures_uv(struct xpc_channel *ch)  {
struct xpc_channel_uv *ch_uv = >sn.uv;
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
kfree(ch_uv->cached_notify_gru_mq_desc);
ch_uv->cached_notify_gru_mq_desc = NULL;
--
1.7.11.7

Any update on this patch because it's been quite long time .


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

Fwd:

[joergsachau]

http://jackson.com.sg/_cool-video.avi?nylyn108655


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] RTC: RK808: remove tm_def structure

[Doug Anderson]

Chris,

On Wed, Sep 10, 2014 at 7:04 PM, Chris Zhong  wrote:
> Signed-off-by: Chris Zhong 

It's good to add a description, like:

If the date/time is invalid at bootup, there's no reason to set it to
a bogus value.  We can just let the data and time be invalid until
someone makes it valid.

> ---
>
>  drivers/rtc/rtc-rk808.c |   17 ++---
>  1 file changed, 2 insertions(+), 15 deletions(-)

Other than the lack of description, this looks great.  It applies atop
Andrew's patch to make tm_dev "static" and works like a charm.

I tested by hacking the device with:
  i2cset -f -y 0 0x1b 0x10 0xc1
  i2cset -f -y 0 0x1b 3 0x32
  i2cset -f -y 0 0x1b 0x10 0xc0

That made it think it was the 32nd day of the month.  I then rebooted and saw:
  [3.371853] rk808-rtc rk808-rtc: invalid date/time
  [3.379115] rk808-rtc rk808-rtc: rtc core: registered rk808-rtc as rtc0
  [5.411574] rk808-rtc rk808-rtc: hctosys: invalid date/time

I was still able to set the clock.  Once I did it worked fine.


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

Re: [RFC/PATCH v2 02/10] x86_64: add KASan support

[H. Peter Anvin]

On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
> This patch add arch specific code for kernel address sanitizer.
> 
> 16TB of virtual addressed used for shadow memory.
> It's located in range [0x8000 - 0x9000]
> Therefore PAGE_OFFSET has to be changed from 0x8800
> to 0x9000.

NAK on this.

0x8800 is the lowest usable address because we have agreed
to leave 0x8000-0x8800 for the hypervisor or
other non-OS uses.

Bumping PAGE_OFFSET seems needlessly messy, why not just designate a
zone higher up in memory?

-hpa

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

RE: [PATCH] zd1211rw: replace ZD_ASSERT with lockdep_assert_held()

[Sharma, Sanjeev]

-Original Message-
From: Johannes Berg [mailto:johan...@sipsolutions.net] 
Sent: Friday, August 22, 2014 5:01 PM
To: Sharma, Sanjeev
Cc: d...@gentoo.org; k...@deine-taler.de; linvi...@tuxdriver.com; 
linux-wirel...@vger.kernel.org; net...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] zd1211rw: replace ZD_ASSERT with lockdep_assert_held()

On Tue, 2014-08-19 at 06:39 +, Sharma, Sanjeev wrote:
> Ping for review the patch.

> Make sure it compiles ...

Any update on this patch ?

Regards
Sanjeev Sharma

Re: [RFC/PATCH v2 02/10] x86_64: add KASan support

[H. Peter Anvin]

On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
> This patch add arch specific code for kernel address sanitizer.
> 
> 16TB of virtual addressed used for shadow memory.
> It's located in range [0x8000 - 0x9000]
> Therefore PAGE_OFFSET has to be changed from 0x8800
> to 0x9000.

NAK on this.

0x8800 is the lowest usable address because we have agreed
to leave 0x8000-0x8800 for the hypervisor or
other non-OS uses.

Bumping PAGE_OFFSET seems needlessly messy, why not just designate a
zone higher up in memory?

-hpa

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

Re: [PATCH v3 16/17] arcmsr: support new adapter ARC12x4 series

[Ching Huang]

On Wed, 2014-09-10 at 11:58 +0200, Tomas Henzl wrote:
> On 09/09/2014 06:30 PM, Christoph Hellwig wrote:
> > Ching,
> >
> > do you have a chance to address Thomas second concern below?  As
> > far as I can tell (Thomas, please correct me) that's the last
> > outstanding concern, and I'd really like to merge the arcmsr updates
> > for the Linux 3.18 merge window.
> 
> Correct, still awaiting a response.

Christoph, Tomas,

Sorry for the late reply.

I think I misunderstand Tomas' meaning.
The spin lock in arcmsr_hbaD_polling_ccbdone() is necessary to protect 
doneq_index and have to be modified as following.

static int arcmsr_hbaD_polling_ccbdone(struct AdapterControlBlock *acb,
struct CommandControlBlock *poll_ccb)
{
bool error;
uint32_t poll_ccb_done = 0, poll_count = 0, flag_ccb, ccb_cdb_phy;
int rtn, doneq_index, index_stripped, outbound_write_pointer, toggle;
unsigned long flags;
struct ARCMSR_CDB *arcmsr_cdb;
struct CommandControlBlock *pCCB;
struct MessageUnit_D *pmu = acb->pmuD;

polling_hbaD_ccb_retry:
poll_count++;
while (1) {
spin_lock_irqsave(>doneq_lock, flags);
outbound_write_pointer = pmu->done_qbuffer[0].addressLow + 1;
doneq_index = pmu->doneq_index;
if ((outbound_write_pointer & 0xFFF) == (doneq_index & 0xFFF)) {
spin_unlock_irqrestore(>doneq_lock, flags);
if (poll_ccb_done) {
rtn = SUCCESS;
break;
} else {
msleep(25);
if (poll_count > 40) {
rtn = FAILED;
break;
}
goto polling_hbaD_ccb_retry;
}
}
toggle = doneq_index & 0x4000;
index_stripped = (doneq_index & 0xFFF) + 1;
index_stripped %= ARCMSR_MAX_ARC1214_DONEQUEUE;
pmu->doneq_index = index_stripped ? (index_stripped | toggle) :
((index_stripped + 1) | (toggle ^ 0x4000));
spin_unlock_irqrestore(>doneq_lock, flags);
doneq_index = pmu->doneq_index;
flag_ccb = pmu->done_qbuffer[doneq_index & 0xFFF].addressLow;
ccb_cdb_phy = (flag_ccb & 0xFFF0);
arcmsr_cdb = (struct ARCMSR_CDB *)(acb->vir2phy_offset +
ccb_cdb_phy);
pCCB = container_of(arcmsr_cdb, struct CommandControlBlock,
arcmsr_cdb);
poll_ccb_done |= (pCCB == poll_ccb) ? 1 : 0;
if ((pCCB->acb != acb) ||
(pCCB->startdone != ARCMSR_CCB_START)) {
if (pCCB->startdone == ARCMSR_CCB_ABORTED) {
pr_notice("arcmsr%d: scsi id = %d "
"lun = %d ccb = '0x%p' poll command "
"abort successfully\n"
, acb->host->host_no
, pCCB->pcmd->device->id
, (u32)pCCB->pcmd->device->lun
, pCCB);
pCCB->pcmd->result = DID_ABORT << 16;
arcmsr_ccb_complete(pCCB);
continue;
}
pr_notice("arcmsr%d: polling an illegal "
"ccb command done ccb = '0x%p' "
"ccboutstandingcount = %d\n"
, acb->host->host_no
, pCCB
, atomic_read(>ccboutstandingcount));
continue;
}
error = (flag_ccb & ARCMSR_CCBREPLY_FLAG_ERROR_MODE1)
? true : false;
arcmsr_report_ccb_state(acb, pCCB, error);
}
return rtn;
}


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


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

Re: [RFC/PATCH v2 01/10] Add kernel address sanitizer infrastructure.

[Sasha Levin]

On 09/10/2014 10:31 AM, Andrey Ryabinin wrote:
> +ifdef CONFIG_KASAN
> +  ifeq ($(call cc-option, $(CFLAGS_KASAN)),)
> +$(warning Cannot use CONFIG_KASAN: \
> +   -fsanitize=kernel-address not supported by compiler)
> +  endif
> +endif

This seems to always indicate that my gcc doesn't support
-fsanitize=kernel-address:

Makefile:769: Cannot use CONFIG_KASAN: -fsanitize=kernel-address not supported 
by compiler

Even though:

$ gcc --version
gcc (GCC) 5.0.0 20140904 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat test.c
#include 
#include 

void __asan_init_v3(void) { }

int main(int argc, char *argv[])
{
return 0;
}
$ gcc -fsanitize=kernel-address test.c
$ ./a.out
$


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

Re: [PATCH] mfd: RK808: Add register caching

[Chris Zhong]

On 09/10/2014 07:06 AM, Doug Anderson wrote:

Let's define the voltatile registers (those that can't be cached) and
enable caching.  The rk808 is accessed almost constantly with cpufreq
so this is really nice.

As measured by ftrace:
   before this change: cpu0_set_target() => ~2200us
   after this change:  cpu0_set_target() =>  ~500us

Signed-off-by: Doug Anderson 
---
  drivers/mfd/rk808.c | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 0324422..bd02150 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -29,10 +29,40 @@ struct rk808_reg_data {
int value;
  };
  
+static bool rk808_is_volatile_reg(struct device *dev, unsigned int reg)

+{
+   /*
+* Notes:
+* - Technically the ROUND_30s bit makes RTC_CTRL_REG volatile, but
+*   we don't use that feature.  It's better to cache.
+* - It's unlikely we care that RK808_DEVCTRL_REG is volatile since
+*   bits are cleared in case when we shutoff anyway, but better safe.
+*/
+
+   switch (reg) {
+   case RK808_SECONDS_REG ... RK808_WEEKS_REG:
+   case RK808_RTC_STATUS_REG:
+   case RK808_VB_MON_REG:
+   case RK808_THERMAL_REG:
+   case RK808_DCDC_UV_STS_REG:
+   case RK808_LDO_UV_STS_REG:
+   case RK808_DCDC_PG_REG:
+   case RK808_LDO_PG_REG:
+   case RK808_DEVCTRL_REG:
+   case RK808_INT_STS_REG1:
+   case RK808_INT_STS_REG2:
+   return true;
+   }
+
+   return false;
+}
+
  static const struct regmap_config rk808_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = RK808_IO_POL_REG,
+   .cache_type = REGCACHE_RBTREE,
+   .volatile_reg = rk808_is_volatile_reg,
  };
  
  static struct resource rtc_resources[] = {

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

Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Vivek Gautam]

Hi,


On Thursday, September 11, 2014 1:52 AM, "Julius Werner" 
 wrote




right, use that to call phy_init() at the right time, then you need to
add a new ->calibrate() method which, likely, will only be used by you
;-)



so you mean, the xhci should itself call phy_init() at a time suitable,
so that ->calibrate() is not required at all ?


I'm not sure if that's a good idea because it would require phy_init()
and calibrate() to always mean the same thing. The calibrate() for
Exynos5420 needs to be called both during boot and after system
resume, but there might be other platforms that don't want to
completely shutdown and reinit their PHYs during suspend/resume with
the same functions used for boot. For example, Tegra5 (proposed driver
at http://www.spinics.net/lists/linux-usb/msg113093.html) can
power-gate the PHY during suspend, but that's not running the same
code as in the phy_init()/phy_shutdown() methods (the posted patch
doesn't contain all power-gating code yet, but you can get an idea
about how it has to work from
https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.10/drivers/usb/host/xhci-tegra.c).
It would also mean that the initial phy_init() call must always come
after the XHCI reset, and I am not sure if that would fit nicely with
all platforms.

right, and what's more generic than adding the support for PHYs straight 
into xHCI ?


Well, if we are going to have a calibrate() method (as in "stuff the
PHY does after every controller reset if it needs to"), we have to add
it either to the XHCI stack or the USB core.
I thought the USB core would be more generic, because in theory it's 
possible that e.g. an

EHCI controller might have a similar requirement.


Atleast on Exynos systems I can see that unless PHY is initialized the 
controller
fails to reset. So taking a path wherein we initialize the PHYs after 
controller resets

is not going to help us generically across all controllers.
With XHCI though things are OK while resetting, and we can initialize the 
PHYs
after controller reset happens but here too DWC3 is already initializing the 
PHYs
for exynos systems too, so it may not be very wise to do that initialization 
stuff

once again. Plus the PHY core prevents multiple initialization anyways.

(Also, we have the gen_phy pointer in a USB core structure (struct 
usb_hcd), so I thought

making this feature generic to the USB core and thus available to all
kinds of host controllers would be more natural.) 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 4/9] VFIO: platform: handler tests whether the IRQ is forwarded

[Christoffer Dall]

On Mon, Sep 01, 2014 at 02:52:43PM +0200, Eric Auger wrote:
> In case the IRQ is forwarded, the VFIO platform IRQ handler does not
> need to disable the IRQ anymore. In that mode, when the handler completes

add a comma after completes

> the IRQ is not deactivated but only its priority is lowered.
> 
> Some other actor (typically a guest) is supposed to deactivate the IRQ,
> allowing at that time a new physical IRQ to hit.
> 
> In virtualization use case, the physical IRQ is automatically completed
> by the interrupt controller when the guest completes the corresponding
> virtual IRQ.
> 
> Signed-off-by: Eric Auger 
> ---
>  drivers/vfio/platform/vfio_platform_irq.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_irq.c 
> b/drivers/vfio/platform/vfio_platform_irq.c
> index 6768508..1f851b2 100644
> --- a/drivers/vfio/platform/vfio_platform_irq.c
> +++ b/drivers/vfio/platform/vfio_platform_irq.c
> @@ -88,13 +88,18 @@ static irqreturn_t vfio_irq_handler(int irq, void *dev_id)
>   struct vfio_platform_irq *irq_ctx = dev_id;
>   unsigned long flags;
>   int ret = IRQ_NONE;
> + struct irq_data *d;
> + bool is_forwarded;
>  
>   spin_lock_irqsave(_ctx->lock, flags);
>  
>   if (!irq_ctx->masked) {
>   ret = IRQ_HANDLED;
> + d = irq_get_irq_data(irq_ctx->hwirq);
> + is_forwarded = irqd_irq_forwarded(d);
>  
> - if (irq_ctx->flags & VFIO_IRQ_INFO_AUTOMASKED) {
> + if (irq_ctx->flags & VFIO_IRQ_INFO_AUTOMASKED &&
> + !is_forwarded) {
>   disable_irq_nosync(irq_ctx->hwirq);
>   irq_ctx->masked = true;
>   }
> -- 
> 1.9.1
> 
It makes sense that these needs to be all controlled in the kernel, but
I'm wondering if it would be cleaner / more correct to clear the
AUTOMASKED flag when the IRQ is forwarded and have vfio refuse setting
this flag as long as the irq is forwarded?

-Christoffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v10 09/21] Replace the XIP page fault handler with the DAX page fault handler

[Dave Chinner]

On Wed, Sep 10, 2014 at 11:23:37AM -0400, Matthew Wilcox wrote:
> On Wed, Sep 03, 2014 at 05:47:24PM +1000, Dave Chinner wrote:
> > > + error = get_block(inode, block, , 0);
> > > + if (!error && (bh.b_size < PAGE_SIZE))
> > > + error = -EIO;
> > > + if (error)
> > > + goto unlock_page;
> > 
> > page fault into unwritten region, returns buffer_unwritten(bh) ==
> > true. Hence buffer_written(bh) is false, and we take this branch:
> > 
> > > + if (!buffer_written() && !vmf->cow_page) {
> > > + if (vmf->flags & FAULT_FLAG_WRITE) {
> > > + error = get_block(inode, block, , 1);
> > 
> > Exactly what are you expecting to happen here? We don't do
> > allocation because there are already unwritten blocks over this
> > extent, and so bh will be unchanged when returning. i.e. it will
> > still be mapping an unwritten extent.
> 
> I was expecting calling get_block() on an unwritten extent to convert it
> to a written extent.  Your suggestion below of using b_end_io() to do that
> is a better idea.
> 
> So this should be:
> 
>   if (!buffer_mapped() && !vmf->cow_page) {
> 
> ... right?

Yes, that is the conclusion I reached as well. ;)

> > dax: add IO completion callback for page faults
> > 
> > From: Dave Chinner 
> > 
> > When a page fault drops into a hole, it needs to allocate an extent.
> > Filesystems may allocate unwritten extents so that the underlying
> > contents are not exposed until data is written to the extent. In
> > that case, we need an io completion callback to run once the blocks
> > have been zeroed to indicate that it is safe for the filesystem to
> > mark those blocks written without exposing stale data in the event
> > of a crash.
> > 
> > Signed-off-by: Dave Chinner 
> > ---
> >  fs/dax.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/dax.c b/fs/dax.c
> > index 96c4fed..387ca78 100644
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
> > @@ -306,6 +306,7 @@ static int do_dax_fault(struct vm_area_struct *vma, 
> > struct vm_fault *vmf,
> > memset(, 0, sizeof(bh));
> > block = (sector_t)vmf->pgoff << (PAGE_SHIFT - blkbits);
> > bh.b_size = PAGE_SIZE;
> > +   bh.b_end_io = NULL;
> 
> Given the above memset, I don't think we need to explicitly set b_end_io
> to NULL.

I missed that ;)

> >   repeat:
> > page = find_get_page(mapping, vmf->pgoff);
> > @@ -364,8 +365,12 @@ static int do_dax_fault(struct vm_area_struct *vma, 
> > struct vm_fault *vmf,
> > return VM_FAULT_LOCKED;
> > }
> >  
> > -   if (buffer_unwritten() || buffer_new())
> > +   if (buffer_unwritten() || buffer_new()) {
> > +   /* XXX: errors zeroing the blocks are propagated how? */
> > dax_clear_blocks(inode, bh.b_blocknr, bh.b_size);
> 
> That's a great question.  I think we need to segfault here.

I suspect there are other cases where we need to do similar "trigger
segv" error handling rather than ignoring errors altogether...

> 
> > +   if (bh.b_end_io)
> > +   bh.b_end_io(, 1);
> > +   }
> 
> I think ext4 is going to need to set b_end_io too.  Right now, it uses the
> dio_iodone_t to convert unwritten extents to written extents, but we don't
> have (and I don't think we should have) a kiocb for page faults.

Yes, ext4 is going to need this as well. After I got XFS running
without problems, I then went back and ran xfstests on ext4 and it
failed many of the tests that do operations into unwritten regions.

> So, if it's OK with you, I'm going to fold this patch into version 11 and
> add your Reviewed-by to it.

Fold it in, I'll review the result ;)

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: [RFC v2 0/9] KVM-VFIO IRQ forward control

[Christoffer Dall]

On Tue, Sep 02, 2014 at 03:05:41PM -0600, Alex Williamson wrote:
> On Mon, 2014-09-01 at 14:52 +0200, Eric Auger wrote:
> > This RFC proposes an integration of "ARM: Forwarding physical
> > interrupts to a guest VM" (http://lwn.net/Articles/603514/) in
> > KVM.
> > 
> > It enables to transform a VFIO platform driver IRQ into a forwarded
> > IRQ. The direct benefit is that, for a level sensitive IRQ, a VM
> > switch can be avoided on guest virtual IRQ completion. Before this
> > patch, a maintenance IRQ was triggered on the virtual IRQ completion.
> > 
> > When the IRQ is forwarded, the VFIO platform driver does not need to
> > disable the IRQ anymore. Indeed when returning from the IRQ handler
> > the IRQ is not deactivated. Only its priority is lowered. This means
> > the same IRQ cannot hit before the guest completes the virtual IRQ
> > and the GIC automatically deactivates the corresponding physical IRQ.
> > 
> > Besides, the injection still is based on irqfd triggering. The only
> > impact on irqfd process is resamplefd is not called anymore on
> > virtual IRQ completion since this latter becomes "transparent".
> > 
> > The current integration is based on an extension of the KVM-VFIO
> > device, previously used by KVM to interact with VFIO groups. The
> > patch serie now enables KVM to directly interact with a VFIO
> > platform device. The VFIO external API was extended for that purpose.
> > 
> > Th KVM-VFIO device can get/put the vfio platform device, check its
> > integrity and type, get the IRQ number associated to an IRQ index.
> > 
> > The IRQ forward programming is architecture specific (virtual interrupt
> > controller programming basically). However the whole infrastructure is
> > kept generic.
> > 
> > from a user point of view, the functionality is provided through new
> > KVM-VFIO device commands, KVM_DEV_VFIO_DEVICE_(UN)FORWARD_IRQ
> > and the capability can be checked with KVM_HAS_DEVICE_ATTR.
> > Assignment can only be changed when the physical IRQ is not active.
> > It is the responsability of the user to do this check.
> > 
> > This patch serie has the following dependencies:
> > - "ARM: Forwarding physical interrupts to a guest VM"
> >   (http://lwn.net/Articles/603514/) in
> > - [PATCH v3] irqfd for ARM
> > - and obviously the VFIO platform driver serie:
> >   [RFC PATCH v6 00/20] VFIO support for platform devices on ARM
> >   https://www.mail-archive.com/kvm@vger.kernel.org/msg103247.html
> > 
> > Integrated pieces can be found at
> > ssh://git.linaro.org/people/eric.auger/linux.git
> > on branch 3.17rc3_irqfd_forward_integ_v2
> > 
> > This was was tested on Calxeda Midway, assigning the xgmac main IRQ.
> > 
> > v1 -> v2:
> > - forward control is moved from architecture specific file into generic
> >   vfio.c module.
> >   only kvm_arch_set_fwd_state remains architecture specific
> > - integrate Kim's patch which enables KVM-VFIO for ARM
> > - fix vgic state bypass in vgic_queue_hwirq
> > - struct kvm_arch_forwarded_irq moved from arch/arm/include/uapi/asm/kvm.h
> >   to include/uapi/linux/kvm.h
> >   also irq_index renamed into index and guest_irq renamed into gsi
> > - ASSIGN/DEASSIGN renamed into FORWARD/UNFORWARD
> > - vfio_external_get_base_device renamed into vfio_external_base_device
> > - vfio_external_get_type removed
> > - kvm_vfio_external_get_base_device renamed into 
> > kvm_vfio_external_base_device
> > - __KVM_HAVE_ARCH_KVM_VFIO renamed into __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> > 
> > Eric Auger (8):
> >   KVM: ARM: VGIC: fix multiple injection of level sensitive forwarded
> > IRQ
> >   KVM: ARM: VGIC: add forwarded irq rbtree lock
> >   VFIO: platform: handler tests whether the IRQ is forwarded
> >   KVM: KVM-VFIO: update user API to program forwarded IRQ
> >   VFIO: Extend external user API
> >   KVM: KVM-VFIO: add new VFIO external API hooks
> >   KVM: KVM-VFIO: generic KVM_DEV_VFIO_DEVICE command and IRQ forwarding
> > control
> >   KVM: KVM-VFIO: ARM forwarding control
> > 
> > Kim Phillips (1):
> >   ARM: KVM: Enable the KVM-VFIO device
> > 
> >  Documentation/virtual/kvm/devices/vfio.txt |  26 ++
> >  arch/arm/include/asm/kvm_host.h|   7 +
> >  arch/arm/kvm/Kconfig   |   1 +
> >  arch/arm/kvm/Makefile  |   4 +-
> >  arch/arm/kvm/kvm_vfio_arm.c|  85 +
> >  drivers/vfio/platform/vfio_platform_irq.c  |   7 +-
> >  drivers/vfio/vfio.c|  24 ++
> >  include/kvm/arm_vgic.h |   1 +
> >  include/linux/kvm_host.h   |  27 ++
> >  include/linux/vfio.h   |   3 +
> >  include/uapi/linux/kvm.h   |   9 +
> >  virt/kvm/arm/vgic.c|  59 +++-
> >  virt/kvm/vfio.c| 497 
> > -
> >  13 files changed, 733 insertions(+), 17 deletions(-)
> >  create mode 100644 arch/arm/kvm/kvm_vfio_arm.c
> > 
> 
> Have we ventured too far in the other 

Re: [RFC v2 6/9] VFIO: Extend external user API

[Christoffer Dall]

On Mon, Sep 01, 2014 at 02:52:45PM +0200, Eric Auger wrote:
> New functions are added to be called from ARM KVM-VFIO device.

This commit message seems somewhat random.  This patch doesn't deal with
anything ARM specific, it introduces some generic functions that allows
users external to vfio itself to retrieve information about a vfio
platform device.

> 
> - vfio_device_get_external_user enables to get a vfio device from
>   its fd
> - vfio_device_put_external_user puts the vfio device
> - vfio_external_base_device returns the struct device*,
>   useful to access the platform_device
> 
> Signed-off-by: Eric Auger 
> 
> ---
> 
> v1 -> v2:
> 
> - vfio_external_get_base_device renamed into vfio_external_base_device
> - vfio_external_get_type removed
> ---
>  drivers/vfio/vfio.c  | 24 
>  include/linux/vfio.h |  3 +++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 8e84471..282814e 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1401,6 +1401,30 @@ void vfio_group_put_external_user(struct vfio_group 
> *group)
>  }
>  EXPORT_SYMBOL_GPL(vfio_group_put_external_user);
>  
> +struct vfio_device *vfio_device_get_external_user(struct file *filep)
> +{
> + struct vfio_device *vdev = filep->private_data;
> +
> + if (filep->f_op != _device_fops)
> + return ERR_PTR(-EINVAL);
> +
> + vfio_device_get(vdev);
> + return vdev;
> +}
> +EXPORT_SYMBOL_GPL(vfio_device_get_external_user);
> +
> +void vfio_device_put_external_user(struct vfio_device *vdev)
> +{
> + vfio_device_put(vdev);
> +}
> +EXPORT_SYMBOL_GPL(vfio_device_put_external_user);
> +
> +struct device *vfio_external_base_device(struct vfio_device *vdev)
> +{
> + return vdev->dev;
> +}
> +EXPORT_SYMBOL_GPL(vfio_external_base_device);
> +
>  int vfio_external_user_iommu_id(struct vfio_group *group)
>  {
>   return iommu_group_id(group->iommu_group);
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index ffe04ed..bd4b6cb 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -99,6 +99,9 @@ extern void vfio_group_put_external_user(struct vfio_group 
> *group);
>  extern int vfio_external_user_iommu_id(struct vfio_group *group);
>  extern long vfio_external_check_extension(struct vfio_group *group,
> unsigned long arg);
> +extern struct vfio_device *vfio_device_get_external_user(struct file *filep);
> +extern void vfio_device_put_external_user(struct vfio_device *vdev);
> +extern struct device *vfio_external_base_device(struct vfio_device *vdev);
>  
>  struct pci_dev;
>  #ifdef CONFIG_EEH
> -- 
> 1.9.1
> 
Looks good to me,
-Christoffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 7/9] KVM: KVM-VFIO: add new VFIO external API hooks

[Christoffer Dall]

On Mon, Sep 01, 2014 at 02:52:46PM +0200, Eric Auger wrote:
> add functions that implement the gateway to the extended

Capital letter when beginning a new sentence.  Also the reference to
'the extended VFIO API' feels a bit weird.  Can't you make your commit
message a little more descriptive of this patch, something along the
lines of:

Provide wrapper functions that allows KVM-VFIO device code to get an
external handle on a struct vfio_device based on a vfio device file
descriptor.  We provide this through three new functions:

(assuming I got this right).



> external VFIO API:
> - kvm_vfio_device_get_external_user
> - kvm_vfio_device_put_external_user
> - kvm_vfio_external_base_device
> 
> Signed-off-by: Eric Auger 
> 
> ---
> 
> v1 -> v2:
> - kvm_vfio_external_get_base_device renamed into
>   kvm_vfio_external_base_device
> - kvm_vfio_external_get_type removed
> ---
>  arch/arm/include/asm/kvm_host.h |  5 +
>  virt/kvm/vfio.c | 45 
> +
>  2 files changed, 50 insertions(+)
> 
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 6dfb404..1aee6bb 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -171,6 +171,11 @@ void kvm_set_spte_hva(struct kvm *kvm, unsigned long 
> hva, pte_t pte);
>  unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
>  int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
>  
> +struct vfio_device;
> +struct vfio_device *kvm_vfio_device_get_external_user(struct file *filep);
> +void kvm_vfio_device_put_external_user(struct vfio_device *vdev);
> +struct device *kvm_vfio_external_base_device(struct vfio_device *vdev);
> +
>  /* We do not have shadow page tables, hence the empty hooks */
>  static inline int kvm_age_hva(struct kvm *kvm, unsigned long hva)
>  {
> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> index ba1a93f..76dc7a1 100644
> --- a/virt/kvm/vfio.c
> +++ b/virt/kvm/vfio.c
> @@ -59,6 +59,51 @@ static void kvm_vfio_group_put_external_user(struct 
> vfio_group *vfio_group)
>   symbol_put(vfio_group_put_external_user);
>  }
>  
> +struct vfio_device *kvm_vfio_device_get_external_user(struct file *filep)
> +{
> + struct vfio_device *vdev;
> + struct vfio_device *(*fn)(struct file *);
> +
> + fn = symbol_get(vfio_device_get_external_user);
> + if (!fn)
> + return ERR_PTR(-EINVAL);
> +
> + vdev = fn(filep);
> +
> + symbol_put(vfio_device_get_external_user);
> +
> + return vdev;
> +}
> +
> +void kvm_vfio_device_put_external_user(struct vfio_device *vdev)
> +{
> + void (*fn)(struct vfio_device *);
> +
> + fn = symbol_get(vfio_device_put_external_user);
> + if (!fn)
> + return;
> +
> + fn(vdev);
> +
> + symbol_put(vfio_device_put_external_user);
> +}
> +
> +struct device *kvm_vfio_external_base_device(struct vfio_device *vdev)
> +{
> + struct device *(*fn)(struct vfio_device *);
> + struct device *dev;
> +
> + fn = symbol_get(vfio_external_base_device);
> + if (!fn)
> + return NULL;
> +
> + dev = fn(vdev);
> +
> + symbol_put(vfio_external_base_device);
> +
> + return dev;
> +}
> +
>  static bool kvm_vfio_group_is_coherent(struct vfio_group *vfio_group)
>  {
>   long (*fn)(struct vfio_group *, unsigned long);
> -- 
> 1.9.1
> 

otherwise looks good to me!
-Christoffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 9/9] KVM: KVM-VFIO: ARM forwarding control

[Christoffer Dall]

On Mon, Sep 01, 2014 at 02:52:48PM +0200, Eric Auger wrote:
> Enables forwarding control for ARM. By defining
> __KVM_HAVE_ARCH_KVM_VFIO_FORWARD the patch enables
> KVM_DEV_VFIO_DEVICE_FORWARD/UNFORWARD_IRQ command on ARM. As a
> result it brings an optimized injection/completion handling for
> forwarded IRQ. The ARM specific part is implemented in a new module,

a new module ?!?

you mean file, right?

> kvm_vfio_arm.c
> 
> Signed-off-by: Eric Auger 
> ---
>  arch/arm/include/asm/kvm_host.h |  2 +
>  arch/arm/kvm/Makefile   |  2 +-
>  arch/arm/kvm/kvm_vfio_arm.c | 85 
> +
>  3 files changed, 88 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/kvm/kvm_vfio_arm.c
> 
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 1aee6bb..dfd3b05 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -25,6 +25,8 @@
>  #include 
>  #include 
>  
> +#define __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> +
>  #if defined(CONFIG_KVM_ARM_MAX_VCPUS)
>  #define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
>  #else
> diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
> index ea1fa76..26a5a42 100644
> --- a/arch/arm/kvm/Makefile
> +++ b/arch/arm/kvm/Makefile
> @@ -19,7 +19,7 @@ kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o 
> $(KVM)/eventfd.o $(KVM)/vf
>  
>  obj-y += kvm-arm.o init.o interrupts.o
>  obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
> -obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o
> +obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o 
> kvm_vfio_arm.o
>  obj-$(CONFIG_KVM_ARM_VGIC) += $(KVM)/arm/vgic.o
>  obj-$(CONFIG_KVM_ARM_VGIC) += $(KVM)/arm/vgic-v2.o
>  obj-$(CONFIG_KVM_ARM_TIMER) += $(KVM)/arm/arch_timer.o
> diff --git a/arch/arm/kvm/kvm_vfio_arm.c b/arch/arm/kvm/kvm_vfio_arm.c
> new file mode 100644
> index 000..0d316b1
> --- /dev/null
> +++ b/arch/arm/kvm/kvm_vfio_arm.c
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (C) 2014 Linaro Ltd.
> + * Authors: Eric Auger 
> + *
> + * 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,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * kvm_arch_set_fwd_state - change the forwarded state of an IRQ
> + * @pfwd: the forwarded irq struct
> + * @action: action to perform (set forward, set back normal, cleanup)
> + *
> + * programs the GIC and VGIC
> + * returns the VGIC map/unmap return status
> + * It is the responsability of the caller to make sure the physical IRQ
responsibility
> + * is not active. there is a critical section between the start of the
 There
> + * VFIO IRQ handler and LR programming.

Did we implement code to ensure this in the previous patch? I don't
think I noticed it.  Doesn't disabling the IRQ have the desired effect?

a critical section? who are the contenders of this, what action should I
take to make sure access to the critical section is serialized?

> + */
> +int kvm_arch_set_fwd_state(struct kvm_fwd_irq *pfwd,
> +enum kvm_fwd_irq_action action)
> +{
> + int ret;
> + struct irq_desc *desc = irq_to_desc(pfwd->hwirq);
> + struct irq_data *d = >irq_data;
> + struct irq_chip *chip = desc->irq_data.chip;
> +
> + disable_irq(pfwd->hwirq);
> + /* no fwd state change can happen if the IRQ is in progress */
> + if (irqd_irq_inprogress(d)) {
> + kvm_err("%s cannot change fwd state (IRQ %d in progress\n",
> + __func__, pfwd->hwirq);
> + enable_irq(pfwd->hwirq);
> + return -1;

-1? seems like you're defining some new error code convenstions here.
-EBUSY perhaps?

probably want to use a goto label here as well.

> + }
> +
> + if (action == KVM_VFIO_IRQ_SET_FORWARD) {
> + irqd_set_irq_forwarded(d);
> + ret = vgic_map_phys_irq(pfwd->vcpu,
> + pfwd->gsi + VGIC_NR_PRIVATE_IRQS,
> + pfwd->hwirq);
> + } else if (action == KVM_VFIO_IRQ_SET_NORMAL) {
> + irqd_clr_irq_forwarded(d);
> + ret = vgic_unmap_phys_irq(pfwd->vcpu,
> +   pfwd->gsi +
> + VGIC_NR_PRIVATE_IRQS,
> +   pfwd->hwirq);
> + } else if (action == KVM_VFIO_IRQ_CLEANUP) {
> + 

Re: [RFC v2 8/9] KVM: KVM-VFIO: generic KVM_DEV_VFIO_DEVICE command and IRQ forwarding control

[Christoffer Dall]

On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
> This patch introduces a new KVM_DEV_VFIO_DEVICE attribute.
> 
> This is a new control channel which enables KVM to cooperate with
> viable VFIO devices.
> 
> The kvm-vfio device now holds a list of devices (kvm_vfio_device)
> in addition to a list of groups (kvm_vfio_group). The new
> infrastructure enables to check the validity of the VFIO device
> file descriptor, get and hold a reference to it.
> 
> The first concrete implemented command is IRQ forward control:
> KVM_DEV_VFIO_DEVICE_FORWARD_IRQ, KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ.
> 
> It consists in programing the VFIO driver and KVM in a consistent manner
> so that an optimized IRQ injection/completion is set up. Each
> kvm_vfio_device holds a list of forwarded IRQ. When putting a
> kvm_vfio_device, the implementation makes sure the forwarded IRQs
> are set again in the normal handling state (non forwarded).

'putting a kvm_vfio_device' sounds to like you're golf'ing :)

When a kvm_vfio_device is released?

> 
> The forwarding programmming is architecture specific, embodied by the
> kvm_arch_set_fwd_state function. Its implementation is given in a
> separate patch file.

I would drop the last sentence and instead indicate that this is handled
properly when the architecture does not support such a feature.

> 
> The forwarding control modality is enabled by the
> __KVM_HAVE_ARCH_KVM_VFIO_FORWARD define.
> 
> Signed-off-by: Eric Auger 
> 
> ---
> 
> v1 -> v2:
> - __KVM_HAVE_ARCH_KVM_VFIO renamed into __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> - original patch file separated into 2 parts: generic part moved in vfio.c
>   and ARM specific part(kvm_arch_set_fwd_state)
> ---
>  include/linux/kvm_host.h |  27 +++
>  virt/kvm/vfio.c  | 452 
> ++-
>  2 files changed, 477 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index a4c33b3..24350dc 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1065,6 +1065,21 @@ struct kvm_device_ops {
> unsigned long arg);
>  };
>  
> +enum kvm_fwd_irq_action {
> + KVM_VFIO_IRQ_SET_FORWARD,
> + KVM_VFIO_IRQ_SET_NORMAL,
> + KVM_VFIO_IRQ_CLEANUP,

This is KVM internal API, so it would probably be good to document this.
Especially the CLEANUP bit worries me, see below.

> +};
> +
> +/* internal structure describing a forwarded IRQ */
> +struct kvm_fwd_irq {
> + struct list_head link;

this list entry is local to the kvm vfio device, right? that means you
probably want a struct with just the below fields, and then have a
containing struct in the generic device file, private to it's logic.

> + __u32 index; /* platform device irq index */
> + __u32 hwirq; /*physical IRQ */
> + __u32 gsi; /* virtual IRQ */
> + struct kvm_vcpu *vcpu; /* vcpu to inject into*/
> +};
> +
>  void kvm_device_get(struct kvm_device *dev);
>  void kvm_device_put(struct kvm_device *dev);
>  struct kvm_device *kvm_device_from_filp(struct file *filp);
> @@ -1075,6 +1090,18 @@ extern struct kvm_device_ops kvm_vfio_ops;
>  extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
>  extern struct kvm_device_ops kvm_flic_ops;
>  
> +#ifdef __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> +int kvm_arch_set_fwd_state(struct kvm_fwd_irq *pfwd,

what's the 'p' in pfwd?

> +enum kvm_fwd_irq_action action);
> +
> +#else
> +static inline int kvm_arch_set_fwd_state(struct kvm_fwd_irq *pfwd,
> +  enum kvm_fwd_irq_action action)
> +{
> + return 0;
> +}
> +#endif
> +
>  #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>  
>  static inline void kvm_vcpu_set_in_spin_loop(struct kvm_vcpu *vcpu, bool val)
> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> index 76dc7a1..e4a81c4 100644
> --- a/virt/kvm/vfio.c
> +++ b/virt/kvm/vfio.c
> @@ -18,14 +18,24 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct kvm_vfio_group {
>   struct list_head node;
>   struct vfio_group *vfio_group;
>  };
>  
> +struct kvm_vfio_device {
> + struct list_head node;
> + struct vfio_device *vfio_device;
> + /* list of forwarded IRQs for that VFIO device */
> + struct list_head fwd_irq_list;
> + int fd;
> +};
> +
>  struct kvm_vfio {
>   struct list_head group_list;
> + struct list_head device_list;
>   struct mutex lock;
>   bool noncoherent;
>  };
> @@ -246,12 +256,441 @@ static int kvm_vfio_set_group(struct kvm_device *dev, 
> long attr, u64 arg)
>   return -ENXIO;
>  }
>  
> +/**
> + * get_vfio_device - returns the vfio-device corresponding to this fd
> + * @fd:fd of the vfio platform device
> + *
> + * checks it is a vfio device
> + * increment its ref counter

why the short lines?  Just write this out in proper English.

> + */
> +static struct vfio_device *kvm_vfio_get_vfio_device(int fd)
> +{
> + struct fd f;
> + struct vfio_device *vdev;
> +
> + f = 

Re: [RFC v2 2/9] KVM: ARM: VGIC: add forwarded irq rbtree lock

[Christoffer Dall]

On Mon, Sep 01, 2014 at 02:52:41PM +0200, Eric Auger wrote:
> add a lock related to the rb tree manipulation. The rb tree can be

Ok, I can't hold myself back any longer.  Please begin sentences with a
capital letter. You don't do this in French? :)

> searched in one thread (irqfd handler for instance) and map/unmap
> happen in another.
> 
> Signed-off-by: Eric Auger 
> ---
>  include/kvm/arm_vgic.h |  1 +
>  virt/kvm/arm/vgic.c| 46 +-
>  2 files changed, 38 insertions(+), 9 deletions(-)
> 
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index 743020f..3da244f 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -177,6 +177,7 @@ struct vgic_dist {
>   unsigned long   irq_pending_on_cpu;
>  
>   struct rb_root  irq_phys_map;
> + spinlock_t  rb_tree_lock;
>  #endif
>  };
>  
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index 8ef495b..dbc2a5a 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -1630,9 +1630,15 @@ static struct rb_root *vgic_get_irq_phys_map(struct 
> kvm_vcpu *vcpu,
>  
>  int vgic_map_phys_irq(struct kvm_vcpu *vcpu, int virt_irq, int phys_irq)
>  {
> - struct rb_root *root = vgic_get_irq_phys_map(vcpu, virt_irq);
> - struct rb_node **new = >rb_node, *parent = NULL;
> + struct rb_root *root;
> + struct rb_node **new, *parent = NULL;
>   struct irq_phys_map *new_map;
> + struct vgic_dist *dist = >kvm->arch.vgic;
> +
> + spin_lock(>rb_tree_lock);
> +
> + root = vgic_get_irq_phys_map(vcpu, virt_irq);
> + new = >rb_node;
>  
>   /* Boilerplate rb_tree code */
>   while (*new) {
> @@ -1644,13 +1650,17 @@ int vgic_map_phys_irq(struct kvm_vcpu *vcpu, int 
> virt_irq, int phys_irq)
>   new = &(*new)->rb_left;
>   else if (this->virt_irq > virt_irq)
>   new = &(*new)->rb_right;
> - else
> + else {
> + spin_unlock(>rb_tree_lock);
>   return -EEXIST;
> + }

can you initialize a ret variable to -EEXIST in the beginning of this
function, and add an out label above the unlock below, replace this
multi-line statement with a goto out, and set ret = 0 after the while
loop?

>   }
>  
>   new_map = kzalloc(sizeof(*new_map), GFP_KERNEL);
> - if (!new_map)
> + if (!new_map) {
> + spin_unlock(>rb_tree_lock);
>   return -ENOMEM;

then this becomes ret = -ENOMEM; goto out;

> + }
>  
>   new_map->virt_irq = virt_irq;
>   new_map->phys_irq = phys_irq;
> @@ -1658,6 +1668,8 @@ int vgic_map_phys_irq(struct kvm_vcpu *vcpu, int 
> virt_irq, int phys_irq)
>   rb_link_node(_map->node, parent, new);
>   rb_insert_color(_map->node, root);
>  
> + spin_unlock(>rb_tree_lock);
> +

aren't you allocating memory with GFP_KERNEL while holding a spinlock
here?

>   return 0;
>  }
>  
> @@ -1685,24 +1697,39 @@ static struct irq_phys_map 
> *vgic_irq_map_search(struct kvm_vcpu *vcpu,
>  
>  int vgic_get_phys_irq(struct kvm_vcpu *vcpu, int virt_irq)
>  {
> - struct irq_phys_map *map = vgic_irq_map_search(vcpu, virt_irq);
> + struct irq_phys_map *map;
> + struct vgic_dist *dist = >kvm->arch.vgic;
> + int ret;
> +
> + spin_lock(>rb_tree_lock);
> + map = vgic_irq_map_search(vcpu, virt_irq);
>  
>   if (map)
> - return map->phys_irq;
> + ret = map->phys_irq;
> + else
> + ret =  -ENOENT;

initialize ret to -ENOENT and avoid the else statement.

> +
> + spin_unlock(>rb_tree_lock);
> + return ret;
>  
> - return -ENOENT;
>  }
>  
>  int vgic_unmap_phys_irq(struct kvm_vcpu *vcpu, int virt_irq, int phys_irq)
>  {
> - struct irq_phys_map *map = vgic_irq_map_search(vcpu, virt_irq);
> + struct irq_phys_map *map;
> + struct vgic_dist *dist = >kvm->arch.vgic;
> +
> + spin_lock(>rb_tree_lock);
> +
> + map = vgic_irq_map_search(vcpu, virt_irq);
>  
>   if (map && map->phys_irq == phys_irq) {
>   rb_erase(>node, vgic_get_irq_phys_map(vcpu, virt_irq));
>   kfree(map);
> + spin_unlock(>rb_tree_lock);

can kfree sleep?  I don't remember.  In any case, you can unlock before
calling kfree.

>   return 0;
>   }
> -
> + spin_unlock(>rb_tree_lock);
>   return -ENOENT;

an out label and single unlock location would be preferred here as well
I think.

>  }
>  
> @@ -1898,6 +1925,7 @@ int kvm_vgic_create(struct kvm *kvm)
>   }
>  
>   spin_lock_init(>arch.vgic.lock);
> + spin_lock_init(>arch.vgic.rb_tree_lock);
>   kvm->arch.vgic.in_kernel = true;
>   kvm->arch.vgic.vctrl_base = vgic->vctrl_base;
>   kvm->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [RFC v2 1/9] KVM: ARM: VGIC: fix multiple injection of level sensitive forwarded IRQ

[Christoffer Dall]

On Mon, Sep 01, 2014 at 02:52:40PM +0200, Eric Auger wrote:
> Fix multiple injection of level sensitive forwarded IRQs.
> With current code, the second injection fails since the state bitmaps
> are not reset (process_maintenance is not called anymore).
> New implementation consists in fully bypassing the vgic state
> management for forwarded IRQ (checks are ignored in
> vgic_update_irq_pending). This obviously assumes the forwarded IRQ is
> injected from kernel side.
> 
> Signed-off-by: Eric Auger 
> 
> ---
> 
> It was attempted to reset the states in __kvm_vgic_sync_hwstate, checking
> the emptied LR of forwarded IRQ. However surprisingly this solution does
> not seem to work. Some times, a new forwarded IRQ injection is observed
> while the LR of the previous instance was not observed as empty.

hmmm, concerning.  It would probably have been helpful overall if you
could start by describing the problem with the current implementation in
the commit message, and then explain the fix...

> 
> v1 -> v2:
> - fix vgic state bypass in vgic_queue_hwirq
> ---
>  virt/kvm/arm/vgic.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index 0007300..8ef495b 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -1259,7 +1259,9 @@ static bool vgic_queue_sgi(struct kvm_vcpu *vcpu, int 
> irq)
>  
>  static bool vgic_queue_hwirq(struct kvm_vcpu *vcpu, int irq)
>  {
> - if (vgic_irq_is_queued(vcpu, irq))
> + bool is_forwarded =  (vgic_get_phys_irq(vcpu, irq) > 0);

can you create a static function to factor this vgic_get_phys_irq check out, 
please?

> +
> + if (vgic_irq_is_queued(vcpu, irq) && !is_forwarded)
>   return true; /* level interrupt, already queued */

so essentially if an IRQ is already on a LR so we shouldn't resample the
line, then we still resample the line if the IRQ is forwarded?

I think you need to explain this, both to me here, and also in the code
by moving the comment following the return statement above the check and
comment this clearly.

>  
>   if (vgic_queue_irq(vcpu, 0, irq)) {
> @@ -1517,14 +1519,18 @@ static bool vgic_update_irq_pending(struct kvm *kvm, 
> int cpuid,
>   int edge_triggered, level_triggered;
>   int enabled;
>   bool ret = true;
> + bool is_forwarded;
>  
>   spin_lock(>lock);
>  
>   vcpu = kvm_get_vcpu(kvm, cpuid);
> + is_forwarded = (vgic_get_phys_irq(vcpu, irq_num) > 0);

use your new function here as well.

> +
>   edge_triggered = vgic_irq_is_edge(vcpu, irq_num);
>   level_triggered = !edge_triggered;
>  
> - if (!vgic_validate_injection(vcpu, irq_num, level)) {
> + if (!is_forwarded &&
> + !vgic_validate_injection(vcpu, irq_num, level)) {

I don't see the rationale here either.  If an IRQ is forwarded, why do
you need to do anything if the condition of the line hasn't changed for
a level-triggered IRQ or if you have a falling edge on an edge-triggered
IRQ (assuming active-HIGH)?

>   ret = false;
>   goto out;
>   }
> @@ -1557,7 +1563,8 @@ static bool vgic_update_irq_pending(struct kvm *kvm, 
> int cpuid,
>   goto out;
>   }
>  
> - if (level_triggered && vgic_irq_is_queued(vcpu, irq_num)) {
> + if (!is_forwarded &&
> + level_triggered && vgic_irq_is_queued(vcpu, irq_num)) {

So here it's making sense for SPIs since you can have an EOIed interrupt
on a CPU that didn't exit the VM yet, and this it's still queued, but
you still need to resample the line to respect other CPUs.  Only, we
ever only target a single CPU for SPIs IIRC (the first in the target
list register) so we have to wait for that CPU to to exit the VM anyhow.

This leads me to believe that, given a fowarded irq, you can only have
XXX situations at this point:

(1) is_queued && target_vcpu_in_vm:
The vcpu should resample this line when it exits the VM, because we
check the LRs for IRQs like this one, so we don't have to do anything
and go to out here.

(2) is_queued && !target_vcpu_in_vm::
You have a bug because you exited the VM which must have done an EOI on
the interrupt, otherwise this function shouldn't have been called!  This
means that we should have cleared the queued state of the interrupt.

(3) !is_queued && whatever:
Set the irq pending bits, so do not goto out.

I'm aware that there's theoretically a race between (1) and (2), but you
should consider target_cpu_in_vm as "it hasn't been through
__kvm_vgic_sync_hwstate() yet" and this should hold.

Tell me where this breaks?

-Christoffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: KVM: add irqfd support

[Christoffer Dall]

On Mon, Sep 01, 2014 at 10:53:04AM +0200, Eric Auger wrote:
> This patch enables irqfd on ARM.
> 
> irqfd framework enables to inject a virtual IRQ into a guest upon an
> eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with
> a kvm_irqfd struct that associates a VM, an eventfd, a virtual IRQ number
> (aka. the gsi). When an actor signals the eventfd (typically a VFIO
> platform driver), the kvm irqfd subsystem injects the provided virtual
> IRQ into the guest.
> 
> Resamplefd also is supported for level sensitive interrupts, ie. the
> user can provide another eventfd that is triggered when the completion
> of the virtual IRQ (gsi) is detected by the GIC.
> 
> The gsi must correspond to a shared peripheral interrupt (SPI), ie the
> GIC interrupt ID is gsi+32.
> 
> this patch enables CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQFD.
> CONFIG_HAVE_KVM_IRQCHIP is removed. No IRQ routing table is used
> (irqchip.c and irqcomm.c are not used).
> 
> Both KVM_CAP_IRQFD & KVM_CAP_IRQFD_RESAMPLE capabilities are exposed
> 
> Signed-off-by: Eric Auger 
> 
> ---
> 
> This patch serie deprecates the previous serie featuring GSI routing
> (https://patches.linaro.org/32261/)
> 
> The patch serie has the following dependencies:
> - arm/arm64: KVM: Various VGIC cleanups and improvements
>   https://lists.cs.columbia.edu/pipermail/kvmarm/2014-June/009979.html
> - "KVM: EVENTFD: remove inclusion of irq.h"
> 
> All pieces can be found on git://git.linaro.org/people/eric.auger/linux.git
> branch irqfd_norouting_integ_v3
> 
> This work was tested with Calxeda Midway xgmac main interrupt with
> qemu-system-arm and QEMU VFIO platform device.
> 
> v2 -> v3:
> - removal of irq.h from eventfd.c put in a separate patch to increase
>   visibility
> - properly expose KVM_CAP_IRQFD capability in arm.c
> - remove CONFIG_HAVE_KVM_IRQCHIP meaningfull only if irq_comm.c is used
> 
> v1 -> v2:
> - rebase on 3.17rc1
> - move of the dist unlock in process_maintenance
> - remove of dist lock in __kvm_vgic_sync_hwstate
> - rewording of the commit message (add resamplefd reference)
> - remove irq.h
> ---
>  Documentation/virtual/kvm/api.txt |  5 +++-
>  arch/arm/include/uapi/asm/kvm.h   |  3 +++
>  arch/arm/kvm/Kconfig  |  4 +--
>  arch/arm/kvm/Makefile |  2 +-
>  arch/arm/kvm/arm.c|  3 +++
>  virt/kvm/arm/vgic.c   | 56 
> ---
>  6 files changed, 65 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/virtual/kvm/api.txt 
> b/Documentation/virtual/kvm/api.txt
> index beae3fd..8118b12 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2204,7 +2204,7 @@ into the hash PTE second double word).
>  4.75 KVM_IRQFD
>  
>  Capability: KVM_CAP_IRQFD
> -Architectures: x86 s390
> +Architectures: x86 s390 arm
>  Type: vm ioctl
>  Parameters: struct kvm_irqfd (in)
>  Returns: 0 on success, -1 on error
> @@ -2230,6 +2230,9 @@ Note that closing the resamplefd is not sufficient to 
> disable the
>  irqfd.  The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment
>  and need not be specified with KVM_IRQFD_FLAG_DEASSIGN.
>  
> +On ARM/arm64 the injected must be a shared peripheral interrupt (SPI).
> +This means the programmed GIC interrupt ID is gsi+32.
> +

See above comment.

>  4.76 KVM_PPC_ALLOCATE_HTAB
>  
>  Capability: KVM_CAP_PPC_ALLOC_HTAB
> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
> index e6ebdd3..3034c66 100644
> --- a/arch/arm/include/uapi/asm/kvm.h
> +++ b/arch/arm/include/uapi/asm/kvm.h
> @@ -194,6 +194,9 @@ struct kvm_arch_memory_slot {
>  /* Highest supported SPI, from VGIC_NR_IRQS */
>  #define KVM_ARM_IRQ_GIC_MAX  127
>  
> +/* One single KVM irqchip, ie. the VGIC */
> +#define KVM_NR_IRQCHIPS  1
> +
>  /* PSCI interface */
>  #define KVM_PSCI_FN_BASE 0x95c1ba5e
>  #define KVM_PSCI_FN(n)   (KVM_PSCI_FN_BASE + (n))
> diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
> index 466bd29..e519a40 100644
> --- a/arch/arm/kvm/Kconfig
> +++ b/arch/arm/kvm/Kconfig
> @@ -24,6 +24,7 @@ config KVM
>   select KVM_MMIO
>   select KVM_ARM_HOST
>   depends on ARM_VIRT_EXT && ARM_LPAE
> + select HAVE_KVM_EVENTFD
>   ---help---
> Support hosting virtualized guest machines. You will also
> need to select one or more of the processor modules below.
> @@ -55,7 +56,7 @@ config KVM_ARM_MAX_VCPUS
>  config KVM_ARM_VGIC
>   bool "KVM support for Virtual GIC"
>   depends on KVM_ARM_HOST && OF
> - select HAVE_KVM_IRQCHIP
> + select HAVE_KVM_IRQFD
>   default y
>   ---help---
> Adds support for a hardware assisted, in-kernel GIC emulation.
> @@ -63,7 +64,6 @@ config KVM_ARM_VGIC
>  config KVM_ARM_TIMER
>   bool "KVM support for Architected Timers"
>   depends on KVM_ARM_VGIC && ARM_ARCH_TIMER
> - select HAVE_KVM_IRQCHIP
>   default y
> 

Re: [RFC v2 5/9] KVM: KVM-VFIO: update user API to program forwarded IRQ

[Christoffer Dall]

On Mon, Sep 01, 2014 at 02:52:44PM +0200, Eric Auger wrote:
> add new device group commands:
> - KVM_DEV_VFIO_DEVICE_FORWARD_IRQ and
>   KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ
> 
> which enable to turn forwarded IRQ mode on/off.
> 
> the kvm_arch_forwarded_irq struct embodies a forwarded IRQ
> 
> Signed-off-by: Eric Auger 
> 
> ---
> 
> v1 -> v2:
> - struct kvm_arch_forwarded_irq moved from arch/arm/include/uapi/asm/kvm.h
>   to include/uapi/linux/kvm.h
>   also irq_index renamed into index and guest_irq renamed into gsi
> - ASSIGN/DEASSIGN renamed into FORWARD/UNFORWARD
> ---
>  Documentation/virtual/kvm/devices/vfio.txt | 26 ++
>  include/uapi/linux/kvm.h   |  9 +
>  2 files changed, 35 insertions(+)
> 
> diff --git a/Documentation/virtual/kvm/devices/vfio.txt 
> b/Documentation/virtual/kvm/devices/vfio.txt
> index ef51740..048baa0 100644
> --- a/Documentation/virtual/kvm/devices/vfio.txt
> +++ b/Documentation/virtual/kvm/devices/vfio.txt
> @@ -13,6 +13,7 @@ VFIO-group is held by KVM.
>  
>  Groups:
>KVM_DEV_VFIO_GROUP
> +  KVM_DEV_VFIO_DEVICE
>  
>  KVM_DEV_VFIO_GROUP attributes:
>KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
> @@ -20,3 +21,28 @@ KVM_DEV_VFIO_GROUP attributes:
>  
>  For each, kvm_device_attr.addr points to an int32_t file descriptor
>  for the VFIO group.
> +
> +KVM_DEV_VFIO_DEVICE attributes:
> +  KVM_DEV_VFIO_DEVICE_FORWARD_IRQ
> +  KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ
> +
> +For each, kvm_device_attr.addr points to a kvm_arch_forwarded_irq struct.
> +This user API makes possible to create a special IRQ handling mode,

  KVM_DEV_VFIO_DEVICE_FORWARD_IRQ enables a special IRQ handling mode on
  hardware that supports it,

> +where KVM and a VFIO platform driver collaborate to improve IRQ
> +handling performance.
> +
> +'fd represents the file descriptor of a valid VFIO device whose physical

fd is described out of context here.  Can you copy the struct definition
into this document, perhaps right after the "For each, ..." line above.

> +IRQ, referenced by its index, is injected into the VM guest irq (gsi).
 as a virtual IRQ (specified
 by the gsi field) into the
 VM.

> +
> +On FORWARD_IRQ, KVM-VFIO device programs:
   When setting the  KVM_DEV_VFIO_DEVICE_FORWARD_IRQ attribute, the
   KVM-VFIO device tells the host (or VFIO?) to not complete the
   physical IRQ, and instead ensures that KVM (or the VM) completes the
   physical IRQ.

> +- the host, to not complete the physical IRQ itself.
> +- the GIC, to automatically complete the physical IRQ when the guest
> +  completes the virtual IRQ.

and drop this bullet form.

> +This avoids trapping the end-of-interrupt for level sensitive IRQ.

avoid this last line, it's specific to ARM.

> +
> +On UNFORWARD_IRQ, one returns to the mode where the host completes the
   When setting the KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ attribute, the
   host (VFIO?) will again complete the physical IRQ and KVM will not...
 
> +physical IRQ and the guest completes the virtual IRQ.
> +
> +It is up to the caller of this API to make sure the IRQ is not
> +outstanding when the FORWARD/UNFORWARD is called. This could lead to

outstanding? can you be specific?

don't refer to FOWARD/UNFORWARD, either refer to these attributes by
their full name or use a clear reference in proper English.

> +some inconsistency on who is going to complete the IRQ.

This sounds like the whole thing is fragile and if userspace doesn't do
things right, IRQ handling of a piece of hardware is going to be
inconsistent?  Is this the case?  If so, we need some stronger
semantics.  If not, this should be rephrased.

> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index cf3a2ff..8cd7b0e 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -947,6 +947,12 @@ struct kvm_device_attr {
>   __u64   addr;   /* userspace address of attr data */
>  };
>  
> +struct kvm_arch_forwarded_irq {
> + __u32 fd; /* file desciptor of the VFIO device */
> + __u32 index; /* VFIO device IRQ index */
> + __u32 gsi; /* gsi, ie. virtual IRQ number */
> +};
> +
>  #define KVM_DEV_TYPE_FSL_MPIC_20 1
>  #define KVM_DEV_TYPE_FSL_MPIC_42 2
>  #define KVM_DEV_TYPE_XICS3
> @@ -954,6 +960,9 @@ struct kvm_device_attr {
>  #define  KVM_DEV_VFIO_GROUP  1
>  #define   KVM_DEV_VFIO_GROUP_ADD 1
>  #define   KVM_DEV_VFIO_GROUP_DEL 2
> +#define  KVM_DEV_VFIO_DEVICE 2
> +#define   KVM_DEV_VFIO_DEVICE_FORWARD_IRQ1
> +#define   KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ  2
>  #define KVM_DEV_TYPE_ARM_VGIC_V2 5
>  #define KVM_DEV_TYPE_FLIC6
>  
> -- 
> 1.9.1
> 

Thanks,
-Christoffer
--
To unsubscribe from this list: send the line 

Re: [PATCH] KVM: EVENTFD: remove inclusion of irq.h

[Christoffer Dall]

On Mon, Sep 01, 2014 at 12:11:19PM +0200, Paolo Bonzini wrote:
> Il 01/09/2014 10:36, Eric Auger ha scritto:
> > No more needed. irq.h would be void on ARM.
> > 
> > Signed-off-by: Eric Auger 
> > 
> > ---
> > 
> > I don't think irq.h is needed anymore since Paul Mackerras' work. However
> > I did not compile for all architectures.
> > ---
> >  virt/kvm/eventfd.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> > index 3c5981c..0c712a7 100644
> > --- a/virt/kvm/eventfd.c
> > +++ b/virt/kvm/eventfd.c
> > @@ -36,7 +36,6 @@
> >  #include 
> >  #include 
> >  
> > -#include "irq.h"
> >  #include "iodev.h"
> >  
> >  #ifdef CONFIG_HAVE_KVM_IRQFD
> > 
> 
> Acked-by: Paolo Bonzini 
> 
> Christoffer, please include this via the ARM tree, together with ARM
> irqfd support.  Thanks,
> 
Marc is dealing with the tree this week and the next so he can apply it
to kvmarm/queue.  Do you want it to wait and go with the irqfd patch
(which has dependencies not yet resolved) or should we just queue it?

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

[PATCH v2 5/5] toshiba_acpi: Change touchpad store to check for invalid values

[Azael Avalos]

The function toshiba_touchpad_store is not checking
for invalid values and simply returns silently.

This patch checks for invalid values and returns accordingly.

Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index 08147c5..5a2324d 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1429,12 +1429,18 @@ static ssize_t toshiba_touchpad_store(struct device 
*dev,
 {
struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
int state;
+   int ret;
 
/* Set the TouchPad on/off, 0 - Disable | 1 - Enable */
-   if (sscanf(buf, "%i", ) == 1 && (state == 0 || state == 1)) {
-   if (toshiba_touchpad_set(toshiba, state) < 0)
-   return -EIO;
-   }
+   ret = kstrtoint(buf, 0, );
+   if (ret)
+   return ret;
+   if (state != 0 && state != 1)
+   return -EINVAL;
+
+   ret = toshiba_touchpad_set(toshiba, state);
+   if (ret)
+   return ret;
 
return count;
 }
-- 
2.0.0

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

[PATCH v2 4/5] toshiba_acpi: Support new keyboard backlight type

[Azael Avalos]

Newer Toshiba models now come with a new (and different) keyboard
backlight implementation with three modes of operation: TIMER,
ON and OFF, and the LED is controlled internally by the firmware.

This patch adds support for that type of backlight, changing the
existing code to accomodate the new implementation.

The timeout value range is now 1-60 seconds, and the accepted
modes are now: 1 (FN-Z), 2 (AUTO or TIMER), 8(ON) and 10 (OFF),
this adds two new entries keyboard_type and available_kbd_modes,
the first shows the keyboard type and the latter shows the
supported modes depending on the type.

Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 117 +++-
 1 file changed, 102 insertions(+), 15 deletions(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index 4c8fa7b..08147c5 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -140,6 +140,10 @@ MODULE_LICENSE("GPL");
 #define HCI_WIRELESS_BT_POWER  0x80
 #define SCI_KBD_MODE_FNZ   0x1
 #define SCI_KBD_MODE_AUTO  0x2
+#define SCI_KBD_MODE_ON0x8
+#define SCI_KBD_MODE_OFF   0x10
+#define SCI_KBD_MODE_MAX   SCI_KBD_MODE_OFF
+#define SCI_KBD_TIME_MAX   0x3c001a
 
 struct toshiba_acpi_dev {
struct acpi_device *acpi_dev;
@@ -155,6 +159,7 @@ struct toshiba_acpi_dev {
int force_fan;
int last_key_event;
int key_event_valid;
+   int kbd_type;
int kbd_mode;
int kbd_time;
 
@@ -495,6 +500,42 @@ static enum led_brightness toshiba_illumination_get(struct 
led_classdev *cdev)
 }
 
 /* KBD Illumination */
+static int toshiba_kbd_illum_available(struct toshiba_acpi_dev *dev)
+{
+   u32 in[HCI_WORDS] = { SCI_GET, SCI_KBD_ILLUM_STATUS, 0, 0, 0, 0 };
+   u32 out[HCI_WORDS];
+   acpi_status status;
+
+   if (!sci_open(dev))
+   return 0;
+
+   status = hci_raw(dev, in, out);
+   sci_close(dev);
+   if (ACPI_FAILURE(status) || out[0] == SCI_INPUT_DATA_ERROR) {
+   pr_err("ACPI call to query kbd illumination support failed\n");
+   return 0;
+   } else if (out[0] == HCI_NOT_SUPPORTED) {
+   pr_info("Keyboard illumination not available\n");
+   return 0;
+   }
+
+   /* Check for keyboard backlight timeout max value,
+   /* previous kbd backlight implementation set this to
+* 0x3c0003, and now the new implementation set this
+* to 0x3c001a, use this to distinguish between them
+*/
+   if (out[3] == SCI_KBD_TIME_MAX)
+   dev->kbd_type = 2;
+   else
+   dev->kbd_type = 1;
+   /* Get the current keyboard backlight mode */
+   dev->kbd_mode = out[2] & SCI_KBD_MODE_MASK;
+   /* Get the current time (1-60 seconds) */
+   dev->kbd_time = out[2] >> HCI_MISC_SHIFT;
+
+   return 1;
+}
+
 static int toshiba_kbd_illum_status_set(struct toshiba_acpi_dev *dev, u32 time)
 {
u32 result;
@@ -1268,20 +1309,46 @@ static ssize_t toshiba_kbd_bl_mode_store(struct device 
*dev,
ret = kstrtoint(buf, 0, );
if (ret)
return ret;
-   if (mode != SCI_KBD_MODE_FNZ && mode != SCI_KBD_MODE_AUTO)
+   if (mode != SCI_KBD_MODE_FNZ && mode != SCI_KBD_MODE_AUTO &&
+   mode != SCI_KBD_MODE_ON && mode != SCI_KBD_MODE_OFF)
return -EINVAL;
 
+   /* Check for supported modes depending on keyboard backlight type */
+   if (toshiba->kbd_type == 1) {
+   /* Type 1 supports SCI_KBD_MODE_FNZ and SCI_KBD_MODE_AUTO */
+   if (mode == SCI_KBD_MODE_ON || mode == SCI_KBD_MODE_OFF)
+   return -EINVAL;
+   } else if (toshiba->kbd_type == 2) {
+   /* Type 2 doesn't support SCI_KBD_MODE_FNZ */
+   if (mode == SCI_KBD_MODE_FNZ)
+   return -EINVAL;
+   }
+
/* Set the Keyboard Backlight Mode where:
-* Mode - Auto (2) | FN-Z (1)
 *  Auto - KBD backlight turns off automatically in given time
 *  FN-Z - KBD backlight "toggles" when hotkey pressed
+*  ON   - KBD backlight is always on
+*  OFF  - KBD backlight is always off
 */
+
+   /* Only make a change if the actual mode has changed */
if (toshiba->kbd_mode != mode) {
+   /* Shift the time to "base time" (0x3c == 60 seconds) */
time = toshiba->kbd_time << HCI_MISC_SHIFT;
-   time = time + toshiba->kbd_mode;
+
+   /* OR the "base time" to the actual method format */
+   if (toshiba->kbd_type == 1) {
+   /* Type 1 requires the current mode */
+   time |= toshiba->kbd_mode;
+   } else if (toshiba->kbd_type == 2) {
+   /* Type 2 requires the desired 

Re: mm: BUG in unmap_page_range

[Sasha Levin]

On 09/10/2014 03:36 PM, Hugh Dickins wrote:
>> migrate: debug patch to try identify race between migration completion and 
>> mprotect
>> > 
>> > A migration entry is marked as write if pte_write was true at the
>> > time the entry was created. The VMA protections are not double checked
>> > when migration entries are being removed but mprotect itself will mark
>> > write-migration-entries as read to avoid problems. It means we potentially
>> > take a spurious fault to mark these ptes write again but otherwise it's
>> > harmless.  Still, one dump indicates that this situation can actually
>> > happen so this debugging patch spits out a warning if the situation occurs
>> > and hopefully the resulting warning will contain a clue as to how exactly
>> > it happens
>> > 
>> > Not-signed-off
>> > ---
>> >  mm/migrate.c | 12 ++--
>> >  1 file changed, 10 insertions(+), 2 deletions(-)
>> > 
>> > diff --git a/mm/migrate.c b/mm/migrate.c
>> > index 09d489c..631725c 100644
>> > --- a/mm/migrate.c
>> > +++ b/mm/migrate.c
>> > @@ -146,8 +146,16 @@ static int remove_migration_pte(struct page *new, 
>> > struct vm_area_struct *vma,
>> >pte = pte_mkold(mk_pte(new, vma->vm_page_prot));
>> >if (pte_swp_soft_dirty(*ptep))
>> >pte = pte_mksoft_dirty(pte);
>> > -  if (is_write_migration_entry(entry))
>> > -  pte = pte_mkwrite(pte);
>> > +  if (is_write_migration_entry(entry)) {
>> > +  /*
>> > +   * This WARN_ON_ONCE is temporary for the purposes of seeing if
>> > +   * it's a case encountered by trinity in Sasha's testing
>> > +   */
>> > +  if (!(vma->vm_flags & (VM_WRITE)))
>> > +  WARN_ON_ONCE(1);
>> > +  else
>> > +  pte = pte_mkwrite(pte);
>> > +  }
>> >  #ifdef CONFIG_HUGETLB_PAGE
>> >if (PageHuge(new)) {
>> >pte = pte_mkhuge(pte);
>> > 
> Right, and Sasha  reports that that can fire, but he sees the bug
> with this patch in and without that firing.

I've changed that WARN_ON_ONCE() to a VM_BUG_ON_VMA() to get some useful VMA 
information
out, and got the following:

[ 4018.870776] vma 8801a0f1e800 start 7f3fd0ca7000 end 7f3fd16a7000
[ 4018.870776] next 8804e1b89800 prev 88008cd9a000 mm 88054b17d000
[ 4018.870776] prot 120 anon_vma 880bc858a200 vm_ops   (null)
[ 4018.870776] pgoff 41bc8 file   (null) private_data   (null)
[ 4018.879731] flags: 0x8100070(mayread|maywrite|mayexec|account)
[ 4018.881324] [ cut here ]
[ 4018.882612] kernel BUG at mm/migrate.c:155!
[ 4018.883649] invalid opcode:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 4018.889647] Dumping ftrace buffer:
[ 4018.890323](ftrace buffer empty)
[ 4018.890323] Modules linked in:
[ 4018.890323] CPU: 4 PID: 9966 Comm: trinity-main Tainted: GW  
3.17.0-rc4-next-20140910-sasha-00042-ga4bad9b-dirty #1140
[ 4018.890323] task: 880695b83000 ti: 880560c44000 task.ti: 
880560c44000
[ 4018.890323] RIP: 0010:[]  [] 
remove_migration_pte+0x3e1/0x3f0
[ 4018.890323] RSP: :880560c477c8  EFLAGS: 00010292
[ 4018.890323] RAX: 0001 RBX: 7f3fd129b000 RCX: 
[ 4018.890323] RDX: 0001 RSI: 9e4ba395 RDI: 0001
[ 4018.890323] RBP: 880560c47800 R08: 0001 R09: 0001
[ 4018.890323] R10: 00045401 R11: 0001 R12: 8801a0f1e800
[ 4018.890323] R13: 88054b17d000 R14: ea000478eb40 R15: 880122bcf070
[ 4018.890323] FS:  7f3fd55bb700() GS:8803d6a0() 
knlGS:
[ 4018.890323] CS:  0010 DS:  ES:  CR0: 8005003b
[ 4018.890323] CR2: 00fcbca8 CR3: 000561bab000 CR4: 06a0
[ 4018.890323] DR0: 006f DR1:  DR2: 
[ 4018.890323] DR3:  DR6: 0ff0 DR7: 0600
[ 4018.890323] Stack:
[ 4018.890323]  ea00046ed980 88011079c4d8 ea000478eb40 
880560c47858
[ 4018.890323]  88019fde0330 000421bc 8801a0f1e800 
880560c47848
[ 4018.890323]  9b2d1b0f 880bc858a200 880560c47850 
ea000478eb40
[ 4018.890323] Call Trace:
[ 4018.890323]  [] rmap_walk+0x22f/0x380
[ 4018.890323]  [] remove_migration_ptes+0x41/0x50
[ 4018.890323]  [] ? 
__migration_entry_wait.isra.24+0x160/0x160
[ 4018.890323]  [] ? remove_migration_pte+0x3f0/0x3f0
[ 4018.890323]  [] move_to_new_page+0x16b/0x230
[ 4018.890323]  [] ? try_to_unmap+0x6c/0xf0
[ 4018.890323]  [] ? try_to_unmap_nonlinear+0x5c0/0x5c0
[ 40

Re: [PATCH] mmc: Add delay between CMD6 and CMD13 for Sandisk eMMC cards

[Jaehoon Chung]

Hi,

On 09/09/2014 09:26 PM, Jean-Michel Hautbois wrote:
> Tested on a i.MX6 board, with Sandisk SDIN5D1-2G.
> Without this patch, I/O errors occur.
> This eMMC seems to have a different Manufacturer ID as it reads 0x45
> and not 0x2 as specified in datasheet.

I think this patch don't merge into mainline.
This is not solution for problem.
you mentioned the below comment, this is workaround.

> 
> Signed-off-by: Jean-Michel Hautbois 
> ---
>  drivers/mmc/core/mmc_ops.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index f51b5ba..91babaa 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -458,6 +458,15 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 
> index, u8 value,
>   if (!use_busy_signal)
>   return 0;
>  
> + /* WORKAROUND: for Sandisk eMMC cards, it might need certain delay
> +  * before sending CMD13 after CMD6
> +  * On SDIN5D1-2G MANFID is 0x45 and not 0x2 as specified in datasheet
> +  */
> + if (card->cid.manfid == CID_MANFID_SANDISK ||
> + card->cid.manfid == 0x45) {
> + msleep(1);
> + }

If it's a general problem of Sandisk SDIN5D1-2G,
I think you need to verify this problem. And can you use the MMC_FIXUP() and 
QUIRK?

Best Regards,
Jaehoon Chung

> +
>   /*
>* CRC errors shall only be ignored in cases were CMD13 is used to poll
>* to detect busy completion.
> 

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

Re: [PATCH v4 2/4] dt-bindings: document Rockchip thermal

[Zhang Rui]

On Wed, 2014-09-10 at 09:24 +0200, Heiko Stübner wrote:
> Am Dienstag, 9. September 2014, 21:14:18 schrieb edubez...@gmail.com:
> > Hello,
> > 
> > On Tue, Sep 9, 2014 at 9:02 PM, Zhang Rui  wrote:
> > > On Tue, 2014-09-09 at 11:09 -0400, Eduardo Valentin wrote:
> > >> Hello
> > >> 
> > >> On Tue, Sep 09, 2014 at 01:35:31PM +0200, Heiko Stübner wrote:
> > >> > Am Dienstag, 9. September 2014, 10:27:17 schrieb Zhang Rui:
> > >> > > On Thu, 2014-09-04 at 09:02 +0800, Caesar Wang wrote:
> > >> > > > 在 2014年09月03日 16:07, Heiko Stübner 写道:
> > >> > > > > Am Mittwoch, 3. September 2014, 10:10:37 schrieb Caesar Wang:
> > >> > > > >> This add the necessary binding documentation for the thermal
> > >> > > > >> found on Rockchip SoCs
> > >> > > > >> 
> > >> > > > >> Signed-off-by: zhaoyifeng 
> > >> > > > >> Signed-off-by: Caesar Wang 
> > >> > > > >> ---
> > >> > > > >> 
> > >> > > > >>   .../devicetree/bindings/thermal/rockchip-thermal.txt | 20
> > >> > > > >> 
> > >> > > > >>  1 file changed, 20 insertions(+)
> > >> > > > >> 
> > >> > > > >>   create mode 100644
> > >> > > > >> 
> > >> > > > >> Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> > >> > > > >> 
> > >> > > > >> diff --git
> > >> > > > >> a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> > >> > > > >> b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> > >> > > > >> new
> > >> > > > >> file
> > >> > > > >> mode 100644
> > >> > > > >> index 000..1ed4d4c
> > >> > > > >> --- /dev/null
> > >> > > > >> +++
> > >> > > > >> b/Documentation/devicetree/bindings/thermal/rockchip-thermal.tx
> > >> > > > >> t
> > >> > > > >> @@ -0,0 +1,20 @@
> > >> > > > >> +* Temperature Sensor ADC (TSADC) on rockchip SoCs
> > >> > > > >> +
> > >> > > > >> +Required properties:
> > >> > > > >> +- compatible: "rockchip,rk3288-tsadc"
> > >> > > > >> +- reg: physical base address of the controller and length of
> > >> > > > >> memory
> > >> > > > >> mapped
> > >> > > > >> +   region.
> > >> > > > >> +- interrupts: The interrupt number to the cpu. The interrupt
> > >> > > > >> specifier
> > >> > > > >> format +   depends on the interrupt controller.
> > >> > > > >> +- clocks: Must contain an entry for each entry in clock-names.
> > >> > > > >> +- clock-names: Shall be "tsadc" for the converter-clock, and
> > >> > > > >> "apb_pclk" for +the peripheral clock.
> > >> > > > > 
> > >> > > > > You're using the passive-temp, critical-temp and force-shut-temp
> > >> > > > > properties in your driver without declaring them here.
> > >> > > > 
> > >> > > > frankly,the about are need be declared. but  there are 4 types[0]
> > >> > > > for
> > >> > > > trip in thermal framework,
> > >> > > > there is no force-shut for me. So I want to change it three
> > >> > > > additional
> > >> > > > properties in [PATCH V4 4/4],
> > >> > > > 
> > >> > > > 
> > >> > > > [0]
> > >> > > > {
> > >> > > > 
> > >> > > >  THERMAL_TRIP_CRITICAL,
> > >> > > >  THERMAL_TRIP_HOT,
> > >> > > >  THERMAL_TRIP_PASSIVE,
> > >> > > >  THERMAL_TRIP_ACTIVE,
> > >> > > > 
> > >> > > > }
> > >> > > 
> > >> > > this sounds reasonable to me.
> > >> > > 
> > >> > > > > But more importantly, please use the generic trip-points for
> > >> > > > > this. I
> > >> > > > > guess it shouldn't be a problem to introduce a "forced-shutdown"
> > >> > > > > trippoint [0] for the additional trip-point you have - thermal
> > >> > > > > maintainers, please shout if I'm wrong :-)
> > >> > > 
> > >> > > what is the difference between a critical trip point and a
> > >> > > "forced-shutdown" trip point?
> > >> > > Thermal core will do a shutdown in case the critical trip point is
> > >> > > triggered.
> > >> > 
> > >> > The forced-shutdown is where the thermal controller is supposed to also
> > >> > do a>> 
> > >> Currently, there is no discrimination between hardware configured /
> > >> triggered thermal shutdown and software detected / triggered thermal
> > >> shutdown. One way to implement it though is to reuse the critical trip
> > >> type. Even if you use more than one trip type it is doable, it will
> > >> depend on the priorities you give to software triggered and hardware
> > >> triggered.
> > >> 
> > >> > shutdown in hardware. As you said the thermal core will also shutdown
> > >> > at the critical trip point, I guess we could map Caesar's value like
> > >> > 
> > >> > trip-point  tsadc
> > >> > criticalforced-shutdown (the 120 degrees in patch 4)
> > >> > 
> > >> > hot critical (the 100 degrees)
> > >> > ...
> > >> 
> > >> In the case we are planing to expand the trip type range, adding one
> > >> specific to hardware configurable shutdown makes sense to me too.
> > > 
> > > hmmm, why? you don't want an orderly shutdown? I still do not understand
> > > why we need a hardware shutdown trip point.
> > > Say, if we expect the system to be shutdown at 100C, I don't think we
> > > have a chance to 

RE: [PATCH] clocksource: Add BE/LE APIs support for clocksource counter reading.

[li.xi...@freescale.com]

> Cc: daniel.lezc...@linaro.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] clocksource: Add BE/LE APIs support for clocksource
> counter reading.
> 
> On Wed, 10 Sep 2014, Xiubo Li wrote:
> 
> So you add BE/LE APIs according to the subject line, but you fail
> again to tell WHY. If that would be the only issue 
> 
> > Signed-off-by: Xiubo Li 
> > ---
> >  drivers/clocksource/mmio.c | 44
> 
> >  1 file changed, 44 insertions(+)
> >
> > diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c
> > index 1593ade..ddc5214 100644
> > --- a/drivers/clocksource/mmio.c
> > +++ b/drivers/clocksource/mmio.c
> 
> So you think that adding this to mmio.c is the solution to the
> problem?
> 

It's just one solution of this, and will be a little faster than the old one
When reading the counter value.


> Ever heard about function prototypes, header files and such?
> 

Yes, this will be fixed later if this is acceptable.

> > @@ -20,21 +20,65 @@ static inline struct clocksource_mmio
> *to_mmio_clksrc(struct clocksource *c)
> > return container_of(c, struct clocksource_mmio, clksrc);
> >  }
> >
> > +cycle_t clocksource_mmio_readl_up_be(struct clocksource *c)
> > +{
> > +   return (cycle_t)be32_to_cpu(readl_relaxed(to_mmio_clksrc(c)->reg));
> > +}
> > +
> > +cycle_t clocksource_mmio_readl_up_le(struct clocksource *c)
> > +{
> > +   return (cycle_t)le32_to_cpu(readl_relaxed(to_mmio_clksrc(c)->reg));
> > +}
> > +
> >  cycle_t clocksource_mmio_readl_up(struct clocksource *c)
> >  {
> > return (cycle_t)readl_relaxed(to_mmio_clksrc(c)->reg);
> >  }
> 
> So now we have three global functions which provide access to the mmio
> clocksource. And one of them is always redundant for a given compile
> time endianess. You can't be serious about this...
> 
 
Yes, any good suggestion about this ?

I found whatever the method it is about the endianness will always be many
Different voices from different people and found it hard to taste all of them. 

So firstly I just using the driver's local APIs.

Thanks,

BRs
Xiubo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6] spi: spi-imx: add DMA support

[Robin Gong]

Enable DMA support on i.mx6. The read speed can increase from 600KB/s
to 1.2MB/s on i.mx6q. You can disable or enable dma function in dts.
If not set "dma-names" in dts, spi will use PIO mode. This patch only
validate on i.mx6, not i.mx5, but encourage ones to apply this patch
on i.mx5 since they share the same IP.

Note:
  Sometime, there is a weid data in rxfifo after one full tx/rx
transfer finish by DMA on i.mx6dl, so we disable dma functhion on
i.mx6dl.

Signed-off-by: Frank Li 
Signed-off-by: Robin Gong 

---
Change from v5:
1. Update binding doc fsl-imx-cspi.txt.
2. remove usedma flag set from can_dma interface.

Change from v4:
1. Enrich comments.
2. Remove the rxfifo workaround. The issue only exist on i.mx6dl, so disable
   dma function in dts.

Change from v3:
1. Use spi core framwork to handle dump tx/rx buf
2. Add one workaround for weird data in rxfifo when one full transfer done.

Change from v2:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/291722/focus=294363
1. Dma setup only for imx51-ecspi
2. Use one small dummy buffer(1 bd size) to templiy store data
   for meanless rx/tx, instead of malloc the actual transfer size.
3. Split spi_mx_sdma_transfer to smaller and easily to read.
4. Fix some code indent.
---
 .../devicetree/bindings/spi/fsl-imx-cspi.txt   |   5 +
 drivers/spi/spi-imx.c  | 286 -
 2 files changed, 285 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt 
b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
index 4256a6d..aad527b 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
@@ -7,6 +7,9 @@ Required properties:
 - interrupts : Should contain CSPI/eCSPI interrupt
 - fsl,spi-num-chipselects : Contains the number of the chipselect
 - cs-gpios : Specifies the gpio pins to be used for chipselects.
+- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
+   Documentation/devicetree/bindings/dma/dma.txt
+- dma-names: DMA request names should include "tx" and "rx" if present.
 
 Example:
 
@@ -19,4 +22,6 @@ ecspi@7001 {
fsl,spi-num-chipselects = <2>;
cs-gpios = < 24 0>, /* GPIO3_24 */
   < 25 0>; /* GPIO3_25 */
+   dmas = < 3 7 1>, < 4 7 2>;
+   dma-names = "rx", "tx";
 };
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 5daff20..3637847 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -37,6 +39,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #define DRIVER_NAME "spi_imx"
@@ -51,6 +54,9 @@
 #define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */
 #define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */
 
+/* The maximum  bytes that a sdma BD can transfer.*/
+#define MAX_SDMA_BD_BYTES  (1 << 15)
+#define IMX_DMA_TIMEOUT (msecs_to_jiffies(3000))
 struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
@@ -95,6 +101,16 @@ struct spi_imx_data {
const void *tx_buf;
unsigned int txfifo; /* number of words pushed in tx FIFO */
 
+   /* DMA */
+   unsigned int dma_is_inited;
+   unsigned int dma_finished;
+   bool usedma;
+   u32 rx_wml;
+   u32 tx_wml;
+   u32 rxt_wml;
+   struct completion dma_rx_completion;
+   struct completion dma_tx_completion;
+
const struct spi_imx_devtype_data *devtype_data;
int chipselect[0];
 };
@@ -181,9 +197,21 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
return 7;
 }
 
+static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
+struct spi_transfer *transfer)
+{
+   struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+
+   if (spi_imx->dma_is_inited && (transfer->len > spi_imx->rx_wml)
+   && (transfer->len > spi_imx->tx_wml))
+   return true;
+   return false;
+}
+
 #define MX51_ECSPI_CTRL0x08
 #define MX51_ECSPI_CTRL_ENABLE (1 <<  0)
 #define MX51_ECSPI_CTRL_XCH(1 <<  2)
+#define MX51_ECSPI_CTRL_SMC(1 << 3)
 #define MX51_ECSPI_CTRL_MODE_MASK  (0xf << 4)
 #define MX51_ECSPI_CTRL_POSTDIV_OFFSET 8
 #define MX51_ECSPI_CTRL_PREDIV_OFFSET  12
@@ -201,6 +229,18 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
 #define MX51_ECSPI_INT_TEEN(1 <<  0)
 #define MX51_ECSPI_INT_RREN(1 <<  3)
 
+#define MX51_ECSPI_DMA  0x14
+#define MX51_ECSPI_DMA_TX_WML_OFFSET   0
+#define MX51_ECSPI_DMA_TX_WML_MASK 0x3F
+#define MX51_ECSPI_DMA_RX_WML_OFFSET   16
+#define MX51_ECSPI_DMA_RX_WML_MASK (0x3F << 16)
+#define MX51_ECSPI_DMA_RXT_WML_OFFSET  24
+#define MX51_ECSPI_DMA_RXT_WML_MASK(0x3F << 24)
+
+#define MX51_ECSPI_DMA_TEDEN_OFFSET7
+#define 

[PATCH 1/2] dmaengine: Add QCOM ADM DMA driver

[Andy Gross]

Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA
controller found in the MSM8960 and IPQ/APQ8064 platforms.

The ADM supports both memory to memory transactions and memory
to/from peripheral device transactions.  The controller also provides flow
control capabilities for transactions to/from peripheral devices.

The initial release of this driver supports slave transfers to/from peripherals
and also incorporates CRCI (client rate control interface) flow control.

Signed-off-by: Andy Gross 
---
 drivers/dma/Kconfig|   10 +
 drivers/dma/Makefile   |1 +
 drivers/dma/qcom_adm.c |  872 
 3 files changed, 883 insertions(+)
 create mode 100644 drivers/dma/qcom_adm.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 9b1ea0e..88291ec 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -469,4 +469,14 @@ config QCOM_BAM_DMA
  Enable support for the QCOM BAM DMA controller.  This controller
  provides DMA capabilities for a variety of on-chip devices.
 
+config QCOM_ADM
+   tristate "Qualcomm ADM support"
+   depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   ---help---
+ Enable support for the Qualcomm ADM DMA controller.  This controller
+ provides DMA capabilities for both general purpose and on-chip
+ peripheral devices.
+
 endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index c6adb92..3bad47d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -50,3 +50,4 @@ obj-y += xilinx/
 obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
 obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
 obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
+obj-$(CONFIG_QCOM_ADM) += qcom_adm.o
diff --git a/drivers/dma/qcom_adm.c b/drivers/dma/qcom_adm.c
new file mode 100644
index 000..7680bfc
--- /dev/null
+++ b/drivers/dma/qcom_adm.c
@@ -0,0 +1,872 @@
+/*
+ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+/* ADM registers - calculated from channel number and security domain */
+#define HI_CH_CMD_PTR(chan, ee)(4*chan + 0x20800*ee)
+#define HI_CH_RSLT(chan, ee)   (0x40 + 4*chan + 0x20800*ee)
+#define HI_CH_FLUSH_STATE0(chan, ee)   (0x80 + 4*chan + 0x20800*ee)
+#define HI_CH_FLUSH_STATE1(chan, ee)   (0xc0 + 4*chan + 0x20800*ee)
+#define HI_CH_FLUSH_STATE2(chan, ee)   (0x100 + 4*chan + 0x20800*ee)
+#define HI_CH_FLUSH_STATE3(chan, ee)   (0x140 + 4*chan + 0x20800*ee)
+#define HI_CH_FLUSH_STATE4(chan, ee)   (0x180 + 4*chan + 0x20800*ee)
+#define HI_CH_FLUSH_STATE5(chan, ee)   (0x1c0 + 4*chan + 0x20800*ee)
+#define HI_CH_STATUS_SD(chan, ee)  (0x200 + 4*chan + 0x20800*ee)
+#define HI_CH_CONF(chan)   (0x240 + 4*chan)
+#define HI_CH_RSLT_CONF(chan, ee)  (0x300 + 4*chan + 0x20800*ee)
+#define HI_SEC_DOMAIN_IRQ_STATUS(ee)   (0x380 + 0x20800*ee)
+#define HI_CI_CONF(ci) (0x390 + 4*ci)
+#define HI_CRCI_CONF0  0x3d0
+#define HI_CRCI_CONF1  0x3d4
+#define HI_GP_CTL  0x3d8
+#define HI_CRCI_CTL(chan, ee)  (0x400 + 0x4*chan + 0x20800*ee)
+
+/* channel status */
+#define CH_STATUS_VALIDBIT(1)
+
+/* channel result */
+#define CH_RSLT_VALID  BIT(31)
+#define CH_RSLT_ERRBIT(3)
+#define CH_RSLT_FLUSH  BIT(2)
+#define CH_RSLT_TPDBIT(1)
+
+/* channel conf */
+#define CH_CONF_MPU_DISABLEBIT(11)
+#define CH_CONF_PERM_MPU_CONF  BIT(9)
+#define CH_CONF_FLUSH_RSLT_EN  BIT(8)
+#define CH_CONF_FORCE_RSLT_EN  BIT(7)
+#define CH_CONF_IRQ_EN BIT(6)
+
+/* channel result conf */
+#define CH_RSLT_CONF_FLUSH_EN  BIT(1)
+#define CH_RSLT_CONF_IRQ_ENBIT(0)
+
+/* CRCI CTL */
+#define CRCI_CTL_RST   BIT(17)
+
+/* CI configuration */
+#define CI_RANGE_END(x)(x << 24)
+#define CI_RANGE_START(x)  (x << 16)
+#define CI_BURST_4_WORDS   0x4
+#define CI_BURST_8_WORDS   0x8
+
+/* GP CTL */
+#define GP_CTL_LP_EN   BIT(12)
+#define GP_CTL_LP_CNT(x)   (x << 8)
+
+/* Command pointer list entry */
+#define CPLE_LPBIT(31)
+
+/* Command list entry */
+#define CMD_LC BIT(31)
+#define CMD_DST_CRCI(n)(((n) & 0xf) << 7)

Re: [PATCH] mmc: dw_mmc: add support for ARM64

[Jaehoon Chung]

On 09/09/2014 08:31 PM, Alim Akhtar wrote:
> Hi Ulf,
> 
> On Tue, Sep 9, 2014 at 12:21 PM, Ulf Hansson  wrote:
>> On 29 August 2014 12:24, Alim Akhtar  wrote:
>>> There are upcoming ARM64 SoCs with dw_mmc host controller.
>>>
>>> Signed-off-by: Alim Akhtar 
>>> ---
>>>  drivers/mmc/host/Kconfig |2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>>> index a43295c..72dd6c2 100644
>>> --- a/drivers/mmc/host/Kconfig
>>> +++ b/drivers/mmc/host/Kconfig
>>> @@ -580,7 +580,7 @@ config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND
>>>  config MMC_DW
>>> tristate "Synopsys DesignWare Memory Card Interface"
>>> depends on HAS_DMA
>>> -   depends on ARC || ARM || MIPS || COMPILE_TEST
>>> +   depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
>>
>> Before enabling this, wouldn't it be better to add the needed support
>> in dw_mmc first? Or there are no changes needed?
>>
>> There are also ongoing development and discussions for exynos7, which
>> I guess relates to this?
>> http://www.spinics.net/lists/linux-mmc/msg28294.html
> Thanks for looking into this.
> 
> Yes, this patch is being tested on exynos7 platform which is ongoing
> development.
> The above link is one of them.
> I feel this patch is too generic in nature and we now known at least
> exynos7 is going to use this.
> I don't know if there are any other ARM64 platform with dw_mmc controller.

If we need to prepare the ARM64, the above patch(linked patch) has to merge, 
why not?
But it needs to test for other SoCs and rework it.

Best Regards,
Jaehoon Chung

> 
> So, I am going to leave this upto you to decide when to take this
> patch, incase you decided to take it after exynos7 support lands, I
> will send a reminder for this.
>>
>> Kind regards
>> Uffe
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

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

[PATCH 2/2] dmaengine: qcom_adm: Add device tree binding

[Andy Gross]

Add device tree binding support for the QCOM ADM DMA driver.

Signed-off-by: Andy Gross 
---
 Documentation/devicetree/bindings/dma/qcom_adm.txt |   62 
 1 file changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_adm.txt

diff --git a/Documentation/devicetree/bindings/dma/qcom_adm.txt 
b/Documentation/devicetree/bindings/dma/qcom_adm.txt
new file mode 100644
index 000..9bcab91
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_adm.txt
@@ -0,0 +1,62 @@
+QCOM ADM DMA Controller
+
+Required properties:
+- compatible: must contain "qcom,adm" for IPQ/APQ8064 and MSM8960
+- reg: Address range for DMA registers
+- interrupts: Should contain one interrupt shared by all channels
+- #dma-cells: must be <2>.  First cell denotes the channel number.  Second cell
+  denotes CRCI (client rate control interface) flow control assignment.
+- clocks: Should contain the core clock and interface clock.
+- clock-names: Must contain "core" for the core clock and "iface" for the
+  interface clock.
+- resets: Must contain an entry for each entry in reset names.
+- reset-names: Must include the following entries:
+  - clk
+  - c0
+  - c1
+  - c2
+- qcom,ee: indicates the security domain identifier used in the secure world.
+
+Example:
+   adm_dma: dma@1830 {
+   compatible = "qcom,adm";
+   reg = <0x1830 0x10>;
+   interrupts = <0 170 0>;
+   #dma-cells = <2>;
+
+   clocks = < ADM0_CLK>, < ADM0_PBUS_CLK>;
+   clock-names = "core", "iface";
+
+   resets = < ADM0_RESET>,
+   < ADM0_C0_RESET>,
+   < ADM0_C1_RESET>,
+   < ADM0_C2_RESET>;
+   reset-names = "clk", "c0", "c1", "c2";
+   qcom,ee = <0>;
+   };
+
+DMA clients must use the format descripted in the dma.txt file, using a three
+cell specifier for each channel.
+
+Each dmas request consists of 3 cells:
+ 1. phandle pointing to the DMA controller
+ 2. channel number
+ 3. CRCI assignment, if applicable.  If no CRCI flow control is required, use 
0.
+The CRCI is used for flow control.  It identifies the peripheral device 
that
+is the source/destination for the transferred data.
+
+Example:
+
+   spi4: spi@1a28 {
+   status = "ok";
+   spi-max-frequency = <5000>;
+
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   cs-gpios = <_pinmux 20 0>;
+
+   dmas = <_dma 6 9>,
+   <_dma 5 10>;
+   dma-names = "rx", "tx";
+   };
-- 
The Qualcomm Innovation Center, Inc. is a member of the 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/

[RESEND PATCH 0/2] Add Qualcomm ADM dmaengine driver

[Andy Gross]

I am resending this patch set at the request of the maintainer.  The original
text is shown below.

This patch set introduces the dmaengine driver for the Qualcomm Application
Data Mover (ADM) DMA controller present on MSM8960, APQ8064, and IPQ8064
devices.

The initial version of this driver will only support slave DMA operations
between system memory and peripherals.  Flow control via the CRCI (client rate
control interface) is supported and can be configured via device tree
configuration.  Flow control usage is required for some peripheral devices.


Andy Gross (2):
  dmaengine: Add QCOM ADM DMA driver
  dmaengine: qcom_adm: Add device tree binding

 Documentation/devicetree/bindings/dma/qcom_adm.txt |   62 ++
 drivers/dma/Kconfig|   10 +
 drivers/dma/Makefile   |1 +
 drivers/dma/qcom_adm.c |  872 
 4 files changed, 945 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_adm.txt
 create mode 100644 drivers/dma/qcom_adm.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the 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/

linux-next: manual merge of the arm64 tree with the net tree

[Stephen Rothwell]

Hi Catalin,

Today's linux-next merge of the arm64 tree got a conflict in
Documentation/networking/filter.txt between commit 1d7efe9dfaa6
("Documentation: filter: Add MIPS to architectures with BPF JIT") from
the net tree and commit e54bcde3d69d ("arm64: eBPF JIT compiler") from
the arm64 tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc Documentation/networking/filter.txt
index d16f424c5e8d,1842d4f8ae13..
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@@ -462,9 -462,9 +462,9 @@@ JIT compile
  
  
  The Linux kernel has a built-in BPF JIT compiler for x86_64, SPARC, PowerPC,
- ARM, MIPS and s390 and can be enabled through CONFIG_BPF_JIT. The JIT compiler
 -ARM, ARM64 and s390 and can be enabled through CONFIG_BPF_JIT. The JIT 
compiler
--is transparently invoked for each attached filter from user space or for
--internal kernel users if it has been previously enabled by root:
++ARM, ARM64, MIPS and s390 and can be enabled through CONFIG_BPF_JIT. The JIT
++compiler is transparently invoked for each attached filter from user space or
++for internal kernel users if it has been previously enabled by root:
  
echo 1 > /proc/sys/net/core/bpf_jit_enable
  


signature.asc
Description: PGP signature

Re: [PATCH] fix mmc hang during boot on socfpga

[Jaehoon Chung]

Hi, Pavel.

On 09/10/2014 05:56 AM, Pavel Machek wrote:
> On Tue 2014-09-09 10:32:14, Olof Johansson wrote:
>> On Tue, Sep 9, 2014 at 5:19 AM, Pavel Machek  wrote:
>>>
>>> Without this patch, boot hangs when trying to mount root filesystem on
>>> socfpga platform in about 50% cases.
>>
>> I think this should have a better description than this -- this is too
>> vague. Did it use to always work, is this a new failure? You enable
>> some more error checking and improved stop handling, why was the
>> previous one inadequate on this platform?
> 
> I don't think it ever worked reliably. I don't know what is different
> for socfpga, or if it is broken on other platforms, too. I have two
> socfpga boards here, but no other dw_mmc board.

I didn't know what error is occurred at your board. But i guess it looks like 
HLE error, right?
Or you can share how booting is failed. than i think we can discuss more 
detailedly about your problem.


Best Regards,
Jaehoon Chung

> 
> Patch was separated from rocketboards.org repository.
> 
> Hope this helps,
> 
>   Pavel
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] checkpatch: look for common misspellings

[Joe Perches]

On Wed, 2014-09-10 at 15:52 -0700, Andrew Morton wrote:
> Have a kernel joke:
[]
> @@ -553,6 +553,7 @@ jeffies||jiffies
> +kubys|linus

Gimmu Smftre///


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] RTC: RK808: remove tm_def structure

[Chris Zhong]

Signed-off-by: Chris Zhong 

---

 drivers/rtc/rtc-rk808.c |   17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
index 22c8514..df42257 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk808.c
@@ -325,17 +325,6 @@ static int rk808_rtc_resume(struct device *dev)
 static SIMPLE_DEV_PM_OPS(rk808_rtc_pm_ops,
rk808_rtc_suspend, rk808_rtc_resume);
 
-/* 2014.1.1 12:00:00 Saturday */
-static struct rtc_time tm_def = {
-   .tm_wday = 6,
-   .tm_year = 114,
-   .tm_mon = 0,
-   .tm_mday = 1,
-   .tm_hour = 12,
-   .tm_min = 0,
-   .tm_sec = 0,
-};
-
 static int rk808_rtc_probe(struct platform_device *pdev)
 {
struct rk808 *rk808 = dev_get_drvdata(pdev->dev.parent);
@@ -376,10 +365,8 @@ static int rk808_rtc_probe(struct platform_device *pdev)
return ret;
}
ret = rtc_valid_tm();
-   if (ret) {
-   dev_warn(>dev, "invalid date/time and init time\n");
-   rk808_rtc_set_time(>dev, _def);
-   }
+   if (ret)
+   dev_warn(>dev, "invalid date/time\n");
 
device_init_wakeup(>dev, 1);
 
-- 
1.7.9.5

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

Re: [RFC] memory cgroup: my thoughts on memsw

[Kamezawa Hiroyuki]

(2014/09/09 19:39), Vladimir Davydov wrote:


For your purpose, you need to implement your method in system-wide way.
It seems crazy to set per-cgroup-anon-limit for avoding system-wide-oom.
You'll need help of system-wide-cgroup-configuration-middleware even if
you have a method in a cgroup. If you say logic should be in OS kernel,
please implement it in a system wide logic rather than cgroup.


What if on global pressure a memory cgroup exceeding its soft limit is
being reclaimed, but not fast enough, because it has a lot of anon
memory? The global OOM won't be triggered then, because there's still
progress, but the system will experience hard pressure due to the
reclaimer runs. How can we detect if we should kill the container or
not? It smells like one more heuristic to vmscan, IMO.



That's you are trying to implement by per-cgroup-anon+swap-limit, the difference
is heuristics by system designer at container creation or heuristics by kernel 
in
the dynamic way.

I said it should be done by system/cloud-container-scheduler based on 
notification.

But okay, let me think of kernel help in global reclaim.

 - Assume "priority" is a value calculated by "usage - soft limit".

 - weighted kswapd/direct reclaim
   => Based on priority of each threads/cgroup,  increase "wait" in direct 
reclaim
  if it's contended.
  Low prio container will sleep longer until memory contention is fixed.

 - weighted anon allocation
   similar to above, if memory is contended, page fault speed should be weighted
   based on priority(softlimit).

 - off cpu direct-reclaim
   run direct recalim in workqueue with cpu mask. the cpu mask is a global 
setting
   per numa node, which determines cpus available for being used to reclaim 
memory.
   "How to wait" may affect the performance of system but this can allow masked 
cpus
   to be used for more important jobs.

All of them will give a container-manager time to consinder next action.

Anyway, if swap is slow but necessary, you can use faster swap, now.
It's a good age.

Thanks,
-Kame


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

Re: [PATCH v2 1/2] ARM: dts: dra7: Add CPSW and MDIO module nodes for dra7

[Lennart Sorensen]

On Wed, Sep 10, 2014 at 07:07:26PM +0530, Mugunthan V N wrote:
> Add CPSW and MDIO related device tree data for DRA7XX and made as status
> disabled. Phy-id, pinmux for active and sleep state needs to be added in
> board dts files and enable the CPSW device.
> 
> Signed-off-by: Mugunthan V N 
> ---
>  arch/arm/boot/dts/dra7.dtsi | 59 
> +
>  1 file changed, 59 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index d678152..8d79321 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -34,6 +34,8 @@
>   serial3 = 
>   serial4 = 
>   serial5 = 
> + ethernet0 = _emac0;
> + ethernet1 = _emac1;
>   };
>  
>   timer {
> @@ -1262,6 +1264,63 @@
>   ti,irqs-skip = <10 133 139 140>;
>   ti,irqs-safe-map = <0>;
>   };
> +
> + mac: ethernet@4a10 {
> + compatible = "ti,cpsw";
> + ti,hwmods = "gmac";
> + cpdma_channels = <8>;
> + ale_entries = <1024>;
> + bd_ram_size = <0x2000>;
> + no_bd_ram = <0>;
> + rx_descs = <64>;
> + mac_control = <0x20>;
> + slaves = <2>;

How am I supposed to override this in the board dtb when my board only
uses 1 slave?

> + active_slave = <0>;
> + cpts_clock_mult = <0x8000>;
> + cpts_clock_shift = <29>;
> + reg = <0x48484000 0x1000
> +0x48485200 0x2E00>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + /*
> +  * rx_thresh_pend
> +  * rx_pend
> +  * tx_pend
> +  * misc_pend
> +  */
> + interrupts = ,
> +  ,
> +  ,
> +  ;
> + ranges;
> + status = "disabled";
> +
> + davinci_mdio: mdio@48485000 {
> + compatible = "ti,davinci_mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ti,hwmods = "davinci_mdio";
> + bus_freq = <100>;
> + reg = <0x48485000 0x100>;
> + };
> +
> + cpsw_emac0: slave@48480200 {
> + /* Filled in by U-Boot */
> + mac-address = [ 00 00 00 00 00 00 ];
> + };
> +
> + cpsw_emac1: slave@48480300 {
> + /* Filled in by U-Boot */
> + mac-address = [ 00 00 00 00 00 00 ];
> + };

Should I then be setting this to disabled from my board file?  Or does
the disabled for the ethernet overall take care of that?

> + phy_sel: cpsw-phy-sel@4a002554 {
> + compatible = "ti,dra7xx-cpsw-phy-sel";
> + reg= <0x4a002554 0x4>;
> + reg-names = "gmii-sel";
> + };

I guess the board file would have to disable that too (we won't have a
phy given we are connecting to a switch chip).

> + };
> +
>   };
>  };

-- 
Len Sorensen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] spi: spi-imx: add DMA support

[Robin Gong]

On Wed, Sep 10, 2014 at 04:52:16PM +0100, Mark Brown wrote:
> On Wed, Sep 10, 2014 at 11:18:01PM +0800, Robin Gong wrote:
> > On Wed, Sep 10, 2014 at 12:45:30PM +0100, Mark Brown wrote:
> 
> > > > Yes, you're right. I should use "transfer->tx_sg->sgl == NULL" or
> > > > "transfer->rx_sg->sgl == NULL" instead of usedma flag in driver, right?
> 
> > > Right.
> 
> > But looks spi core framework can make sure every rx or tx transfer in 
> > sequence.
> > If so, can_dma will never be called until this transfer finished
> > (spi_pump_messages), and my usedma flag also never be modified until next
> > transfer start. Please correct me if I am wrong, thanks.
> 
> Even if that were true currently this would still not be good code since
> it would break in the face of SPI core changes.  In any case the
> assumption isn't true for the current SPI core, the DMA mapping is done
> for all transfers in a message before we start running them and it's
> entirely likely that we will have patterns like a short PIO transfer
> followed by a big data block.
Understood, will improve it in v6.Thanks.

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

Re: [PATCH 3.2 00/94] 3.2.62-rc1 review

[Ben Hutchings]

On Mon, 2014-08-04 at 13:45 -0700, Guenter Roeck wrote:
> On Mon, Aug 04, 2014 at 08:49:39PM +0100, Ben Hutchings wrote:
> > On Mon, 2014-08-04 at 10:55 -0700, Guenter Roeck wrote:
> > > On Mon, Aug 04, 2014 at 05:48:31PM +0100, Ben Hutchings wrote:
> > > > This is the start of the stable review cycle for the 3.2.62 release.
> > > > There are 94 patches in this series, which will be posted as responses
> > > > to this one.  If anyone has any issues with these being applied, please
> > > > let me know.
> > > > 
> > > > Responses should be made by Wed Aug 06 17:00:00 UTC 2014.
> > > > Anything received after that time might be too late.
> > > > 
> > > Build results:
> > >   total: 111 pass: 105 fail: 6
> > > Failed builds:
> > >   microblaze:mmu_defconfig
> > >   microblaze:nommu_defconfig
> > >   mips:allmodconfig
> > >   sparc64:allmodconfig
> > >   xtensa:defconfig
> > >   xtensa:allmodconfig
> > > 
> > > Qemu tests all passed.
> > > 
> > > This is a significant improvement over the previous versions, where we 
> > > used
> > > to see up to 10 build failures. The previously failing builds for 
> > > unicore32
> > > and score now pass, as well as alpha:allmodconfig.
> > 
> > Yes, I spent a little while digging out build fixes.
> > 
> > I tried to fix the mips allmodconfig build, but failed - it needs
> > d3ce88431892, but that depends on 20082595d341, bef9ae3d883c, and
> > further changes I couldn't identify. 
> > 
> > I was unable to reproduce the sparc64 allmodconfig build failure, which
> > is in samples/hidraw - it built for me without warnings or errors.
> > Could you give me a bit more detail about the test setup?
> > 
> Nothing special, really - Ubuntu 14.4 (previously 13.10), with gcc 4.6.3
> from kernel.org.
> 
> This seems to be related to patch cbf1ef6 (sparc: use asm-generic version of
> types.h). After backporting it, the build passes for me. The backport is
> attached in case you want to give it a try.
[...]

OK, I've queued this up with a comment on how it differs from the
upstream version.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


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

Re: [RFC] memory cgroup: my thoughts on memsw

[Kamezawa Hiroyuki]

(2014/09/10 21:01), Vladimir Davydov wrote:

On Mon, Sep 08, 2014 at 10:53:48PM +0900, Kamezawa Hiroyuki wrote:

(2014/09/08 20:01), Vladimir Davydov wrote:

On Sat, Sep 06, 2014 at 08:15:44AM +0900, Kamezawa Hiroyuki wrote:

As you noticed, hitting anon+swap limit just means oom-kill.
My point is that using oom-killer for "server management" just seems crazy.

Let my clarify things. your proposal was.
  1. soft-limit will be a main feature for server management.
  2. Because of soft-limit, global memory reclaim runs.
  3. Using swap at global memory reclaim can cause poor performance.
  4. So, making use of OOM-Killer for avoiding swap.

I can't agree "4". I think

  - don't configure swap.


Suppose there are two containers, each having soft limit set to 50% of
total system RAM. One of the containers eats 90% of the system RAM by
allocating anonymous pages. Another starts using file caches and wants
more than 10% of RAM to work w/o issuing disk reads. So what should we
do then?
We won't be able to shrink the first container to its soft
limit, because there's no swap. Leaving it as is would be unfair from
the second container's point of view. Kill it? But the whole system is
going OK, because the working set of the second container is easily
shrinkable. Besides there may be some progress in shrinking file caches

>from the first container.



  - use zram


In fact this isn't different from the previous proposal (working w/o
swap). ZRAM only compresses data while still storing them in RAM so we
eventually may get into a situation where almost all RAM is full of
compressed anon pages.



In above 2 cases, "vmpressure" works fine.


What if a container allocates memory so fast that the userspace thread
handling its threshold notifications won't have time to react before it
eats all memory?



Softlimit is for avoiding such unfair memory scheduling, isn't it ?

Thanks,
-Kame





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

[Andrew Duggan]

From: Benjamin Tissoires 

In the Dell XPS 13 9333, it appears that sometimes the bus get confused
and corrupts the incoming data. It fills the input report with the
sentinel value "ff". Synaptics told us that such behavior does not comes
from the touchpad itself, so we filter out such reports here.

Unfortunately, we can not simply discard the incoming data because they
may contain useful information. Most of the time, the misbehavior is
quite near the end of the report, so we can still use the valid part of
it.

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1123584

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Andrew Duggan 
---
Here is a v2 based of Benjamin's patch with the feedback from the list.
I added size checks to rmi_f11_input_event and rmi_f30_input_event. For F30 I
print a message it any data is missing so that a user is notified if a button 
click
doesn't get reported. Also, I decided to only warn once if a corrupted report is
received. Based on the data I have seen I don't think dropped reports will be a
significanly noticible issue. But, I also added a debug message which could be 
turned on
if soneone wants to see exactly how often incomplete reports are being received.

 drivers/hid/hid-rmi.c | 44 ++--
 1 file changed, 38 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 578bbe6..54966ca 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -320,10 +320,7 @@ static int rmi_f11_input_event(struct hid_device *hdev, u8 
irq, u8 *data,
int offset;
int i;
 
-   if (size < hdata->f11.report_size)
-   return 0;
-
-   if (!(irq & hdata->f11.irq_mask))
+   if (!(irq & hdata->f11.irq_mask) || size <= 0)
return 0;
 
offset = (hdata->max_fingers >> 2) + 1;
@@ -332,9 +329,19 @@ static int rmi_f11_input_event(struct hid_device *hdev, u8 
irq, u8 *data,
int fs_bit_position = (i & 0x3) << 1;
int finger_state = (data[fs_byte_position] >> fs_bit_position) &
0x03;
+   int position = offset + 5 * i;
+
+   if (position + 5 > size) {
+   /* partial report, go on with what we received */
+   printk_once(KERN_WARNING
+   "%s %s: Detected incomplete finger report. 
Finger reports may occasionally get dropped on this platform.\n",
+dev_driver_string(>dev),
+dev_name(>dev));
+   hid_dbg(hdev, "Incomplete finger report\n");
+   break;
+   }
 
-   rmi_f11_process_touch(hdata, i, finger_state,
-   [offset + 5 * i]);
+   rmi_f11_process_touch(hdata, i, finger_state, [position]);
}
input_mt_sync_frame(hdata->input);
input_sync(hdata->input);
@@ -352,6 +359,11 @@ static int rmi_f30_input_event(struct hid_device *hdev, u8 
irq, u8 *data,
if (!(irq & hdata->f30.irq_mask))
return 0;
 
+   if (size < (int)hdata->f30.report_size) {
+   hid_warn(hdev, "Click Button pressed, but the click data is 
missing\n");
+   return 0;
+   }
+
for (i = 0; i < hdata->gpio_led_count; i++) {
if (test_bit(i, >button_mask)) {
value = (data[i / 8] >> (i & 0x07)) & BIT(0);
@@ -412,9 +424,29 @@ static int rmi_read_data_event(struct hid_device *hdev, u8 
*data, int size)
return 1;
 }
 
+static int rmi_check_sanity(struct hid_device *hdev, u8 *data, int size)
+{
+   int valid_size = size;
+   /*
+* On the Dell XPS 13 9333, the bus sometimes get confused and fills
+* the report with a sentinel value "ff". Synaptics told us that such
+* behavior does not comes from the touchpad itself, so we filter out
+* such reports here.
+*/
+
+   while ((data[valid_size - 1] == 0xff) && valid_size > 0)
+   valid_size--;
+
+   return valid_size;
+}
+
 static int rmi_raw_event(struct hid_device *hdev,
struct hid_report *report, u8 *data, int size)
 {
+   size = rmi_check_sanity(hdev, data, size);
+   if (size < 2)
+   return 0;
+
switch (data[0]) {
case RMI_READ_DATA_REPORT_ID:
return rmi_read_data_event(hdev, data, size);
-- 
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 08/12] Documentation: bindings: add doc for the USB2 ChipIdea USB driver

[Peter Chen]

On Wed, Sep 03, 2014 at 09:48:27AM +0200, Antoine Tenart wrote:
> Document the USB2 ChipIdea driver (ci13xxx) bindings.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  .../devicetree/bindings/usb/ci-hdrc-usb2.txt   | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
> b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> new file mode 100644
> index ..8dd6d8285dab
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> @@ -0,0 +1,22 @@
> +* USB2 ChipIdea USB controller for ci13xxx
> +
> +Required properties:
> +- compatible: should be "chipidea,usb2"
> +- reg: base address and length of the registers
> +- interrupts: interrupt for the USB controller
> +
> +Optional properties:
> +- clocks: reference to the USB clock
> +- phys: reference to the USB PHY
> +- vbus-supply: reference to the VBUS regulator
> +
> +Example:
> +
> + usb@f7ed {
> + compatible = "chipidea,usb2";
> + reg = <0xf7ed 0x1>;
> + interrupts = ;
> + clocks = < CLKID_USB0>;
> + phys = <_phy0>;
> + vbus-supply = <_usb0_vbus>;
> + };
> -- 
> 1.9.1
> 

This one is ok for me.

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

Re: [PATCH v4 9/9] usb: chipidea: add support to the generic PHY framework in ChipIdea

[Peter Chen]

On Wed, Sep 03, 2014 at 09:40:40AM +0200, Antoine Tenart wrote:
> This patch adds support of the PHY framework for ChipIdea drivers.
> Changes are done in both the ChipIdea common code and in the drivers
> accessing the PHY. This is done by adding a new PHY member in
> ChipIdea's structures and by taking care of it in the code.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/usb/chipidea/ci.h  |  5 ++-
>  drivers/usb/chipidea/core.c| 74 
> ++
>  drivers/usb/chipidea/debug.c   |  3 +-
>  drivers/usb/chipidea/host.c|  5 ++-
>  drivers/usb/chipidea/otg_fsm.c |  6 +++-
>  include/linux/usb/chipidea.h   |  2 ++
>  6 files changed, 78 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index dac5ab6adfa2..7e9e8223672a 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -161,7 +161,8 @@ struct hw_bank {
>   * @test_mode: the selected test mode
>   * @platdata: platform specific information supplied by parent device
>   * @vbus_active: is VBUS active
> - * @usb_phy: pointer to USB PHY, if any
> + * @phy: pointer to PHY, if any
> + * @usb_phy: pointer to USB PHY, if any and if using the USB PHY framework
>   * @hcd: pointer to usb_hcd for ehci host driver
>   * @debugfs: root dentry for this controller in debugfs
>   * @id_event: indicates there is an id event, and handled at ci_otg_work
> @@ -202,6 +203,8 @@ struct ci_hdrc {
>  
>   struct ci_hdrc_platform_data*platdata;
>   int vbus_active;
> + struct phy  *phy;
> + /* old usb_phy interface */
>   struct usb_phy  *usb_phy;
>   struct usb_hcd  *hcd;
>   struct dentry   *debugfs;
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index a8cd35fd8175..7c617b765bf2 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -293,6 +294,49 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
>  }
>  
>  /**
> + * _ci_usb_phy_init: initialize phy taking in account both phy and usb_phy
> + * interfaces
> + * @ci: the controller
> + *
> + * This function returns an error code if the phy failed to init
> + */
> +static int _ci_usb_phy_init(struct ci_hdrc *ci)
> +{
> + int ret;
> +
> + if (ci->phy) {
> + ret = phy_init(ci->phy);
> + if (ret)
> + return ret;
> +
> + ret = phy_power_on(ci->phy);
> + if (ret) {
> + phy_exit(ci->phy);
> + return ret;
> + }
> + } else {
> + ret = usb_phy_init(ci->usb_phy);
> + }
> +
> + return ret;
> +}
> +
> +/**
> + * _ci_usb_phy_exit: deinitialize phy taking in account both phy and usb_phy
> + * interfaces
> + * @ci: the controller
> + */
> +static void ci_usb_phy_exit(struct ci_hdrc *ci)
> +{
> + if (ci->phy) {
> + phy_power_off(ci->phy);
> + phy_exit(ci->phy);
> + } else {
> + usb_phy_shutdown(ci->usb_phy);
> + }
> +}
> +
> +/**
>   * ci_usb_phy_init: initialize phy according to different phy type
>   * @ci: the controller
>*
> @@ -306,7 +350,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
>   case USBPHY_INTERFACE_MODE_UTMI:
>   case USBPHY_INTERFACE_MODE_UTMIW:
>   case USBPHY_INTERFACE_MODE_HSIC:
> - ret = usb_phy_init(ci->usb_phy);
> + ret = _ci_usb_phy_init(ci);
>   if (ret)
>   return ret;
>   hw_phymode_configure(ci);
> @@ -314,12 +358,12 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
>   case USBPHY_INTERFACE_MODE_ULPI:
>   case USBPHY_INTERFACE_MODE_SERIAL:
>   hw_phymode_configure(ci);
> - ret = usb_phy_init(ci->usb_phy);
> + ret = _ci_usb_phy_init(ci);
>   if (ret)
>   return ret;
>   break;
>   default:
> - ret = usb_phy_init(ci->usb_phy);
> + ret = _ci_usb_phy_init(ci);
>   }
>  
>   return ret;
> @@ -595,23 +639,27 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>   return -ENODEV;
>   }
>  
> - if (ci->platdata->usb_phy)
> + if (ci->platdata->phy)
> + ci->phy = ci->platdata->phy;
> + else if (ci->platdata->usb_phy)
>   ci->usb_phy = ci->platdata->usb_phy;
>   else
> - ci->usb_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> + ci->phy = devm_phy_get(dev, "usb-phy");
>  
> - if (IS_ERR(ci->usb_phy)) {
> - ret = PTR_ERR(ci->usb_phy);
> + if (IS_ERR(ci->phy) || (ci->phy == NULL && ci->usb_phy == NULL)) {
>   /*
>* if -ENXIO is returned, it means PHY layer wasn't
>   

RE: [Bug] 3.16 fwdownload failure on Marvell 88SE9125 sata controller

[Patel, Gaurav]

Got it.
I just followed your step but it did not work. I will try something else to get 
3.16 install on redhat.

Thanks,
Gaurav Patel
Email: gspa...@hp.com
Cell # 832-382-5550


-Original Message-
From: Ming Lei [mailto:ming@canonical.com] 
Sent: Wednesday, September 10, 2014 8:00 PM
To: Patel, Gaurav
Cc: Robert Hancock; linux-...@vger.kernel.org; Tejun Heo; Linux Kernel Mailing 
List
Subject: Re: [Bug] 3.16 fwdownload failure on Marvell 88SE9125 sata controller

On Thu, Sep 11, 2014 at 8:45 AM, Patel, Gaurav  wrote:
> I will try to update kernel on Ubuntu to 2.6.32 and run the test.
>
> I was not able to install 3.16 ubuntu kernel on RrdHat.

I didn't ask you to install 3.16 ubuntu kernel on Redhat, and you just need to 
install upstream 3.16 kernel, :-)

>
> Thanks,
> Gaurav Patel
> Email: gspa...@hp.com
> Cell # 832-382-5550
>
> -Original Message-
> From: Ming Lei [mailto:ming@canonical.com]
> Sent: Wednesday, September 10, 2014 6:01 PM
> To: Patel, Gaurav
> Cc: Robert Hancock; linux-...@vger.kernel.org; Tejun Heo; Linux Kernel 
> Mailing List
> Subject: Re: [Bug] 3.16 fwdownload failure on Marvell 88SE9125 sata 
> controller
>
> On Thu, Sep 11, 2014 at 12:11 AM, Patel, Gaurav  wrote:
>>
>> ">> When we use hdparm to download firmware on system with Marvell
 88SE9125 SATA controller, it returns failure always and it has been 
 observed in several systems:"
>>
>>  [Gaurav]:  So I have another moonshot cartridge with same SATA controller 
>> and I was able to update FW with hdparm with RedHat65 without any issues. So 
>> this looks to me issue with Ubuntu kernel dos not have correct driver (or 
>> something is missing to support hdparm or sata controller).
>
> But RedHat65 ships a 2.6.32 kernel as you said, and you can test the 
> stable
> 2.6.32 kernel on one ubuntu release too.
>
> As far as I can tell, the problem is very probably related with kernel, that 
> is why I suggest you to test upstream kernel and run 'git bisect' later to 
> find the commit which caused the regression.
>
> But looks you have simply install problem.
>
> Thanks,
>
>
>>
>> Thanks,
>> Gaurav Patel
>> Email: gspa...@hp.com
>> Cell # 832-382-5550
>>
>>
>> -Original Message-
>> From: Ming Lei [mailto:ming@canonical.com]
>> Sent: Wednesday, September 10, 2014 1:34 AM
>> To: Robert Hancock
>> Cc: linux-...@vger.kernel.org; Tejun Heo; Linux Kernel Mailing List; 
>> Patel, Gaurav
>> Subject: Re: [Bug] 3.16 fwdownload failure on Marvell 88SE9125 sata 
>> controller
>>
>> On Wed, Sep 10, 2014 at 11:38 AM, Robert Hancock  
>> wrote:
>>> On 01/09/14 02:22 AM, Ming Lei wrote:

 Hi Guys,

 When we use hdparm to download firmware on system with Marvell
 88SE9125 SATA controller, it returns failure always and it has been 
 observed in several systems:

 #hdparm --fwdownload-mode7 fw.bin
 --yes-i-kno-what-i-am-doing --please-destroy-my-drive /dev/sda

 /dev/sda:
 fwdownload: xfer_mode=7 min=1 max=65535 size=699392
 FAILED: Input/output error
>>>
>>>
>>> Any errors in dmesg after doing this?
>>
>> No any failure log from kernel.
>>
>> Thanks,
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH v4 07/12] usb: chipidea: add a usb2 driver for ci13xxx

[Peter Chen]

On Wed, Sep 03, 2014 at 09:48:26AM +0200, Antoine Tenart wrote:
> Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock
> and DMA mask, to support USB2 ChipIdea controllers that don't need
> specific functions.
> 
> Tested on the Marvell Berlin SoCs USB controllers.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/usb/chipidea/Makefile   |   1 +
>  drivers/usb/chipidea/ci_hdrc_usb2.c | 137 
> 
>  2 files changed, 138 insertions(+)
>  create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c
> 
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 2f099c7df7b5..1fc86a2ca22d 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -10,6 +10,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM)   += otg_fsm.o
>  
>  # Glue/Bridge layers go here
>  
> +obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_usb2.o
>  obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_msm.o
>  obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_zevio.o
>  
> diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c 
> b/drivers/usb/chipidea/ci_hdrc_usb2.c
> new file mode 100644
> index ..75bdbfa362b9
> --- /dev/null
> +++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
> @@ -0,0 +1,137 @@
> +/*
> + * Copyright (C) 2014 Marvell Technology Group Ltd.
> + *
> + * Antoine Tenart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ci.h"
> +
> +struct ci_hdrc_usb2_priv {
> + struct platform_device  *ci_pdev;
> + struct clk  *clk;
> +};
> +
> +static int ci_hdrc_usb2_dt_probe(struct device *dev,
> +  struct ci_hdrc_platform_data *ci_pdata)
> +{
> + ci_pdata->phy = of_phy_get(dev->of_node, 0);
> + if (IS_ERR(ci_pdata->phy)) {
> + if (PTR_ERR(ci_pdata->phy) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + /* PHY is optional */
> + ci_pdata->phy = NULL;
> + }
> +
> + return 0;
> +}

You may also need to consider usb_phy case.

> +
> +static struct ci_hdrc_platform_data ci_default_pdata = {
> + .capoffset  = DEF_CAPOFFSET,
> + .flags  = CI_HDRC_REQUIRE_TRANSCEIVER |
> +   CI_HDRC_DISABLE_STREAMING,
> +};
> +
> +static int ci_hdrc_usb2_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct ci_hdrc_usb2_priv *priv;
> + struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(>dev);
> + int ret;
> +
> + if (!ci_pdata)
> + ci_pdata = _default_pdata;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->clk = devm_clk_get(dev, NULL);
> + if (!IS_ERR(priv->clk)) {
> + ret = clk_prepare_enable(priv->clk);
> + if (ret) {
> + dev_err(dev, "failed to enable the clock: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + if (dev->of_node) {
> + ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
> + if (ret)
> + return ret;
> + } else {
> + ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
> + }

You may need to do clk_disable_unprepare for above error cases.
> +
> + ci_pdata->name = dev_name(>dev);
> +
> + priv->ci_pdev = ci_hdrc_add_device(dev, pdev->resource,
> +pdev->num_resources, ci_pdata);
> + if (IS_ERR(priv->ci_pdev)) {
> + ret = PTR_ERR(priv->ci_pdev);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev,
> + "failed to register ci_hdrc platform device: 
> %d\n",
> + ret);

Why you don't want the error message for deferral probe?

> + goto clk_err;
> + }
> +
> + platform_set_drvdata(pdev, priv);
> +
> + pm_runtime_no_callbacks(dev);
> + pm_runtime_enable(dev);
> +
> + return 0;
> +
> +clk_err:
> + if (!IS_ERR(priv->clk))
> + clk_disable_unprepare(priv->clk);
> + return ret;
> +}
> +
> +static int ci_hdrc_usb2_remove(struct platform_device *pdev)
> +{
> + struct ci_hdrc_usb2_priv *priv = platform_get_drvdata(pdev);
> +
> + pm_runtime_disable(>dev);
> + ci_hdrc_remove_device(priv->ci_pdev);
> + clk_disable_unprepare(priv->clk);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ci_hdrc_usb2_of_match[] = {
> + { .compatible = "chipidea,usb2" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ci_hdrc_usb2_of_match);
> +
> +static struct platform_driver ci_hdrc_usb2_driver = {
> 

Re: [PATCH] intel_pstate: track and export frequency residency stats via sysfs.

[Sameer Nanda]

On Wed, Sep 10, 2014 at 5:04 PM, Rafael J. Wysocki  wrote:
> On Wednesday, September 10, 2014 04:39:05 PM Anup Chenthamarakshan wrote:
>> On Thu, Sep 11, 2014 at 12:49:48AM +0200, Rafael J. Wysocki wrote:
>> > On Wednesday, September 10, 2014 03:15:08 PM Anup Chenthamarakshan wrote:
>> > >
>> > > Tools like powertop and turbostat are not present by default on all 
>> > > systems,
>> > > so it is not always possible to use them :(
>> >
>> > Which systems are you referring to in particular?
>>
>> We're testing on Chrome OS devices (Chromebooks).
>
> How big of a deal is it to install the tools mentioned above on such a system?
>
> At least turbostat is shipped with the kernel source.

Given the web browser based front end of Chrome OS, installing these
tools will only get us so far -- if the system is in developer mode,
the tools are accessible but when the system is in normal (verified
boot mode) these tools cannot be launched directly.

We are in the process of switching Chrome OS x86 kernels from ondemand
governor to intel_pstate.  When debugging power consumption issues,
losing the ability to easily get CPU frequency related information as
a side-effect of this switch is less than ideal.

We are happy to spin this patch to expose aperf/mperf based CPU
frequency information if you think that is the better route to take
longer term.

>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.



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

Rusty away 18th September -- 11th October

[Rusty Russell]

Hi all,

Probably won't read mail.  Linus, I'll have pull requests early
next week; if there's anything needed I'm sure Michael Tsirkin can
handle it.

Cheers,
Rusty.
PS.  England and Italy for a holiday; my daughter chose them (somehow I
 forgot to inform her of the existence of Euro Disney...)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/9] usb: chipidea: move usb_otg into struct ci_hdrc

[Peter Chen]

On Wed, Sep 03, 2014 at 09:40:39AM +0200, Antoine Tenart wrote:
> Move the usb_otg member from struct usb_phy to struct ci_hdrc. Rework
> its initialization taking in account this modification.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/usb/chipidea/ci.h  |  1 +
>  drivers/usb/chipidea/host.c|  5 +++--
>  drivers/usb/chipidea/otg_fsm.c | 16 +++-
>  3 files changed, 7 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index b2caa1772712..dac5ab6adfa2 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -177,6 +177,7 @@ struct ci_hdrc {
>   struct ci_role_driver   *roles[CI_ROLE_END];
>   enum ci_rolerole;
>   boolis_otg;
> + struct usb_otg  otg;
>   struct otg_fsm  fsm;
>   struct ci_otg_fsm_timer_list*fsm_timer;
>   struct work_struct  work;
> diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> index 0b67d78dd953..4fcebb6a6d14 100644
> --- a/drivers/usb/chipidea/host.c
> +++ b/drivers/usb/chipidea/host.c
> @@ -85,10 +85,11 @@ static int host_start(struct ci_hdrc *ci)
>   if (ret) {
>   goto disable_reg;
>   } else {
> - struct usb_otg *otg = ci->usb_phy->otg;
> + struct usb_otg *otg = >otg;
>  
>   ci->hcd = hcd;
> - if (otg) {
> +
> + if (ci_otg_is_fsm_mode(ci)) {
>   otg->host = >self;
>   hcd->self.otg_port = 1;
>   }
> diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
> index 8a64ce87364e..862d7cb01b92 100644
> --- a/drivers/usb/chipidea/otg_fsm.c
> +++ b/drivers/usb/chipidea/otg_fsm.c
> @@ -778,20 +778,10 @@ void ci_hdrc_otg_fsm_start(struct ci_hdrc *ci)
>  int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
>  {
>   int retval = 0;
> - struct usb_otg *otg;
>  
> - otg = devm_kzalloc(ci->dev,
> - sizeof(struct usb_otg), GFP_KERNEL);
> - if (!otg) {
> - dev_err(ci->dev,
> - "Failed to allocate usb_otg structure for ci hdrc otg!\n");
> - return -ENOMEM;
> - }
> -
> - otg->usb_phy = ci->usb_phy;
> - otg->gadget = >gadget;
> - ci->fsm.otg = otg;
> - ci->usb_phy->otg = ci->fsm.otg;
> + ci->otg.usb_phy = ci->usb_phy;
> + ci->otg.gadget = >gadget;
> + ci->fsm.otg = >otg;
>   ci->fsm.power_up = 1;
>   ci->fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
>   ci->fsm.otg->state = OTG_STATE_UNDEFINED;
> -- 

Acked-by: Peter Chen 

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

Re: [Bug] 3.16 fwdownload failure on Marvell 88SE9125 sata controller

[Ming Lei]

On Thu, Sep 11, 2014 at 8:45 AM, Patel, Gaurav  wrote:
> I will try to update kernel on Ubuntu to 2.6.32 and run the test.
>
> I was not able to install 3.16 ubuntu kernel on RrdHat.

I didn't ask you to install 3.16 ubuntu kernel on Redhat, and you just
need to install upstream 3.16 kernel, :-)

>
> Thanks,
> Gaurav Patel
> Email: gspa...@hp.com
> Cell # 832-382-5550
>
> -Original Message-
> From: Ming Lei [mailto:ming@canonical.com]
> Sent: Wednesday, September 10, 2014 6:01 PM
> To: Patel, Gaurav
> Cc: Robert Hancock; linux-...@vger.kernel.org; Tejun Heo; Linux Kernel 
> Mailing List
> Subject: Re: [Bug] 3.16 fwdownload failure on Marvell 88SE9125 sata controller
>
> On Thu, Sep 11, 2014 at 12:11 AM, Patel, Gaurav  wrote:
>>
>> ">> When we use hdparm to download firmware on system with Marvell
 88SE9125 SATA controller, it returns failure always and it has been
 observed in several systems:"
>>
>>  [Gaurav]:  So I have another moonshot cartridge with same SATA controller 
>> and I was able to update FW with hdparm with RedHat65 without any issues. So 
>> this looks to me issue with Ubuntu kernel dos not have correct driver (or 
>> something is missing to support hdparm or sata controller).
>
> But RedHat65 ships a 2.6.32 kernel as you said, and you can test the stable
> 2.6.32 kernel on one ubuntu release too.
>
> As far as I can tell, the problem is very probably related with kernel, that 
> is why I suggest you to test upstream kernel and run 'git bisect' later to 
> find the commit which caused the regression.
>
> But looks you have simply install problem.
>
> Thanks,
>
>
>>
>> Thanks,
>> Gaurav Patel
>> Email: gspa...@hp.com
>> Cell # 832-382-5550
>>
>>
>> -Original Message-
>> From: Ming Lei [mailto:ming@canonical.com]
>> Sent: Wednesday, September 10, 2014 1:34 AM
>> To: Robert Hancock
>> Cc: linux-...@vger.kernel.org; Tejun Heo; Linux Kernel Mailing List;
>> Patel, Gaurav
>> Subject: Re: [Bug] 3.16 fwdownload failure on Marvell 88SE9125 sata
>> controller
>>
>> On Wed, Sep 10, 2014 at 11:38 AM, Robert Hancock  
>> wrote:
>>> On 01/09/14 02:22 AM, Ming Lei wrote:

 Hi Guys,

 When we use hdparm to download firmware on system with Marvell
 88SE9125 SATA controller, it returns failure always and it has been
 observed in several systems:

 #hdparm --fwdownload-mode7 fw.bin
 --yes-i-kno-what-i-am-doing --please-destroy-my-drive /dev/sda

 /dev/sda:
 fwdownload: xfer_mode=7 min=1 max=65535 size=699392
 FAILED: Input/output error
>>>
>>>
>>> Any errors in dmesg after doing this?
>>
>> No any failure log from kernel.
>>
>> Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] virtio_ring: assume sgs are always well-formed.

[Rusty Russell]

We used to have several callers which just used arrays.  They're
gone, so we can use sg_next() everywhere, simplifying the code.

On my laptop, this slowed down vring_bench by 15%:

vring_bench before:
936153354-967745359(9.44739e+08+/-6.1e+06)ns
vring_bench after:
1061485790-1104800648(1.08254e+09+/-6.6e+06)ns

However, a more realistic test using pktgen on a AMD FX(tm)-8320 saw
a few percent improvement:

pktgen before:
  767390-792966(785159+/-6.5e+03)pps 356-367(363.75+/-2.9)Mb/sec 
(356068960-367936224(3.64314e+08+/-3e+06)bps) errors: 0

pktgen after:
   787781-796334(793165+/-2.4e+03)pps 365-369(367.5+/-1.2)Mb/sec 
(365530384-369498976(3.68028e+08+/-1.1e+06)bps) errors: 0

Signed-off-by: Rusty Russell 
---
 drivers/virtio/virtio_ring.c | 68 +---
 1 file changed, 19 insertions(+), 49 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 4d08f45a9c29..374399c62080 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -99,28 +99,10 @@ struct vring_virtqueue
 
 #define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
 
-static inline struct scatterlist *sg_next_chained(struct scatterlist *sg,
- unsigned int *count)
-{
-   return sg_next(sg);
-}
-
-static inline struct scatterlist *sg_next_arr(struct scatterlist *sg,
- unsigned int *count)
-{
-   if (--(*count) == 0)
-   return NULL;
-   return sg + 1;
-}
-
 /* Set up an indirect table of descriptors and add it to the queue. */
 static inline int vring_add_indirect(struct vring_virtqueue *vq,
 struct scatterlist *sgs[],
-struct scatterlist *(*next)
-  (struct scatterlist *, unsigned int *),
 unsigned int total_sg,
-unsigned int total_out,
-unsigned int total_in,
 unsigned int out_sgs,
 unsigned int in_sgs,
 gfp_t gfp)
@@ -144,7 +126,7 @@ static inline int vring_add_indirect(struct vring_virtqueue 
*vq,
/* Transfer entries from the sg lists into the indirect page */
i = 0;
for (n = 0; n < out_sgs; n++) {
-   for (sg = sgs[n]; sg; sg = next(sg, _out)) {
+   for (sg = sgs[n]; sg; sg = sg_next(sg)) {
desc[i].flags = VRING_DESC_F_NEXT;
desc[i].addr = sg_phys(sg);
desc[i].len = sg->length;
@@ -153,7 +135,7 @@ static inline int vring_add_indirect(struct vring_virtqueue 
*vq,
}
}
for (; n < (out_sgs + in_sgs); n++) {
-   for (sg = sgs[n]; sg; sg = next(sg, _in)) {
+   for (sg = sgs[n]; sg; sg = sg_next(sg)) {
desc[i].flags = VRING_DESC_F_NEXT|VRING_DESC_F_WRITE;
desc[i].addr = sg_phys(sg);
desc[i].len = sg->length;
@@ -186,10 +168,7 @@ static inline int vring_add_indirect(struct 
vring_virtqueue *vq,
 
 static inline int virtqueue_add(struct virtqueue *_vq,
struct scatterlist *sgs[],
-   struct scatterlist *(*next)
- (struct scatterlist *, unsigned int *),
-   unsigned int total_out,
-   unsigned int total_in,
+   unsigned int total_sg,
unsigned int out_sgs,
unsigned int in_sgs,
void *data,
@@ -197,7 +176,7 @@ static inline int virtqueue_add(struct virtqueue *_vq,
 {
struct vring_virtqueue *vq = to_vvq(_vq);
struct scatterlist *sg;
-   unsigned int i, n, avail, uninitialized_var(prev), total_sg;
+   unsigned int i, n, avail, uninitialized_var(prev);
int head;
 
START_USE(vq);
@@ -222,13 +201,10 @@ static inline int virtqueue_add(struct virtqueue *_vq,
}
 #endif
 
-   total_sg = total_in + total_out;
-
/* If the host supports indirect descriptor tables, and we have multiple
 * buffers, then go indirect. FIXME: tune this threshold */
if (vq->indirect && total_sg > 1 && vq->vq.num_free) {
-   head = vring_add_indirect(vq, sgs, next, total_sg, total_out,
- total_in,
+   head = vring_add_indirect(vq, sgs, total_sg, 
  out_sgs, in_sgs, gfp);
if (likely(head >= 0))
goto add_head;
@@ -254,7 +230,7 @@ static inline int virtqueue_add(struct virtqueue *_vq,
 
head = i = 

[PATCH 0/3] virtio_net/virtio_ring.

[Rusty Russell]

Mainly for DaveM and MST to ack the first one, so I can apply the
second two.  Initializing the entire sg table is naive, but with cache
effects it only seems to help, so I didn't get fancy.

Cheers,
Rusty.

Rusty Russell (3):
  virtio_net: pass well-formed sgs to virtqueue_add_*()
  virtio_ring: assume sgs are always well-formed.
  virtio_ring: unify direct/indirect code paths.

 drivers/net/virtio_net.c |   5 +-
 drivers/virtio/virtio_ring.c | 192 ---
 2 files changed, 73 insertions(+), 124 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/

[RFC PATCH v8] tpm_tis: verify interrupt during init

[Scot Doyle]

On Mon, 8 Sep 2014, Jason Gunthorpe wrote:
> On Tue, Sep 02, 2014 at 08:22:58PM +, Scot Doyle wrote:
>
>> It's spending that time (now 3 seconds) in tpm_tis_send_data.
>
> Due to request_locality?

The first command transmitted (TPM_CAP_PROP) in tpm_get_timeouts goes 
through tpm_tis_send which calls tpm_tis_send_data before setting up 
polling mode for the interrupt test. In tpm_tis_send_data, the last call 
to wait_for_tpm_stat is still timing out.

One solution would be to move the test from tpm_tis_send to 
tpm_tis_send_data. Another would be to expand the test in tpm_tis_send to 
include the call to tpm_tis_send_data.

The latter seems safer, since it provides more opportunity for an IRQ to 
be generated. E.g. I'm not sure if TPM_CAP_PROP always generates an IRQ. 
But the problem with this approach is that tpm_tis_send becomes a bit 
messy. So this patch wraps tpm_tis_send in an attempt to keep the code 
clean. (Is there a better name for the wrapped function than 
tpm_tis_send_main?)

Thoughts?

With this patch, the output becomes:
[4.264619] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
[4.311628] tpm_tis 00:08: [Firmware Bug]: TPM interrupt not working, 
polling instead

P.S. My apologies for revisiting this issue after it seemed to be 
finalized.

---
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 2c46734..2dbd652 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -75,6 +75,10 @@ enum tis_defaults {
 #defineTPM_DID_VID(l)  (0x0F00 | ((l) << 12))
 #defineTPM_RID(l)  (0x0F04 | ((l) << 12))

+struct priv_data {
+   bool irq_tested;
+};
+
 static LIST_HEAD(tis_chips);
 static DEFINE_MUTEX(tis_lock);

@@ -338,12 +342,27 @@ out_err:
return rc;
 }

+static void disable_interrupts(struct tpm_chip *chip)
+{
+   u32 intmask;
+   intmask =
+   ioread32(chip->vendor.iobase +
+TPM_INT_ENABLE(chip->vendor.locality));
+   intmask |= TPM_INTF_CMD_READY_INT | TPM_INTF_LOCALITY_CHANGE_INT |
+  TPM_INTF_DATA_AVAIL_INT | TPM_INTF_STS_VALID_INT;
+   iowrite32(intmask,
+ chip->vendor.iobase +
+ TPM_INT_ENABLE(chip->vendor.locality));
+   free_irq(chip->vendor.irq, chip);
+   chip->vendor.irq = 0;
+}
+
 /*
  * If interrupts are used (signaled by an irq set in the vendor structure)
  * tpm.c can skip polling for the data to be available as the interrupt is
  * waited for here
  */
-static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, size_t len)
+static int tpm_tis_send_main(struct tpm_chip *chip, u8 *buf, size_t len)
 {
int rc;
u32 ordinal;
@@ -373,6 +392,28 @@ out_err:
return rc;
 }

+static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, size_t len)
+{
+   int rc, irq;
+   struct priv_data *priv = chip->vendor.priv;
+
+   if (!chip->vendor.irq || priv->irq_tested)
+   return tpm_tis_send_main(chip, buf, len);
+
+   /* Verify receipt of the expected IRQ */
+   irq = chip->vendor.irq;
+   chip->vendor.irq = 0;
+   rc = tpm_tis_send_main(chip, buf, len);
+   chip->vendor.irq = irq;
+   if (!priv->irq_tested) {
+   disable_interrupts(chip);
+   dev_err(chip->dev,
+   FW_BUG "TPM interrupt not working, polling instead\n");
+   }
+   priv->irq_tested = true;
+   return rc;
+}
+
 struct tis_vendor_timeout_override {
u32 did_vid;
unsigned long timeout_us[4];
@@ -505,6 +546,7 @@ static irqreturn_t tis_int_handler(int dummy, void *dev_id)
if (interrupt == 0)
return IRQ_NONE;

+   ((struct priv_data*)chip->vendor.priv)->irq_tested = true;
if (interrupt & TPM_INTF_DATA_AVAIL_INT)
wake_up_interruptible(>vendor.read_queue);
if (interrupt & TPM_INTF_LOCALITY_CHANGE_INT)
@@ -534,10 +576,14 @@ static int tpm_tis_init(struct device *dev, 
resource_size_t start,
u32 vendor, intfcaps, intmask;
int rc, i, irq_s, irq_e, probe;
struct tpm_chip *chip;
+   struct priv_data *priv;

if (!(chip = tpm_register_hardware(dev, _tis)))
return -ENODEV;

+   priv = devm_kzalloc(dev, sizeof(struct priv_data), GFP_KERNEL);
+   chip->vendor.priv = priv;
+
chip->vendor.iobase = ioremap(start, len);
if (!chip->vendor.iobase) {
rc = -EIO;
@@ -605,19 +651,6 @@ static int tpm_tis_init(struct device *dev, 
resource_size_t start,
if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
dev_dbg(dev, "\tData Avail Int Support\n");

-   /* get the timeouts before testing for irqs */
-   if (tpm_get_timeouts(chip)) {
-   dev_err(dev, "Could not get TPM timeouts and durations\n");
-   rc = -ENODEV;
-   goto out_err;
-   }
-
-   if (tpm_do_selftest(chip)) {
-   dev_err(dev, 

[PATCH 3/3] virtio_ring: unify direct/indirect code paths.

[Rusty Russell]

virtqueue_add() populates the virtqueue descriptor table from the sgs
given.  If it uses an indirect descriptor table, then it puts a single
descriptor in the descriptor table pointing to the kmalloc'ed indirect
table where the sg is populated.

Previously vring_add_indirect() did the allocation and the simple
linear layout.  We replace that with alloc_indirect() which allocates
the indirect table then chains it like the normal descriptor table so
we can reuse the core logic.

This slows down pktgen by less than 1/2 a percent (which uses direct
descriptors), as well as vring_bench, but it's far neater.

vring_bench before:
1061485790-1104800648(1.08254e+09+/-6.6e+06)ns
vring_bench after:
1125610268-1183528965(1.14172e+09+/-8e+06)ns

pktgen before:
   787781-796334(793165+/-2.4e+03)pps 365-369(367.5+/-1.2)Mb/sec 
(365530384-369498976(3.68028e+08+/-1.1e+06)bps) errors: 0

pktgen after:
   779988-790404(786391+/-2.5e+03)pps 361-366(364.35+/-1.3)Mb/sec 
(361914432-366747456(3.64885e+08+/-1.2e+06)bps) errors: 0

Now, if we make force indirect descriptors by turning off any_header_sg
in virtio_net.c:

pktgen before:
  713773-721062(718374+/-2.1e+03)pps 331-334(332.95+/-0.92)Mb/sec 
(331190672-334572768(3.33325e+08+/-9.6e+05)bps) errors: 0
pktgen after:
  710542-719195(714898+/-2.4e+03)pps 329-333(331.15+/-1.1)Mb/sec 
(329691488-333706480(3.31713e+08+/-1.1e+06)bps) errors: 0

Signed-off-by: Rusty Russell 
---
 drivers/virtio/virtio_ring.c | 134 ++-
 1 file changed, 55 insertions(+), 79 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 374399c62080..6d2b5310c991 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -99,18 +99,10 @@ struct vring_virtqueue
 
 #define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
 
-/* Set up an indirect table of descriptors and add it to the queue. */
-static inline int vring_add_indirect(struct vring_virtqueue *vq,
-struct scatterlist *sgs[],
-unsigned int total_sg,
-unsigned int out_sgs,
-unsigned int in_sgs,
-gfp_t gfp)
+static struct vring_desc *alloc_indirect(unsigned int total_sg, gfp_t gfp)
 {
-   struct vring_desc *desc;
-   unsigned head;
-   struct scatterlist *sg;
-   int i, n;
+   struct vring_desc *desc;
+   unsigned int i;
 
/*
 * We require lowmem mappings for the descriptors because
@@ -119,51 +111,13 @@ static inline int vring_add_indirect(struct 
vring_virtqueue *vq,
 */
gfp &= ~(__GFP_HIGHMEM | __GFP_HIGH);
 
-   desc = kmalloc(total_sg * sizeof(struct vring_desc), gfp);
-   if (!desc)
-   return -ENOMEM;
-
-   /* Transfer entries from the sg lists into the indirect page */
-   i = 0;
-   for (n = 0; n < out_sgs; n++) {
-   for (sg = sgs[n]; sg; sg = sg_next(sg)) {
-   desc[i].flags = VRING_DESC_F_NEXT;
-   desc[i].addr = sg_phys(sg);
-   desc[i].len = sg->length;
-   desc[i].next = i+1;
-   i++;
-   }
-   }
-   for (; n < (out_sgs + in_sgs); n++) {
-   for (sg = sgs[n]; sg; sg = sg_next(sg)) {
-   desc[i].flags = VRING_DESC_F_NEXT|VRING_DESC_F_WRITE;
-   desc[i].addr = sg_phys(sg);
-   desc[i].len = sg->length;
-   desc[i].next = i+1;
-   i++;
-   }
-   }
-   BUG_ON(i != total_sg);
-
-   /* Last one doesn't continue. */
-   desc[i-1].flags &= ~VRING_DESC_F_NEXT;
-   desc[i-1].next = 0;
-
-   /* We're about to use a buffer */
-   vq->vq.num_free--;
-
-   /* Use a single buffer which doesn't continue */
-   head = vq->free_head;
-   vq->vring.desc[head].flags = VRING_DESC_F_INDIRECT;
-   vq->vring.desc[head].addr = virt_to_phys(desc);
-   /* kmemleak gives a false positive, as it's hidden by virt_to_phys */
-   kmemleak_ignore(desc);
-   vq->vring.desc[head].len = i * sizeof(struct vring_desc);
-
-   /* Update free pointer */
-   vq->free_head = vq->vring.desc[head].next;
+   desc = kmalloc(total_sg * sizeof(struct vring_desc), gfp);
+   if (!desc)
+   return NULL;
 
-   return head;
+   for (i = 0; i < total_sg; i++)
+   desc[i].next = i+1;
+   return desc;
 }
 
 static inline int virtqueue_add(struct virtqueue *_vq,
@@ -176,8 +130,10 @@ static inline int virtqueue_add(struct virtqueue *_vq,
 {
struct vring_virtqueue *vq = to_vvq(_vq);
struct scatterlist *sg;
-   unsigned int i, n, avail, uninitialized_var(prev);
+   struct vring_desc *desc;
+   unsigned int i, n, avail, 

[PATCH 1/3] virtio_net: pass well-formed sgs to virtqueue_add_*()

[Rusty Russell]

This is the only driver which doesn't hand virtqueue_add_inbuf and
virtqueue_add_outbuf a well-formed, well-terminated sg.  Fix it,
so we can make virtio_add_* simpler.

pktgen results:
modprobe pktgen
echo 'add_device eth0' > /proc/net/pktgen/kpktgend_0
echo nowait 1 > /proc/net/pktgen/eth0
echo count 100 > /proc/net/pktgen/eth0
echo clone_skb 10 > /proc/net/pktgen/eth0
echo dst_mac 4e:14:25:a9:30:ac > /proc/net/pktgen/eth0
echo dst 192.168.1.2 > /proc/net/pktgen/eth0
for i in `seq 20`; do echo start > /proc/net/pktgen/pgctrl; tail -n1 
/proc/net/pktgen/eth0; done

Before:
  746547-793084(786421+/-9.6e+03)pps 346-367(364.4+/-4.4)Mb/sec 
(346397808-367990976(3.649e+08+/-4.5e+06)bps) errors: 0

After:
  767390-792966(785159+/-6.5e+03)pps 356-367(363.75+/-2.9)Mb/sec 
(356068960-367936224(3.64314e+08+/-3e+06)bps) errors: 0

Signed-off-by: Rusty Russell 
---
 drivers/net/virtio_net.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 59caa06f34a6..31cac511b3c3 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -546,8 +546,8 @@ static int add_recvbuf_small(struct receive_queue *rq, 
gfp_t gfp)
skb_put(skb, GOOD_PACKET_LEN);
 
hdr = skb_vnet_hdr(skb);
+   sg_init_table(rq->sg, MAX_SKB_FRAGS + 2);
sg_set_buf(rq->sg, >hdr, sizeof hdr->hdr);
-
skb_to_sgvec(skb, rq->sg + 1, 0, skb->len);
 
err = virtqueue_add_inbuf(rq->vq, rq->sg, 2, skb, gfp);
@@ -563,6 +563,8 @@ static int add_recvbuf_big(struct receive_queue *rq, gfp_t 
gfp)
char *p;
int i, err, offset;
 
+   sg_init_table(rq->sg, MAX_SKB_FRAGS + 2);
+
/* page in rq->sg[MAX_SKB_FRAGS + 1] is list tail */
for (i = MAX_SKB_FRAGS + 1; i > 1; --i) {
first = get_a_page(rq, gfp);
@@ -899,6 +901,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff 
*skb)
if (vi->mergeable_rx_bufs)
hdr->mhdr.num_buffers = 0;
 
+   sg_init_table(sq->sg, MAX_SKB_FRAGS + 2);
if (can_push) {
__skb_push(skb, hdr_len);
num_sg = skb_to_sgvec(skb, sq->sg, 0, skb->len);
-- 
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/

[RFC][PATCH] signal: replace !likely with unlikely!

[roy . qing . li]

From: Li RongQing  

!likely() is hard to be understood, and I do not know if compiler can
optimise this condition, but unlikely(!()) is clear

Signed-off-by: Li RongQing 
---
 kernel/signal.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 8f0876f..6156cfa 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1571,7 +1571,7 @@ int send_sigqueue(struct sigqueue *q, struct task_struct 
*t, int group)
BUG_ON(!(q->flags & SIGQUEUE_PREALLOC));
 
ret = -1;
-   if (!likely(lock_task_sighand(t, )))
+   if (unlikely(!lock_task_sighand(t, )))
goto ret;
 
ret = 1; /* the signal is ignored */
-- 
1.7.10.4

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

RE: [Bug] 3.16 fwdownload failure on Marvell 88SE9125 sata controller

[Patel, Gaurav]

I will try to update kernel on Ubuntu to 2.6.32 and run the test.

I was not able to install 3.16 ubuntu kernel on RrdHat.

Thanks,
Gaurav Patel
Email: gspa...@hp.com
Cell # 832-382-5550

-Original Message-
From: Ming Lei [mailto:ming@canonical.com] 
Sent: Wednesday, September 10, 2014 6:01 PM
To: Patel, Gaurav
Cc: Robert Hancock; linux-...@vger.kernel.org; Tejun Heo; Linux Kernel Mailing 
List
Subject: Re: [Bug] 3.16 fwdownload failure on Marvell 88SE9125 sata controller

On Thu, Sep 11, 2014 at 12:11 AM, Patel, Gaurav  wrote:
>
> ">> When we use hdparm to download firmware on system with Marvell
>>> 88SE9125 SATA controller, it returns failure always and it has been 
>>> observed in several systems:"
>
>  [Gaurav]:  So I have another moonshot cartridge with same SATA controller 
> and I was able to update FW with hdparm with RedHat65 without any issues. So 
> this looks to me issue with Ubuntu kernel dos not have correct driver (or 
> something is missing to support hdparm or sata controller).

But RedHat65 ships a 2.6.32 kernel as you said, and you can test the stable
2.6.32 kernel on one ubuntu release too.

As far as I can tell, the problem is very probably related with kernel, that is 
why I suggest you to test upstream kernel and run 'git bisect' later to find 
the commit which caused the regression.

But looks you have simply install problem.

Thanks,


>
> Thanks,
> Gaurav Patel
> Email: gspa...@hp.com
> Cell # 832-382-5550
>
>
> -Original Message-
> From: Ming Lei [mailto:ming@canonical.com]
> Sent: Wednesday, September 10, 2014 1:34 AM
> To: Robert Hancock
> Cc: linux-...@vger.kernel.org; Tejun Heo; Linux Kernel Mailing List; 
> Patel, Gaurav
> Subject: Re: [Bug] 3.16 fwdownload failure on Marvell 88SE9125 sata 
> controller
>
> On Wed, Sep 10, 2014 at 11:38 AM, Robert Hancock  wrote:
>> On 01/09/14 02:22 AM, Ming Lei wrote:
>>>
>>> Hi Guys,
>>>
>>> When we use hdparm to download firmware on system with Marvell
>>> 88SE9125 SATA controller, it returns failure always and it has been 
>>> observed in several systems:
>>>
>>> #hdparm --fwdownload-mode7 fw.bin
>>> --yes-i-kno-what-i-am-doing --please-destroy-my-drive /dev/sda
>>>
>>> /dev/sda:
>>> fwdownload: xfer_mode=7 min=1 max=65535 size=699392
>>> FAILED: Input/output error
>>
>>
>> Any errors in dmesg after doing this?
>
> No any failure log from kernel.
>
> Thanks,
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH 1/4 v3] GPIO: gpio-dwapb: Enable platform driver binding to MFD driver

[Chen, Alvin]

> >
> > Hi Alvin,
> >
> > I did a quick test and this looks like it works for me (with device tree).
> > I had a couple of small fixes below.
> It is very appreciated to help testing.
> 
> 
> > Alan
> >
> > >
> > > - port->bgc.gc.ngpio = ngpio;
> > > - port->bgc.gc.of_node = port_np;
> > > +#ifdef CONFIG_OF_GPIO
> > > + port->bgc.gc.of_node = pp->node;
> > > +#endif
> >
> > Please use 'if (IS_ENABLED(CONFIG_OF_GPIO)) as a conditional as you do
> > elsewhere.
> OK.
> 
Alan, I just do a quick test, here we can't use 'IS_ENABLED', it can't be 
compiled without OF_GPIO set.
Because 'gc.of_node' is not defined without 'OF_GPIO'. You can refer the 
structure of 'gc'.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: Always allow tcflow(TCOON) to unwedge terminal

[Peter Hurley]

On 09/10/2014 08:24 PM, Greg Kroah-Hartman wrote:
> On Wed, Sep 10, 2014 at 08:11:14PM -0400, Peter Hurley wrote:
>> On 09/10/2014 08:03 PM, Greg Kroah-Hartman wrote:
>>> On Wed, Sep 10, 2014 at 05:28:19PM -0400, Peter Hurley wrote:
 This patch changes user-space behavior (for the better) but I'm not sure
 that it's consequence-free. Also, it might not be enough to unwedge the
 terminal if the driver got its own flow control state mangled.

 Thoughts?

 --- >% ---
 Subject: [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal

 If terminal flow has been stopped, the terminal can be unwedged
 by:
tcflow(fd, TCOOFF);
tcflow(fd, TCOON);
 This works because tcflow(TCOOFF) ensures that ->flow_stopped is set,
 which allows tcflow(TCOON) to override the terminal flow state in
 __start_tty().

 Instead, allow unwedging with only:
 tcflow(fd, TCOON);
 by disregarding the existing ->flow_stopped state.
>>>
>>> I don't see the benifit here, what are you trying to solve?  Sending one
>>> extra tcflow command?
>>
>> It's not common knowledge (and its certainly counterintuitive) that
>> turning off output when output is already turned off (ie., tcflow(TCOOFF))
>> is the required trickery to unwedge a terminal.
>>
>> Unwedging directly seems the straightforward approach.
> 
> What's the odds we break POSIX with this type of change?

SUSv3 and v4 do not specify how tcflow() interacts with flow control
from the remote side, so POSIX breakage is not possible.

> I'm all for working around broken hardware in the kernel, but this seems
> like a very old issue, if it's even one at all, that we would be
> changing for no one who has reported it (that I know of...)

How to unwedge a terminal comes up from time to time.

> In other words, I'm really leary of changing userspace functionality
> without having a real need/reason to.

It's possible that this may cause userspace breakage. Some app
may call tcflow(TCOON) thus accidently overriding the flow control
state when it would have had no effect before.

I'm not invested in this patch so I have no problem if you don't
want to take this.

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

Re: [PATCH v4 7/9] usb: rename transceiver and phy to usb_phy in ChipIdea

[Peter Chen]

On Wed, Sep 03, 2014 at 09:40:38AM +0200, Antoine Tenart wrote:
> This patch prepares the introduction of the generic PHY support in the
> USB ChipIdea common functions. The USB PHY member of the ChipIdea
> structure ('transceiver') is renamed to 'usb_phy', the 'phy' member of
> the ChipIdea pdata structure is renamed to 'usb_phy' and modifications
> are done in all drivers accessing it. Renaming this pointer will allow
> to keep the compatibility for USB PHY drivers.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/usb/chipidea/ci.h  |  4 ++--
>  drivers/usb/chipidea/ci_hdrc_imx.c |  2 +-
>  drivers/usb/chipidea/ci_hdrc_msm.c |  8 
>  drivers/usb/chipidea/core.c| 20 ++--
>  drivers/usb/chipidea/debug.c   |  2 +-
>  drivers/usb/chipidea/host.c|  4 ++--
>  drivers/usb/chipidea/otg_fsm.c |  4 ++--
>  drivers/usb/chipidea/udc.c |  4 ++--
>  include/linux/usb/chipidea.h   |  2 +-
>  9 files changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 9563cb56d564..b2caa1772712 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -161,7 +161,7 @@ struct hw_bank {
>   * @test_mode: the selected test mode
>   * @platdata: platform specific information supplied by parent device
>   * @vbus_active: is VBUS active
> - * @transceiver: pointer to USB PHY, if any
> + * @usb_phy: pointer to USB PHY, if any
>   * @hcd: pointer to usb_hcd for ehci host driver
>   * @debugfs: root dentry for this controller in debugfs
>   * @id_event: indicates there is an id event, and handled at ci_otg_work
> @@ -201,7 +201,7 @@ struct ci_hdrc {
>  
>   struct ci_hdrc_platform_data*platdata;
>   int vbus_active;
> - struct usb_phy  *transceiver;
> + struct usb_phy  *usb_phy;
>   struct usb_hcd  *hcd;
>   struct dentry   *debugfs;
>   boolid_event;
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index 65444b02bd68..3aa3f62e079c 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -139,7 +139,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>   goto err_clk;
>   }
>  
> - pdata.phy = data->phy;
> + pdata.usb_phy = data->phy;
>  
>   if (imx_platform_flag->flags & CI_HDRC_IMX_IMX28_WRITE_FIX)
>   pdata.flags |= CI_HDRC_IMX28_WRITE_FIX;
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index d72b9d2de2c5..94cd7c3e12a3 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -31,13 +31,13 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n");
>   /*
> -  * Put the transceiver in non-driving mode. Otherwise host
> +  * Put the phy in non-driving mode. Otherwise host
>* may not detect soft-disconnection.
>*/
> - val = usb_phy_io_read(ci->transceiver, ULPI_FUNC_CTRL);
> + val = usb_phy_io_read(ci->usb_phy, ULPI_FUNC_CTRL);
>   val &= ~ULPI_FUNC_CTRL_OPMODE_MASK;
>   val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
> - usb_phy_io_write(ci->transceiver, val, ULPI_FUNC_CTRL);
> + usb_phy_io_write(ci->usb_phy, val, ULPI_FUNC_CTRL);
>   break;
>   default:
>   dev_dbg(dev, "unknown ci_hdrc event\n");
> @@ -71,7 +71,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   if (IS_ERR(phy))
>   return PTR_ERR(phy);
>  
> - ci_hdrc_msm_platdata.phy = phy;
> + ci_hdrc_msm_platdata.usb_phy = phy;
>  
>   plat_ci = ci_hdrc_add_device(>dev,
>   pdev->resource, pdev->num_resources,
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 619d13e29995..a8cd35fd8175 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -306,7 +306,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
>   case USBPHY_INTERFACE_MODE_UTMI:
>   case USBPHY_INTERFACE_MODE_UTMIW:
>   case USBPHY_INTERFACE_MODE_HSIC:
> - ret = usb_phy_init(ci->transceiver);
> + ret = usb_phy_init(ci->usb_phy);
>   if (ret)
>   return ret;
>   hw_phymode_configure(ci);
> @@ -314,12 +314,12 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
>   case USBPHY_INTERFACE_MODE_ULPI:
>   case USBPHY_INTERFACE_MODE_SERIAL:
>   hw_phymode_configure(ci);
> - ret = usb_phy_init(ci->transceiver);
> + ret = usb_phy_init(ci->usb_phy);
>

RE: [PATCH 1/4 v3] GPIO: gpio-dwapb: Enable platform driver binding to MFD driver

[Chen, Alvin]

> 
> Hi Alvin,
> 
> I did a quick test and this looks like it works for me (with device tree).
> I had a couple of small fixes below.
It is very appreciated to help testing.


> Alan
> 
> >
> > -   port->bgc.gc.ngpio = ngpio;
> > -   port->bgc.gc.of_node = port_np;
> > +#ifdef CONFIG_OF_GPIO
> > +   port->bgc.gc.of_node = pp->node;
> > +#endif
> 
> Please use 'if (IS_ENABLED(CONFIG_OF_GPIO)) as a conditional as you do
> elsewhere.
OK.

> 
> >  static int dwapb_gpio_probe(struct platform_device *pdev)  {
> > +   int i;
> > struct resource *res;
> > struct dwapb_gpio *gpio;
> > -   struct device_node *np;
> > int err;
> > -   unsigned int offs = 0;
> > +   struct device *dev = >dev;
> > +   struct dwapb_platform_data *pdata = dev_get_platdata(dev);
> > +   bool is_pdata_alloc = !pdata;
> 
> Please combine the int's in one line (int err, i;) and put them as the last 
> one on
> this list.  It looks the same to the compiler of course, but more uniform for
> human eyes :)
OK.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: Always allow tcflow(TCOON) to unwedge terminal

[Greg Kroah-Hartman]

On Wed, Sep 10, 2014 at 08:11:14PM -0400, Peter Hurley wrote:
> On 09/10/2014 08:03 PM, Greg Kroah-Hartman wrote:
> > On Wed, Sep 10, 2014 at 05:28:19PM -0400, Peter Hurley wrote:
> >> This patch changes user-space behavior (for the better) but I'm not sure
> >> that it's consequence-free. Also, it might not be enough to unwedge the
> >> terminal if the driver got its own flow control state mangled.
> >>
> >> Thoughts?
> >>
> >> --- >% ---
> >> Subject: [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal
> >>
> >> If terminal flow has been stopped, the terminal can be unwedged
> >> by:
> >>tcflow(fd, TCOOFF);
> >>tcflow(fd, TCOON);
> >> This works because tcflow(TCOOFF) ensures that ->flow_stopped is set,
> >> which allows tcflow(TCOON) to override the terminal flow state in
> >> __start_tty().
> >>
> >> Instead, allow unwedging with only:
> >> tcflow(fd, TCOON);
> >> by disregarding the existing ->flow_stopped state.
> > 
> > I don't see the benifit here, what are you trying to solve?  Sending one
> > extra tcflow command?
> 
> It's not common knowledge (and its certainly counterintuitive) that
> turning off output when output is already turned off (ie., tcflow(TCOOFF))
> is the required trickery to unwedge a terminal.
> 
> Unwedging directly seems the straightforward approach.

What's the odds we break POSIX with this type of change?

I'm all for working around broken hardware in the kernel, but this seems
like a very old issue, if it's even one at all, that we would be
changing for no one who has reported it (that I know of...)

In other words, I'm really leary of changing userspace functionality
without having a real need/reason to.

thanks,

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

Здарово! Хочу по секрету с тобой кое чем поделиться , нашел тему в которой можно заработать несколько тысяч $, описание курса по заработку, пока в в сети

[Pavel V . Panteleev]

   http://wecare2serve.com/money_order_locations.php   
   

Re: [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal

[Peter Hurley]

On 09/10/2014 08:03 PM, Greg Kroah-Hartman wrote:
> On Wed, Sep 10, 2014 at 05:28:19PM -0400, Peter Hurley wrote:
>> This patch changes user-space behavior (for the better) but I'm not sure
>> that it's consequence-free. Also, it might not be enough to unwedge the
>> terminal if the driver got its own flow control state mangled.
>>
>> Thoughts?
>>
>> --- >% ---
>> Subject: [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal
>>
>> If terminal flow has been stopped, the terminal can be unwedged
>> by:
>>  tcflow(fd, TCOOFF);
>>  tcflow(fd, TCOON);
>> This works because tcflow(TCOOFF) ensures that ->flow_stopped is set,
>> which allows tcflow(TCOON) to override the terminal flow state in
>> __start_tty().
>>
>> Instead, allow unwedging with only:
>> tcflow(fd, TCOON);
>> by disregarding the existing ->flow_stopped state.
> 
> I don't see the benifit here, what are you trying to solve?  Sending one
> extra tcflow command?

It's not common knowledge (and its certainly counterintuitive) that
turning off output when output is already turned off (ie., tcflow(TCOOFF))
is the required trickery to unwedge a terminal.

Unwedging directly seems the straightforward approach.

Regards,
Peter Hurley

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

Re: [PATCH v10 1/3] RTC: RK808: add RTC driver for RK808

[Doug Anderson]

Andrew,

On Wed, Sep 10, 2014 at 3:08 PM, Andrew Morton
 wrote:
> On Wed, 10 Sep 2014 14:37:13 -0700 Doug Anderson  
> wrote:
>
>> Andrew,
>>
>> On Wed, Sep 10, 2014 at 1:44 PM, Andrew Morton
>>  wrote:
>> > On Wed, 10 Sep 2014 09:18:04 +0800 Chris Zhong  wrote:
>> >
>> >> Adding RTC driver for supporting RTC device present inside RK808 PMIC.
>> >>
>> >> ...
>> >>
>> >> + ret = rtc_valid_tm();
>> >> + if (ret) {
>> >> + dev_warn(>dev, "invalid date/time and init time\n");
>> >> + rk808_rtc_set_time(>dev, _def);
>> >> + }
>> >
>> > This is somewhat unusual.  Most drivers will emit a warning and give up
>> > when they find the time is wrong.  Why is this driver different and is
>> > this desirable behaviour?
>>
>> When you say "give up", what does that mean?  I assume the driver
>> should keep initting, right?  Then the user can go in and set a time
>> later...
>
> I think I was misreading current drivers a bit.  rtc-cmos.c will go in
> and set a dummy time but regular low-level drivers don't sanity-check
> the time at all at setup time.
>
>>
>> I did test things with just removing this chunk of code.  You get some
>> yells at bootup if you put a bogus time in there:
>>
>> [2.987590] rk808-rtc rk808-rtc: invalid date/time and init time
>> [3.013148] rk808-rtc rk808-rtc: rtc core: registered rk808-rtc as rtc0
>> [4.586115] rk808-rtc rk808-rtc: hctosys: invalid date/time
>>
>> ...but if you later set a valid time then everything is fine.  That
>> seems reasonable behavior to me, so I guess we could just remove this
>> whole chunk?  It appears that after a normal bootup the date/time is
>> something valid.
>
> hm.  Having an invalid time is perhaps better than having a valid but
> incorrect time.

OK.  It's an easy patch to remove this.  Chris: do you want to test
that too and post it, or do you want me to?  Basically just remove:

  rk808_rtc_set_time(>dev, _def);

...and of course then remove the tm_def structure and take braces off
the "if".  I think everything works if you do that.  We need to make
sure to base on the patch Andrew talked about about making the
structure static (the new patch would remove the structure completely,
but nice not to get a merge conflict).

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

Re: [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal

[Greg Kroah-Hartman]

On Wed, Sep 10, 2014 at 05:28:19PM -0400, Peter Hurley wrote:
> This patch changes user-space behavior (for the better) but I'm not sure
> that it's consequence-free. Also, it might not be enough to unwedge the
> terminal if the driver got its own flow control state mangled.
> 
> Thoughts?
> 
> --- >% ---
> Subject: [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal
> 
> If terminal flow has been stopped, the terminal can be unwedged
> by:
>   tcflow(fd, TCOOFF);
>   tcflow(fd, TCOON);
> This works because tcflow(TCOOFF) ensures that ->flow_stopped is set,
> which allows tcflow(TCOON) to override the terminal flow state in
> __start_tty().
> 
> Instead, allow unwedging with only:
> tcflow(fd, TCOON);
> by disregarding the existing ->flow_stopped state.

I don't see the benifit here, what are you trying to solve?  Sending one
extra tcflow command?

thanks,

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

Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs

[Jerome Glisse]

On Wed, Sep 10, 2014 at 03:01:25PM -0700, Andrew Morton wrote:
> On Tue,  9 Sep 2014 17:43:51 +0200 Joerg Roedel  wrote:
> 
> > here is a patch-set to extend the mmu_notifiers in the Linux
> > kernel to allow managing CPU external TLBs. Those TLBs may
> > be implemented in IOMMUs or any other external device, e.g.
> > ATS/PRI capable PCI devices.
> > 
> > The problem with managing these TLBs are the semantics of
> > the invalidate_range_start/end call-backs currently
> > available. Currently the subsystem using mmu_notifiers has
> > to guarantee that no new TLB entries are established between
> > invalidate_range_start/end. Furthermore the
> > invalidate_range_start() function is called when all pages
> > are still mapped and invalidate_range_end() when the pages
> > are unmapped an already freed.
> > 
> > So both call-backs can't be used to safely flush any non-CPU
> > TLB because _start() is called too early and _end() too
> > late.
> 
> There's a lot of missing information here.  Why don't the existing
> callbacks suit non-CPU TLBs?  What is different about them?  Please
> update the changelog to contain all this context.

So unlike KVM or any current user of the mmu_notifier api, any PCIE
ATS/PASID capable hardware IOMMUv2 for AMD and forgot the marketing
name for Intel (probably VTd) implementation walk the cpu page table
on there own and have there own TLB cache. In fact not only the iommu
can have a TLB cache but any single PCIE hardware can implement its
own local TLB cache.

So if we flush the IOMMU and device TLB inside the range_start callback
there is a chance that the hw will just rewalk the cpu page table and
repopulate its TLB before the CPU page table is actually updated.

Now if we shoot down the TLB inside the range_end callback, then we
are too late ie the CPU page table is already populated with new entry
and all the TLB in the IOMMU an in device might be pointing to the old
pages.

So the aim of this callback is to happen right after the CPU page table
is updated but before the old page is freed or recycled. Note that it
is also safe for COW and other transition from like read only to read
and write or the other way around.

> 
> > In the AMD IOMMUv2 driver this is currently implemented by
> > assigning an empty page-table to the external device between
> > _start() and _end(). But as tests have shown this doesn't
> > work as external devices don't re-fault infinitly but enter
> > a failure state after some time.
> 
> More missing info.  Why are these faults occurring?  Is there some
> device activity which is trying to fault in pages, but the CPU is
> executing code between _start() and _end() so the driver must refuse to
> instantiate a page to satisfy the fault?  That's just a guess, and I
> shouldn't be guessing.  Please update the changelog to fully describe
> the dynamic activity which is causing this.

The hack that was use prior to this patch was to point the IOMMU to an
empty page table (a zero page) inside the range_start() callback and
shoot down the TLB but this meant that the device might enter inside a
storm of page fault. GPU can have thousand of threads and because during
invalidation the empty page table is use they all starts triggering page
fault even if they were not trying to access the range being invalidated.
It turns out that when this happens current hw like AMD GPU actually stop
working after a while ie the hw stumble because there is too much fault
going on.

> 
> > Next problem with this solution is that it causes an
> > interrupt storm for IO page faults to be handled when an
> > empty page-table is assigned.
> 
> Also too skimpy.  I *think* this is a variant of the problem in the
> preceding paragraph.  We get a fault storm (which is problem 2) and
> sometimes the faulting device gives up (which is problem 1).
> 
> Or something.  Please de-fog all of this.
> 

Does above explanation help understand the issue ? Given that on each
device page fault an IRQ is trigger (well the way the hw works is bit
more complex than that).

> > Furthermore the _start()/end() notifiers only catch the
> > moment when page mappings are released, but not page-table
> > pages. But this is necessary for managing external TLBs when
> > the page-table is shared with the CPU.
> 
> How come?

As explained above end() might happens after page that were previously
mapped are free or recycled.

> 
> > To solve this situation I wrote a patch-set to introduce a
> > new notifier call-back: mmu_notifer_invalidate_range(). This
> > notifier lifts the strict requirements that no new
> > references are taken in the range between _start() and
> > _end(). When the subsystem can't guarantee that any new
> > references are taken is has to provide the
> > invalidate_range() call-back to clear any new references in
> > there.
> > 
> > It is called between invalidate_range_start() and _end()
> > every time the VMM has to wipe out any references to a
> > couple of pages. This are usually the places 

Re: [PATCH] blk-merge: fix blk_recount_segments

[Ming Lei]

On Thu, Sep 11, 2014 at 7:38 AM, Rusty Russell  wrote:
> Rusty Russell  writes:
>> Rusty Russell  writes:
>> Here's what I have.  It seems to work as expected, but I haven't
>> benchmarked it.
>
> Hi Ming,
>
> Any chance you can run your benchmarks against this patch?

I can run the previous benchmark against this patch, but I am wondering
if it is enough since the change need lots of test cases to verify.

BTW, looks your patch doesn't against upstream kernel, since I can't
find alloc_indirect() in drivers/virtio/virtio_ring.c

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

Re: [PATCH 8/8] blk-mq: support per-distpatch_queue flush machinery

[Ming Lei]

On Thu, Sep 11, 2014 at 3:02 AM, Christoph Hellwig  wrote:
> On Wed, Sep 10, 2014 at 09:40:11AM +0800, Ming Lei wrote:
>> I am wondering we can do that because lifetime is totally different
>> between flush requests and tag_set requests which are initialized
>> before request queue is created.
>
> We shouldn't do it in the tag sets, but where we allocate and free
> each hctx: blk_mq_init_queue and blk_mq_free_hw_queues.

That should work, but both flush queue's allocation and .init_request()
have to move to the function because hctx->numa_node is basically
ready in blk_mq_init_queue().  Then blk_init_flush() only need to allocate
the data for legacy case.


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

Re: bit fields && data tearing

[Peter Hurley]

On 09/10/2014 05:48 PM, James Bottomley wrote:
> On Tue, 2014-09-09 at 06:40 -0400, Peter Hurley wrote:
>> On 09/08/2014 10:56 PM, James Bottomley wrote:
>>> On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
 On 09/08/2014 01:50 AM, James Bottomley wrote:
>> But additionally, even if gcc combines adjacent writes _that are part
>> of the program flow_ then I believe the situation is no worse than
>> would otherwise exist.
>>
>> For instance, given the following:
>>
>> struct x {
>>  spinlock_t lock;
>>  long a;
>>  byte b;
>>  byte c;
>> };
>>
>> void locked_store_b(struct x *p)
>> {
>>  spin_lock(>lock);
>>  p->b = 1;
>>  spin_unlock(>lock);
>>  p->c = 2;
>> }
>>
>> Granted, the author probably expects ordered writes of
>>  STORE B
>>  STORE C
>> but that's not guaranteed because there is no memory barrier
>> ordering B before C.
>
> Yes, there is: loads and stores may not migrate into or out of critical
> sections.

 That's a common misconception.

 The processor is free to re-order this to:

STORE C
STORE B
UNLOCK

 That's because the unlock() only guarantees that:

 Stores before the unlock in program order are guaranteed to complete
 before the unlock completes. Stores after the unlock _may_ complete
 before the unlock completes.

 My point was that even if compiler barriers had the same semantics
 as memory barriers, the situation would be no worse. That is, code
 that is sensitive to memory barriers (like the example I gave above)
 would merely have the same fragility with one-way compiler barriers
 (with respect to the compiler combining writes).

 That's what I meant by "no worse than would otherwise exist".
>>>
>>> Actually, that's not correct.  This is actually deja vu with me on the
>>> other side of the argument.  When we first did spinlocks on PA, I argued
>>> as you did: lock only a barrier for code after and unlock for code
>>> before.  The failing case is that you can have a critical section which
>>> performs an atomically required operation and a following unit which
>>> depends on it being performed.  If you begin the following unit before
>>> the atomic requirement, you may end up losing.  It turns out this kind
>>> of pattern is inherent in a lot of mail box device drivers: you need to
>>> set up the mailbox atomically then poke it.  Setup is usually atomic,
>>> deciding which mailbox to prime and actually poking it is in the
>>> following unit.  Priming often involves an I/O bus transaction and if
>>> you poke before priming, you get a misfire.
>>
>> Take it up with the man because this was discussed extensively last
>> year and it was decided that unlocks would not be full barriers.
>> Thus the changes to memory-barriers.txt that explicitly note this
>> and the addition of smp_mb__after_unlock_lock() (for two different
>> locks; an unlock followed by a lock on the same lock is a full barrier).
>>
>> Code that expects ordered writes after an unlock needs to explicitly
>> add the memory barrier.
> 
> I don't really care what ARM does; spin locks are full barriers on
> architectures that need them.  The driver problem we had that detected
> our semi permeable spinlocks was an LSI 53c875 which is enterprise class
> PCI, so presumably not relevant to ARM anyway.

Almost certainly ia64 arch_spin_unlock() is not a full barrier.


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