[PATCH] posix-clock: Use an unsigned data type for a variable

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 20 Dec 2015 09:09:34 +0100

The data type "int" was used by the variable "result" in the
function "posix_clock_poll" even though the type "uint" will usually
be needed for the return value from a call of the function which was
assigned to the pointer "poll" of the variable "clk".
Reuse the type from this poll call instead.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 kernel/time/posix-clock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/posix-clock.c b/kernel/time/posix-clock.c
index ce033c7..ac0b733 100644
--- a/kernel/time/posix-clock.c
+++ b/kernel/time/posix-clock.c
@@ -69,7 +69,7 @@ static ssize_t posix_clock_read(struct file *fp, char __user 
*buf,
 static unsigned int posix_clock_poll(struct file *fp, poll_table *wait)
 {
struct posix_clock *clk = get_posix_clock(fp);
-   int result = 0;
+   uint result = 0;
 
if (!clk)
return -ENODEV;
-- 
2.6.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: [RESEND GIT PULL 0/9] phy: for 4.4 -rc

[Kishon Vijay Abraham I]

On Friday 18 December 2015 10:57 PM, Greg KH wrote:
> On Tue, Dec 15, 2015 at 03:34:15PM +0530, Kishon Vijay Abraham I wrote:
>> Hi Greg,
>>
>> Looks like this have not been merged yet. Can you merge it in this
>> -rc cycle. Let me know if I have to change something.
>>
>> Bulk of the changes are with respect to adding of_node_put in
>> the PHY drivers, a fix in PHY core and a patch to fix randconfig error.
>>
>> Thanks
>> Kishon
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
>> tags/phy-for-4.4-rc
> 
> Sorry for the delay, now pulled and pushed out.

Thank you for taking this Greg.

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

CONTACT HIM NOW FOR YOUR ATM CARD DELIVERY

[Mark]

Attention,
We have deposited your fund ($7.500`00USD) through UPS department after our 
finally meeting regarding your ATM CARD, All you will do is to contact UPS 
director  Andy Chalk via E-mail:(chalka...@gmail.com). he will give you 
direction on how you will be receiving your ATM CARD .Remember to send him your 
Full information to avoid wrong delivery such as,

Receiver's Name___
Address: 
Country: 
occupation:
Phone Number: _

Though,UPS department you will receive your ATM CARD so contact Dr. Andy Chalk 
you call him +2349039326424 as soon as you receive this email and tell him to 
show you the way you will receive your ATM CARD.

Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] thermal: rockchip: fix a impossible condition caused by the warning

[Caesar Wang]

As the Dan report the smatch check the thermal driver warning:
drivers/thermal/rockchip_thermal.c:551 rockchip_configure_from_dt()
warn: impossible condition '(thermal->tshut_temp > ((~0 >> 1))) =>
(s32min-s32max > s32max)'

Although The shut_temp read from DT is u32,the temperature is currently
represented as int not long in the thermal driver.
Let's change to make shut_temp instead of the thermal->tshut_temp for
the condition.

Fixes: commit 437df2172e8d
("thermal: rockchip: consistently use int for temperatures")

Reported-by: Dan Carpenter 
Signed-off-by: Caesar Wang 

---

Changes in v4:
- As the Dmitry and Brain comments, let's change to make.sh
  tshut_temp instead of thermal->tshut_temp.

Changes in v3:
- As Brian comments on https://patchwork.kernel.org/patch/7580661/,
  let's remove the impossible condition.

Changes in v2:
- None

Changes in v1:
- None

 drivers/thermal/rockchip_thermal.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index e845841..7106288 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -545,15 +545,14 @@ static int rockchip_configure_from_dt(struct device *dev,
 thermal->chip->tshut_temp);
thermal->tshut_temp = thermal->chip->tshut_temp;
} else {
+   if (shut_temp > INT_MAX) {
+   dev_err(dev, "Invalid tshut temperature specified: 
%d\n",
+   shut_temp);
+   return -ERANGE;
+   }
thermal->tshut_temp = shut_temp;
}
 
-   if (thermal->tshut_temp > INT_MAX) {
-   dev_err(dev, "Invalid tshut temperature specified: %d\n",
-   thermal->tshut_temp);
-   return -ERANGE;
-   }
-
if (of_property_read_u32(np, "rockchip,hw-tshut-mode", &tshut_mode)) {
dev_warn(dev,
 "Missing tshut mode property, using default (%s)\n",
-- 
1.9.1

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

Re: [PATCH v3 7/8] clk: rockchip: fix usbphy-related clocks

[Kishon Vijay Abraham I]

Hi,

On Saturday 19 December 2015 10:51 PM, Heiko Stübner wrote:
> Hi Kishon,
> 
> Am Dienstag, 15. Dezember 2015, 16:22:32 schrieb Kishon Vijay Abraham I:
>> On Friday 20 November 2015 02:52 AM, Heiko Stuebner wrote:
>>> The otgphy clocks really only drive the phy blocks. These in turn
>>> contain plls that then generate the 480m clocks the clock controller
>>> uses to supply some other clocks like uart0, gpu or the video-codec.
>>>
>>> So fix this structure to actually respect that hirarchy and removed
>>> that usb480m fixed-rate clock working as a placeholder till now, as
>>> this wouldn't even work if the supplying phy gets turned off while
>>> its pll-output gets used elsewhere.
>>>
>>> Signed-off-by: Heiko Stuebner 
>>> Reviewed-by: Douglas Anderson 
>>
>> I saw you've given your Acked-by in a previous version of this patch.
>> Do you want me to take this in linux-phy tree?
> 
> from my POV, this series should probably go through your tree in one go, as 
> this patch depends on the newly exposed clocks from the previous patch. So to 
> keep bisectability, it should most likely stay together.

I agree. But I can't take another subsystem patch without getting a clear nod
from the maintainer. I'll wait till tomorrow for Turquette to give his Acked-by.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] Fix a trivial typo and support rk3228/rk3399 SoCs for thermal driver.

[Caesar Wang]

在 2015年12月18日 04:09, Eduardo Valentin 写道:

Hello,

On Thu, Dec 03, 2015 at 04:48:38PM +0800, Caesar Wang wrote:

This series pacthes to support the next soc for this thermal driver.
I don't add the dts thermal data since these SoCs have *_not_* land
in this mainline. I believe these SoCs dts will land in this mainline
lately,
then I will add the thermal data for Heiko.

This series patches can apply into Eduardo branch.
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git

Also, this series pacthes have built on github branch.
https://github.com/rockchip-linux/kernel/commits/develop4.4

PATCH[1/5]:
That's bit ugly typo, sorry for sending again :(.

PATCH[2/5]:
To fix a build warning came from Dan Carpenter report smatch check,
Thanks. :)

PATCH[3/5]:
Add the rk3228/rk3399 SoCs compatible for dt-bindings.

PATCH[4/5]:
Add the rk3228 SoCs for thermal driver.

PATCH[5/5]:
Add the rk3399 SoCs for thermal driver based on PATCH[4/5].

I applied all but 2/5.


Thanks Eduardo,

I send the new patch[2/5].
https://patchwork.kernel.org/patch/7891381/



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
caesar wang | software engineer | w...@rock-chip.com


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

Re: [PATCH 1/2] x86/mm/pat: Change untrack_pfn() to handle unmapped vma

[Thomas Gleixner]

Toshi,

On Wed, 9 Dec 2015, Toshi Kani wrote:
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 188e3e0..f3e391e 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -966,8 +966,14 @@ int track_pfn_insert(struct vm_area_struct *vma, 
> pgprot_t *prot,
>  
>  /*
>   * untrack_pfn is called while unmapping a pfnmap for a region.
> - * untrack can be called for a specific region indicated by pfn and size or
> - * can be for the entire vma (in which case pfn, size are zero).
> + * untrack_pfn can be called for a specific region indicated by pfn and
> + * size or can be for the entire vma (in which case pfn, size are zero).
> + *
> + * NOTE: mremap may move a virtual address of VM_PFNMAP, but keeps the
> + * pfn and cache type.  In this case, untrack_pfn() is called with the
> + * old vma after its translation has removed.  Hence, when follow_phys()
> + * fails, track_pfn() keeps the pfn tracked and clears VM_PAT from the
> + * old vma.
>   */
>  void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
>unsigned long size)
> @@ -981,14 +987,13 @@ void untrack_pfn(struct vm_area_struct *vma, unsigned 
> long pfn,
>   /* free the chunk starting from pfn or the whole chunk */
>   paddr = (resource_size_t)pfn << PAGE_SHIFT;
>   if (!paddr && !size) {
> - if (follow_phys(vma, vma->vm_start, 0, &prot, &paddr)) {
> - WARN_ON_ONCE(1);
> - return;
> - }
> + if (follow_phys(vma, vma->vm_start, 0, &prot, &paddr))
> + goto out;

Shouldn't we have an explicit call in the mremap code which clears the
PAT flag on the mm instead of removing this sanity check?
  
Because that's what we end up with there. We just clear the PAT flag.

I rather prefer to do that explicitely, so the following call to
untrack_pfn() from move_vma()->do_munmap() ... will see the PAT flag
cleared. untrack_moved_pfn() or such.

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/

new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)

[Michael S. Tsirkin]

On Thu, Dec 17, 2015 at 03:39:10PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 17, 2015 at 04:33:44PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote:
> > > 
> > > You could of course go fix that instead of mutilating things into
> > > sort-of functional state.
> > 
> > Yes, we'd just need to touch all architectures, all for
> > the sake of UP which almost no one uses.
> > Basically, we need APIs that explicitly are
> > for talking to another kernel on a different CPU on
> > the same SMP system, and implemented identically
> > between CONFIG_SMP and !CONFIG_SMP on all architectures.
> > 
> > Do you think this is something of general usefulness,
> > outside virtio?
> 
> I'm not aware of any other case, but if there are more parts of virt
> that need this then I see no problem adding it.

When I wrote this, I assumed there are no other users, and I'm still not
sure there are other users at the moment. Do you see a problem then?

> That is, virt in general is the only use-case that I can think of,
> because this really is an artifact of interfacing with an SMP host while
> running an UP kernel.

Or another guest kernel on an SMP host.

> But I'm really not familiar with virt, so I do not know if there's more
> sites outside of virtio that could use this.
> Touching all archs is a tad tedious, but its fairly straight forward.

So I looked and I was only able to find other another possible user in Xen.

Cc Xen folks.

I noticed that drivers/xen/xenbus/xenbus_comms.c uses
full memory barriers to communicate with the other side.
For example:

/* Must write data /after/ reading the consumer index.  * */
mb();

memcpy(dst, data, avail);
data += avail;
len -= avail;

/* Other side must not see new producer until data is * there. 
*/
wmb();
intf->req_prod += avail;

/* Implies mb(): other side will see the updated producer. */
notify_remote_via_evtchn(xen_store_evtchn);

To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb
would be sufficient, so mb() and wmb() here are only needed if
a non-SMP guest runs on an SMP host.

Is my analysis correct?

So what I'm suggesting is something like the below patch,
except instead of using virtio directly, a new set of barriers
that behaves identically for SMP and non-SMP guests will be introduced.

And of course the weak barriers flag is not needed for Xen -
that's a virtio only thing.

For example:

smp_pv_wmb()
smp_pv_rmb()
smp_pv_mb()

I'd like to get confirmation from Xen folks before posting
this patchset.

Comments/suggestions?

Signed-off-by: Michael S. Tsirkin 

--

compile-tested only.

diff --git a/drivers/xen/xenbus/xenbus_comms.c 
b/drivers/xen/xenbus/xenbus_comms.c
index fdb0f33..a28f049 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -123,14 +124,14 @@ int xb_write(const void *data, unsigned len)
avail = len;
 
/* Must write data /after/ reading the consumer index. */
-   mb();
+   virtio_mb(true);
 
memcpy(dst, data, avail);
data += avail;
len -= avail;
 
/* Other side must not see new producer until data is there. */
-   wmb();
+   virtio_wmb(true);
intf->req_prod += avail;
 
/* Implies mb(): other side will see the updated producer. */
@@ -180,14 +181,14 @@ int xb_read(void *data, unsigned len)
avail = len;
 
/* Must read data /after/ reading the producer index. */
-   rmb();
+   virtio_rmb(true);
 
memcpy(data, src, avail);
data += avail;
len -= avail;
 
/* Other side must not see free space until we've copied out */
-   mb();
+   virtio_mb(true);
intf->rsp_cons += avail;
 
pr_debug("Finished read of %i bytes (%i to go)\n", avail, len);

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

Re: [PATCH 2/2] x86/mm/pat: Change free_memtype() to free shrinking range

[Thomas Gleixner]

Toshi,

On Wed, 9 Dec 2015, Toshi Kani wrote:
> diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
> index 6393108..d6faef8 100644
> --- a/arch/x86/mm/pat_rbtree.c
> +++ b/arch/x86/mm/pat_rbtree.c
> @@ -107,7 +112,12 @@ static struct memtype *memtype_rb_exact_match(struct 
> rb_root *root,
>   while (match != NULL && match->start < end) {
>   struct rb_node *node;
>  
> - if (match->start == start && match->end == end)
> + if ((match_type == MEMTYPE_EXACT_MATCH) &&
> + (match->start == start) && (match->end == end))
> + return match;
> +
> + if ((match_type == MEMTYPE_SHRINK_MATCH) &&
> + (match->start < start) && (match->end == end))

Confused. If we shrink a mapping then I'd expect that the start of the
mapping stays the same and the end changes. I certainly miss something
here, but if the above is correct, then it definitely needs a big fat
comment explaining it.

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] ASoC: ssm2518: Use a signed return type for ssm2518_lookup_mcs()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 20 Dec 2015 10:34:25 +0100

The return type "unsigned int" was used by the ssm2518_lookup_mcs()
function even though it will eventually return a negative error code.
Improve this implementation detail by deletion of the type modifier then.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 sound/soc/codecs/ssm2518.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/ssm2518.c b/sound/soc/codecs/ssm2518.c
index 86b81a6..e2e0bfa 100644
--- a/sound/soc/codecs/ssm2518.c
+++ b/sound/soc/codecs/ssm2518.c
@@ -309,7 +309,7 @@ static const struct snd_pcm_hw_constraint_list 
ssm2518_constraints_12288000 = {
.count = ARRAY_SIZE(ssm2518_rates_12288000),
 };
 
-static unsigned int ssm2518_lookup_mcs(struct ssm2518 *ssm2518,
+static int ssm2518_lookup_mcs(struct ssm2518 *ssm2518,
unsigned int rate)
 {
const unsigned int *sysclks = NULL;
-- 
2.6.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: [char-misc-next 4/7] watchdog: mei_wdt: add status debugfs entry

[Winkler, Tomas]

> On 12/17/2015 06:49 AM, Tomas Winkler wrote:
> > Add entry for dumping current watchdog internal state
> >
> > Signed-off-by: Tomas Winkler 
> > ---
> >   drivers/watchdog/mei_wdt.c | 84
> ++
> >   1 file changed, 84 insertions(+)
> >
> > diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
> > index 3c97deb70d90..a3f1c1613c32 100644
> > --- a/drivers/watchdog/mei_wdt.c
> > +++ b/drivers/watchdog/mei_wdt.c
> > @@ -16,6 +16,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >
> >   #include 
> >   #include 
> > @@ -54,6 +55,19 @@ enum mei_wdt_state {
> > MEI_WDT_STOPPING,
> >   };
> >
> > +#if IS_ENABLED(CONFIG_DEBUG_FS)
> > +static const char *mei_wdt_state_str(enum mei_wdt_state state)
> > +{
> > +   switch (state) {
> > +   case MEI_WDT_IDLE: return "IDLE";
> > +   case MEI_WDT_START: return "START";
> > +   case MEI_WDT_RUNNING: return "RUNNING";
> > +   case MEI_WDT_STOPPING: return "STOPPING";
> > +   default: return "unknown";
> 
> Doesn't this cause checkpatch warnings ?
It doesn't and also checkpatch.pl  is just a help tool. 
> 
> > +   }
> > +}
> > +#endif /* CONFIG_DEBUG_FS */
> > +
> 
> Can you move this conditional code into the other #ifdef block below ?

I'm removing the ifdef in the following patch so this is just for this path to 
not to spill warning the compilation w/o CONFIG_DEBUG_FS set.

.start   = mei_wdt_ops_start,
> > @@ -348,6 +428,8 @@ static int mei_wdt_probe(struct mei_cl_device *cldev,
> > if (ret)
> > goto err_disable;
> >
> > +   dbgfs_register(wdt);
> > +
> > return 0;
> >
> >   err_disable:
> > @@ -367,6 +449,8 @@ static int mei_wdt_remove(struct mei_cl_device *cldev)
> >
> > kref_put(&wdt->refcnt, mei_wdt_release);
> >
> > +   dbgfs_deregister(wdt);
> > +
> 
> This should probably come before the call to kref_put() since it uses wdt.

Good catch, will resend.
Tomas

 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] devpts: Sensible /dev/ptmx & force newinstance

[Eric W. Biederman]

"H. Peter Anvin"  writes:

> Does it matter if it mounts devpts twice?  It seems like a waste of a
> minuscule amount of memory, and nothing else.

It breaks system("mknod /tmp/ptmx c 5 2"); open("/tmp/ptmx");

As it opens a pty in an inaccessible instance of devpts.  When
previously the instance of devpts was accessible.  So backwards
compatibility is broken.

It doubly matters as we have evidence that b0rken userspace actually
does that things like that.

I will probably get a grumble or two but it turns out it isn't
particularly hard to deal with the overmounting that happens in CentOS6,
and the mounting then unmounting then mounting again that happens in
CentOS5, and openwrt.

For the cases I know to test for I have something that works now.I
am going to  sleep on it and then see if I can find think of other
things to test before I push out a patch.

Eric

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

[Eric W. Biederman]

Dongsheng Yang  writes:

> On 12/20/2015 10:37 AM, Al Viro wrote:
>> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
>>> On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
 Hi guys,
  We are working on making core dump behaviour isolated in
 container. But the problem is, the /proc/sys/kernel/core_pattern
 is a kernel wide setting, not belongs to a container.

  So we want to add core_pattern into mnt namespace. What
 do you think about it?
>>>
>>> Hi Eric,
>>> I found your patch about "net: Implement the per network namespace
>>> sysctl infrastructure", I want to do the similar thing
>>> in mnt namespace. Is that suggested way?
>>
>> Why mnt namespace and not something else?
>
> Hi Al,
>
> Well, because core_pattern indicates the path to store core file.
> In different mnt namespace, we would like to change the path with
> different value.
>
> In addition, Let's considering other namespaces:
> UTS ns: contains informations of kernel and arch, not proper for core_pattern.
> IPC ns: communication informations, not proper for core_pattern
> PID ns: core_pattern is not related with pid
> net ns: obviousely no.
> user ns: not proper too.
>
> Then I believe it's better to do this in mnt namespace. of course,
> core_pattern is just one example. After this infrastructure finished,
> we can implement more sysctls as per-mnt if necessary, I think.
>
> Al, what do you think about this idea?

The hard part is not the sysctl.  The hard part is starting the usermode
helper, in an environment that it can deal with.  The mount namespace
really provides you with no help there.

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

JUST REPLY YES ONLY

[Richard]

Hello

My proposal will give us 2 million in seven days reply "YES" for details.

Regards,

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

[PATCH] ARM: dts: veyron: enable the tsadc on pinky board

[Caesar Wang]

I think the tsadc is fakly hand on pinky board,
maybe that's fixed in newest kernel.
As the following patch is a example:
https://patchwork.kernel.org/patch/7472051/

I don't have meet this issue on pinky board.
Let me know if that's still hanging on pinky board.

Signed-off-by: Caesar Wang 
---

 arch/arm/boot/dts/rk3288-veyron-pinky.dts | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts 
b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
index 94b56e3..b587ebf 100644
--- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
@@ -121,8 +121,3 @@
 &sdmmc_wp_gpio &sdmmc_bus4>;
wp-gpios = <&gpio7 10 GPIO_ACTIVE_HIGH>;
 };
-
-&tsadc {
-   /* Some connection is flaky making the tsadc hang the system */
-   status = "disabled";
-};
-- 
1.9.1

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

Re: [char-misc-next 4/7] watchdog: mei_wdt: add status debugfs entry

[Guenter Roeck]

On 12/20/2015 01:44 AM, Winkler, Tomas wrote:



On 12/17/2015 06:49 AM, Tomas Winkler wrote:

Add entry for dumping current watchdog internal state

Signed-off-by: Tomas Winkler 
---
   drivers/watchdog/mei_wdt.c | 84

++

   1 file changed, 84 insertions(+)

diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
index 3c97deb70d90..a3f1c1613c32 100644
--- a/drivers/watchdog/mei_wdt.c
+++ b/drivers/watchdog/mei_wdt.c
@@ -16,6 +16,7 @@
   #include 
   #include 
   #include 
+#include 

   #include 
   #include 
@@ -54,6 +55,19 @@ enum mei_wdt_state {
MEI_WDT_STOPPING,
   };

+#if IS_ENABLED(CONFIG_DEBUG_FS)
+static const char *mei_wdt_state_str(enum mei_wdt_state state)
+{
+   switch (state) {
+   case MEI_WDT_IDLE: return "IDLE";
+   case MEI_WDT_START: return "START";
+   case MEI_WDT_RUNNING: return "RUNNING";
+   case MEI_WDT_STOPPING: return "STOPPING";
+   default: return "unknown";


Doesn't this cause checkpatch warnings ?

It doesn't and also checkpatch.pl  is just a help tool.


I should have said "Doesn't this violate the single-statement-per-line"
coding style rule, but I guess then you'd argue that "case xxx:" is not
a statement.

Guenter

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

Re: [PATCH v5] mtd: support BB SRAM on ICP DAS LP-8x4x

[Sergei Ianovich]

On Sat, 2015-12-19 at 21:38 -0600, Rob Herring wrote:
> On Tue, Dec 15, 2015 at 09:58:53PM +0300, Sergei Ianovich wrote:
> > This provides an MTD device driver for 512kB of battery backed up
> > SRAM
> > on ICPDAS LP-8X4X programmable automation controllers.
> > 
> > SRAM chip is connected via FPGA and is not accessible without a
> > driver,
> > unlike flash memory which is wired to CPU MMU.
> > 
> > This SRAM becomes an excellent persisent storage of volatile process
> > data like counter values and sensor statuses. Storing those data in
> > flash or mmc card is not a viable solution.
> > 
> > Signed-off-by: Sergei Ianovich 
> > Reviewed-by: Brian Norris 
> > ---
> >    v4..v5
> >    * remove .owner from struct platform_driver
> >    * constify struct of_device_id
> > for further Brian Norris comments:
> >    * drop unused property from doc file
> >    * move defconfig update to a different file
> >    * drop extra match w/ of_match_device()
> > 
> >    v3..v4 for Brian Norris 'Reviewed-by'
> >    * add doc file for DT binding
> >    * move DTS binding to a different patch (8/21)
> >    * drop unused include directive
> >    * drop safely unused callback
> >    * drop non-default partion probe types
> >    * drop duplicate error checks
> >    * drop duplicate error reporting
> >    * fixed error message on MTD registeration
> >    * fixed module removal routine
> > 
> >    v2..v3
> >    * no changes (except number 08/16 -> 10/21)
> > 
> >    v0..v2
> >    * use device tree
> >    * use devm helpers where possible
> > 
> >  .../devicetree/bindings/mtd/sram-lp8x4x.txt|  20 +++
> >  drivers/mtd/devices/Kconfig|  14 ++
> >  drivers/mtd/devices/Makefile   |   1 +
> >  drivers/mtd/devices/sram_lp8x4x.c  | 199
> > +
> >  4 files changed, 234 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mtd/sram-
> > lp8x4x.txt
> >  create mode 100644 drivers/mtd/devices/sram_lp8x4x.c
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
> > b/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
> > new file mode 100644
> > index 000..476934f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
> > @@ -0,0 +1,20 @@
> > +512kB battery backed up SRAM on LP-8x4x industrial computers
> > +
> > +Required properties:
> > +- compatible : should be "icpdas,sram-lp8x4x"
> 
> No wildcards please. Otherwise looks fine.

There is a similar review comment from Arnd Bergmann in the discussion
of `[PATCH v5] serial: support for 16550A serial ports on LP-8x4x`.

I'll quote my latest clarification:
> ... This driver will support ports on LP-8081, 
> LP-8141, LP-8441, LP-8841. Last time I checked the vendor was announcing
> a series with 3 as the last digit. They use lp8x4x name, eg. in
> documentation like `LP-8x4x_ChangeLog.txt`. They ship their proprietary
> SDK in `lp8x4x_sdk_for_linux.tar`. All of this implies that it is a
> single board.

I think the solution should be the same for all LP-8x4x drivers (IRQ,
SRAM, SERIAL, IIO).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] x86: KVM vdso and clock improvements

[Andy Lutomirski]

x86: KVM vdso and clock improvements

NB: patch 1 doesn't really belong here, but it makes this a lot
easier for me to test.  Patch 1, if it's okay at all, should go
though the kvm tree.  The rest should probably go through
tip:x86/vdso once they're reviewed.

I'll do a followup to enable vdso pvclock on 32-bit guests.
I'm not currently set up to test it.  (The KVM people could also
do it very easily on top of these patches.)

Changes from v1:
 - Dropped patch 1
 - Added Paolo's review and acks
 - Fixed a build issue on some configs

Andy Lutomirski (4):
  x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
  x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap
  x86/vdso: Remove pvclock fixmap machinery
  x86/vdso: Enable vdso pvclock access on all vdso variants

 arch/x86/entry/vdso/vclock_gettime.c  | 151 --
 arch/x86/entry/vdso/vdso-layout.lds.S |   3 +-
 arch/x86/entry/vdso/vdso2c.c  |   3 +
 arch/x86/entry/vdso/vma.c |  14 
 arch/x86/include/asm/fixmap.h |   5 --
 arch/x86/include/asm/pvclock.h|  14 ++--
 arch/x86/include/asm/vdso.h   |   1 +
 arch/x86/kernel/kvmclock.c|  11 ++-
 arch/x86/kernel/pvclock.c |  24 --
 9 files changed, 107 insertions(+), 119 deletions(-)

-- 
2.5.0

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

[PATCH v2 1/4] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

[Andy Lutomirski]

From: Andy Lutomirski 

The pvclock vdso code was too abstracted to understand easily and
excessively paranoid.  Simplify it for a huge speedup.

This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.

Before, vclock_gettime using kvm-clock took about 45ns on my machine.
With this change, it takes 29ns, which is almost as fast as the pure TSC
implementation.

Reviewed-by: Paolo Bonzini 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/vdso/vclock_gettime.c | 81 
 1 file changed, 46 insertions(+), 35 deletions(-)

diff --git a/arch/x86/entry/vdso/vclock_gettime.c 
b/arch/x86/entry/vdso/vclock_gettime.c
index ca94fa649251..c325ba1bdddf 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -78,47 +78,58 @@ static notrace const struct pvclock_vsyscall_time_info 
*get_pvti(int cpu)
 
 static notrace cycle_t vread_pvclock(int *mode)
 {
-   const struct pvclock_vsyscall_time_info *pvti;
+   const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
cycle_t ret;
-   u64 last;
-   u32 version;
-   u8 flags;
-   unsigned cpu, cpu1;
-
+   u64 tsc, pvti_tsc;
+   u64 last, delta, pvti_system_time;
+   u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
 
/*
-* Note: hypervisor must guarantee that:
-* 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
-* 2. that per-CPU pvclock time info is updated if the
-*underlying CPU changes.
-* 3. that version is increased whenever underlying CPU
-*changes.
+* Note: The kernel and hypervisor must guarantee that cpu ID
+* number maps 1:1 to per-CPU pvclock time info.
+*
+* Because the hypervisor is entirely unaware of guest userspace
+* preemption, it cannot guarantee that per-CPU pvclock time
+* info is updated if the underlying CPU changes or that that
+* version is increased whenever underlying CPU changes.
 *
+* On KVM, we are guaranteed that pvti updates for any vCPU are
+* atomic as seen by *all* vCPUs.  This is an even stronger
+* guarantee than we get with a normal seqlock.
+*
+* On Xen, we don't appear to have that guarantee, but Xen still
+* supplies a valid seqlock using the version field.
+
+* We only do pvclock vdso timing at all if
+* PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
+* mean that all vCPUs have matching pvti and that the TSC is
+* synced, so we can just look at vCPU 0's pvti.
 */
-   do {
-   cpu = __getcpu() & VGETCPU_CPU_MASK;
-   /* TODO: We can put vcpu id into higher bits of pvti.version.
-* This will save a couple of cycles by getting rid of
-* __getcpu() calls (Gleb).
-*/
-
-   pvti = get_pvti(cpu);
-
-   version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
-
-   /*
-* Test we're still on the cpu as well as the version.
-* We could have been migrated just after the first
-* vgetcpu but before fetching the version, so we
-* wouldn't notice a version change.
-*/
-   cpu1 = __getcpu() & VGETCPU_CPU_MASK;
-   } while (unlikely(cpu != cpu1 ||
- (pvti->pvti.version & 1) ||
- pvti->pvti.version != version));
-
-   if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
+
+   if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
*mode = VCLOCK_NONE;
+   return 0;
+   }
+
+   do {
+   version = pvti->version;
+
+   /* This is also a read barrier, so we'll read version first. */
+   tsc = rdtsc_ordered();
+
+   pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
+   pvti_tsc_shift = pvti->tsc_shift;
+   pvti_system_time = pvti->system_time;
+   pvti_tsc = pvti->tsc_timestamp;
+
+   /* Make sure that the version double-check is last. */
+   smp_rmb();
+   } while (unlikely((version & 1) || version != pvti->version));
+
+   delta = tsc - pvti_tsc;
+   ret = pvti_system_time +
+   pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
+   pvti_tsc_shift);
 
/* refer to tsc.c read_tsc() comment for rationale */
last = gtod->cycle_last;
-- 
2.5.0

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

[PATCH v2 2/4] x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap

[Andy Lutomirski]

Acked-by: Paolo Bonzini 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/vdso/vclock_gettime.c  | 20 
 arch/x86/entry/vdso/vdso-layout.lds.S |  3 ++-
 arch/x86/entry/vdso/vdso2c.c  |  3 +++
 arch/x86/entry/vdso/vma.c | 13 +
 arch/x86/include/asm/pvclock.h|  9 +
 arch/x86/include/asm/vdso.h   |  1 +
 arch/x86/kernel/kvmclock.c|  5 +
 7 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/arch/x86/entry/vdso/vclock_gettime.c 
b/arch/x86/entry/vdso/vclock_gettime.c
index c325ba1bdddf..5dd363d54348 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -36,6 +36,11 @@ static notrace cycle_t vread_hpet(void)
 }
 #endif
 
+#ifdef CONFIG_PARAVIRT_CLOCK
+extern u8 pvclock_page
+   __attribute__((visibility("hidden")));
+#endif
+
 #ifndef BUILD_VDSO32
 
 #include 
@@ -62,23 +67,14 @@ notrace static long vdso_fallback_gtod(struct timeval *tv, 
struct timezone *tz)
 
 #ifdef CONFIG_PARAVIRT_CLOCK
 
-static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
+static notrace const struct pvclock_vsyscall_time_info *get_pvti0(void)
 {
-   const struct pvclock_vsyscall_time_info *pvti_base;
-   int idx = cpu / (PAGE_SIZE/PVTI_SIZE);
-   int offset = cpu % (PAGE_SIZE/PVTI_SIZE);
-
-   BUG_ON(PVCLOCK_FIXMAP_BEGIN + idx > PVCLOCK_FIXMAP_END);
-
-   pvti_base = (struct pvclock_vsyscall_time_info *)
-   __fix_to_virt(PVCLOCK_FIXMAP_BEGIN+idx);
-
-   return &pvti_base[offset];
+   return (const struct pvclock_vsyscall_time_info *)&pvclock_page;
 }
 
 static notrace cycle_t vread_pvclock(int *mode)
 {
-   const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
+   const struct pvclock_vcpu_time_info *pvti = &get_pvti0()->pvti;
cycle_t ret;
u64 tsc, pvti_tsc;
u64 last, delta, pvti_system_time;
diff --git a/arch/x86/entry/vdso/vdso-layout.lds.S 
b/arch/x86/entry/vdso/vdso-layout.lds.S
index de2c921025f5..4158acc17df0 100644
--- a/arch/x86/entry/vdso/vdso-layout.lds.S
+++ b/arch/x86/entry/vdso/vdso-layout.lds.S
@@ -25,7 +25,7 @@ SECTIONS
 * segment.
 */
 
-   vvar_start = . - 2 * PAGE_SIZE;
+   vvar_start = . - 3 * PAGE_SIZE;
vvar_page = vvar_start;
 
/* Place all vvars at the offsets in asm/vvar.h. */
@@ -36,6 +36,7 @@ SECTIONS
 #undef EMIT_VVAR
 
hpet_page = vvar_start + PAGE_SIZE;
+   pvclock_page = vvar_start + 2 * PAGE_SIZE;
 
. = SIZEOF_HEADERS;
 
diff --git a/arch/x86/entry/vdso/vdso2c.c b/arch/x86/entry/vdso/vdso2c.c
index 785d9922b106..491020b2826d 100644
--- a/arch/x86/entry/vdso/vdso2c.c
+++ b/arch/x86/entry/vdso/vdso2c.c
@@ -73,6 +73,7 @@ enum {
sym_vvar_start,
sym_vvar_page,
sym_hpet_page,
+   sym_pvclock_page,
sym_VDSO_FAKE_SECTION_TABLE_START,
sym_VDSO_FAKE_SECTION_TABLE_END,
 };
@@ -80,6 +81,7 @@ enum {
 const int special_pages[] = {
sym_vvar_page,
sym_hpet_page,
+   sym_pvclock_page,
 };
 
 struct vdso_sym {
@@ -91,6 +93,7 @@ struct vdso_sym required_syms[] = {
[sym_vvar_start] = {"vvar_start", true},
[sym_vvar_page] = {"vvar_page", true},
[sym_hpet_page] = {"hpet_page", true},
+   [sym_pvclock_page] = {"pvclock_page", true},
[sym_VDSO_FAKE_SECTION_TABLE_START] = {
"VDSO_FAKE_SECTION_TABLE_START", false
},
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 64df47148160..aa828191c654 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -100,6 +100,7 @@ static int map_vdso(const struct vdso_image *image, bool 
calculate_addr)
.name = "[vvar]",
.pages = no_pages,
};
+   struct pvclock_vsyscall_time_info *pvti;
 
if (calculate_addr) {
addr = vdso_addr(current->mm->start_stack,
@@ -169,6 +170,18 @@ static int map_vdso(const struct vdso_image *image, bool 
calculate_addr)
}
 #endif
 
+   pvti = pvclock_pvti_cpu0_va();
+   if (pvti && image->sym_pvclock_page) {
+   ret = remap_pfn_range(vma,
+ text_start + image->sym_pvclock_page,
+ __pa(pvti) >> PAGE_SHIFT,
+ PAGE_SIZE,
+ PAGE_READONLY);
+
+   if (ret)
+   goto up_fail;
+   }
+
 up_fail:
if (ret)
current->mm->context.vdso = NULL;
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 7a6bed5c08bc..571dad355bbc 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -4,6 +4,15 @@
 #include 
 #include 
 
+#ifdef CONFIG_KVM_GUEST
+extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
+#else
+static inline struct pvclock_vsyscall_time_info *

[PATCH v2 3/4] x86/vdso: Remove pvclock fixmap machinery

[Andy Lutomirski]

Acked-by: Paolo Bonzini 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/vdso/vclock_gettime.c |  1 -
 arch/x86/entry/vdso/vma.c|  1 +
 arch/x86/include/asm/fixmap.h|  5 -
 arch/x86/include/asm/pvclock.h   |  5 -
 arch/x86/kernel/kvmclock.c   |  6 --
 arch/x86/kernel/pvclock.c| 24 
 6 files changed, 1 insertion(+), 41 deletions(-)

diff --git a/arch/x86/entry/vdso/vclock_gettime.c 
b/arch/x86/entry/vdso/vclock_gettime.c
index 5dd363d54348..59a98c25bde7 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -45,7 +45,6 @@ extern u8 pvclock_page
 
 #include 
 #include 
-#include 
 #include 
 
 notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index aa828191c654..b8f69e264ac4 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index f80d70009ff8..6d7d0e52ed5a 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #ifdef CONFIG_X86_32
 #include 
 #include 
@@ -72,10 +71,6 @@ enum fixed_addresses {
 #ifdef CONFIG_X86_VSYSCALL_EMULATION
VSYSCALL_PAGE = (FIXADDR_TOP - VSYSCALL_ADDR) >> PAGE_SHIFT,
 #endif
-#ifdef CONFIG_PARAVIRT_CLOCK
-   PVCLOCK_FIXMAP_BEGIN,
-   PVCLOCK_FIXMAP_END = PVCLOCK_FIXMAP_BEGIN+PVCLOCK_VSYSCALL_NR_PAGES-1,
-#endif
 #endif
FIX_DBGP_BASE,
FIX_EARLYCON_MEM_BASE,
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 571dad355bbc..fdcc04020636 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -100,10 +100,5 @@ struct pvclock_vsyscall_time_info {
 } __attribute__((__aligned__(SMP_CACHE_BYTES)));
 
 #define PVTI_SIZE sizeof(struct pvclock_vsyscall_time_info)
-#define PVCLOCK_VSYSCALL_NR_PAGES (((NR_CPUS-1)/(PAGE_SIZE/PVTI_SIZE))+1)
-
-int __init pvclock_init_vsyscall(struct pvclock_vsyscall_time_info *i,
-int size);
-struct pvclock_vcpu_time_info *pvclock_get_vsyscall_time_info(int cpu);
 
 #endif /* _ASM_X86_PVCLOCK_H */
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index ec1b06dc82d2..72cef58693c7 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -310,7 +310,6 @@ int __init kvm_setup_vsyscall_timeinfo(void)
 {
 #ifdef CONFIG_X86_64
int cpu;
-   int ret;
u8 flags;
struct pvclock_vcpu_time_info *vcpu_time;
unsigned int size;
@@ -330,11 +329,6 @@ int __init kvm_setup_vsyscall_timeinfo(void)
return 1;
}
 
-   if ((ret = pvclock_init_vsyscall(hv_clock, size))) {
-   put_cpu();
-   return ret;
-   }
-
put_cpu();
 
kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 2f355d229a58..99bfc025111d 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -140,27 +140,3 @@ void pvclock_read_wallclock(struct pvclock_wall_clock 
*wall_clock,
 
set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
 }
-
-#ifdef CONFIG_X86_64
-/*
- * Initialize the generic pvclock vsyscall state.  This will allocate
- * a/some page(s) for the per-vcpu pvclock information, set up a
- * fixmap mapping for the page(s)
- */
-
-int __init pvclock_init_vsyscall(struct pvclock_vsyscall_time_info *i,
-int size)
-{
-   int idx;
-
-   WARN_ON (size != PVCLOCK_VSYSCALL_NR_PAGES*PAGE_SIZE);
-
-   for (idx = 0; idx <= (PVCLOCK_FIXMAP_END-PVCLOCK_FIXMAP_BEGIN); idx++) {
-   __set_fixmap(PVCLOCK_FIXMAP_BEGIN + idx,
-__pa(i) + (idx*PAGE_SIZE),
-PAGE_KERNEL_VVAR);
-   }
-
-   return 0;
-}
-#endif
-- 
2.5.0

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

[PATCH v2 4/4] x86/vdso: Enable vdso pvclock access on all vdso variants

[Andy Lutomirski]

Now that pvclock doesn't require access to the fixmap, all vdso
variants can use it.

The kernel side isn't wired up for 32-bit kernels yet, but this
covers 32-bit and x32 userspace on 64-bit kernels.

Acked-by: Paolo Bonzini 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/vdso/vclock_gettime.c | 91 
 1 file changed, 40 insertions(+), 51 deletions(-)

diff --git a/arch/x86/entry/vdso/vclock_gettime.c 
b/arch/x86/entry/vdso/vclock_gettime.c
index 59a98c25bde7..8602f06c759f 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -17,8 +17,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 #define gtod (&VVAR(vsyscall_gtod_data))
 
@@ -43,10 +45,6 @@ extern u8 pvclock_page
 
 #ifndef BUILD_VDSO32
 
-#include 
-#include 
-#include 
-
 notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
 {
long ret;
@@ -64,8 +62,42 @@ notrace static long vdso_fallback_gtod(struct timeval *tv, 
struct timezone *tz)
return ret;
 }
 
-#ifdef CONFIG_PARAVIRT_CLOCK
 
+#else
+
+notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+{
+   long ret;
+
+   asm(
+   "mov %%ebx, %%edx \n"
+   "mov %2, %%ebx \n"
+   "call __kernel_vsyscall \n"
+   "mov %%edx, %%ebx \n"
+   : "=a" (ret)
+   : "0" (__NR_clock_gettime), "g" (clock), "c" (ts)
+   : "memory", "edx");
+   return ret;
+}
+
+notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
+{
+   long ret;
+
+   asm(
+   "mov %%ebx, %%edx \n"
+   "mov %2, %%ebx \n"
+   "call __kernel_vsyscall \n"
+   "mov %%edx, %%ebx \n"
+   : "=a" (ret)
+   : "0" (__NR_gettimeofday), "g" (tv), "c" (tz)
+   : "memory", "edx");
+   return ret;
+}
+
+#endif
+
+#ifdef CONFIG_PARAVIRT_CLOCK
 static notrace const struct pvclock_vsyscall_time_info *get_pvti0(void)
 {
return (const struct pvclock_vsyscall_time_info *)&pvclock_page;
@@ -109,9 +141,9 @@ static notrace cycle_t vread_pvclock(int *mode)
do {
version = pvti->version;
 
-   /* This is also a read barrier, so we'll read version first. */
-   tsc = rdtsc_ordered();
+   smp_rmb();
 
+   tsc = rdtsc_ordered();
pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
pvti_tsc_shift = pvti->tsc_shift;
pvti_system_time = pvti->system_time;
@@ -126,7 +158,7 @@ static notrace cycle_t vread_pvclock(int *mode)
pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
pvti_tsc_shift);
 
-   /* refer to tsc.c read_tsc() comment for rationale */
+   /* refer to vread_tsc() comment for rationale */
last = gtod->cycle_last;
 
if (likely(ret >= last))
@@ -136,49 +168,6 @@ static notrace cycle_t vread_pvclock(int *mode)
 }
 #endif
 
-#else
-
-notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
-{
-   long ret;
-
-   asm(
-   "mov %%ebx, %%edx \n"
-   "mov %2, %%ebx \n"
-   "call __kernel_vsyscall \n"
-   "mov %%edx, %%ebx \n"
-   : "=a" (ret)
-   : "0" (__NR_clock_gettime), "g" (clock), "c" (ts)
-   : "memory", "edx");
-   return ret;
-}
-
-notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
-{
-   long ret;
-
-   asm(
-   "mov %%ebx, %%edx \n"
-   "mov %2, %%ebx \n"
-   "call __kernel_vsyscall \n"
-   "mov %%edx, %%ebx \n"
-   : "=a" (ret)
-   : "0" (__NR_gettimeofday), "g" (tv), "c" (tz)
-   : "memory", "edx");
-   return ret;
-}
-
-#ifdef CONFIG_PARAVIRT_CLOCK
-
-static notrace cycle_t vread_pvclock(int *mode)
-{
-   *mode = VCLOCK_NONE;
-   return 0;
-}
-#endif
-
-#endif
-
 notrace static cycle_t vread_tsc(void)
 {
cycle_t ret = (cycle_t)rdtsc_ordered();
-- 
2.5.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] posix-clock: Use an unsigned data type for a variable

[Julia Lawall]

On Sun, 20 Dec 2015, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Sun, 20 Dec 2015 09:09:34 +0100
> 
> The data type "int" was used by the variable "result" in the
> function "posix_clock_poll" even though the type "uint" will usually
> be needed for the return value from a call of the function which was
> assigned to the pointer "poll" of the variable "clk".
> Reuse the type from this poll call instead.

Why use uint when the function return type it unsigned int?
On the other hand, why is the function return type unsigned int when there 
is a return of a negative constant?

julia

> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  kernel/time/posix-clock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/time/posix-clock.c b/kernel/time/posix-clock.c
> index ce033c7..ac0b733 100644
> --- a/kernel/time/posix-clock.c
> +++ b/kernel/time/posix-clock.c
> @@ -69,7 +69,7 @@ static ssize_t posix_clock_read(struct file *fp, char 
> __user *buf,
>  static unsigned int posix_clock_poll(struct file *fp, poll_table *wait)
>  {
>   struct posix_clock *clk = get_posix_clock(fp);
> - int result = 0;
> + uint result = 0;
>  
>   if (!clk)
>   return -ENODEV;
> -- 
> 2.6.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] iio: add ad5761 DAC driver

[Ricardo Ribalda Delgado]

Hello Jonthan

Thanks for your comments, I have fixed all the style problems in v2,
so we can focus in the range parameter.

On Sat, Dec 19, 2015 at 5:31 PM, Jonathan Cameron  wrote:
> Range isn't actually specified in the ABI docs.
> Documenation\ABI\testing\sysfs-bus-iio*
> The control interface for this is normally scale rather than range
> (we had to pick one of the two and that is the way it fell out)  Usually
> hardware designers care about range, but userspace programs are often
> most directly interested in scale factors that need to be applied.
> (and that was my most rediculously over generalized statement for the day ;)

What about a first version of the driver where the range is set via
pdata and is not userland configurable?
That way the four chips will be supported and we can have more
feedback from other users about the range issue.

>
> I can see this is rather complex here given the random looking collection
> of associated scales and offsets.  You would have to have _available
> attributes to say what offsets are available at a given scale I think.
> Also we'd have to then define a precedence order in the docs for the
> two attributes (worth doing to make it obvious what to do when this
> sort of setup arises).

The problem with that approach is that there will be two operations to
set the range: one  to change the scale, and another for the offset.  The output
voltage will change twice in this process and may have an intermediate value
that can damage a circuit.

I also believe that my approach with a text description is more user friendly
(but problably because I programmed it :P)

In any case, I will implement whatever we agree ;)

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

Re: [PATCH v4 1/2] serial: rewrite pxa2xx-uart to use 8250_core

[Sergei Ianovich]

On Sun, 2015-12-20 at 00:12 +0100, Robert Jarzmik wrote:
> Sergei Ianovich  writes:
> 
> > On Sat, 2015-12-19 at 20:31 +0100, Robert Jarzmik wrote:
> > > Sergei Ianovich  writes:
> > > Thanks for spotting this. This is caused by a change in the latest
> > > > version of the patch (SERIAL_8250_PXA instead of SERIAL_PXA).
> > > > This
> > > > change could be reverted.
> > > Actually I'm against the revert.
> > > The name change looks very good to me, please keep it.
> > 
> > Is it worth adding an error if CONFIG_SERIAL_PXA is defined?
> I don't think so.

...

> 
> > I understand that people are afraid of taking this patch. If it
> > starts
> > causing troubles at runtime, it will be difficult to diagnose. There
> > will be no console for most people. So it is probably good idea to
> > fail
> > at boot time.
> Who are "the people" ? 

I think "the people" are at least Greg Kroah-Hartman and Russell King.

> If it's about something already written in a mailing
> list, please point me to it so that it can help me think about it.

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/2167
73.html

I can explain why I think so. Greg acked the patch, but hasn't merged it
since then. He has good reasons for this most probably. Russell's
comment pointed by the link seems to be the reason.

I think the problem raised by Russell could be addressed. My best guess
is compile time error, despite your comment above.

I have one more plan. For transition period, we can introduce a
temporary Kconfig option SERIAL_8250_PXA_OFF, and fail at build time if
neither SERIAL_8250_PXA nor SERIAL_8250_PXA_OFF is set. This way all
interested parties will be notified of this driver update.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: add ad5761 DAC driver

[Ricardo Ribalda Delgado]

Hello Peter:


Thanks for your review! I agree on all your points but one:

On Sat, Dec 19, 2015 at 6:06 PM, Peter Meerwald-Stadler
 wrote:
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
>> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
>> + BIT(IIO_CHAN_INFO_OFFSET),  \
>> + .scan_type = {  \
>
> the driver does not support buffered mode, not sure if scan_type should be
> used to store the number of bits; I think it would be cleaner to put this
> in chip_info


Although I understand your point, must of the other dac drivers are
doing the same and in my humble opinion is very elegant.



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

[PATCH 4/4] ASoC: Intel: add NULL test

[Julia Lawall]

Add NULL test on call to devm_kzalloc.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression x;
identifier fld;
@@

* x = devm_kzalloc(...);
  ... when != x == NULL
  x->fld
// 

Signed-off-by: Julia Lawall 

---
 sound/soc/intel/baytrail/sst-baytrail-pcm.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c 
b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
index 79547be..4765ad4 100644
--- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
+++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
@@ -377,6 +377,8 @@ static int sst_byt_pcm_probe(struct snd_soc_platform 
*platform)
 
priv_data = devm_kzalloc(platform->dev, sizeof(*priv_data),
 GFP_KERNEL);
+   if (!priv_data)
+   return -ENOMEM;
priv_data->byt = plat_data->dsp;
snd_soc_platform_set_drvdata(platform, priv_data);
 

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

[Julia Lawall]

Add NULL tests on various calls to kzalloc and devm_kzalloc.

The semantic match that finds these problems is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression x,y;
identifier fld;
@@

(
x = \(vmalloc\|kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|krealloc\|
kmemdup\|kstrdup\|
devm_kzalloc\|devm_kmalloc\|devm_kcalloc\|devm_kasprintf\|
kmalloc_array\)(...,<+... __GFP_NOFAIL ...+>,...);
|
* x = \(vmalloc\|kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|krealloc\|
kmemdup\|kstrdup\|
devm_kzalloc\|devm_kmalloc\|devm_kcalloc\|devm_kasprintf\|
kmalloc_array\)(...);
)
  ... when != (x) == NULL
  when != (x) != NULL
  when != (x) == 0
  when != (x) != 0
  when != x = y
(
  x->fld
|
  *x
|
  x[...]
)
// 

---

 drivers/s390/char/con3215.c |2 ++
 drivers/s390/char/raw3270.c |2 ++
 sound/soc/fsl/imx-pcm-dma.c |2 ++
 sound/soc/intel/baytrail/sst-baytrail-pcm.c |2 ++
 sound/soc/omap/omap-hdmi-audio.c|2 ++
 5 files changed, 10 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] s390/cio: add NULL test

[Julia Lawall]

Add NULL test on call to kzalloc.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression x;
identifier fld;
@@

* x = kzalloc(...);
  ... when != x == NULL
  x->fld
// 

Signed-off-by: Julia Lawall 

---
 drivers/s390/char/con3215.c |2 ++
 1 files changed, 2 insertions(+)

diff --git a/drivers/s390/char/con3215.c b/drivers/s390/char/con3215.c
index 0fc3fe5..7d82bbc 100644
--- a/drivers/s390/char/con3215.c
+++ b/drivers/s390/char/con3215.c
@@ -922,6 +922,8 @@ static int __init con3215_init(void)
spin_lock_init(&raw3215_freelist_lock);
for (i = 0; i < NR_3215_REQ; i++) {
req = kzalloc(sizeof(struct raw3215_req), GFP_KERNEL | GFP_DMA);
+   if (!req)
+   return -ENOMEM;
req->next = raw3215_freelist;
raw3215_freelist = req;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] ASoC: omap-hdmi-audio: add NULL test

[Julia Lawall]

Add NULL test on call to devm_kzalloc.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression x;
identifier fld;
@@

* x = devm_kzalloc(...);
  ... when != x == NULL
  x->fld
// 

Signed-off-by: Julia Lawall 

---
 sound/soc/omap/omap-hdmi-audio.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/omap/omap-hdmi-audio.c
index 584b237..f83cc2b 100644
--- a/sound/soc/omap/omap-hdmi-audio.c
+++ b/sound/soc/omap/omap-hdmi-audio.c
@@ -368,6 +368,8 @@ static int omap_hdmi_audio_probe(struct platform_device 
*pdev)
card->owner = THIS_MODULE;
card->dai_link =
devm_kzalloc(dev, sizeof(*(card->dai_link)), GFP_KERNEL);
+   if (!card->dai_link)
+   return -ENOMEM;
card->dai_link->name = card->name;
card->dai_link->stream_name = card->name;
card->dai_link->cpu_dai_name = dev_name(ad->dssdev);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] ASoC: imx-pcm-dma: add NULL test

[Julia Lawall]

Add NULL test on call to devm_kzalloc.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression x;
@@

* x = devm_kzalloc(...);
  ... when != x == NULL
  *x
// 

Signed-off-by: Julia Lawall 

---
 sound/soc/fsl/imx-pcm-dma.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
index 1fc01ed..f3d3d1f 100644
--- a/sound/soc/fsl/imx-pcm-dma.c
+++ b/sound/soc/fsl/imx-pcm-dma.c
@@ -62,6 +62,8 @@ int imx_pcm_dma_init(struct platform_device *pdev, size_t 
size)
 
config = devm_kzalloc(&pdev->dev,
sizeof(struct snd_dmaengine_pcm_config), GFP_KERNEL);
+   if (!config)
+   return -ENOMEM;
*config = imx_dmaengine_pcm_config;
if (size)
config->prealloc_buffer_size = size;

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

[tip:irq/core] genirq/msi: Export functions to allow MSI domains in modules

[tip-bot for Jake Oshins]

Commit-ID:  a4289dc2ec3a5821076a78ee9678909b4eff297e
Gitweb: http://git.kernel.org/tip/a4289dc2ec3a5821076a78ee9678909b4eff297e
Author: Jake Oshins 
AuthorDate: Thu, 10 Dec 2015 17:52:59 +
Committer:  Thomas Gleixner 
CommitDate: Sun, 20 Dec 2015 12:26:52 +0100

genirq/msi: Export functions to allow MSI domains in modules

The Linux kernel already has the concept of IRQ domain, wherein a
component can expose a set of IRQs which are managed by a particular
interrupt controller chip or other subsystem. The PCI driver exposes
the notion of an IRQ domain for Message-Signaled Interrupts (MSI) from
PCI Express devices. This patch exposes the functions which are
necessary for creating a MSI IRQ domain within a module.

[ tglx: Split it into x86 and core irq parts ]

Signed-off-by: Jake Oshins 
Cc: gre...@linuxfoundation.org
Cc: k...@microsoft.com
Cc: de...@linuxdriverproject.org
Cc: o...@aepfle.de
Cc: a...@canonical.com
Cc: vkuzn...@redhat.com
Cc: haiya...@microsoft.com
Cc: marc.zyng...@arm.com
Cc: bhelg...@google.com
Link: 
http://lkml.kernel.org/r/1449769983-12948-4-git-send-email-ja...@microsoft.com
Signed-off-by: Thomas Gleixner 
---
 drivers/pci/msi.c  | 4 
 kernel/irq/chip.c  | 1 +
 kernel/irq/irqdomain.c | 4 
 3 files changed, 9 insertions(+)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 7eaa4c8..7a0df3f 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -257,6 +257,7 @@ void pci_msi_mask_irq(struct irq_data *data)
 {
msi_set_mask_bit(data, 1);
 }
+EXPORT_SYMBOL_GPL(pci_msi_mask_irq);
 
 /**
  * pci_msi_unmask_irq - Generic irq chip callback to unmask PCI/MSI interrupts
@@ -266,6 +267,7 @@ void pci_msi_unmask_irq(struct irq_data *data)
 {
msi_set_mask_bit(data, 0);
 }
+EXPORT_SYMBOL_GPL(pci_msi_unmask_irq);
 
 void default_restore_msi_irqs(struct pci_dev *dev)
 {
@@ -1126,6 +1128,7 @@ struct pci_dev *msi_desc_to_pci_dev(struct msi_desc *desc)
 {
return to_pci_dev(desc->dev);
 }
+EXPORT_SYMBOL(msi_desc_to_pci_dev);
 
 void *msi_desc_to_pci_sysdata(struct msi_desc *desc)
 {
@@ -1285,6 +1288,7 @@ struct irq_domain *pci_msi_create_irq_domain(struct 
fwnode_handle *fwnode,
domain->bus_token = DOMAIN_BUS_PCI_MSI;
return domain;
 }
+EXPORT_SYMBOL_GPL(pci_msi_create_irq_domain);
 
 /**
  * pci_msi_domain_alloc_irqs - Allocate interrupts for @dev in @domain
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 05e29de..5797909 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -950,6 +950,7 @@ void irq_chip_ack_parent(struct irq_data *data)
data = data->parent_data;
data->chip->irq_ack(data);
 }
+EXPORT_SYMBOL_GPL(irq_chip_ack_parent);
 
 /**
  * irq_chip_mask_parent - Mask the parent interrupt
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 1c9973e..280a7fc 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -60,6 +60,7 @@ struct fwnode_handle *irq_domain_alloc_fwnode(void *data)
fwid->fwnode.type = FWNODE_IRQCHIP;
return &fwid->fwnode;
 }
+EXPORT_SYMBOL_GPL(irq_domain_alloc_fwnode);
 
 /**
  * irq_domain_free_fwnode - Free a non-OF-backed fwnode_handle
@@ -77,6 +78,7 @@ void irq_domain_free_fwnode(struct fwnode_handle *fwnode)
kfree(fwid->name);
kfree(fwid);
 }
+EXPORT_SYMBOL_GPL(irq_domain_free_fwnode);
 
 /**
  * __irq_domain_add() - Allocate a new irq_domain data structure
@@ -1013,6 +1015,7 @@ struct irq_data *irq_domain_get_irq_data(struct 
irq_domain *domain,
 
return NULL;
 }
+EXPORT_SYMBOL_GPL(irq_domain_get_irq_data);
 
 /**
  * irq_domain_set_hwirq_and_chip - Set hwirq and irqchip of @virq at @domain
@@ -1343,6 +1346,7 @@ struct irq_data *irq_domain_get_irq_data(struct 
irq_domain *domain,
 
return (irq_data && irq_data->domain == domain) ? irq_data : NULL;
 }
+EXPORT_SYMBOL_GPL(irq_domain_get_irq_data);
 
 /**
  * irq_domain_set_info - Set the complete data for a @virq in @domain
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] RTC/PCF85063: fix time/date reading (part II)

[Alexandre Belloni]

Hi,

On 07/12/2015 at 14:49:33 +0100, Juergen Borleis wrote :
> Use the function to read the whole time/date register in one turn and now
> check if the RTC signals an invalid time/date (due to a battery power loss
> for example). In this case ignore the time/date until it is really set
> again.
> 
> Signed-off-by: Juergen Borleis 
> ---
>  drivers/rtc/rtc-pcf85063.c | 45 +++--
>  1 file changed, 19 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
> index 75f2866..abed934 100644
> --- a/drivers/rtc/rtc-pcf85063.c
> +++ b/drivers/rtc/rtc-pcf85063.c
> @@ -22,6 +22,7 @@
>  #define PCF85063_REG_CTRL2   0x01
>  
>  #define PCF85063_REG_SC  0x04 /* datetime */
> +#define PCF85063_REG_SC_OS   0x80
>  #define PCF85063_REG_MN  0x05
>  #define PCF85063_REG_HR  0x06
>  #define PCF85063_REG_DM  0x07
> @@ -77,39 +78,31 @@ static int pcf85063_read_time(struct i2c_client *client, 
> u8 *buf, u16 size)
>   */
>  static int pcf85063_get_datetime(struct i2c_client *client, struct rtc_time 
> *tm)
>  {
> + int rc;
>   struct pcf85063 *pcf85063 = i2c_get_clientdata(client);
> - unsigned char buf[13] = { PCF85063_REG_CTRL1 };
> - struct i2c_msg msgs[] = {
> - {/* setup read ptr */
> - .addr = client->addr,
> - .len = 1,
> - .buf = buf
> - },
> - {/* read status + date */
> - .addr = client->addr,
> - .flags = I2C_M_RD,
> - .len = 13,
> - .buf = buf
> - },
> - };
> + u8 regs[7];
>  
> - /* read registers */
> - if ((i2c_transfer(client->adapter, msgs, 2)) != 2) {
> - dev_err(&client->dev, "%s: read error\n", __func__);
> - return -EIO;

Isn't that already reading the time and date register in one block? I'd
say you are simply reading less registers. Also, maybe you could use
i2c_smbus_read_block_data?


> + rc = pcf85063_read_time(client, regs, sizeof(regs));
> + if (rc < 0)
> + return rc;
> +
> + /* if the clock has lost its power it makes no sense to use its time */
> + if (regs[0] & PCF85063_REG_SC_OS) {
> + dev_warn(&client->dev, "Power loss detected, invalid time\n");
> + return -EINVAL;
>   }

That part is more useful and as I understand it is what you are trying
to fix.


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

This Is A MIRACLE, I Have Cured My Diabetes, from: Latoya Richards

[Latoya Richards]

.

Hi,

There is a complete natural treatment that treats the r00t cause of diabetes 
that the medical establishment has been hiding from you all along. A treatment 
that is 100 percent effective yet totally unknown to your doctor and almost all 
doctors around the country.

Watch our presentaion below.
http://Safe-ur-Diabetes.yolasite.com/?cr=2019mjovy-lfsofmx-xwhfs.lfsofm.psh/?ts=2019mjovy-lfsofmx-xwhfs.lfsofm.psh

Cheers,

Yvette Dianne Miller-Lewis

























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

[Ricardo Ribalda Delgado]

ad5761 is a 1-channel DAC with configurable output range.
The driver uses the regulator interface for its voltage ref.

It shares its register layout with ad5761r, ad5721 and ad5721r.

Differences:
ad5761* are 16 bit, ad5721* are 12 bits.
ad57*1r have an internal reference.
---

v2: A lot of CodeStyle Fixes
Thanks to Peter Meerwald-Stadler  and 
Jonathan Cameron 

This v2 has not been tested on real hardware. I will have access
to the board after New Year.


 CREDITS  |   1 +
 drivers/iio/dac/Kconfig  |  10 ++
 drivers/iio/dac/Makefile |   1 +
 drivers/iio/dac/ad5761.c | 450 +++
 4 files changed, 462 insertions(+)
 create mode 100644 drivers/iio/dac/ad5761.c

diff --git a/CREDITS b/CREDITS
index 8207cc6..44ea433 100644
--- a/CREDITS
+++ b/CREDITS
@@ -3035,6 +3035,7 @@ D: PLX USB338x driver
 D: PCA9634 driver
 D: Option GTM671WFS
 D: Fintek F81216A
+D: AD5761 iio driver
 D: Various kernel hacks
 S: Qtechnology A/S
 S: Valby Langgade 142
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index e701e28..4caedd6 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -111,6 +111,16 @@ config AD5755
  To compile this driver as a module, choose M here: the
  module will be called ad5755.
 
+config AD5761
+   tristate "Analog Devices AD5761/61R/21/21R DAC driver"
+   depends on SPI_MASTER
+   help
+ Say yes here to build support for Analog Devices AD5761, AD5761R, 
AD5721,
+ AD5721R Digital to Analog Converter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad5761.
+
 config AD5764
tristate "Analog Devices AD5764/64R/44/44R DAC driver"
depends on SPI_MASTER
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 63ae056..cb525b5 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_AD5504) += ad5504.o
 obj-$(CONFIG_AD5446) += ad5446.o
 obj-$(CONFIG_AD5449) += ad5449.o
 obj-$(CONFIG_AD5755) += ad5755.o
+obj-$(CONFIG_AD5761) += ad5761.o
 obj-$(CONFIG_AD5764) += ad5764.o
 obj-$(CONFIG_AD5791) += ad5791.o
 obj-$(CONFIG_AD5686) += ad5686.o
diff --git a/drivers/iio/dac/ad5761.c b/drivers/iio/dac/ad5761.c
new file mode 100644
index 000..6c96150
--- /dev/null
+++ b/drivers/iio/dac/ad5761.c
@@ -0,0 +1,450 @@
+/*
+ * AD5721, AD5721R, AD5761, AD5761R, Voltage Output Digital to Analog Converter
+ *
+ * Copyright 2015 Qtechnology A/S
+ *
+ * Licensed under the GPL-2.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AD5761_ADDR(addr)  ((addr & 0xf) << 16)
+#define AD5761_ADDR_NOOP   0x0
+#define AD5761_ADDR_DAC_WRITE  0x3
+#define AD5761_ADDR_CTRL_WRITE_REG 0x4
+#define AD5761_ADDR_SW_DATA_RESET  0x7
+#define AD5761_ADDR_DAC_READ   0xb
+#define AD5761_ADDR_CTRL_READ_REG  0xc
+#define AD5761_ADDR_SW_FULL_RESET  0xf
+
+#define AD5761_CTRL_USE_INTVREFBIT(5)
+#define AD5761_CTRL_ETSBIT(6)
+
+/**
+ * struct ad5761_chip_info - chip specific information
+ * @int_vref:  Value of the internal reference voltage in mV - 0 if external
+ * reference voltage is used
+ * @channel:   channel specification
+*/
+
+struct ad5761_chip_info {
+   unsigned long int_vref;
+   const struct iio_chan_spec channel;
+};
+
+struct ad5761_range_params {
+   int m;
+   int c;
+};
+
+enum ad5761_supported_device_ids {
+   ID_AD5721,
+   ID_AD5721R,
+   ID_AD5761,
+   ID_AD5761R,
+};
+
+enum ad5761_range_ids {
+   MODE_M10V_10V,
+   MODE_0V_10V,
+   MODE_M5V_5V,
+   MODE_0V_5V,
+   MODE_M2V5_7V5,
+   MODE_M3V_3V,
+   MODE_0V_16V,
+   MODE_0V_20V,
+};
+
+/**
+ * struct ad5761_state - driver instance specific data
+ * @spi:   spi_device
+ * @chip_info: chip model specific constants
+ * @vref_reg:  reference voltage regulator
+ * @use_intref:true when the internal voltage reference is used
+ * @vref:  actual voltage reference in mVolts
+ * @range: output range mode used
+ * @data:  cache aligned spi buffer
+ */
+struct ad5761_state {
+   struct spi_device   *spi;
+   struct regulator*vref_reg;
+
+   bool use_intref;
+   int vref;
+   enum ad5761_range_ids range;
+
+   /*
+* DMA (thus cache coherency maintenance) requires the
+* transfer buffers to live in their own cache lines.
+*/
+   union {
+   __be32 d32;
+   u8 d8[4];
+   } data[3] cacheline_aligned;
+};
+
+static const struct ad5761_range_params ad5761_range_params[] = {
+   [MODE_M10V_10V] = {
+   .m = 80,
+   .c = 40,
+   },
+   [MODE_0V_10V] = {
+   .m = 40,
+   .c = 0,
+   },
+

Re: [PATCH 3/3] RTC/PCF85063: fix time/date setting

[Alexandre Belloni]

On 07/12/2015 at 14:49:34 +0100, Juergen Borleis wrote :
> When setting a new time/date the RTC's clock must be stopped first, in
> order to write the time/date registers in an atomic manner.
> So, this change stops the clock first and then writes the time/date
> registers and the clock control register (to re-enable the clock) in one
> turn.
> 

I'd have the same comment for that patch. Using
i2c_smbus_write_byte_data and i2c_smbus_write_block_data would make the
code clearer and also more robust because it takes care of
retransmissions for example.


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

[tip:x86/apic] x86/irq: Export functions to allow MSI domains in modules

[tip-bot for Jake Oshins]

Commit-ID:  c8f3e518d3444ee9200a4987421fcee60f768f11
Gitweb: http://git.kernel.org/tip/c8f3e518d3444ee9200a4987421fcee60f768f11
Author: Jake Oshins 
AuthorDate: Thu, 10 Dec 2015 17:52:59 +
Committer:  Thomas Gleixner 
CommitDate: Sun, 20 Dec 2015 12:40:49 +0100

x86/irq: Export functions to allow MSI domains in modules

The Linux kernel already has the concept of IRQ domain, wherein a
component can expose a set of IRQs which are managed by a particular
interrupt controller chip or other subsystem. The PCI driver exposes
the notion of an IRQ domain for Message-Signaled Interrupts (MSI) from
PCI Express devices. This patch exposes the functions which are
necessary for creating a MSI IRQ domain within a module.

[ tglx: Split it into x86 and core irq parts ]

Signed-off-by: Jake Oshins 
Cc: gre...@linuxfoundation.org
Cc: k...@microsoft.com
Cc: de...@linuxdriverproject.org
Cc: o...@aepfle.de
Cc: a...@canonical.com
Cc: vkuzn...@redhat.com
Cc: haiya...@microsoft.com
Cc: marc.zyng...@arm.com
Cc: bhelg...@google.com
Link: 
http://lkml.kernel.org/r/1449769983-12948-4-git-send-email-ja...@microsoft.com
Signed-off-by: Thomas Gleixner 
---
 arch/x86/include/asm/msi.h| 6 ++
 arch/x86/kernel/apic/msi.c| 8 +---
 arch/x86/kernel/apic/vector.c | 2 ++
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/msi.h b/arch/x86/include/asm/msi.h
index 93724cc..eb4b09b 100644
--- a/arch/x86/include/asm/msi.h
+++ b/arch/x86/include/asm/msi.h
@@ -1,7 +1,13 @@
 #ifndef _ASM_X86_MSI_H
 #define _ASM_X86_MSI_H
 #include 
+#include 
 
 typedef struct irq_alloc_info msi_alloc_info_t;
 
+int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
+   msi_alloc_info_t *arg);
+
+void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc);
+
 #endif /* _ASM_X86_MSI_H */
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 5f1feb6..ade2532 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -96,8 +96,8 @@ static irq_hw_number_t pci_msi_get_hwirq(struct 
msi_domain_info *info,
return arg->msi_hwirq;
 }
 
-static int pci_msi_prepare(struct irq_domain *domain, struct device *dev,
-  int nvec, msi_alloc_info_t *arg)
+int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
+   msi_alloc_info_t *arg)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct msi_desc *desc = first_pci_msi_entry(pdev);
@@ -113,11 +113,13 @@ static int pci_msi_prepare(struct irq_domain *domain, 
struct device *dev,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(pci_msi_prepare);
 
-static void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc)
+void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc)
 {
arg->msi_hwirq = pci_msi_domain_calc_hwirq(arg->msi_dev, desc);
 }
+EXPORT_SYMBOL_GPL(pci_msi_set_desc);
 
 static struct msi_domain_ops pci_msi_domain_ops = {
.get_hwirq  = pci_msi_get_hwirq,
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 861bc59..908cb37 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -29,6 +29,7 @@ struct apic_chip_data {
 };
 
 struct irq_domain *x86_vector_domain;
+EXPORT_SYMBOL_GPL(x86_vector_domain);
 static DEFINE_RAW_SPINLOCK(vector_lock);
 static cpumask_var_t vector_cpumask;
 static struct irq_chip lapic_controller;
@@ -66,6 +67,7 @@ struct irq_cfg *irqd_cfg(struct irq_data *irq_data)
 
return data ? &data->cfg : NULL;
 }
+EXPORT_SYMBOL_GPL(irqd_cfg);
 
 struct irq_cfg *irq_cfg(unsigned int irq)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [char-misc-next 4/7] watchdog: mei_wdt: add status debugfs entry

[Winkler, Tomas]

> >>> +#if IS_ENABLED(CONFIG_DEBUG_FS)
> >>> +static const char *mei_wdt_state_str(enum mei_wdt_state state)
> >>> +{
> >>> + switch (state) {
> >>> + case MEI_WDT_IDLE: return "IDLE";
> >>> + case MEI_WDT_START: return "START";
> >>> + case MEI_WDT_RUNNING: return "RUNNING";
> >>> + case MEI_WDT_STOPPING: return "STOPPING";
> >>> + default: return "unknown";
> >>
> >> Doesn't this cause checkpatch warnings ?
> > It doesn't and also checkpatch.pl  is just a help tool.
> 
> I should have said "Doesn't this violate the single-statement-per-line"
> coding style rule, but I guess then you'd argue that "case xxx:" is not
> a statement.

I believe it is reasonably readable , but I don't have a strong feeling about 
it, if you do I can change it.

Tomas 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/9] phy: omap-usb2: use *syscon* framework API to power on/off the PHY

[Kishon Vijay Abraham I]

Hi Rob,

On Sunday 20 December 2015 09:09 AM, Rob Herring wrote:
> On Tue, Dec 15, 2015 at 02:46:08PM +0530, Kishon Vijay Abraham I wrote:
>> Deprecate using phy-omap-control driver to power on/off the PHY,
>> and use *syscon* framework to do the same. This handles
>> powering on/off the PHY for the USB2 PHYs used in various TI SoCs.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
>>  drivers/phy/phy-omap-usb2.c  |   94 
>> ++
>>  include/linux/phy/omap_usb.h |   23 ++
>>  3 files changed, 107 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
>> b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> index 49e5b0c..a3b3945 100644
>> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> @@ -31,6 +31,8 @@ OMAP USB2 PHY
>>  
>>  Required properties:
>>   - compatible: Should be "ti,omap-usb2"
>> +   Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
>> +   in DRA7x
> 
> The 2nd instance is different somehow?

yeah, the bit fields are slightly different.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtc: support DS1302 RTC on ICP DAS LP-8x4x

[Sergei Ianovich]

On Sat, 2015-12-19 at 21:38 -0600, Rob Herring wrote:
> On Tue, Dec 15, 2015 at 08:45:23PM +0300, Sergei Ianovich wrote:
> 
> Nothing in this is specific to ICP, so the subject should be updated.
> 
> > Signed-off-by: Sergei Ianovich 
> > CC: Alexandre Belloni 
> > ---
> >    v4..v5
> >    * drop THIS_MODULE from struct platform driver
> >    * use "dallas" for vendor name per vendor-prefixes.txt
> > 
> >    v3..v4
> >    * move DTS bindings to a different patch
> > 
> >    v2..v3
> >    * use usleep_range instead of custom nsleep
> >    * number change (07/16 -> 09/21)
> > 
> >    v0..v2
> >    * use device tree
> >    * use devm helpers where possible
> > 
> >  .../devicetree/bindings/rtc/rtc-ds1302.txt |  14 +++
> >  drivers/rtc/Kconfig|   2 +-
> >  drivers/rtc/rtc-ds1302.c   | 100
> > -
> >  3 files changed, 113 insertions(+), 3 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-
> > ds1302.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> > b/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> > new file mode 100644
> > index 000..810613b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> > @@ -0,0 +1,14 @@
> > +* Dallas Semiconductor DS-1302 RTC
> > +
> > +Simple device which could be used to store date/time between
> > reboots.
> > +
> > +Required properties:
> > +- compatible : Should be "dallas,rtc-ds1302"
> > +- reg : Should be address and size of IO memory region
> 
> This device is a SPI (or SPI like?) interface. So you have some sort
> of 
> of FPGA logic in between the cpu and ds1302. The DT should have a node
> for the controller and then the ds1302 as a child of it. A full blown 
> SPI driver may be overkill here, but that's a separate discussion from
> the DT binding.

Below is the quote from the actual DT of LP-8x4x:
> fpga@5 {
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 5 0x300 0x1>;
> interrupt-parent = <&fpgairq>;
> 
> rtc@901c {
> compatible = "dallas,rtc-ds1302";
> reg = <0x901c 0x1>;
> status = "okay";
> };

You are right about the topology. ds1302 is a half-duplex SPI device.
Does this mean I should rewrite the driver to handle the chip as a slave
SPI device, and then provide a master SPI functionality at the FPGA?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

firmware_class warnings on resume

[Andy Lutomirski]

I hit this warning fairly frequently when resuming 4.4-rc5:

ret = usermodehelper_read_trylock();
if (WARN_ON(ret)) {
dev_err(device, "firmware: %s will not be loaded\n",
name);
goto out;
}

It seems like it could be improved in two ways fairly easily:

1. Shouldn't firmware_class try the direct load before trying to get
the usermodehelper lock?

2. Why is the !NOWAIT case doing a trylock?  That seems wrong.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [char-misc-next v2 6/7] watchdog: mei_wdt: register wd device only if required

[Winkler, Tomas]

> 
> On 12/17/2015 06:49 AM, Tomas Winkler wrote:
> > From: Alexander Usyskin 
> >
> > For Intel Broadwell and newer platforms, the ME device can inform
> > the host whether the watchdog functionality is activated or not.
> > If the watchdog functionality is not activated then the watchdog interface
> > can be not registered and eliminate unnecessary pings and hence lower the
> > power consumption by avoiding waking up the device.
> >
> > Signed-off-by: Alexander Usyskin 
> > Signed-off-by: Tomas Winkler 
> > ---
> > V2: rework unregistration
> >
> >   drivers/watchdog/mei_wdt.c | 180
> +
> >   1 file changed, 167 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
> > index a3f1c1613c32..00d1b8e630b7 100644
> > --- a/drivers/watchdog/mei_wdt.c
> > +++ b/drivers/watchdog/mei_wdt.c
> > @@ -16,6 +16,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >
> >   #include 
> > @@ -38,43 +39,54 @@
> >
> >   /* Sub Commands */
> >   #define MEI_MC_START_WD_TIMER_REQ  0x13
> > +#define MEI_MC_START_WD_TIMER_RES  0x83
> > +#define   MEI_WDT_STATUS_SUCCESS 0
> > +#define   MEI_WDT_WDSTATE_NOT_REQUIRED 0x1
> >   #define MEI_MC_STOP_WD_TIMER_REQ   0x14
> >
> >   /**
> >* enum mei_wdt_state - internal watchdog state
> >*
> > + * @MEI_WDT_PROBE: wd in probing stage
> >* @MEI_WDT_IDLE: wd is idle and not opened
> >* @MEI_WDT_START: wd was opened, start was called
> >* @MEI_WDT_RUNNING: wd is expecting keep alive pings
> >* @MEI_WDT_STOPPING: wd is stopping and will move to IDLE
> > + * @MEI_WDT_NOT_REQUIRED: wd device is not required
> >*/
> >   enum mei_wdt_state {
> > +   MEI_WDT_PROBE,
> > MEI_WDT_IDLE,
> > MEI_WDT_START,
> > MEI_WDT_RUNNING,
> > MEI_WDT_STOPPING,
> > +   MEI_WDT_NOT_REQUIRED,
> >   };
> >
> > -#if IS_ENABLED(CONFIG_DEBUG_FS)
> >   static const char *mei_wdt_state_str(enum mei_wdt_state state)
> >   {
> > switch (state) {
> > +   case MEI_WDT_PROBE: return "PROBE";
> > case MEI_WDT_IDLE: return "IDLE";
> > case MEI_WDT_START: return "START";
> > case MEI_WDT_RUNNING: return "RUNNING";
> > case MEI_WDT_STOPPING: return "STOPPING";
> > +   case MEI_WDT_NOT_REQUIRED: return "NOT_REQUIRED";
> > default: return "unknown";
> > }
> >   }
> > -#endif /* CONFIG_DEBUG_FS */
> >
> >   /**
> >* struct mei_wdt - mei watchdog driver
> >* @wdd: watchdog device
> >* @refcnt: watchdog device reference counter
> > + * @reg_lock: watchdog device registration lock
> > + * @is_registered: is watchdog device registered
> >*
> > - * @state: watchdog internal state
> >* @cldev: mei watchdog client device
> > + * @state: watchdog internal state
> > + * @resp_required: ping required response
> > + * @response: ping response
> >* @timeout: watchdog current timeout
> >*
> >* @dbgfs_dir: debugfs dir entry
> > @@ -82,9 +94,13 @@ static const char *mei_wdt_state_str(enum
> mei_wdt_state state)
> >   struct mei_wdt {
> > struct watchdog_device wdd;
> > struct kref refcnt;
> > +   struct mutex reg_lock;
> > +   bool   is_registered;
> >
> > struct mei_cl_device *cldev;
> > enum mei_wdt_state state;
> > +   bool resp_required;
> > +   struct completion response;
> > u16 timeout;
> >
> >   #if IS_ENABLED(CONFIG_DEBUG_FS)
> > @@ -121,6 +137,19 @@ struct mei_wdt_start_request {
> >   } __packed;
> >
> >   /**
> > + * struct mei_wdt_start_response watchdog start/ping response
> > + *
> > + * @hdr: Management Control Command Header
> > + * @status: operation status
> > + * @wdstate: watchdog status bit mask
> > + */
> > +struct mei_wdt_start_response {
> > +   struct mei_mc_hdr hdr;
> > +   u8 status;
> > +   u8 wdstate;
> > +} __packed;
> > +
> > +/**
> >* struct mei_wdt_stop_request - watchdog stop
> >*
> >* @hdr: Management Control Command Header
> > @@ -192,6 +221,23 @@ static void mei_wdt_release(struct kref *ref)
> >   }
> >
> >   /**
> > + * mei_wdt_unregister - unregister from the watchdog subsystem
> > + *
> > + * @wdt: mei watchdog device
> > + */
> > +static void mei_wdt_unregister(struct mei_wdt *wdt)
> > +{
> > +
> > +   mutex_lock(&wdt->reg_lock);
> > +   if (wdt->is_registered) {
> > +   clear_bit(WDOG_ACTIVE, &wdt->wdd.status);
> 
> WDOG_ACTIVE is commonly handled by the core. Why does it have to be
> touched here ?

This have to be cleaned otherwise we ops->start is won't be called on new open()

> I am a bit concerned about the entire sequence.
> 
> If the following happens
> 
> - watchdog character device is opened
> - watchdog goes away
> - watchdog reappears
> - watchdog character device is accessed


> the code may access the driver through an old instance of the watchdog
> character device. The behavior in this situation is pretty much undefined.
> It may work, but only by luck, not by design.

You won't get through as the file descriptor is stal

Re: [PATCH v3 3/7] tpm_tis: Do not fall back to a hardcoded address for TPM2

[Jarkko Sakkinen]

On Fri, Dec 18, 2015 at 09:51:27AM -0700, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2015 at 11:34:32AM +0200, Jarkko Sakkinen wrote:
> > > + st = acpi_get_table(ACPI_SIG_TPM2, 1,
> > > + (struct acpi_table_header **) &tbl);
> > > + if (ACPI_FAILURE(st) || tbl->header.length < sizeof(*tbl)) {
> > > + dev_err(&acpi_dev->dev,
> > > + FW_BUG "failed to get TPM2 ACPI table\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + if (tbl->start_method != ACPI_TPM2_MEMORY_MAPPED)
> > >   return -ENODEV;
> > >  
> > >   INIT_LIST_HEAD(&resources);
> > > @@ -996,6 +978,12 @@ static int tpm_tis_acpi_init(struct acpi_device 
> > > *acpi_dev)
> > >  
> > >   acpi_dev_free_resource_list(&resources);
> > >  
> > > + if (tpm_info.start == 0 && tpm_info.len == 0) {
> > > + dev_err(&acpi_dev->dev,
> > > + FW_BUG "TPM2 ACPI table does not define a memory 
> > > resource\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > 
> > I guess this the only relevant change in this patch? You should propose
> > removal of is_fifo() as a separate patch if that makes sense. This patch
> > is now doing orthogonal things.
> 
> No, the return code changes are relevant too, and are why is_fifo was
> best un-inlined.
> 
> The patch is fixing all the ACPI data validatation in one go, not just
> the resource range, the description notes this.

Got you. I think I'm good with this patch.

Reviewed-by: Jarkko Sakkinen 

> Jason

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: hv: vmbus: fix the building warning with hyperv-keyboard

[Dexuan Cui]

With the recent change af3ff643ea91ba64dd8d0b1cbed54d44512f96cd
(Drivers: hv: vmbus: Use uuid_le type consistently), we always get this
warning:

  CC [M]  drivers/input/serio/hyperv-keyboard.o
drivers/input/serio/hyperv-keyboard.c:427:2: warning: missing braces around
initializer [-Wmissing-braces]
  { HV_KBD_GUID, },
  ^
drivers/input/serio/hyperv-keyboard.c:427:2: warning: (near initialization
for ‘id_table[0].guid.b’) [-Wmissing-braces]

The patch fixes the warning.

Signed-off-by: Dexuan Cui 
---
 drivers/input/serio/hyperv-keyboard.c | 10 --
 include/linux/hyperv.h|  8 
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/input/serio/hyperv-keyboard.c 
b/drivers/input/serio/hyperv-keyboard.c
index e74e5d6..c948866 100644
--- a/drivers/input/serio/hyperv-keyboard.c
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -412,16 +412,6 @@ static int hv_kbd_remove(struct hv_device *hv_dev)
return 0;
 }
 
-/*
- * Keyboard GUID
- * {f912ad6d-2b17-48ea-bd65-f927a61c7684}
- */
-#define HV_KBD_GUID \
-   .guid = { \
-   0x6d, 0xad, 0x12, 0xf9, 0x17, 0x2b, 0xea, 0x48, \
-   0xbd, 0x65, 0xf9, 0x27, 0xa6, 0x1c, 0x76, 0x84 \
-   }
-
 static const struct hv_vmbus_device_id id_table[] = {
/* Keyboard guid */
{ HV_KBD_GUID, },
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 179ff33..753dbad 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1079,6 +1079,14 @@ u64 hv_do_hypercall(u64 control, void *input, void 
*output);
0x8b, 0xa1, 0xa1, 0xf3, 0xf9, 0x5a)
 
 /*
+ * Keyboard GUID
+ * {f912ad6d-2b17-48ea-bd65-f927a61c7684}
+ */
+#define HV_KBD_GUID \
+   .guid = UUID_LE(0xf912ad6d, 0x2b17, 0x48ea, 0xbd, 0x65, \
+   0xf9, 0x27, 0xa6, 0x1c, 0x76, 0x84)
+
+/*
  * VSS (Backup/Restore) GUID
  */
 #define HV_VSS_GUID \
-- 
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 v5 2/2] spi: sun4i: Add support for wait time between word transmissions

[Marcus Weseloh]

Hi,

2015-12-18 12:16 GMT+01:00 Maxime Ripard :

>>   sun4i_spi_write(sspi, SUN4I_CLK_CTL_REG, reg);
>>
>> + /*
>> +  * Setup wait time between words.
>> +  *
>> +  * Wait time is set in SPI_CLK cycles. The SPI hardware needs 3
>> +  * additional cycles to setup the wait counter, so the minimum delay
>> +  * time is 4 cycles.
>> +  */
>> + if (spi->word_wait_ns) {
>> + clk_ns = DIV_ROUND_UP(10, tfr->speed_hz);
>
> You should use the actual rate of the clock returned by clk_get_rate
> (or probably just use mclk_rate).
>
> The clock driver might round the frequency to something else than what
> was set in clk_set_rate, which would make your calculation here a bit
> off.

Yes, good point! And as the wait clock counter is based on the actual
SPI_CLK and not the mod clock, I need to calculate the exact clock
myself before handling the wait clock setting. Will amend the patch
and send a new version.

While looking into this, I also noticed a problem with a previous
patch of mine, which changed the spi-sun[46]i to use
transfer->speed_hz instead of the spi->max_speed_hz: I also changed
the mclk_rate calculation to be based on tfr->speed_hz, which should
have stayed with spi->max_speed_hz. In the current state, the clock
calculations only ever increase mclk_rate, wich leads to very
different clocks being set depending on which clock was used on the
previous transfer. Will send a fix for that as well in a separate
patch.

Cheers,

   Marcus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 0/6] Support the rk3036 Kylin board

[Caesar Wang]

Hi Heiko,

在 2015年12月20日 01:16, Heiko Stübner 写道:

Hi Caesar,

Am Donnerstag, 17. Dezember 2015, 22:21:46 schrieb Caesar Wang:

Kylin-board is based on RK3036 SOCs, add the initiation
version for working.

I've applied:
- patch1 (please include the "rockchip:" part in dts subjects)
- patch3 (dito)
- patch4 (after merging in patch6 and dropping the hdmi+lcdc parts)


Okay, thanks!

Sync to the rockchip github 
.



Please resubmit the missing parts (audio + graphics) against my dts-branch [0]
after the relevant maintainers have added the code-parts to their trees.


For codec:
RT5616 is existing  in
https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=for-next 
now.


For 3036 vop:
I would like wait a moment from Mark Yao updating the driver.




Thanks
Heiko

[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.5-armsoc/dts32


This series patches have the following decriptions:

PATCH[1/6]:
ARM: dts: fix the correct pinctrl control for rk3036

The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs
can't set the status in the internal.
---

PATCH[2/6]:
ARM: dts: add the lcdc and hdmi node for rk3036

Add the devices is related to display.
Based on the series patches of Mark Yao's
---

PATCH[3/6]:
ARM: dts: add the sdio/sdmmc node for rk3036

Add the wifi/sd card work for kylin board.
---

PATCH[4/6]:
ARM: dts: rockchip: add the kylin board for rk3036

Add the dts for kylin board.
---

PATCH[5/6]:
ARM: dts: add the sound codec for kylin board

Make the codec rt5616 working on kylin board.
The realteak have been upstream for Mark Brown,
I guess need some days to review.

---

PATCH[6/6]:
ARM: dts: add the sdio node for kylin board

Enable the sdio for kylin board.
---



Caesar Wang (6):
   ARM: dts: fix the correct pinctrl control for rk3036
   ARM: dts: add the lcdc and hdmi node for rk3036
   ARM: dts: add the sdio/sdmmc node for rk3036
   ARM: dts: rockchip: add the kylin board for rk3036
   ARM: dts: add the sound codec for kylin board
   ARM: dts: add the sdio node for kylin board

  Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
  arch/arm/boot/dts/Makefile |   1 +
  arch/arm/boot/dts/rk3036-kylin.dts | 345
+ arch/arm/boot/dts/rk3036.dtsi  |
167 -- 4 files changed, 498 insertions(+), 19 deletions(-)
  create mode 100644 arch/arm/boot/dts/rk3036-kylin.dts


___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] posix-clock: Use an unsigned data type for a variable

[SF Markus Elfring]

>> Reuse the type from this poll call instead.
> 
> Why use uint when the function return type it unsigned int?

Do you prefer to express the type modifier once more there?


> On the other hand, why is the function return type unsigned int
> when there is a return of a negative constant?

This implementation detail can trigger further software development
considerations, can't it?

This is a general issue for the exception handling in several functions.
Would you like to improve any more source code around it?

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

Re: [PATCH] Input: xpad - use LED API when identifying wireless controllers

[Pavel Rojtberg]

2015-12-20 8:55 GMT+01:00 Dmitry Torokhov :
> On Sat, Dec 19, 2015 at 10:17:09PM +0100, Clement Calmels wrote:
>> On Wed, 16 Dec 2015 14:44:08 -0800
>> Dmitry Torokhov  wrote:
>>
>> > When lighting up the segment identifying wireless controller, Instead
>> > of sending command directly to the controller, let's do it via LED
>> > API (usinf led_set_brightness) so that LED object state is in sync
>> > with controller state and we'll light up the correct segment on
>> > resume as well.
>> >
>> > Signed-off-by: Dmitry Torokhov 
>> > ---
>> >
>> > I do not have the hardware so please try this out.
>> >
>> >  drivers/input/joystick/xpad.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/input/joystick/xpad.c
>> > b/drivers/input/joystick/xpad.c index 36328b3..00a766b 100644
>> > --- a/drivers/input/joystick/xpad.c
>> > +++ b/drivers/input/joystick/xpad.c
>> > @@ -1118,7 +1118,7 @@ static void xpad_send_led_command(struct
>> > usb_xpad *xpad, int command) */
>> >  static void xpad_identify_controller(struct usb_xpad *xpad)
>> >  {
>> > -   xpad_send_led_command(xpad, (xpad->pad_nr % 4) + 2);
>> > +   led_set_brightness(&xpad->led->led_cdev, (xpad->pad_nr % 4)
>> > + 2); }
>> >
>> >  static void xpad_led_set(struct led_classdev *led_cdev,
>>
>> Hi Dimitri,
>
> Hi Clement,
>
>>
>> My hardware: two wireless xpad 360 using a single usb receiver.
>>
>> Power on the first gamepad => light the "1" led.
>> Power on the second gamepad => light the "2" led.
>>
>> Suspend the PC (systemctl suspend): the two gamepads are "disconnected"
>> => blinking circle.
>>
>> Resume the PC, the two gamepads keep blinking but are working (tested
>> with jstest).
>>
>> Power off and on the gamepad => still blinking.
>> Reload (rmmod/modprobe) the xpad module => still blinking.
>>
>> That said, without your patch, the behavior is exactly the same.
>> It seems that the suspend/resume broke the led feature. Even using
>> the /sys/class/leds/xpad0/brigthness sysfs entry does not work.
>>
>
> OK, so the patch does work (the device is still correctly identified),
> but resume requires additional patches. Could you try 'xpad' branch of
> my tree on kernel.org [1] and let me know if it works for you?
at least on my machine your follow up patch was also required which I merged at:
https://github.com/paroj/xpad/tree/dtor

with this patch the controllers still continue blinking after resume,
however the URB
will still work so they respond to subsequent LED commands triggered
via sysfs (or if they are powered off and on).

I also verified that a LED command is triggered upon resume - however
the controller ignores that.
Maybe it is sent too early/ in the wrong order.

>
> Thanks!
>
> --
> Dmitry
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] posix-clock: Use an unsigned data type for a variable

[Julia Lawall]

On Sun, 20 Dec 2015, SF Markus Elfring wrote:

> >> Reuse the type from this poll call instead.
> > 
> > Why use uint when the function return type it unsigned int?
> 
> Do you prefer to express the type modifier once more there?

I don't know what the sentence means, but I think that the type should be 
referenced in a consistent manner.

> > On the other hand, why is the function return type unsigned int
> > when there is a return of a negative constant?
> 
> This implementation detail can trigger further software development
> considerations, can't it?

It would seem reasonable to address all of the signed/unsigned issues 
related to the function return value at once.

julia

> This is a general issue for the exception handling in several functions.
> Would you like to improve any more source code around it?
> 
> Regards,
> Markus
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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: Indent issus in kernel module development

[chunguang qu]

I tried it.  Not worked unfortunately,.

```bash
$ ~/share/linux/scripts/checkpatch.pl --fix --types=spacing testcompletion.c
total: 0 errors, 0 warnings, 0 lines checked

testcompletion.c has no obvious style problems and is ready for submission.

NOTE: Used message types: SPACING
```

2015-12-19 14:16 GMT+08:00 Joe Perches :
> On Sat, 2015-12-19 at 13:50 +0800, chunguang qu wrote:
>> Yes, I just tried `scripts/Lindent` and it has the same problem.
>>
>> I had compared the source of `Lindent` with `-linux` option of
>> `indent` long time ago, there's seems no major difference.
>> So i used `indent -linux ` above.
>>
>> Thanks for your advice about `emace`, but `vi` is my only editor for
>> dozens of years.
>
> Try:
>
> $ ./scripts/checkpatch.pl --fix --types=spacing 
>



-- 
[Kevin Q (ChunGuang Qu)](mailto:quchungu...@gmail.com) [public
key](http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5B06DCA77BEF043B)
@sdu.edu.cn @gnu.org @mit.edu @grazestar.com @jolijolie.cn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [char-misc-next v2 7/7] watchdog: mei_wdt: re-register device on event

[Winkler, Tomas]

> 
> > > That breaks the existing behaviour of hot pluggable watchdog interfaces
> > > and is different to just about any other device in the kernel. Today with
> > > any desktop or server distribution you can already trivially arrange for
> > > watchdog daemons to start at the point a watchdog is detected dynamically.
> > >
> >
> > Ok, you have a point. Wonder if any distributions are doing that, though.
> > Any idea ?
> 
> I don't know for any of the out of the box mainstream ones.
> 
> There is a second problem if you register the watchdog but don't actually
> have it enabled. Consider the case where a user has the mei watchdog
> disabled and a more advanced watchdog card plugged in - in that case the
> naïvely implemented existing watchdog app may bind to the non-functional
> watchdog, not the correct one.

That's correct, though  WDIOF_ALARMONLY or device identity has to be checked. 
And if mei is disabled one would probably hit ENODEV, still there will be no 
uevent to the user space
when the device is provisioned again, so still I prefer add/removing the 
watchdog device. 

Thanks
Tomas

[GIT PULL] RTC fixes for 4.4 #2

[Alexandre Belloni]

Hi Linus,

Please pull those late fixes for the RTC subsystem for 4.4.

The following changes since commit 3abb1ada21a4fb5b2920457a2e5c8483abb09a45:

  rtc: ds1307: fix alarm reading at probe time (2015-11-26 18:11:26 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
tags/rtc-4.4-3

for you to fetch changes up to 77535acedc26627f16a1a39c1471f942689fe11e:

  rtc: da9063: fix access ordering error during RTC interrupt at system power 
on (2015-12-20 13:39:29 +0100)


RTC fixes for 4.4 #2

A fix for a nasty hardware bug in rk808 and a initialization reordering in
da9063 to fix a possible crash.


Julius Werner (1):
  rtc: rk808: Compensate for Rockchip calendar deviation on November 31st

Steve Twiss (1):
  rtc: da9063: fix access ordering error during RTC interrupt at system 
power on

 drivers/rtc/rtc-da9063.c | 19 +--
 drivers/rtc/rtc-rk808.c  | 48 
 2 files changed, 53 insertions(+), 14 deletions(-)

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH] posix-clock: Use an unsigned data type for a variable

[SF Markus Elfring]

 Reuse the type from this poll call instead.
>>>
>>> Why use uint when the function return type it unsigned int?
>>
>> Do you prefer to express the type modifier once more there?
> 
> I don't know what the sentence means,

Can it be a matter of taste if the key word "unsigned" should be repeated
in such an use case?


> but I think that the type should be referenced in a consistent manner.

How do involved software designers and developers prefer to achieve
data type consistency here?

Which kind of naming convention will get priority?


>>> On the other hand, why is the function return type unsigned int
>>> when there is a return of a negative constant?
>>
>> This implementation detail can trigger further software development
>> considerations, can't it?
> 
> It would seem reasonable to address all of the signed/unsigned issues 
> related to the function return value at once.

Would you like to extend another evolving script for the semantic patch 
language?


I imagine that the general issue around the exception handling will cause
too many software development challenges to tackle them "at once".

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

[tip:locking/core] futex: Drop refcount if requeue_pi() acquired the rtmutex

[tip-bot for Thomas Gleixner]

Commit-ID:  fb75a4282d0d9a3c7c44d940582c2d226cf3acfb
Gitweb: http://git.kernel.org/tip/fb75a4282d0d9a3c7c44d940582c2d226cf3acfb
Author: Thomas Gleixner 
AuthorDate: Sat, 19 Dec 2015 20:07:38 +
Committer:  Thomas Gleixner 
CommitDate: Sun, 20 Dec 2015 12:43:24 +0100

futex: Drop refcount if requeue_pi() acquired the rtmutex

If the proxy lock in the requeue loop acquires the rtmutex for a
waiter then it acquired also refcount on the pi_state related to the
futex, but the waiter side does not drop the reference count.

Add the missing free_pi_state() call.

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: bhuvanesh_surach...@mentor.com
Cc: Andy Lowe 
Link: http://lkml.kernel.org/r/20151219200607.178132...@linutronix.de
Signed-off-by: Thomas Gleixner 
Cc: sta...@vger.kernel.org
---
 kernel/futex.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/futex.c b/kernel/futex.c
index 684d754..24fbc77 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2755,6 +2755,11 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
unsigned int flags,
if (q.pi_state && (q.pi_state->owner != current)) {
spin_lock(q.lock_ptr);
ret = fixup_pi_state_owner(uaddr2, &q, current);
+   /*
+* Drop the reference to the pi state which
+* the requeue_pi() code acquired for us.
+*/
+   free_pi_state(q.pi_state);
spin_unlock(q.lock_ptr);
}
} else {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:locking/core] futex: Rename free_pi_state() to put_pi_state( )

[tip-bot for Thomas Gleixner]

Commit-ID:  29e9ee5d48c35d6cf8afe09bdf03f77125c9ac11
Gitweb: http://git.kernel.org/tip/29e9ee5d48c35d6cf8afe09bdf03f77125c9ac11
Author: Thomas Gleixner 
AuthorDate: Sat, 19 Dec 2015 20:07:39 +
Committer:  Thomas Gleixner 
CommitDate: Sun, 20 Dec 2015 12:43:24 +0100

futex: Rename free_pi_state() to put_pi_state()

free_pi_state() is confusing as it is in fact only freeing/caching the
pi state when the last reference is gone. Rename it to put_pi_state()
which reflects better what it is doing.

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: bhuvanesh_surach...@mentor.com
Cc: Andy Lowe 
Link: http://lkml.kernel.org/r/20151219200607.259636...@linutronix.de
Signed-off-by: Thomas Gleixner 
---
 kernel/futex.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 24fbc77..f1581ff 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -725,9 +725,12 @@ static struct futex_pi_state * alloc_pi_state(void)
 }
 
 /*
+ * Drops a reference to the pi_state object and frees or caches it
+ * when the last reference is gone.
+ *
  * Must be called with the hb lock held.
  */
-static void free_pi_state(struct futex_pi_state *pi_state)
+static void put_pi_state(struct futex_pi_state *pi_state)
 {
if (!pi_state)
return;
@@ -1729,7 +1732,7 @@ retry_private:
case 0:
break;
case -EFAULT:
-   free_pi_state(pi_state);
+   put_pi_state(pi_state);
pi_state = NULL;
double_unlock_hb(hb1, hb2);
hb_waiters_dec(hb2);
@@ -1746,7 +1749,7 @@ retry_private:
 *   exit to complete.
 * - The user space value changed.
 */
-   free_pi_state(pi_state);
+   put_pi_state(pi_state);
pi_state = NULL;
double_unlock_hb(hb1, hb2);
hb_waiters_dec(hb2);
@@ -1815,7 +1818,7 @@ retry_private:
} else if (ret) {
/* -EDEADLK */
this->pi_state = NULL;
-   free_pi_state(pi_state);
+   put_pi_state(pi_state);
goto out_unlock;
}
}
@@ -1824,7 +1827,7 @@ retry_private:
}
 
 out_unlock:
-   free_pi_state(pi_state);
+   put_pi_state(pi_state);
double_unlock_hb(hb1, hb2);
wake_up_q(&wake_q);
hb_waiters_dec(hb2);
@@ -1973,7 +1976,7 @@ static void unqueue_me_pi(struct futex_q *q)
__unqueue_futex(q);
 
BUG_ON(!q->pi_state);
-   free_pi_state(q->pi_state);
+   put_pi_state(q->pi_state);
q->pi_state = NULL;
 
spin_unlock(q->lock_ptr);
@@ -2759,7 +2762,7 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
unsigned int flags,
 * Drop the reference to the pi state which
 * the requeue_pi() code acquired for us.
 */
-   free_pi_state(q.pi_state);
+   put_pi_state(q.pi_state);
spin_unlock(q.lock_ptr);
}
} else {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:locking/core] futex: Cleanup the goto confusion in requeue_pi()

[tip-bot for Thomas Gleixner]

Commit-ID:  885c2cb770b5ac2507c41bc9f91a5d1c98337bee
Gitweb: http://git.kernel.org/tip/885c2cb770b5ac2507c41bc9f91a5d1c98337bee
Author: Thomas Gleixner 
AuthorDate: Sat, 19 Dec 2015 20:07:41 +
Committer:  Thomas Gleixner 
CommitDate: Sun, 20 Dec 2015 12:43:25 +0100

futex: Cleanup the goto confusion in requeue_pi()

out_unlock: does not only drop the locks, it also drops the refcount
on the pi_state. Really intuitive.

Move the label after the put_pi_state() call and use 'break' in the
error handling path of the requeue loop.

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: bhuvanesh_surach...@mentor.com
Cc: Andy Lowe 
Link: http://lkml.kernel.org/r/20151219200607.526665...@linutronix.de
Signed-off-by: Thomas Gleixner 
---
 kernel/futex.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index dcec018..461d438 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1839,20 +1839,25 @@ retry_private:
 */
this->pi_state = NULL;
put_pi_state(pi_state);
-   goto out_unlock;
+   /*
+* We stop queueing more waiters and let user
+* space deal with the mess.
+*/
+   break;
}
}
requeue_futex(this, hb1, hb2, &key2);
drop_count++;
}
 
-out_unlock:
/*
 * We took an extra initial reference to the pi_state either
 * in futex_proxy_trylock_atomic() or in lookup_pi_state(). We
 * need to drop it here again.
 */
put_pi_state(pi_state);
+
+out_unlock:
double_unlock_hb(hb1, hb2);
wake_up_q(&wake_q);
hb_waiters_dec(hb2);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:locking/core] futex: Document pi_state refcounting in requeue code

[tip-bot for Thomas Gleixner]

Commit-ID:  ecb38b78f698a51988ec456751b20440e54702fb
Gitweb: http://git.kernel.org/tip/ecb38b78f698a51988ec456751b20440e54702fb
Author: Thomas Gleixner 
AuthorDate: Sat, 19 Dec 2015 20:07:39 +
Committer:  Thomas Gleixner 
CommitDate: Sun, 20 Dec 2015 12:43:24 +0100

futex: Document pi_state refcounting in requeue code

Documentation of the pi_state refcounting in the requeue code is non
existent. Add it.

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: bhuvanesh_surach...@mentor.com
Cc: Andy Lowe 
Link: http://lkml.kernel.org/r/20151219200607.335938...@linutronix.de
Signed-off-by: Thomas Gleixner 
---
 kernel/futex.c | 51 +++
 1 file changed, 39 insertions(+), 12 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index f1581ff..20c4683 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1709,27 +1709,31 @@ retry_private:
 * exist yet, look it up one more time to ensure we have a
 * reference to it. If the lock was taken, ret contains the
 * vpid of the top waiter task.
+* If the lock was not taken, we have pi_state and an initial
+* refcount on it. In case of an error we have nothing.
 */
if (ret > 0) {
WARN_ON(pi_state);
drop_count++;
task_count++;
/*
-* If we acquired the lock, then the user
-* space value of uaddr2 should be vpid. It
-* cannot be changed by the top waiter as it
-* is blocked on hb2 lock if it tries to do
-* so. If something fiddled with it behind our
-* back the pi state lookup might unearth
-* it. So we rather use the known value than
-* rereading and handing potential crap to
-* lookup_pi_state.
+* If we acquired the lock, then the user space value
+* of uaddr2 should be vpid. It cannot be changed by
+* the top waiter as it is blocked on hb2 lock if it
+* tries to do so. If something fiddled with it behind
+* our back the pi state lookup might unearth it. So
+* we rather use the known value than rereading and
+* handing potential crap to lookup_pi_state.
+*
+* If that call succeeds then we have pi_state and an
+* initial refcount on it.
 */
ret = lookup_pi_state(ret, hb2, &key2, &pi_state);
}
 
switch (ret) {
case 0:
+   /* We hold a reference on the pi state. */
break;
case -EFAULT:
put_pi_state(pi_state);
@@ -1804,19 +1808,37 @@ retry_private:
 * of requeue_pi if we couldn't acquire the lock atomically.
 */
if (requeue_pi) {
-   /* Prepare the waiter to take the rt_mutex. */
+   /*
+* Prepare the waiter to take the rt_mutex. Take a
+* refcount on the pi_state and store the pointer in
+* the futex_q object of the waiter.
+*/
atomic_inc(&pi_state->refcount);
this->pi_state = pi_state;
ret = rt_mutex_start_proxy_lock(&pi_state->pi_mutex,
this->rt_waiter,
this->task);
if (ret == 1) {
-   /* We got the lock. */
+   /*
+* We got the lock. We do neither drop the
+* refcount on pi_state nor clear
+* this->pi_state because the waiter needs the
+* pi_state for cleaning up the user space
+* value. It will drop the refcount after
+* doing so.
+*/
requeue_pi_wake_futex(this, &key2, hb2);
drop_count++;
continue;
} else if (ret) {
-   /* -EDEADLK */
+   /*
+* rt_mutex_start_proxy_lock() detected a
+* potential deadlock when we tried to queue
+

[tip:locking/core] futex: Remove pointless put_pi_state calls in requeue()

[tip-bot for Thomas Gleixner]

Commit-ID:  4959f2de11ca532a120a337429e5576fd283700f
Gitweb: http://git.kernel.org/tip/4959f2de11ca532a120a337429e5576fd283700f
Author: Thomas Gleixner 
AuthorDate: Sat, 19 Dec 2015 20:07:40 +
Committer:  Thomas Gleixner 
CommitDate: Sun, 20 Dec 2015 12:43:25 +0100

futex: Remove pointless put_pi_state calls in requeue()

In the error handling cases we neither have pi_state nor a reference
to it. Remove the pointless code.

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: bhuvanesh_surach...@mentor.com
Cc: Andy Lowe 
Link: http://lkml.kernel.org/r/20151219200607.432780...@linutronix.de
Signed-off-by: Thomas Gleixner 
---
 kernel/futex.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 20c4683..dcec018 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1735,9 +1735,9 @@ retry_private:
case 0:
/* We hold a reference on the pi state. */
break;
+
+   /* If the above failed, then pi_state is NULL */
case -EFAULT:
-   put_pi_state(pi_state);
-   pi_state = NULL;
double_unlock_hb(hb1, hb2);
hb_waiters_dec(hb2);
put_futex_key(&key2);
@@ -1753,8 +1753,6 @@ retry_private:
 *   exit to complete.
 * - The user space value changed.
 */
-   put_pi_state(pi_state);
-   pi_state = NULL;
double_unlock_hb(hb1, hb2);
hb_waiters_dec(hb2);
put_futex_key(&key2);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:locking/core] futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

[tip-bot for Darren Hart]

Commit-ID:  337f13046ff03717a9e99675284a817527440a49
Gitweb: http://git.kernel.org/tip/337f13046ff03717a9e99675284a817527440a49
Author: Darren Hart 
AuthorDate: Fri, 18 Dec 2015 13:36:37 -0800
Committer:  Thomas Gleixner 
CommitDate: Sun, 20 Dec 2015 12:43:25 +0100

futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

While reviewing Michael Kerrisk's recent futex manpage update, I noticed
that we allow the FUTEX_CLOCK_REALTIME flag for FUTEX_WAIT_BITSET but
not for FUTEX_WAIT.

FUTEX_WAIT is treated as a simple version for FUTEX_WAIT_BITSET
internally (with a bitmask of FUTEX_BITSET_MATCH_ANY). As such, I cannot
come up with a reason for this exclusion for FUTEX_WAIT.

This change does modify the behavior of the futex syscall, changing a
call with FUTEX_WAIT | FUTEX_CLOCK_REALTIME from returning -ENOSYS, to be
equivalent to FUTEX_WAIT_BITSET | FUTEX_CLOCK_REALTIME with a bitset of
FUTEX_BITSET_MATCH_ANY.

Reported-by: Michael Kerrisk 
Signed-off-by: Darren Hart 
Cc: Peter Zijlstra 
Cc: Davidlohr Bueso 
Link: 
http://lkml.kernel.org/r/9f3bdc116d79d23f5ee72ceb9a2a857f5ff8fa29.1450474525.git.dvh...@linux.intel.com
Signed-off-by: Thomas Gleixner 
---
 kernel/futex.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 461d438..8a310e2 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -3084,7 +3084,8 @@ long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t 
*timeout,
 
if (op & FUTEX_CLOCK_REALTIME) {
flags |= FLAGS_CLOCKRT;
-   if (cmd != FUTEX_WAIT_BITSET && cmd != FUTEX_WAIT_REQUEUE_PI)
+   if (cmd != FUTEX_WAIT && cmd != FUTEX_WAIT_BITSET && \
+   cmd != FUTEX_WAIT_REQUEUE_PI)
return -ENOSYS;
}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3] serial: 8250: add gpio support to exar

[Sudip Mukherjee]

Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
can be controlled using gpio interface.
Add support to use these pins and select GPIO_SYSFS also so that these
pins can be used from the userspace through sysfs.

Tested-by: Rob Groner 
Signed-off-by: Sudip Mukherjee 
---

v3: Alan commented on v2, few things like NULL check, name of the gpio chip,
moving some more code into the gpio code. He also commented on it being
a separate module, but since this will not be needed by someone who is not
using Exar chip, and even those who are using, some of them may not need it.
This is optional for only those who wants to use the gpio capability of that
chip. So kept it as a separate module. Waiting for your comments on that.

v2: v1 had problems with build, reported by 0day bot.

 drivers/tty/serial/8250/8250_gpio.c | 261 
 drivers/tty/serial/8250/8250_pci.c  |  19 ++-
 drivers/tty/serial/8250/Kconfig |   8 ++
 drivers/tty/serial/8250/Makefile|   1 +
 include/linux/8250_pci.h|  15 +++
 5 files changed, 303 insertions(+), 1 deletion(-)
 create mode 100644 drivers/tty/serial/8250/8250_gpio.c

diff --git a/drivers/tty/serial/8250/8250_gpio.c 
b/drivers/tty/serial/8250/8250_gpio.c
new file mode 100644
index 000..948236e
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_gpio.c
@@ -0,0 +1,261 @@
+/*
+ * GPIO driver for Exar XR17V35X chip
+ *
+ * Copyright (C) 2015 Sudip Mukherjee 
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "8250.h"
+
+#define EXAR_OFFSET_MPIOLVL_LO 0x90
+#define EXAR_OFFSET_MPIOSEL_LO 0x93
+#define EXAR_OFFSET_MPIOLVL_HI 0x96
+#define EXAR_OFFSET_MPIOSEL_HI 0x99
+
+static LIST_HEAD(exar_list);
+static DEFINE_MUTEX(exar_mtx); /* lock while manipulating the list */
+
+struct exar_gpio_chip {
+   struct gpio_chip gpio_chip;
+   struct mutex lock;
+   struct uart_8250_port *port;
+   struct list_head list;
+   int index;
+   void __iomem *regs;
+   char name[16];
+};
+
+#define to_exar_chip(n) container_of(n, struct exar_gpio_chip, gpio_chip)
+
+static inline unsigned int read_exar_reg(struct exar_gpio_chip *chip,
+int offset)
+{
+   pr_debug("%s regs=%p offset=%x\n", __func__, chip->regs, offset);
+   return readb(chip->regs + offset);
+}
+
+static inline void write_exar_reg(struct exar_gpio_chip *chip, int offset,
+ int value)
+{
+   pr_debug("%s regs=%p value=%x offset=%x\n", __func__, chip->regs,
+value, offset);
+   writeb(value, chip->regs + offset);
+}
+
+void xr17v35x_gpio_exit(struct uart_8250_port *port)
+{
+   struct exar_gpio_chip *exar_gpio, *exar_temp1, *exar_temp2;
+
+   if (!port)
+   return;
+
+   exar_gpio = port->port.private_data;
+   if (!exar_gpio)
+   return;
+
+   mutex_lock(&exar_mtx);
+   list_for_each_entry_safe(exar_temp1, exar_temp2, &exar_list, list) {
+   if (exar_temp1->index == exar_gpio->index) {
+   list_del(&exar_temp1->list);
+   break;
+   }
+   }
+   mutex_unlock(&exar_mtx);
+
+   gpiochip_remove(&exar_gpio->gpio_chip);
+   mutex_destroy(&exar_gpio->lock);
+   iounmap(exar_gpio->regs);
+}
+EXPORT_SYMBOL(xr17v35x_gpio_exit);
+
+static void exar_set(struct gpio_chip *chip, unsigned int reg, int val,
+unsigned int offset)
+{
+   struct exar_gpio_chip *exar_gpio = to_exar_chip(chip);
+   int temp;
+
+   mutex_lock(&exar_gpio->lock);
+   temp = read_exar_reg(exar_gpio, reg);
+   temp &= ~(1 << offset);
+   temp |= val << offset;
+   write_exar_reg(exar_gpio, reg, temp);
+   mutex_unlock(&exar_gpio->lock);
+}
+
+static int exar_direction_output(struct gpio_chip *chip, unsigned int offset,
+int value)
+{
+   if (offset < 8)
+   exar_set(chip, EXAR_OFFSET_MPIOSEL_LO, 0, offset);
+   else
+   exar_set(chip, EXAR_OFFSET_MPIOSEL_HI, 0, offset - 8);
+   return 0;
+}
+
+static int exar_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+   if (offset < 8)
+   exar_set(chip, EXAR_OFFSET_MPIOSEL_LO, 1, offset);
+   else
+   exar_set(chip, EXAR_OFFSET_MPIOSEL_HI, 1, offset - 8);
+   return 0;
+}
+
+static int exar_get(struct gpio_chip *chip, unsigned int reg)
+{
+   int value;
+   struct exar_gpio_chip *exar_gpio = to_exar_chip(chip);
+
+   if (!exar_gpio) {
+   pr_err("%s exar_gpio is NULL\n", __func__);
+   return -ENOMEM;
+   }
+
+   mutex_lock(&exar_gpio->lock);

Re: [PATCH 1/2] x86/msr: add on cpu read/modify/write function

[Thomas Gleixner]

Jacob,

On Fri, 11 Dec 2015, Jacob Pan wrote:
> +static inline int rmwmsrl_safe_on_cpu(unsigned int cpu, u32 msr_no, u64 
> mask, u64 bits)
> +{
> + int err;
> + u64 val;
> +
> + err = rdmsrl_safe(msr_no, &val);
> + if (err)
> + goto out;
> +
> + val &= ~mask;
> + val |= bits;
> +
> + err = wrmsrl_safe(msr_no, val);
> +out:
> + return err;
> +}



> +static void __rmwmsrl_safe(void *info)
> +{
> + int err;
> + struct msr_action *ma = info;
> + u64 val;
> +
> + err = rdmsrl_safe(ma->msr_no, &val);
> + if (err)
> + goto out;
> +
> + val &= ~ma->mask;
> + val |= ma->bits;
> +
> + err = wrmsrl_safe(ma->msr_no, val);
> +
> +out:
> + ma->err = err;

So this is a copy of the above !SMP inline. What's wrong with providing:

 int rmwmsrl_safe(msr_no, clear_mask, set_mask)

in x86/lib/msr.c and make the !SMP variant of rdmsrl_safe_on_cpu() and that
variant for the SMP case a simple wrapper around it?

static void remote_rmwmsrl_safe(void *info)
{
struct msr_action *ma = info;

return rmwmsrl_safe(ma->msr, ma->clear_mask, ma->set_mask);
}

No gotos, no pointless code duplication. Just simple.

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/

Re: [PATCH 05/10] perf tools: Add dynamic sort key for tracepoint events

[Jiri Olsa]

On Wed, Dec 16, 2015 at 12:35:38AM +0900, Namhyung Kim wrote:

SNIP

> +
> + if (!len)
> + len = hde_width(hde);
> +
> + return len;
> +}
> +
> +static int __sort__hde_entry(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
> +  struct hist_entry *he)
> +{
> + struct hpp_dynamic_entry *hde;
> + size_t len = fmt->user_len;
> + struct trace_seq seq;
> + int ret;
> +
> + hde = container_of(fmt, struct hpp_dynamic_entry, hpp);
> +
> + if (!len)
> + len = hde_width(hde);
> +
> + if (hists_to_evsel(he->hists) != hde->evsel)
> + return scnprintf(hpp->buf, hpp->size, "%*.*s", len, len, "N/A");

hum, how can this happen? ... "hists_to_evsel(he->hists) != hde->evsel"

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/10] perf tools: Add dynamic sort key for tracepoint events

[Namhyung Kim]

Hi Jiri,

On Sun, Dec 20, 2015 at 02:51:32PM +0100, Jiri Olsa wrote:
> On Wed, Dec 16, 2015 at 12:35:38AM +0900, Namhyung Kim wrote:
> 
> SNIP
> 
> > +
> > +   if (!len)
> > +   len = hde_width(hde);
> > +
> > +   return len;
> > +}
> > +
> > +static int __sort__hde_entry(struct perf_hpp_fmt *fmt, struct perf_hpp 
> > *hpp,
> > +struct hist_entry *he)
> > +{
> > +   struct hpp_dynamic_entry *hde;
> > +   size_t len = fmt->user_len;
> > +   struct trace_seq seq;
> > +   int ret;
> > +
> > +   hde = container_of(fmt, struct hpp_dynamic_entry, hpp);
> > +
> > +   if (!len)
> > +   len = hde_width(hde);
> > +
> > +   if (hists_to_evsel(he->hists) != hde->evsel)
> > +   return scnprintf(hpp->buf, hpp->size, "%*.*s", len, len, "N/A");
> 
> hum, how can this happen? ... "hists_to_evsel(he->hists) != hde->evsel"

If there's more than one event, a dynamic sort key is defined for one
event.  So other events should not be affected by the sort key and
show "N/A" in the output.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ibmveth: consolidate kmalloc of array, memset 0 to kcalloc

[Nicholas Mc Guire]

This is an API consolidation only. The use of kmalloc + memset to 0
is equivalent to kcalloc in this case as it is allocating an array
of elements.

Signed-off-by: Nicholas Mc Guire 
---

Found by coccinelle script (relaxed version of
scripts/coccinelle/api/alloc/kzalloc-simple.cocci)

Patch was compile tested with: ppc64_defconfig
(implies CONFIG_IBMVETH=m)

Patch is against linux-next (localversion-next is -next-20150518)

 drivers/net/ethernet/ibm/ibmveth.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmveth.c 
b/drivers/net/ethernet/ibm/ibmveth.c
index 6691b5a..05f5e81 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -169,7 +169,7 @@ static int ibmveth_alloc_buffer_pool(struct 
ibmveth_buff_pool *pool)
if (!pool->free_map)
return -1;
 
-   pool->dma_addr = kmalloc(sizeof(dma_addr_t) * pool->size, GFP_KERNEL);
+   pool->dma_addr = kcalloc(pool->size, sizeof(dma_addr_t), GFP_KERNEL);
if (!pool->dma_addr) {
kfree(pool->free_map);
pool->free_map = NULL;
@@ -187,8 +187,6 @@ static int ibmveth_alloc_buffer_pool(struct 
ibmveth_buff_pool *pool)
return -1;
}
 
-   memset(pool->dma_addr, 0, sizeof(dma_addr_t) * pool->size);
-
for (i = 0; i < pool->size; ++i)
pool->free_map[i] = i;
 
-- 
1.7.10.4

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

Re: Aw: Re: [RFC PATCH urcu on mips, parisc] Fix: compat_futex should work-around futex signal-restart kernel bug

[Mathieu Desnoyers]

- On Dec 19, 2015, at 5:37 AM, Helge Deller del...@gmx.de wrote:

> Hi Mathieu,
> 
> On 18.12.2015 21:42, Helge Deller wrote:
>> On 18.12.2015 20:58, Mathieu Desnoyers wrote:
>> When testing liburcu on a 3.18 Linux kernel, 2-core MIPS (cpu model :
>> Ingenic JZRISC V4.15  FPU V0.0), we notice that a blocked sys_futex
>> FUTEX_WAIT returns -1, errno=ENOSYS when interrupted by a SA_RESTART
>> signal handler. This spurious ENOSYS behavior causes hangs in liburcu
>> 0.9.x. Running a MIPS 3.18 kernel under a QEMU emulator exhibits the
>> same behavior. This might affect earlier kernels.
>>
>> This issue appears to be fixed in 3.18.y stable kernels and 3.19, but
>> nevertheless, we should try to handle this kernel bug more gracefully
>> than a user-space hang due to unexpected spurious ENOSYS return value.
>
> It's actually fixed in 3.19, but not in 3.18.y stable kernels. The
> Linux kernel upstream fix commit is:
> e967ef02 "MIPS: Fix restart of indirect syscalls"
> 
>>> Looks like parisc has an issue very similar to the one that
>>> has been fixed on MIPS by e967ef02 "MIPS: Fix restart of indirect syscalls".
> 
> Yes, parisc is affected the same way.
> I've posted a patch to the parisc mailing list which fixes this issue for
> parisc and which I plan to push into stable kernels:
> http://thread.gmane.org/gmane.linux.ports.parisc/26243
> 
> Regarding your patch for liburcu:
> 
>> Therefore, fallback on the "async-safe" version of compat_futex in those
>> situations where FUTEX_WAIT returns ENOSYS. This async-safe fallback has
>> the nice property of being OK to use concurrently with other FUTEX_WAKE
>> and FUTEX_WAIT futex() calls, because it's simply a busy-wait scheme.
> 
> I've tested your patch. It does not produce any regressions on parisc, but I
> can't
> say for sure if it really works. ENOSYS is returned randomly, so maybe I 
> didn't
> faced a situation where your patch actually was used.

If you ran make check and make regtest, and nothing
fails/hangs, you should be OK. liburcu runs very heavy
stress-tests which makes it likely to hit race conditions
repeatedly.

Thanks!

Mathieu

> 
> Helge

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

Re: [PATCH 06/10] perf tools: Try to show pretty printed output for dynamic sort keys

[Jiri Olsa]

On Wed, Dec 16, 2015 at 12:35:39AM +0900, Namhyung Kim wrote:

SNIP

>   struct trace_seq seq;
> + char *str, *pos;
> + struct format_field *field;
> + struct pevent_record rec = {
> + .cpu  = he->cpu,
> + .data = he->raw_data,
> + .size = he->raw_size,
> + };
> + size_t namelen;
>   int ret;
>  
>   hde = container_of(fmt, struct hpp_dynamic_entry, hpp);
> @@ -1605,9 +1654,28 @@ static int __sort__hde_entry(struct perf_hpp_fmt *fmt, 
> struct perf_hpp *hpp,
>   if (hists_to_evsel(he->hists) != hde->evsel)
>   return scnprintf(hpp->buf, hpp->size, "%*.*s", len, len, "N/A");
>  
> + field = hde->field;
>   trace_seq_init(&seq);
> - print_event_field(&seq, he->raw_data, hde->field);
> - ret = scnprintf(hpp->buf, hpp->size, "%*.*s", len, len, seq.buffer);
> + pevent_event_info(&seq, field->event, &rec);

hm, maybe we could cache the seq.buffer data in hist_entry?

IIRC pevent_event_info code does a lot of stuff, so
it might be better to call it just once.. caching
its results in hist_entry seems like small price

jirka

> +
> + namelen = strlen(field->name);
> + str = strtok_r(seq.buffer, " ", &pos);
> + while (str) {
> + if (!strncmp(str, field->name, namelen)) {
> + str += namelen + 1;
> + break;
> + }
> +
> + str = strtok_r(NULL, " ", &pos);
> + }
> +

SNIP

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

[Andy Shevchenko]

On Sun, Dec 20, 2015 at 3:24 PM, Sudip Mukherjee
 wrote:
> Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
> can be controlled using gpio interface.
> Add support to use these pins and select GPIO_SYSFS also so that these
> pins can be used from the userspace through sysfs.
>
> Tested-by: Rob Groner 
> Signed-off-by: Sudip Mukherjee 

> @@ -0,0 +1,261 @@
> +/*
> + * GPIO driver for Exar XR17V35X chip
> + *
> + * Copyright (C) 2015 Sudip Mukherjee 
> + *
> + * 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.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "8250.h"
> +
> +#define EXAR_OFFSET_MPIOLVL_LO 0x90
> +#define EXAR_OFFSET_MPIOSEL_LO 0x93
> +#define EXAR_OFFSET_MPIOLVL_HI 0x96
> +#define EXAR_OFFSET_MPIOSEL_HI 0x99
> +
> +static LIST_HEAD(exar_list);
> +static DEFINE_MUTEX(exar_mtx); /* lock while manipulating the list */
> +
> +struct exar_gpio_chip {
> +   struct gpio_chip gpio_chip;
> +   struct mutex lock;
> +   struct uart_8250_port *port;
> +   struct list_head list;
> +   int index;
> +   void __iomem *regs;
> +   char name[16];
> +};
> +
> +#define to_exar_chip(n) container_of(n, struct exar_gpio_chip, gpio_chip)
> +
> +static inline unsigned int read_exar_reg(struct exar_gpio_chip *chip,
> +int offset)
> +{
> +   pr_debug("%s regs=%p offset=%x\n", __func__, chip->regs, offset);

dev_dbg()

> +   return readb(chip->regs + offset);
> +}
> +
> +static inline void write_exar_reg(struct exar_gpio_chip *chip, int offset,
> + int value)
> +{
> +   pr_debug("%s regs=%p value=%x offset=%x\n", __func__, chip->regs,
> +value, offset);

Ditto.

> +   writeb(value, chip->regs + offset);
> +}
> +
> +void xr17v35x_gpio_exit(struct uart_8250_port *port)
> +{
> +   struct exar_gpio_chip *exar_gpio, *exar_temp1, *exar_temp2;

I would suggest to use *e, *_e for temporary variables.

> +
> +   if (!port)
> +   return;
> +
> +   exar_gpio = port->port.private_data;
> +   if (!exar_gpio)
> +   return;

Maybe
   if (!port || !port->port.private_data)
  return;

   exar_gpio = port->port.private_data;
   mutex_lock(&exar_mtx);

> +   list_for_each_entry_safe(exar_temp1, exar_temp2, &exar_list, list) {
> +   if (exar_temp1->index == exar_gpio->index) {
> +   list_del(&exar_temp1->list);
> +   break;
> +   }
> +   }
> +   mutex_unlock(&exar_mtx);
> +
> +   gpiochip_remove(&exar_gpio->gpio_chip);
> +   mutex_destroy(&exar_gpio->lock);
> +   iounmap(exar_gpio->regs);
> +}
> +EXPORT_SYMBOL(xr17v35x_gpio_exit);
> +
> +static void exar_set(struct gpio_chip *chip, unsigned int reg, int val,
> +unsigned int offset)

Perhaps …, unsigned int offset, int val)

> +{
> +   struct exar_gpio_chip *exar_gpio = to_exar_chip(chip);
> +   int temp;
> +
> +   mutex_lock(&exar_gpio->lock);
> +   temp = read_exar_reg(exar_gpio, reg);
> +   temp &= ~(1 << offset);
> +   temp |= val << offset;
> +   write_exar_reg(exar_gpio, reg, temp);
> +   mutex_unlock(&exar_gpio->lock);
> +}
> +
> +static int exar_direction_output(struct gpio_chip *chip, unsigned int offset,
> +int value)
> +{
> +   if (offset < 8)
> +   exar_set(chip, EXAR_OFFSET_MPIOSEL_LO, 0, offset);
> +   else
> +   exar_set(chip, EXAR_OFFSET_MPIOSEL_HI, 0, offset - 8);
> +   return 0;
> +}
> +
> +static int exar_direction_input(struct gpio_chip *chip, unsigned int offset)
> +{
> +   if (offset < 8)
> +   exar_set(chip, EXAR_OFFSET_MPIOSEL_LO, 1, offset);
> +   else
> +   exar_set(chip, EXAR_OFFSET_MPIOSEL_HI, 1, offset - 8);
> +   return 0;
> +}
> +
> +static int exar_get(struct gpio_chip *chip, unsigned int reg)
> +{
> +   int value;
> +   struct exar_gpio_chip *exar_gpio = to_exar_chip(chip);

Perhaps exchange positions of the lines to be assignment first,
uninitialized — second.

> +
> +   if (!exar_gpio) {
> +   pr_err("%s exar_gpio is NULL\n", __func__);

I doubt it's useful message.

> +   return -ENOMEM;
> +   }
> +
> +   mutex_lock(&exar_gpio->lock);
> +   value = read_exar_reg(exar_gpio, reg);
> +   mutex_unlock(&exar_gpio->lock);
> +
> +   return value;
> +}
> +
> +static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
> +{
> +   int val;

int value; like you have elsewhere.

> +
> +   if (offset < 8) {
> +   val = exar_get(chip, EXAR_OFFSET_MPIOSEL_LO);
> +   } else {
> +  

Re: [PATCH v5] extcon: add Maxim MAX3355 driver

[Chanwoo Choi]

Hi,

This patch depend on GPIOLIB configuration as following:
I modified it with following diff and applied it.

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index ba4db7d..3d89e60 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -54,6 +54,7 @@ config EXTCON_MAX14577

 config EXTCON_MAX3355
tristate "Maxim MAX3355 USB OTG EXTCON Support"
+   depends on GPIOLIB || COMPILE_TEST
help
  If you say yes here you get support for the USB OTG role detection by
  MAX3355. The MAX3355 chip integrates a charge pump and comparators to

Thanks,
Chanwoo Choi


On Sat, Dec 19, 2015 at 8:17 AM, Sergei Shtylyov
 wrote:
> Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
> enable a system with an integrated USB OTG dual-role transceiver to
> function as an USB OTG dual-role device. In addition to sensing/controlling
> Vbus, the chip also passes thru the ID signal from the USB OTG connector.
> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
> pin -- there's no real OTG controller, only host and gadget USB controllers
> sharing the same USB bus; however, we'd like to allow host or gadget
> drivers to be loaded depending on the cable type, hence the need for the
> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
> (however, we aren't currently interested in them), the OFFVBUS# signal is
> controlled by the host controllers, there's also the SHDN# signal wired to
> a GPIO, it should be driven high for the normal operation.
>
> Signed-off-by: Sergei Shtylyov 
> Acked-by: Chanwoo Choi 
>
> ---
> Changes in version 5:
> - removed unused variable in the probe() method;
> - removed reference to the Koelsch board from the binding document;
> - added Chanwoo Choi's ACK.
>
> Changes in version 4:
> - stopped calling kstrdup() for the device name;
> - removed unneeded 'owner' field initializer;
> - moved devm_extcon_allocate() call further down in the probe() method;
> - extended the driver copyright;
> - indented the continuation lines in the binding document.
>
> Changes in version 3:
> - reformatted the change log.
>
> Changes in version 2:
> - added the USB gadget cable support;
> - added the remove() driver method which drives SHDN# GPIO low to save power;
> - dropped vendor prefix from the ID GPIO property name;
> - changed the GPIO property name suffix to "-gpios";
> - switched to usign extcon_set_cable_state_() API;
> - switched to using the gpiod/sleeping 'gpiolib' APIs;
> - addded error messages to max3355_probe();
> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
> - renamed 'ret' variable to 'err' in max3355_probe();
> - expanded the Kconfig entry help text;
> - added vendor name to the patch summary, the bindings document, the Kconfig
>   entry, the driver heading comment, the module description, and the change 
> log;
> - fixed up and reformatted the change log.
>
>  Documentation/devicetree/bindings/extcon/extcon-max3355.txt |   21 +
>  drivers/extcon/Kconfig  |8
>  drivers/extcon/Makefile |1
>  drivers/extcon/extcon-max3355.c |  150 
> 
>  4 files changed, 180 insertions(+)
>
> Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +Maxim Integrated MAX3355 USB OTG chip
> +-
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO 
> pin
> +   connected to the MAX3355's SHDN# pin;
> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
> +   connected to the MAX3355's ID_OUT pin.
> +
> +Example:
> +
> +   usb-otg {
> +   compatible = "maxim,max3355";
> +   maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
> +   id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
> +   };
> Index: extcon/drivers/extcon/Kconfig
> ===
> --- extcon.orig/drivers/extcon/Kconfig
> +++ extcon/drivers/extcon/Kconfig
> @@ -52,6 +52,14 @@ config EXTCON_MAX14577
>   Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port 
> accessory
>   detector and switch.
>
> +config EXTCON_MAX3355
> +   tristate "Maxim MAX3355 USB OTG EXTCON Support"
> +   help
> + If you say yes here you get support for the USB OTG role detection 
> by
> + MAX3355. The MAX3355 chip integrates a charge pump and comparators 
> t

Re: [PATCH v1 0/6] Support the rk3036 Kylin board

[Heiko Stübner]

Hi Caesar,

Am Sonntag, 20. Dezember 2015, 20:49:14 schrieb Caesar Wang:
> Hi Heiko,
> 
> 在 2015年12月20日 01:16, Heiko Stübner 写道:
> > Hi Caesar,
> > 
> > Am Donnerstag, 17. Dezember 2015, 22:21:46 schrieb Caesar Wang:
> >> Kylin-board is based on RK3036 SOCs, add the initiation
> >> version for working.
> > 
> > I've applied:
> > - patch1 (please include the "rockchip:" part in dts subjects)
> > - patch3 (dito)
> > - patch4 (after merging in patch6 and dropping the hdmi+lcdc parts)
> 
> Okay, thanks!
> 
> Sync to the rockchip github
> .
> 
> > Please resubmit the missing parts (audio + graphics) against my dts-branch
> > [0] after the relevant maintainers have added the code-parts to their
> > trees.
> For codec:
> RT5616 is existing  in
> https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=for-ne
> xt now.

that seems to be missing the devicetree-parts. I think you can just send a 
patch to Mark adding
- of_device_id match table
- of_match_table assignment
- binding-documentation (it seems to have only compatible and reg propeties)


Heiko

> For 3036 vop:
> I would like wait a moment from Mark Yao updating the driver.
> 
> > Thanks
> > Heiko
> > 
> > [0]
> > https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log
> > /?h=v4.5-armsoc/dts32> 
> >> This series patches have the following decriptions:
> >> 
> >> PATCH[1/6]:
> >> ARM: dts: fix the correct pinctrl control for rk3036
> >> 
> >> The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs
> >> can't set the status in the internal.
> >> ---
> >> 
> >> PATCH[2/6]:
> >> ARM: dts: add the lcdc and hdmi node for rk3036
> >> 
> >> Add the devices is related to display.
> >> Based on the series patches of Mark Yao's
> >> ---
> >> 
> >> PATCH[3/6]:
> >> ARM: dts: add the sdio/sdmmc node for rk3036
> >> 
> >> Add the wifi/sd card work for kylin board.
> >> ---
> >> 
> >> PATCH[4/6]:
> >> ARM: dts: rockchip: add the kylin board for rk3036
> >> 
> >> Add the dts for kylin board.
> >> ---
> >> 
> >> PATCH[5/6]:
> >> ARM: dts: add the sound codec for kylin board
> >> 
> >> Make the codec rt5616 working on kylin board.
> >> The realteak have been upstream for Mark Brown,
> >> I guess need some days to review.
> >> 
> >> ---
> >> 
> >> PATCH[6/6]:
> >> ARM: dts: add the sdio node for kylin board
> >> 
> >> Enable the sdio for kylin board.
> >> ---
> >> 
> >> Caesar Wang (6):
> >>ARM: dts: fix the correct pinctrl control for rk3036
> >>ARM: dts: add the lcdc and hdmi node for rk3036
> >>ARM: dts: add the sdio/sdmmc node for rk3036
> >>ARM: dts: rockchip: add the kylin board for rk3036
> >>ARM: dts: add the sound codec for kylin board
> >>ARM: dts: add the sdio node for kylin board
> >>   
> >>   Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
> >>   arch/arm/boot/dts/Makefile |   1 +
> >>   arch/arm/boot/dts/rk3036-kylin.dts | 345
> >> 
> >> + arch/arm/boot/dts/rk3036.dtsi 
> >> |
> >> 167 -- 4 files changed, 498 insertions(+), 19 deletions(-)
> >> 
> >>   create mode 100644 arch/arm/boot/dts/rk3036-kylin.dts
> > 
> > ___
> > Linux-rockchip mailing list
> > linux-rockc...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

[Sudip Mukherjee]

On Sun, Dec 20, 2015 at 04:18:17PM +0200, Andy Shevchenko wrote:
> On Sun, Dec 20, 2015 at 3:24 PM, Sudip Mukherjee
>  wrote:
> > Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
> > can be controlled using gpio interface.
> > Add support to use these pins and select GPIO_SYSFS also so that these
> > pins can be used from the userspace through sysfs.
> >
> > Tested-by: Rob Groner 
> > Signed-off-by: Sudip Mukherjee 
> 
Hi Andy,
Thanks for the review. Just a few doubts below.

> > @@ -0,0 +1,261 @@
> > +/*
> > + * GPIO driver for Exar XR17V35X chip
> > + *
> > + * Copyright (C) 2015 Sudip Mukherjee 
> > + *
> > + * 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.
> > + */

> > +
> > +err_destroy:
> > +   mutex_unlock(&exar_mtx);
> > +   mutex_destroy(&exar_gpio->lock);
> > +err_unmap:
> > +   iounmap(p);
> 
> pci_iounmap?

I thought about pci_iounmap but I saw that most of the code in
8250_pci.c is using iounmap, so i went in favor of the majority.
Will change it.

> 
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL(xr17v35x_gpio_init);
> > +
> 
> > +static void __exit exar_gpio_exit(void)
> > +{
> > +}
> > +
> > +module_exit(exar_gpio_exit);
> > +
> > +static int __init exar_gpio_init(void)
> > +{
> > +   return 0;
> > +}
> > +
> > +module_init(exar_gpio_init);
> > +
> 
> Useless for now. You are using it as a library.

Main doubt here. If I do not give the module_init() and module_exit()
then what entry do i keep in the Kconfig? In this v3, it is kept as
tristate. Should that be bool then? 

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

Re: [PATCH 1/1] Fix 'sleeping function called from invalid context' warning in sysrq generated crash.

[Anirban Sinha]

On Fri, 18 Dec 2015, Paul E. McKenney wrote:

> On Thu, Dec 17, 2015 at 05:15:10PM -0800, Ani Sinha wrote:
> > Commit 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq")
> > replaced spin_lock_irqsave() calls with
> > rcu_read_lock() calls in sysrq. Since rcu_read_lock() does not
> > disable preemption, faulthandler_disabled() in
> > __do_page_fault() in x86/fault.c returns false. When the code
> > later calls might_sleep() in the pagefault handler, we get the
> > following warning:
> > 
> > BUG: sleeping function called from invalid context at 
> > ../arch/x86/mm/fault.c:1187
> > in_atomic(): 0, irqs_disabled(): 0, pid: 4706, name: bash
> > Preemption disabled at:[] printk+0x48/0x4a
> > 
> > To fix this, we release the RCU read lock before we crash.
> > 
> > Tested this patch on linux 3.18 by booting off one of our boards.
> > 
> > Fixes: 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq")
> > 
> > Signed-off-by: Ani Sinha 
> 
> I queued this with Rik's Signed-off-by, and fixed some checkpatch.pl
> errors.  Please run scripts/checkpatch.pl on your patches in the future.
> 
> Please see below for the result.
> 
> Rik, did you test this as well?  If so, may I also have your Tested-by?
> 

I applied this patch on linux 4.4-rc5 and booted off a fedora core 22 
vmware VM with it (sorry I don't have a real box around). Seems to be 
working fine. Also booted off a fc14 vm box with it and it also seems 
fine. Here's the kernel crash dump from fc22 box :

Fedora release 22 (Twenty Two)
Kernel 4.4.0-rc5-2847908.AroraKernelbleeding.5.fc18.x86_64 on an x86_64 (ttyS1)

localhost login: [   50.070804] [drm:vmw_cmdbuf_work_func [vmwgfx]] *ERROR* 
Command buffer error.
[   81.823507] sysrq: SysRq : Trigger a crash
[   81.825099] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[   81.827357] IP: [] sysrq_handle_crash+0x11/0x1b
[   81.828986] PGD 0 
[   81.829542] Oops: 0002 [#1] SMP 
[   81.830426] Modules linked in: rfcomm xt_CHECKSUM ipt_MASQUERADE 
nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast 
xt_tcpudp ip6t_REJECT fuse ipt_REJECT xt_conntrack ebtable_nat ebtable_broute 
bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 
nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw 
ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw 
iptable_filter snd_seq_midi snd_seq_midi_event bnep coretemp hwmon crc32c_intel 
ppdev aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd 
snd_ens1371 snd_ac97_codec ac97_bus snd_seq pcspkr snd_pcm serio_raw snd_timer 
snd_rawmidi snd_seq_device snd soundcore gameport i2c_piix4 shpchp battery 
parport_pc parport btusb btrtl btbcm btintel ac bluetooth acpi_cpufreq tpm_tis 
tpm nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc ip_tables x_tables 
uhci_hcd vmwgfx e1000 ehci_pci ehci_hcd mptspi scsi_transport_spi mptscsih 
mptbase drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm 
i2c_core sr_mod cdrom dm_mirror dm_region_hash dm_log dm_mod autofs4
[   81.854446] CPU: 0 PID: 2296 Comm: bash Not tainted 
4.4.0-rc5-2847908.AroraKernelbleeding.5.fc18.x86_64 #1
[   81.856338] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 05/20/2014
[   81.858431] task: 88001c7d9a00 ti: 880004d7 task.ti: 
880004d7
[   81.859903] RIP: 0010:[]  [] 
sysrq_handle_crash+0x11/0x1b
[   81.861609] RSP: 0018:880004d73d98  EFLAGS: 00010296
[   81.862672] RAX: 000f RBX: 81a774a0 RCX: 
[   81.864078] RDX: 88003f60f101 RSI: 88003f60cae8 RDI: 0063
[   81.865482] RBP: 880004d73d98 R08: 000f R09: 
[   81.866889] R10:  R11: 000f R12: 0004
[   81.868294] R13: 0063 R14: 880004d73f00 R15: 
[   81.869702] FS:  7fd8e0c69700() GS:88003f60() 
knlGS:
[   81.871293] CS:  0010 DS:  ES:  CR0: 80050033
[   81.872437] CR2:  CR3: 1199f000 CR4: 001406f0
[   81.873877] Stack:
[   81.874297]  880004d73dc8 8131c835 0002 
880004cb5200
[   81.875876]  7fd8e0c77000 880004d73f20 880004d73de8 
8131c8e7
[   81.877455]  fff2 88003abff500 880004d73e28 
81181949
[   81.879032] Call Trace:
[   81.879537]  [] __handle_sysrq+0x8f/0x11c
[   81.880645]  [] write_sysrq_trigger+0x25/0x36
[   81.881829]  [] proc_reg_write+0x54/0x76
[   81.883007]  [] __vfs_write+0x23/0xa2
[   81.884050]  [] ? security_file_permission+0x37/0x40
[   81.885344]  [] ? rw_verify_area+0x6b/0xcb
[   81.886469]  [] ? __sb_start_write+0x22/0x42
[   81.887628]  [] vfs_write+0x86/0xdc
[   81.888634]  [] SyS_write+0x4d/0x7f
[   81.889643]  [] entry_SYSCALL_64_fastpath+0x12/0x71
[   81.89

Re: [PATCH 08/10] perf tools: Add --raw-trace option

[Jiri Olsa]

On Wed, Dec 16, 2015 at 12:35:41AM +0900, Namhyung Kim wrote:
> The --raw-trace option is to prevent pretty printing by event's
> print_fmt or plugin.  Besides that, each dynamic sort key now receives
> 'raw' suffix separated by '/' to apply the raw trace to a specific
> field.
> 
>   $ perf report -s comm,kmem:kmalloc.gfp_flags
>   ...
>   # Overhead  Commandgfp_flags
>   #   ...  ...
>   #
>   99.89%  perf   GFP_NOFS|GFP_ZERO
>0.06%  sleep GFP_KERNEL
>0.03%  perf GFP_KERNEL|GFP_ZERO
>0.01%  perf  GFP_KERNEL
> 
> Now
> 
>   $ perf report -s comm,kmem:kmalloc.gfp_flags --raw-trace
> or
>   $ perf report -s comm,kmem:kmalloc.gfp_flags/raw
>   ...
>   # Overhead  Command   gfp_flags
>   #   ...  ..
>   #
>   99.89%  perf  32848
>0.06%  sleep   208
>0.03%  perf  32976
>0.01%  perf208
> 
> Suggested-by: Jiri Olsa 
> Cc: Steven Rostedt 
> Signed-off-by: Namhyung Kim 

I think the default is good with the 'trace' sort key as it is now:

$ ./perf report -s trace 
  27.01%  offlineimap:17701 [120] S ==> swapper/1:0 [120]
  27.00%  swapper/1:0 [120] R ==> offlineimap:17701 [120]


But for '--raw-trace' option rather than displaying fields in the '=' notation:

$ ./perf report -s trace --raw-trace
  27.01%   prev_comm=offlineimap prev_pid=17701 prev_prio=120 
prev_state=1 next_comm=swapper/1 next_pid=0 next_prio=120
  27.00%   prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=0 
next_comm=offlineimap next_pid=17701 next_prio=120


it would be more readable to register all available columns as is possible to 
do now with:

$ ./perf report -s 
prev_comm,prev_pid,prev_prio,prev_state,next_comm,next_pid,next_prio
Overhead prev_commprev_pid   prev_prio  prev_state  
   next_commnext_pid   next_prio
  27.01%   offlineimap   17701 120   1  
   swapper/1   0 120
  27.00% swapper/1   0 120   0  
 offlineimap   17701 120


it would be default output for 'perf report -s trace --raw-trace' command

how about that?

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: 8250: add gpio support to exar

[Andy Shevchenko]

On Sun, Dec 20, 2015 at 4:47 PM, Sudip Mukherjee
 wrote:
> On Sun, Dec 20, 2015 at 04:18:17PM +0200, Andy Shevchenko wrote:
>> On Sun, Dec 20, 2015 at 3:24 PM, Sudip Mukherjee
>>  wrote:
>> > Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
>> > can be controlled using gpio interface.
>> > Add support to use these pins and select GPIO_SYSFS also so that these
>> > pins can be used from the userspace through sysfs.


>> > +err_destroy:
>> > +   mutex_unlock(&exar_mtx);
>> > +   mutex_destroy(&exar_gpio->lock);
>> > +err_unmap:
>> > +   iounmap(p);
>>
>> pci_iounmap?
>
> I thought about pci_iounmap but I saw that most of the code in
> 8250_pci.c is using iounmap, so i went in favor of the majority.
> Will change it.

Okay, let maintainers speak about it,

>> > +static void __exit exar_gpio_exit(void)
>> > +{
>> > +}
>> > +
>> > +module_exit(exar_gpio_exit);
>> > +
>> > +static int __init exar_gpio_init(void)
>> > +{
>> > +   return 0;
>> > +}
>> > +
>> > +module_init(exar_gpio_init);
>> > +
>>
>> Useless for now. You are using it as a library.
>
> Main doubt here. If I do not give the module_init() and module_exit()
> then what entry do i keep in the Kconfig?

I don't see any problem. It's already somehow classical approach in
the drivers when core part is represented as a library (one example
comes immediately to my mind is drivers/dma/dw/core.c, I think you may
find much more in the kernel sources).

> In this v3, it is kept as
> tristate. Should that be bool then?

No, why?


-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: "special" key when Lenovo Yoga 900 in tablet mode

[Andy Shevchenko]

On Tue, Dec 15, 2015 at 9:27 PM, Nish Aravamudan
 wrote:
> So the Lenovo Yoga 900 has 4 "modes" (laptop, tent, stand and tablet).
> In tablet mode, it appears that the following is printed roughly every
> second:
>
> atkbd serio0: Unknown key pressed (translated set 2, code 0xbf on
> isa0060/serio0).
> atkbd serio0: Use 'setkeycodes e03f ' to make it known.
> ideapad_laptop: Unknown event: 1
> atkbd serio0: Unknown key released (translated set 2, code 0xbf on
> isa0060/serio0).
> atkbd serio0: Use 'setkeycodes e03f ' to make it known.
> ideapad_laptop: Unknown event: 1
>
> What I would like to do is rotate the screen when I see the unknown
> key (a la https://gist.github.com/emiller/6488449), although that's not
> super-efficient, but is fine. But I'm wondering if the ideapad event
> should actually be properly handled and how that would be done? I
> guess it could also just emit a key like the other ideapad values?

I might be able to reproduce this next week. Maybe we will come up
with the solution.

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

Re: [PATCH 1/2] x86/msr: add on cpu read/modify/write function

[Borislav Petkov]

On Sun, Dec 20, 2015 at 02:28:48PM +0100, Thomas Gleixner wrote:
> So this is a copy of the above !SMP inline. What's wrong with providing:
> 
>  int rmwmsrl_safe(msr_no, clear_mask, set_mask)
> 
> in x86/lib/msr.c and make the !SMP variant of rdmsrl_safe_on_cpu() and that
> variant for the SMP case a simple wrapper around it?
> 
> static void remote_rmwmsrl_safe(void *info)
> {
>   struct msr_action *ma = info;
> 
>   return rmwmsrl_safe(ma->msr, ma->clear_mask, ma->set_mask);
> }
> 
> No gotos, no pointless code duplication. Just simple.

TBH, I find this new "rmwmsrl" interface (the name is unreadable, btw)
silly:

It provides a plain read-modify-write on a MSR and nothing more but
patch 2 immediately shows that this interface is insufficient for the
other cases, i.e. package_power_limit_irq_save() for example, where you
need to do something more like check bits or error handling.

So there we do smp_call_function_single() with a function which does the
MSR accesses and whatever else is needed.

So why add the former interface in the first place?

Having driver-specific functions do whatever it is required and then
using a single IPI to run them is much cleaner than adding that
unfortunate function which doesn't really suffice.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/24] coresight: associating path with session rather than tracer

[Rabin Vincent]

On Fri, Dec 18, 2015 at 01:58:58PM -0700, Mathieu Poirier wrote:
> When using the Coresight framework from the sysFS interface a
> tracer is always handling a single session and as such, a path
> can be associated with a tracer.  But when supporting multiple
> session per tracer there is no guarantee that sessions will always
> have the same path from source to sink.
> 
> This patch is removing the automatic association between path and
> tracers.  The building of a path and enablement of the components
> in the path are decoupled, allowing for the association of a path
> with a session rather than a tracer.

This patch introduces a use-after-free/double kfree() if the sink is
disabled after the source.

With this command sequence:

# echo 1 > /sys/bus/coresight/devices/54162000.etb/enable_sink 
# echo 1 > /sys/bus/coresight/devices/5414c000.ptm/enable_source 
...
# echo 0 > /sys/bus/coresight/devices/54162000.etb/enable_sink 
# echo 0 > /sys/bus/coresight/devices/5414c000.ptm/enable_source 

Before these patches, we get these messages while disabling:

[  165.822326] coresight-etm3x 5414c000.ptm: ETM tracing disabled
[  165.828491] coresight 5414c000.ptm: releasing path(s) failed

After these patches, we get this (with SLUB debugging enabled):

=
BUG kmalloc-512 (Not tainted): Invalid object pointer 0xed60e164
-

Disabling lock debugging due to kernel taint
INFO: Slab 0xeebac180 objects=23 used=23 fp=0x  (null) flags=0x4081
CPU: 0 PID: 856 Comm: sh Tainted: GB   
4.4.0-rc5-00224-ge461459-dirty #168
Hardware name: Generic OMAP4 (Flattened Device Tree)
Backtrace: 
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
 r7:0001 r6:eebac180 r5:c07ae71c r4:
[] (show_stack) from [] (dump_stack+0x98/0xc0)
[] (dump_stack) from [] (slab_err+0x78/0x80)
 r5:ee0013c0 r4:eebac180
[] (slab_err) from [] (free_debug_processing+0x234/0x34c)
 r3:ed60e164 r2:c068d484
 r5:ee0013c0 r4:ed60e164
[] (free_debug_processing) from [] (__slab_free+0x29c/0x428)
 r10:ee0013c0 r9: r8:2013 r7:c041a5f4 r6:ed60e164 r5:00010d00
 r4:eebac180
[] (__slab_free) from [] (kfree+0x2dc/0x2f4)
 r10:eda29f80 r9: r8:2013 r7:c041a5f4 r6:ed60e164 r5:eebac180
 r4:ee0013c0
[] (kfree) from [] (etm_disable+0xf8/0x148)
 r10:eda29f80 r9: r8:ed7ba500 r7: r6:ed60e120 r5:0001
 r4:ed60e110
[] (etm_disable) from [] (coresight_disable+0xbc/0x100)
 r7: r6:c0771150 r5:c076c900 r4:ed662600
[] (coresight_disable) from [] 
(enable_source_store+0x48/0x68)
 r9:ed67ec8c r8:ed7d7900 r7: r6:ed7d7900 r5:0002 r4:ed662620
[] (enable_source_store) from [] (dev_attr_store+0x20/0x2c)
 r5:ed67ec80 r4:c0415ea8
[] (dev_attr_store) from [] (sysfs_kf_write+0x50/0x54)
 r5:ed67ec80 r4:c030b35c
[] (sysfs_kf_write) from [] (kernfs_fop_write+0xc4/0x1c0)
 r7: r6: r5:0002 r4:ed67ec80
[] (kernfs_fop_write) from [] (__vfs_write+0x34/0xe4)
 r10: r9:eda28000 r8:c0010964 r7:eda29f80 r6:0002 r5:c01d4ad4
 r4:ed811180
[] (__vfs_write) from [] (vfs_write+0x98/0x174)
 r9:eda28000 r8:c0010964 r7:eda29f80 r6:000a9e40 r5:0002 r4:ed811180
[] (vfs_write) from [] (SyS_write+0x4c/0xa8)
 r8:c0010964 r7:0002 r6:000a9e40 r5:ed811180 r4:ed811180
[] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c)
 r7:0004 r6:0001 r5:000a9e40 r4:0002
FIX kmalloc-512: Object at 0xed60e164 not freed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Aw: Re: [RFC PATCH urcu on mips, parisc] Fix: compat_futex should work-around futex signal-restart kernel bug

[Helge Deller]

On 20.12.2015 15:11, Mathieu Desnoyers wrote:
> - On Dec 19, 2015, at 5:37 AM, Helge Deller del...@gmx.de wrote:
> 
>> Hi Mathieu,
>>
>> On 18.12.2015 21:42, Helge Deller wrote:
>>> On 18.12.2015 20:58, Mathieu Desnoyers wrote:
>>> When testing liburcu on a 3.18 Linux kernel, 2-core MIPS (cpu model :
>>> Ingenic JZRISC V4.15  FPU V0.0), we notice that a blocked sys_futex
>>> FUTEX_WAIT returns -1, errno=ENOSYS when interrupted by a SA_RESTART
>>> signal handler. This spurious ENOSYS behavior causes hangs in liburcu
>>> 0.9.x. Running a MIPS 3.18 kernel under a QEMU emulator exhibits the
>>> same behavior. This might affect earlier kernels.
>>>
>>> This issue appears to be fixed in 3.18.y stable kernels and 3.19, but
>>> nevertheless, we should try to handle this kernel bug more gracefully
>>> than a user-space hang due to unexpected spurious ENOSYS return value.
>>
>> It's actually fixed in 3.19, but not in 3.18.y stable kernels. The
>> Linux kernel upstream fix commit is:
>> e967ef02 "MIPS: Fix restart of indirect syscalls"
>>
 Looks like parisc has an issue very similar to the one that
 has been fixed on MIPS by e967ef02 "MIPS: Fix restart of indirect 
 syscalls".
>>
>> Yes, parisc is affected the same way.
>> I've posted a patch to the parisc mailing list which fixes this issue for
>> parisc and which I plan to push into stable kernels:
>> http://thread.gmane.org/gmane.linux.ports.parisc/26243
>>
>> Regarding your patch for liburcu:
>>
>>> Therefore, fallback on the "async-safe" version of compat_futex in those
>>> situations where FUTEX_WAIT returns ENOSYS. This async-safe fallback has
>>> the nice property of being OK to use concurrently with other FUTEX_WAKE
>>> and FUTEX_WAIT futex() calls, because it's simply a busy-wait scheme.
>>
>> I've tested your patch. It does not produce any regressions on parisc, but I
>> can't
>> say for sure if it really works. ENOSYS is returned randomly, so maybe I 
>> didn't
>> faced a situation where your patch actually was used.
> 
> If you ran make check and make regtest, and nothing
> fails/hangs, you should be OK.

Yes, I did run both.

> liburcu runs very heavy
> stress-tests which makes it likely to hit race conditions
> repeatedly.

Helge

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 1/3] i2c: rk3x: add calc_divs ops for new version

[Andy Shevchenko]

On Tue, Dec 15, 2015 at 2:32 AM, Jianqun Xu  wrote:
> Hi David:
>
> It's better to add a cover-letter, and add changes note for new version,
> such as:
>
> changes since v0:
> - split patch to two patches or more, one patch for one new feature (Heiko)
>
> and NOT to have two same signed-off-by

Besides that…

>>   #define REG_CON_LASTACK   BIT(5) /* 1: send NACK after last received
>> byte */
>>   #define REG_CON_ACTACKBIT(6) /* 1: stop if NACK is received */
>>
>> +#define VERSION_MASK 0x

GENMASK()

>> +#define VERSION_SHIFT16
>> +
>> +#define RK3X_I2C_V0  0x0
>> +#define RK3X_I2C_V1  0x1
>> +
>>   /* REG_MRXADDR bits */
>>   #define REG_MRXADDR_VALID(x) BIT(24 + (x)) /* [x*8+7:x*8] of MRX[R]ADDR
>> valid */
>>
>> @@ -90,10 +96,22 @@ struct rk3x_i2c_soc_data {
>> int grf_offset;
>>   };
>>
>> +struct rk3x_i2c_ops {
>> +   int (*calc_divs)(unsigned long,
>> +unsigned long,
>> +unsigned long,
>> +unsigned long,
>> +unsigned long,
>> +unsigned long *,
>> +unsigned long *,
>> +unsigned int *);

Too many arguments, what about struct for them (perhaps two groups)?

>> +};
>> +
>>   struct rk3x_i2c {
>> struct i2c_adapter adap;
>> struct device *dev;
>> struct rk3x_i2c_soc_data *soc_data;
>> +   struct rk3x_i2c_ops ops;
>>
>> /* Hardware resources */
>> void __iomem *regs;
>> @@ -116,6 +134,7 @@ struct rk3x_i2c {
>> u8 addr;
>> unsigned int mode;
>> bool is_last_msg;
>> +   unsigned int time_con;
>>
>> /* I2C state machine */
>> enum rk3x_i2c_state state;
>> @@ -151,7 +170,8 @@ static void rk3x_i2c_start(struct rk3x_i2c *i2c)
>> i2c_writel(i2c, REG_INT_START, REG_IEN);
>>
>> /* enable adapter with correct mode, send START condition */
>> -   val = REG_CON_EN | REG_CON_MOD(i2c->mode) | REG_CON_START;
>> +   val = i2c->time_con | REG_CON_EN | REG_CON_MOD(i2c->mode)
>> +   | REG_CON_START;
>>
>> /* if we want to react to NACK, set ACTACK bit */
>> if (!(i2c->msg->flags & I2C_M_IGNORE_NAK))
>> @@ -443,16 +463,19 @@ out:
>>* @sda_fall_ns: How many ns it takes for SDA to fall.
>>* @div_low: Divider output for low
>>* @div_high: Divider output for high
>> + * @con: version0 is not used
>>*
>>* Returns: 0 on success, -EINVAL if the goal SCL rate is too slow. In
>> that case
>>* a best-effort divider value is returned in divs. If the target rate
>> is
>>* too high, we silently use the highest possible rate.
>>*/
>> -static int rk3x_i2c_calc_divs(unsigned long clk_rate, unsigned long
>> scl_rate,
>> - unsigned long scl_rise_ns,
>> - unsigned long scl_fall_ns,
>> - unsigned long sda_fall_ns,
>> - unsigned long *div_low, unsigned long
>> *div_high)
>> +static int rk3x_i2c_v0_calc_divs(unsigned long clk_rate, unsigned long
>> scl_rate,
>> +unsigned long scl_rise_ns,
>> +unsigned long scl_fall_ns,
>> +unsigned long sda_fall_ns,

Wolfram did some sturct to assign the parameters from device properties.
It might be re-used here.

>> +unsigned long *div_low,
>> +unsigned long *div_high,
>> +unsigned int *con)
>>   {
>> unsigned long spec_min_low_ns, spec_min_high_ns;
>> unsigned long spec_setup_start, spec_max_data_hold_ns;
>> @@ -616,17 +639,19 @@ static int rk3x_i2c_calc_divs(unsigned long
>> clk_rate, unsigned long scl_rate,
>>
>>   static void rk3x_i2c_adapt_div(struct rk3x_i2c *i2c, unsigned long
>> clk_rate)
>>   {
>> +   unsigned int con = 0;
>> unsigned long div_low, div_high;
>> u64 t_low_ns, t_high_ns;
>> int ret;
>>
>> -   ret = rk3x_i2c_calc_divs(clk_rate, i2c->scl_frequency,
>> i2c->scl_rise_ns,
>> +   ret = i2c->ops.calc_divs(clk_rate, i2c->scl_frequency,
>> i2c->scl_rise_ns,
>>  i2c->scl_fall_ns, i2c->sda_fall_ns,
>> -&div_low, &div_high);
>> +&div_low, &div_high, &con);
>> WARN_ONCE(ret != 0, "Could not reach SCL freq %u",
>> i2c->scl_frequency);
>>
>> clk_enable(i2c->clk);
>> i2c_writel(i2c, (div_high << 16) | (div_low & 0x),
>> REG_CLKDIV);
>> +   i2c->time_con = con;
>> clk_disable(i2c->clk);
>>
>> t_low_ns = div_u64(((u64)div_low + 1) * 8 * 10, clk_rate);
>> @@ -661,13 +686,14 @@ static int rk3x_i2c_clk_notifier_cb(struct
>> notifier_block *nb, unsigned long
>> struct clk_notifier_data *ndata = data;
>> struct rk3x_i2c *i2

Re: [PATCH v15 20/25] x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()

[Rafael J. Wysocki]

On Friday, December 18, 2015 06:39:34 AM Josh Poimboeuf wrote:
> do_suspend_lowlevel() is a callable non-leaf function which doesn't
> honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
> 
> Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
> 
> Signed-off-by: Josh Poimboeuf 
> Acked-by: Pavel Machek 
> Cc: Rafael J. Wysocki 
> Cc: Len Brown 

Acked-by: Rafael J. Wysocki 

> ---
>  arch/x86/kernel/acpi/wakeup_64.S | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/kernel/acpi/wakeup_64.S 
> b/arch/x86/kernel/acpi/wakeup_64.S
> index 8c35df4..169963f 100644
> --- a/arch/x86/kernel/acpi/wakeup_64.S
> +++ b/arch/x86/kernel/acpi/wakeup_64.S
> @@ -5,6 +5,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  # Copyright 2003 Pavel Machek , distribute under GPLv2
>  
> @@ -39,6 +40,7 @@ bogus_64_magic:
>   jmp bogus_64_magic
>  
>  ENTRY(do_suspend_lowlevel)
> + FRAME_BEGIN
>   subq$8, %rsp
>   xorl%eax, %eax
>   callsave_processor_state
> @@ -109,6 +111,7 @@ ENTRY(do_suspend_lowlevel)
>  
>   xorl%eax, %eax
>   addq$8, %rsp
> + FRAME_END
>   jmp restore_processor_state
>  ENDPROC(do_suspend_lowlevel)
>  
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v15 23/25] x86/asm/power: Create stack frames in hibernate_asm_64.S

[Rafael J. Wysocki]

On Friday, December 18, 2015 06:39:37 AM Josh Poimboeuf wrote:
> swsusp_arch_suspend() and restore_registers() are callable non-leaf
> functions which don't honor CONFIG_FRAME_POINTER, which can result in
> bad stack traces.  Also they aren't annotated as ELF callable functions
> which can confuse tooling.
> 
> Create a stack frame for them when CONFIG_FRAME_POINTER is enabled and
> give them proper ELF function annotations.
> 
> Signed-off-by: Josh Poimboeuf 
> Acked-by: Pavel Machek 
> Cc: Rafael J. Wysocki 

Acked-by: Rafael J. Wysocki 

> ---
>  arch/x86/power/hibernate_asm_64.S | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/x86/power/hibernate_asm_64.S 
> b/arch/x86/power/hibernate_asm_64.S
> index e2386cb..4400a43 100644
> --- a/arch/x86/power/hibernate_asm_64.S
> +++ b/arch/x86/power/hibernate_asm_64.S
> @@ -21,8 +21,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  ENTRY(swsusp_arch_suspend)
> + FRAME_BEGIN
>   movq$saved_context, %rax
>   movq%rsp, pt_regs_sp(%rax)
>   movq%rbp, pt_regs_bp(%rax)
> @@ -50,7 +52,9 @@ ENTRY(swsusp_arch_suspend)
>   movq%rax, restore_cr3(%rip)
>  
>   call swsusp_save
> + FRAME_END
>   ret
> +ENDPROC(swsusp_arch_suspend)
>  
>  ENTRY(restore_image)
>   /* switch to temporary page tables */
> @@ -107,6 +111,7 @@ ENTRY(core_restore_code)
>*/
>  
>  ENTRY(restore_registers)
> + FRAME_BEGIN
>   /* go back to the original page tables */
>   movq%rbx, %cr3
>  
> @@ -147,4 +152,6 @@ ENTRY(restore_registers)
>   /* tell the hibernation core that we've just restored the memory */
>   movq%rax, in_suspend(%rip)
>  
> + FRAME_END
>   ret
> +ENDPROC(restore_registers)
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/tty: add kernel.restrict_pushback sysctl

[Jann Horn]

This new sysctl can be set to 1 to require CAP_SYS_ADMIN for
the TIOCSTI ioctl (which lets the caller push input back into
the TTY and thereby fake input to other processes that read
from the same TTY).

This is a well-known problem that hasn't been handled
particularly well in userland, e.g. allowing a user to whose
account root switches using "su" (or using "sudo" in the
default config) to write input to root's shell, resulting
in a privilege escalation. Additionally, it has increased
the impact of other security issues and requires care by
LSMs to ensure that restricted processes can't fiddle with
the TTYs of more privileged processes running under the
same user.

TIOCSTI is relatively exotic. For most users, turning this
sysctl on should be no problem.

Note that this does not make it completely safe to leak pty
FDs to unprivileged code: They could still be used to steal
passwords that the user enters in his terminal, to
selectively suppress keystrokes or to just fake program
output. An automatic kernel-side solution to this, if it is
even possible, would probably be complicated.

Signed-off-by: Jann Horn 
---
 drivers/tty/tty_io.c | 12 +++-
 include/linux/tty.h  |  2 ++
 kernel/sysctl.c  | 10 ++
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index bcc8e1e..c7536d6 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -126,6 +126,15 @@ struct ktermios tty_std_termios = {/* for the 
benefit of tty drivers  */
.c_ospeed = 38400
 };
 
+/*
+ * There are many ways in which an attacker can get hold of a TTY's
+ * file descriptor, both through leaks from a privileged parent to
+ * a less privileged child and through other attacks. The system
+ * administrator can set this flag to reduce the impact of such
+ * attacks a lot.
+ */
+int sysctl_restrict_pushback __read_mostly;
+
 EXPORT_SYMBOL(tty_std_termios);
 
 /* This list gets poked at by procfs and various bits of boot up code. This
@@ -2270,8 +2279,9 @@ static int tiocsti(struct tty_struct *tty, char __user *p)
 {
char ch, mbz = 0;
struct tty_ldisc *ld;
+   bool needpriv = current->signal->tty != tty || sysctl_restrict_pushback;
 
-   if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
+   if (needpriv && !capable(CAP_SYS_ADMIN))
return -EPERM;
if (get_user(ch, p))
return -EFAULT;
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 5e31f1b..8cc8173 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -674,3 +674,5 @@ static inline void proc_tty_unregister_driver(struct 
tty_driver *d) {}
} while (0)
 
 #endif
+
+extern int sysctl_restrict_pushback;
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index dc6858d..7bd1a28 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -65,6 +65,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1172,6 +1173,15 @@ static struct ctl_table kern_table[] = {
.extra2 = &one,
},
 #endif
+   {
+   .procname   = "restrict_pushback",
+   .data   = &sysctl_restrict_pushback,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = &zero,
+   .extra2 = &one,
+   },
{ }
 };
 
-- 
2.1.4

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

Dear Friend,

[Dr. David White]

Dear Friend,

With due respect to your person and much sincerity of purpose . I have a 
business proposal which I will like to handle with you. $35 million USD is 
involves. But be rest assured that everything is legal and risk free as I have 
concluded all the arrangements and the legal papers that will back the 
transaction up. Kindly indicate your interest to enable me tell you more detail 
of the proposal.

Waiting for your urgent response.
Yours Faithfully,
Dr David White

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

NULL pointer deref in dccp (inet_csk_listen_start/inet_csk_get_port)

[Vegard Nossum]

Hi all,

I've been running into the following oops:

[ 1128.895622] BUG: unable to handle kernel NULL pointer dereference at 
  (null)

[ 1128.896010] IP: [<  (null)>]   (null)
[ 1128.896010] PGD 179ee067 PUD 189b1067 PMD 0
[ 1128.896010] Oops: 0010 [#1] PREEMPT SMP
[ 1128.896010] CPU: 1 PID: 1023 Comm: a.out Not tainted 4.4.0-rc5+ #64
[ 1128.896010] task: 88001a7e72c0 ti: 880017534000 task.ti: 
880017534000
[ 1128.896010] RIP: 0010:[<>]  [<  (null)>] 
  (null)

[ 1128.896010] RSP: 0018:880017537e60  EFLAGS: 00010246
[ 1128.896010] RAX: 820deec0 RBX: 880019e12e00 RCX: 
a90c
[ 1128.896010] RDX: 0001 RSI: 880019e12e00 RDI: 
880018f23f00
[ 1128.896010] RBP: 880017537ed0 R08: 7f0788df40f4 R09: 
fe0ab1db
[ 1128.896010] R10:  R11: 0206 R12: 
a90c
[ 1128.896010] R13: 828233c0 R14: 880018f23f00 R15: 
8800196b1db0
[ 1128.896010] FS:  7f078872f700() GS:88001a90() 
knlGS:

[ 1128.896010] CS:  0010 DS:  ES:  CR0: 80050033
[ 1128.896010] CR2:  CR3: 18832000 CR4: 
001406a0

[ 1128.896010] Stack:
[ 1128.896010]  81ae7190 0005 880018f23f00 
0006
[ 1128.896010]  810dc981 8311b380  
a90c
[ 1128.896010]  4001 880018f23f00 007d 
007d

[ 1128.896010] Call Trace:
[ 1128.896010]  [] ? inet_csk_get_port+0x4c0/0x820
[ 1128.896010]  [] ? 
__raw_callee_save___pv_queued_spin_unlock+0x11/0x20

[ 1128.896010]  [] inet_csk_listen_start+0x78/0xf0
[ 1128.896010]  [] inet_dccp_listen+0xbe/0x120
[ 1128.896010]  [] SyS_listen+0xcc/0xe0
[ 1128.896010]  [] entry_SYSCALL_64_fastpath+0x12/0x71
[ 1128.896010] Code:  Bad RIP value.
[ 1128.896010] RIP  [<  (null)>]   (null)
[ 1128.896010]  RSP 
[ 1128.896010] CR2: 
[ 1128.896010] ---[ end trace 583887ed13928755 ]---

It looks like the same thing that Dave Jones ran into a couple of times
before:

https://www.mail-archive.com/netdev@vger.kernel.org/msg73745.html
https://www.mail-archive.com/netdev@vger.kernel.org/msg87675.html

I am able to reproduce this reliably within ~30 seconds or so (as non-root).

Jamie Iles and I been able to narrow it down to a race between connect()
and listen() on AF_INET6/IPPROTO_DCCP sockets:

- Thread A does connect() which calls dccp_v6_connect() which sets
icsk->icsk_af_ops = &dccp_ipv6_mapped. However, dccp_ipv6_mapped has
->bind_conflict == NULL.

- Thread B does listen() which calls into inet_csk_get_port() and tries
to call inet_csk(sk)->icsk_af_ops->bind_conflict.

Using the following patch we can no longer reproduce this specific issue:

diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 9c6d050..0c27e71 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -947,6 +947,7 @@ static const struct inet_connection_sock_af_ops 
dccp_ipv6_mapped = {

.getsockopt= ipv6_getsockopt,
.addr2sockaddr = inet6_csk_addr2sockaddr,
.sockaddr_len  = sizeof(struct sockaddr_in6),
+   .bind_conflict = inet6_csk_bind_conflict,
 #ifdef CONFIG_COMPAT
.compat_setsockopt = compat_ipv6_setsockopt,
.compat_getsockopt = compat_ipv6_getsockopt,

If you think this is the right fix, we can submit a proper patch.

Thanks,


Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/14] serial: pic32_uart: Add PIC32 UART driver

[Andy Shevchenko]

On Tue, Dec 15, 2015 at 12:42 AM, Joshua Henderson
 wrote:
> From: Andrei Pistirica 
>
> This adds UART and a serial console driver for Microchip PIC32 class
> devices.
>
> Signed-off-by: Andrei Pistirica 
> Signed-off-by: Joshua Henderson 
> Cc: Ralf Baechle 
> ---
>  drivers/tty/serial/Kconfig   |   21 +
>  drivers/tty/serial/Makefile  |1 +
>  drivers/tty/serial/pic32_uart.c  |  927 
> ++
>  drivers/tty/serial/pic32_uart.h  |  198 
>  include/uapi/linux/serial_core.h |3 +
>  5 files changed, 1150 insertions(+)
>  create mode 100644 drivers/tty/serial/pic32_uart.c
>  create mode 100644 drivers/tty/serial/pic32_uart.h
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index f38beb2..8853b1e 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -901,6 +901,27 @@ config SERIAL_SGI_L1_CONSOLE
> controller serial port as your console (you want this!),
> say Y.  Otherwise, say N.
>
> +config SERIAL_PIC32
> +   tristate "Microchip PIC32 serial support"
> +   depends on MACH_PIC32
> +   select SERIAL_CORE
> +   help
> + If you have a PIC32, this driver supports the serial ports.
> +
> + Say Y or M to use PIC32 serial ports, otherwise say N. Note that
> + to use a serial port as a console, this must be included in kernel 
> and
> + not as a module.
> +
> +config SERIAL_PIC32_CONSOLE
> +   bool "PIC32 serial console support"
> +   depends on SERIAL_PIC32
> +   select SERIAL_CORE_CONSOLE
> +   help
> + If you have a PIC32, this driver supports the putting a console on 
> one
> + of the serial ports.
> +
> + Say Y to use the PIC32 console, otherwise say N.
> +
>  config SERIAL_MPC52xx
> tristate "Freescale MPC52xx/MPC512x family PSC serial support"
> depends on PPC_MPC52xx || PPC_MPC512x
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index 5ab4111..bc5e354 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)   += 
> digicolor-usart.o
>  obj-$(CONFIG_SERIAL_MEN_Z135)  += men_z135_uart.o
>  obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
>  obj-$(CONFIG_SERIAL_STM32) += stm32-usart.o
> +obj-$(CONFIG_SERIAL_PIC32) += pic32_uart.o
>
>  # GPIOLIB helpers for modem control lines
>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/pic32_uart.c b/drivers/tty/serial/pic32_uart.c
> new file mode 100644
> index 000..5c05c11
> --- /dev/null
> +++ b/drivers/tty/serial/pic32_uart.c
> @@ -0,0 +1,927 @@
> +/*
> + * PIC32 Integrated Serial Driver.
> + *
> + * Copyright (C) 2015 Microchip Technology, Inc.
> + *
> + * Authors:
> + *   Steve Scott ,
> + *   Sorin-Andrei Pistirica 
> + *
> + * Licensed under GPLv2 or later.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Didn't notice clock provider here.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Revisit this list and leave exactly what is used.

> +
> +#include "pic32_uart.h"
> +
> +/* UART name and device definitions */
> +#define PIC32_DEV_NAME "pic32-uart"
> +#define PIC32_MAX_UARTS6
> +
> +#define PIC32_SDEV_NAME"ttyS"
> +#define PIC32_SDEV_MAJOR   TTY_MAJOR
> +#define PIC32_SDEV_MINOR   64
> +
> +/* pic32_sport pointer for console use */
> +static struct pic32_sport *pic32_sports[PIC32_MAX_UARTS];
> +
> +static inline int pic32_enable_clock(struct pic32_sport *sport)
> +{
> +   sport->ref_clk++;
> +

Useless empty line (do in one style).

> +   return clk_prepare_enable(sport->clk);
> +}
> +
> +static inline void pic32_disable_clock(struct pic32_sport *sport)
> +{
> +   sport->ref_clk--;
> +   clk_disable_unprepare(sport->clk);
> +}
> +
> +/* serial core request to check if uart tx buffer is empty */
> +static unsigned int pic32_uart_tx_empty(struct uart_port *port)
> +{
> +   struct pic32_sport *sport = to_pic32_sport(port);
> +   u32 val = pic32_uart_read(sport, PIC32_UART_STA);
> +
> +   return (val & PIC32_UART_STA_TRMT) ? 1 : 0;
> +}
> +
> +/* serial core request to set UART outputs */
> +static void pic32_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> +   struct pic32_sport *sport = to_pic32_sport(port);
> +
> +   /* set loopback mode */
> +   if (mctrl & TIOCM_LOOP)
> +   pic32_uart_rset(PIC32_UART_MODE_LPBK, sport, PIC32_UART_MODE);
> +   else
> +   pic32_uart_rclr(PIC32_UART_MODE_LPBK, sport, PIC32_UART_MODE);
> +}
> +
> +/* get the state of CTS input pin for this port */
> +static unsigned int get_cts_state(struct pic32_sport *sport)
> +{
> + 

Re: Power off problem with newer kernels on Acer laptop

[Andy Shevchenko]

On Sun, Dec 13, 2015 at 10:57 PM, Bruce Mayo  wrote:
> Dear kernel maintainers,
>
> Newer versions of the linux kernel don't shut off the power on an Acer
> Aspire E11 laptop. The full bug report is attached.

I'm pretty sure this is related to
https://bugzilla.kernel.org/show_bug.cgi?id=101271.



-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Power off problem with newer kernels on Acer laptop

[Andy Shevchenko]

On Sun, Dec 20, 2015 at 6:27 PM, Andy Shevchenko
 wrote:
> On Sun, Dec 13, 2015 at 10:57 PM, Bruce Mayo  wrote:
>> Dear kernel maintainers,
>>
>> Newer versions of the linux kernel don't shut off the power on an Acer
>> Aspire E11 laptop. The full bug report is attached.
>
> I'm pretty sure this is related to
> https://bugzilla.kernel.org/show_bug.cgi?id=101271.
>

Oops, this link:
https://bugzilla.kernel.org/show_bug.cgi?id=85931


-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf tools: Do not show trace command if it's not compiled in

[Jiri Olsa]

The trace command still appears in help message when you
run simple 'perf' command.

It's because the generate-cmdlist.sh does not care about the
HAVE_LIBAUDIT_SUPPORT dependency of trace command and puts
it into generated common_cmds array.

Wrapping trace command under HAVE_LIBAUDIT_SUPPORT dependency,
which will exclude it from common_cmds array if HAVE_LIBAUDIT_SUPPORT
is not set.

Link: http://lkml.kernel.org/n/tip-eys6x7vq4y9363s2wkjwa...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/command-list.txt |  2 +-
 tools/perf/util/generate-cmdlist.sh | 15 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/tools/perf/command-list.txt b/tools/perf/command-list.txt
index acc3ea7d90b7..ab5cbaa170d0 100644
--- a/tools/perf/command-list.txt
+++ b/tools/perf/command-list.txt
@@ -26,4 +26,4 @@ perf-stat mainporcelain common
 perf-test  mainporcelain common
 perf-timechart mainporcelain common
 perf-top   mainporcelain common
-perf-trace mainporcelain common
+perf-trace mainporcelain audit
diff --git a/tools/perf/util/generate-cmdlist.sh 
b/tools/perf/util/generate-cmdlist.sh
index 36a885d2cd22..0ac2037c970c 100755
--- a/tools/perf/util/generate-cmdlist.sh
+++ b/tools/perf/util/generate-cmdlist.sh
@@ -36,4 +36,19 @@ do
  }' "Documentation/perf-$cmd.txt"
 done
 echo "#endif /* HAVE_LIBELF_SUPPORT */"
+
+echo "#ifdef HAVE_LIBAUDIT_SUPPORT"
+sed -n -e 's/^perf-\([^]*\)[   ].* audit*/\1/p' command-list.txt |
+sort |
+while read cmd
+do
+ sed -n '
+ /^NAME/,/perf-'"$cmd"'/H
+ ${
+x
+s/.*perf-'"$cmd"' - \(.*\)/  {"'"$cmd"'", "\1"},/
+   p
+ }' "Documentation/perf-$cmd.txt"
+done
+echo "#endif /* HAVE_LIBELF_SUPPORT */"
 echo "};"
-- 
2.4.3

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

Re: [PATCH] drivers/tty: add kernel.restrict_pushback sysctl

[One Thousand Gnomes]

On Sun, 20 Dec 2015 16:45:26 +0100
Jann Horn  wrote:

> This new sysctl can be set to 1 to require CAP_SYS_ADMIN for
> the TIOCSTI ioctl (which lets the caller push input back into
> the TTY and thereby fake input to other processes that read
> from the same TTY).

You can already do tbis with an LSM, you don't need to add random
unstructured extra options nobody will know about. Your extra code also
doesn't log anything so the user who does hit a usage case will have
nightmares debugging it.

Am LSM can also do the job properly because it can use labels to
ascertain the action to perform dependant upon the tty and how it is
currently being used. An LSM can also protect you far better as it can
taint the input (for example it can arrange that any TIOCSTI input
character from a non root user causes the receiving process to be
untrusted - so you attach the su session and your input just makes the
shell executing it untrusted so unable to run the command).

> This is a well-known problem that hasn't been handled
> particularly well in userland, e.g. allowing a user to whose
> account root switches using "su" (or using "sudo" in the
> default config) to write input to root's shell, resulting
> in a privilege escalation. Additionally, it has increased

And the same attack works via X events and keyboard programming games. If
you leak file handles you lose. Again an LSM can mitigate here in ways
your sysctl can't.

> Note that this does not make it completely safe to leak pty
> FDs to unprivileged code: They could still be used to steal
> passwords that the user enters in his terminal, to
> selectively suppress keystrokes or to just fake program
> output. An automatic kernel-side solution to this, if it is
> even possible, would probably be complicated.

This is precisely the problem I have with this - it's airport security,
it sounds good but has no value at all. Remember that anyone wanting to
attack you today is using scripts so a week after your sysctl appears the
script will be updated and everyone's robots will have the new attack that
bypasses it.

So instead of attacking a leaked pty/tty handle the opponent uses the
leaked X11 handle and posts X events, or if its a console fd they use the
console interfaces to fake up keypresses.

There are IMHO two things you need to make any attempt to solve this
properly in the usual circumstances

- You need a secure event channel between the keyboard and the root shell
  you create

- You need a way to switch reliably to that secure channel

That all comes down to having usable SAK (secure attention keu) support.
With the current graphics DRM and with Wayland we are actually fairly
close to that being feasible. Until then anyone who types su on an
untrusted console is (and always has been) asking for trouble.

As an aside - you also need to include documentation if adding sysctls.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: 8250: add gpio support to exar

[One Thousand Gnomes]

On Sun, 20 Dec 2015 20:17:22 +0530
Sudip Mukherjee  wrote:

> On Sun, Dec 20, 2015 at 04:18:17PM +0200, Andy Shevchenko wrote:
> > On Sun, Dec 20, 2015 at 3:24 PM, Sudip Mukherjee
> >  wrote:
> > > Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
> > > can be controlled using gpio interface.
> > > Add support to use these pins and select GPIO_SYSFS also so that these
> > > pins can be used from the userspace through sysfs.
> > >
> > > Tested-by: Rob Groner 
> > > Signed-off-by: Sudip Mukherjee 
> > 
> Hi Andy,
> Thanks for the review. Just a few doubts below.
> 
> > > @@ -0,0 +1,261 @@
> > > +/*
> > > + * GPIO driver for Exar XR17V35X chip
> > > + *
> > > + * Copyright (C) 2015 Sudip Mukherjee 
> > > + *
> > > + * 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.
> > > + */
> 
> > > +
> > > +err_destroy:
> > > +   mutex_unlock(&exar_mtx);
> > > +   mutex_destroy(&exar_gpio->lock);
> > > +err_unmap:
> > > +   iounmap(p);
> > 
> > pci_iounmap?
> 
> I thought about pci_iounmap but I saw that most of the code in
> 8250_pci.c is using iounmap, so i went in favor of the majority.
> Will change it.
> 
> > 
> > > +   return ret;
> > > +}
> > > +EXPORT_SYMBOL(xr17v35x_gpio_init);
> > > +
> > 
> > > +static void __exit exar_gpio_exit(void)
> > > +{
> > > +}
> > > +
> > > +module_exit(exar_gpio_exit);
> > > +
> > > +static int __init exar_gpio_init(void)
> > > +{
> > > +   return 0;
> > > +}
> > > +
> > > +module_init(exar_gpio_init);
> > > +
> > 
> > Useless for now. You are using it as a library.
> 
> Main doubt here. If I do not give the module_init() and module_exit()
> then what entry do i keep in the Kconfig? In this v3, it is kept as
> tristate. Should that be bool then? 

If you are linking it into the driver you don't need the module_init/exit
gpio_init/exit methods. Your Kconfig becomes a bool and you combine the
file into the driver based upon that bool.

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

Re: [PATCH v5 2/3] tty: Add software emulated RS485 support for 8250

[Andy Shevchenko]

On Sat, Dec 12, 2015 at 1:23 PM, Matwey V. Kornilov  wrote:
> Implementation of software emulation of RS485 direction handling is based
> on omap_serial driver.
> Before and after transmission RTS is set to the appropriate value.
>
> Note that before calling serial8250_em485_init the caller has to
> ensure that UART will interrupt when shift register empty. Otherwise,
> emultaion cannot be used.
>
> Both serial8250_em485_init and serial8250_em485_destroy are
> idempotent functions.

Just nitpick suggesting to rename both struct and field:

struct uart_8250_rs485em *rs485em;

(might be 'sw' suffix as well, which I like more — rs485sw)

and corresponding local variables if any.

>
> Signed-off-by: Matwey V. Kornilov 
> ---
>  drivers/tty/serial/8250/8250.h  |   6 ++
>  drivers/tty/serial/8250/8250_port.c | 161 
> +++-
>  include/linux/serial_8250.h |   7 ++
>  3 files changed, 170 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
> index d54dcd8..a3816c6 100644
> --- a/drivers/tty/serial/8250/8250.h
> +++ b/drivers/tty/serial/8250/8250.h
> @@ -117,6 +117,12 @@ static inline void serial_dl_write(struct uart_8250_port 
> *up, int value)
>  struct uart_8250_port *serial8250_get_port(int line);
>  void serial8250_rpm_get(struct uart_8250_port *p);
>  void serial8250_rpm_put(struct uart_8250_port *p);
> +int serial8250_em485_init(struct uart_8250_port *p);
> +void serial8250_em485_destroy(struct uart_8250_port *p);
> +static inline bool serial8250_em485_enabled(struct uart_8250_port *p)
> +{
> +   return p->rs485_emul && (p->port.rs485.flags & SER_RS485_ENABLED);
> +}
>
>  #if defined(__alpha__) && !defined(CONFIG_PCI)
>  /*
> diff --git a/drivers/tty/serial/8250/8250_port.c 
> b/drivers/tty/serial/8250/8250_port.c
> index 8ad0b2d..394d0d2 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -504,6 +505,31 @@ static void serial8250_clear_fifos(struct uart_8250_port 
> *p)
> }
>  }
>
> +static inline void serial8250_em485_rts_on_send(struct uart_8250_port *p)
> +{
> +   unsigned char mcr = serial_in(p, UART_MCR);
> +
> +   if (p->port.rs485.flags & SER_RS485_RTS_ON_SEND)
> +   mcr |= UART_MCR_RTS;
> +   else
> +   mcr &= ~UART_MCR_RTS;
> +   serial_out(p, UART_MCR, mcr);
> +}
> +
> +static inline void serial8250_em485_rts_after_send(struct uart_8250_port *p)
> +{
> +   unsigned char mcr = serial_in(p, UART_MCR);
> +
> +   if (p->port.rs485.flags & SER_RS485_RTS_AFTER_SEND)
> +   mcr |= UART_MCR_RTS;
> +   else
> +   mcr &= ~UART_MCR_RTS;
> +   serial_out(p, UART_MCR, mcr);
> +}
> +
> +static void serial8250_em485_handle_start_tx(unsigned long arg);
> +static void serial8250_em485_handle_stop_tx(unsigned long arg);
> +
>  void serial8250_clear_and_reinit_fifos(struct uart_8250_port *p)
>  {
> serial8250_clear_fifos(p);
> @@ -528,6 +554,42 @@ void serial8250_rpm_put(struct uart_8250_port *p)
>  }
>  EXPORT_SYMBOL_GPL(serial8250_rpm_put);
>
> +int serial8250_em485_init(struct uart_8250_port *p)
> +{
> +   if (p->rs485_emul != NULL)
> +   return 0;
> +
> +   p->rs485_emul = kmalloc(sizeof(struct uart_8250_rs485_emul), 
> GFP_KERNEL);
> +   if (p->rs485_emul == NULL)
> +   return -ENOMEM;
> +
> +   init_timer(&p->rs485_emul->stop_tx_timer);
> +   p->rs485_emul->stop_tx_timer.function = 
> serial8250_em485_handle_stop_tx;
> +   p->rs485_emul->stop_tx_timer.data = (unsigned long)p;
> +   p->rs485_emul->stop_tx_timer.flags |= TIMER_IRQSAFE;
> +   init_timer(&p->rs485_emul->start_tx_timer);
> +   p->rs485_emul->start_tx_timer.function = 
> serial8250_em485_handle_start_tx;
> +   p->rs485_emul->start_tx_timer.data = (unsigned long)p;
> +   p->rs485_emul->start_tx_timer.flags |= TIMER_IRQSAFE;
> +
> +   serial8250_em485_rts_after_send(p);
> +
> +   return 0;
> +}
> +EXPORT_SYMBOL_GPL(serial8250_em485_init);
> +void serial8250_em485_destroy(struct uart_8250_port *p)
> +{
> +   if (p->rs485_emul == NULL)
> +   return;
> +
> +   del_timer_sync(&p->rs485_emul->start_tx_timer);
> +   del_timer_sync(&p->rs485_emul->stop_tx_timer);
> +
> +   kfree(p->rs485_emul);
> +   p->rs485_emul = NULL;
> +}
> +EXPORT_SYMBOL_GPL(serial8250_em485_destroy);
> +
>  /*
>   * These two wrappers ensure that enable_runtime_pm_tx() can be called more 
> than
>   * once and disable_runtime_pm_tx() will still disable RPM because the fifo 
> is
> @@ -1293,7 +1355,61 @@ static void serial8250_stop_rx(struct uart_port *port)
> serial8250_rpm_put(up);
>  }
>
> -static inline void __stop_tx(struct uart_8250_port *p)
> +static __u32 __start_tx_rs485(struct uart_8250_port *p)
> +{
> +   if (!serial

arch/x86/xen/suspend.c:70:9: error: implicit declaration of function 'xen_pv_domain'

[kbuild test robot]

Hi Sasha,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   69c37a92ddbf79d9672230f21a04580d7ac2f4c3
commit: 71458cfc782eafe4b27656e078d379a34e472adf kernel: add support for gcc 5
date:   1 year, 2 months ago
config: x86_64-randconfig-x006-201551 (attached as .config)
reproduce:
git checkout 71458cfc782eafe4b27656e078d379a34e472adf
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   arch/x86/xen/suspend.c: In function 'xen_arch_pre_suspend':
>> arch/x86/xen/suspend.c:70:9: error: implicit declaration of function 
>> 'xen_pv_domain' [-Werror=implicit-function-declaration]
if (xen_pv_domain())
^
   cc1: some warnings being treated as errors

vim +/xen_pv_domain +70 arch/x86/xen/suspend.c

0e91398f Jeremy Fitzhardinge 2008-05-26  54 
pfn_to_mfn(xen_start_info->store_mfn);
0e91398f Jeremy Fitzhardinge 2008-05-26  55 
xen_start_info->console.domU.mfn =
0e91398f Jeremy Fitzhardinge 2008-05-26  56 
pfn_to_mfn(xen_start_info->console.domU.mfn);
0e91398f Jeremy Fitzhardinge 2008-05-26  57 } else {
0e91398f Jeremy Fitzhardinge 2008-05-26  58  #ifdef CONFIG_SMP
b78936e1 Mike Travis 2008-12-16  59 
BUG_ON(xen_cpu_initialized_map == NULL);
b78936e1 Mike Travis 2008-12-16  60 
cpumask_copy(xen_cpu_initialized_map, cpu_online_mask);
0e91398f Jeremy Fitzhardinge 2008-05-26  61  #endif
9c7a7942 Jeremy Fitzhardinge 2008-05-31  62 xen_vcpu_restore();
0e91398f Jeremy Fitzhardinge 2008-05-26  63 }
0e91398f Jeremy Fitzhardinge 2008-05-26  64  
aa8532c3 David Vrabel2014-05-08  65 xen_mm_unpin_all();
aa8532c3 David Vrabel2014-05-08  66  }
aa8532c3 David Vrabel2014-05-08  67  
aa8532c3 David Vrabel2014-05-08  68  void xen_arch_pre_suspend(void)
aa8532c3 David Vrabel2014-05-08  69  {
aa8532c3 David Vrabel2014-05-08 @70  if (xen_pv_domain())
aa8532c3 David Vrabel2014-05-08  71  xen_pv_pre_suspend();
aa8532c3 David Vrabel2014-05-08  72  }
aa8532c3 David Vrabel2014-05-08  73  
aa8532c3 David Vrabel2014-05-08  74  void xen_arch_post_suspend(int 
cancelled)
aa8532c3 David Vrabel2014-05-08  75  {
aa8532c3 David Vrabel2014-05-08  76  if (xen_pv_domain())
aa8532c3 David Vrabel2014-05-08  77  
xen_pv_post_suspend(cancelled);
aa8532c3 David Vrabel2014-05-08  78  else

:: The code at line 70 was first introduced by commit
:: aa8532c32216ae07c3813b9aeb774517878a7573 xen: refactor suspend pre/post 
hooks

:: TO: David Vrabel 
:: CC: David Vrabel 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v3] serial: 8250: add gpio support to exar

[One Thousand Gnomes]

> v3: Alan commented on v2, few things like NULL check, name of the gpio chip,
> moving some more code into the gpio code. He also commented on it being
> a separate module, but since this will not be needed by someone who is not
> using Exar chip, and even those who are using, some of them may not need it.
> This is optional for only those who wants to use the gpio capability of that
> chip. So kept it as a separate module. Waiting for your comments on that.

That doesn't work because you reference the methods in it so it will
always be dragged in. You would have to make the exar driver an MFD that
provided a serial and a gpio binding to fix that up I think, or instead
of having the serial driver call into your gpio driver (thus forcing the
module into memory) you would have the serial driver create a platform
device or similar that the GPIO device bound to.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v9 1/3] serial: 8250_dw: Avoid serial_outx code duplicate with new dw8250_check_lcr()

[Andy Shevchenko]

On Sat, Dec 12, 2015 at 7:18 PM, Noam Camus  wrote:
> From: Noam Camus 
>
> With the help of Heikki we take common code that
> makes sure LCR write wasn't ignored and put it in new function called
> dw8250_check_lcr(). This function serves 3 serial_out routines:
> dw8250_serial_out(), dw8250_serial_out32(), and dw8250_serial_outq().
>
> This patch only brings better code reuse.
>
> Signed-off-by: Noam Camus 
> Cc: Heikki Krogerus 
> Cc: Andy Shevchenko 

All three fine by me:
Acked-by: Andy Shevchenko 

> ---
>  drivers/tty/serial/8250/8250_dw.c |   91 
> +
>  1 files changed, 42 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_dw.c 
> b/drivers/tty/serial/8250/8250_dw.c
> index a5d319e..ffe5e0c 100644
> --- a/drivers/tty/serial/8250/8250_dw.c
> +++ b/drivers/tty/serial/8250/8250_dw.c
> @@ -95,25 +95,43 @@ static void dw8250_force_idle(struct uart_port *p)
> (void)p->serial_in(p, UART_RX);
>  }
>
> -static void dw8250_serial_out(struct uart_port *p, int offset, int value)
> +static void dw8250_check_lcr(struct uart_port *p, int value)
>  {
> -   writeb(value, p->membase + (offset << p->regshift));
> +   void __iomem *offset = p->membase + (UART_LCR << p->regshift);
> +   int tries = 1000;
>
> /* Make sure LCR write wasn't ignored */
> -   if (offset == UART_LCR) {
> -   int tries = 1000;
> -   while (tries--) {
> -   unsigned int lcr = p->serial_in(p, UART_LCR);
> -   if ((value & ~UART_LCR_SPAR) == (lcr & 
> ~UART_LCR_SPAR))
> -   return;
> -   dw8250_force_idle(p);
> -   writeb(value, p->membase + (UART_LCR << p->regshift));
> -   }
> -   /*
> -* FIXME: this deadlocks if port->lock is already held
> -* dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> -*/
> +   while (tries--) {
> +   unsigned int lcr = p->serial_in(p, UART_LCR);
> +
> +   if ((value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR))
> +   return;
> +
> +   dw8250_force_idle(p);
> +
> +#ifdef CONFIG_64BIT
> +   __raw_writeq(value & 0xff, offset);
> +#else
> +   if (p->iotype == UPIO_MEM32)
> +   writel(value, offset);
> +   else
> +   writeb(value, offset);
> +#endif
> }
> +   /*
> +* FIXME: this deadlocks if port->lock is already held
> +* dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> +*/
> +}
> +
> +static void dw8250_serial_out(struct uart_port *p, int offset, int value)
> +{
> +   struct dw8250_data *d = p->private_data;
> +
> +   writeb(value, p->membase + (offset << p->regshift));
> +
> +   if (offset == UART_LCR && !d->uart_16550_compatible)
> +   dw8250_check_lcr(p, value);
>  }
>
>  static unsigned int dw8250_serial_in(struct uart_port *p, int offset)
> @@ -135,49 +153,26 @@ static unsigned int dw8250_serial_inq(struct uart_port 
> *p, int offset)
>
>  static void dw8250_serial_outq(struct uart_port *p, int offset, int value)
>  {
> +   struct dw8250_data *d = p->private_data;
> +
> value &= 0xff;
> __raw_writeq(value, p->membase + (offset << p->regshift));
> /* Read back to ensure register write ordering. */
> __raw_readq(p->membase + (UART_LCR << p->regshift));
>
> -   /* Make sure LCR write wasn't ignored */
> -   if (offset == UART_LCR) {
> -   int tries = 1000;
> -   while (tries--) {
> -   unsigned int lcr = p->serial_in(p, UART_LCR);
> -   if ((value & ~UART_LCR_SPAR) == (lcr & 
> ~UART_LCR_SPAR))
> -   return;
> -   dw8250_force_idle(p);
> -   __raw_writeq(value & 0xff,
> -p->membase + (UART_LCR << p->regshift));
> -   }
> -   /*
> -* FIXME: this deadlocks if port->lock is already held
> -* dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> -*/
> -   }
> +   if (offset == UART_LCR && !d->uart_16550_compatible)
> +   dw8250_check_lcr(p, value);
>  }
>  #endif /* CONFIG_64BIT */
>
>  static void dw8250_serial_out32(struct uart_port *p, int offset, int value)
>  {
> +   struct dw8250_data *d = p->private_data;
> +
> writel(value, p->membase + (offset << p->regshift));
>
> -   /* Make sure LCR write wasn't ignored */
> -   if (offset == UART_LCR) {
> -   int tries = 1000;
> -   while (tries--) {
> -   unsigned int lcr = p->serial_in(p, UART_LCR);
> -   if ((value & ~UART_LCR_SPAR) == (lcr & 
> ~UART_LCR_SPAR))
> -   retur

Re: [PATCH v2 1/2] crypto: KEYS: convert public key to the akcipher api

[Tadeusz Struk]

On 12/19/2015 03:49 PM, kbuild test robot wrote:
> Hi Tadeusz,
> 
> [auto build test ERROR on crypto/master]
> [also build test ERROR on v4.4-rc5 next-20151218]
> 
> url:
> https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-KEYS-convert-public-key-to-akcipher-api/20151213-103429
> base:   
> https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git master
> config: x86_64-randconfig-s4-12200710 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from include/crypto/public_key.h:17:0,
> from include/linux/verify_pefile.h:15,
> from arch/x86/kernel/kexec-bzimage64.c:22:
>include/keys/asymmetric-type.h: In function 'asymmetric_key_ids':
>>> >> include/keys/asymmetric-type.h:74:12: error: dereferencing pointer to 
>>> >> incomplete type 'const struct key'
>  return key->payload.data[asym_key_ids];
>^
> 
> vim +74 include/keys/asymmetric-type.h
> 
> 7901c1a8 David Howells 2014-09-16  68 
> size_t len_1,
> 7901c1a8 David Howells 2014-09-16  69 
> const void *val_2,
> 7901c1a8 David Howells 2014-09-16  70 
> size_t len_2);
> 146aa8b1 David Howells 2015-10-21  71  static inline
> 146aa8b1 David Howells 2015-10-21  72  const struct asymmetric_key_ids 
> *asymmetric_key_ids(const struct key *key)
> 146aa8b1 David Howells 2015-10-21  73  {
> 146aa8b1 David Howells 2015-10-21 @74 return 
> key->payload.data[asym_key_ids];
> 146aa8b1 David Howells 2015-10-21  75  }
> 7901c1a8 David Howells 2014-09-16  76  
> 7901c1a8 David Howells 2014-09-16  77  /*
> 
> :: The code at line 74 was first introduced by commit
> :: 146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc KEYS: Merge the type-specific 
> data with the payload data
> 
> :: TO: David Howells 
> :: CC: David Howells 

I think there is something missing in this configuration.
cat .config | grep KEXEC_BZIMAGE_VERIFY_SIG gives nothing.
Anyways, this patch should fix it.

---8<---

From: Tadeusz Struk 

Fix auto build test ERROR on crypto/master

Reported-by: 
Signed-off-by: Tadeusz Struk 

diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86/kernel/kexec-bzimage64.c
index 0f8a6bb..23aa625 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -19,9 +19,10 @@
#include 
#include 
#include 
+#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG
#include 
#include 
-
+#endif
#include 
#include 
#include 

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

[RFC PATCH] ARM: pxa: add defconfig covering all the boards

[Robert Jarzmik]

Add a defconfig covering all known pxa board, ie. all selectable machine
files in arch/arm/mach-pxa/*.c.

This defconfig was built by doing :
 - aggregation of all known defconfigs by cat
am200epdkit_defconfig
cm_x2xx_defconfig
cm_x300_defconfig
colibri_pxa270_defconfig
colibri_pxa300_defconfig
corgi_defconfig
em_x270_defconfig
eseries_pxa_defconfig
ezx_defconfig
h5000_defconfig
imote2_defconfig
lpd270_defconfig
lubbock_defconfig
magician_defconfig
mainstone_defconfig
multi_v7_defconfig
palmz72_defconfig
pcm027_defconfig
pxa168_defconfig
pxa255-idp_defconfig
pxa3xx_defconfig
pxa910_defconfig
raumfeld_defconfig
spitz_defconfig
trizeps4_defconfig
viper_defconfig
xcep_defconfig
zeus_defconfig
 - manual make menuconfig to ensure :
   - all pxa implementation were selected
   - all drivers were transformed into modules rather than builtin
 => as a consequence this single kernel will rely on an initramfs
 => as kernel size matters on pxa, each machine can take the subset
of modules required for it to work
 - CONFIG_PXA_SHARPSL was disabled
   This breaks the boot very early on any non Sharp platform, see
   head-sharpsl.S

This defconfig was tested as booting up to the login phase on :
 - lubbock (pxa25x)
 - mainstone (pxa27x)
 - zylonite (pxa3xx)

The completion of this work will require to :
 - parse manually all the arch/arm/mach-pxa/*c files, look for all
   platform devices added, and verify they are all in pxa_defconfig
 - do the same to ensure all pxa specific drivers (leds, gpio, ...) are
   included

Signed-off-by: Robert Jarzmik 
---
 arch/arm/configs/pxa_defconfig | 772 +
 1 file changed, 772 insertions(+)
 create mode 100644 arch/arm/configs/pxa_defconfig

diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
new file mode 100644
index ..042600285127
--- /dev/null
+++ b/arch/arm/configs/pxa_defconfig
@@ -0,0 +1,772 @@
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
+CONFIG_IRQ_DOMAIN_DEBUG=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=13
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
+CONFIG_SLOB=y
+CONFIG_PROFILING=y
+CONFIG_OPROFILE=m
+CONFIG_KPROBES=y
+CONFIG_MODULES=y
+CONFIG_MODULE_FORCE_LOAD=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_MODULE_SRCVERSION_ALL=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_LDM_PARTITION=y
+CONFIG_CMDLINE_PARTITION=y
+CONFIG_ARCH_PXA=y
+CONFIG_MACH_PXA27X_DT=y
+CONFIG_MACH_PXA3XX_DT=y
+CONFIG_ARCH_LUBBOCK=y
+CONFIG_MACH_MAINSTONE=y
+CONFIG_MACH_ZYLONITE300=y
+CONFIG_MACH_ZYLONITE320=y
+CONFIG_MACH_LITTLETON=y
+CONFIG_MACH_TAVOREVB=y
+CONFIG_MACH_SAAR=y
+CONFIG_ARCH_PXA_IDP=y
+CONFIG_ARCH_VIPER=y
+CONFIG_MACH_ARCOM_ZEUS=y
+CONFIG_MACH_BALLOON3=y
+CONFIG_MACH_CSB726=y
+CONFIG_CSB726_CSB701=y
+CONFIG_MACH_ARMCORE=y
+CONFIG_MACH_EM_X270=y
+CONFIG_MACH_EXEDA=y
+CONFIG_MACH_CM_X300=y
+CONFIG_MACH_CAPC7117=y
+CONFIG_ARCH_GUMSTIX=y
+CONFIG_MACH_INTELMOTE2=y
+CONFIG_MACH_STARGATE2=y
+CONFIG_MACH_XCEP=y
+CONFIG_TRIZEPS_PXA=y
+CONFIG_MACH_TRIZEPS4WL=y
+CONFIG_MACH_LOGICPD_PXA270=y
+CONFIG_MACH_PCM027=y
+CONFIG_MACH_PCM990_BASEBOARD=y
+CONFIG_MACH_COLIBRI=y
+CONFIG_MACH_COLIBRI_PXA270_INCOME=y
+CONFIG_MACH_COLIBRI300=y
+CONFIG_MACH_COLIBRI320=y
+CONFIG_MACH_COLIBRI_EVALBOARD=y
+CONFIG_MACH_VPAC270=y
+CONFIG_MACH_H4700=y
+CONFIG_MACH_H5000=y
+CONFIG_MACH_HIMALAYA=y
+CONFIG_MACH_MAGICIAN=y
+CONFIG_MACH_MIOA701=y
+CONFIG_PXA_EZX=y
+CONFIG_MACH_MP900C=y
+CONFIG_ARCH_PXA_PALM=y
+CONFIG_MACH_RAUMFELD_RC=y
+CONFIG_MACH_RAUMFELD_CONNECTOR=y
+CONFIG_MACH_RAUMFELD_SPEAKER=y
+CONFIG_PXA_SHARPSL=y
+CONFIG_MACH_POODLE=y
+CONFIG_MACH_CORGI=y
+CONFIG_MACH_SHEPHERD=y
+CONFIG_MACH_HUSKY=y
+CONFIG_MACH_AKITA=y
+CONFIG_MACH_BORZOI=y
+CONFIG_MACH_TOSA=y
+CONFIG_TOSA_BT=m
+CONFIG_TOSA_USE_EXT_KEYCODES=y
+CONFIG_MACH_ICONTROL=y
+CONFIG_ARCH_PXA_ESERIES=y
+CONFIG_MACH_ZIPIT2=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCIEPORTBUS=y
+CONFIG_PCCARD=m
+CONFIG_YENTA=m
+CONFIG_PCMCIA_PXA2XX=m
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+# CONFIG_COMPACTION is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_CMDLINE="root=/dev/ram0 ro"
+CONFIG_KEXEC=y
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT_DETAILS=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=m
+CONFIG_CPU_FREQ_GOV_USERSPACE=m
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
+CONFIG_CPUFREQ_DT=m
+CONFIG_ARM_PXA2xx_CPUFREQ=m
+CONFIG_CPU_IDLE=y
+CONFIG_ARM_CPUIDLE=y
+CONFIG_BINFMT_MISC=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=m
+CONFIG_NET_KEY=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=

Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)

[Andrew Cooper]

On 20/12/15 09:25, Michael S. Tsirkin wrote:
> On Thu, Dec 17, 2015 at 03:39:10PM +0100, Peter Zijlstra wrote:
>> On Thu, Dec 17, 2015 at 04:33:44PM +0200, Michael S. Tsirkin wrote:
>>> On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote:
 You could of course go fix that instead of mutilating things into
 sort-of functional state.
>>> Yes, we'd just need to touch all architectures, all for
>>> the sake of UP which almost no one uses.
>>> Basically, we need APIs that explicitly are
>>> for talking to another kernel on a different CPU on
>>> the same SMP system, and implemented identically
>>> between CONFIG_SMP and !CONFIG_SMP on all architectures.
>>>
>>> Do you think this is something of general usefulness,
>>> outside virtio?
>> I'm not aware of any other case, but if there are more parts of virt
>> that need this then I see no problem adding it.
> When I wrote this, I assumed there are no other users, and I'm still not
> sure there are other users at the moment. Do you see a problem then?
>
>> That is, virt in general is the only use-case that I can think of,
>> because this really is an artifact of interfacing with an SMP host while
>> running an UP kernel.
> Or another guest kernel on an SMP host.
>
>> But I'm really not familiar with virt, so I do not know if there's more
>> sites outside of virtio that could use this.
>> Touching all archs is a tad tedious, but its fairly straight forward.
> So I looked and I was only able to find other another possible user in Xen.
>
> Cc Xen folks.
>
> I noticed that drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
> For example:
>
> /* Must write data /after/ reading the consumer index.  * */
> mb();
>
> memcpy(dst, data, avail);
> data += avail;
> len -= avail;
> 
> /* Other side must not see new producer until data is * 
> there. */
> wmb();
> intf->req_prod += avail;
> 
> /* Implies mb(): other side will see the updated producer. */
> notify_remote_via_evtchn(xen_store_evtchn);
>
> To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
>
> Is my analysis correct?

Correct.  The reason full barriers are used is so non-SMP guests still
function correctly.  It is certainly inefficient.

>
> So what I'm suggesting is something like the below patch,
> except instead of using virtio directly, a new set of barriers
> that behaves identically for SMP and non-SMP guests will be introduced.
>
> And of course the weak barriers flag is not needed for Xen -
> that's a virtio only thing.
>
> For example:
>
> smp_pv_wmb()
> smp_pv_rmb()
> smp_pv_mb()
>
> I'd like to get confirmation from Xen folks before posting
> this patchset.
>
> Comments/suggestions?

Very much +1 for fixing this.

Those names would be fine, but they do add yet another set of options in
an already-complicated area.

An alternative might be to have the regular smp_{w,r,}mb() not revert
back to nops if CONFIG_PARAVIRT, or perhaps if pvops have detected a
non-native environment.  (I don't know how feasible this suggestion is,
however.)

~Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: 8250: add gpio support to exar

[Sudip Mukherjee]

On Sun, Dec 20, 2015 at 04:41:31PM +, One Thousand Gnomes wrote:
> On Sun, 20 Dec 2015 20:17:22 +0530
> Sudip Mukherjee  wrote:
> 
> > On Sun, Dec 20, 2015 at 04:18:17PM +0200, Andy Shevchenko wrote:
> > > On Sun, Dec 20, 2015 at 3:24 PM, Sudip Mukherjee
> > >  wrote:
> > > > Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
> > > > can be controlled using gpio interface.
> > > > Add support to use these pins and select GPIO_SYSFS also so that these
> > > > pins can be used from the userspace through sysfs.
> > > >
> > > > Tested-by: Rob Groner 
> > > > Signed-off-by: Sudip Mukherjee 
> > > 
> > Hi Andy,
> > Thanks for the review. Just a few doubts below.
> > 
> > > > @@ -0,0 +1,261 @@
> > > > +/*
> > > > + * GPIO driver for Exar XR17V35X chip
> > > > + *
> > > > + * Copyright (C) 2015 Sudip Mukherjee 
> > > > + *
> > > > + * 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.
> > > > + */
> > 
> > > > +
> > > > +err_destroy:
> > > > +   mutex_unlock(&exar_mtx);
> > > > +   mutex_destroy(&exar_gpio->lock);
> > > > +err_unmap:
> > > > +   iounmap(p);
> > > 
> > > pci_iounmap?
> > 
> > I thought about pci_iounmap but I saw that most of the code in
> > 8250_pci.c is using iounmap, so i went in favor of the majority.
> > Will change it.
> > 
> > > 
> > > > +   return ret;
> > > > +}
> > > > +EXPORT_SYMBOL(xr17v35x_gpio_init);
> > > > +
> > > 
> > > > +static void __exit exar_gpio_exit(void)
> > > > +{
> > > > +}
> > > > +
> > > > +module_exit(exar_gpio_exit);
> > > > +
> > > > +static int __init exar_gpio_init(void)
> > > > +{
> > > > +   return 0;
> > > > +}
> > > > +
> > > > +module_init(exar_gpio_init);
> > > > +
> > > 
> > > Useless for now. You are using it as a library.
> > 
> > Main doubt here. If I do not give the module_init() and module_exit()
> > then what entry do i keep in the Kconfig? In this v3, it is kept as
> > tristate. Should that be bool then? 
> 
> If you are linking it into the driver you don't need the module_init/exit
> gpio_init/exit methods. Your Kconfig becomes a bool and you combine the
> file into the driver based upon that bool.

But isn't it better to have the gpio code separete from the 8250 code?
But how do i combine a file? is it like:

#ifdef SERIAL_8250_EXAR_GPIO
#include "8250_gpio.c"
#endif

or should it be:

#ifdef SERIAL_8250_EXAR_GPIO

all c code

#endif

regards
sudip


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

Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel

[Måns Rullgård]

Julian Margetson  writes:

> On 12/19/2015 4:41 PM, Måns Rullgård wrote:
>> Andy Shevchenko  writes:
>>
>>> On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson  wrote:
 On 12/19/2015 3:07 PM, Måns Rullgård wrote:
> Julian Margetson  writes:
>> Total pages: 522752
>> [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200
>> console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg
> Please add ignore_log_level.
>
 Had to truncate the kernel command line to add it.
>>> I guess Måns meant 'ignore_loglevel'
>> Obviously.  I can never remember where the underscores go.
>
> [   18.362244] sd 3:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 
> GB/465 GiB)
> [   18.372454] sd 3:0:0:0: Attached scsi generic sg3 type 0
> [   18.405433] sd 3:0:0:0: [sdc] Write Protect is off
> [   18.420654] sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
> [   18.461731] sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, 
> doesn't support DPO or FUA
> [   18.502918] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: port=0 dma 
> dir=from device n_elem=1
> [   18.511807] dma dma0chan0: dwc_prep_slave_sg
> [   18.516083] dma dma0chan0: scanned 1 descriptors on freelist
> [   18.521753] sata-dwc 4bffd1000.sata: dma_dwc_xfer_setup sg: 0xedeaa800, 
> count: 1 addr: 0xf6a14400
> [   18.531327] sata-dwc 4bffd1000.sata: sata_dwc_qc_issue: tag=0 
> ap->link.sactive = 0x0001 sactive=0x0001
> [   18.541359] sata-dwc 4bffd1000.sata: sata_dwc_exec_command_by_tag 
> cmd(0x60): READ FPDMA QUEUED tag=0
> [   18.553703] sata-dwc 4bffd1000.sata: sata_dwc_isr intpr=0x0082 
> active_tag=-84148995
> [   18.561717] sata-dwc 4bffd1000.sata: sata_dwc_isr: NEWFP tag=0
> [   18.567561] sata-dwc 4bffd1000.sata: sata_dwc_bmdma_start_by_tag 
> qc=ed2340b8 tag: 0 cmd: 0x60 dma_dir: from device start_dma? 1
> [   18.579043] sata-dwc 4bffd1000.sata: taskfile cmd: 0x60 protocol: ATA NCQ 
> flags: 0x17 device: 40
> [   18.587836] sata-dwc 4bffd1000.sata: feature: 0x08 nsect: 0x0 lbal: 0x0 
> lbam: 0x0 lbah: 0x0
> [   18.596196] sata-dwc 4bffd1000.sata: hob_feature: 0x00 hob_nsect: 0x0 
> hob_lbal: 0x0 hob_lbam: 0x0 hob_lbah: 0x0
> [   18.606292] dma dma0chan0: dwc_tx_submit: queued 2
> [   18.611091] dma dma0chan0: dwc_dostart_first_queued: started 2
> [   48.748614] ata3: lost interrupt (Status 0x40)

Now we're getting somewhere.  The dma transfer is set up and initiated,
but then nothing happens.  Comparing the old sata_dwc driver, from
before the switch to dmaengine, with the dw_dma driver, I noticed an
obvious problem: the descriptors are filled in using the wrong byte
order.  This patch might fix that.

-- 
Måns Rullgård
>From 04b444b301c8b2db732dbf259dddb3dc87d622c8 Mon Sep 17 00:00:00 2001
From: Mans Rullgard 
Date: Sun, 20 Dec 2015 16:54:21 +
Subject: [PATCH] dmaengine: dw: fix byte order of hw descriptor fields

If the DMA controller uses a different byte order than the host CPU,
the hardware linked list descriptor fields need to be byte-swapped.

This patch makes the driver write these fields using the same byte
order it uses for mmio accesses to the DMA engine.  I do not know
if this is guaranteed to always be correct.

Signed-off-by: Mans Rullgard 
---
 drivers/dma/dw/core.c | 84 +++
 drivers/dma/dw/regs.h | 26 +++-
 2 files changed, 63 insertions(+), 47 deletions(-)

diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 7067b6d..b954904 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -209,12 +209,12 @@ static inline void dwc_do_single_block(struct dw_dma_chan *dwc,
 	 * Software emulation of LLP mode relies on interrupts to continue
 	 * multi block transfer.
 	 */
-	ctllo = desc->lli.ctllo | DWC_CTLL_INT_EN;
+	ctllo = dw_lli_read(desc->lli.ctllo) | DWC_CTLL_INT_EN;
 
-	channel_writel(dwc, SAR, desc->lli.sar);
-	channel_writel(dwc, DAR, desc->lli.dar);
+	channel_writel(dwc, SAR, dw_lli_read(desc->lli.sar));
+	channel_writel(dwc, DAR, dw_lli_read(desc->lli.dar));
 	channel_writel(dwc, CTL_LO, ctllo);
-	channel_writel(dwc, CTL_HI, desc->lli.ctlhi);
+	channel_writel(dwc, CTL_HI, dw_lli_read(desc->lli.ctlhi));
 	channel_set_bit(dw, CH_EN, dwc->mask);
 
 	/* Move pointer to next descriptor */
@@ -432,7 +432,7 @@ static void dwc_scan_descriptors(struct dw_dma *dw, struct dw_dma_chan *dwc)
 		}
 
 		/* Check first descriptors llp */
-		if (desc->lli.llp == llp) {
+		if (dw_lli_read(desc->lli.llp) == llp) {
 			/* This one is currently in progress */
 			dwc->residue -= dwc_get_sent(dwc);
 			spin_unlock_irqrestore(&dwc->lock, flags);
@@ -441,7 +441,7 @@ static void dwc_scan_descriptors(struct dw_dma *dw, struct dw_dma_chan *dwc)
 
 		dwc->residue -= desc->len;
 		list_for_each_entry(child, &desc->tx_list, desc_node) {
-			if (child->lli.llp == llp) {
+			if (dw_lli_read(child->lli.llp) == llp) {
 /* Currently in progress */
 dwc->residue -= dwc_get_sent(dwc);
 spin_unlock_irqrestore(&dwc->

Re: [PATCH v5] extcon: add Maxim MAX3355 driver

[Sergei Shtylyov]

Hello.

On 12/20/2015 05:31 PM, Chanwoo Choi wrote:


This patch depend on GPIOLIB configuration as following:
I modified it with following diff and applied it.

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index ba4db7d..3d89e60 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -54,6 +54,7 @@ config EXTCON_MAX14577

  config EXTCON_MAX3355
 tristate "Maxim MAX3355 USB OTG EXTCON Support"
+   depends on GPIOLIB || COMPILE_TEST


   If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST?
   And no, it shouldn't depend on gpiolib. It has empty stubs for the case of 
CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO headers, I'll 
look into it.


[...]


Thanks,
Chanwoo Choi


MBR, Sergei

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

Re: [PATCH RESEND 1/1] serial: 8250_pci: Fix real serial port count for F81504/508/512

[Andy Shevchenko]

On Tue, Dec 15, 2015 at 4:56 AM, Peter Hung  wrote:
> Andy Shevchenko 於 2015/12/13 上午 09:08 寫道:
>>
>> On Tue, Dec 1, 2015 at 8:54 AM, Peter Hung  wrote:
>>> +/* The device is multi-function with UART & GPIO */
>>> +static u8 fintek_gpio_mapping[] = {2, 3, 8, 9, 10, 11};
>>
>>
>> Clearly you have bit combination here
>> Bit 1: 1
>> Bit 3: 1
>>
>> So, mask as 0x0a shall cover this IIAC.
>
>
> IMO, It maybe wrong. If we checked only with 0x0a mask,
> the 0x06 & 0x07 will be passed.

Ah, yes, it will be a bit more than just one check, something like:
(x & 0x0a) && (x & 0x0e != 6)


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