Re: [PATCH v10 07/10] OF: Introduce helper function for getting PCI domain_nr

[Yijing Wang]

>>> on new requests. This function gets called quite a lot and I'm trying not to
>>> make it too heavy weight.
>>
>> Generally, nothing should be accessing the same DT value frequently.
>> It should get cached somewhere.
>>
> 
> The problem appears for DTs that don't have the pci-domain info. Then the 
> cached
> value is left at the default non-valid value and attempts to rescan the DT 
> will
> be made every time the function is called.
> 
>> I don't really understand how domains are used so it's hard to provide
>> a recommendation here. Do domains even belong in the DT?
> 
> ACPI calls them segments and the way Bjorn explained it to me at some moment 
> was
> that it was an attempt to split up a bus in different groups (or 
> alternatively,
> merge a few busses together). To be honest I haven't seen systems where the 
> domain
> is anything other than zero, but JasonG (or maybe Benjamin) were floating an
> idea of using the domain number to identify physical slots.

PCI domain(or named segment) is provided by firmware, in ACPI system, we 
evaluated it
by method "_SEG". in IA64 with ACPI, PCI hostbridge driver retrieves the domain 
from ACPI,
if it's absent, the default domain is zero. So I wonder why in DTS, if it's 
absent, we get
a auto increment domain value.

PCI get domain by ACPI "_SEG" in IA64(drivers/acpi/pci_root.c)
..
status = acpi_evaluate_integer(handle, METHOD_NAME__SEG, NULL,
   );
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
dev_err(>dev,  "can't evaluate _SEG\n");
result = -ENODEV;
goto end;
}
...

Thanks!
Yijing.

> 
>> This function
>> is just a weird mixture of data retrieval and allocation. I think you
>> need to separate it into 2 functions.
> 
> It is meant to do allocation with the retrieval being a short-cut (or fine
> control if you want).
> 
> I need to think a bit more for a better solution.
> 
> Best regards,
> Liviu
> 
>>
>> Rob
>>
> 


-- 
Thanks!
Yijing

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: serial: men_z135_uart: Fix driver for changes in hardware

[Johannes Thumshirn]

On Mon, Sep 08, 2014 at 04:17:33PM -0700, Greg Kroah-Hartman wrote:
> >
> > @@ -118,6 +117,10 @@ static int align;
> >  module_param(align, int, S_IRUGO);
> >  MODULE_PARM_DESC(align, "Keep hardware FIFO write pointer aligned, default 
> > 0");
> >
> > +static int rx_timeout;
> > +module_param(rx_timeout, uint, S_IRUGO);
> > +MODULE_PARM_DESC(rx_timeout, "RX timeout");
>
> Why add a module parameter?  Who will know to set this?  And to what
> value?
>

There will be a user manual describing the parameter. It's like the rxlvl and
txlvl parameters, you'll have to read the manual if you need other values than
the default ones.


> And what about this driver working on old hardware, didn't you just
> break this?
>

No. Currently the hardware is in a testing stage at only one customer and it is
an IP-Core inside a FPGA, so it can be (and already is) updated. So we can be
save to assume this is O.K.

> thanks,
>
> greg k-h

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

RE: [PATCH net-next v2] r8169:add support for RTL8168H and RTL8107E

[Hayes Wang]

 From: Ivan Vecera [mailto:ivec...@redhat.com] 
> Sent: Monday, September 08, 2014 9:01 PM
> To: Hau; net...@vger.kernel.org
> Cc: nic_swsd; linux-kernel@vger.kernel.org; rom...@fr.zoreil.com
> Subject: Re: [PATCH net-next v2] r8169:add support for 
> RTL8168H and RTL8107E
[...]
> Where are these new firmware files  located? They are missing at 
> git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-f
> irmware.git

We don't update them, yet. We will update them after testing all of them.
 
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/17] ARM64 / ACPI: Parse MADT for SMP initialization

[Jon Masters]

On 09/09/2014 12:57 AM, Hanjun Guo wrote:
> Hi Jon,
> 
> On 2014年09月09日 12:23, Jon Masters wrote:
>> On 09/01/2014 10:57 AM, Hanjun Guo wrote:
>>> MADT contains the information for MPIDR which is essential for
>>> SMP initialization, parse the GIC cpu interface structures to
>>> get the MPIDR value and map it to cpu_logical_map(), and add
>>> enabled cpu with valid MPIDR into cpu_possible_map.
>>>
>>> ACPI 5.1 only has two explicit methods to boot up SMP, PSCI and
>>> Parking protocol, but the Parking protocol is only specified for
>>> ARMv7 now, so make PSCI as the only way for the SMP boot protocol
>>> before some updates for the ACPI spec or the Parking protocol spec.
>>> +   /* CPU 0 was already initialized */
>>> +   if (cpu) {
>>> +   if (cpu_ops[cpu]->cpu_init(NULL, cpu))
>>> +   return -EOPNOTSUPP;
>>> +
>>> +   /* map the logical cpu id to cpu MPIDR */
>>> +   cpu_logical_map(cpu) = mpidr;
>> I'm not sure it's worth noting in a comment or just in the dialogue that
>> none of these MPIDR values is literally the value in the MPIDR. Linux
>> doesn't store that anyway (even in the cpu_logical_map), since it is
>> pre-filtered against MPIDR_HWID_BITMASK to remove the non-affinity level
>> bits. And since the ACPI5.1 specification requires that non-affinity
>> bits be zero everything works. But it relies upon this assumption so it
>> might be worth explicitly masking out the bits when making the call into:
>>
>>acpi_map_gic_cpu_interface(processor->arm_mpidr,
>>processor->flags & ACPI_MADT_ENABLED);
>>
>> During the parsing of the processor object's MPIDR value.
> 
> Yes, I agree with you. When I tested this patch set on our
> ARM64 platform, I found this problem too. some firmware
> will just present the real MPIDR value to OS which some reserved
> bit set to 1, and it will lead to some logic problem in this patch.
> (actually firmware didn't obey with ACPI spec)
> 
> I had updated the patch with:
> 
> + acpi_map_gic_cpu_interface(processor->arm_mpidr & MPIDR_HWID_BITMASK,
> + processor->flags & ACPI_MADT_ENABLED);
> 
> and then the problem was gone :)

Did I miss an updated patch posting then? It is possible...I was keeping
out of this thread for "obvious" reasons (I'm somewhat biased in favor
of ACPI on 64-bit ARM server platforms and thus not objective in all
cases...so I am confining my feedback to technical specifics). But it's
necessary that there be a little more discussion here. I've got a couple
of requests into various vendors to get more vocal too.

Jon.

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

[Huang Ying]

On Mon, 2014-09-08 at 22:13 -0700, Jaegeuk Kim wrote:
> Hi Huang,
> 
> On Mon, Sep 08, 2014 at 03:36:35PM +0800, huang ying wrote:
> > Hi, Jaegeuk,
> > 
> > On Mon, Sep 8, 2014 at 11:50 AM, Jaegeuk Kim  wrote:
> > 
> > > Hi,
> > >
> > > On Sun, Sep 07, 2014 at 11:38:30AM +0800, Huang Ying wrote:
> > > > Only one bit is read in check_valid_map, holding a lock to do that
> > > > doesn't help anything except decreasing performance.
> > > >
> > > > Signed-off-by: Huang, Ying 
> > > > ---
> > > >
> > > > v2: Fixed a build warning.
> > > >
> > > > ---
> > > >  fs/f2fs/gc.c |3 ---
> > > >  1 file changed, 3 deletions(-)
> > > >
> > > > --- a/fs/f2fs/gc.c
> > > > +++ b/fs/f2fs/gc.c
> > > > @@ -378,14 +378,11 @@ static void put_gc_inode(struct list_hea
> > > >  static int check_valid_map(struct f2fs_sb_info *sbi,
> > > >   unsigned int segno, int offset)
> > > >  {
> > > > - struct sit_info *sit_i = SIT_I(sbi);
> > > >   struct seg_entry *sentry;
> > > >   int ret;
> > > >
> > > > - mutex_lock(_i->sentry_lock);
> > > >   sentry = get_seg_entry(sbi, segno);
> > > >   ret = f2fs_test_bit(offset, sentry->cur_valid_map);
> > > > - mutex_unlock(_i->sentry_lock);
> > > >   return ret;
> > >
> > > The f2fs_test_bit is not atomic, so I'm not sure this is a good approach.
> > > How about introducing rw_semaphore?
> > >
> > 
> > IMO, f2fs_test_bit just read a global variable (a byte in cur_valid_map),
> > then check its value. The byte may be changed in another CPU concurrently.
> > But even protected with a mutex, it can be changed in another CPU
> > immediately after mutex_unlock.  So mutex does not help  here.  Here we
> > just read a global variable, not read/modify/write, so, we don't need
> > atomic too.
> 
> Hmm. This is a pretty hard corner case to allow the mutex removal under the
> following assumption.
> 
> 1. All the sit entries are cached in a global array, which means that it never
> happens that any sit entry pointers are changed.
> 
> 2. I agree that f2fs_gc tries to conduct the cleaning with best effort, and
> it triggers again when it detects there is something to do more.
> So, check_valid_bitmap doesn't need to make a precise decision.
> 
> But, what I concern is the consistent policy to use such the mutex.
> If we break the rule, it becomes harder to debug potential bugs.

Yes.  We definitely need a rule.  But I suggest to make a small tweak to
the rule.  If we just read one variable with fixed address, we need not
to use a mutex to protect that.

> Anyway, have you been facing with such the lock contention?

No, I just review the code and thinks the mutex is not necessary.

Best Regards,
Huang, Ying


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

[Huang Ying]

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.

Best Regards,
Huang, Ying

> Rather than this tweak, if iget is failed, we'd better go to next instead of
> break.
> Can you test that?
> 
> > +   } else if (IS_INODE(page)) {
> > +   if (is_dent_dnode(page)) {
> > err = recover_inode_page(sbi, page);
> > if (err)
> > break;
> > @@ -193,7 +193,8 @@ static int find_fsync_dnodes(struct f2fs
> > break;
> > }
> > list_add_tail(>list, head);
> > -   }
> > +   } else
> > +   goto next;
> > entry->blkaddr = blkaddr;
> >  
> > err = recover_inode(entry->inode, page);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/6] kthread: warn on kill signal if not OOM

[James Bottomley]

On Tue, 2014-09-09 at 10:10 +0900, Tejun Heo wrote:
> Hello, Luis.
> 
> On Mon, Sep 08, 2014 at 06:04:23PM -0700, Luis R. Rodriguez wrote:
> > > I have no idea how the selection should be.  It could be per-insmod or
> > > maybe just a system-wide flag with explicit exceptions marked on
> > > drivers is good enough.  I don't know.
> > 
> > Its perfectly understandable if we don't know what path to take yet
> > and its also understandable for it to take time to figure out --
> > meanwhile though systemd already has merged a policy of a 30 second
> > timeout for *all drivers* though so we therefore need:
> 
> I'm not too convinced this is such a difficult problem to figure out.
> We already have most of logic in place and the only thing missing is
> how to switch it.  Wouldn't something like the following work?
> 
> * Add a sysctl knob to enable asynchronous device probing on module
>   load and enable asynchronous probing globally if the knob is set.
> 
> * Identify cases which can't be asynchronous and make them
>   synchronous.  e.g. keep who's doing request_module() and avoid
>   asynchronous probing if current is probing one of those.

What's wrong with just fixing systemd?  Arbitrary timeouts in init
scripts for system bring up are plain wrong ... I thought we had this
sorted out ten years ago when we were first having the arguments about
how long to wait for root; I'm surprised it's coming back again.

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.  For the current bug fix, just fix
the component that broke ... which would be systemd.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pci/probe: Enable CRS for root port if it is supported

[Bjorn Helgaas]

On Tue, Sep 02, 2014 at 04:26:00PM -0700, Rajat Jain wrote:
> 
> As per the PCIe spec, an endpoint may return the configuration cycles
> with CRS if it is not yet fully ready to be accessed. If the CRS visibility
> is not enabled at the root port, the spec leaves the retry behaviour open
> to implementation in such a case. The Intel root ports have chosen to retry
> endlessly in this situation. Thus, the root controller may "hang" (repeatedly
> retrying the configuration requests until it gets a status other than CRS) if
> a device returns CRS for a long time. This can cause a broken endpoint to 
> bring
> down the whole PCI hierarchy.
> 
> This was recently known to cause problems on Intel systems and
> was discussed here:
> http://marc.info/?t=14092629852=1=2
> 
> Ref1:
> https://www.pcisig.com/specifications/pciexpress/ECN_CRS_Software_Visibility_No27.pdf
> 
> Ref2:
> PCIe spec V3.0, pg119, pg127 for "Configuration Request Retry Status"
> 
> Thus enable the CRS visibility for the root ports that support it. This
> patch reverts the following commit, but enables CRS visibility only
> when the root port supports it:
> 
> ad7edfe04908 ("[PCI] Do not enable CRS Software Visibility by default")
> 
> (Linus' response: http://marc.info/?l=linux-pci=140968622520192=2)
> 
> Signed-off-by: Rajat Jain 
> Signed-off-by: Rajat Jain 
> Signed-off-by: Guenter Roeck 

I put this and the "only look at Vendor ID" patch on a pci/enumeration
branch [1].  I rewrote the changelogs to reflect my understanding of what's
going on, so probably the real truth is somewhere between your original and
mine.  Let me know what should be fixed.

We should figure out an easy way for Josh to test these.  Ideally, he could
test the second patch by itself first, then both together.

[1] 
https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/enumeration

> ---
> v2: Remove the white list, that was enabling the CRS for certain known Intel 
> systems.
> Rather now enable it for all systems that support this capability.
> v1: Enable CRS for only some given Intel systems (maintain a whitelist)
> 
>  drivers/pci/probe.c   |   13 +
>  include/uapi/linux/pci_regs.h |1 +
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index e3cf8a2..3c4c35c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -740,6 +740,17 @@ struct pci_bus *pci_add_new_bus(struct pci_bus *parent, 
> struct pci_dev *dev,
>  }
>  EXPORT_SYMBOL(pci_add_new_bus);
>  
> +static void pci_enable_crs(struct pci_dev *pdev)
> +{
> + u16 root_cap = 0;
> +
> + /* Enable CRS Software visibility if supported */
> + pcie_capability_read_word(pdev, PCI_EXP_RTCAP, _cap);
> + if (root_cap & PCI_EXP_RTCAP_CRSVIS)
> + pcie_capability_set_word(pdev, PCI_EXP_RTCTL,
> +  PCI_EXP_RTCTL_CRSSVE);
> +}
> +
>  /*
>   * If it's a bridge, configure it and scan the bus behind it.
>   * For CardBus bridges, we don't scan behind as the devices will
> @@ -787,6 +798,8 @@ int pci_scan_bridge(struct pci_bus *bus, struct pci_dev 
> *dev, int max, int pass)
>   pci_write_config_word(dev, PCI_BRIDGE_CONTROL,
> bctl & ~PCI_BRIDGE_CTL_MASTER_ABORT);
>  
> + pci_enable_crs(dev);
> +
>   if ((secondary || subordinate) && !pcibios_assign_all_busses() &&
>   !is_cardbus && !broken) {
>   unsigned int cmax;
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 30db069..a75106d 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -552,6 +552,7 @@
>  #define  PCI_EXP_RTCTL_PMEIE 0x0008  /* PME Interrupt Enable */
>  #define  PCI_EXP_RTCTL_CRSSVE0x0010  /* CRS Software Visibility 
> Enable */
>  #define PCI_EXP_RTCAP30  /* Root Capabilities */
> +#define  PCI_EXP_RTCAP_CRSVIS0x0001  /* CRS software visibility 
> capability */
>  #define PCI_EXP_RTSTA32  /* Root Status */
>  #define PCI_EXP_RTSTA_PME0x0001 /* PME status */
>  #define PCI_EXP_RTSTA_PENDING0x0002 /* PME pending */
> -- 
> 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/

linux-next: manual merge of the userns tree with the nfs tree

[Stephen Rothwell]

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in
fs/nfs/client.c between commit 21e81002f978 ("nfs: fix kernel warning
when removing proc entry") from the nfs tree and commit a1998908ba46
("nfs: fix kernel warning when removing proc entry") from the userns
tree.  Slightly different version of the same fix.

I fixed it up (I used the version from the nfs tree) and can carry the
fix as necessary (no action is required).

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


signature.asc
Description: PGP signature

[PATCH] ACPI / platform / LPSS: disable async suspend/resume of LPSS devices

[Fu, Zhonghui]

>From 6deb00230f5df68da3ca7490402a0c537bf386bb Mon Sep 17 00:00:00 2001
From: Fu Zhonghui 
Date: Tue, 9 Sep 2014 13:02:25 +0800
Subject: [PATCH] ACPI / platform / LPSS: disable async suspend/resume of LPSS 
devices

LPSS devices must suspend/resume in fixed order. Or some LPSS devices
will hang during the transition to ACPI_STATE_D0 state.

Signed-off-by: Li Aubrey 
Signed-off-by: Fu Zhonghui 
---
 drivers/acpi/acpi_lpss.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index fddc1e8..54e5c97 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -419,7 +419,7 @@ static int acpi_lpss_create_device(struct acpi_device *adev,
adev->driver_data = pdata;
pdev = acpi_create_platform_device(adev);
if (!IS_ERR_OR_NULL(pdev)) {
-   device_enable_async_suspend(>dev);
+   device_disable_async_suspend(>dev);
return 1;
}
 
-- 1.7.1

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

Re: [PATCH v3 09/17] ARM64 / ACPI: Parse MADT for SMP initialization

[Jon Masters]

On 09/09/2014 01:11 AM, Hanjun Guo wrote:
> On 2014年09月09日 12:29, Jon Masters wrote:
>> Hi Hanjun, Lorenzo,
> 
> Hi Jon,
> 
>>
>> Resending due to my mail client removing list CCs...sorry about that.
>>
>> On 09/04/2014 11:29 AM, Hanjun Guo wrote:
>>
> + } else {
> + /* Fist GICC entry must be BSP as ACPI spec said */
 s/Fist/First/

> + if  (cpu_logical_map(0) != mpidr) {
> + pr_err("First GICC entry is not BSP for MPIDR 0x%llx\n",
> +mpidr);
> + return -EINVAL;
> + }
 Interesting, this means that if I want to change the boot CPU I have to
 recompile the ACPI tables. Is that really true ?
>> Well, the ACPI5.1 specification does require that the PEs (cores) be
>> listed in a very specific order, with the boot CPU first, and then a
>> precisely defined sequence of interleaving of any possible SMT threads
>> with other cores. So I think you would in practice update your tables.
> 
> Thanks for the clarify.

No problem :) I'm trying to go through the various threads and ensure
various things are documented in the record. I'm skipping (for now)
notes on e.g. CPU cache flush behavior because we're not pushing for C3
support (or really any runtime power management) in the first round.

>>
> + /*
> +  * ACPI 5.1 only has two explicit methods to boot up SMP,
> +  * PSCI and Parking protocol, but the Parking protocol is
> +  * only specified for ARMv7 now, so make PSCI as the only
> +  * way for the SMP boot protocol before some updates for
> +  * the ACPI spec or the Parking protocol spec.
> +  */
>> The Parking Protocol may be updated for a (limited) number of platforms
>> that may use it in the early days. The preferred option (as described in
>> the SBBR) is to use PSCI when at all possible. Some implementations of
>> the architecture may not be able to use PSCI for MP-Boot. Thus while
>> there may be some limited early use of the parking protocol (including
>> while PSCI firmware is being finalized during bringup activities), it
>> will ultimately be completely replaced by PSCI based boot over time.
> 
> Thank you for the clarify again :)
> 
> Will Parking Protocol be upstreamed?

Yes, a version against v8 will be posted (perhaps in the next few days),
but we should not wait for it in this general discussion. The default in
v8 will be PSCI other than for early bringup, or for an architecture
implementation that cannot use PSCI, which is rare.

(When we wrote the SBBR we had many discussions about this. A goal is to
be fair to everyone - those rare instances where PSCI is not possible
must be covered by a specification, but there must be a strong
preference established for a preferred course over the longer term)

> If yes, I think we can update the
> comments when Parking Protocol driver upstreamed.

Indeed so. For the moment, the logic you have in your patch to fail
setup in the case that there is no defined PSCI cpu ops for the
associated processor is fine IMHO.

Jon.

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

[PATCH] ACPI / LPSS: complete PM entries for LPSS power domain

[Fu, Zhonghui]

>From de3dfa34bd7f219586057a1e0679f9e7515fa722 Mon Sep 17 00:00:00 2001
From: Fu Zhonghui 
Date: Tue, 9 Sep 2014 10:54:30 +0800
Subject: [PATCH] ACPI / LPSS: complete PM entries for LPSS power domain

PM entries of LPSS power domain were not implemented correctly
in the patch "ACPI / LPSS: custom power domain for LPSS"
commit ID c78b0830667a7e7c1f0ca65b76b33166a84806b3.
This patch fixes and completes these PM entries.

Signed-off-by: Li Aubrey 
Signed-off-by: Mika Westerberg 
Signed-off-by: Fu Zhonghui 
---
 drivers/acpi/acpi_lpss.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 9dfec48..fddc1e8 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -610,7 +610,7 @@ static int acpi_lpss_suspend_late(struct device *dev)
return acpi_dev_suspend_late(dev);
 }
 
-static int acpi_lpss_restore_early(struct device *dev)
+static int acpi_lpss_resume_early(struct device *dev)
 {
int ret = acpi_dev_resume_early(dev);
 
@@ -650,15 +650,15 @@ static int acpi_lpss_runtime_resume(struct device *dev)
 static struct dev_pm_domain acpi_lpss_pm_domain = {
.ops = {
 #ifdef CONFIG_PM_SLEEP
-   .suspend_late = acpi_lpss_suspend_late,
-   .restore_early = acpi_lpss_restore_early,
.prepare = acpi_subsys_prepare,
.complete = acpi_subsys_complete,
.suspend = acpi_subsys_suspend,
-   .resume_early = acpi_subsys_resume_early,
+   .suspend_late = acpi_lpss_suspend_late,
+   .resume_early = acpi_lpss_resume_early,
.freeze = acpi_subsys_freeze,
.poweroff = acpi_subsys_suspend,
-   .poweroff_late = acpi_subsys_suspend_late,
+   .poweroff_late = acpi_lpss_suspend_late,
+   .restore_early = acpi_lpss_resume_early,
 #endif
 #ifdef CONFIG_PM_RUNTIME
.runtime_suspend = acpi_lpss_runtime_suspend,
-- 1.7.1

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

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

[Anup Chenthamarakshan]

On Mon, Sep 8, 2014 at 10:03 PM, Viresh Kumar  wrote:
> On 9 September 2014 05:40, Anup Chenthamarakshan  wrote:
>> Exported stats appear in
>> /devices/system/cpu/intel_pstate/time_in_state as follows:
>>
>> ## CPU 0
>> 40 3647
>> 50 24342
>> 60 144150
>> 70 202469
>> ## CPU 1
>> 40 4813
>> 50 22628
>> 60 149564
>> 70 211885
>> 80 173890
>>
>> Signed-off-by: Anup Chenthamarakshan 
>> ---
>>  drivers/cpufreq/intel_pstate.c | 77 
>> --
>>  1 file changed, 74 insertions(+), 3 deletions(-)
>
> Why don't we reuse cpufreq_stats.c for all this?

Thanks for taking a look into this.

I had initially tried reusing cpufreq_stats.c to export stats.
Calling cpufreq_stats_update() via the cpufreq notifier added
some amount of overhead while switching frequencies. Specifically,
looking up the index of the new frequency in freq_table_get_index()
is a linear search through all available frequencies (vs a single
subtraction with custom stats export). Also, the notifier mechanism
itself added a level of indirection before calling stats_update.

There is a 5X increase in time taken to complete intel_pstate_set_pstate
while using cpufreq_stats compared to having custom stats exported.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: serport: Add compat_ioctl routine to support 32bit inputattach in 64bit systems

[John Sung]

When running a 32-bit inputattach utility in a 64-bit system, there will be 
error code "inputattach: can't set device type". This is caused by the serport 
device driver not supporting compat_ioctl, so that SPIOCSTYPE ioctl fails.

Changes in v2:
(1) Codes of the compat_ioctl are protected by #ifdef CONFIG_COMPAT.
(2) Add a new function serport_set_type() for common codes used by 
serport_ldisc_ioctl() and serport_ldisc_compat_ioctl().

Signed-off-by: John Sung 
---
 drivers/input/serio/serport.c |   57 +
 1 file changed, 46 insertions(+), 11 deletions(-)

diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c
index 0cb7ef5..1decaa2 100644
--- a/drivers/input/serio/serport.c
+++ b/drivers/input/serio/serport.c
@@ -22,6 +22,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_COMPAT
+#include 
+#endif
+
 MODULE_AUTHOR("Vojtech Pavlik ");
 MODULE_DESCRIPTION("Input device TTY line discipline");
 MODULE_LICENSE("GPL");
@@ -40,6 +44,30 @@ struct serport {
unsigned long flags;
 };
 
+#ifdef CONFIG_COMPAT
+#define SPIOCSTYPE32 (_IOW('q', 0x01, compat_ulong_t))
+#endif
+
+/*
+ * serport_set_type() is called by serport_ldisc_ioctl() and
+ * serport_ldisc_compat_ioctl() to set up the serio_device_id values
+ */
+
+static int serport_set_type(struct tty_struct *tty, unsigned long arg)
+{
+   struct serport *serport = (struct serport *) tty->disc_data;
+   unsigned long type;
+
+   if (get_user(type, (unsigned long __user *) arg))
+   return -EFAULT;
+
+   serport->id.proto = type & 0x00ff;
+   serport->id.id= (type & 0xff00) >> 8;
+   serport->id.extra = (type & 0x00ff) >> 16;
+
+   return 0;
+}
+
 /*
  * Callback functions from the serio code.
  */
@@ -204,18 +232,8 @@ static ssize_t serport_ldisc_read(struct tty_struct * tty, 
struct file * file, u
 
 static int serport_ldisc_ioctl(struct tty_struct * tty, struct file * file, 
unsigned int cmd, unsigned long arg)
 {
-   struct serport *serport = (struct serport*) tty->disc_data;
-   unsigned long type;
-
if (cmd == SPIOCSTYPE) {
-   if (get_user(type, (unsigned long __user *) arg))
-   return -EFAULT;
-
-   serport->id.proto = type & 0x00ff;
-   serport->id.id= (type & 0xff00) >> 8;
-   serport->id.extra = (type & 0x00ff) >> 16;
-
-   return 0;
+   return serport_set_type(tty, arg);
}
 
return -EINVAL;
@@ -232,6 +250,20 @@ static void serport_ldisc_write_wakeup(struct tty_struct * 
tty)
spin_unlock_irqrestore(>lock, flags);
 }
 
+#ifdef CONFIG_COMPAT
+/*
+ * serport_ldisc_compat_ioctl() allows to set the port protocol, and device ID
+ */
+
+static long serport_ldisc_compat_ioctl(struct tty_struct *tty, struct file 
*file, unsigned int cmd, unsigned long arg)
+{
+   if (cmd == SPIOCSTYPE32)
+   return serport_set_type(tty, arg);
+
+   return -EINVAL;
+}
+#endif
+
 /*
  * The line discipline structure.
  */
@@ -243,6 +275,9 @@ static struct tty_ldisc_ops serport_ldisc = {
.close =serport_ldisc_close,
.read = serport_ldisc_read,
.ioctl =serport_ldisc_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl = serport_ldisc_compat_ioctl,
+#endif
.receive_buf =  serport_ldisc_receive,
.write_wakeup = serport_ldisc_write_wakeup
 };
-- 
1.7.9.5

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

Re: [PATCH] f2fs: Fix recover when nid of non-inode dnode < nid of inode

[Jaegeuk Kim]

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.
Rather than this tweak, if iget is failed, we'd better go to next instead of
break.
Can you test that?

> + } else if (IS_INODE(page)) {
> + if (is_dent_dnode(page)) {
>   err = recover_inode_page(sbi, page);
>   if (err)
>   break;
> @@ -193,7 +193,8 @@ static int find_fsync_dnodes(struct f2fs
>   break;
>   }
>   list_add_tail(>list, head);
> - }
> + } else
> + goto next;
>   entry->blkaddr = blkaddr;
>  
>   err = recover_inode(entry->inode, page);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xtensa/uapi: Add definition of TIOC[SG]RS485

[Ricardo Ribalda Delgado]

Commit: e676253b19b2d269cccf67fdb1592120a0cd0676 [3/21] serial/8250: Add
support for RS485 IOCTLs, adds support for RS485 ioctls for 825_core on
all the archs. Unfortunaltely the definition of TIOCSRS485 and
TIOCGRS485 was missing on the ioctls.h file

Reported-by: kbuild test robot 
Signed-off-by: Ricardo Ribalda Delgado 
---
 arch/xtensa/include/uapi/asm/ioctls.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/xtensa/include/uapi/asm/ioctls.h 
b/arch/xtensa/include/uapi/asm/ioctls.h
index a47909f..accda82 100644
--- a/arch/xtensa/include/uapi/asm/ioctls.h
+++ b/arch/xtensa/include/uapi/asm/ioctls.h
@@ -95,6 +95,8 @@
 #define TCSETS2_IOW('T', 43, struct termios2)
 #define TCSETSW2   _IOW('T', 44, struct termios2)
 #define TCSETSF2   _IOW('T', 45, struct termios2)
+#define TIOCGRS485 0x542E
+#define TIOCSRS485 0x542F
 #define TIOCGPTN   _IOR('T',0x30, unsigned int) /* Get Pty Number (of 
pty-mux device) */
 #define TIOCSPTLCK _IOW('T',0x31, int)  /* Lock/unlock Pty */
 #define TIOCGDEV   _IOR('T',0x32, unsigned int) /* Get primary device node 
of /dev/console */
-- 
2.1.0

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

Re: [PATCH] rtc: ds1307: add trickle charger device tree binding

[Matti Vaittinen]

On Mon, Sep 08, 2014 at 03:58:25PM +0100, ext Mark Rutland wrote:
> On Mon, Sep 08, 2014 at 02:52:42PM +0100, Pavel Machek wrote:
> > > I would suggest we have two properties that describe the resistor's
> > > rating and whether or not there is a diode:
> > > 
> > > trickle-resistor-ohms = <250>
> > > diode-connected;
> > > 
> > > That's easy for a human to write and/or validate, we can easily extend
> > > it in future, requires no proliferation of macros, and describes the
> > > hardware rather than telling software what to do.
> > > 
> > > The driver becomes a little more complicated, but gains sanity checking,
> > > which is a good thing.
> > 
> > Certainly looks better than register bit defines.
> > 
> > As rtc-bq32k has similar options, I'm interested, too. I believe we
> > should add
> > 
> > trickle-charge-enable;

I am unsure about this. It makes sense for devices where we cannot
select resistor but just enable or disable charger. Is there any such
devices? For devices like ds1339 this makes no sense. For them it is
simpler to just enable the charger if resistor value is specified, and
default the charger to be off. But I do not see a problem in supporting
the trickle-charge-enable; for devices needing this (independently from
the ds1307 driver).

> > 
> > (we may not want to charge at all), and I believe the diode should be
> > 
> > disconnect-diode;
> > 
> > ... With diode connected, charge is slower, and that probably should
> > be the default value. We don't want to give too much current in
> > default case.  (bq32k has hard-coded resistor value for
> > diode/not-diode case).
> 
> I agree that if one case is less likely to be problematic / damaging
> that should be the default.

_Maybe_ 
diode-connected = <1>; or 
diode-connected = <0>; 
or both
diode-connected; and 
diode-disconnected;
could be used and let the driver to choose the defaults? But yes, I have
no problem with inverting the default to be diode-connected.

Then one question regarding the "process". Now if I cook up fourth patch
with inverted diode-connected default for ds1339, should I collect new
acks for this new patch? (V3 was acked by Alessandro and Jason.) I assume 
yes.

> 
> Mark.

-- 
=

Matti Vaittinen
Senile SW Specialist
FINLAND 

~~ When things go utterly wrong vim users can always type :help! ~~

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

[PATCH 1/2] serial/8250_core: Add reference to uacess.h

[Ricardo Ribalda Delgado]

Commit: e676253b19b2d269cccf67fdb1592120a0cd0676 [3/21] serial/8250: Add
support for RS485 IOCTLs, adds a building error on arch m32r.

All error/warnings:

   drivers/tty/serial/8250/8250_core.c: In function 'serial8250_ioctl':
>> drivers/tty/serial/8250/8250_core.c:2859:3: error: implicit declaration of 
>> function 'copy_from_user' [-Werror=implicit-function-declaration]
  if (copy_from_user(_config, (void __user *)arg,
  ^
>> drivers/tty/serial/8250/8250_core.c:2871:3: error: implicit declaration of 
>> function 'copy_to_user' [-Werror=implicit-function-declaration]
  if (copy_to_user((void __user *)arg, >rs485,
  ^
   cc1: some warnings being treated as errors

Reported-by: kbuild test robot 
Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/tty/serial/8250/8250_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 872c020..a0c1d64 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_SPARC
 #include 
 #endif
-- 
2.1.0

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

Re: [PATCH -v2] f2fs: Remove lock from check_valid_map

[Jaegeuk Kim]

Hi Huang,

On Mon, Sep 08, 2014 at 03:36:35PM +0800, huang ying wrote:
> Hi, Jaegeuk,
> 
> On Mon, Sep 8, 2014 at 11:50 AM, Jaegeuk Kim  wrote:
> 
> > Hi,
> >
> > On Sun, Sep 07, 2014 at 11:38:30AM +0800, Huang Ying wrote:
> > > Only one bit is read in check_valid_map, holding a lock to do that
> > > doesn't help anything except decreasing performance.
> > >
> > > Signed-off-by: Huang, Ying 
> > > ---
> > >
> > > v2: Fixed a build warning.
> > >
> > > ---
> > >  fs/f2fs/gc.c |3 ---
> > >  1 file changed, 3 deletions(-)
> > >
> > > --- a/fs/f2fs/gc.c
> > > +++ b/fs/f2fs/gc.c
> > > @@ -378,14 +378,11 @@ static void put_gc_inode(struct list_hea
> > >  static int check_valid_map(struct f2fs_sb_info *sbi,
> > >   unsigned int segno, int offset)
> > >  {
> > > - struct sit_info *sit_i = SIT_I(sbi);
> > >   struct seg_entry *sentry;
> > >   int ret;
> > >
> > > - mutex_lock(_i->sentry_lock);
> > >   sentry = get_seg_entry(sbi, segno);
> > >   ret = f2fs_test_bit(offset, sentry->cur_valid_map);
> > > - mutex_unlock(_i->sentry_lock);
> > >   return ret;
> >
> > The f2fs_test_bit is not atomic, so I'm not sure this is a good approach.
> > How about introducing rw_semaphore?
> >
> 
> IMO, f2fs_test_bit just read a global variable (a byte in cur_valid_map),
> then check its value. The byte may be changed in another CPU concurrently.
> But even protected with a mutex, it can be changed in another CPU
> immediately after mutex_unlock.  So mutex does not help  here.  Here we
> just read a global variable, not read/modify/write, so, we don't need
> atomic too.

Hmm. This is a pretty hard corner case to allow the mutex removal under the
following assumption.

1. All the sit entries are cached in a global array, which means that it never
happens that any sit entry pointers are changed.

2. I agree that f2fs_gc tries to conduct the cleaning with best effort, and
it triggers again when it detects there is something to do more.
So, check_valid_bitmap doesn't need to make a precise decision.

But, what I concern is the consistent policy to use such the mutex.
If we break the rule, it becomes harder to debug potential bugs.

Anyway, have you been facing with such the lock contention?

Thanks,

> 
> Best Regards,
> Huang, Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/17] ARM64 / ACPI: Parse MADT for SMP initialization

[Hanjun Guo]

On 2014年09月09日 12:29, Jon Masters wrote:
> Hi Hanjun, Lorenzo,

Hi Jon,

>
> Resending due to my mail client removing list CCs...sorry about that.
>
> On 09/04/2014 11:29 AM, Hanjun Guo wrote:
>
 +  } else {
 +  /* Fist GICC entry must be BSP as ACPI spec said */
>>> s/Fist/First/
>>>
 +  if  (cpu_logical_map(0) != mpidr) {
 +  pr_err("First GICC entry is not BSP for MPIDR 0x%llx\n",
 + mpidr);
 +  return -EINVAL;
 +  }
>>> Interesting, this means that if I want to change the boot CPU I have to
>>> recompile the ACPI tables. Is that really true ?
> Well, the ACPI5.1 specification does require that the PEs (cores) be
> listed in a very specific order, with the boot CPU first, and then a
> precisely defined sequence of interleaving of any possible SMT threads
> with other cores. So I think you would in practice update your tables.

Thanks for the clarify.

>
 +  /*
 +   * ACPI 5.1 only has two explicit methods to boot up SMP,
 +   * PSCI and Parking protocol, but the Parking protocol is
 +   * only specified for ARMv7 now, so make PSCI as the only
 +   * way for the SMP boot protocol before some updates for
 +   * the ACPI spec or the Parking protocol spec.
 +   */
> The Parking Protocol may be updated for a (limited) number of platforms
> that may use it in the early days. The preferred option (as described in
> the SBBR) is to use PSCI when at all possible. Some implementations of
> the architecture may not be able to use PSCI for MP-Boot. Thus while
> there may be some limited early use of the parking protocol (including
> while PSCI firmware is being finalized during bringup activities), it
> will ultimately be completely replaced by PSCI based boot over time.

Thank you for the clarify again :)

Will Parking Protocol be upstreamed? If yes, I think we can update the
comments when Parking Protocol driver upstreamed.

Thanks
Hanjun 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/14] input: cyapa: add function to monitor LID close event to off trackpad device

[Benson Leung]

Hi Dudley,


On Fri, Aug 29, 2014 at 4:35 PM, Dudley Du  wrote:
> Add the function to monitor lid close event to suspend and resume
> trackpad device.
> Because system suspend takes some time to trigger from user space,
> and in that time, the lid panel of the laptop may couple with the
> active trackpad. This may generate stray input events, which may
> in turn cancel the suspend if the drivers use pm_wakup_event(), and
> those input events may trigger something unwanted in the UI.
> So this patch adds the function to do off the trackpad device quickly.
> When the lid is closed, as soon as possible, the trakcpad device must
> be off. And furthermore, the policy on lid close is not always to
> enter suspend (lid closed with external display), and at this time,
> the trackpad device must be disabled as well as again to avoid the
> risk of generating stray events.
> TEST=test on Chromebooks.
>
> Signed-off-by: Dudley Du 

So, I think for the chromeos-kernel, we are moving away from this hack
lid filter solution. Very soon we'll remove this in favor of something
else, so my suggestion would be to drop this from your patch series.



-- 
Benson Leung
Software Engineer, Chrome OS
Google Inc.
ble...@google.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: [GIT PULL] EFI urgent fixes

[Ingo Molnar]

* Matt Fleming  wrote:

> Folks,
> 
> Please queue up the following fixes, mainly for regressions introduced
> in the merge window or -rc2.

So the rule for post-rc1 merges is to fix regressions 'only', not 
'mainly'!

> 
> Mark Rustad (1):
>   efi: Resolve some shadow warnings

That's not a critical regression.

> 
> Mark Salter (1):
>   efi/arm64: Fix fdt-related memory reservation

That's a regression fix.

> Mathias Krause (4):
>   x86/efi: Remove unused efi_call* macros
>   x86/efi: Unexport add_efi_memmap variable
>   x86/efi: Update comment regarding required phys mapped EFI services
>   x86/efi: Mark initialization code as such

Neither of these 4 changes is a critical regression!

> Matt Fleming (1):
>   x86/efi: Fixup GOT in all boot code paths

That's a regression fix.

> Yinghai Lu (1):
>   x86/efi: Only load initrd above 4g on second try

This revert is a regression fix too.

So please only put the 3 regression fixes into efi-urgent, the 
rest can go into the v3.18 pile.

Thanks,

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

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

[Viresh Kumar]

On 9 September 2014 05:40, Anup Chenthamarakshan  wrote:
> Exported stats appear in
> /devices/system/cpu/intel_pstate/time_in_state as follows:
>
> ## CPU 0
> 40 3647
> 50 24342
> 60 144150
> 70 202469
> ## CPU 1
> 40 4813
> 50 22628
> 60 149564
> 70 211885
> 80 173890
>
> Signed-off-by: Anup Chenthamarakshan 
> ---
>  drivers/cpufreq/intel_pstate.c | 77 
> --
>  1 file changed, 74 insertions(+), 3 deletions(-)

Why don't we reuse cpufreq_stats.c for all this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL 00/13] perf/core improvements and fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> The following changes since commit 39b5a56ec0be5effe9b7d0f18cb27724bf2e5d47:
> 
>   Merge branch 'rfc/perf' into perf/core, because it's ready for inclusion 
> (2014-08-24 22:35:42 +0200)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo
> 
> for you to fetch changes up to fa3480cb0a96c8af9ded1a8c836c91bd5704bda1:
> 
>   perf tools: Add perf_pmu__scan_file() (2014-09-08 17:16:06 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> User visible:
> 
> o Add +field argument support for --sort option (Jiri Olsa)
> 
> Infrastructure:
> 
> o More intel PT prep work, from Adrian Hunter, including:
> 
>   - Let a user specify a PMU event without any config terms
>   - Add perf-with-kcore script
>   - Build programs to copy 32-bit compatibility VDSOs
>   - Add support for 32-bit compatibility VDSOs
>   - Let default config be defined for a PMU
>   - Add perf_pmu__scan_file()
> 
> o Add feature checks to .gitignore (Alexander Shishkin)
> 
> o "perf kvm stat report" improvements by Alexander Yarygin:
>   o  Save pid string in opts.target.pid
>   o  Enable the target.system_wide flag
>   o  Unify the title bar output
> 
> o Fix build issue on powerpc when DWARF support is disabled (Anton Blanchard)
> 
> o Allow to specify lib compile variable for spec usage (Jiri Olsa)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Adrian Hunter (6):
>   perf tools: Let a user specify a PMU event without any config terms
>   perf tools: Add perf-with-kcore script
>   perf tools: Build programs to copy 32-bit compatibility VDSOs
>   perf tools: Add support for 32-bit compatibility VDSOs
>   perf tools: Let default config be defined for a PMU
>   perf tools: Add perf_pmu__scan_file()
> 
> Alexander Shishkin (1):
>   perf tools: Add feature checks to .gitignore
> 
> Alexander Yarygin (3):
>   perf kvm stat report: Save pid string in opts.target.pid
>   perf kvm stat report: Enable the target.system_wide flag
>   perf kvm stat report: Unify the title bar output
> 
> Anton Blanchard (1):
>   perf tools powerpc: Fix build issue when DWARF support is disabled
> 
> Jiri Olsa (2):
>   perf tools: Add +field argument support for --sort option
>   perf tools: Allow to specify lib compile variable for spec usage
> 
>  tools/perf/.gitignore|   2 +
>  tools/perf/Makefile.perf |  42 ++-
>  tools/perf/arch/powerpc/Makefile |   2 +-
>  tools/perf/builtin-kvm.c |  23 ++--
>  tools/perf/config/Makefile   |  33 -
>  tools/perf/config/Makefile.arch  |   8 ++
>  tools/perf/perf-read-vdso.c  |  59 +
>  tools/perf/perf-with-kcore.sh| 259 
> +++
>  tools/perf/tests/pmu.c   |   2 +-
>  tools/perf/util/kvm-stat.h   |   1 -
>  tools/perf/util/parse-events.c   |  13 +-
>  tools/perf/util/parse-events.y   |  10 ++
>  tools/perf/util/pmu.c|  79 +---
>  tools/perf/util/pmu.h|  12 +-
>  tools/perf/util/sort.c   |  37 +-
>  tools/perf/util/vdso.c   | 170 -
>  tools/perf/util/vdso.h   |   4 +-
>  17 files changed, 712 insertions(+), 44 deletions(-)
>  create mode 100644 tools/perf/perf-read-vdso.c
>  create mode 100644 tools/perf/perf-with-kcore.sh

Hm, so I'm getting this error, when trying to profile a 32-bit 
ELF binary on a 64-bit kernel, on a testbox:

 $ perf record ~/hackbench  10
 Time: 0.115
 [ perf record: Woken up 1 times to write data ]
 [ perf record: Captured and wrote 0.373 MB perf.data (~16279 samples) ]
 sh: perf-read-vdso32: command not found

comet:~/tip> file ~/hackbench 
/home/mingo/hackbench: ELF 32-bit LSB executable, Intel 80386, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

64-bit executables work fine:

 $ perf record perf bench sched pipe
 # Running 'sched/pipe' benchmark:
 # Executed 100 pipe operations between two processes

  Total time: 13.374 [sec]

   13.374352 usecs/op
   74769 ops/sec
 [ perf record: Woken up 14 times to write data ]
 [ perf record: Captured and wrote 3.602 MB perf.data (~157354 samples) ]

The kernel is an older one:

 $ uname -a
 Linux comet 3.14.17-100.fc19.x86_64 #1 SMP Thu Aug 14 17:17:26 
 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Thanks,

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

Re: [PATCH v3 09/17] ARM64 / ACPI: Parse MADT for SMP initialization

[Hanjun Guo]

Hi Jon,

On 2014年09月09日 12:23, Jon Masters wrote:
> On 09/01/2014 10:57 AM, Hanjun Guo wrote:
>> MADT contains the information for MPIDR which is essential for
>> SMP initialization, parse the GIC cpu interface structures to
>> get the MPIDR value and map it to cpu_logical_map(), and add
>> enabled cpu with valid MPIDR into cpu_possible_map.
>>
>> ACPI 5.1 only has two explicit methods to boot up SMP, PSCI and
>> Parking protocol, but the Parking protocol is only specified for
>> ARMv7 now, so make PSCI as the only way for the SMP boot protocol
>> before some updates for the ACPI spec or the Parking protocol spec.
>> +/* CPU 0 was already initialized */
>> +if (cpu) {
>> +if (cpu_ops[cpu]->cpu_init(NULL, cpu))
>> +return -EOPNOTSUPP;
>> +
>> +/* map the logical cpu id to cpu MPIDR */
>> +cpu_logical_map(cpu) = mpidr;
> I'm not sure it's worth noting in a comment or just in the dialogue that
> none of these MPIDR values is literally the value in the MPIDR. Linux
> doesn't store that anyway (even in the cpu_logical_map), since it is
> pre-filtered against MPIDR_HWID_BITMASK to remove the non-affinity level
> bits. And since the ACPI5.1 specification requires that non-affinity
> bits be zero everything works. But it relies upon this assumption so it
> might be worth explicitly masking out the bits when making the call into:
>
>acpi_map_gic_cpu_interface(processor->arm_mpidr,
>processor->flags & ACPI_MADT_ENABLED);
>
> During the parsing of the processor object's MPIDR value.

Yes, I agree with you. When I tested this patch set on our
ARM64 platform, I found this problem too. some firmware
will just present the real MPIDR value to OS which some reserved
bit set to 1, and it will lead to some logic problem in this patch.
(actually firmware didn't obey with ACPI spec)

I had updated the patch with:

+   acpi_map_gic_cpu_interface(processor->arm_mpidr & MPIDR_HWID_BITMASK,
+   processor->flags & ACPI_MADT_ENABLED);

and then the problem was gone :)

Thanks
Hanjun


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

[Viresh Kumar]

On 9 September 2014 06:07, Stephen Boyd  wrote:
>> A module author as well?
>
> How about we use git blame instead?

Not very sure but this information is probably present in the compiled module.
And so can be accessed without the sourcecode as well..

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

[PATCH v2] arm: prevent BUG_ON in audit_syscall_entry()

[AKASHI Takahiro]

BUG_ON() in audit_syscall_entry() will be hit if user issues syscall(-1)
while syscall auditing is enabled (that is, by starting auditd).

[ cut here ]
kernel BUG at /home/akashi/arm/armv7/linux/kernel/auditsc.c:1534!
Internal error: Oops - BUG: 0 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 61 Comm: syscall_arm Not tainted 3.17.0-rc4 #60
task: ea0c4380 ti: ea48e000 task.ti: ea48e000
PC is at __audit_syscall_entry+0xe4/0x110
LR is at 0xea0c4380
pc : []lr : []psr: 2013
sp : ea48ff68  ip : 0001  fp : 869c
r10: 0200  r9 : ea48e000  r8 : c020f4e4
r7 : 00c5  r6 : ea48e000  r5 : ea48ffb0  r4 : ea490800
r3 : bef1e718  r2 : 0001  r1 : 00c5  r0 : 4028
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8a4ac059  DAC: 0015
Process syscall_arm (pid: 61, stack limit = 0xea48e250)
Stack: (0xea48ff68 to 0xea49)
ff60:   540e7a69 3ab5e840 0200 00c5 ea48ffb0 ea48e000
ff80: 00c5 c02114bc bef1e718 0001 b6efdb58  0840 00c5
ffa0: c020f4e4 c020f49c b6efdb58  0001 bef1e718 bef1e718 0001
ffc0: b6efdb58  0840 00c5  b6f22850 0008 869c
ffe0: 00c5 bef1e704 b6ea315f b6e318e6 2030 0001  
[] (__audit_syscall_entry) from [] 
(syscall_trace_enter+0xf0/0x120)
[] (syscall_trace_enter) from [] (__sys_trace+0xc/0x38)
Code: e584500c e5842004 e28dd00c e8bd80f0 (e7f001f2)
---[ end trace 0c4441660aba5692 ]---

In fact, syscall(-1) just fails (not signaled despite the expectation,
this is another minor bug), but the succeeding syscall hits BUG_ON.

When auditing syscall(-1), audit_syscall_entry() is called anyway, but
audit_syscall_exit() is not called and then 'in_syscall' flag in thread's
audit context is kept on. In this way, audit_syscall_entry() against
the succeeding syscall will see BUG_ON(in_syscall).

This patch fixes this bug by
1) preventing syscall tracing, ftrace tracepoint and audit, from being
   executed in case of invalid or pseudo system calls,
2) handling user-issued syscall(-1) with arm_syscall().

Signed-off-by: AKASHI Takahiro 
---
 arch/arm/include/asm/traps.h   |1 +
 arch/arm/kernel/entry-common.S |4 ++--
 arch/arm/kernel/ptrace.c   |   47 +---
 3 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/arch/arm/include/asm/traps.h b/arch/arm/include/asm/traps.h
index f555bb3..de01145 100644
--- a/arch/arm/include/asm/traps.h
+++ b/arch/arm/include/asm/traps.h
@@ -49,6 +49,7 @@ static inline int in_exception_text(unsigned long ptr)
 extern void __init early_trap_init(void *);
 extern void dump_backtrace_entry(unsigned long where, unsigned long from, 
unsigned long frame);
 extern void ptrace_break(struct task_struct *tsk, struct pt_regs *regs);
+extern int arm_syscall(int no, struct pt_regs *regs);
 
 extern void *vectors_page;
 
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index e52fe5a..28d3931 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -426,7 +426,6 @@ ENTRY(vector_swi)
 local_restart:
ldr r10, [tsk, #TI_FLAGS]   @ check for syscall tracing
stmdb   sp!, {r4, r5}   @ push fifth and sixth args
-
tst r10, #_TIF_SYSCALL_WORK @ are we tracing syscalls?
bne __sys_trace
 
@@ -476,10 +475,11 @@ __sys_trace:
cmp scno, #-1   @ skip the syscall?
bne 2b
add sp, sp, #S_OFF  @ restore stack
-   b   ret_slow_syscall
+   b   __sys_trace_return_skipped
 
 __sys_trace_return:
str r0, [sp, #S_R0 + S_OFF]!@ save returned r0
+__sys_trace_return_skipped:
mov r0, sp
bl  syscall_trace_exit
b   ret_slow_syscall
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index 0c27ed6..68b42cd 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -930,7 +930,9 @@ static void tracehook_report_syscall(struct pt_regs *regs,
 
 asmlinkage int syscall_trace_enter(struct pt_regs *regs, int scno)
 {
-   current_thread_info()->syscall = scno;
+   int orig_scno;
+
+   current_thread_info()->syscall = orig_scno = scno;
 
/* Do the secure computing check first; failures should be fast. */
if (secure_computing(scno) == -1)
@@ -941,31 +943,40 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs, 
int scno)
 
scno = current_thread_info()->syscall;
 
-   if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
-   trace_sys_enter(regs, scno);
+   if (scno >= 0 && scno < NR_syscalls) {
+   if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
+   trace_sys_enter(regs, scno);
+
+   audit_syscall_entry(AUDIT_ARCH_ARM, scno,
+   regs->ARM_r0, 

Re: [PATCH] arm: prevent BUG_ON in audit_syscall_entry()

[AKASHI Takahiro]

Russell,

On 09/05/2014 06:52 PM, Russell King - ARM Linux wrote:

On Fri, Sep 05, 2014 at 06:46:33PM +0900, AKASHI Takahiro wrote:

BUG_ON() in audit_syscall_entry() will be hit if user issues syscall(-1)
while syscall auditing is enabled (that is, by starting auditd).
In fact, syscall(-1) just fails (not signaled despite the expectation,
this is another minor bug), but the succeeding syscall hits BUG_ON.

When auditing syscall(-1), audit_syscall_entry() is called anyway, but
audit_syscall_exit() is not called and then 'in_syscall' flag in thread's
audit context is kept on. In this way, audit_syscall_entry() against
the succeeding syscall will see BUG_ON(in_syscall).

This patch fixes this bug by
1) enforcing syscall exit tracing, including audit_syscall_exit(), to be
executed in all cases,


Really, no.  That adds additional overhead to every syscall, and that
matters for system performance.  We want to have as little as possible
overhead here.


My words might have confused you, but this issue exists, in the current
mainline kernel, not only against syscall(-1), but any invalid or pseudo 
syscalls.
(And other archs seem to behave in the same way AFAIK.)
But if you want, I can fix it.
See my next version.

-Takahiro AKASHI


The second issue here is that you haven't explained where the oops
occurs.  It's seen as a good practice to include the oops dump for the
bug you're fixing in the commit changelog, so that others can see the
starting point for the investigation, and see exactly where things are
going wrong.


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

[Jaegeuk Kim]

Hi Tommi,

This patch should resolve this bug.
Thanks a lot. :)

>From ee24677b9917583f50f16b6f59771439f91b890c Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Mon, 8 Sep 2014 10:59:43 -0700
Subject: [PATCH] f2fs: fix negative value for lseek offset

If application throws negative value of lseek with SEEK_DATA|SEEK_HOLE,
previous f2fs went into BUG_ON in get_dnode_of_data, which was reported
by Tommi Rantala.

He could make a simple code to detect this having:
lseek(fd, -17595150933902LL, SEEK_DATA);

This patch should resolve that bug.

Reported-by: Tommi Rentala 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 9f0ea3d..c9a1295 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -281,7 +281,7 @@ static loff_t f2fs_seek_block(struct file *file, loff_t 
offset, int whence)
mutex_lock(>i_mutex);
 
isize = i_size_read(inode);
-   if (offset >= isize)
+   if (offset >= isize || offset < 0)
goto fail;
 
/* handle inline data case */
-- 
1.8.5.2 (Apple Git-48)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/17] ARM64 / ACPI: Parse MADT for SMP initialization

[Jon Masters]

Hi Hanjun, Lorenzo,

Resending due to my mail client removing list CCs...sorry about that.

On 09/04/2014 11:29 AM, Hanjun Guo wrote:

>>> +   } else {
>>> +   /* Fist GICC entry must be BSP as ACPI spec said */
>> s/Fist/First/
>>
>>> +   if  (cpu_logical_map(0) != mpidr) {
>>> +   pr_err("First GICC entry is not BSP for MPIDR 0x%llx\n",
>>> +  mpidr);
>>> +   return -EINVAL;
>>> +   }
>> Interesting, this means that if I want to change the boot CPU I have to
>> recompile the ACPI tables. Is that really true ?

Well, the ACPI5.1 specification does require that the PEs (cores) be
listed in a very specific order, with the boot CPU first, and then a
precisely defined sequence of interleaving of any possible SMT threads
with other cores. So I think you would in practice update your tables.

>>> +   /*
>>> +* ACPI 5.1 only has two explicit methods to boot up SMP,
>>> +* PSCI and Parking protocol, but the Parking protocol is
>>> +* only specified for ARMv7 now, so make PSCI as the only
>>> +* way for the SMP boot protocol before some updates for
>>> +* the ACPI spec or the Parking protocol spec.
>>> +*/

The Parking Protocol may be updated for a (limited) number of platforms
that may use it in the early days. The preferred option (as described in
the SBBR) is to use PSCI when at all possible. Some implementations of
the architecture may not be able to use PSCI for MP-Boot. Thus while
there may be some limited early use of the parking protocol (including
while PSCI firmware is being finalized during bringup activities), it
will ultimately be completely replaced by PSCI based boot over time.

Jon.

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

[H. Peter Anvin]

Add a short member for proper alignment and one will probably pop out.

Sent from my tablet, pardon any formatting problems.

> On Sep 8, 2014, at 19:56, 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:
 Two things: I think that gcc has given up on combining adjacent writes,
 perhaps because unaligned writes on some arches are prohibitive, so
 whatever minor optimization was believed to be gained was quickly lost,
 multi-fold. (Although this might not be the reason since one would
 expect that gcc would know the alignment of the promoted store).
>>> 
>>> Um, gcc assumes architecturally correct alignment; that's why it pads
>>> structures.  Only when accessing packed structures will it use the
>>> lowest unit load/store.
>>> 
>>> if you have a struct { char a, char b }; and load first a then b with a
>>> constant gcc will obligingly optimise to a short store.
>> 
>> Um, please re-look at the test above. The exact test you describe is
>> coded above and compiled with gcc 4.6.3 cross-compiler for parisc using
>> the kernel compiler options.
>> 
>> In the generated code, please note the _absence_ of a combined write
>> to two adjacent byte stores.
> 
> So one version of gcc doesn't do it.  Others do because I've been
> surprised seeing it in assembly.
> 
 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.
> 
 I see no problem with gcc write-combining in the absence of
 memory barriers (as long as alignment is still respected,
 ie., the size-promoted write is still naturally aligned). The
 combined write is still atomic.
>>> 
>>> Actual alignment is pretty irrelevant.  That's why all architectures
>>> which require alignment also have to implement misaligned traps ... this
>>> is a fundamental requirement of the networking code, for instance.
>>> 
>>> The main problem is gcc thinking there's a misalignment (or a packed
>>> structure).  That causes splitting of loads and stores and that destroys
>>> atomicity.
>> 
>> Yeah, the extra requirement I added is basically nonsense, since the
>> only issue is what instructions the compiler is emitting. So if compiler
>> thinks the alignment is natural and combines the writes -- ok. If the
>> compiler thinks the alignment is off and doesn't combine the writes --
>> also ok.
> 
> Yes, I think I can agree that the only real problem is gcc thinking the
> store or load needs splitting.
> 
> James
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH v3 09/17] ARM64 / ACPI: Parse MADT for SMP initialization

[Jon Masters]

On 09/01/2014 10:57 AM, Hanjun Guo wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map.
> 
> ACPI 5.1 only has two explicit methods to boot up SMP, PSCI and
> Parking protocol, but the Parking protocol is only specified for
> ARMv7 now, so make PSCI as the only way for the SMP boot protocol
> before some updates for the ACPI spec or the Parking protocol spec.

> + /* CPU 0 was already initialized */
> + if (cpu) {
> + if (cpu_ops[cpu]->cpu_init(NULL, cpu))
> + return -EOPNOTSUPP;
> +
> + /* map the logical cpu id to cpu MPIDR */
> + cpu_logical_map(cpu) = mpidr;

I'm not sure it's worth noting in a comment or just in the dialogue that
none of these MPIDR values is literally the value in the MPIDR. Linux
doesn't store that anyway (even in the cpu_logical_map), since it is
pre-filtered against MPIDR_HWID_BITMASK to remove the non-affinity level
bits. And since the ACPI5.1 specification requires that non-affinity
bits be zero everything works. But it relies upon this assumption so it
might be worth explicitly masking out the bits when making the call into:

   acpi_map_gic_cpu_interface(processor->arm_mpidr,
   processor->flags & ACPI_MADT_ENABLED);

During the parsing of the processor object's MPIDR value.

Jon.

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

[PATCH 5/5] extcon: gpio: Add support for using cable names

[George Cherian]

Add support for using cable names. Enables other drivers to register interest
and get notified using extcon provided notifier call backs.

Signed-off-by: George Cherian 
---
 Documentation/devicetree/bindings/extcon/extcon-gpio.txt | 2 ++
 drivers/extcon/extcon-gpio.c | 4 
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
index 30aa2e1..2c9d29f 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -7,6 +7,7 @@ Required Properties:
  - compatible: should be:
* "linux,extcon-gpio"
  - gpios: specifies the gpio pin used.
+ - cable-name: Name of the cable used.
 
 Optional Properties:
  - debounce: Debounce time for GPIO IRQ in ms
@@ -18,4 +19,5 @@ Eg:
compatible = "linux,extcon-gpio";
gpios = < 12 GPIO_ACTIVE_HIGH>;
debounce = <20>;
+   cable-name = "USB-HOST";
};
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 3839749..c0ab8e7 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -42,6 +42,7 @@ struct gpio_extcon_data {
struct delayed_work work;
unsigned long debounce_jiffies;
bool check_on_resume;
+   const char *cable_name[1];
 };
 
 static void gpio_extcon_work(struct work_struct *work)
@@ -111,6 +112,9 @@ static int gpio_extcon_probe(struct platform_device *pdev)
of_property_read_u32(np, "debounce", );
irq = gpiod_to_irq(extcon_data->gpiod);
irq_flags = irq_get_trigger_type(irq);
+   of_property_read_string_index(np, "cable-name", 0,
+ extcon_data->cable_name);
+   extcon_data->edev->supported_cable = extcon_data->cable_name;
} else {
if (!pdata)
return -EBUSY;
-- 
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 2/5] extcon: gpio: Convert the driver to use gpio desc API's

[George Cherian]

Convert the driver to use gpiod_* API's.

Signed-off-by: George Cherian 
---
 drivers/extcon/extcon-gpio.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 72f19a3..25269f6 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -33,8 +33,7 @@
 
 struct gpio_extcon_data {
struct extcon_dev *edev;
-   unsigned gpio;
-   bool gpio_active_low;
+   struct gpio_desc *gpiod;
const char *state_on;
const char *state_off;
int irq;
@@ -50,9 +49,7 @@ static void gpio_extcon_work(struct work_struct *work)
container_of(to_delayed_work(work), struct gpio_extcon_data,
 work);
 
-   state = gpio_get_value(data->gpio);
-   if (data->gpio_active_low)
-   state = !state;
+   state = gpiod_get_value(data->gpiod);
extcon_set_state(data->edev, state);
 }
 
@@ -106,22 +103,21 @@ static int gpio_extcon_probe(struct platform_device *pdev)
}
extcon_data->edev->name = pdata->name;
 
-   extcon_data->gpio = pdata->gpio;
-   extcon_data->gpio_active_low = pdata->gpio_active_low;
+   extcon_data->gpiod = gpio_to_desc(pdata->gpio);
extcon_data->state_on = pdata->state_on;
extcon_data->state_off = pdata->state_off;
extcon_data->check_on_resume = pdata->check_on_resume;
if (pdata->state_on && pdata->state_off)
extcon_data->edev->print_state = extcon_gpio_print_state;
 
-   ret = devm_gpio_request_one(>dev, extcon_data->gpio, GPIOF_DIR_IN,
+   ret = devm_gpio_request_one(>dev, pdata->gpio, GPIOF_DIR_IN,
pdev->name);
if (ret < 0)
return ret;
 
if (pdata->debounce) {
-   ret = gpio_set_debounce(extcon_data->gpio,
-   pdata->debounce * 1000);
+   ret = gpiod_set_debounce(extcon_data->gpiod,
+pdata->debounce * 1000);
if (ret < 0)
extcon_data->debounce_jiffies =
msecs_to_jiffies(pdata->debounce);
@@ -133,7 +129,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
 
INIT_DELAYED_WORK(_data->work, gpio_extcon_work);
 
-   extcon_data->irq = gpio_to_irq(extcon_data->gpio);
+   extcon_data->irq = gpiod_to_irq(extcon_data->gpiod);
if (extcon_data->irq < 0)
return extcon_data->irq;
 
-- 
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 3/5] extcon: gpio: Add dt support for the driver.

[George Cherian]

Add device tree support to extcon-gpio driver.
Add devicetree binding documentation

Signed-off-by: George Cherian 
---
 .../devicetree/bindings/extcon/extcon-gpio.txt | 21 +++
 drivers/extcon/extcon-gpio.c   | 70 +++---
 2 files changed, 69 insertions(+), 22 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
new file mode 100644
index 000..30aa2e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -0,0 +1,21 @@
+GPIO based EXTCON
+
+EXTCON GPIO
+---
+
+Required Properties:
+ - compatible: should be:
+   * "linux,extcon-gpio"
+ - gpios: specifies the gpio pin used.
+
+Optional Properties:
+ - debounce: Debounce time for GPIO IRQ in ms
+
+
+Eg:
+
+   extcon1: am43_usbid_extcon1 {
+   compatible = "linux,extcon-gpio";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   debounce = <20>;
+   };
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 25269f6..2bfbd2e 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -25,8 +25,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -80,16 +82,12 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev 
*edev, char *buf)
 
 static int gpio_extcon_probe(struct platform_device *pdev)
 {
+   struct device_node *np = pdev->dev.of_node;
struct gpio_extcon_platform_data *pdata = dev_get_platdata(>dev);
struct gpio_extcon_data *extcon_data;
int ret;
-
-   if (!pdata)
-   return -EBUSY;
-   if (!pdata->irq_flags) {
-   dev_err(>dev, "IRQ flag is not specified.\n");
-   return -EINVAL;
-   }
+   unsigned int irq_flags;
+   unsigned int debounce = 0;
 
extcon_data = devm_kzalloc(>dev, sizeof(struct gpio_extcon_data),
   GFP_KERNEL);
@@ -101,26 +99,48 @@ static int gpio_extcon_probe(struct platform_device *pdev)
dev_err(>dev, "failed to allocate extcon device\n");
return -ENOMEM;
}
-   extcon_data->edev->name = pdata->name;
 
-   extcon_data->gpiod = gpio_to_desc(pdata->gpio);
-   extcon_data->state_on = pdata->state_on;
-   extcon_data->state_off = pdata->state_off;
-   extcon_data->check_on_resume = pdata->check_on_resume;
-   if (pdata->state_on && pdata->state_off)
-   extcon_data->edev->print_state = extcon_gpio_print_state;
+   if (np) {
+   int irq;
+
+   extcon_data->gpiod = gpiod_get(>dev, NULL);
+   if (IS_ERR(extcon_data->gpiod))
+   return PTR_ERR(extcon_data->gpiod);
+
+   extcon_data->edev->name = np->name;
+   of_property_read_u32(np, "debounce", );
+   irq = gpiod_to_irq(extcon_data->gpiod);
+   irq_flags = irq_get_trigger_type(irq);
+   } else {
+   if (!pdata)
+   return -EBUSY;
+   if (!pdata->irq_flags) {
+   dev_err(>dev, "IRQ flag is not specified.\n");
+   return -EINVAL;
+   }
+   extcon_data->edev->name = pdata->name;
+   extcon_data->state_on = pdata->state_on;
+   extcon_data->state_off = pdata->state_off;
+   extcon_data->check_on_resume = pdata->check_on_resume;
+   if (pdata->state_on && pdata->state_off)
+   extcon_data->edev->print_state = 
extcon_gpio_print_state;
+
+   extcon_data->gpiod = gpio_to_desc(pdata->gpio);
+   ret = devm_gpio_request_one(>dev, pdata->gpio,
+   GPIOF_DIR_IN, pdev->name);
+   if (ret < 0)
+   return ret;
+   irq_flags = pdata->irq_flags;
+   debounce = pdata->debounce;
+   }
 
-   ret = devm_gpio_request_one(>dev, pdata->gpio, GPIOF_DIR_IN,
-   pdev->name);
-   if (ret < 0)
-   return ret;
 
-   if (pdata->debounce) {
+   if (debounce) {
ret = gpiod_set_debounce(extcon_data->gpiod,
-pdata->debounce * 1000);
+debounce * 1000);
if (ret < 0)
extcon_data->debounce_jiffies =
-   msecs_to_jiffies(pdata->debounce);
+   msecs_to_jiffies(debounce);
}
 
ret = devm_extcon_dev_register(>dev, extcon_data->edev);
@@ -134,7 +154,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
return extcon_data->irq;
 
ret = 

[PATCH 4/5] extcon: gpio: Always use gpio_get_value_cansleep

[George Cherian]

Some gpio's can sleep while reading, so always use gpio_get_value_cansleep
to get data. This fixes warning from gpiolib due to wrong API usage.

Signed-off-by: George Cherian 
---
 drivers/extcon/extcon-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 2bfbd2e..3839749 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -51,7 +51,7 @@ static void gpio_extcon_work(struct work_struct *work)
container_of(to_delayed_work(work), struct gpio_extcon_data,
 work);
 
-   state = gpiod_get_value(data->gpiod);
+   state = gpiod_get_value_cansleep(data->gpiod);
extcon_set_state(data->edev, state);
 }
 
-- 
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] staging:r8190_rtl8256: coding style: Fixed commenting style

[Sharma, Sanjeev]

-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org] 
Sent: Sunday, August 31, 2014 2:28 AM
To: Sharma, Sanjeev
Cc: de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging:r8190_rtl8256: coding style: Fixed commenting style

On Mon, Aug 25, 2014 at 12:55:27PM +0530, Sanjeev Sharma wrote:
> This is a patch to the r8190_rtl8256.c file that fixes commenting 
> style Error
> 
> Signed-off-by: Sanjeev Sharma 
> ---
>  drivers/staging/rtl8192u/r8190_rtl8256.c | 59 
> +---
>  1 file changed, 31 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/r8190_rtl8256.c 
> b/drivers/staging/rtl8192u/r8190_rtl8256.c
> index 43ed768..8fe35ad 100644
> --- a/drivers/staging/rtl8192u/r8190_rtl8256.c
> +++ b/drivers/staging/rtl8192u/r8190_rtl8256.c
> @@ -61,13 +61,15 @@ void PHY_SetRF8256Bandwidth(struct net_device *dev , 
> HT_CHANNEL_WIDTH Bandwidth)
>   break;
>   case HT_CHANNEL_WIDTH_20_40:
>   if (priv->card_8192_version == VERSION_819xU_A 
> || priv->card_8192_version == VERSION_819xU_B) { /* 8256 D-cut, E-cut, xiong: 
> consider it later! */
> - rtl8192_phy_SetRFReg(dev, 
> (RF90_RADIO_PATH_E)eRFPath, 0x0b, bMask12Bits, 0x300); //phy para:3ba
> + rtl8192_phy_SetRFReg(dev, 
> (RF90_RADIO_PATH_E)eRFPath, 0x0b, 
> +bMask12Bits, 0x300); /* phy para:3ba */
>   rtl8192_phy_SetRFReg(dev, 
> (RF90_RADIO_PATH_E)eRFPath, 0x2c, bMask12Bits, 0x3df);
>   rtl8192_phy_SetRFReg(dev, 
> (RF90_RADIO_PATH_E)eRFPath, 0x0e, 
> bMask12Bits, 0x0a1);
>  
> - //cosa add for sd3's request 01/23/2008
> + /* cosa add for sd3's request 01/23/2008
> +  *
> +  */
>   if (priv->chan == 3 || priv->chan == 9)
> - //I need to set priv->chan 
> whenever current channel changes
> + /* I need to set priv->chan 
> whenever current channel changes */
>   rtl8192_phy_SetRFReg(dev, 
> (RF90_RADIO_PATH_E)eRFPath, 0x14, bMask12Bits, 0x59b);
>   else
>   rtl8192_phy_SetRFReg(dev, 
> (RF90_RADIO_PATH_E)eRFPath, 0x14, 
> bMask12Bits, 0x5ab); @@ -91,11 +93,12 @@ void 
> PHY_SetRF8256Bandwidth(struct net_device *dev , HT_CHANNEL_WIDTH 
> Bandwidth)  void PHY_RF8256_Config(struct net_device *dev)  {
>   struct r8192_priv *priv = ieee80211_priv(dev);
> - // Initialize general global value
> - //
> - // TODO: Extend RF_PATH_C and RF_PATH_D in the future
> + /* Initialize general global value
> +  *
> +  * TODO: Extend RF_PATH_C and RF_PATH_D in the future
> +  */
>   priv->NumTotalRFPath = RTL819X_TOTAL_RF_PATH;
> - // Config BB and RF
> + /* Config BB and RF */
>   phy_RF8256_Config_ParaFile(dev);
>  }
>  
> /*
> -- @@ -107,10 +110,11 @@ void PHY_RF8256_Config(struct net_device 
> *dev)  void phy_RF8256_Config_ParaFile(struct net_device *dev)  {
>   u32 u4RegValue = 0;
> - //static s1Byte szRadioAFile[] = 
> RTL819X_PHY_RADIO_A;
> - //static s1Byte szRadioBFile[] = 
> RTL819X_PHY_RADIO_B;
> - //static s1Byte szRadioCFile[] = 
> RTL819X_PHY_RADIO_C;
> - //static s1Byte szRadioDFile[] = 
> RTL819X_PHY_RADIO_D;
> + /* static s1ByteszRadioAFile[] = 
> RTL819X_PHY_RADIO_A;
> +  * static s1ByteszRadioBFile[] = 
> RTL819X_PHY_RADIO_B;
> +  * static s1ByteszRadioCFile[] = 
> RTL819X_PHY_RADIO_C;
> +  * static s1ByteszRadioDFile[] = 
> RTL819X_PHY_RADIO_D;
> +  */

Why not just remove stuff like this if it's not being used?

Same goes for other commented out code lines.

thanks,

greg k-h

Hi greg

submitted patch after removal of unwanted code 

thanks,

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/

[PATCH 0/5] Add dt support for extcon gpio driver

[George Cherian]

This series
- Convert extcon-gpio driver to use gpiod_* API's
- Adds dt support to extcon-gpio driver.
- Add cable name support in case of dt.

George Cherian (5):
  extcon: gpio: Minor cleanups
  extcon: gpio: Convert the driver to use gpio desc API's
  extcon: gpio: Add dt support for the driver.
  extcon: gpio: Always use  gpio_get_value_cansleep
  extcon: gpio: Add support for using cable names

 .../devicetree/bindings/extcon/extcon-gpio.txt |  23 +
 drivers/extcon/extcon-gpio.c   | 100 +
 include/linux/extcon/extcon-gpio.h |   4 +-
 3 files changed, 89 insertions(+), 38 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt

-- 
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 1/5] extcon: gpio: Minor cleanups

[George Cherian]

Minor Cleanups
 - Order the include files in alphabetical order.
 - Fix description of state_off in extcon_gpio.h
 - Add a descrition for check_on_resume in extcon_gpio.h

Signed-off-by: George Cherian 
---
 drivers/extcon/extcon-gpio.c   | 10 +-
 include/linux/extcon/extcon-gpio.h |  4 +++-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 5b7ec27..72f19a3 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -20,16 +20,16 @@
  *
 */
 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 struct gpio_extcon_data {
struct extcon_dev *edev;
diff --git a/include/linux/extcon/extcon-gpio.h 
b/include/linux/extcon/extcon-gpio.h
index 8900fdf..0b17ad4 100644
--- a/include/linux/extcon/extcon-gpio.h
+++ b/include/linux/extcon/extcon-gpio.h
@@ -34,8 +34,10 @@
  * @irq_flags: IRQ Flags (e.g., IRQF_TRIGGER_LOW).
  * @state_on:  print_state is overriden with state_on if attached.
  * If NULL, default method of extcon class is used.
- * @state_off: print_state is overriden with state_on if detached.
+ * @state_off: print_state is overriden with state_off if detached.
  * If NUll, default method of extcon class is used.
+ * @check_on_resume:   Boolean describing whether to check the state of gpio
+ * while resuming from sleep.
  *
  * Note that in order for state_on or state_off to be valid, both state_on
  * and state_off should be not NULL. If at least one of them is NULL,
-- 
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 v2] staging:r8190_rtl8256: coding style: Fixed commenting style

[Sanjeev Sharma]

This is a patch to the r8190_rtl8256.c file that fixes
commenting style Error

Signed-off-by: Sanjeev Sharma 
---
Changes in v2:
  - removed stuff which is not being used ad per greg comment

 drivers/staging/rtl8192u/r8190_rtl8256.c | 52 +---
 1 file changed, 21 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8190_rtl8256.c 
b/drivers/staging/rtl8192u/r8190_rtl8256.c
index 43ed768..45514aa 100644
--- a/drivers/staging/rtl8192u/r8190_rtl8256.c
+++ b/drivers/staging/rtl8192u/r8190_rtl8256.c
@@ -49,9 +49,6 @@ void PHY_SetRF8256Bandwidth(struct net_device *dev , 
HT_CHANNEL_WIDTH Bandwidth)
rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath,
0x0e, bMask12Bits, 0x021);
-
-   /* cosa add for sd3's request 01/23/2008
-*/
rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath,
0x14, bMask12Bits, 0x5ab);
@@ -61,13 +58,12 @@ void PHY_SetRF8256Bandwidth(struct net_device *dev , 
HT_CHANNEL_WIDTH Bandwidth)
break;
case HT_CHANNEL_WIDTH_20_40:
if (priv->card_8192_version == VERSION_819xU_A 
|| priv->card_8192_version == VERSION_819xU_B) { /* 8256 D-cut, E-cut, xiong: 
consider it later! */
-   rtl8192_phy_SetRFReg(dev, 
(RF90_RADIO_PATH_E)eRFPath, 0x0b, bMask12Bits, 0x300); //phy para:3ba
+   rtl8192_phy_SetRFReg(dev, 
(RF90_RADIO_PATH_E)eRFPath, 0x0b, bMask12Bits, 0x300); /* phy para:3ba */
rtl8192_phy_SetRFReg(dev, 
(RF90_RADIO_PATH_E)eRFPath, 0x2c, bMask12Bits, 0x3df);
rtl8192_phy_SetRFReg(dev, 
(RF90_RADIO_PATH_E)eRFPath, 0x0e, bMask12Bits, 0x0a1);
 
-   //cosa add for sd3's request 01/23/2008
if (priv->chan == 3 || priv->chan == 9)
-   //I need to set priv->chan 
whenever current channel changes
+   /* I need to set priv->chan 
whenever current channel changes */
rtl8192_phy_SetRFReg(dev, 
(RF90_RADIO_PATH_E)eRFPath, 0x14, bMask12Bits, 0x59b);
else
rtl8192_phy_SetRFReg(dev, 
(RF90_RADIO_PATH_E)eRFPath, 0x14, bMask12Bits, 0x5ab);
@@ -91,11 +87,12 @@ void PHY_SetRF8256Bandwidth(struct net_device *dev , 
HT_CHANNEL_WIDTH Bandwidth)
 void PHY_RF8256_Config(struct net_device *dev)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
-   // Initialize general global value
-   //
-   // TODO: Extend RF_PATH_C and RF_PATH_D in the future
+   /* Initialize general global value
+*
+* TODO: Extend RF_PATH_C and RF_PATH_D in the future
+*/
priv->NumTotalRFPath = RTL819X_TOTAL_RF_PATH;
-   // Config BB and RF
+   /* Config BB and RF */
phy_RF8256_Config_ParaFile(dev);
 }
 /*--
@@ -107,10 +104,6 @@ void PHY_RF8256_Config(struct net_device *dev)
 void phy_RF8256_Config_ParaFile(struct net_device *dev)
 {
u32 u4RegValue = 0;
-   //static s1Byte szRadioAFile[] = 
RTL819X_PHY_RADIO_A;
-   //static s1Byte szRadioBFile[] = 
RTL819X_PHY_RADIO_B;
-   //static s1Byte szRadioCFile[] = 
RTL819X_PHY_RADIO_C;
-   //static s1Byte szRadioDFile[] = 
RTL819X_PHY_RADIO_D;
u8  eRFPath;
BB_REGISTER_DEFINITION_T*pPhyReg;
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -119,19 +112,17 @@ void phy_RF8256_Config_ParaFile(struct net_device *dev)
u32 RF3_Final_Value = 0;
u8  ConstRetryTimes = 5, RetryTimes = 5;
u8 ret = 0;
-   //3//-
-   //3// <2> Initialize RF
-   //3//-
+   /* Initialize RF */
for (eRFPath = (RF90_RADIO_PATH_E)RF90_PATH_A; eRFPath < 
priv->NumTotalRFPath; eRFPath++) {
if (!rtl8192_phy_CheckIsLegalRFPath(dev, eRFPath))
continue;
 
pPhyReg = >PHYRegDef[eRFPath];
 
-   // Joseph test for shorten RF config
-   //  pHalData->RfReg0Value[eRFPath] =  rtl8192_phy_QueryRFReg(dev, 
(RF90_RADIO_PATH_E)eRFPath, rGlobalCtrl, bMaskDWord);
-
-   /*Store original 

Re: PFUZE100 regulator not going off when PWRON is 0

[Robin Gong]

Thanks for Mark's forward.

Hi Jean-Michel,
  Yes, SWxOMODE can be set as 1 to active sleep mode if PWRON turn-off event
occurs. And the voltage of sleep mode can be set in other register SWxOFF. But
by default, SWxOMODE is 0 which means all SW will be turned off while PWRON go
form 1 to 0. For your issue, I hope you check the hardware design, and measure
PWRON pin to see whether it has been pulled low once your push reset key.

On Wed, Sep 03, 2014 at 01:52:48PM +0100, Mark Brown wrote:
> On Wed, Sep 03, 2014 at 11:44:22AM +0200, Jean-Michel Hautbois wrote:
> 
> > I have a custom i.MX6 based board, but PMIC part is exactly the same
> > as the Freescale SabreSD board.
> > I have a reset button, which makes the PWRON signal on PFUZE100 go from 1 
> > to 0.
> > I thought this would reset the chip, and thus all voltages would go to
> > 0, but this is not the case. It seems that SWxOMODE registers are
> > involved in this process, accorgind to the datasheet, but I don't
> > think this is implemented right now.
> > 
> > I also removed regulator-always-on for my SW2 pin in order to get it
> > off, but this has no effect.
> 
> You should really contact someone who worked on the driver or Freescale
> about this - I don't think anyone on the CC list knows anything about
> the part.  In general if you're asking about a specific driver this is a
> good approach.  I've CCed Robin Gong who was the original author.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: add guard macro of unistd.h to prevent double inclusion

[Yang Yingliang]

Add guard macros in both uapi/asm/unistd.h and asm/unistd.h.

Signed-off-by: Yang Yingliang 
---
 arch/arm64/include/asm/unistd.h  | 5 +
 arch/arm64/include/uapi/asm/unistd.h | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index 6d2bf41..21a7dec 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -13,6 +13,9 @@
  * You should have received a copy of the GNU General Public License
  * along with this program.  If not, see .
  */
+#ifndef __ASM_ARM64_UNISTD_H
+#define __ASM_ARM64_UNISTD_H
+
 #ifdef CONFIG_COMPAT
 #define __ARCH_WANT_COMPAT_SYS_GETDENTS64
 #define __ARCH_WANT_COMPAT_STAT64
@@ -48,3 +51,5 @@
 #include 
 
 #define NR_syscalls (__NR_syscalls)
+
+#endif /* __ASM_ARM64_UNISTD_H */
diff --git a/arch/arm64/include/uapi/asm/unistd.h 
b/arch/arm64/include/uapi/asm/unistd.h
index 1caadc2..ab72cac 100644
--- a/arch/arm64/include/uapi/asm/unistd.h
+++ b/arch/arm64/include/uapi/asm/unistd.h
@@ -13,4 +13,9 @@
  * You should have received a copy of the GNU General Public License
  * along with this program.  If not, see .
  */
+#ifndef _UAPI__ASM_ARM64_UNISTD_H
+#define _UAPI__ASM_ARM64_UNISTD_H
+
 #include 
+
+#endif /* _UAPI__ASM_ARM64_UNISTD_H */
-- 
1.8.0


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

RE: [PATCH v2 0/5] Add max77802 support for Peach boards

[kgene]

Javier Martinez Canillas wrote:
> 
> Hello Kukjin,
> 
Hi,

> On Wed, Aug 20, 2014 at 1:19 PM, Javier Martinez Canillas
>  wrote:
> >
> > This is a second version of the series that adds max77802 support for
> > the Peach Pit and Pi boards. The series also have all the pending
> > patches that were posted but depended on this support. I've picked
> > all the patches I found and rebased them to be sure that they apply
> > cleanly on top of linux-next. Also I've taken some DT snippets from
> > the downstream Chrome OS 3.8 kernel DTS for devices that use one of
> > these regulators as their input supply.
> >
> 
> Any comments on this series?
> 
Looks good to me but I just wanted to get ack from chrome guy, Doug? But since
Naveen tested, it should be fine I think. I'll take the series.

Thanks,
Kukjin

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

[PATCH net-next] r8152: use usleep_range

[Hayes Wang]

Replace mdelay with usleep_range to avoid busy loop.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f95e678..2130c75 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2051,13 +2051,13 @@ static void rtl8152_disable(struct r8152 *tp)
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
if ((ocp_data & FIFO_EMPTY) == FIFO_EMPTY)
break;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
 
for (i = 0; i < 1000; i++) {
if (ocp_read_word(tp, MCU_TYPE_PLA, PLA_TCR0) & TCR0_TX_EMPTY)
break;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
 
for (i = 0; i < RTL8152_MAX_RX; i++)
@@ -2202,7 +2202,7 @@ static void rtl_clear_bp(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_2, 0);
ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_4, 0);
ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_6, 0);
-   mdelay(3);
+   usleep_range(3000, 6000);
ocp_write_word(tp, MCU_TYPE_PLA, PLA_BP_BA, 0);
ocp_write_word(tp, MCU_TYPE_USB, USB_BP_BA, 0);
 }
@@ -2288,7 +2288,7 @@ static void r8152b_exit_oob(struct r8152 *tp)
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
if (ocp_data & LINK_LIST_READY)
break;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
 
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_SFF_STS_7);
@@ -2299,7 +2299,7 @@ static void r8152b_exit_oob(struct r8152 *tp)
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
if (ocp_data & LINK_LIST_READY)
break;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
 
rtl8152_nic_reset(tp);
@@ -2360,7 +2360,7 @@ static void r8152b_enter_oob(struct r8152 *tp)
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
if (ocp_data & LINK_LIST_READY)
break;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
 
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_SFF_STS_7);
@@ -2371,7 +2371,7 @@ static void r8152b_enter_oob(struct r8152 *tp)
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
if (ocp_data & LINK_LIST_READY)
break;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
 
ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, RTL8152_RMS);
@@ -2518,7 +2518,7 @@ static void r8153_first_init(struct r8152 *tp)
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
if (ocp_data & LINK_LIST_READY)
break;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
 
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_SFF_STS_7);
@@ -2529,7 +2529,7 @@ static void r8153_first_init(struct r8152 *tp)
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
if (ocp_data & LINK_LIST_READY)
break;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
 
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_CPCR);
@@ -2573,7 +2573,7 @@ static void r8153_enter_oob(struct r8152 *tp)
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
if (ocp_data & LINK_LIST_READY)
break;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
 
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_SFF_STS_7);
@@ -2584,7 +2584,7 @@ static void r8153_enter_oob(struct r8152 *tp)
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
if (ocp_data & LINK_LIST_READY)
break;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
 
ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, RTL8153_RMS);
-- 
1.9.3

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

RE: [PATCH v5 RESEND 1/3] ARM: EXYNOS: Move code from hotplug.c to platsmp.c

[kgene]

Krzysztof Kozlowski wrote:
> 
> Cleanup a little the SMP/hotplug code for Exynos by:
> 1. Moving completely all functions from hotplug.c into the platsmp.c;
> 2. Deleting the hotplug.c file.
> 
> After recent cleanups (e.g. 75ad2ab28f0f "ARM: EXYNOS: use
> v7_exit_coherency_flush macro for cache disabling") there was only CPU
> power down related code in hotplug.c file.
> 
> Rationale behind the code movement and benefits:
> 1. The file platsmp.c is the only user of code located in hotplug.c.
>Keeping code in hotplug.c required declaring exynos_cpu_die() in common.h.
>Such dependencies and mentioned exynos_cpu_die() declaration can be
>removed.
> 2. In next patches exynos_set_delayed_reset_assertion() will be
>introduced. This function will be called by:
> - cpu_leave_power (hotplug.c),
> - platform_do_lowpower (hotplug.c),
> - exynos_boot_secondary (platsmp.c).
> 
> Merging hotplug.c into platsmp.c leads to simpler and cleaner code with
> less dependencies between files.
> 
> The commit only moves code around with one additional observable change:
> the hotplug.c was compiled with custom CFLAGS (-march=armv7-a). These
> CFLAGS are not necessary any more.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Reviewed-by: Tomasz Figa 
> 
> ---
> Changes since v4:
> 1. Rebase on linux-next-20140804.
> 2. Add Reviewed-by Tomasz Figa.
> ---
>  arch/arm/mach-exynos/Makefile  |  3 --
>  arch/arm/mach-exynos/common.h  |  2 -
>  arch/arm/mach-exynos/hotplug.c | 91 
> --
>  arch/arm/mach-exynos/platsmp.c | 74 ++
>  4 files changed, 74 insertions(+), 96 deletions(-)
>  delete mode 100644 arch/arm/mach-exynos/hotplug.c

[...]

OK, I will take this series but I'm not sure what conflicts will be happened
with other pm related patches. If anything, I'll let you know ;)

Thanks,
Kukjin

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

RE: [PATCH v6 0/5] ARM: EXYNOS: cpuidle: fix AFTR mode on boards with secure firmware enabled

[kgene]

Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
Hi,

> This patch series adds support for AFTR idle mode on boards with
> secure firmware enabled and allows EXYNOS cpuidle driver usage on
> Exynos4x12 SoCs.
> 
> It has been tested on Trats2 board (using Exynos4412 SoC with secure
> firmware enabled) on which AFTR mode reduces power consumption by ~12%

Nice.

> when EXYNOS cpuidle driver is enabled (in both cases the default
> exynos_defconfig config is used and CPU1-3 are offlined).
> 
> Currently Exynos4412 SoC support is limited to Trats2 board.
> 
> Depends on:
> - next-20140904 branch of linux-next kernel tree
> - "irqchip: Properly fetch the per cpu offset" patch
>   (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg716674.html)
> - [PATCH v3 0/5] Firmware-assisted suspend/resume of Exynos SoCs
>   
> (https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35921.html)
> 
OK this series looks good to me, I will take this series once above patches are
landed.

Thanks,
Kukjin

> Changes since v5:
> - rebased on top of next-20140904 +
>   "irqchip: Properly fetch the per cpu offset" patch
>   (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg716674.html)
>   [PATCH v3 0/5] Firmware-assisted suspend/resume of Exynos SoCs
>   
> (https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35921.html)
> - limit Exynos4412 SoC support to Trats2 board for now
> 
> Changes since v4:
> - rebased on top of next-20140804 +
>   [PATCH v5][next-20140804] ARM: EXYNOS: Fix suspend/resume sequences
>   
> (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35262.html)
>   [PATCH v2 0/2] Firmware-assisted suspend/resume of Exynos SoCs
>   
> (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34282.html)
> - call exynos_save_cp15() only on A9 type core (this is needed for the future
>   Exynos3250 SoC support)
> 
> Changes since v3:
> - rebased on top of next-20140804 +
>   [PATCH v4][next-20140804] ARM: EXYNOS: Fix suspend/resume sequences
>   
> (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35192.html)
>   [PATCH v2 0/2] Firmware-assisted suspend/resume of Exynos SoCs
>   
> (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34282.html)
> - (re-)added patch fixing S5P_CENTRAL_SEQ_OPTION register setup
> 
> Changes since v2:
> - rebased on top of next-20140708 +
>   [PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies
>   
> (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32809.html)
>   [with rejects fixed]
>   [PATCH 6/6] ARM: EXYNOS: Register cpuidle device only on Exynos4210 and 5250
>   
> (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32808.html)
>   [PATCH 0/2] Firmware-assisted suspend/resume of Exynos SoCs
>   
> (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32991.html)
>   [with rejects fixed in patch #2]
> - addressed review comments from Tomasz Figa and Daniel Lezcano
> 
> Changes since v1:
> - synced against next-20140602
> - added missing Acked-by-s
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
> 
> 
> Bartlomiej Zolnierkiewicz (5):
>   ARM: EXYNOS: PM: replace EXYNOS_BOOT_VECTOR_* macros by static inlines
>   ARM: EXYNOS: add AFTR mode support to firmware do_idle method
>   ARM: EXYNOS: cpuidle: add secure firmware support to AFTR mode code
>   ARM: EXYNOS: PM: fix register setup for AFTR mode code
>   ARM: EXYNOS: cpuidle: allow driver usage on Exynos4x12 SoCs
> 
>  arch/arm/include/asm/firmware.h |  2 +-
>  arch/arm/mach-exynos/common.h   |  5 
>  arch/arm/mach-exynos/exynos.c   |  5 +++-
>  arch/arm/mach-exynos/firmware.c | 34 ---
>  arch/arm/mach-exynos/pm.c   | 60 
> -
>  5 files changed, 71 insertions(+), 35 deletions(-)
> 
> --
> 1.8.2.3

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

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

[Tejun Heo]

Hello,

On Mon, Sep 08, 2014 at 08:19:12PM -0700, Luis R. Rodriguez wrote:
> On the systemd side of things it should enable this sysctl and for
> older kernels what should it do?

Supposing the change is backported via -stable, it can try to set the
sysctl on all kernels.  If the knob doesn't exist, the fix is not
there and nothing can be done about it.

Thanks.

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

Re: bit fields && data tearing

[H. Peter Anvin]

On 09/08/2014 07:56 PM, James Bottomley wrote:
>>
>> Yeah, the extra requirement I added is basically nonsense, since the
>> only issue is what instructions the compiler is emitting. So if compiler
>> thinks the alignment is natural and combines the writes -- ok. If the
>> compiler thinks the alignment is off and doesn't combine the writes --
>> also ok.
> 
> Yes, I think I can agree that the only real problem is gcc thinking the
> store or load needs splitting.
> 

That seems much saner, and yes, that applies to any architecture which
needs unaligned references.  Now, if the references are *actually*
unaligned they can end up being split even on x86, especially if they
cross cache line boundaries.

-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 v2 3/6] kthread: warn on kill signal if not OOM

[Luis R. Rodriguez]

On Mon, Sep 8, 2014 at 8:03 PM, Tejun Heo  wrote:
> On Mon, Sep 08, 2014 at 07:57:28PM -0700, Luis R. Rodriguez wrote:
>> > I think we
>> > just should make exceptions sensible so that it works fine in practice
>> > for now (and I don't think that'd be too hard).  So, the only
>> > cooperation necessary from userland would be just saying "I don't
>> > wanna wait for device probing on module load."
>>
>> But we're talking about drivers that have a flag that says 'you gotta
>> wait sucker', what do we want systemd to do then? I'd be happy if it'd
>> would not send the sigkill for these drivers, for example.
>
> Hah?  Can you give me an example?  I'm having hard time imagining a
> driver with such requirement given our current driver core
> implementation.

I didn't say I had one in mind, but if you're certain these *shouldn't
exist* that's sufficient by me as well.

OK so I'll respin this series to enable a sysctl that would enable
async probe for *all drivers* using queue_work(system_unbound_wq) and
only use sync probe for now on request_module() users, we'll address
scheduling issues as they come up. I'll be ignoring built-in.

On the systemd side of things it should enable this sysctl and for
older kernels what should it do?

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

Re: [PATCH v7] tpm_tis: verify interrupt during init

[Scot Doyle]

On Tue, 9 Sep 2014, Scot Doyle wrote:


Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do
not send IRQs while also having an ACPI TPM entry indicating that they
will be sent. These machines freeze on resume while the tpm_tis module
waits for an IRQ, eventually timing out.

When in interrupt mode, the tpm_tis module should receive an IRQ during
module init. Fall back to polling mode if none is received when expected.

Signed-off-by: Scot Doyle 
Tested-by: Michael Mullin 
Reviewed-By: Jason Gunthorpe 


Would anyone be willing to test this patch on a system that uses the 
tpm_tis module with interrupts?




---
drivers/char/tpm/tpm_tis.c | 75 +++---
1 file changed, 57 insertions(+), 18 deletions(-)

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

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

@@ -338,6 +342,21 @@ 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
@@ -345,8 +364,10 @@ out_err:
 */
static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, size_t len)
{
-   int rc;
+   int rc, irq;
u32 ordinal;
+   bool test_irq;
+   struct priv_data *priv = chip->vendor.priv;

rc = tpm_tis_send_data(chip, buf, len);
if (rc < 0)
@@ -358,13 +379,27 @@ static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, 
size_t len)

if (chip->vendor.irq) {
ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
-   if (wait_for_tpm_stat
-   (chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
-tpm_calc_ordinal_duration(chip, ordinal),
->vendor.read_queue, false) < 0) {
+   test_irq = !priv->irq_tested;
+   if (test_irq) {
+   irq = chip->vendor.irq;
+   chip->vendor.irq = 0;
+   }
+   rc = wait_for_tpm_stat
+(chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+ tpm_calc_ordinal_duration(chip, ordinal),
+ >vendor.read_queue, false);
+   if (test_irq)
+   chip->vendor.irq = irq;
+   if (rc < 0) {
rc = -ETIME;
goto out_err;
}
+   if (test_irq && !priv->irq_tested) {
+   priv->irq_tested = true;
+   disable_interrupts(chip);
+   dev_err(chip->dev,
+   FW_BUG "TPM interrupt not working, polling 
instead\n");
+   }
}
return len;
out_err:
@@ -505,6 +540,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 +570,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 +645,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 

RE: SHIPPING COST FROM CHINA TO RUSSIA

[RAIN]

Dear Sir,
 
Good day! I'm Rain from Shenzhen Topway International Forwarding Co.,ltd

We are providing the Shipping service for Courier, Air  and sea shipment from 
all cities of China
Our competitive advantages :

Full container shipment china ports to Russia,Central America and Africa ports

DHL,UPS,FEDEX courier door to door price 30% discount to worldwide

Especially: 
Door to door sea freight cargo from Guangzhou to 
Singapore,Thailand,Malaysia,Phillippines, Kenya,Japan and Korea
DDP( Double custom clearance service to these countries): Include custom 
declaration in China, shipping to your country, custom clearance, duty and vat 
taxes paid. and delivery to your door. you only need waiting goods in your 
place no need pay else when it arrive your door.

To view more details, plz click in: www.topwayfreight.com  
 
PS: Special sea freight by CMA CGM from China to North Africa, Black 
Sea,Adriatic Sea and Russia inland ports.
 

Sincerely hope we can receive your response to get the valuable opportuntity to 
offer our best service and also believe that we will be your reliable partner 
in China to take care your goods.
 
One chance, serve forever.


Thanks regards
Ms.Rain 
Shenzhen Top Way International Forwarding Co., Ltd
MOBILE & WHATSAPP:+86-13528787227
TEL:+86-755-89367755-802
Email:r...@topwayfreight.com
Skype:rain-blestocean
QQ:840626628
website: topwayfreight.com
http://hkkingway.en.alibaba.com

Re: linux-next: build failure after merge of the v4l-dvb tree

[Mauro Carvalho Chehab]

Hi Stephen,

Em Tue, 9 Sep 2014 12:43:06 +1000
Stephen Rothwell  escreveu:

> Hi Mauro,
> 
> After merging the v4l-dvb tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] 
> undefined!
> ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] 
> undefined!
> ERROR: "omap_dma_link_lch" 
> [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_dest_burst_mode" 
> [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_src_params" 
> [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] 
> undefined!
> ERROR: "omap_set_dma_transfer_params" 
> [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_dest_params" 
> [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] 
> undefined!
> ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
> ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_display.ko] undefined!
> ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
> 

Yeah, there are several drivers that are now enabled with COMPILE_TEST.

Not sure what's the best thing to do with those errors. Perhaps I should
add some stub functions for those drivers to not complain about linking
issues if COMPILE_TEST.

> I have used the v4l-dvb tree from next-20140908 for today.

> 
> There were also lots of new warnings like:
> 
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c: In function 
> 's5p_mfc_get_crop_info_h_v6':
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c:2039:3: warning: cast from 
> pointer to integer of different size [-Wpointer-to-int-cast]
>(unsigned int) ctx->dev->mfc_regs->d_display_crop_info1);
>^
> 

Those warnings are harmless in practice, but they should be fixed.

I'll be handling them before the next merge window.

Regards,
Mauro


signature.asc
Description: PGP signature

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

[Tejun Heo]

On Mon, Sep 08, 2014 at 07:57:28PM -0700, Luis R. Rodriguez wrote:
> > I think we
> > just should make exceptions sensible so that it works fine in practice
> > for now (and I don't think that'd be too hard).  So, the only
> > cooperation necessary from userland would be just saying "I don't
> > wanna wait for device probing on module load."
> 
> But we're talking about drivers that have a flag that says 'you gotta
> wait sucker', what do we want systemd to do then? I'd be happy if it'd
> would not send the sigkill for these drivers, for example.

Hah?  Can you give me an example?  I'm having hard time imagining a
driver with such requirement given our current driver core
implementation.

Thanks.

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

RE: [PATCH] imx6 PCI Host initialisation order

[hong-xing....@freescale.com]

> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Tuesday, September 09, 2014 12:51 AM
> To: Guo Shawn-R65073
> Cc: Raymond van der Rots; Zhu Richard-R65037; linux-kernel@vger.kernel.org;
> Lucas Stach; Tim Harvey
> Subject: Re: [PATCH] imx6 PCI Host initialisation order
> 
> On Mon, Sep 8, 2014 at 5:28 AM, Shawn Guo  wrote:
> > Hi Raymond,
> >
> > It seems that there is already a similar patch [1] from Tim floating
> > on the list.
> >
> > Shawn
> >
> > [1] http://www.spinics.net/lists/linux-pci/msg33520.html
> 
> Yes.  MAINTAINERS lists Richard Zhu  and Shawn Guo
>  (hi Shawn :)) as the caretakers for pci-imx6.c.
> Neither has acked it yet, and Richard asked for a comment update, which I
> haven't seen yet.  So I haven't applied it yet.
> 
[Richard] Yes it is. I recommended to add one comment used to describe why
the modification is required.

> > On Mon, Sep 08, 2014 at 11:10:37AM +0200, Raymond van der Rots wrote:
> >> Hi,
> >>
> >> The imx6dl on our hardware board frequently had problems bringing up the
> PCI link, with or without peripherals connected. I found these issues to be
> due to the initialisation order of the PCI Host.
> >>
> >> The host driver first enables the phy, and then enables its clocks. 
> >> However,
> according to the reference manual (IMX6SDLRM, page 2033):
> >> > The phy_ref_ssp_en signal must remain deasserted until the reference
> clock is running at the appropriate frequency, at which point phy_ref_ssp_en
> can be asserted.
> >>
> >>
> >> Which implies that the clocks should be brought up first, after which the
> peripheral should be enabled.
> >> This patch changes that initialisation order.
> >>
> >> I do not have other hardware with an imx6dl, so this patch has only been
> tested on our board. Could someone confirm that this is more technically
> correct or improves behaviour?
> >>
> >> Signed-off-by: Raymond van der Rots 
> >> ---
> >> diff --git a/drivers/pci/host/pci-imx6.c
> >> b/drivers/pci/host/pci-imx6.c index a568efa..17c35b4 100644
> >> --- a/drivers/pci/host/pci-imx6.c
> >> +++ b/drivers/pci/host/pci-imx6.c
> >> @@ -228,11 +228,6 @@ static int imx6_pcie_deassert_core_reset(struct
> pcie_port *pp)
> >>   struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> >>   int ret;
> >>
> >> - regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> >> - IMX6Q_GPR1_PCIE_TEST_PD, 0 << 18);
> >> - regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> >> - IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
> >> -
> >>   ret = clk_prepare_enable(imx6_pcie->pcie_phy);
> >>   if (ret) {
> >>   dev_err(pp->dev, "unable to enable pcie_phy clock\n");
> >> @@ -254,6 +249,11 @@ static int imx6_pcie_deassert_core_reset(struct
> pcie_port *pp)
> >>   /* allow the clocks to stabilize */
> >>   usleep_range(200, 500);
> >>
> >> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> >> + IMX6Q_GPR1_PCIE_TEST_PD, 0 << 18);
> >> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> >> + IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
> >> +
> >>   /* Some boards don't have PCIe reset GPIO. */
> >>   if (gpio_is_valid(imx6_pcie->reset_gpio)) {
> >>   gpio_set_value(imx6_pcie->reset_gpio, 0);
> >>
> >>

Best Regards
Richard Zhu

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 v2] nfs: fix kernel warning when removing proc entry

[Cong Wang]

On Mon, Sep 8, 2014 at 4:54 PM, Trond Myklebust
 wrote:
> On Wed, Aug 27, 2014 at 6:41 PM, Al Viro  wrote:
>> On Tue, Aug 19, 2014 at 09:20:38PM -0700, Eric W. Biederman wrote:
>>> Cong Wang  writes:
>>>
>>> > I saw the following kernel warning:
>>>
>>> Cong thanks for finding and tracking this.  I was clearly asleep at the
>>> switch when I was testing my fix to the nfs client code :(
>>>
>>> I have applied this patch and will push it to Linus after it has a
>>> little bit to sit in linux-next.
>>
>> Why does that code wank with one-by-one remove_proc_entry(), BTW?
>> remove_proc_subtree("nfsfs", net->proc_net) will take care of the whole pile
>> just fine, TYVM...  While we are it, there's no need to keep ->proc_nfsfs
>> at all - just have it in a local variable in nfs_fs_proc_net_init().
>
> Since nobody sent me an updated version with the remove_proc_subtree
> fix, I went ahead and edited the patch myself (see attachment). Cong,
> please let me know if you disagree with that change, otherwise, that
> will be the final patch sent upstream and Cc: stable # 3.4+.
>
> I'll schedule cleanup patches to make the same changes to the original
> nfs_fs_proc_exit() and nfs_fs_proc_init() and to remove (struct
> nfs_net)->proc_nfsfs for merging in 3.18.
>

Oops, I missed Al's reply and didn't know remove_proc_subtree() either.

Thanks for the update and it definitely looks good to me!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/6] kthread: warn on kill signal if not OOM

[Luis R. Rodriguez]

On Mon, Sep 8, 2014 at 7:39 PM, Tejun Heo  wrote:
> Hello,
>
> On Mon, Sep 08, 2014 at 07:28:58PM -0700, Luis R. Rodriguez wrote:
>> > Given that the behvaior change is from driver core and that device
>> > probing can happen post-loading anyway,
>>
>> Ah but lets not forget Dmitry's requirement which is for in-kernel
>> drivers. We'd need to deal with both built-in and modules. Dmitry's
>> case is completely orthogonal to the systemd issue and is just needed
>> to help not stall boot but I see no reason to blend these two issues
>> into one requirement together.
>
> Maybe we can piggy back the two on the same mechanism but as you said
> the two issues are orthogonal.  Let's keep it that way for now.  We
> need them separate anyway for backports.

OK.

>> In terms of approach we would still need to decide on a path for how
>> to do asynch probing for both in-kernel drivers and modules, do we
>> want async_schedule(), or queue_work()? If async_schedule() do we want
>> to use a new domain or a new one shared for all drivers? Priority on
>
> I don't think async_schedule() is the right mechanism for this use
> case as the mechanism is inherently opportunistic.  It also gets
> tangled up with async synchronization at the end of module loading.
>
>> the schedular was one of my other concerns which we'd need to make
>> right to match existing load on drivers through finit_module() and
>> synchronous probe.
>
> Why do we care about the priority of probing tasks?  Does that
> actually make any meaningful difference?  If so, how?

As I noted before -- I have yet to provide clear metrics but at least
changing both init paths + probe from finit_module() to kthread
certainly had a measurable time increase, I suspect using
queue_work(system_unbound_wq, async_probe_work) will make probe
slower. I'll get to these metrics this week.

>> > Userland could backport a fix to set the sysctl.  Given that we need
>> > both synchrnous and asynchronous behaviors, it's unlikely that we can
>> > come up with a solution which doesn't need cooperation from userland.
>>
>> True and then the timeout would also have to be skipped for device
>> drivers that have the sync_probe flag set, so I guess we'd need to
>
> I'm not sure about skipping for sync_probe flag.  That seems like an
> implementation detail to me.  Sure, we do that now because we don't
> have a better way of figuring out whether request_module() is waiting
> for it or not but hopefully we'd be able to in the future.

Oh I was not thinking about just request_modules() users but also any
of those stragglers which we might have ended up finding through run
time analysis. The alternative right now is these drivers won't load.
No bueno.

> I think we
> just should make exceptions sensible so that it works fine in practice
> for now (and I don't think that'd be too hard).  So, the only
> cooperation necessary from userland would be just saying "I don't
> wanna wait for device probing on module load."

But we're talking about drivers that have a flag that says 'you gotta
wait sucker', what do we want systemd to do then? I'd be happy if it'd
would not send the sigkill for these drivers, for example.

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

Re: bit fields && data tearing

[James Bottomley]

On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
> On 09/08/2014 01:50 AM, James Bottomley wrote:
> >> Two things: I think that gcc has given up on combining adjacent writes,
> >> perhaps because unaligned writes on some arches are prohibitive, so
> >> whatever minor optimization was believed to be gained was quickly lost,
> >> multi-fold. (Although this might not be the reason since one would
> >> expect that gcc would know the alignment of the promoted store).
> > 
> > Um, gcc assumes architecturally correct alignment; that's why it pads
> > structures.  Only when accessing packed structures will it use the
> > lowest unit load/store.
> > 
> > if you have a struct { char a, char b }; and load first a then b with a
> > constant gcc will obligingly optimise to a short store.
> 
> Um, please re-look at the test above. The exact test you describe is
> coded above and compiled with gcc 4.6.3 cross-compiler for parisc using
> the kernel compiler options.
> 
> In the generated code, please note the _absence_ of a combined write
> to two adjacent byte stores.

So one version of gcc doesn't do it.  Others do because I've been
surprised seeing it in assembly.

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

> >> I see no problem with gcc write-combining in the absence of
> >> memory barriers (as long as alignment is still respected,
> >> ie., the size-promoted write is still naturally aligned). The
> >> combined write is still atomic.
> > 
> > Actual alignment is pretty irrelevant.  That's why all architectures
> > which require alignment also have to implement misaligned traps ... this
> > is a fundamental requirement of the networking code, for instance.
> > 
> > The main problem is gcc thinking there's a misalignment (or a packed
> > structure).  That causes splitting of loads and stores and that destroys
> > atomicity.
> 
> Yeah, the extra requirement I added is basically nonsense, since the
> only issue is what instructions the compiler is emitting. So if compiler
> thinks the alignment is natural and combines the writes -- ok. If the
> compiler thinks the alignment is off and doesn't combine the writes --
> also ok.

Yes, I think I can agree that the only real problem is gcc thinking the
store or load needs splitting.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv3 0/5] OMAP Mailbox framework adoption & DT support

[Tony Lindgren]

* Tony Lindgren  [140908 16:21]:
> * Suman Anna  [140729 17:37]:
> > Hi,
> > 
> > This is an updated version of the OMAP Mailbox framework adoption &
> > DT support series, refreshed to work with the v9 version of the mailbox
> > framework [1] from Jassi Brar while also addressing some minor review
> > comments. Detailed changes are summarized below. Patches are based on
> > 3.16-rc2.
> 
> Sorry for the delay, just noticed that I'm supposed to queue
> these too. I'll queue these into omap-for-v3.18/mailbox against
> v3.17-rc1 and will probably also merge it into omap-for-v3.18/dt
> as well.

Actually this is not compiling and seems to probably miss
the dependencies from Jassi, so dropping the branch.

Anyways, since it seems you need to repost this again, please
repost the DT changes separately from the driver changes.

Regards,

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

[tip:x86/seccomp] x86_64, entry: Use split-phase syscall_trace_enter for 64-bit syscalls

[tip-bot for Andy Lutomirski]

Commit-ID:  1dcf74f6edfc3a9acd84d83d8865dd9e2a3b1d1e
Gitweb: http://git.kernel.org/tip/1dcf74f6edfc3a9acd84d83d8865dd9e2a3b1d1e
Author: Andy Lutomirski 
AuthorDate: Fri, 5 Sep 2014 15:13:56 -0700
Committer:  H. Peter Anvin 
CommitDate: Mon, 8 Sep 2014 14:14:12 -0700

x86_64, entry: Use split-phase syscall_trace_enter for 64-bit syscalls

On KVM on my box, this reduces the overhead from an always-accept
seccomp filter from ~130ns to ~17ns.  Most of that comes from
avoiding IRET on every syscall when seccomp is enabled.

In extremely approximate hacked-up benchmarking, just bypassing IRET
saves about 80ns, so there's another 43ns of savings here from
simplifying the seccomp path.

The diffstat is also rather nice :)

Signed-off-by: Andy Lutomirski 
Link: 
http://lkml.kernel.org/r/a3dbd267ee990110478d349f78cccfdac5497a84.1409954077.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/entry_64.S | 38 +++---
 1 file changed, 15 insertions(+), 23 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 0bd6d3c..df088bb 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -478,22 +478,6 @@ sysret_signal:
 
 #ifdef CONFIG_AUDITSYSCALL
/*
-* Fast path for syscall audit without full syscall trace.
-* We just call __audit_syscall_entry() directly, and then
-* jump back to the normal fast path.
-*/
-auditsys:
-   movq %r10,%r9   /* 6th arg: 4th syscall arg */
-   movq %rdx,%r8   /* 5th arg: 3rd syscall arg */
-   movq %rsi,%rcx  /* 4th arg: 2nd syscall arg */
-   movq %rdi,%rdx  /* 3rd arg: 1st syscall arg */
-   movq %rax,%rsi  /* 2nd arg: syscall number */
-   movl $AUDIT_ARCH_X86_64,%edi/* 1st arg: audit arch */
-   call __audit_syscall_entry
-   LOAD_ARGS 0 /* reload call-clobbered registers */
-   jmp system_call_fastpath
-
-   /*
 * Return fast path for syscall audit.  Call __audit_syscall_exit()
 * directly and then jump back to the fast path with TIF_SYSCALL_AUDIT
 * masked off.
@@ -510,17 +494,25 @@ sysret_audit:
 
/* Do syscall tracing */
 tracesys:
-#ifdef CONFIG_AUDITSYSCALL
-   testl $(_TIF_WORK_SYSCALL_ENTRY & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
-   jz auditsys
-#endif
+   leaq -REST_SKIP(%rsp), %rdi
+   movq $AUDIT_ARCH_X86_64, %rsi
+   call syscall_trace_enter_phase1
+   test %rax, %rax
+   jnz tracesys_phase2 /* if needed, run the slow path */
+   LOAD_ARGS 0 /* else restore clobbered regs */
+   jmp system_call_fastpath/*  and return to the fast path */
+
+tracesys_phase2:
SAVE_REST
FIXUP_TOP_OF_STACK %rdi
-   movq %rsp,%rdi
-   call syscall_trace_enter
+   movq %rsp, %rdi
+   movq $AUDIT_ARCH_X86_64, %rsi
+   movq %rax,%rdx
+   call syscall_trace_enter_phase2
+
/*
 * Reload arg registers from stack in case ptrace changed them.
-* We don't reload %rax because syscall_trace_enter() returned
+* We don't reload %rax because syscall_trace_entry_phase2() returned
 * the value it wants us to use in the table lookup.
 */
LOAD_ARGS ARGOFFSET, 1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/seccomp] x86, entry: Only call user_exit if TIF_NOHZ

[tip-bot for Andy Lutomirski]

Commit-ID:  fd143b210e685f0c4b37895f03fb79cd0555b00d
Gitweb: http://git.kernel.org/tip/fd143b210e685f0c4b37895f03fb79cd0555b00d
Author: Andy Lutomirski 
AuthorDate: Fri, 5 Sep 2014 15:13:53 -0700
Committer:  H. Peter Anvin 
CommitDate: Mon, 8 Sep 2014 14:13:59 -0700

x86, entry: Only call user_exit if TIF_NOHZ

The RCU context tracking code requires that arch code call
user_exit() on any entry into kernel code if TIF_NOHZ is set.  This
patch adds a check for TIF_NOHZ and a comment to the syscall entry
tracing code.

The main purpose of this patch is to make the code easier to follow:
one can read the body of user_exit and of every function it calls
without finding any explanation of why it's called for traced
syscalls but not for untraced syscalls.  This makes it clear when
user_exit() is necessary.

Cc: Frederic Weisbecker 
Signed-off-by: Andy Lutomirski 
Link: 
http://lkml.kernel.org/r/0b13e0e24ec0307d67ab7a23b58764f6b1270116.1409954077.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/ptrace.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 39296d2..bbf338a 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1449,7 +1449,12 @@ long syscall_trace_enter(struct pt_regs *regs)
 {
long ret = 0;
 
-   user_exit();
+   /*
+* If TIF_NOHZ is set, we are required to call user_exit() before
+* doing anything that could touch RCU.
+*/
+   if (test_thread_flag(TIF_NOHZ))
+   user_exit();
 
/*
 * If we stepped into a sysenter/syscall insn, it trapped in
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/seccomp] x86_64, entry: Treat regs-> ax the same in fastpath and slowpath syscalls

[tip-bot for Andy Lutomirski]

Commit-ID:  54eea9957f5763dd1a2555d7e4cb53b4dd389cc6
Gitweb: http://git.kernel.org/tip/54eea9957f5763dd1a2555d7e4cb53b4dd389cc6
Author: Andy Lutomirski 
AuthorDate: Fri, 5 Sep 2014 15:13:55 -0700
Committer:  H. Peter Anvin 
CommitDate: Mon, 8 Sep 2014 14:14:08 -0700

x86_64, entry: Treat regs->ax the same in fastpath and slowpath syscalls

For slowpath syscalls, we initialize regs->ax to -ENOSYS and stick
the syscall number into regs->orig_ax prior to any possible tracing
and syscall execution.  This is user-visible ABI used by ptrace
syscall emulation and seccomp.

For fastpath syscalls, there's no good reason not to do the same
thing.  It's even slightly simpler than what we're currently doing.
It probably has no measureable performance impact.  It should have
no user-visible effect.

The purpose of this patch is to prepare for two-phase syscall
tracing, in which the first phase might modify the saved RAX without
leaving the fast path.  This change is just subtle enough that I'm
keeping it separate.

Signed-off-by: Andy Lutomirski 
Link: 
http://lkml.kernel.org/r/01218b493f12ae2f98034b78c9ae085e38e94350.1409954077.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/calling.h |  6 +-
 arch/x86/kernel/entry_64.S | 13 -
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/calling.h b/arch/x86/include/asm/calling.h
index cb4c73b..76659b6 100644
--- a/arch/x86/include/asm/calling.h
+++ b/arch/x86/include/asm/calling.h
@@ -85,7 +85,7 @@ For 32-bit we have the following conventions - kernel is 
built with
 #define ARGOFFSET  R11
 #define SWFRAMEORIG_RAX
 
-   .macro SAVE_ARGS addskip=0, save_rcx=1, save_r891011=1
+   .macro SAVE_ARGS addskip=0, save_rcx=1, save_r891011=1, rax_enosys=0
subq  $9*8+\addskip, %rsp
CFI_ADJUST_CFA_OFFSET   9*8+\addskip
movq_cfi rdi, 8*8
@@ -96,7 +96,11 @@ For 32-bit we have the following conventions - kernel is 
built with
movq_cfi rcx, 5*8
.endif
 
+   .if \rax_enosys
+   movq $-ENOSYS, 4*8(%rsp)
+   .else
movq_cfi rax, 4*8
+   .endif
 
.if \save_r891011
movq_cfi r8,  3*8
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 2fac134..0bd6d3c 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -404,8 +404,8 @@ GLOBAL(system_call_after_swapgs)
 * and short:
 */
ENABLE_INTERRUPTS(CLBR_NONE)
-   SAVE_ARGS 8,0
-   movq  %rax,ORIG_RAX-ARGOFFSET(%rsp)
+   SAVE_ARGS 8, 0, rax_enosys=1
+   movq_cfi rax,(ORIG_RAX-ARGOFFSET)
movq  %rcx,RIP-ARGOFFSET(%rsp)
CFI_REL_OFFSET rip,RIP-ARGOFFSET
testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
@@ -417,7 +417,7 @@ system_call_fastpath:
andl $__SYSCALL_MASK,%eax
cmpl $__NR_syscall_max,%eax
 #endif
-   ja badsys
+   ja ret_from_sys_call  /* and return regs->ax */
movq %r10,%rcx
call *sys_call_table(,%rax,8)  # XXX:rip relative
movq %rax,RAX-ARGOFFSET(%rsp)
@@ -476,10 +476,6 @@ sysret_signal:
FIXUP_TOP_OF_STACK %r11, -ARGOFFSET
jmp int_check_syscall_exit_work
 
-badsys:
-   movq $-ENOSYS,RAX-ARGOFFSET(%rsp)
-   jmp ret_from_sys_call
-
 #ifdef CONFIG_AUDITSYSCALL
/*
 * Fast path for syscall audit without full syscall trace.
@@ -519,7 +515,6 @@ tracesys:
jz auditsys
 #endif
SAVE_REST
-   movq $-ENOSYS,RAX(%rsp) /* ptrace can change this for a bad syscall */
FIXUP_TOP_OF_STACK %rdi
movq %rsp,%rdi
call syscall_trace_enter
@@ -536,7 +531,7 @@ tracesys:
andl $__SYSCALL_MASK,%eax
cmpl $__NR_syscall_max,%eax
 #endif
-   ja   int_ret_from_sys_call  /* RAX(%rsp) set to -ENOSYS above */
+   ja   int_ret_from_sys_call  /* RAX(%rsp) is already set */
movq %r10,%rcx  /* fixup for C */
call *sys_call_table(,%rax,8)
movq %rax,RAX-ARGOFFSET(%rsp)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/seccomp] x86: Split syscall_trace_enter into two phases

[tip-bot for Andy Lutomirski]

Commit-ID:  e0ffbaabc46db508b8717f023c0ce03b980eefac
Gitweb: http://git.kernel.org/tip/e0ffbaabc46db508b8717f023c0ce03b980eefac
Author: Andy Lutomirski 
AuthorDate: Fri, 5 Sep 2014 15:13:54 -0700
Committer:  H. Peter Anvin 
CommitDate: Mon, 8 Sep 2014 14:14:03 -0700

x86: Split syscall_trace_enter into two phases

This splits syscall_trace_enter into syscall_trace_enter_phase1 and
syscall_trace_enter_phase2.  Only phase 2 has full pt_regs, and only
phase 2 is permitted to modify any of pt_regs except for orig_ax.

The intent is that phase 1 can be called from the syscall fast path.

In this implementation, phase1 can handle any combination of
TIF_NOHZ (RCU context tracking), TIF_SECCOMP, and TIF_SYSCALL_AUDIT,
unless seccomp requests a ptrace event, in which case phase2 is
forced.

In principle, this could yield a big speedup for TIF_NOHZ as well as
for TIF_SECCOMP if syscall exit work were similarly split up.

Signed-off-by: Andy Lutomirski 
Link: 
http://lkml.kernel.org/r/2df320a600020fda055fccf2b668145729dd0c04.1409954077.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/ptrace.h |   5 ++
 arch/x86/kernel/ptrace.c  | 157 +++---
 2 files changed, 138 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 6205f0c..86fc2bb 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -75,6 +75,11 @@ convert_ip_to_linear(struct task_struct *child, struct 
pt_regs *regs);
 extern void send_sigtrap(struct task_struct *tsk, struct pt_regs *regs,
 int error_code, int si_code);
 
+
+extern unsigned long syscall_trace_enter_phase1(struct pt_regs *, u32 arch);
+extern long syscall_trace_enter_phase2(struct pt_regs *, u32 arch,
+  unsigned long phase1_result);
+
 extern long syscall_trace_enter(struct pt_regs *);
 extern void syscall_trace_leave(struct pt_regs *);
 
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index bbf338a..29576c2 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1441,20 +1441,126 @@ void send_sigtrap(struct task_struct *tsk, struct 
pt_regs *regs,
force_sig_info(SIGTRAP, , tsk);
 }
 
+static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch)
+{
+#ifdef CONFIG_X86_64
+   if (arch == AUDIT_ARCH_X86_64) {
+   audit_syscall_entry(arch, regs->orig_ax, regs->di,
+   regs->si, regs->dx, regs->r10);
+   } else
+#endif
+   {
+   audit_syscall_entry(arch, regs->orig_ax, regs->bx,
+   regs->cx, regs->dx, regs->si);
+   }
+}
+
 /*
- * We must return the syscall number to actually look up in the table.
- * This can be -1L to skip running any syscall at all.
+ * We can return 0 to resume the syscall or anything else to go to phase
+ * 2.  If we resume the syscall, we need to put something appropriate in
+ * regs->orig_ax.
+ *
+ * NB: We don't have full pt_regs here, but regs->orig_ax and regs->ax
+ * are fully functional.
+ *
+ * For phase 2's benefit, our return value is:
+ * 0:  resume the syscall
+ * 1:  go to phase 2; no seccomp phase 2 needed
+ * anything else:  go to phase 2; pass return value to seccomp
  */
-long syscall_trace_enter(struct pt_regs *regs)
+unsigned long syscall_trace_enter_phase1(struct pt_regs *regs, u32 arch)
 {
-   long ret = 0;
+   unsigned long ret = 0;
+   u32 work;
+
+   BUG_ON(regs != task_pt_regs(current));
+
+   work = ACCESS_ONCE(current_thread_info()->flags) &
+   _TIF_WORK_SYSCALL_ENTRY;
 
/*
 * If TIF_NOHZ is set, we are required to call user_exit() before
 * doing anything that could touch RCU.
 */
-   if (test_thread_flag(TIF_NOHZ))
+   if (work & _TIF_NOHZ) {
user_exit();
+   work &= ~TIF_NOHZ;
+   }
+
+#ifdef CONFIG_SECCOMP
+   /*
+* Do seccomp first -- it should minimize exposure of other
+* code, and keeping seccomp fast is probably more valuable
+* than the rest of this.
+*/
+   if (work & _TIF_SECCOMP) {
+   struct seccomp_data sd;
+
+   sd.arch = arch;
+   sd.nr = regs->orig_ax;
+   sd.instruction_pointer = regs->ip;
+#ifdef CONFIG_X86_64
+   if (arch == AUDIT_ARCH_X86_64) {
+   sd.args[0] = regs->di;
+   sd.args[1] = regs->si;
+   sd.args[2] = regs->dx;
+   sd.args[3] = regs->r10;
+   sd.args[4] = regs->r8;
+   sd.args[5] = regs->r9;
+   } else
+#endif
+   {
+   sd.args[0] = regs->bx;
+   sd.args[1] = regs->cx;
+   sd.args[2] = regs->dx;
+  

[tip:x86/seccomp] x86, x32, audit: Fix x32's AUDIT_ARCH wrt audit

[tip-bot for Andy Lutomirski]

Commit-ID:  81f49a8fd7088cfcb588d182eeede862c0e3303e
Gitweb: http://git.kernel.org/tip/81f49a8fd7088cfcb588d182eeede862c0e3303e
Author: Andy Lutomirski 
AuthorDate: Fri, 5 Sep 2014 15:13:52 -0700
Committer:  H. Peter Anvin 
CommitDate: Mon, 8 Sep 2014 14:13:55 -0700

x86, x32, audit: Fix x32's AUDIT_ARCH wrt audit

is_compat_task() is the wrong check for audit arch; the check should
be is_ia32_task(): x32 syscalls should be AUDIT_ARCH_X86_64, not
AUDIT_ARCH_I386.

CONFIG_AUDITSYSCALL is currently incompatible with x32, so this has
no visible effect.

Signed-off-by: Andy Lutomirski 
Link: 
http://lkml.kernel.org/r/a0138ed8c709882aec06e4acc30bfa9b623b8717.1409954077.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/ptrace.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 93c182a..39296d2 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1441,15 +1441,6 @@ void send_sigtrap(struct task_struct *tsk, struct 
pt_regs *regs,
force_sig_info(SIGTRAP, , tsk);
 }
 
-
-#ifdef CONFIG_X86_32
-# define IS_IA32   1
-#elif defined CONFIG_IA32_EMULATION
-# define IS_IA32   is_compat_task()
-#else
-# define IS_IA32   0
-#endif
-
 /*
  * We must return the syscall number to actually look up in the table.
  * This can be -1L to skip running any syscall at all.
@@ -1487,7 +1478,7 @@ long syscall_trace_enter(struct pt_regs *regs)
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_enter(regs, regs->orig_ax);
 
-   if (IS_IA32)
+   if (is_ia32_task())
audit_syscall_entry(AUDIT_ARCH_I386,
regs->orig_ax,
regs->bx, regs->cx,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: build failure after merge of the v4l-dvb tree

[Stephen Rothwell]

Hi Mauro,

After merging the v4l-dvb tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] 
undefined!
ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] 
undefined!
ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] 
undefined!
ERROR: "omap_set_dma_dest_burst_mode" 
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_src_params" 
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] 
undefined!
ERROR: "omap_set_dma_transfer_params" 
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_dest_params" 
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] 
undefined!
ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_capture.ko] undefined!

I have used the v4l-dvb tree from next-20140908 for today.

There were also lots of new warnings like:

drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c: In function 
's5p_mfc_get_crop_info_h_v6':
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c:2039:3: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
   (unsigned int) ctx->dev->mfc_regs->d_display_crop_info1);
   ^

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


signature.asc
Description: PGP signature

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

[Tejun Heo]

Hello,

On Mon, Sep 08, 2014 at 07:28:58PM -0700, Luis R. Rodriguez wrote:
> > Given that the behvaior change is from driver core and that device
> > probing can happen post-loading anyway,
> 
> Ah but lets not forget Dmitry's requirement which is for in-kernel
> drivers. We'd need to deal with both built-in and modules. Dmitry's
> case is completely orthogonal to the systemd issue and is just needed
> to help not stall boot but I see no reason to blend these two issues
> into one requirement together.

Maybe we can piggy back the two on the same mechanism but as you said
the two issues are orthogonal.  Let's keep it that way for now.  We
need them separate anyway for backports.

> In terms of approach we would still need to decide on a path for how
> to do asynch probing for both in-kernel drivers and modules, do we
> want async_schedule(), or queue_work()? If async_schedule() do we want
> to use a new domain or a new one shared for all drivers? Priority on

I don't think async_schedule() is the right mechanism for this use
case as the mechanism is inherently opportunistic.  It also gets
tangled up with async synchronization at the end of module loading.

> the schedular was one of my other concerns which we'd need to make
> right to match existing load on drivers through finit_module() and
> synchronous probe.

Why do we care about the priority of probing tasks?  Does that
actually make any meaningful difference?  If so, how?

> > Userland could backport a fix to set the sysctl.  Given that we need
> > both synchrnous and asynchronous behaviors, it's unlikely that we can
> > come up with a solution which doesn't need cooperation from userland.
> 
> True and then the timeout would also have to be skipped for device
> drivers that have the sync_probe flag set, so I guess we'd need to

I'm not sure about skipping for sync_probe flag.  That seems like an
implementation detail to me.  Sure, we do that now because we don't
have a better way of figuring out whether request_module() is waiting
for it or not but hopefully we'd be able to in the future.  I think we
just should make exceptions sensible so that it works fine in practice
for now (and I don't think that'd be too hard).  So, the only
cooperation necessary from userland would be just saying "I don't
wanna wait for device probing on module load."

Thanks.

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

Re: [PATCH 0/2] Support CrystalCove PMIC ACPI operation region

[Aaron Lu]

I forgot to cc linux-acpi in the last series so please reply to this
thread, sorry for the inconvenience.

Regards,
Aaron

On Tue, Sep 09, 2014 at 10:32:46AM +0800, Aaron Lu wrote:
> The two patches add support for CrystalCove PMIC ACPI operation region.
> The PMIC chip has two customized operation regions: one for power rail
> manipulation and one for thermal purpose: sensor temperature reading
> and trip point value reading/setting.
> 
> For an example ASL code on ASUS T100 with CrystalCove PMIC, see here:
> https://gist.github.com/aaronlu/f5f65771a6c3251fae5d
> 
> Aaron Lu (2):
>   gpio / CrystalCove: support virtual GPIO
>   PMIC / opregion: support PMIC customized operation region for
> CrystalCove
> 
>  drivers/gpio/gpio-crystalcove.c   |  19 +-
>  drivers/mfd/Kconfig   |  11 +
>  drivers/mfd/Makefile  |   1 +
>  drivers/mfd/intel_soc_pmic_crc.c  |   3 +
>  drivers/mfd/intel_soc_pmic_crc_opregion.c | 229 +++
>  drivers/mfd/intel_soc_pmic_opregion.c | 350 
> ++
>  drivers/mfd/intel_soc_pmic_opregion.h |  35 +++
>  include/asm-generic/gpio.h|   2 +-
>  8 files changed, 646 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/mfd/intel_soc_pmic_crc_opregion.c
>  create mode 100644 drivers/mfd/intel_soc_pmic_opregion.c
>  create mode 100644 drivers/mfd/intel_soc_pmic_opregion.h
> 
> -- 
> 1.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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: bit fields && data tearing

[H. Peter Anvin]

On 09/08/2014 03:39 PM, James Bottomley wrote:
> 
> I don't understand what you mean by "pass each other".  Atomicity
> guarantees are not ordering guarantees in a SMP environment.  The
> guarantee is that if you follow the rules when two CPUs update the same
> natural width aligned object simultaneously using the same primitive,
> the result is either one or the other of their updates.  Which one wins
> (the ordering) isn't defined.
> 

I'm trying to figure out why it would possibly make a difference in any
kind of sane system if gcc fuses accesses.

Assuming bigendian for the moment, I would expect that if CPU 1 does a
write of 0x01020304 to address 0 and CPU 2 does a write of 0x0506 to
address 2, that the end result would be either 0x01020304 or 0x01020506.
 Similarly, I would expect that if these operations are both done on the
same CPU in that order, that the result would unambiguously be 0x01020506.

I would strongly suspect an architecture which does not provide those
guarantees is an outlier.

-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 v2] audit: vfs: fix audit records error when write to a file

[hujianyang]

Changes from v1:

   * Move audit_inode() to the beginning of O_CREAT case in
 lookup_open() to avoid missing audit for ROFS error. This
 lack is spotted by Jeff Layton 

commit 33e2208acfc1

audit: vfs: fix audit_inode call in O_CREAT case of do_last

fix a regression in auditing of open(..., O_CREAT) syscalls but
introduce a new problem which lead the records of write operation
confusion.

This error can be reproduced by these steps:

touch /etc/test
echo "-w /etc/test" >>/etc/audit/audit.rules
/etc/init.d/auditd restart

echo "abc" >> /etc/test

audit_name records are:

type=PATH msg=audit(1409764556.196:67): item=0 name="/etc/" inode=5097 
dev=00:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT
type=PATH msg=audit(1409764556.196:67): item=1 name=(null) inode=23161 
dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
type=PATH msg=audit(1409764556.196:67): item=2 name=(null) inode=23161 
dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL

but if we revert commit 33e2208acfc1, records are correct:

type=PATH msg=audit(1409763058.192:219): item=0 name="/etc/test" inode=1275 
dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL

We shouldn't leave audit_inode(.., LOOKUP_PARENT) in O_CREAT case
of do_last() because this branch don't really know if vfs need to
create a new file. There is no need to do vfs_create() if we open
an existing file with O_CREAT flag and write to it. But this
audit_inode() in O_CREAT case will record a msg as we create a new
file and confuse the records of write.

This patch moves the audit for create operation to where a file
really need to be created, the O_CREAT case in lookup_open().
We have to add the pointer of struct filename as a parameter of
lookup_open(). By doing this, the records of both create and write
are correct.

Signed-off-by: hujianyang 
---
 fs/namei.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index a996bb4..ca4a831 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2808,7 +2808,8 @@ looked_up:
 static int lookup_open(struct nameidata *nd, struct path *path,
struct file *file,
const struct open_flags *op,
-   bool got_write, int *opened)
+   bool got_write, int *opened,
+   struct filename *name)
 {
struct dentry *dir = nd->path.dentry;
struct inode *dir_inode = dir->d_inode;
@@ -2841,6 +2842,8 @@ static int lookup_open(struct nameidata *nd, struct path 
*path,
/* Negative dentry, just create the file */
if (!dentry->d_inode && (op->open_flag & O_CREAT)) {
umode_t mode = op->mode;
+
+   audit_inode(name, dir, LOOKUP_PARENT);
if (!IS_POSIXACL(dir->d_inode))
mode &= ~current_umask();
/*
@@ -2926,7 +2929,6 @@ static int do_last(struct nameidata *nd, struct path 
*path,
if (error)
return error;

-   audit_inode(name, dir, LOOKUP_PARENT);
error = -EISDIR;
/* trailing slashes? */
if (nd->last.name[nd->last.len])
@@ -2945,7 +2947,7 @@ retry_lookup:
 */
}
mutex_lock(>d_inode->i_mutex);
-   error = lookup_open(nd, path, file, op, got_write, opened);
+   error = lookup_open(nd, path, file, op, got_write, opened, name);
mutex_unlock(>d_inode->i_mutex);

if (error <= 0) {
-- 
1.8.5.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: bit fields && data tearing

[H. Peter Anvin]

On 09/08/2014 03:43 PM, James Bottomley wrote:
> 
> This was years ago (possibly decades).  We had to implement in-kernel
> unaligned traps for the networking layer because it could access short
> and int fields that weren't of the correct alignment when processing
> packets.  It that's all corrected now, we wouldn't really notice (except
> a bit of a speed up since an unaligned trap effectively places the
> broken out instructions into the bit stream).
> 
> James
> 

Well, ARM doesn't trap, it just silently gives garbage on unaligned
memory references.

-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 v4 04/16] ACPI: Rename processor_core.c as apic_id.c

[Jiang Liu]

Hi Rafael and Hanjun,
Thanks for your review. I will keep the original file name
in next version.
Regards!
Gerry

On 2014/9/9 5:00, Rafael J. Wysocki wrote:
> On Monday, September 08, 2014 08:51:31 PM Hanjun Guo wrote:
>> Hi Gerry, Rafael,
>>
>> On 2014年09月08日 06:37, Rafael J. Wysocki wrote:
>>> On Thursday, August 28, 2014 10:22:29 AM Jiang Liu wrote:
 Now all code in processor_core.c is APIC ID related, so rename it as
 apic_id.c. Later IOAPIC ID related code will be added into apic_id.c.
>>> Actually, I'm not sure about this one.
>>>
>>> Renames like this make it difficult to backport things in general
>>> and kind of break "git blame", so do we have to do that?
>>>
>>> What's wrong with leaving the name as is and adding a comment
>>> about the contents being related to IOAPIC ID?
>>
>> It will be thankful for not renaming the file into apic_id.c, because apic 
>> id is x86 specific,
>> and platform like ARM will also add some code to get cpu hardware id via 
>> GICC structure
>> in MADT table in that file, apic id is not a generic name for both x86 and 
>> ARM, I prefer to
>> keep it as it is :)
> 
> Well, that's a good argument too.
> 
> Rafael
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] Support CrystalCove PMIC ACPI operation region

[Aaron Lu]

The two patches add support for CrystalCove PMIC ACPI operation region.
The PMIC chip has two customized operation regions: one for power rail
manipulation and one for thermal purpose: sensor temperature reading
and trip point value reading/setting.

For an example ASL code on ASUS T100 with CrystalCove PMIC, see here:
https://gist.github.com/aaronlu/f5f65771a6c3251fae5d

Aaron Lu (2):
  gpio / CrystalCove: support virtual GPIO
  PMIC / opregion: support PMIC customized operation region for
CrystalCove

 drivers/gpio/gpio-crystalcove.c   |  19 +-
 drivers/mfd/Kconfig   |  11 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/intel_soc_pmic_crc.c  |   3 +
 drivers/mfd/intel_soc_pmic_crc_opregion.c | 229 +++
 drivers/mfd/intel_soc_pmic_opregion.c | 350 ++
 drivers/mfd/intel_soc_pmic_opregion.h |  35 +++
 include/asm-generic/gpio.h|   2 +-
 8 files changed, 646 insertions(+), 4 deletions(-)
 create mode 100644 drivers/mfd/intel_soc_pmic_crc_opregion.c
 create mode 100644 drivers/mfd/intel_soc_pmic_opregion.c
 create mode 100644 drivers/mfd/intel_soc_pmic_opregion.h

-- 
1.9.3

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

[PATCH 2/2] PMIC / opregion: support PMIC customized operation region for CrystalCove

[Aaron Lu]

The Baytrail-T platform firmware has defined two customized operation
regions for PMIC chip Crystal Cove - one is for power resource handling
and one is for thermal: sensor temperature reporting, trip point setting,
etc. This patch adds support for them on top of the existing Crystal Cove
PMIC driver.

The reason to split code into a separate file intel_soc_pmic_opregion.c
is that there are more PMIC driver with ACPI operation region support
coming and we can re-use those code. The intel_soc_pmic_opregion_data
structure is created also for this purpose: when we need to support a
new PMIC's operation region, we just need to fill those callbacks and
the two register mapping tables.

Signed-off-by: Aaron Lu 
---
 drivers/mfd/Kconfig   |  11 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/intel_soc_pmic_crc.c  |   3 +
 drivers/mfd/intel_soc_pmic_crc_opregion.c | 229 +++
 drivers/mfd/intel_soc_pmic_opregion.c | 350 ++
 drivers/mfd/intel_soc_pmic_opregion.h |  35 +++
 6 files changed, 629 insertions(+)
 create mode 100644 drivers/mfd/intel_soc_pmic_crc_opregion.c
 create mode 100644 drivers/mfd/intel_soc_pmic_opregion.c
 create mode 100644 drivers/mfd/intel_soc_pmic_opregion.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf244746..77a7229058a6 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -266,6 +266,17 @@ config INTEL_SOC_PMIC
  thermal, charger and related power management functions
  on these systems.
 
+config CRC_PMIC_OPREGION
+   tristate "ACPI operation region support for CrystalCove PMIC"
+   depends on ACPI
+   depends on INTEL_SOC_PMIC
+   help
+ Select this option to enable support for ACPI operation
+ region of the PMIC chip. The operation region can be used
+ to control power rails and sensor reading/writing on the
+ PMIC chip. This config addes ACPI operation region support
+ for CrystalCove PMIC.
+
 config MFD_INTEL_MSIC
bool "Intel MSIC"
depends on INTEL_SCU_IPC
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f00148782d9b..e02f0573e293 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -172,3 +172,4 @@ obj-$(CONFIG_MFD_IPAQ_MICRO)+= ipaq-micro.o
 
 intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
+obj-$(CONFIG_CRC_PMIC_OPREGION) += intel_soc_pmic_crc_opregion.o 
intel_soc_pmic_opregion.o
diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
index 7107cab832e6..48845d636bba 100644
--- a/drivers/mfd/intel_soc_pmic_crc.c
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -106,6 +106,9 @@ static struct mfd_cell crystal_cove_dev[] = {
.num_resources = ARRAY_SIZE(gpio_resources),
.resources = gpio_resources,
},
+   {
+   .name = "crystal_cove_region",
+   },
 };
 
 static struct regmap_config crystal_cove_regmap_config = {
diff --git a/drivers/mfd/intel_soc_pmic_crc_opregion.c 
b/drivers/mfd/intel_soc_pmic_crc_opregion.c
new file mode 100644
index ..27b67dc3fa8d
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_crc_opregion.c
@@ -0,0 +1,229 @@
+/*
+ * intel_soc_pmic_crc_opregion.c - Intel SoC PMIC operation region Driver
+ *
+ * Copyright (C) 2014 Intel Corporation. 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 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 "intel_soc_pmic_opregion.h"
+
+#define PWR_SOURCE_SELECT  BIT(1)
+
+#define PMIC_A0LOCK_REG0xc5
+
+static struct pmic_pwr_table pwr_table[] = {
+   {
+   .address = 0x24,
+   .pwr_reg = {
+   .reg = 0x66,
+   .bit = 0x00,
+   },
+   },  /* X285 -> V2P85SX, camara */
+   {
+   .address = 0x48,
+   .pwr_reg = {
+   .reg = 0x5d,
+   .bit = 0x00,
+   },
+   },  /* V18X -> V1P8SX, eMMC/camara/audio */
+};
+
+static struct pmic_dptf_table dptf_table[] = {
+   {
+   .address = 0x00,
+   .reg = 0x75
+   },  /* TMP0 -> SYS0_THRM_RSLT_L */
+   {
+   .address = 0x04,
+   .reg = 0x95
+   },  /* AX00 -> SYS0_THRMALRT0_L */
+   {
+   .address = 0x08,
+   .reg = 0x97
+   },  /* AX01 -> SYS0_THRMALRT1_L */
+  

[PATCH 1/2] gpio / CrystalCove: support virtual GPIO

[Aaron Lu]

The virtual GPIO introduced in ACPI table of Baytrail-T based system is
used to solve a problem under Windows. We do not have such problems
under Linux so we do not actually need them. But we have to tell GPIO
library that the Crystal Cove GPIO chip has this many GPIO pins or the
common GPIO handler will refuse any access to those high number GPIO
pins, which will resulted in a failure evaluation of every ACPI control
method that is used to turn on/off power resource and/or report sensor
temperatures.

Due to the high number of virtual GPIOs, the value of ARCH_NR_GPIOS is
bumped from 256 to 512 to avoid failures on platforms that have various
GPIO controllers.

Signed-off-by: Aaron Lu 
---
 drivers/gpio/gpio-crystalcove.c | 19 ---
 include/asm-generic/gpio.h  |  2 +-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
index 934462f5bd22..a8daada67aa4 100644
--- a/drivers/gpio/gpio-crystalcove.c
+++ b/drivers/gpio/gpio-crystalcove.c
@@ -24,6 +24,7 @@
 #include 
 
 #define CRYSTALCOVE_GPIO_NUM   16
+#define CRYSTALCOVE_VGPIO_NUM  0x5e
 
 #define UPDATE_IRQ_TYPEBIT(0)
 #define UPDATE_IRQ_MASKBIT(1)
@@ -130,6 +131,9 @@ static int crystalcove_gpio_dir_in(struct gpio_chip *chip, 
unsigned gpio)
 {
struct crystalcove_gpio *cg = to_cg(chip);
 
+   if (gpio > CRYSTALCOVE_VGPIO_NUM)
+   return 0;
+
return regmap_write(cg->regmap, to_reg(gpio, CTRL_OUT),
CTLO_INPUT_SET);
 }
@@ -139,6 +143,9 @@ static int crystalcove_gpio_dir_out(struct gpio_chip *chip, 
unsigned gpio,
 {
struct crystalcove_gpio *cg = to_cg(chip);
 
+   if (gpio > CRYSTALCOVE_VGPIO_NUM)
+   return 0;
+
return regmap_write(cg->regmap, to_reg(gpio, CTRL_OUT),
CTLO_OUTPUT_SET | value);
 }
@@ -149,6 +156,9 @@ static int crystalcove_gpio_get(struct gpio_chip *chip, 
unsigned gpio)
int ret;
unsigned int val;
 
+   if (gpio > CRYSTALCOVE_VGPIO_NUM)
+   return 0;
+
ret = regmap_read(cg->regmap, to_reg(gpio, CTRL_IN), );
if (ret)
return ret;
@@ -161,6 +171,9 @@ static void crystalcove_gpio_set(struct gpio_chip *chip,
 {
struct crystalcove_gpio *cg = to_cg(chip);
 
+   if (gpio > CRYSTALCOVE_VGPIO_NUM)
+   return;
+
if (value)
regmap_update_bits(cg->regmap, to_reg(gpio, CTRL_OUT), 1, 1);
else
@@ -256,7 +269,7 @@ static irqreturn_t crystalcove_gpio_irq_handler(int irq, 
void *data)
 
pending = p0 | p1 << 8;
 
-   for (gpio = 0; gpio < cg->chip.ngpio; gpio++) {
+   for (gpio = 0; gpio < CRYSTALCOVE_GPIO_NUM; gpio++) {
if (pending & BIT(gpio)) {
virq = irq_find_mapping(cg->chip.irqdomain, gpio);
generic_handle_irq(virq);
@@ -273,7 +286,7 @@ static void crystalcove_gpio_dbg_show(struct seq_file *s,
int gpio, offset;
unsigned int ctlo, ctli, mirqs0, mirqsx, irq;
 
-   for (gpio = 0; gpio < cg->chip.ngpio; gpio++) {
+   for (gpio = 0; gpio < CRYSTALCOVE_GPIO_NUM; gpio++) {
regmap_read(cg->regmap, to_reg(gpio, CTRL_OUT), );
regmap_read(cg->regmap, to_reg(gpio, CTRL_IN), );
regmap_read(cg->regmap, gpio < 8 ? MGPIO0IRQS0 : MGPIO1IRQS0,
@@ -320,7 +333,7 @@ static int crystalcove_gpio_probe(struct platform_device 
*pdev)
cg->chip.get = crystalcove_gpio_get;
cg->chip.set = crystalcove_gpio_set;
cg->chip.base = -1;
-   cg->chip.ngpio = CRYSTALCOVE_GPIO_NUM;
+   cg->chip.ngpio = CRYSTALCOVE_VGPIO_NUM;
cg->chip.can_sleep = true;
cg->chip.dev = dev;
cg->chip.dbg_show = crystalcove_gpio_dbg_show;
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index c1d4105e1c1d..383ade1a211b 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -27,7 +27,7 @@
  */
 
 #ifndef ARCH_NR_GPIOS
-#define ARCH_NR_GPIOS  256
+#define ARCH_NR_GPIOS  512
 #endif
 
 /*
-- 
1.9.3

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

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

[Luis R. Rodriguez]

On Mon, Sep 8, 2014 at 6:47 PM, Tejun Heo  wrote:
> Hello,
>
> On Mon, Sep 08, 2014 at 06:38:34PM -0700, Luis R. Rodriguez wrote:
>> OK then one only concern I would have with this is that the presence
>> of such a flag doesn't necessarily mean that all drivers on a system
>> have been tested for asynch probe yet. I'd feel much more comfortable
>
> Given that the behvaior change is from driver core and that device
> probing can happen post-loading anyway,

Ah but lets not forget Dmitry's requirement which is for in-kernel
drivers. We'd need to deal with both built-in and modules. Dmitry's
case is completely orthogonal to the systemd issue and is just needed
to help not stall boot but I see no reason to blend these two issues
into one requirement together.

> I don't think we need to worry
> about drivers breaking from probing made asynchronous to loading.  The
> problem is the expectation of the entity which initiated loading of
> the module.  If it's depending on device being probed synchronously
> but insmod returns before that, it can break things.  We probably
> should audit request_module() users and see which ones expect such
> behavior.

Sure. Based on a quick glance I see sloppy uses of this, this should
probably be fixed anyway.

>> if this global flag allowed say specific drivers that *did* have such
>> a bool enabled, for example. Then that would enable synchronous
>> behaviour for the kernel by default, require the flag for enabling the
>> new async feature but only for drivers that have been tested.
>
> If we're gonna do the global switch, I personally think the right
> approach is blacklisting instead of the other way around because each
> specific driver doesn't really have much to do with it and the
> exceptions are about specific use cases that we don't have a good way
> to identify them from module loading path.

OK sure... even if we did whitelist I'm afraid such a white list might
be subjective in terms of design to specific systems anyway... I
suppose the only real way to do it right is to push and strive towards
a full system whitelist and address the black list as you mention.

In terms of approach we would still need to decide on a path for how
to do asynch probing for both in-kernel drivers and modules, do we
want async_schedule(), or queue_work()? If async_schedule() do we want
to use a new domain or a new one shared for all drivers? Priority on
the schedular was one of my other concerns which we'd need to make
right to match existing load on drivers through finit_module() and
synchronous probe.

>> That also still would not technically solve the issue of the current
>> existence of the timeout, unless of course we wish to ask systemd to
>> only make the timeout take effect *iff* the global sysctl flag /
>> whatever was enabled.
>
> Userland could backport a fix to set the sysctl.  Given that we need
> both synchrnous and asynchronous behaviors, it's unlikely that we can
> come up with a solution which doesn't need cooperation from userland.

True and then the timeout would also have to be skipped for device
drivers that have the sync_probe flag set, so I guess we'd need to
expose that too. I'm not too sure if systemd is equipped to be happy
with no timeout on module loading based previous discussions [0] so
we'd need to ensure we're all in agreement there that such drivers
exist and we may need *something*, if at the very least a really long
fucking timeout (TM) for such drivers.

[0] http://lists.freedesktop.org/archives/systemd-devel/2014-August/021852.html

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

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

[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.txt
> >> @@ -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.

thanks,
rui
> It's a good option.
> I can send a patch,but I don't know whether the thermal maintainers will 
> accept it.
> 
> Maybe,they have a better way to suggest it.:-)
> 
> 
> PS:I will sent a new patch If I still have no received their suggestions 
> in two days.
> 
> >
> > Heiko
> >
> >
> > [0] in a separate patch, changing
> > - thermal_trip_type enum in include/linux/thermal.h
> > - trip_types mapping in drivers/thermal/of-thermal.c
> > - Documentation/devicetree/bindings/thermal/thermal.txt
> >
> >> +
> >> +Example:
> >> +tsadc: tsadc@ff28 {
> >> +  compatible = "rockchip,rk3288-tsadc";
> >> +  reg = <0xff28 0x100>;
> >> +  interrupts = ;
> >> +  clocks = < SCLK_TSADC>, < PCLK_TSADC>;
> >> +  clock-names = "tsadc", "apb_pclk";
> >> +};
> >
> >
> >
> 


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

[PATCH 0/2] Support CrystalCove PMIC ACPI operation region

[Aaron Lu]

The two patches add support for CrystalCove PMIC ACPI operation region.
The PMIC chip has two customized operation regions: one for power rail
manipulation and one for thermal purpose: sensor temperature reading
and trip point value reading/setting.

For an example ASL code on ASUS T100 with CrystalCove PMIC, see here:
https://gist.github.com/aaronlu/f5f65771a6c3251fae5d

Aaron Lu (2):
  gpio / CrystalCove: support virtual GPIO
  PMIC / opregion: support PMIC customized operation region for
CrystalCove

 drivers/gpio/gpio-crystalcove.c   |  19 +-
 drivers/mfd/Kconfig   |  11 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/intel_soc_pmic_crc.c  |   3 +
 drivers/mfd/intel_soc_pmic_crc_opregion.c | 229 +++
 drivers/mfd/intel_soc_pmic_opregion.c | 350 ++
 drivers/mfd/intel_soc_pmic_opregion.h |  35 +++
 include/asm-generic/gpio.h|   2 +-
 8 files changed, 646 insertions(+), 4 deletions(-)
 create mode 100644 drivers/mfd/intel_soc_pmic_crc_opregion.c
 create mode 100644 drivers/mfd/intel_soc_pmic_opregion.c
 create mode 100644 drivers/mfd/intel_soc_pmic_opregion.h

-- 
1.9.3

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

[PATCH 2/2] PMIC / opregion: support PMIC customized operation region for CrystalCove

[Aaron Lu]

The Baytrail-T platform firmware has defined two customized operation
regions for PMIC chip Crystal Cove - one is for power resource handling
and one is for thermal: sensor temperature reporting, trip point setting,
etc. This patch adds support for them on top of the existing Crystal Cove
PMIC driver.

The reason to split code into a separate file intel_soc_pmic_opregion.c
is that there are more PMIC driver with ACPI operation region support
coming and we can re-use those code. The intel_soc_pmic_opregion_data
structure is created also for this purpose: when we need to support a
new PMIC's operation region, we just need to fill those callbacks and
the two register mapping tables.

Signed-off-by: Aaron Lu 
---
 drivers/mfd/Kconfig   |  11 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/intel_soc_pmic_crc.c  |   3 +
 drivers/mfd/intel_soc_pmic_crc_opregion.c | 229 +++
 drivers/mfd/intel_soc_pmic_opregion.c | 350 ++
 drivers/mfd/intel_soc_pmic_opregion.h |  35 +++
 6 files changed, 629 insertions(+)
 create mode 100644 drivers/mfd/intel_soc_pmic_crc_opregion.c
 create mode 100644 drivers/mfd/intel_soc_pmic_opregion.c
 create mode 100644 drivers/mfd/intel_soc_pmic_opregion.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf244746..77a7229058a6 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -266,6 +266,17 @@ config INTEL_SOC_PMIC
  thermal, charger and related power management functions
  on these systems.
 
+config CRC_PMIC_OPREGION
+   tristate "ACPI operation region support for CrystalCove PMIC"
+   depends on ACPI
+   depends on INTEL_SOC_PMIC
+   help
+ Select this option to enable support for ACPI operation
+ region of the PMIC chip. The operation region can be used
+ to control power rails and sensor reading/writing on the
+ PMIC chip. This config addes ACPI operation region support
+ for CrystalCove PMIC.
+
 config MFD_INTEL_MSIC
bool "Intel MSIC"
depends on INTEL_SCU_IPC
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f00148782d9b..e02f0573e293 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -172,3 +172,4 @@ obj-$(CONFIG_MFD_IPAQ_MICRO)+= ipaq-micro.o
 
 intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
+obj-$(CONFIG_CRC_PMIC_OPREGION) += intel_soc_pmic_crc_opregion.o 
intel_soc_pmic_opregion.o
diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
index 7107cab832e6..48845d636bba 100644
--- a/drivers/mfd/intel_soc_pmic_crc.c
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -106,6 +106,9 @@ static struct mfd_cell crystal_cove_dev[] = {
.num_resources = ARRAY_SIZE(gpio_resources),
.resources = gpio_resources,
},
+   {
+   .name = "crystal_cove_region",
+   },
 };
 
 static struct regmap_config crystal_cove_regmap_config = {
diff --git a/drivers/mfd/intel_soc_pmic_crc_opregion.c 
b/drivers/mfd/intel_soc_pmic_crc_opregion.c
new file mode 100644
index ..27b67dc3fa8d
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_crc_opregion.c
@@ -0,0 +1,229 @@
+/*
+ * intel_soc_pmic_crc_opregion.c - Intel SoC PMIC operation region Driver
+ *
+ * Copyright (C) 2014 Intel Corporation. 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 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 "intel_soc_pmic_opregion.h"
+
+#define PWR_SOURCE_SELECT  BIT(1)
+
+#define PMIC_A0LOCK_REG0xc5
+
+static struct pmic_pwr_table pwr_table[] = {
+   {
+   .address = 0x24,
+   .pwr_reg = {
+   .reg = 0x66,
+   .bit = 0x00,
+   },
+   },  /* X285 -> V2P85SX, camara */
+   {
+   .address = 0x48,
+   .pwr_reg = {
+   .reg = 0x5d,
+   .bit = 0x00,
+   },
+   },  /* V18X -> V1P8SX, eMMC/camara/audio */
+};
+
+static struct pmic_dptf_table dptf_table[] = {
+   {
+   .address = 0x00,
+   .reg = 0x75
+   },  /* TMP0 -> SYS0_THRM_RSLT_L */
+   {
+   .address = 0x04,
+   .reg = 0x95
+   },  /* AX00 -> SYS0_THRMALRT0_L */
+   {
+   .address = 0x08,
+   .reg = 0x97
+   },  /* AX01 -> SYS0_THRMALRT1_L */
+  

[PATCH 1/2] gpio / CrystalCove: support virtual GPIO

[Aaron Lu]

The virtual GPIO introduced in ACPI table of Baytrail-T based system is
used to solve a problem under Windows. We do not have such problems
under Linux so we do not actually need them. But we have to tell GPIO
library that the Crystal Cove GPIO chip has this many GPIO pins or the
common GPIO handler will refuse any access to those high number GPIO
pins, which will resulted in a failure evaluation of every ACPI control
method that is used to turn on/off power resource and/or report sensor
temperatures.

Due to the high number of virtual GPIOs, the value of ARCH_NR_GPIOS is
bumped from 256 to 512 to avoid failures on platforms that have various
GPIO controllers.

Signed-off-by: Aaron Lu 
---
 drivers/gpio/gpio-crystalcove.c | 19 ---
 include/asm-generic/gpio.h  |  2 +-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
index 934462f5bd22..a8daada67aa4 100644
--- a/drivers/gpio/gpio-crystalcove.c
+++ b/drivers/gpio/gpio-crystalcove.c
@@ -24,6 +24,7 @@
 #include 
 
 #define CRYSTALCOVE_GPIO_NUM   16
+#define CRYSTALCOVE_VGPIO_NUM  0x5e
 
 #define UPDATE_IRQ_TYPEBIT(0)
 #define UPDATE_IRQ_MASKBIT(1)
@@ -130,6 +131,9 @@ static int crystalcove_gpio_dir_in(struct gpio_chip *chip, 
unsigned gpio)
 {
struct crystalcove_gpio *cg = to_cg(chip);
 
+   if (gpio > CRYSTALCOVE_VGPIO_NUM)
+   return 0;
+
return regmap_write(cg->regmap, to_reg(gpio, CTRL_OUT),
CTLO_INPUT_SET);
 }
@@ -139,6 +143,9 @@ static int crystalcove_gpio_dir_out(struct gpio_chip *chip, 
unsigned gpio,
 {
struct crystalcove_gpio *cg = to_cg(chip);
 
+   if (gpio > CRYSTALCOVE_VGPIO_NUM)
+   return 0;
+
return regmap_write(cg->regmap, to_reg(gpio, CTRL_OUT),
CTLO_OUTPUT_SET | value);
 }
@@ -149,6 +156,9 @@ static int crystalcove_gpio_get(struct gpio_chip *chip, 
unsigned gpio)
int ret;
unsigned int val;
 
+   if (gpio > CRYSTALCOVE_VGPIO_NUM)
+   return 0;
+
ret = regmap_read(cg->regmap, to_reg(gpio, CTRL_IN), );
if (ret)
return ret;
@@ -161,6 +171,9 @@ static void crystalcove_gpio_set(struct gpio_chip *chip,
 {
struct crystalcove_gpio *cg = to_cg(chip);
 
+   if (gpio > CRYSTALCOVE_VGPIO_NUM)
+   return;
+
if (value)
regmap_update_bits(cg->regmap, to_reg(gpio, CTRL_OUT), 1, 1);
else
@@ -256,7 +269,7 @@ static irqreturn_t crystalcove_gpio_irq_handler(int irq, 
void *data)
 
pending = p0 | p1 << 8;
 
-   for (gpio = 0; gpio < cg->chip.ngpio; gpio++) {
+   for (gpio = 0; gpio < CRYSTALCOVE_GPIO_NUM; gpio++) {
if (pending & BIT(gpio)) {
virq = irq_find_mapping(cg->chip.irqdomain, gpio);
generic_handle_irq(virq);
@@ -273,7 +286,7 @@ static void crystalcove_gpio_dbg_show(struct seq_file *s,
int gpio, offset;
unsigned int ctlo, ctli, mirqs0, mirqsx, irq;
 
-   for (gpio = 0; gpio < cg->chip.ngpio; gpio++) {
+   for (gpio = 0; gpio < CRYSTALCOVE_GPIO_NUM; gpio++) {
regmap_read(cg->regmap, to_reg(gpio, CTRL_OUT), );
regmap_read(cg->regmap, to_reg(gpio, CTRL_IN), );
regmap_read(cg->regmap, gpio < 8 ? MGPIO0IRQS0 : MGPIO1IRQS0,
@@ -320,7 +333,7 @@ static int crystalcove_gpio_probe(struct platform_device 
*pdev)
cg->chip.get = crystalcove_gpio_get;
cg->chip.set = crystalcove_gpio_set;
cg->chip.base = -1;
-   cg->chip.ngpio = CRYSTALCOVE_GPIO_NUM;
+   cg->chip.ngpio = CRYSTALCOVE_VGPIO_NUM;
cg->chip.can_sleep = true;
cg->chip.dev = dev;
cg->chip.dbg_show = crystalcove_gpio_dbg_show;
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index c1d4105e1c1d..383ade1a211b 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -27,7 +27,7 @@
  */
 
 #ifndef ARCH_NR_GPIOS
-#define ARCH_NR_GPIOS  256
+#define ARCH_NR_GPIOS  512
 #endif
 
 /*
-- 
1.9.3

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

[PATCH V4 3/4 resend] xen-pciback: use pci device flag operation helper function

[Ethan Zhao]

Use pci device flag operation helper functions when set device
to assigned or deassigned state.

Acked-by: David Vrabel 
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ethan Zhao 
---
 drivers/xen/xen-pciback/pci_stub.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c 
b/drivers/xen/xen-pciback/pci_stub.c
index d57a173..e593921 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -133,7 +133,7 @@ static void pcistub_device_release(struct kref *kref)
xen_pcibk_config_free_dyn_fields(dev);
xen_pcibk_config_free_dev(dev);
 
-   dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
+   pci_clear_dev_assigned(dev);
pci_dev_put(dev);
 
kfree(psdev);
@@ -413,7 +413,7 @@ static int pcistub_init_device(struct pci_dev *dev)
dev_dbg(>dev, "reset device\n");
xen_pcibk_reset_device(dev);
 
-   dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
+   pci_set_dev_assigned(dev);
return 0;
 
 config_release:
-- 
1.7.1

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

[PATCH V4 4/4 resend] PCI: use device flag operation helper function in iov.c

[Ethan Zhao]

Use device flag operation helper functions when check device
assignment status.

Signed-off-by: Ethan Zhao 
---
 drivers/pci/iov.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index cb6f247..4d109c0 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -633,7 +633,7 @@ int pci_vfs_assigned(struct pci_dev *dev)
 * our dev as the physical function and the assigned bit is set
 */
if (vfdev->is_virtfn && (vfdev->physfn == dev) &&
-   (vfdev->dev_flags & PCI_DEV_FLAGS_ASSIGNED))
+   pci_is_dev_assigned(vfdev))
vfs_assigned++;
 
vfdev = pci_get_device(dev->vendor, dev_id, vfdev);
-- 
1.7.1

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

[PATCH V4 2/4 resend] KVM: use pci device flag operation helper functions

[Ethan Zhao]

Use helper function instead of direct operation to pci device
flag when set device to assigned or deassigned.

Acked-by: Paolo Bonzini 
Signed-off-by: Ethan Zhao 
---
 virt/kvm/assigned-dev.c |2 +-
 virt/kvm/iommu.c|4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
index bf06577..38581ee 100644
--- a/virt/kvm/assigned-dev.c
+++ b/virt/kvm/assigned-dev.c
@@ -302,7 +302,7 @@ static void kvm_free_assigned_device(struct kvm *kvm,
else
pci_restore_state(assigned_dev->dev);
 
-   assigned_dev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
+   pci_clear_dev_assigned(assigned_dev->dev);
 
pci_release_regions(assigned_dev->dev);
pci_disable_device(assigned_dev->dev);
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index 0df7d4b..34a8b02 100644
--- a/virt/kvm/iommu.c
+++ b/virt/kvm/iommu.c
@@ -194,7 +194,7 @@ int kvm_assign_device(struct kvm *kvm,
goto out_unmap;
}
 
-   pdev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
+   pci_set_dev_assigned(pdev);
 
dev_info(>dev, "kvm assign device\n");
 
@@ -220,7 +220,7 @@ int kvm_deassign_device(struct kvm *kvm,
 
iommu_detach_device(domain, >dev);
 
-   pdev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
+   pci_clear_dev_assigned(pdev);
 
dev_info(>dev, "kvm deassign device\n");
 
-- 
1.7.1

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

[PATCH V4 1/4 resend] PCI: introduce helper functions for device flag operation

[Ethan Zhao]

This patch introduced three helper functions to hide direct
device flag operation.

void pci_set_dev_assigned(struct pci_dev *pdev);
void pci_clear_dev_assigned(struct pci_dev *pdev);
bool pci_is_dev_assigned(struct pci_dev *pdev);

Signed-off-by: Ethan Zhao 
---
 v2: simplify unnecessory ternary operation in function pci_is_dev_assigned();
 v3: amend helper functions naming.
 v4: fix incorrect type in return expression warning.
---
 include/linux/pci.h |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 466bcd1..b610ab3 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1829,4 +1829,17 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
  */
 struct pci_dev *pci_find_upstream_pcie_bridge(struct pci_dev *pdev);
 
+/* helper functions for operation of device flag */
+static inline void pci_set_dev_assigned(struct pci_dev *pdev)
+{
+   pdev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
+}
+static inline void pci_clear_dev_assigned(struct pci_dev *pdev)
+{
+   pdev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
+}
+static inline bool pci_is_dev_assigned(struct pci_dev *pdev)
+{
+   return (pdev->dev_flags & PCI_DEV_FLAGS_ASSIGNED) == 
PCI_DEV_FLAGS_ASSIGNED;
+}
 #endif /* LINUX_PCI_H */
-- 
1.7.1

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

[PATCH v4 0/4 resend] Introduce device assignment flag operation helper function

[Ethan Zhao]

This patch set introduces three PCI device flag operation helper functions
when set pci device PF/VF to assigned or deassigned status also check it.
and patch 2,3,4 apply these helper functions to KVM,XEN and PCI.

v2: simplify unnecessory ternary operation in function pci_is_dev_assigned().
v3: amend helper function naming.
v4: fix incorrect type in return expression warning found by Fengguang Wu.

Appreciate suggestion from
alex.william...@redhat.com,
david.vra...@citrix.com,
alexander.h.du...@intel.com

Resend for v3.18 building.

Thanks,
Ethan
---
Ethan Zhao (4):
  PCI: introduce helper functions for device flag operation
  KVM: use pci device flag operation helper functions
  xen-pciback: use pci device flag operation helper function
  PCI: use device flag operation helper function in iov.c

 drivers/pci/iov.c  |2 +-
 drivers/xen/xen-pciback/pci_stub.c |4 ++--
 include/linux/pci.h|   13 +
 virt/kvm/assigned-dev.c|2 +-
 virt/kvm/iommu.c   |4 ++--
 5 files changed, 19 insertions(+), 6 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7] tpm_tis: verify interrupt during init

[Scot Doyle]

Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do
not send IRQs while also having an ACPI TPM entry indicating that they
will be sent. These machines freeze on resume while the tpm_tis module
waits for an IRQ, eventually timing out.

When in interrupt mode, the tpm_tis module should receive an IRQ during
module init. Fall back to polling mode if none is received when expected.

Signed-off-by: Scot Doyle 
Tested-by: Michael Mullin 
Reviewed-By: Jason Gunthorpe 
---
 drivers/char/tpm/tpm_tis.c | 75 +++---
 1 file changed, 57 insertions(+), 18 deletions(-)

diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 2c46734..43aeb6961 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,6 +342,21 @@ 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
@@ -345,8 +364,10 @@ out_err:
  */
 static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, size_t len)
 {
-   int rc;
+   int rc, irq;
u32 ordinal;
+   bool test_irq;
+   struct priv_data *priv = chip->vendor.priv;

rc = tpm_tis_send_data(chip, buf, len);
if (rc < 0)
@@ -358,13 +379,27 @@ static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, 
size_t len)

if (chip->vendor.irq) {
ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
-   if (wait_for_tpm_stat
-   (chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
-tpm_calc_ordinal_duration(chip, ordinal),
->vendor.read_queue, false) < 0) {
+   test_irq = !priv->irq_tested;
+   if (test_irq) {
+   irq = chip->vendor.irq;
+   chip->vendor.irq = 0;
+   }
+   rc = wait_for_tpm_stat
+(chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+ tpm_calc_ordinal_duration(chip, ordinal),
+ >vendor.read_queue, false);
+   if (test_irq)
+   chip->vendor.irq = irq;
+   if (rc < 0) {
rc = -ETIME;
goto out_err;
}
+   if (test_irq && !priv->irq_tested) {
+   priv->irq_tested = true;
+   disable_interrupts(chip);
+   dev_err(chip->dev,
+   FW_BUG "TPM interrupt not working, polling 
instead\n");
+   }
}
return len;
 out_err:
@@ -505,6 +540,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 +570,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 +645,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, "TPM self test failed\n");
-   rc = -ENODEV;
-

Re: 回复： Re: 回复： Re: 回复： Re: 回复： Re: 回复： Re: 回复： Status of 'unicore32' architecture in Linux kernel

[Guenter Roeck]

On 09/08/2014 05:58 PM, Xuetao Guan  wrote:


- Guenter Roeck  写道：

On 09/08/2014 05:57 AM, Xuetao Guan  wrote:

Whatever is more recent. Guess you'll have to either update the toolchain
or the kernel. If the plan is to update the kernel, can you send me a patch
to do that so I can test it ?

Thanks,
Guenter


I'll update unicore kernel at first, and cc patches to you.


Ok.

Thanks,
Guenter


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

[PATCH v2 4/7] mtd: denali: change the type of iterators to int

[Masahiro Yamada]

We should rathar use "int" type for loop iterators.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/mtd/nand/denali.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index dcd6771..259ca0ba 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -178,7 +178,7 @@ static void reset_bank(struct denali_nand_info *denali)
 /* Reset the flash controller */
 static uint16_t denali_nand_reset(struct denali_nand_info *denali)
 {
-   uint32_t i;
+   int i;
 
dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
   __FILE__, __LINE__, __func__);
@@ -499,7 +499,8 @@ static uint16_t denali_nand_timing_set(struct 
denali_nand_info *denali)
 {
uint16_t status = PASS;
uint32_t id_bytes[8], addr;
-   uint8_t i, maf_id, device_id;
+   uint8_t maf_id, device_id;
+   int i;
 
dev_dbg(denali->dev,
"%s, Line %d, Function: %s\n",
@@ -830,7 +831,8 @@ static int write_data_to_flash_mem(struct denali_nand_info 
*denali,
const uint8_t *buf,
int len)
 {
-   uint32_t i, *buf32;
+   uint32_t *buf32;
+   int i;
 
/*
 * verify that the len is a multiple of 4.
@@ -850,7 +852,8 @@ static int read_data_from_flash_mem(struct denali_nand_info 
*denali,
uint8_t *buf,
int len)
 {
-   uint32_t i, *buf32;
+   uint32_t *buf32;
+   int i;
 
/*
 * we assume that len will be a multiple of 4, if not it would be nice
-- 
1.9.1

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

[PATCH v2 6/7] mtd: denali: remove unnecessary parentheses

[Masahiro Yamada]

We should use parentheses only when they are necessary
or they really improve the readability.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Josh Triplett 
---

Changes in v2: None

 drivers/mtd/nand/denali.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index d37c2e1..ed37b76 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -267,10 +267,10 @@ static void nand_onfi_timing_set(struct denali_nand_info 
*denali,
 
acc_clks = CEIL_DIV(Trea[mode], CLK_X);
 
-   while (((acc_clks * CLK_X) - Trea[mode]) < 3)
+   while (acc_clks * CLK_X - Trea[mode] < 3)
acc_clks++;
 
-   if ((data_invalid - acc_clks * CLK_X) < 2)
+   if (data_invalid - acc_clks * CLK_X < 2)
dev_warn(denali->dev, "%s, Line %d: Warning!\n",
__FILE__, __LINE__);
 
@@ -285,7 +285,7 @@ static void nand_onfi_timing_set(struct denali_nand_info 
*denali,
cs_cnt = 1;
 
if (Tcea[mode]) {
-   while (((cs_cnt * CLK_X) + Trea[mode]) < Tcea[mode])
+   while (cs_cnt * CLK_X + Trea[mode] < Tcea[mode])
cs_cnt++;
}
 
@@ -295,8 +295,8 @@ static void nand_onfi_timing_set(struct denali_nand_info 
*denali,
 #endif
 
/* Sighting 3462430: Temporary hack for MT29F128G08CJABAWP:B */
-   if ((ioread32(denali->flash_reg + MANUFACTURER_ID) == 0) &&
-   (ioread32(denali->flash_reg + DEVICE_ID) == 0x88))
+   if (ioread32(denali->flash_reg + MANUFACTURER_ID) == 0 &&
+   ioread32(denali->flash_reg + DEVICE_ID) == 0x88)
acc_clks = 6;
 
iowrite32(acc_clks, denali->flash_reg + ACC_CLKS);
@@ -577,7 +577,7 @@ static void denali_set_intr_modes(struct denali_nand_info 
*denali,
  */
 static inline bool is_flash_bank_valid(int flash_bank)
 {
-   return (flash_bank >= 0 && flash_bank < 4);
+   return flash_bank >= 0 && flash_bank < 4;
 }
 
 static void denali_irq_init(struct denali_nand_info *denali)
@@ -1103,7 +1103,7 @@ static int write_page(struct mtd_info *mtd, struct 
nand_chip *chip,
"timeout on write_page (type = %d)\n",
raw_xfer);
denali->status =
-   (irq_status & INTR_STATUS__PROGRAM_FAIL) ?
+   irq_status & INTR_STATUS__PROGRAM_FAIL ?
NAND_STATUS_FAIL : PASS;
}
 
@@ -1296,7 +1296,7 @@ static int denali_erase(struct mtd_info *mtd, int page)
irq_status = wait_for_irq(denali, INTR_STATUS__ERASE_COMP |
INTR_STATUS__ERASE_FAIL);
 
-   return (irq_status & INTR_STATUS__ERASE_FAIL) ? NAND_STATUS_FAIL : PASS;
+   return irq_status & INTR_STATUS__ERASE_FAIL ? NAND_STATUS_FAIL : PASS;
 }
 
 static void denali_cmdfunc(struct mtd_info *mtd, unsigned int cmd, int col,
-- 
1.9.1

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

[PATCH v2 5/7] mtd: denali: remove a set-but-unused variable

[Masahiro Yamada]

The variable "retry" in wait_for_irq() is set, but not used.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Josh Triplett 
---

Changes in v2: None

 drivers/mtd/nand/denali.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 259ca0ba..d37c2e1 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -697,7 +697,6 @@ static uint32_t wait_for_irq(struct denali_nand_info 
*denali, uint32_t irq_mask)
 {
unsigned long comp_res;
uint32_t intr_status;
-   bool retry = false;
unsigned long timeout = msecs_to_jiffies(1000);
 
do {
@@ -717,7 +716,6 @@ static uint32_t wait_for_irq(struct denali_nand_info 
*denali, uint32_t irq_mask)
 * need to wait again
 */
spin_unlock_irq(>irq_lock);
-   retry = true;
}
} while (comp_res != 0);
 
-- 
1.9.1

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

[PATCH v2 1/7] mtd: denali: fix the format of comment blocks

[Masahiro Yamada]

We should use
/*
 * Blah Blah ...
 * ...
 */

for multi-line comment blocks.

In addition, refactor some comments where it seems reasonable and
remove some comments where the code is clear enough such as:

/* clear interrupts */
clear_interrupts(denali);

Signed-off-by: Masahiro Yamada 
Reviewed-by: Josh Triplett 
---

Changes in v2: None

 drivers/mtd/nand/denali.c | 311 --
 1 file changed, 188 insertions(+), 123 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index da0fcc2..44a5f159 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -29,7 +29,8 @@
 
 MODULE_LICENSE("GPL");
 
-/* We define a module parameter that allows the user to override
+/*
+ * We define a module parameter that allows the user to override
  * the hardware and decide what timing mode should be used.
  */
 #define NAND_DEFAULT_TIMINGS   -1
@@ -41,8 +42,10 @@ MODULE_PARM_DESC(onfi_timing_mode, "Overrides default ONFI 
setting."
 
 #define DENALI_NAND_NAME"denali-nand"
 
-/* We define a macro here that combines all interrupts this driver uses into
- * a single constant value, for convenience. */
+/*
+ * We define a macro here that combines all interrupts this driver uses into
+ * a single constant value, for convenience.
+ */
 #define DENALI_IRQ_ALL (INTR_STATUS__DMA_CMD_COMP | \
INTR_STATUS__ECC_TRANSACTION_DONE | \
INTR_STATUS__ECC_ERR | \
@@ -54,23 +57,30 @@ MODULE_PARM_DESC(onfi_timing_mode, "Overrides default ONFI 
setting."
INTR_STATUS__RST_COMP | \
INTR_STATUS__ERASE_COMP)
 
-/* indicates whether or not the internal value for the flash bank is
- * valid or not */
+/*
+ * indicates whether or not the internal value for the flash bank is
+ * valid or not
+ */
 #define CHIP_SELECT_INVALID-1
 
 #define SUPPORT_8BITECC1
 
-/* This macro divides two integers and rounds fractional values up
- * to the nearest integer value. */
+/*
+ * This macro divides two integers and rounds fractional values up
+ * to the nearest integer value.
+ */
 #define CEIL_DIV(X, Y) (((X)%(Y)) ? ((X)/(Y)+1) : ((X)/(Y)))
 
-/* this macro allows us to convert from an MTD structure to our own
+/*
+ * this macro allows us to convert from an MTD structure to our own
  * device context (denali) structure.
  */
 #define mtd_to_denali(m) container_of(m, struct denali_nand_info, mtd)
 
-/* These constants are defined by the driver to enable common driver
- * configuration options. */
+/*
+ * These constants are defined by the driver to enable common driver
+ * configuration options.
+ */
 #define SPARE_ACCESS   0x41
 #define MAIN_ACCESS0x42
 #define MAIN_SPARE_ACCESS  0x43
@@ -84,8 +94,10 @@ MODULE_PARM_DESC(onfi_timing_mode, "Overrides default ONFI 
setting."
 #define ADDR_CYCLE 1
 #define STATUS_CYCLE   2
 
-/* this is a helper macro that allows us to
- * format the bank into the proper bits for the controller */
+/*
+ * this is a helper macro that allows us to
+ * format the bank into the proper bits for the controller
+ */
 #define BANK(x) ((x) << 24)
 
 /* forward declarations */
@@ -96,12 +108,12 @@ static void denali_irq_enable(struct denali_nand_info 
*denali,
uint32_t int_mask);
 static uint32_t read_interrupt_status(struct denali_nand_info *denali);
 
-/* Certain operations for the denali NAND controller use
- * an indexed mode to read/write data. The operation is
- * performed by writing the address value of the command
- * to the device memory followed by the data. This function
+/*
+ * Certain operations for the denali NAND controller use an indexed mode to
+ * read/write data. The operation is performed by writing the address value
+ * of the command to the device memory followed by the data. This function
  * abstracts this common operation.
-*/
+ */
 static void index_addr(struct denali_nand_info *denali,
uint32_t address, uint32_t data)
 {
@@ -117,8 +129,10 @@ static void index_addr_read_data(struct denali_nand_info 
*denali,
*pdata = ioread32(denali->flash_mem + 0x10);
 }
 
-/* We need to buffer some data for some of the NAND core routines.
- * The operations manage buffering that data. */
+/*
+ * We need to buffer some data for some of the NAND core routines.
+ * The operations manage buffering that data.
+ */
 static void reset_buf(struct denali_nand_info *denali)
 {
denali->buf.head = denali->buf.tail = 0;
@@ -192,7 +206,8 @@ static uint16_t denali_nand_reset(struct denali_nand_info 
*denali)
return PASS;
 }
 
-/* this routine calculates the ONFI timing values for a given mode and
+/*
+ * this routine calculates the ONFI timing values for a given mode and
  * programs the clocking register accordingly. The mode is determined by
  * the get_onfi_nand_para routine.
  */
@@ -298,9 +313,11 @@ 

[PATCH v2 7/7] mtd: denali: fix indents and other trivial things

[Masahiro Yamada]

- Fix indents
- Do not break a line unless it is longer than 80 columns
- Do not insert a whitespace before ';'
- Use whitespaces around operators
- Use braces for a "else" block where the "if" block uses ones.

Besides, eliminate all the warnings reported by checkpatch.pl:
- WARNING: quoted string split across lines
- WARNING: else is not generally useful after a break or return
- WARNING: Missing a blank line after declarations
- WARNING: Avoid line continuations in quoted strings

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Join quotes strings into a single line

 drivers/mtd/nand/denali.c | 143 --
 1 file changed, 63 insertions(+), 80 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index ed37b76..9da5432 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -37,8 +37,8 @@ MODULE_LICENSE("GPL");
 
 static int onfi_timing_mode = NAND_DEFAULT_TIMINGS;
 module_param(onfi_timing_mode, int, S_IRUGO);
-MODULE_PARM_DESC(onfi_timing_mode, "Overrides default ONFI setting."
-   " -1 indicates use default timings");
+MODULE_PARM_DESC(onfi_timing_mode,
+  "Overrides default ONFI setting. -1 indicates use default timings");
 
 #define DENALI_NAND_NAME"denali-nand"
 
@@ -162,8 +162,7 @@ static void read_status(struct denali_nand_info *denali)
 static void reset_bank(struct denali_nand_info *denali)
 {
uint32_t irq_status;
-   uint32_t irq_mask = INTR_STATUS__RST_COMP |
-   INTR_STATUS__TIME_OUT;
+   uint32_t irq_mask = INTR_STATUS__RST_COMP | INTR_STATUS__TIME_OUT;
 
clear_interrupts(denali);
 
@@ -181,16 +180,15 @@ static uint16_t denali_nand_reset(struct denali_nand_info 
*denali)
int i;
 
dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
-  __FILE__, __LINE__, __func__);
+   __FILE__, __LINE__, __func__);
 
-   for (i = 0 ; i < denali->max_banks; i++)
+   for (i = 0; i < denali->max_banks; i++)
iowrite32(INTR_STATUS__RST_COMP | INTR_STATUS__TIME_OUT,
denali->flash_reg + INTR_STATUS(i));
 
-   for (i = 0 ; i < denali->max_banks; i++) {
+   for (i = 0; i < denali->max_banks; i++) {
iowrite32(1 << i, denali->flash_reg + DEVICE_RESET);
-   while (!(ioread32(denali->flash_reg +
-   INTR_STATUS(i)) &
+   while (!(ioread32(denali->flash_reg + INTR_STATUS(i)) &
(INTR_STATUS__RST_COMP | INTR_STATUS__TIME_OUT)))
cpu_relax();
if (ioread32(denali->flash_reg + INTR_STATUS(i)) &
@@ -201,7 +199,7 @@ static uint16_t denali_nand_reset(struct denali_nand_info 
*denali)
 
for (i = 0; i < denali->max_banks; i++)
iowrite32(INTR_STATUS__RST_COMP | INTR_STATUS__TIME_OUT,
-   denali->flash_reg + INTR_STATUS(i));
+ denali->flash_reg + INTR_STATUS(i));
 
return PASS;
 }
@@ -235,7 +233,7 @@ static void nand_onfi_timing_set(struct denali_nand_info 
*denali,
uint16_t addr_2_data, re_2_we, re_2_re, we_2_re, cs_cnt;
 
dev_dbg(denali->dev, "%s, Line %d, Function: %s\n",
-  __FILE__, __LINE__, __func__);
+   __FILE__, __LINE__, __func__);
 
en_lo = CEIL_DIV(Trp[mode], CLK_X);
en_hi = CEIL_DIV(Treh[mode], CLK_X);
@@ -255,9 +253,8 @@ static void nand_onfi_timing_set(struct denali_nand_info 
*denali,
 
data_invalid_rloh = (en_lo + en_hi) * CLK_X + Trloh[mode];
 
-   data_invalid =
-   data_invalid_rhoh <
-   data_invalid_rloh ? data_invalid_rhoh : data_invalid_rloh;
+   data_invalid = data_invalid_rhoh < data_invalid_rloh ?
+   data_invalid_rhoh : data_invalid_rloh;
 
dv_window = data_invalid - Trea[mode];
 
@@ -272,7 +269,7 @@ static void nand_onfi_timing_set(struct denali_nand_info 
*denali,
 
if (data_invalid - acc_clks * CLK_X < 2)
dev_warn(denali->dev, "%s, Line %d: Warning!\n",
-   __FILE__, __LINE__);
+__FILE__, __LINE__);
 
addr_2_data = CEIL_DIV(Tadl[mode], CLK_X);
re_2_we = CEIL_DIV(Trhw[mode], CLK_X);
@@ -406,9 +403,9 @@ static void get_hynix_nand_para(struct denali_nand_info 
*denali,
break;
default:
dev_warn(denali->dev,
-   "Spectra: Unknown Hynix NAND (Device ID: 0x%x)."
-   "Will use default parameter values instead.\n",
-   device_id);
+"Spectra: Unknown Hynix NAND (Device ID: 0x%x).\n"
+"Will use default parameter values instead.\n",
+device_id);
}
 }
 
@@ -425,8 +422,7 @@ static void 

[PATCH v2 0/7] mtd: denali: A collection of trivial coding style fixes

[Masahiro Yamada]

Changes in v2:
  - Join quotes strings into a single line

Masahiro Yamada (7):
  mtd: denali: fix the format of comment blocks
  mtd: denali: remove unnecessary variable initializations
  mtd: denali: remove unnecessary casts
  mtd: denali: change the type of iterators to int
  mtd: denali: remove a set-but-unused variable
  mtd: denali: remove unnecessary parentheses
  mtd: denali: fix indents and other trivial things

 drivers/mtd/nand/denali.c | 562 +-
 1 file changed, 303 insertions(+), 259 deletions(-)

-- 
1.9.1

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

[PATCH v2 3/7] mtd: denali: remove unnecessary casts

[Masahiro Yamada]

Useless casts result in unreadable source code.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/mtd/nand/denali.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 3836828..dcd6771 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -423,10 +423,10 @@ static void find_valid_banks(struct denali_nand_info 
*denali)
 
denali->total_used_banks = 1;
for (i = 0; i < denali->max_banks; i++) {
-   index_addr(denali, (uint32_t)(MODE_11 | (i << 24) | 0), 0x90);
-   index_addr(denali, (uint32_t)(MODE_11 | (i << 24) | 1), 0);
+   index_addr(denali, MODE_11 | (i << 24) | 0, 0x90);
+   index_addr(denali, MODE_11 | (i << 24) | 1, 0);
index_addr_read_data(denali,
-   (uint32_t)(MODE_11 | (i << 24) | 2), [i]);
+   MODE_11 | (i << 24) | 2, [i]);
 
dev_dbg(denali->dev,
"Return 1st ID for bank[%d]: %x\n", i, id[i]);
@@ -510,9 +510,9 @@ static uint16_t denali_nand_timing_set(struct 
denali_nand_info *denali)
 * For some NAND chips, controller can't report the correct
 * device ID by reading from DEVICE_ID register
 */
-   addr = (uint32_t)MODE_11 | BANK(denali->flash_bank);
-   index_addr(denali, (uint32_t)addr | 0, 0x90);
-   index_addr(denali, (uint32_t)addr | 1, 0);
+   addr = MODE_11 | BANK(denali->flash_bank);
+   index_addr(denali, addr | 0, 0x90);
+   index_addr(denali, addr | 1, 0);
for (i = 0; i < 8; i++)
index_addr_read_data(denali, addr | 2, _bytes[i]);
maf_id = id_bytes[0];
@@ -782,14 +782,14 @@ static int denali_send_pipeline_cmd(struct 
denali_nand_info *denali,
} else if (op == DENALI_WRITE && access_type == SPARE_ACCESS) {
/* read spare area */
cmd = MODE_10 | addr;
-   index_addr(denali, (uint32_t)cmd, access_type);
+   index_addr(denali, cmd, access_type);
 
cmd = MODE_01 | addr;
iowrite32(cmd, denali->flash_mem);
} else if (op == DENALI_READ) {
/* setup page read request for access type */
cmd = MODE_10 | addr;
-   index_addr(denali, (uint32_t)cmd, access_type);
+   index_addr(denali, cmd, access_type);
 
/*
 * page 33 of the NAND controller spec indicates we should not
@@ -800,7 +800,7 @@ static int denali_send_pipeline_cmd(struct denali_nand_info 
*denali,
cmd = MODE_01 | addr;
iowrite32(cmd, denali->flash_mem);
} else {
-   index_addr(denali, (uint32_t)cmd,
+   index_addr(denali, cmd,
PIPELINE_ACCESS | op | page_count);
 
/*
@@ -929,7 +929,7 @@ static void read_oob_data(struct mtd_info *mtd, uint8_t 
*buf, int page)
 */
addr = BANK(denali->flash_bank) | denali->page;
cmd = MODE_10 | addr;
-   index_addr(denali, (uint32_t)cmd, MAIN_ACCESS);
+   index_addr(denali, cmd, MAIN_ACCESS);
}
 }
 
@@ -1035,7 +1035,7 @@ static void denali_setup_dma(struct denali_nand_info 
*denali, int op)
 {
uint32_t mode;
const int page_count = 1;
-   dma_addr_t addr = denali->buf.dma_buf;
+   uint32_t addr = denali->buf.dma_buf;
 
mode = MODE_10 | BANK(denali->flash_bank);
 
@@ -1045,10 +1045,10 @@ static void denali_setup_dma(struct denali_nand_info 
*denali, int op)
index_addr(denali, mode | denali->page, 0x2000 | op | page_count);
 
/* 2. set memory high address bits 23:8 */
-   index_addr(denali, mode | ((uint16_t)(addr >> 16) << 8), 0x2200);
+   index_addr(denali, mode | ((addr >> 16) << 8), 0x2200);
 
/* 3. set memory low address bits 23:8 */
-   index_addr(denali, mode | ((uint16_t)addr << 8), 0x2300);
+   index_addr(denali, mode | ((addr & 0xff) << 8), 0x2300);
 
/* 4. interrupt when complete, burst len = 64 bytes */
index_addr(denali, mode | 0x14000, 0x2400);
@@ -1289,7 +1289,7 @@ static int denali_erase(struct mtd_info *mtd, int page)
 
/* setup page read request for access type */
cmd = MODE_10 | BANK(denali->flash_bank) | page;
-   index_addr(denali, (uint32_t)cmd, 0x1);
+   index_addr(denali, cmd, 0x1);
 
/* wait for erase to complete or failure to occur */
irq_status = wait_for_irq(denali, INTR_STATUS__ERASE_COMP |
@@ -1319,12 +1319,12 @@ static void denali_cmdfunc(struct mtd_info *mtd, 
unsigned int cmd, int col,
 * e.g. some of Micron MT29F32G08QAA MLC NAND chips
 * So here we send READID cmd to NAND insteand
 

[PATCH v2 2/7] mtd: denali: remove unnecessary variable initializations

[Masahiro Yamada]

All of these variables are initialized to zero and then
set to a different value below.
Zero-initializing is redundant.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/mtd/nand/denali.c | 59 ++-
 1 file changed, 27 insertions(+), 32 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 44a5f159..3836828 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -146,7 +146,7 @@ static void write_byte_to_buf(struct denali_nand_info 
*denali, uint8_t byte)
 /* reads the status of the device */
 static void read_status(struct denali_nand_info *denali)
 {
-   uint32_t cmd = 0x0;
+   uint32_t cmd;
 
/* initialize the data buffer to store status */
reset_buf(denali);
@@ -161,7 +161,7 @@ static void read_status(struct denali_nand_info *denali)
 /* resets a specific device connected to the core */
 static void reset_bank(struct denali_nand_info *denali)
 {
-   uint32_t irq_status = 0;
+   uint32_t irq_status;
uint32_t irq_mask = INTR_STATUS__RST_COMP |
INTR_STATUS__TIME_OUT;
 
@@ -581,7 +581,7 @@ static inline bool is_flash_bank_valid(int flash_bank)
 
 static void denali_irq_init(struct denali_nand_info *denali)
 {
-   uint32_t int_mask = 0;
+   uint32_t int_mask;
int i;
 
/* Disable global interrupts */
@@ -624,7 +624,7 @@ static inline uint32_t denali_irq_detected(struct 
denali_nand_info *denali)
 static inline void clear_interrupt(struct denali_nand_info *denali,
uint32_t irq_mask)
 {
-   uint32_t intr_status_reg = 0;
+   uint32_t intr_status_reg;
 
intr_status_reg = INTR_STATUS(denali->flash_bank);
 
@@ -633,7 +633,8 @@ static inline void clear_interrupt(struct denali_nand_info 
*denali,
 
 static void clear_interrupts(struct denali_nand_info *denali)
 {
-   uint32_t status = 0x0;
+   uint32_t status;
+
spin_lock_irq(>irq_lock);
 
status = read_interrupt_status(denali);
@@ -645,7 +646,7 @@ static void clear_interrupts(struct denali_nand_info 
*denali)
 
 static uint32_t read_interrupt_status(struct denali_nand_info *denali)
 {
-   uint32_t intr_status_reg = 0;
+   uint32_t intr_status_reg;
 
intr_status_reg = INTR_STATUS(denali->flash_bank);
 
@@ -659,7 +660,7 @@ static uint32_t read_interrupt_status(struct 
denali_nand_info *denali)
 static irqreturn_t denali_isr(int irq, void *dev_id)
 {
struct denali_nand_info *denali = dev_id;
-   uint32_t irq_status = 0x0;
+   uint32_t irq_status;
irqreturn_t result = IRQ_NONE;
 
spin_lock(>irq_lock);
@@ -693,8 +694,8 @@ static irqreturn_t denali_isr(int irq, void *dev_id)
 
 static uint32_t wait_for_irq(struct denali_nand_info *denali, uint32_t 
irq_mask)
 {
-   unsigned long comp_res = 0;
-   uint32_t intr_status = 0;
+   unsigned long comp_res;
+   uint32_t intr_status;
bool retry = false;
unsigned long timeout = msecs_to_jiffies(1000);
 
@@ -736,7 +737,7 @@ static uint32_t wait_for_irq(struct denali_nand_info 
*denali, uint32_t irq_mask)
 static void setup_ecc_for_xfer(struct denali_nand_info *denali, bool ecc_en,
bool transfer_spare)
 {
-   int ecc_en_flag = 0, transfer_spare_flag = 0;
+   int ecc_en_flag, transfer_spare_flag;
 
/* set ECC, transfer spare bits if needed */
ecc_en_flag = ecc_en ? ECC_ENABLE__FLAG : 0;
@@ -759,8 +760,8 @@ static int denali_send_pipeline_cmd(struct denali_nand_info 
*denali,
int op)
 {
int status = PASS;
-   uint32_t addr = 0x0, cmd = 0x0, page_count = 1, irq_status = 0,
-irq_mask = 0;
+   uint32_t page_count = 1;
+   uint32_t addr, cmd, irq_status, irq_mask;
 
if (op == DENALI_READ)
irq_mask = INTR_STATUS__LOAD_COMP;
@@ -829,7 +830,7 @@ static int write_data_to_flash_mem(struct denali_nand_info 
*denali,
const uint8_t *buf,
int len)
 {
-   uint32_t i = 0, *buf32;
+   uint32_t i, *buf32;
 
/*
 * verify that the len is a multiple of 4.
@@ -849,7 +850,7 @@ static int read_data_from_flash_mem(struct denali_nand_info 
*denali,
uint8_t *buf,
int len)
 {
-   uint32_t i = 0, *buf32;
+   uint32_t i, *buf32;
 
/*
 * we assume that len will be a multiple of 4, if not it would be nice
@@ -870,7 +871,7 @@ static int read_data_from_flash_mem(struct denali_nand_info 
*denali,
 static int write_oob_data(struct mtd_info *mtd, uint8_t *buf, int page)
 {
struct denali_nand_info *denali = mtd_to_denali(mtd);
-   

Re: [PATCH v3 00/29] nios2 Linux kernel port

[Al Viro]

On Mon, Sep 08, 2014 at 05:22:11PM +0800, Ley Foon Tan wrote:
> This is the 3rd version of patchset adds the Linux kernel port for Nios II 
> processor from
> Altera. All of the feedback from v2 patchseries has been addressed. Thanks to 
> all who
> provided feedback on the previous version.

a) signal caught in rt_sigreturn() (e.g. from change of the set of blocked
signals) should *NOT* trigger syscall restart.  IOW, wrt syscall restart
logics, rt_sigreturn() acts as exception, not as a syscall.  You are
setting ->orig_r2 to -1, but that doesn't affect your syscall restart
logics.

As the matter of fact, your 'in_syscall' argument is bogus - it's always
1.  For return from interrupt as well as that from syscall.  And syscall
restart logics _really_ shouldn't apply to return from interrupts - it's
not only wrong, but very hard to debug.

b) multiple pending signals should be all handled before return to
userland.  Only the first one might have syscall restart logics triggered.
The effect should be identical to what you'd get if e.g. a timer interrupt
had hit just as you were returning to userland (possibly into handler)
after handling the first one, etc.  At the absolute least, SIGSEGV from
failing attempt to build a sigframe should be handled before returning
to userland.

c) rt_sigreturn() should reset ->restart_block.fn to do_no_restart_syscall

d) what's
+   regs->estatus = (regs->estatus & 0x);
in rt_restore_ucontext() about?

e) restart in handlerless case is better off without leaving the kernel
mode.  See what e.g. arm and s390 are doing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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

[Paul E. McKenney]

On Mon, Sep 08, 2014 at 06:47:35PM -0400, Peter Hurley wrote:
> On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
> > On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
> >> On Fri, 05 Sep 2014 08:41:52 -0700
> >> "H. Peter Anvin"  wrote:
> >>
> >>> On 09/05/2014 08:31 AM, Peter Hurley wrote:
> 
>  Which is a bit ironic because I remember when Digital had a team
>  working on emulating native x86 apps on Alpha/NT.
> 
> >>>
> >>> Right, because the x86 architecture was obsolete and would never scale...
> >>
> >> Talking about "not scaling" can anyone explain how a "you need to use
> >> set_bit() and friends" bug report scaled into a hundred message plus
> >> discussion about ambiguous properties of processors (and nobody has
> >> audited all the embedded platforms we support yet, or the weirder ARMs)
> >> and a propsal to remove Alpha support.
> >>
> >> Wouldn't it be *much* simpler to do what I suggested in the first place
> >> and use the existing intended for purpose, deliberately put there,
> >> functions for atomic bitops, because they are fast on sane processors and
> >> they work on everything else.
> >>
> >> I think the whole "removing Alpha EV5" support is basically bonkers. Just
> >> use set_bit in the tty layer. Alpha will continue to work as well as it
> >> always has done and you won't design out support for any future processor
> >> that turns out not to do byte aligned stores.
> >>
> >> Alan
> >>
> > 
> > Is *that* what we are talking about?  I was added to this conversation
> > in the middle where it had already generalized, so I had no idea.
> 
> No, this is just what brought this craziness to my attention.
> 
> For example, byte- and short-sized circular buffers could not possibly
> be safe either, when the head nears the tail.
> 
> Who has audited global storage and ensured that _every_ byte-sized write
> doesn't happen to be adjacent to some other storage that may not happen
> to be protected by the same (or any) lock?

This was my concern as well.

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2 1/4] Clocksource: Flextimer: Use internal clocksource read API.

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

Hi Thomas,

Okay.

I will try to fix this.

Thanks,

BRs
Xiubo




> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Friday, September 05, 2014 11:40 PM
> To: Xiubo Li-B47053
> Cc: daniel.lezc...@linaro.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCHv2 1/4] Clocksource: Flextimer: Use internal clocksource
> read API.
> 
> On Fri, 5 Sep 2014, Xiubo Li wrote:
> 
> > Since the Flextimer device will be implemented in BE mode on
> > LS1 SoC, and in LE mode on Vybrid, LS2 SoCs, so here we need
> > the endianness judgment before doing the mmio.
> 
> WTF? I explained you in great length HOW you should solve that, but
> you just ignore it. Instead of trying to understand what I say you
> just resend the same nonsense again.
> 
> Keep that attitude up, if you want to make sure, that your patches are
> ignored in the future.
> 
> Thanks,
> 
>   tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers: staging: rtl8723au: Fix 'code indent should use tabs where possible' errors

[Greg Donald]

Fix checkpatch.pl 'code indent should use tabs where possible' errors

Signed-off-by: Greg Donald 
---
 drivers/staging/rtl8723au/core/rtw_cmd.c   |  4 ++--
 drivers/staging/rtl8723au/core/rtw_led.c   |  2 +-
 drivers/staging/rtl8723au/core/rtw_mlme.c  | 12 ++--
 drivers/staging/rtl8723au/core/rtw_mlme_ext.c  |  6 +++---
 drivers/staging/rtl8723au/core/rtw_recv.c  | 10 +-
 drivers/staging/rtl8723au/core/rtw_security.c  | 10 +++---
 drivers/staging/rtl8723au/core/rtw_wlan_util.c |  2 +-
 drivers/staging/rtl8723au/core/rtw_xmit.c  |  4 ++--
 drivers/staging/rtl8723au/include/ieee80211.h  | 14 +++---
 drivers/staging/rtl8723au/include/rtw_cmd.h| 10 +-
 10 files changed, 35 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c 
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index 9fd9b10..4eaa502 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -717,11 +717,11 @@ int rtw_setstakey_cmd23a(struct rtw_adapter *padapter, u8 
*psta, u8 unicast_key)
 
if (unicast_key == true) {
memcpy(_para->key, >dot118021x_UncstKey, 16);
-} else {
+   } else {
int idx = psecuritypriv->dot118021XGrpKeyid;
memcpy(_para->key,
   >dot118021XGrpKey[idx].skey, 16);
-}
+   }
 
/* jeff: set this because at least sw key is ready */
padapter->securitypriv.busetkipkey = 1;
diff --git a/drivers/staging/rtl8723au/core/rtw_led.c 
b/drivers/staging/rtl8723au/core/rtw_led.c
index e21a42c5..989cda2 100644
--- a/drivers/staging/rtl8723au/core/rtw_led.c
+++ b/drivers/staging/rtl8723au/core/rtw_led.c
@@ -1842,7 +1842,7 @@ LedControl871x23a(struct rtw_adapter *padapter, enum 
led_ctl_mode LedAction) {
if ((padapter->bSurpriseRemoved == true) ||
(padapter->bDriverStopped == true) ||
(padapter->hw_init_completed == false)) {
- return;
+   return;
}
 
if (ledpriv->bRegUseLed == false)
diff --git a/drivers/staging/rtl8723au/core/rtw_mlme.c 
b/drivers/staging/rtl8723au/core/rtw_mlme.c
index 099ef8c..99fbb5c 100644
--- a/drivers/staging/rtl8723au/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723au/core/rtw_mlme.c
@@ -159,7 +159,7 @@ rtw_find_network23a(struct rtw_queue *scanned_queue, u8 
*addr)
break;
 
plist = plist->next;
-}
+   }
 
if (plist == phead)
pnetwork = NULL;
@@ -556,7 +556,7 @@ static int rtw_is_desired_network(struct rtw_adapter 
*adapter,
/* for  correct flow of 8021X  to do */
if (desired_encmode == Ndis802_11EncryptionDisabled &&
privacy != 0)
-   bselected = false;
+   bselected = false;
}
 
if (desired_encmode != Ndis802_11EncryptionDisabled && privacy == 0) {
@@ -637,7 +637,7 @@ void rtw_survey_event_cb23a(struct rtw_adapter *adapter, 
const u8 *pbuf)
 
/*  lock pmlmepriv->lock when you accessing network_q */
if (!check_fwstate(pmlmepriv, _FW_UNDER_LINKING)) {
-   if (pnetwork->Ssid.ssid[0] == 0)
+   if (pnetwork->Ssid.ssid[0] == 0)
pnetwork->Ssid.ssid_len = 0;
 
rtw_add_network(adapter, pnetwork);
@@ -743,7 +743,7 @@ static void free_scanqueue(struct mlme_priv *pmlmepriv)
pnetwork = container_of(plist, struct wlan_network, list);
pnetwork->fixed = false;
_rtw_free_network23a(pmlmepriv, pnetwork);
-}
+   }
 
spin_unlock_bh(_queue->lock);
 }
@@ -855,7 +855,7 @@ void rtw_indicate_disconnect23a(struct rtw_adapter 
*padapter)
 
_clr_fwstate_(pmlmepriv, _FW_UNDER_LINKING|WIFI_UNDER_WPS);
 
-/* DBG_8723A("clear wps when %s\n", __func__); */
+   /* DBG_8723A("clear wps when %s\n", __func__); */
 
if (padapter->mlmepriv.to_roaming > 0)
_clr_fwstate_(pmlmepriv, _FW_LINKED);
@@ -1351,7 +1351,7 @@ void rtw_stadel_event_callback23a(struct rtw_adapter 
*adapter, const u8 *pbuf)
DBG_8723A("%s(mac_id=%d)=" MAC_FMT "\n", __func__, mac_id,
  MAC_ARG(pstadel->macaddr));
 
-if (check_fwstate(pmlmepriv, WIFI_AP_STATE))
+   if (check_fwstate(pmlmepriv, WIFI_AP_STATE))
return;
 
mlmeext_sta_del_event_callback23a(adapter);
diff --git a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
index 23621a8..fcba087 100644
--- a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
@@ -625,7 +625,7 @@ _mgt_dispatcher23a(struct rtw_adapter *padapter, struct 
mlme_handler *ptable,
return;
 
ptable->func(padapter, precv_frame);
-}
+   }
 }
 
 void mgt_dispatcher23a(struct rtw_adapter 

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

[Chen, Alvin]

> On Friday 05 September 2014 12:02:01 Shevchenko, Andriy wrote:
> > > irq = irq_of_parse_and_map(node, 0); If (!irq) {
> > > pp->irq = -1;
> > > return;
> > > } else {
> > > pp->irq = irq;
> > > }
> > > Then the code looks strange.
> > >
> > > How do you think?
> >
> > If I understood correctly you messed up with hwirq vs. virq.
> > Otherwise you have mention that you are using virq everywhere (I guess
> > you may rename the field in the structure), but in this case the field
> > in the platform_data looks a bit strange.
> 
> The field in platform_data should be the mapped virtual irq number, it makes 
> no
> sense to use the hwirq unless you also add a pointer to the domain in which
> that hwirq exists.
> 
> Also the output of irq_of_parse_and_map() is a mapped irq, as the name
> suggests.
> 
I agree with Arnd. Here, the 'irq' is 'virq'.
Andriy, you may be confused by the code like 'irq_create_mapping'. For Quark 
case, it has 8 GPIO pins, and each pin can trigger
interrupt, but all these interrupts are triggered by PCI irq which is shared. 
The 'irq' in pdata is PCI irq. As all GPIO interrupts connect to the PCI
irq, once the GPIO interrupt is triggered, and the PCI irq handler will be 
called 'dwapb_irq_handler_mfd'. And in 'dwapb_do_irq', it will read the
interrupt register to see the interrupt is triggered by which GPIO pin, and 
'irq_create_mapping' is for this case.


.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi  wrote:
> Hi,
>
> On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote:
>> On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi  wrote:
>> > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote:
>> >> > Don't we have phy_power_on()
>> >> > for that ? It looks like you could just as well do this from
>> >> > phy_power_on() ?
>> >>
>> >> No, unfortunately keeping these calibration settings in phy_power_on()
>> >> doesn't help, since we need to do this after XHCI reset has happened.
>> >
>> > teach xHCI about PHYs ?
>>
>> sorry i couldn't understand you here.
>> Aren't we trying to do the same with Heikki's patch about dwc3 :
>> [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci
>>
>> and the 2nd patch in this series :
>> [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds
>>
>> Is there something else that is expected ?
>
> 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 think you meant there - "then you __do not__ need to
> add a new ->calibrate() method which, likely,
will only be used by you", is it ?




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

Re: [PATCH v3 0/4 resend] Introduce device assignment flag operation helper function

[ethan zhao]

Bjorn,
   Thanks, will fix the building issue for new version and resend.

Ethan

On 2014/9/9 1:08, Bjorn Helgaas wrote:

On Fri, Sep 05, 2014 at 11:15:22AM -0600, Bjorn Helgaas wrote:

On Fri, Aug 08, 2014 at 01:36:03PM +0800, Ethan Zhao wrote:

This patch set introduces three PCI device flag operation helper functions
when set pci device PF/VF to assigned or deassigned status also check it.
and patch 2,3,4 apply these helper functions to KVM,XEN and PCI.

v2: simplify unnecessory ternary operation in function pci_is_dev_assigned().
v3: amend helper function naming.

Appreciate suggestion from
alex.william...@redhat.com,
david.vra...@citrix.com,
alexander.h.du...@intel.com

Resend for v3.16 building.

Thanks,
Ethan
---
Ethan Zhao (4):
   PCI: introduce helper functions for device flag operation
   KVM: use pci device flag operation helper functions
   xen-pciback: use pci device flag operation helper function
   PCI: use device flag operation helper function in iov.c

  drivers/pci/iov.c  |2 +-
  drivers/xen/xen-pciback/pci_stub.c |4 ++--
  include/linux/pci.h|   13 +
  virt/kvm/assigned-dev.c|2 +-
  virt/kvm/iommu.c   |4 ++--
  5 files changed, 19 insertions(+), 6 deletions(-)


Applied to pci/virtualization for v3.18, thanks!

I dropped these because of build errors from the kbuild-test robot.  Fix
and resend if you still want them.

Bjorn


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