Re: Enable runtime PM automatically?

[Geert Uytterhoeven]

Hi Kevin,

Thanks for your comments!

On Thu, Dec 18, 2014 at 10:29 PM, Kevin Hilman  wrote:
>> However, if PM domains are active, drivers must be runtime PM-aware for the
>> gpd_dev_ops.start() method to be called in the first place (perhaps this is 
>> just
>> one bug that's easy to fix --- the device is "assumed suspended", but can be
>> used). They must
>>   1. call pm_runtime_enable() to enable runtime PM for the device,
>>   2. call pm_runtime_get_sync() to prevent the device from being put in a
>> low-power state at any time. This second call has the
>> "side-effect" of calling
>> gpd_dev_ops.start().
>>
>> Hence, if PM domains are enabled, wouldn't it make sense to
>>   1. enable runtime PM by default, for all devices (bound and unbound),
>>   2. call pm_runtime_get_sync(), for all devices bound to a driver.
>> Of course we have to keep track if drivers call any of the pm_runtime_*()
>> methods theirselves, as that would have to move them from automatic to
>> manual mode.
>>
>> Would this be feasible?
>
> We have to be careful about where the PM core's _get_sync() call goes.
>
> Because you're talking about "bound" devices, I guess you mean after the
> driver probes?  Otherwise, it gets tricky if the _get_sync() is before
> the driver probes, because the device driver may have work it wants to
> do in its runtime PM callbacks, which are not initialized/available
> before the driver probes.  Doing this before probe also makes it rather
> difficult to know for sure the actual physical state of the device, and
> make sure it matches the runtime PM state of the device.  Rafael
> mentioned this also, and I'm not sure how we can be sure of the physical
> state.

Yes, it's complicated by the fact that there are multiple sets of callbacks
(PM domain, device type, class type, bus type, driver).
However, the PM domain one has the highest priority, and is always
(also for devices not bound to a driver) available.

> Some thoughts: devices without drivers would be runtime resumed by the
> core, but will never be suspended, so the PM domain will never shut
> down.  I guess the core will have to keep track of the devices it
> automatically runtime resumed and decide to runtime suspend them too?
> Hmm, where would that go?

No, devices without a driver just need to become runtime PM enabled.
They will only be resumed when a dependent device (e.g. a child) is resumed,
and are suspended again after all dependents are suspended. That's how
simple-pm-bus behaves.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] Support qcom GDSC hardware

[Ivan T. Ivanov]

On Tue, 2014-04-15 at 10:56 -0700, Stephen Boyd wrote:
> On 04/04/14 11:45, Stephen Boyd wrote:
> > These patches add support for the multimedia GDSCs on the
> > apq8074 dragonboard. The first two patches (and potentially the last)
> > should go through Mike's tree and the DTS patch should go through
> > the qcom tree. Patches are based on v3.14. The probe will conflict with
> > patches I sent to consolidate things. I'll rework these patches on top of
> > that if the gdsc.c file is acked/reviewed.
> 
> Any comments?
> 

Hi,

It will nice if we can progress on this. They are several drivers posted 
already which depends on these regulators, USB3.0 and PCIe, at least.

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

Re: rfc: remove early_printk from a few arches? (blackfin, m68k, mips)

[Geert Uytterhoeven]

On Wed, Dec 17, 2014 at 9:58 PM, Joe Perches  wrote:
> It seems like early_printk can be configured into
> a few architectures but also appear not to be used.
>
> $ git grep -w "early_printk"

[...]

> arch/m68k/kernel/Makefile:obj-$(CONFIG_EARLY_PRINTK)+= early_printk.o

[...]

> These seem to the only uses:
>
> arch/arm/mach-socfpga/socfpga.c:early_printk("Early printk 
> initialized\n");
> []
> arch/microblaze/kernel/cpu/cpuinfo-pvr-full.c:  early_printk("ERROR: 
> Microblaze " x "-different for PVR and DTS\n");
> arch/microblaze/kernel/cpu/cpuinfo-static.c:early_printk("ERROR: 
> Microblaze " x "-different for kernel and DTS\n");
> []
> arch/tile/kernel/early_printk.c:early_printk("Kernel panic - not 
> syncing: %pV", &vaf);
> []
> arch/x86/kernel/e820.c: early_printk(msg);
> arch/x86/kernel/head64.c:   early_printk("Kernel alive\n");
> arch/x86/kernel/head_64.S:  call early_printk
> []
> kernel/events/core.c:   early_printk("perf interrupt took too long 
> (%lld > %lld), lowering "
>
> So blackfin, m68k, and mips seems to have it possible to enable,
> but also don't appear at first glance to use it,
>
> Is early_printk really used by these architectures?
> Should it be removed?

The m68k "early_printk" match is not about the early_printk()
function, but about
the early printk functionality. Hence nothing to remove there.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Latest kernel build problem in arch/x86/ia32/audit.c

[Cyrill Gorcunov]

On Thu, Dec 18, 2014 at 10:04:09PM +0300, Cyrill Gorcunov wrote:
>   case __NR_execveat:
>^
> arch/x86/ia32/audit.c:38:7: note: each undeclared identifier is reported only 
> once for each function it appears in
> make[2]: *** [arch/x86/ia32/audit.o] Error 1
> make[1]: *** [arch/x86/ia32] Error 2
> make: *** [arch/x86] Error 2
> make: *** Waiting for unfinished jobs

Looks like it was leftover from old builds. mrproper fixed it.
Sorry for noise.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH net-next v3 1/1] net: Support for switch port configuration

[Jiri Pirko]

Fri, Dec 19, 2014 at 01:35:10AM CET, tg...@suug.ch wrote:
>On 12/18/14 at 08:03am, John Fastabend wrote:
>> On 12/18/2014 07:30 AM, Varlese, Marco wrote:
>> Could you also document the attributes. I think they are mostly
>> clear but what is IFLA_SW_LOOPBACK. It will help later when we
>> try to read the code in 6months and implement drivers.
>> 
>> I am thinking something like
>> 
>> /* Switch Port Attributes section
>>  * IFLA_SW_LEARNING - turns learning on in the bridge
>>  * IFLA_SW_LOOPBACK - does something interesting
>> 
>>  [...]
>>  */
>
>+1. I would even ask for more than that. While clear in the bridge
>context, "learning" for this API targetting multi layer switches
>is ambigious. The expectation towards the driver must be crystical
>clear.
>
>> >+
>> >+enum {
>> >+   IFLA_SW_UNSPEC,
>> >+   IFLA_SW_LEARNING,
>> 
>> Can you address Roopa's feedback. I'm also a bit confused by the
>> duplication.
>
>Agreed. Can we decide on the ndo first and then build the APIs on
>top of that? While I agree that we should have a non-bridge based
>Netlink API, the underlying ndo should be the same.

Maybe we can use this kind of ndos (proposed by this patch) and call it
for switchdevs instead of bridge_get/setlink. Would make sense to me.
single set of ndos, many possible users (userspace/in-kernel).
bridge_get/setlink would be just a wrapper for this.

>
>> >+static const struct nla_policy ifla_sw_attr_policy[IFLA_SW_ATTR_MAX+1] = {
>> >+   [IFLA_SW_LEARNING]  = { .type = NLA_U64 },
>> >+   [IFLA_SW_LOOPBACK]  = { .type = NLA_U64 },
>> >+   [IFLA_SW_BCAST_FLOODING] = { .type = NLA_U64 },
>> >+   [IFLA_SW_UCAST_FLOODING] = { .type = NLA_U64 },
>> >+   [IFLA_SW_MCAST_FLOODING] = { .type = NLA_U64 },
>> >+};
>> 
>> Why U64 values? What would we pass in these? Are these just boolean
>> bits? Maybe the annotation above will help me understand this.
>
>I think the intent is to keep the ndo API as simple as possible
>but I agree that this is wasteful. I gave this feedback on v2 already.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] PM: Eliminate CONFIG_PM_RUNTIME

[Geert Uytterhoeven]

On Fri, Dec 19, 2014 at 3:03 AM, Rafael J. Wysocki  wrote:
> --- linux-pm.orig/arch/mips/configs/lemote2f_defconfig
> +++ linux-pm/arch/mips/configs/lemote2f_defconfig
> @@ -37,7 +37,7 @@ CONFIG_MIPS32_N32=y
>  CONFIG_PM=y
  ^^^
>  CONFIG_HIBERNATION=y
>  CONFIG_PM_STD_PARTITION="/dev/hda3"
> -CONFIG_PM_RUNTIME=y
> +CONFIG_PM=y
   ^^^
Now we have two of them

>  CONFIG_CPU_FREQ=y
>  CONFIG_CPU_FREQ_DEBUG=y
>  CONFIG_CPU_FREQ_STAT=m

Other defconfig files may be affected, too.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[Jiri Pirko]

Thu, Dec 18, 2014 at 11:43:06PM CET, ronen.a...@intel.com wrote:
>
>
>>-Original Message-
>>From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
>>Behalf Of John Fastabend
>>Sent: Thursday, December 18, 2014 9:21 PM
>>To: Roopa Prabhu; Varlese, Marco
>>Cc: net...@vger.kernel.org; Thomas Graf; Jiri Pirko; sfel...@gmail.com; linux-
>>ker...@vger.kernel.org
>>Subject: Re: [RFC PATCH net-next v2 1/1] net: Support for switch port
>>configuration
>>
>>On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
>>> On 12/18/14, 10:02 AM, Varlese, Marco wrote:
 Removed unnecessary content for ease of reading...

>> +/* Switch Port Attributes section */
>> +
>> +enum {
>> +IFLA_ATTR_UNSPEC,
>> +IFLA_ATTR_LEARNING,
> Any reason you want learning here ?. This is covered as part  of
> the bridge setlink attributes.
>
 Yes, because the user may _not_ want to go through a bridge
 interface
>>> necessarily.
>>> But, the bridge setlink/getlink interface was changed to accommodate
> 'self'
>>> for exactly such cases.
>>> I kind of understand your case for the other attributes (these are
>>> per port settings that switch asics provide).
>>>
>>> However, i don't understand the reason to pull in bridge attributes
>>here.
>>>
>> Maybe, I am missing something so you might help. The learning attribute -
> in my case - it is like all other attributes: a port attribute (as you
>>said, port
> settings that the switch provides per port).
>> So, what I was saying is "why the user shall go through a bridge to
>>configure
> the learning attribute"? From my perspective, it is as any other attribute
>>and
> as such configurable on the port.
>
> Thinking about this some more, i don't see why any of these attributes
> (except loopback. I dont understand the loopback attribute) cant be part
>>of
> the birdge port attributes.
>
> With this we will end up adding l2 attributes in two places: the general
>>link
> attributes and bridge attributes.
>
> And since we have gone down the path of using ndo_bridge_setlink/getlink
> with 'self'we should stick to that for all l2 attributes.
>
> The idea of overloading ndo_bridge_set/getlink, was to have the same set
>>of
> attributes but support both cases where the user wants to go through the
> bridge driver or directly to the switch port driver. So, you are not
>>really going
> through the bridge driver if you use 'self' and
>>ndo_bridge_setlink/getlink.
>
>>
 Roopa, one of the comments I got from Thomas Graf on my v1 patch
 was that your patch and mine were supplementary ("I think Roopa's
 patches are supplementary. Not all switchdev users will be backed
 with a Linux Bridge. I therefore welcome your patches very
 much")... I also understood by others that the patch made sense for
 the same reason. I simply do not understand why these attributes
 (and maybe others in the future) could not be configured directly
 on a standard port but have to go through a bridge.

>>> ok, i am very confused in that case. The whole moving of bridge
>>> attributes from the bridge driver to rtnetlink.c was to make the
>>> bridge attributes accessible to any driver who wants to set l2/bridge
>>> attributes on their switch ports. So, its unclear to me why we are
>>> doing this parallel thing again. This move to rtnetlink.c was done
>>> during the recent rocker support. so, maybe scott/jiri can elaborate
>>> more.
>>
>>
>>Not sure if this will add to the confusion or help. But you do not
>>need to have the bridge.ko loaded or netdev's attached to a bridge
>>to use the setlink/getlink ndo ops and netlink messages.
>
>No you don't need bridge.ko to implement ndo_bridge_setlink/getlink. Rtnetlink 
>invokes those ndos from code which does not depend on CONFIG_BRIDGE or the 
>presence of bridge.ko.
>Calling some bridge exported functions such as br_fdb_external_learn_add/del 
>requires the presence of bridge.ko and it only makes sense when the switch 
>port device is enslaved to a bridge.

Note I plan to change br_fdb_external_learn_add/del to (semi-)generic
notifier very soon.


>
>>
>>This was intentionally done. Its already used with NIC devices to
>>configure embedded bridge settings such as VEB/VEPA.
>>
>>I think I'm just repeating Roopa though.
>>
>>--
>>To unsubscribe from this list: send the line "unsubscribe netdev" 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 2/2] leds: add Qualcomm PM8941 WLED driver

[Ivan T. Ivanov]

On Thu, 2014-12-18 at 15:43 -0800, Bjorn wrote:
> On Tue 16 Dec 16:54 PST 2014, Bryan Wu wrote:
> 
> > On Mon, Dec 8, 2014 at 4:22 PM, Bjorn Andersson
> 
> [..]
> 
> > > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> 
> [..]
> 
> > > +config LEDS_PM8941_WLED
> > > +   tristate "LED support for the Qualcomm PM8941 WLED block"
> > > +   depends on LEDS_CLASS
> > > +   depends on REGMAP
> > Here should be "select REGMAP"
> > 
> 
> Thanks
> > > 


If not mistaken the correct way was:

depends on SPMI
select REGMAP_SPMI

or
depends on MFD_SPMI_PMIC

Regards,
Ivan

https://patchwork.kernel.org/patch/4566591/

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

[vireshk:cpufreq/stats/cleanups 12/14] drivers/cpufreq/cpufreq_stats.c:19:1: sparse: symbol 'cpufreq_stats_lock' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.linaro.org/people/vireshk/linux cpufreq/stats/cleanups
head:   f6439741b76da59257758838e8b24472831e850c
commit: 2194c3c381af6cbfe8ab4fda481e07a004446e30 [12/14] cpufreq: stats: 
replace spinlock with mutex
reproduce:
  # apt-get install sparse
  git checkout 2194c3c381af6cbfe8ab4fda481e07a004446e30
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/cpufreq/cpufreq_stats.c:19:1: sparse: symbol 'cpufreq_stats_lock' 
>> was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 vireshk] cpufreq: stats: cpufreq_stats_lock can be static

[kbuild test robot]

drivers/cpufreq/cpufreq_stats.c:19:1: sparse: symbol 'cpufreq_stats_lock' was 
not declared. Should it be static?

Signed-off-by: Fengguang Wu 
---
 cpufreq_stats.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index d333659..de55ca8 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 
-DEFINE_MUTEX(cpufreq_stats_lock);
+static DEFINE_MUTEX(cpufreq_stats_lock);
 
 struct cpufreq_stats {
unsigned int total_trans;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ALSA: atmel: fix building the ac97 driver for at91-multiplatform

[Alexander Stein]

Hi Alexandre,

Am Freitag 19 Dezember 2014, 00:13:10 schrieb Alexandre Belloni:
> From: Arnd Bergmann 
> 
> at91 will no longer export the mach/cpu.h and mach/hardware.h header files
> in the future, which would break building the atmel ac97c driver.
> 
> Since the cpu_is_* check is only used to find out whether we are running
> on avr32 or arm/at91, we can hardcode that check in the ARM case.
> 
> Unfortunately the driver is missing other work to be useful again on ARM,
> if anyone wants to actually use it, they need to add a DT binding, and
> the driver should really be converted to use the ASoC framework.

I recently send 3 patches to make DT working with this driver, you were on CC 
:). Please refer to http://comments.gmane.org/gmane.linux.alsa.devel/131686
I wonder though why all 3 are listed there although they were sent to different 
lists.

Best regards,
Alexander

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [vireshk:cpufreq/stats/cleanups 12/14] drivers/cpufreq/cpufreq_stats.c:19:1: sparse: symbol 'cpufreq_stats_lock' was not declared. Should it be static?

[Viresh Kumar]

On 19 December 2014 at 13:47, kbuild test robot  wrote:
> tree:   https://git.linaro.org/people/vireshk/linux cpufreq/stats/cleanups
> head:   f6439741b76da59257758838e8b24472831e850c
> commit: 2194c3c381af6cbfe8ab4fda481e07a004446e30 [12/14] cpufreq: stats: 
> replace spinlock with mutex
> reproduce:
>   # apt-get install sparse
>   git checkout 2194c3c381af6cbfe8ab4fda481e07a004446e30
>   make ARCH=x86_64 allmodconfig
>   make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones prefixed by >>)
>
>>> drivers/cpufreq/cpufreq_stats.c:19:1: sparse: symbol 'cpufreq_stats_lock' 
>>> was not declared. Should it be static?
>
> Please review and possibly fold the followup patch.

Thanks fixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 02/10] power: charger-manager: Use power_supply_changed() not private uevent.

[jonghwa3 . lee]

On 2014년 12월 19일 16:41, MyungJoo Ham wrote:

>>   
>>  Whenever battery status is changed, charger manager tries to trigger uevent
>> through private interface. This patch modifies it to use 
>> power_supply_changed()
>> since it belongs to power supply subsystem.
>>
>> Signed-off-by: Jonghwa Lee 
> 
> The original uevent_notify() has two additional mechanisms:
> C1. Save events in suspend-again context and show them up at wakeup.
> C2. If the new event is a duplicated event, ignore it.
> 
> Questions:
> Q1. Have you checked if C1 is met with the modification? Besides, have
> you made it sure that the modification won't change the behavior of
> suspend-again context? (whether "theoretical" or "experimental")


It won't ruin suspend-again context because it just changes the location where
the charger manager's notice to go.

> Q2. Do you still support C2?
>   For example, if we have notifited the user that we are charging
>   30 seconds ago, we should never bother the user with another message
>   that declares that it is charging unless we have notified that
>   we are not charging since then.
> 


Above case never happens. If charging state is not changed, the report will not
be triggered. Maybe current driver will send same event repeatedly even though,
these patch series will guarantee not to do so.

And also if we have a status changing while short time wake-up which expects
suspend-again proceeds in near future, I think it is better to notify it to the
user not to keep until undetermined 'TRUE' wake-up.

Thanks,
Jonghwa

> Cheers,
> MyungJoo.
> 
>> ---
>>  drivers/power/charger-manager.c |   91 
>> +--
>>  1 file changed, 11 insertions(+), 80 deletions(-)
>>
> N�r��y���b�X��ǧv�^�)޺{.n�+{��h����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?&�)ߢfl===


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1] ARM: dts: dra7-evm: fix qspi device tree partition size

[Mugunthan V N]

64KiB is allocated for qspi dtb partition which is not
sufficient, so updating the partition table size to 512KiB
for device tree partition.

This also aligns the QSPI partition definitions between
kernel and U-Boot.

Fixes: dc2dd5b8 ("ARM: dts: dra7: Add qspi device")

Signed-off-by: Mugunthan V N 
---

This patch is tested on Linux next and the boot logs at [1]

[1] - http://pastebin.ubuntu.com/9567672/

---
 arch/arm/boot/dts/dra7-evm.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 736092b..235d001 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -499,23 +499,23 @@
};
partition@5 {
label = "QSPI.u-boot-spl-os";
-   reg = <0x0014 0x0001>;
+   reg = <0x0014 0x0008>;
};
partition@6 {
label = "QSPI.u-boot-env";
-   reg = <0x0015 0x0001>;
+   reg = <0x001c 0x0001>;
};
partition@7 {
label = "QSPI.u-boot-env.backup1";
-   reg = <0x0016 0x001>;
+   reg = <0x001d 0x001>;
};
partition@8 {
label = "QSPI.kernel";
-   reg = <0x0017 0x080>;
+   reg = <0x001e 0x080>;
};
partition@9 {
label = "QSPI.file-system";
-   reg = <0x0097 0x0169>;
+   reg = <0x009e 0x0162>;
};
};
 };
-- 
2.2.1.62.g3f15098

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

Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[Jiri Pirko]

Fri, Dec 19, 2014 at 12:48:28AM CET, ro...@cumulusnetworks.com wrote:
>On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
>>
>>On 12/18/2014 3:07 PM, Roopa Prabhu wrote:
>>>On 12/18/14, 11:21 AM, John Fastabend wrote:
On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
>On 12/18/14, 10:02 AM, Varlese, Marco wrote:
>>Removed unnecessary content for ease of reading...
>>
+/* Switch Port Attributes section */
+
+enum {
+IFLA_ATTR_UNSPEC,
+IFLA_ATTR_LEARNING,
>>>Any reason you want learning here ?. This is covered as part  of
>>>the bridge setlink attributes.
>>>
>>Yes, because the user may _not_ want to go through a bridge
>>interface
>necessarily.
>But, the bridge setlink/getlink interface was changed to
>accommodate
>>>'self'
>for exactly such cases.
>I kind of understand your case for the other attributes (these are
>per port settings that switch asics provide).
>
>However, i don't understand the reason to pull in bridge
>attributes here.
>
Maybe, I am missing something so you might help. The learning
attribute -
>>>in my case - it is like all other attributes: a port attribute
>>>(as you said, port
>>>settings that the switch provides per port).
So, what I was saying is "why the user shall go through a
bridge to configure
>>>the learning attribute"? From my perspective, it is as any other
>>>attribute and
>>>as such configurable on the port.
>>>
>>>Thinking about this some more, i don't see why any of these
>>>attributes
>>>(except loopback. I dont understand the loopback attribute) cant
>>>be part of
>>>the birdge port attributes.
>>>
>>>With this we will end up adding l2 attributes in two places: the
>>>general link
>>>attributes and bridge attributes.
>>>
>>>And since we have gone down the path of using
>>>ndo_bridge_setlink/getlink
>>>with 'self'we should stick to that for all l2 attributes.
>>>
>>>The idea of overloading ndo_bridge_set/getlink, was to have the
>>>same set of
>>>attributes but support both cases where the user wants to go
>>>through the
>>>bridge driver or directly to the switch port driver. So, you are
>>>not really going
>>>through the bridge driver if you use 'self' and
>>>ndo_bridge_setlink/getlink.
>>>
>>Roopa, one of the comments I got from Thomas Graf on my v1 patch
>>was that your patch and mine were supplementary ("I think Roopa's
>>patches are supplementary. Not all switchdev users will be backed
>>with a Linux Bridge. I therefore welcome your patches very
>>much")... I also understood by others that the patch made sense for
>>the same reason. I simply do not understand why these attributes
>>(and maybe others in the future) could not be configured directly
>>on a standard port but have to go through a bridge.
>>
>ok, i am very confused in that case. The whole moving of bridge
>attributes from the bridge driver to rtnetlink.c was to make the
>bridge attributes accessible to any driver who wants to set l2/bridge
>attributes on their switch ports. So, its unclear to me why we are
>doing this parallel thing again. This move to rtnetlink.c was done
>during the recent rocker support. so, maybe scott/jiri can elaborate
>more.

Not sure if this will add to the confusion or help. But you do not
need to have the bridge.ko loaded or netdev's attached to a bridge
to use the setlink/getlink ndo ops and netlink messages.

This was intentionally done. Its already used with NIC devices to
configure embedded bridge settings such as VEB/VEPA.
>>>
>>>that helps my case, thanks.
>>
>>So the user interface to set/get the per-port attributes will be via
>>'bridge', not 'ip'
>>
>>bridge link set dev sw0p1 port_attr bcast_flooding 1 self
>>bridge link get dev sw0p1 port_attr bcast_flooding self
>
>yes, l2 attributes.
>>
>>We also need an interface to set per-switch attributes. Can this work?
>>bridge link set dev sw0 sw_attr bcast_flooding 1 master
>>where sw0 is a bridge representing the hardware switch.

How can a bridge represent the hardware switch? What if you have 2 bridge
on ports of the same hardware switch. Or what if you have a bridge with
couple of ports from one hardware switch and couple of ports from second
hardware switch. Or else, you can have a misxture of switch ports and
other devices (taps for example). Bridge->hardware switch does not map
1:1.

If you want to set any per switch attributes, just use one of the ports
as a "gateway". port->hardware switch mapping is strict, so you should
be okay doing that. There are no ndos for this purpose at the moment,
but they can be easily added.

>
>Not today. We discussed this @ LPC, and on

Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[Jiri Pirko]

Fri, Dec 19, 2014 at 06:14:57AM CET, marichi...@gmail.com wrote:
>On 19 December 2014 at 05:18, Roopa Prabhu  wrote:
>> On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
>>>
>>>
>>> On 12/18/2014 3:07 PM, Roopa Prabhu wrote:

 On 12/18/14, 11:21 AM, John Fastabend wrote:
>
> On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
>>
>> On 12/18/14, 10:02 AM, Varlese, Marco wrote:
>>>
>>> Removed unnecessary content for ease of reading...
>>>
> +/* Switch Port Attributes section */
> +
> +enum {
> +IFLA_ATTR_UNSPEC,
> +IFLA_ATTR_LEARNING,

 Any reason you want learning here ?. This is covered as part  of
 the bridge setlink attributes.

>>> Yes, because the user may _not_ want to go through a bridge
>>> interface
>>
>> necessarily.
>> But, the bridge setlink/getlink interface was changed to
>> accommodate

 'self'
>>
>> for exactly such cases.
>> I kind of understand your case for the other attributes (these are
>> per port settings that switch asics provide).
>>
>> However, i don't understand the reason to pull in bridge attributes
>> here.
>>
> Maybe, I am missing something so you might help. The learning
> attribute -

 in my case - it is like all other attributes: a port attribute (as
 you said, port
 settings that the switch provides per port).
>
> So, what I was saying is "why the user shall go through a bridge to
> configure

 the learning attribute"? From my perspective, it is as any other
 attribute and
 as such configurable on the port.

 Thinking about this some more, i don't see why any of these
 attributes
 (except loopback. I dont understand the loopback attribute) cant be
 part of
 the birdge port attributes.

 With this we will end up adding l2 attributes in two places: the
 general link
 attributes and bridge attributes.

 And since we have gone down the path of using
 ndo_bridge_setlink/getlink
 with 'self'we should stick to that for all l2 attributes.

 The idea of overloading ndo_bridge_set/getlink, was to have the same
 set of
 attributes but support both cases where the user wants to go through
 the
 bridge driver or directly to the switch port driver. So, you are not
 really going
 through the bridge driver if you use 'self' and
 ndo_bridge_setlink/getlink.

>>> Roopa, one of the comments I got from Thomas Graf on my v1 patch
>>> was that your patch and mine were supplementary ("I think Roopa's
>>> patches are supplementary. Not all switchdev users will be backed
>>> with a Linux Bridge. I therefore welcome your patches very
>>> much")... I also understood by others that the patch made sense for
>>> the same reason. I simply do not understand why these attributes
>>> (and maybe others in the future) could not be configured directly
>>> on a standard port but have to go through a bridge.
>>>
>> ok, i am very confused in that case. The whole moving of bridge
>> attributes from the bridge driver to rtnetlink.c was to make the
>> bridge attributes accessible to any driver who wants to set l2/bridge
>> attributes on their switch ports. So, its unclear to me why we are
>> doing this parallel thing again. This move to rtnetlink.c was done
>> during the recent rocker support. so, maybe scott/jiri can elaborate
>> more.
>
>
> Not sure if this will add to the confusion or help. But you do not
> need to have the bridge.ko loaded or netdev's attached to a bridge
> to use the setlink/getlink ndo ops and netlink messages.
>
> This was intentionally done. Its already used with NIC devices to
> configure embedded bridge settings such as VEB/VEPA.


 that helps my case, thanks.
>>>
>>>
>>> So the user interface to set/get the per-port attributes will be via
>>> 'bridge', not 'ip'
>>>
>>> bridge link set dev sw0p1 port_attr bcast_flooding 1 self
>>> bridge link get dev sw0p1 port_attr bcast_flooding self
>>
>>
>> yes, l2 attributes.
>>>
>>>
>>> We also need an interface to set per-switch attributes. Can this work?
>>> bridge link set dev sw0 sw_attr bcast_flooding 1 master
>>> where sw0 is a bridge representing the hardware switch.
>>
>>
>> Not today. We discussed this @ LPC, and one way to do this would be to have
>> a device
>> representing the switch asic. This is in the works.
>
>
>Can I assume that on  platforms which house more than one asic (say
>two 24 port asics, interconnected via a 10G link or equivalent, to get
>a 48 

Re: sched: odd values for effective load calculations

[Yuyang Du]

On Tue, Dec 16, 2014 at 10:09:48AM +0800, Yuyang Du wrote:
> 
> Sasha, it might be helpful to see this_load is from:
> 
> this_load1: this_load = target_load(this_cpu, idx);
> 
> or
> 
> this_load2: this_load += effective_load(tg, this_cpu, -weight, -weight);
> 
> It really does not seem to be this_load1, while the calc of effective_load is 
> a bit
> complicated to see what the problem is.

Hi all,

I finally managed to reproduce this, but not by trinity, just by keeping 
rebooting.

Indeed, the problem is from:

this_load2: this_load += effective_load(tg, this_cpu, -weight, -weight);

After digging into effective_load(), the root cause is:

wl = (w * tg->shares) / W;

if we have negative w, then it will be cast to unsigned long, and then may or 
may not
overflow, and end up an insane number.

I tried this in userspace, interestingly if we have:

wl = w * tg->shares;
wl /= W;

the result is ok, but not ok with the lines combined as the original one.

Anyway, the following patch can fix this.

---
Subject: [PATCH] sched: Fix long and unsigned long multiplication error in
 effective_load

In effective_load, we have (long w * unsigned long tg->shares) / long W,
when w is negative, it is cast to unsigned long and hence the product is
insanely large. Fix this by casting tg->shares to long.

Reported-by: Sasha Levin 
Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index df2cdf7..6b99659 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4424,7 +4424,7 @@ static long effective_load(struct task_group *tg, int 
cpu, long wl, long wg)
 * wl = S * s'_i; see (2)
 */
if (W > 0 && w < W)
-   wl = (w * tg->shares) / W;
+   wl = (w * (long)tg->shares) / W;
else
wl = tg->shares;
 
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 03/10] power: charger-manager: Remove deprecated function, cm_notify_event().

[jonghwa3 . lee]

On 2014년 12월 19일 16:52, MyungJoo Ham wrote:

>>   
>>  cm_notify_event() is introduced to get event associated with battery status
>> externally, but no one had been used. Moreover it makes charger manager
>> driver more complicated. This patch tries to drop the function and all data
>> related to simplify the driver.
>>
>> Signed-off-by: Jonghwa Lee 
> 
> You are not just removing cm_notify_event() and its related.
> 
> You are hereby removing the much of software charger control
> and suspend-related operations. Could you please be more specific
> on why? (many of such features are to comply with operators' requirements)
> 


Unfortunately, all those codes are only for cm_notify_event(). Currently, and
since charger-manager has been introduced then, there's no one to use it. And
the works of cm_notify_event() are is just notifying the event to user space or
reset the polling work. We may need passive method to get event related with
battery status externally, if so we can use power_supply class notification
method, power_supply_notifier.

I decided to remove it to make driver simple and clean.

Thanks,
Jonghwa


> (Or we may meet next Monday for some discussions :) )
> 
>> ---
>>  .../bindings/power_supply/charger-manager.txt  |1 -
>>  drivers/power/charger-manager.c|  196 
>> +---
>>  include/linux/power/charger-manager.h  |   19 +-
>>  3 files changed, 8 insertions(+), 208 deletions(-)
>>


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

Re: [PATCH RESEND V2 0/10] Improve charger manager driver for optimized operation.

[jonghwa3 . lee]

On 2014년 12월 19일 11:47, Jonghwa Lee wrote:

> After charger manager's initially introduced, it has kept its codes without 
> any
> big change. However, the charger manager working operation isn't optimized and
> it also has unused codes and non-generic interface. This series tries to make
> charger manager more generic and maintainable with some fixes.
> 
> [Changes in V2]
> - Rebase patch series on latest of battery-2.6.git.
> - Seperate 'power: charger-manager: Rearrange data and monitor ~' patch into
>   several patches depends on its purpose.
> - Add 2 patches related with polling mode.
> 
> Jonghwa Lee (10):
>   power: charger-manager: Use thermal subsystem interface only to get
> temperature.
>   power: charger-manager: Use power_supply_changed() not private
> uevent.
>   power: charger-manager: Remove deprecated function,
> cm_notify_event().
>   power: charger-manager: Fix to use CHARGE_NOW/FULL property
> correctly.
>   power: charger-manager: Concentrate scattered power_supply_changed()
> calls.
>   power: charger-manager: Get external power souce information only
> from EXTCON.
>   power: charger-manager: Make chraging decision focusing on battery
> status.
>   power: charger-manager: Not to start charging directly in cable
> nofitication.
>   power: charger-manager: Support different polling mode for sleep
> state.
>   power: charger-manager: Support to change polling rate in runtime.
> 
>  .../bindings/power_supply/charger-manager.txt  |1 -
>  drivers/power/Kconfig  |1 +
>  drivers/power/charger-manager.c|  758 
> ++--
>  include/linux/power/charger-manager.h  |   34 +-
>  4 files changed, 219 insertions(+), 575 deletions(-)



Oops, I omitted a patch from series,
I'll resend it again.

Sorry for noise.

Thanks,
Jonghwa

> 


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

linux-next: Tree for Dec 19

[Stephen Rothwell]

Hi all,

Please do not add any code destined for v3.20 to your linux-next included
trees/branches until after v3.19-rc1 is released.

There will only be intermittent releases of linux-next between now and
Jan 5.

Changes since 20141218:

The modules tree lost its build failure.

Non-merge commits (relative to Linus' tree): 762
 943 files changed, 26140 insertions(+), 8948 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (00c845dbfe2e Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (f114040e3ea6 Linux 3.18-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (3f4aa45ceea5 ARM: 8226/1: cacheflush: get rid of 
restarting block)
Merging m68k-current/for-linus (f0b99a643e96 m68k/mm: Eliminate memset after 
alloc_bootmem_pages)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused 
force_32bit_msi quirk)
Merging powerpc-merge-mpe/fixes (b2776bf7149b Linux 3.18)
Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() 
needs to disable interrupts.)
Merging net/master (86c8fc4bbe14 Merge tag 'mac80211-for-davem-2014-12-18' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging ipsec/master (f855691975bb xfrm6: Fix the nexthdr offset in 
_decode_session6.)
Merging sound-current/for-linus (d70a1b9893f8 ALSA: usb-audio: extend KEF X300A 
FU 10 tweak to Arcam rPAC)
Merging pci-current/for-linus (5106787a9e08 PCI: tegra: Use physical range for 
I/O mapping)
Merging wireless/master (9a1dce3a0591 rtlwifi: rtl8192ce: Set fw_ready flag)
Merging driver-core.current/driver-core-linus (2dbfca5a1819 Merge branch 
'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds)
Merging tty.current/tty-linus (2dbfca5a1819 Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds)
Merging usb.current/usb-linus (2dbfca5a1819 Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds)
Merging usb-gadget-fixes/fixes (520fe7633692 usb: dwc3: ep0: fix for dead code)
Merging usb-serial-fixes/usb-linus (009d0431c391 Linux 3.18-rc7)
Merging staging.current/staging-linus (2dbfca5a1819 Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds)
Merging char-misc.current/char-misc-linus (67e2c3883828 Merge branch 'next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging input-current/for-linus (6d32af019a45 Merge branch 'next' into 
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (8606813a6c89 crypto: tcrypt - Allow speed 
testing of arbitrary hash functions)
Merging ide/master (f96fe225677b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (094cb98179f1 of/fdt: 
memblock_reserve /memreserve/ regions in the case of partial overlap)
Merging rr-fixes/fixes (3438cf549d2f param: fix crash on bad kernel arguments)
Me

Re: randconfig build error with next-20141204, in drivers/pwm

[Thierry Reding]

On Thu, Dec 18, 2014 at 08:51:32PM +0100, Boris Brezillon wrote:
> Hi Thierry,
> 
> On Thu, 18 Dec 2014 10:44:44 +0100
> Thierry Reding  wrote:
> 
> > On Thu, Dec 04, 2014 at 09:10:55AM -0700, Jim Davis wrote:
> > > Building with the attached random configuration file,
> > > 
> > > ERROR: "ilog2_NaN" [drivers/pwm/pwm-atmel-hlcdc.ko] undefined!  
> > 
> > This took a while to figure out. The attached patch fixes this build
> > failure, though the driver should probably be fixed to avoid division by
> > zero, just in case. Adding Boris for visibility.
> 
> Thanks for fixing this build issue. I'll propose a patch to prevent
> this div by 0 from happening.
> 
> > 
> > Thierry
> > 
> > From 7933af1d2e5f3941d934eec88f32f5547ee218c3 Mon Sep 17 00:00:00 2001
> > From: Thierry Reding 
> > Date: Thu, 18 Dec 2014 10:09:42 +0100
> > Subject: [PATCH] pwm: atmel-hlcdc: Depend on HAVE_CLK
> > 
> > The include/linux/clk.h header defines dummy implementations for the
> > various clk_*() functions if HAVE_CLK is not selected to improve build
> > coverage in randconfig builds.
> > 
> > The dummy implementation of clk_get_rate() returns 0, which causes the
> > Atmel HLCDC PWM driver's atmel_hlcdc_pwm_config() implementation to end
> > up calling:
> > 
> > do_div(clk_period_ns, 0)
> > 
> > On x86, do_div(n, base) will end up evaluating to this:
> > 
> > n >>= ilog2(base)
> > 
> > with base = 0, the implementation of ilog2() will call ilog2_NaN(),
> > which is purposely undefined and results in a linker failure:
> > 
> > ERROR: "ilog2_NaN" [drivers/pwm/pwm-atmel-hlcdc.ko] undefined!
> > 
> > The implementation of do_div() checks that base is a power of 2 before
> > calling ilog2(). The compiler doesn't optimize this away, presumably
> > because is_power_of_2() is an inline function and the compiler doesn't
> > or can't inspect it closely enough. ilog2() being a macro it still ends
> > up generating the ilog2_NaN() because of the constant 0.
> > 
> > The root of the problem is that the driver really should be checking
> > before possibly dividing by zero. That should eventually be fixed, but
> > for now just assume that the clock runs at a sensible frequency when
> > available.
> > 
> > Reported-by: Jim Davis 
> > Signed-off-by: Thierry Reding 
> 
> Acked-by: Boris Brezillon 

Applied, thanks.

Thierry


pgp0ij135C5v_.pgp
Description: PGP signature

Re: [PATCH] pwm: atmel-hlcdc: Prevent div by zero

[Thierry Reding]

On Thu, Dec 18, 2014 at 09:05:30PM +0100, Boris Brezillon wrote:
> The slow and system clock should never return a rate of zero, but this
> might happen if the clocks property defined in the DT is referencing the
> wrong clocks.
> Prevent any division by zero from happening by testing the clk_freq value
> before calling do_div.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/pwm/pwm-atmel-hlcdc.c | 6 ++
>  1 file changed, 6 insertions(+)

Applied, thanks.

Thierry


pgpcx1en4pkRQ.pgp
Description: PGP signature

Re: [PATCH v6 4/4] staging: fpga manager: add driver for socfpga fpga manager

[Steffen Trumtrar]

Hi!

Just a minor nitpick, but...

On Thu, Dec 18, 2014 at 04:29:08PM -0600, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> Add driver to fpga manager framework to allow configuration
> of FPGA in Altera SoCFPGA parts.
> 
> Signed-off-by: Alan Tull 
> Acked-by: Michal Simek 
> ---
> v2: fpga_manager struct now contains struct device
> fpga_manager_register parameters now take device
> 
> v3: skip a version to align versions
> 
> v4: move to drivers/staging
> 
> v5: fix array_size.cocci warnings
> fix platform_no_drv_owner.cocci warnings
> Remove .owner = THIS_MODULE
> include asm/irq.h
> clean up list of includes
> use altera_fpga_reset for ops
> use enum fpga_mgr_states or u32 as needed
> use devm_request_irq
> check irq <= 0 instead of == NO_IRQ
> Use ARRAY_SIZE
> rename altera -> socfpga
> static const socfpga_fpga_ops
> header moved to linux/fpga/ folder
> remove ifdef'ed code
> use platform_get_resource and platform_get_irq
> move .probe and .remove lines adjacent
> use module_platform_driver
> use __maybe_unused
> only need to 'if (IS_ENABLED(CONFIG_REGULATOR))' in one fn
> fix "unsigned 'mode' is never < 0"
> 
> v6: return error for (unused) default of case statement
> ---
  ^^^

...if you remove these, than that changelog will not land in the final
commit which I would prefer. Nobody cares for the changelog of a
patch once it is in its final state. And this is a rather noisy one.
When someone in the future looks at this, he will see two lines of
information and 10 times that of uninteresting noise.

Not a dealbreaker, but just something to consider for future patches.

> +
> +static u32 socfpga_fpga_readl(struct socfpga_fpga_priv *priv, u32 reg_offset)
> +{
> + return readl(priv->fpga_base_addr + reg_offset);
> +}
> +
> +static void socfpga_fpga_writel(struct socfpga_fpga_priv *priv, u32 
> reg_offset,
> + u32 value)
> +{
> + writel(value, priv->fpga_base_addr + reg_offset);
> +}
> +
> +static u32 socfpga_fpga_raw_readl(struct socfpga_fpga_priv *priv,
> +   u32 reg_offset)
> +{
> + return __raw_readl(priv->fpga_base_addr + reg_offset);
> +}
> +
> +static void socfpga_fpga_raw_writel(struct socfpga_fpga_priv *priv,
> + u32 reg_offset, u32 value)
> +{
> + __raw_writel(value, priv->fpga_base_addr + reg_offset);
> +}
> +
> +static void socfpga_fpga_data_writel(struct socfpga_fpga_priv *priv, u32 
> value)
> +{
> + writel(value, priv->fpga_data_addr);
> +}
> +
> +static inline void socfpga_fpga_set_bitsl(struct socfpga_fpga_priv *priv,
> +   u32 offset, u32 bits)
> +{
> + u32 val;
> +
> + val = socfpga_fpga_readl(priv, offset);
> + val |= bits;
> + socfpga_fpga_writel(priv, offset, val);
> +}
> +
> +static inline void socfpga_fpga_clr_bitsl(struct socfpga_fpga_priv *priv,
> +   u32 offset, u32 bits)
> +{
> + u32 val;
> +
> + val = socfpga_fpga_readl(priv, offset);
> + val &= ~bits;
> + socfpga_fpga_writel(priv, offset, val);
> +}
> +

Please, please, please at least fix this once the driver hit staging.
It is always a major annoyance, to follow functions, just to find out
that their only reason of existence is to flip the arguments just for the
hell of it. But I guess it is okay for staging...

Regards,
Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/11] power: charger-manager: Support to change polling rate in runtime.

[Jonghwa Lee]

Add 'polling_ms' sysfs node to change charger-manager's monitoring rate
in runtime. It can set only bigger than 2 jiffies (for 200 HZ system it
is 10 msecs.) as it's allowed for minimum poling rate in previous.
It resets poller and re-configure polling rate based on new input if next
polling time is far enough. Otherwise, it just waits expiration of timer
and new polling rate will affects the next scheduling.

Signed-off-by: Jonghwa Lee 
---
 drivers/power/charger-manager.c |   62 +++
 1 file changed, 62 insertions(+)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index f5787bc..a8cabf09 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -1054,6 +1054,63 @@ static ssize_t charger_externally_control_store(struct 
device *dev,
return count;
 }
 
+static ssize_t show_polling_ms(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct charger_manager *cm;
+   ssize_t len;
+
+   list_for_each_entry(cm, &cm_list, entry)
+   if (cm->charger_psy.dev == dev)
+   break;
+
+   if (cm->charger_psy.dev != dev)
+   return -EINVAL;
+
+   len = sprintf(buf, "%d\n", cm->desc->polling_interval_ms);
+
+   return len;
+}
+
+static ssize_t store_polling_ms(struct device *dev,
+   struct device_attribute *attr, const char *buf,
+   size_t count)
+{
+   struct charger_manager *cm;
+   int polling_ms;
+   int ret;
+
+   ret = sscanf(buf, "%d", &polling_ms);
+   if (ret < 0 )
+   return -EINVAL;
+
+   if (polling_ms < CM_JIFFIES_SMALL * MSEC_PER_SEC / HZ)
+   return -EINVAL;
+
+   list_for_each_entry(cm, &cm_list, entry)
+   if (cm->charger_psy.dev == dev)
+   break;
+
+   if (cm->charger_psy.dev != dev)
+   return -ENODEV;
+
+   cm->desc->polling_interval_ms = polling_ms;
+
+   pr_info("Polling interval's changed to %u ms.\n",
+   cm->desc->polling_interval_ms);
+
+   if (next_polling - jiffies >
+   msecs_to_jiffies(cm->desc->polling_interval_ms)) {
+   pr_info("Reset poller now... \n");
+   cancel_delayed_work(&cm_monitor_work);
+   schedule_work(&setup_polling);
+   }
+
+   return count;
+}
+
+static DEVICE_ATTR(polling_ms, 0644, show_polling_ms, store_polling_ms);
+
 /**
  * charger_manager_register_sysfs - Register sysfs entry for each charger
  * @cm: the Charger Manager representing the battery.
@@ -1077,6 +1134,11 @@ static int charger_manager_register_sysfs(struct 
charger_manager *cm)
int ret = 0;
int i;
 
+   /* Create polling_ms sysfs node */
+   ret = device_create_file(cm->charger_psy.dev, &dev_attr_polling_ms);
+   if (ret)
+   pr_err("Failed to create poling_ms sysfs node (%d)\n", ret);
+
/* Create sysfs entry to control charger(regulator) */
for (i = 0; i < desc->num_charger_regulators; i++) {
charger = &desc->charger_regulators[i];
-- 
1.7.9.5

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

[PATCH V3 10/11] power: charger-manager: Support different polling mode for sleep state.

[Jonghwa Lee]

Add additional polling mode for sleep state to define different mode with
normal state. With this change, charger-manager can work differently in
normal state or sleep state. e.g, polling aways for normal and polling
only when charing for sleep. If there is no defined polling mode for
sleep state it just follows the normal state's.
In addition to, polling rate is still same in sleep.

Signed-off-by: Jonghwa Lee 
---
 drivers/power/charger-manager.c   |   20 +---
 include/linux/power/charger-manager.h |9 ++---
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 4f8b0e6..f5787bc 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -291,7 +291,15 @@ static bool is_full_charged(struct charger_manager *cm)
  */
 static bool is_polling_required(struct charger_manager *cm)
 {
-   switch (cm->desc->polling_mode) {
+   enum polling_modes polling_mode;
+
+   if (cm_suspended
+   && cm->desc->poll_mode_sleep >= 0)
+   polling_mode = cm->desc->poll_mode_sleep;
+   else
+   polling_mode = cm->desc->poll_mode_normal;
+
+   switch (polling_mode) {
case CM_POLL_DISABLE:
return false;
case CM_POLL_ALWAYS:
@@ -302,7 +310,7 @@ static bool is_polling_required(struct charger_manager *cm)
return is_charging(cm);
default:
dev_warn(cm->dev, "Incorrect polling_mode (%d)\n",
-cm->desc->polling_mode);
+polling_mode);
}
 
return false;
@@ -1158,7 +1166,13 @@ static struct charger_desc *of_cm_parse_desc(struct 
device *dev)
of_property_read_string(np, "cm-name", &desc->psy_name);
 
of_property_read_u32(np, "cm-poll-mode", &poll_mode);
-   desc->polling_mode = poll_mode;
+   desc->poll_mode_normal = poll_mode;
+
+   /* Polling mode in sleep state */
+   if (!of_property_read_u32(np, "cm-poll-mode-sleep", &poll_mode))
+   desc->poll_mode_sleep = poll_mode;
+   else
+   desc->poll_mode_sleep = -EINVAL;
 
of_property_read_u32(np, "cm-poll-interval",
&desc->polling_interval_ms);
diff --git a/include/linux/power/charger-manager.h 
b/include/linux/power/charger-manager.h
index 37fb181..a30a0b6 100644
--- a/include/linux/power/charger-manager.h
+++ b/include/linux/power/charger-manager.h
@@ -131,8 +131,10 @@ struct charger_regulator {
 /**
  * struct charger_desc
  * @psy_name: the name of power-supply-class for charger manager
- * @polling_mode:
- * Determine which polling mode will be used
+ * @poll_mode_normal:
+ * Determine which polling mode will be used in normal state.
+ * @poll_mode_sleep:
+ * Determine which polling mode will be used in sleep state.
  * @fullbatt_vchkdrop_uV:
  * Check voltage drop after the battery is fully charged.
  * If it has dropped more than fullbatt_vchkdrop_uV
@@ -170,7 +172,8 @@ struct charger_regulator {
 struct charger_desc {
const char *psy_name;
 
-   enum polling_modes polling_mode;
+   enum polling_modes poll_mode_normal;
+   enum polling_modes poll_mode_sleep;
unsigned int polling_interval_ms;
 
unsigned int fullbatt_vchkdrop_uV;
-- 
1.7.9.5

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

[PATCH net-next 2/2] r8152: check the status before submitting rx

[Hayes Wang]

Don't submit the rx if the device is unplugged, linking down,
or stopped.

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

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 59b70c5..b39b2e4 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1789,6 +1789,11 @@ int r8152_submit_rx(struct r8152 *tp, struct rx_agg 
*agg, gfp_t mem_flags)
 {
int ret;
 
+   /* The rx would be stopped, so skip submitting */
+   if (test_bit(RTL8152_UNPLUG, &tp->flags) ||
+   !test_bit(WORK_ENABLE, &tp->flags) || !(tp->speed & LINK_STATUS))
+   return 0;
+
usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
  agg->head, agg_buf_sz,
  (usb_complete_t)read_bulk_callback, agg);
-- 
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/

[PATCH V3 07/11] power: charger-manager: Get external power souce information only from EXTCON.

[Jonghwa Lee]

When charger-manager checks whether external power source is available,
it gets information from charger IC driver. However, it's not correct source,
charger IC doesn't have responsibilty to give cable connection status.
The charger-manager already gets cable information from EXTCON susbsystem,
so it can re-use it.

Signed-off-by: Jonghwa Lee 
---
 drivers/power/charger-manager.c |   34 ++
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index d29155d..dc15436 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -115,34 +115,28 @@ static bool is_batt_present(struct charger_manager *cm)
  * is_ext_pwr_online - See if an external power source is attached to charge
  * @cm: the Charger Manager representing the battery.
  *
- * Returns true if at least one of the chargers of the battery has an external
- * power source attached to charge the battery regardless of whether it is
- * actually charging or not.
+ * Returns true if there is external power source.
+ * Cable connection information is only obtained by EXTCON class notification.
  */
 static bool is_ext_pwr_online(struct charger_manager *cm)
 {
-   union power_supply_propval val;
-   struct power_supply *psy;
-   bool online = false;
-   int i, ret;
 
-   /* If at least one of them has one, it's yes. */
-   for (i = 0; cm->desc->psy_charger_stat[i]; i++) {
-   psy = power_supply_get_by_name(cm->desc->psy_charger_stat[i]);
-   if (!psy) {
-   dev_err(cm->dev, "Cannot find power supply \"%s\"\n",
-   cm->desc->psy_charger_stat[i]);
-   continue;
-   }
+   struct charger_desc *desc = cm->desc;
+   struct charger_regulator *regulators = desc->charger_regulators;
+   struct charger_cable *cables;
+   int i, j, num_cables;
 
-   ret = psy->get_property(psy, POWER_SUPPLY_PROP_ONLINE, &val);
-   if (ret == 0 && val.intval) {
-   online = true;
-   break;
+   /* If at least one of them has one, it's yes. */
+   for (i = 0; i < desc->num_charger_regulators; i++) {
+   cables = regulators[i].cables;
+   num_cables = regulators[i].num_cables;
+   for (j = 0; j < num_cables; j++) {
+   if (cables[j].attached)
+   return true;
}
}
 
-   return online;
+   return false;
 }
 
 /**
-- 
1.7.9.5

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

[PATCH net-next 0/2] r8152: adjust r8152_submit_rx

[Hayes Wang]

Avoid r8152_submit_rx() from submitting rx during unexpected
moment. This could reduce the time of stopping rx.

For patch #1, the tp->speed should be updated early. Then,
the patch #2 could use it to check the current linking status.

Hayes Wang (2):
  r8152: adjust set_carrier
  r8152: check the status before submitting rx

 drivers/net/usb/r8152.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

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

[PATCH V3 08/11] power: charger-manager: Make chraging decision focusing on battery status.

[Jonghwa Lee]

In cm_monitor() where charging management starts, it checks various charging
condition sequentially to decide next charging operation. However, as it
follows sequential process, cascaded IF statements, it does some duplicated
jobs which is already done in previous stage. It results delay in decision
making. And moreover, starting point of charing is spreaded all around, so
it makes maintain codes and debugging difficult.

Both of problems mentioned above becomes clean if it manages battery charging
focusing on battery status not following sequential condition checking.
Now, cm_monitor() moves battery state diagram and does optimal operation for
current state. As a result, it reduces whole monitoring time almost in half.

Signed-off-by: Jonghwa Lee 
---
 drivers/power/charger-manager.c   |  177 +++--
 include/linux/power/charger-manager.h |3 +
 2 files changed, 62 insertions(+), 118 deletions(-)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index dc15436..44cc19a 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -249,6 +249,19 @@ static bool is_full_charged(struct charger_manager *cm)
if (!fuel_gauge)
return false;
 
+   /* Full, if it's over the fullbatt voltage */
+   if (desc->fullbatt_uV > 0) {
+   ret = get_batt_uV(cm, &uV);
+   if (!ret) {
+   /* Battery is already full, checks voltage drop. */
+   if (cm->battery_status == POWER_SUPPLY_STATUS_FULL
+   && desc->fullbatt_vchkdrop_uV)
+   uV += desc->fullbatt_vchkdrop_uV;
+   if (uV >= desc->fullbatt_uV)
+   return true;
+   }
+   }
+
if (desc->fullbatt_full_capacity > 0) {
val.intval = 0;
 
@@ -259,13 +272,6 @@ static bool is_full_charged(struct charger_manager *cm)
return true;
}
 
-   /* Full, if it's over the fullbatt voltage */
-   if (desc->fullbatt_uV > 0) {
-   ret = get_batt_uV(cm, &uV);
-   if (!ret && uV >= desc->fullbatt_uV)
-   return true;
-   }
-
/* Full, if the capacity is more than fullbatt_soc */
if (desc->fullbatt_soc > 0) {
val.intval = 0;
@@ -376,67 +382,13 @@ static int try_charger_enable(struct charger_manager *cm, 
bool enable)
}
}
 
-   if (!err) {
+   if (!err)
cm->charger_enabled = enable;
-   power_supply_changed(&cm->charger_psy);
-   }
 
return err;
 }
 
 /**
- * try_charger_restart - Restart charging.
- * @cm: the Charger Manager representing the battery.
- *
- * Restart charging by turning off and on the charger.
- */
-static int try_charger_restart(struct charger_manager *cm)
-{
-   int err;
-
-   if (cm->emergency_stop)
-   return -EAGAIN;
-
-   err = try_charger_enable(cm, false);
-   if (err)
-   return err;
-
-   return try_charger_enable(cm, true);
-}
-
-/**
- * fullbatt_vchk - Check voltage drop some times after "FULL" event.
- *
- * If a user has designated "fullbatt_vchkdrop_uV" values with
- * charger_desc, Charger Manager checks voltage drop after the battery
- * "FULL" event. It checks whether the voltage has dropped more than
- * fullbatt_vchkdrop_uV by calling this function after fullbatt_vchkrop_ms.
- */
-static void fullbatt_vchk(struct charger_manager *cm)
-{
-   struct charger_desc *desc = cm->desc;
-   int batt_uV, err, diff;
-
-   if (!desc->fullbatt_vchkdrop_uV)
-   return;
-
-   err = get_batt_uV(cm, &batt_uV);
-   if (err) {
-   dev_err(cm->dev, "%s: get_batt_uV error(%d)\n", __func__, err);
-   return;
-   }
-
-   diff = desc->fullbatt_uV - batt_uV;
-   if (diff < 0)
-   return;
-
-   dev_info(cm->dev, "VBATT dropped %duV after full-batt\n", diff);
-
-   if (diff > desc->fullbatt_vchkdrop_uV)
-   try_charger_restart(cm);
-}
-
-/**
  * check_charging_duration - Monitor charging/discharging duration
  * @cm: the Charger Manager representing the battery.
  *
@@ -463,17 +415,14 @@ static int check_charging_duration(struct charger_manager 
*cm)
if (duration > desc->charging_max_duration_ms) {
dev_info(cm->dev, "Charging duration exceed %ums\n",
 desc->charging_max_duration_ms);
-   try_charger_enable(cm, false);
ret = true;
}
-   } else if (is_ext_pwr_online(cm) && !cm->charger_enabled) {
+   } else if (cm->battery_status == POWER_SUPPLY_STATUS_NOT_CHARGING) {
duration = curr - cm->charging_end_time;
 
-   if (duration > desc->charging_max_duration_ms &&
-  

[PATCH net-next 1/2] r8152: adjust set_carrier

[Hayes Wang]

Update the tp->speed at the beginning of the function. Then,
the other fucntion could use it for checking linking status.

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

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2d1c77e..59b70c5 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2848,26 +2848,25 @@ static void rtl8153_down(struct r8152 *tp)
 static void set_carrier(struct r8152 *tp)
 {
struct net_device *netdev = tp->netdev;
-   u8 speed;
+   u8 old_speed = tp->speed;
 
clear_bit(RTL8152_LINK_CHG, &tp->flags);
-   speed = rtl8152_get_speed(tp);
+   tp->speed = rtl8152_get_speed(tp);
 
-   if (speed & LINK_STATUS) {
-   if (!(tp->speed & LINK_STATUS)) {
+   if (tp->speed & LINK_STATUS) {
+   if (!(old_speed & LINK_STATUS)) {
tp->rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, &tp->flags);
netif_carrier_on(netdev);
}
} else {
-   if (tp->speed & LINK_STATUS) {
+   if (old_speed & LINK_STATUS) {
netif_carrier_off(netdev);
tasklet_disable(&tp->tl);
tp->rtl_ops.disable(tp);
tasklet_enable(&tp->tl);
}
}
-   tp->speed = speed;
 }
 
 static void rtl_work_func_t(struct work_struct *work)
-- 
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/

[PATCH V3 02/11] power: charger-manager: Use thermal subsystem interface only to get temperature.

[Jonghwa Lee]

It drops the way of using power_supply interface to reference battery's
temperature. Then it tries to use thermal subsystem's only. This makes driver
more simple and also can remove ifdeferies.

Signed-off-by: Jonghwa Lee 
---
 drivers/power/Kconfig |1 +
 drivers/power/charger-manager.c   |  111 -
 include/linux/power/charger-manager.h |3 +-
 3 files changed, 27 insertions(+), 88 deletions(-)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 8ff2511..9ede4f2 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -316,6 +316,7 @@ config CHARGER_GPIO
 config CHARGER_MANAGER
bool "Battery charger manager for multiple chargers"
depends on REGULATOR
+   depends on THERMAL
select EXTCON
help
   Say Y to enable charger-manager support, which allows multiple
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 22246b9..71a3df7 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -28,13 +28,6 @@
 #include 
 #include 
 
-/*
- * Default termperature threshold for charging.
- * Every temperature units are in tenth of centigrade.
- */
-#define CM_DEFAULT_RECHARGE_TEMP_DIFF  50
-#define CM_DEFAULT_CHARGE_TEMP_MAX 500
-
 static const char * const default_event_names[] = {
[CM_EVENT_UNKNOWN] = "Unknown",
[CM_EVENT_BATT_FULL] = "Battery Full",
@@ -572,40 +565,18 @@ static int check_charging_duration(struct charger_manager 
*cm)
return ret;
 }
 
-static int cm_get_battery_temperature_by_psy(struct charger_manager *cm,
-   int *temp)
-{
-   struct power_supply *fuel_gauge;
-
-   fuel_gauge = power_supply_get_by_name(cm->desc->psy_fuel_gauge);
-   if (!fuel_gauge)
-   return -ENODEV;
-
-   return fuel_gauge->get_property(fuel_gauge,
-   POWER_SUPPLY_PROP_TEMP,
-   (union power_supply_propval *)temp);
-}
-
 static int cm_get_battery_temperature(struct charger_manager *cm,
int *temp)
 {
int ret;
 
-   if (!cm->desc->measure_battery_temp)
+   if (!cm->tzd_batt)
return -ENODEV;
 
-#ifdef CONFIG_THERMAL
-   if (cm->tzd_batt) {
-   ret = thermal_zone_get_temp(cm->tzd_batt, (unsigned long 
*)temp);
-   if (!ret)
-   /* Calibrate temperature unit */
-   *temp /= 100;
-   } else
-#endif
-   {
-   /* if-else continued from CONFIG_THERMAL */
-   ret = cm_get_battery_temperature_by_psy(cm, temp);
-   }
+   ret = thermal_zone_get_temp(cm->tzd_batt, (unsigned long *)temp);
+   if (!ret)
+   /* Calibrate temperature unit */
+   *temp /= 100;
 
return ret;
 }
@@ -1007,12 +978,11 @@ static enum power_supply_property 
default_charger_props[] = {
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_CHARGE_FULL,
+   POWER_SUPPLY_PROP_TEMP,
/*
 * Optional properties are:
 * POWER_SUPPLY_PROP_CHARGE_NOW,
 * POWER_SUPPLY_PROP_CURRENT_NOW,
-* POWER_SUPPLY_PROP_TEMP, and
-* POWER_SUPPLY_PROP_TEMP_AMBIENT,
 */
 };
 
@@ -1417,49 +1387,6 @@ err:
return ret;
 }
 
-static int cm_init_thermal_data(struct charger_manager *cm,
-   struct power_supply *fuel_gauge)
-{
-   struct charger_desc *desc = cm->desc;
-   union power_supply_propval val;
-   int ret;
-
-   /* Verify whether fuel gauge provides battery temperature */
-   ret = fuel_gauge->get_property(fuel_gauge,
-   POWER_SUPPLY_PROP_TEMP, &val);
-
-   if (!ret) {
-   cm->charger_psy.properties[cm->charger_psy.num_properties] =
-   POWER_SUPPLY_PROP_TEMP;
-   cm->charger_psy.num_properties++;
-   cm->desc->measure_battery_temp = true;
-   }
-#ifdef CONFIG_THERMAL
-   if (ret && desc->thermal_zone) {
-   cm->tzd_batt =
-   thermal_zone_get_zone_by_name(desc->thermal_zone);
-   if (IS_ERR(cm->tzd_batt))
-   return PTR_ERR(cm->tzd_batt);
-
-   /* Use external thermometer */
-   cm->charger_psy.properties[cm->charger_psy.num_properties] =
-   POWER_SUPPLY_PROP_TEMP_AMBIENT;
-   cm->charger_psy.num_properties++;
-   cm->desc->measure_battery_temp = true;
-   ret = 0;
-   }
-#endif
-   if (cm->desc->measure_battery_temp) {
-   /* NOTICE : Default allowable minimum charge temperature is 0 */
-   if (!desc->temp_max)
-   desc->temp_max = CM_DEFAULT_CHARGE_TEMP_MAX;
-   if (!desc->temp_diff)
-

[PATCH V3 03/11] power: charger-manager: Use power_supply_changed() not private uevent.

[Jonghwa Lee]

Whenever battery status is changed, charger manager tries to trigger uevent
through private interface. This patch modifies it to use power_supply_changed()
since it belongs to power supply subsystem.

Signed-off-by: Jonghwa Lee 
---
 drivers/power/charger-manager.c |   91 +--
 1 file changed, 11 insertions(+), 80 deletions(-)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 71a3df7..8c76bce 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -28,18 +28,6 @@
 #include 
 #include 
 
-static const char * const default_event_names[] = {
-   [CM_EVENT_UNKNOWN] = "Unknown",
-   [CM_EVENT_BATT_FULL] = "Battery Full",
-   [CM_EVENT_BATT_IN] = "Battery Inserted",
-   [CM_EVENT_BATT_OUT] = "Battery Pulled Out",
-   [CM_EVENT_BATT_OVERHEAT] = "Battery Overheat",
-   [CM_EVENT_BATT_COLD] = "Battery Cold",
-   [CM_EVENT_EXT_PWR_IN_OUT] = "External Power Attach/Detach",
-   [CM_EVENT_CHG_START_STOP] = "Charging Start/Stop",
-   [CM_EVENT_OTHERS] = "Other battery events"
-};
-
 /*
  * Regard CM_JIFFIES_SMALL jiffies is small enough to ignore for
  * delayed works so that we can run delayed works with CM_JIFFIES_SMALL
@@ -56,8 +44,6 @@ static const char * const default_event_names[] = {
  */
 #define CM_RTC_SMALL   (2)
 
-#define UEVENT_BUF_SIZE32
-
 static LIST_HEAD(cm_list);
 static DEFINE_MUTEX(cm_list_mtx);
 
@@ -423,61 +409,6 @@ static int try_charger_restart(struct charger_manager *cm)
 }
 
 /**
- * uevent_notify - Let users know something has changed.
- * @cm: the Charger Manager representing the battery.
- * @event: the event string.
- *
- * If @event is null, it implies that uevent_notify is called
- * by resume function. When called in the resume function, cm_suspended
- * should be already reset to false in order to let uevent_notify
- * notify the recent event during the suspend to users. While
- * suspended, uevent_notify does not notify users, but tracks
- * events so that uevent_notify can notify users later after resumed.
- */
-static void uevent_notify(struct charger_manager *cm, const char *event)
-{
-   static char env_str[UEVENT_BUF_SIZE + 1] = "";
-   static char env_str_save[UEVENT_BUF_SIZE + 1] = "";
-
-   if (cm_suspended) {
-   /* Nothing in suspended-event buffer */
-   if (env_str_save[0] == 0) {
-   if (!strncmp(env_str, event, UEVENT_BUF_SIZE))
-   return; /* status not changed */
-   strncpy(env_str_save, event, UEVENT_BUF_SIZE);
-   return;
-   }
-
-   if (!strncmp(env_str_save, event, UEVENT_BUF_SIZE))
-   return; /* Duplicated. */
-   strncpy(env_str_save, event, UEVENT_BUF_SIZE);
-   return;
-   }
-
-   if (event == NULL) {
-   /* No messages pending */
-   if (!env_str_save[0])
-   return;
-
-   strncpy(env_str, env_str_save, UEVENT_BUF_SIZE);
-   kobject_uevent(&cm->dev->kobj, KOBJ_CHANGE);
-   env_str_save[0] = 0;
-
-   return;
-   }
-
-   /* status not changed */
-   if (!strncmp(env_str, event, UEVENT_BUF_SIZE))
-   return;
-
-   /* save the status and notify the update */
-   strncpy(env_str, event, UEVENT_BUF_SIZE);
-   kobject_uevent(&cm->dev->kobj, KOBJ_CHANGE);
-
-   dev_info(cm->dev, "%s\n", event);
-}
-
-/**
  * fullbatt_vchk - Check voltage drop some times after "FULL" event.
  * @work: the work_struct appointing the function
  *
@@ -514,7 +445,7 @@ static void fullbatt_vchk(struct work_struct *work)
 
if (diff > desc->fullbatt_vchkdrop_uV) {
try_charger_restart(cm);
-   uevent_notify(cm, "Recharging");
+   power_supply_changed(&cm->charger_psy);
}
 }
 
@@ -545,7 +476,7 @@ static int check_charging_duration(struct charger_manager 
*cm)
if (duration > desc->charging_max_duration_ms) {
dev_info(cm->dev, "Charging duration exceed %ums\n",
 desc->charging_max_duration_ms);
-   uevent_notify(cm, "Discharging");
+   power_supply_changed(&cm->charger_psy);
try_charger_enable(cm, false);
ret = true;
}
@@ -556,7 +487,7 @@ static int check_charging_duration(struct charger_manager 
*cm)
is_ext_pwr_online(cm)) {
dev_info(cm->dev, "Discharging duration exceed %ums\n",
 desc->discharging_max_duration_ms);
-   uevent_notify(cm, "Recharging");
+   power_supply_changed(&cm->charger_psy);
try_charger_enable(cm, true);
 

[PATCH V3 0/11] Improve charger manager driver for optimized operation.

[Jonghwa Lee]

After charger manager's initially introduced, it has kept its codes without any
big change. However, the charger manager working operation isn't optimized and
it also has unused codes and non-generic interface. This series tries to make
charger manager more generic and maintainable with some fixes.

[Changes in V3]
- Add omitted patch '[1/11] Use alarmtimer for battery~' from v2 patch set.

[Changes in V2]
- Rebase patch series on latest of battery-2.6.git.
- Seperate 'power: charger-manager: Rearrange data and monitor ~' patch into
  several patches depends on its purpose.
- Add 2 patches related with polling mode.

Jonghwa Lee (11):
  power: charger-manager: Use alarmtimer for battery monitoring in
suspend.
  power: charger-manager: Use thermal subsystem interface only to get
temperature.
  power: charger-manager: Use power_supply_changed() not private
uevent.
  power: charger-manager: Remove deprecated function,
cm_notify_event().
  power: charger-manager: Fix to use CHARGE_NOW/FULL property
correctly.
  power: charger-manager: Concentrate scattered power_supply_changed()
calls.
  power: charger-manager: Get external power souce information only
from EXTCON.
  power: charger-manager: Make chraging decision focusing on battery
status.
  power: charger-manager: Not to start charging directly in cable
nofitication.
  power: charger-manager: Support different polling mode for sleep
state.
  power: charger-manager: Support to change polling rate in runtime.

 .../bindings/power_supply/charger-manager.txt  |1 -
 drivers/power/Kconfig  |3 +-
 drivers/power/charger-manager.c| 1026 ++--
 include/linux/power/charger-manager.h  |   66 +-
 4 files changed, 293 insertions(+), 803 deletions(-)

-- 
1.7.9.5

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

[PATCH V3 05/11] power: charger-manager: Fix to use CHARGE_NOW/FULL property correctly.

[Jonghwa Lee]

The POWER_SUPPLY_CHARGE_NOW/FULL property reflects battery's charges
in uAh unit, but charger-manager has been used it wrongly. This patch
makes it to use those propeties correctly and change to be optional.

Signed-off-by: Jonghwa Lee 
---
 drivers/power/charger-manager.c |   85 +--
 1 file changed, 28 insertions(+), 57 deletions(-)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 5482661..7bbaef6 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -796,35 +796,13 @@ static int charger_get_property(struct power_supply *psy,
val->intval = 0;
break;
case POWER_SUPPLY_PROP_CHARGE_FULL:
-   if (is_full_charged(cm))
-   val->intval = 1;
-   else
-   val->intval = 0;
-   ret = 0;
-   break;
case POWER_SUPPLY_PROP_CHARGE_NOW:
-   if (is_charging(cm)) {
-   fuel_gauge = power_supply_get_by_name(
-   cm->desc->psy_fuel_gauge);
-   if (!fuel_gauge) {
-   ret = -ENODEV;
-   break;
-   }
-
-   ret = fuel_gauge->get_property(fuel_gauge,
-   POWER_SUPPLY_PROP_CHARGE_NOW,
-   val);
-   if (ret) {
-   val->intval = 1;
-   ret = 0;
-   } else {
-   /* If CHARGE_NOW is supplied, use it */
-   val->intval = (val->intval > 0) ?
-   val->intval : 1;
-   }
-   } else {
-   val->intval = 0;
+   fuel_gauge = power_supply_get_by_name(cm->desc->psy_fuel_gauge);
+   if (!fuel_gauge) {
+   ret = -ENODEV;
+   break;
}
+   ret = fuel_gauge->get_property(fuel_gauge, psp, val);
break;
default:
return -EINVAL;
@@ -832,8 +810,7 @@ static int charger_get_property(struct power_supply *psy,
return ret;
 }
 
-#define NUM_CHARGER_PSY_OPTIONAL   (4)
-static enum power_supply_property default_charger_props[] = {
+static enum power_supply_property cm_default_props[] = {
/* Guaranteed to provide */
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_HEALTH,
@@ -841,20 +818,21 @@ static enum power_supply_property default_charger_props[] 
= {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_ONLINE,
-   POWER_SUPPLY_PROP_CHARGE_FULL,
POWER_SUPPLY_PROP_TEMP,
-   /*
-* Optional properties are:
-* POWER_SUPPLY_PROP_CHARGE_NOW,
-* POWER_SUPPLY_PROP_CURRENT_NOW,
-*/
 };
 
+static enum power_supply_property cm_optional_props[] = {
+   POWER_SUPPLY_PROP_CHARGE_FULL,
+   POWER_SUPPLY_PROP_CHARGE_NOW,
+   POWER_SUPPLY_PROP_CURRENT_NOW,
+};
+
+#define CM_NUM_OF_PROPS\
+   (ARRAY_SIZE(cm_default_props) + ARRAY_SIZE(cm_optional_props))
+
 static struct power_supply psy_default = {
.name = "battery",
.type = POWER_SUPPLY_TYPE_BATTERY,
-   .properties = default_charger_props,
-   .num_properties = ARRAY_SIZE(default_charger_props),
.get_property = charger_get_property,
.no_thermal = true,
 };
@@ -1484,29 +1462,22 @@ static int charger_manager_probe(struct platform_device 
*pdev)
/* Allocate for psy properties because they may vary */
cm->charger_psy.properties = devm_kzalloc(&pdev->dev,
sizeof(enum power_supply_property)
-   * (ARRAY_SIZE(default_charger_props) +
-   NUM_CHARGER_PSY_OPTIONAL), GFP_KERNEL);
+   * CM_NUM_OF_PROPS, GFP_KERNEL);
if (!cm->charger_psy.properties)
return -ENOMEM;
 
-   memcpy(cm->charger_psy.properties, default_charger_props,
-   sizeof(enum power_supply_property) *
-   ARRAY_SIZE(default_charger_props));
-   cm->charger_psy.num_properties = psy_default.num_properties;
-
-   /* Find which optional psy-properties are available */
-   if (!fuel_gauge->get_property(fuel_gauge,
- POWER_SUPPLY_PROP_CHARGE_NOW, &val)) {
-   cm->charger_psy.properties[cm->charger_psy.num_properties] =
-   POWER_SUPPLY_PROP_CHARGE_NOW;
-   cm->charger_psy.num_properties++;
-   }
-   if (!fuel_gauge->get_property(fuel_gauge,
- POWER_SUPPLY_PROP_CURRENT_NOW,
- 

[PATCH V3 06/11] power: charger-manager: Concentrate scattered power_supply_changed() calls.

[Jonghwa Lee]

Current charger-manager calls power_suuply_changed() whenever charging
status is changed. This patch removes seperated power_supply_changed()
use and let it be called at end of try_charger_enable() function which
is called to set charging/discharging.

Signed-off-by: Jonghwa Lee 
---
 drivers/power/charger-manager.c |   18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 7bbaef6..d29155d 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -382,8 +382,10 @@ static int try_charger_enable(struct charger_manager *cm, 
bool enable)
}
}
 
-   if (!err)
+   if (!err) {
cm->charger_enabled = enable;
+   power_supply_changed(&cm->charger_psy);
+   }
 
return err;
 }
@@ -436,10 +438,8 @@ static void fullbatt_vchk(struct charger_manager *cm)
 
dev_info(cm->dev, "VBATT dropped %duV after full-batt\n", diff);
 
-   if (diff > desc->fullbatt_vchkdrop_uV) {
+   if (diff > desc->fullbatt_vchkdrop_uV)
try_charger_restart(cm);
-   power_supply_changed(&cm->charger_psy);
-   }
 }
 
 /**
@@ -469,7 +469,6 @@ static int check_charging_duration(struct charger_manager 
*cm)
if (duration > desc->charging_max_duration_ms) {
dev_info(cm->dev, "Charging duration exceed %ums\n",
 desc->charging_max_duration_ms);
-   power_supply_changed(&cm->charger_psy);
try_charger_enable(cm, false);
ret = true;
}
@@ -480,7 +479,6 @@ static int check_charging_duration(struct charger_manager 
*cm)
is_ext_pwr_online(cm)) {
dev_info(cm->dev, "Discharging duration exceed %ums\n",
 desc->discharging_max_duration_ms);
-   power_supply_changed(&cm->charger_psy);
try_charger_enable(cm, true);
ret = true;
}
@@ -561,8 +559,7 @@ static bool _cm_monitor(struct charger_manager *cm)
 */
if (temp_alrt) {
cm->emergency_stop = temp_alrt;
-   if (!try_charger_enable(cm, false))
-   power_supply_changed(&cm->charger_psy);
+   try_charger_enable(cm, false);
 
/*
 * Check whole charging duration and discharing duration
@@ -587,16 +584,13 @@ static bool _cm_monitor(struct charger_manager *cm)
} else if (!cm->emergency_stop && is_full_charged(cm) &&
cm->charger_enabled) {
dev_info(cm->dev, "EVENT_HANDLE: Battery Fully Charged\n");
-   power_supply_changed(&cm->charger_psy);
-
try_charger_enable(cm, false);
 
fullbatt_vchk(cm);
} else {
cm->emergency_stop = 0;
if (is_ext_pwr_online(cm)) {
-   if (!try_charger_enable(cm, true))
-   power_supply_changed(&cm->charger_psy);
+   try_charger_enable(cm, true);
}
}
 
-- 
1.7.9.5

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

[PATCH V3 09/11] power: charger-manager: Not to start charging directly in cable nofitication.

[Jonghwa Lee]

This patch prevents direct charging control in cable notification.
It sets only input current limit according to cable type and yields charging
control to be done by cm_monitor() where charging management proceeds.
It may loose few ms to enable charging compared to before, even though it's
more important that charging is enabled always in safe context.

Signed-off-by: Jonghwa Lee 
---
 drivers/power/charger-manager.c |   12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 44cc19a..4f8b0e6 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -849,7 +849,8 @@ static void charger_extcon_work(struct work_struct *work)
cable->min_uA, cable->max_uA);
}
 
-   try_charger_enable(cable->cm, cable->attached);
+   cancel_delayed_work(&cm_monitor_work);
+   queue_delayed_work(cm_wq, &cm_monitor_work, 0);
 }
 
 /**
@@ -873,15 +874,6 @@ static int charger_extcon_notifier(struct notifier_block 
*self,
cable->attached = event;
 
/*
-* Setup monitoring to check battery state
-* when charger cable is attached.
-*/
-   if (cable->attached && is_polling_required(cable->cm)) {
-   cancel_work_sync(&setup_polling);
-   schedule_work(&setup_polling);
-   }
-
-   /*
 * Setup work for controlling charger(regulator)
 * according to charger cable.
 */
-- 
1.7.9.5

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

[PATCH V3 01/11] power: charger-manager: Use alarmtimer for battery monitoring in suspend.

[Jonghwa Lee]

To guerantee proper charing and managing batteries even in suspend,
charger-manager has used rtc device with rtc framework interface.
However, it is better to use alarmtimer for cleaner and more appropriate
operation.
This patch makes driver to use alamtimer for polling work in suspend and
removes all deprecated codes related with using rtc interface.

Signed-off-by: Jonghwa Lee 
---
 drivers/power/Kconfig |2 +-
 drivers/power/charger-manager.c   |  288 ++---
 include/linux/power/charger-manager.h |   32 +---
 3 files changed, 84 insertions(+), 238 deletions(-)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 0108c2a..8ff2511 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -315,7 +315,7 @@ config CHARGER_GPIO
 
 config CHARGER_MANAGER
bool "Battery charger manager for multiple chargers"
-   depends on REGULATOR && RTC_CLASS
+   depends on REGULATOR
select EXTCON
help
   Say Y to enable charger-manager support, which allows multiple
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index ef8094a..22246b9 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -69,16 +69,11 @@ static LIST_HEAD(cm_list);
 static DEFINE_MUTEX(cm_list_mtx);
 
 /* About in-suspend (suspend-again) monitoring */
-static struct rtc_device *rtc_dev;
-/*
- * Backup RTC alarm
- * Save the wakeup alarm before entering suspend-to-RAM
- */
-static struct rtc_wkalrm rtc_wkalarm_save;
+static struct alarm *cm_timer;
+
 /* Backup RTC alarm time in terms of seconds since 01-01-1970 00:00:00 */
-static unsigned long rtc_wkalarm_save_time;
 static bool cm_suspended;
-static bool cm_rtc_set;
+static bool cm_timer_set;
 static unsigned long cm_suspend_duration_ms;
 
 /* About normal (not suspended) monitoring */
@@ -87,9 +82,6 @@ static unsigned long next_polling; /* Next appointed polling 
time */
 static struct workqueue_struct *cm_wq; /* init at driver add */
 static struct delayed_work cm_monitor_work; /* init at driver add */
 
-/* Global charger-manager description */
-static struct charger_global_desc *g_desc; /* init with setup_charger_manager 
*/
-
 /**
  * is_batt_present - See if the battery presents in place.
  * @cm: the Charger Manager representing the battery.
@@ -1047,10 +1039,13 @@ static bool cm_setup_timer(void)
 {
struct charger_manager *cm;
unsigned int wakeup_ms = UINT_MAX;
-   bool ret = false;
+   int timer_req = 0;
 
-   mutex_lock(&cm_list_mtx);
+   if (time_after(next_polling, jiffies))
+   CM_MIN_VALID(wakeup_ms,
+   jiffies_to_msecs(next_polling - jiffies));
 
+   mutex_lock(&cm_list_mtx);
list_for_each_entry(cm, &cm_list, entry) {
unsigned int fbchk_ms = 0;
 
@@ -1070,162 +1065,38 @@ static bool cm_setup_timer(void)
/* Skip if polling is not required for this CM */
if (!is_polling_required(cm) && !cm->emergency_stop)
continue;
+   timer_req++;
if (cm->desc->polling_interval_ms == 0)
continue;
CM_MIN_VALID(wakeup_ms, cm->desc->polling_interval_ms);
}
-
mutex_unlock(&cm_list_mtx);
 
-   if (wakeup_ms < UINT_MAX && wakeup_ms > 0) {
-   pr_info("Charger Manager wakeup timer: %u ms\n", wakeup_ms);
-   if (rtc_dev) {
-   struct rtc_wkalrm tmp;
-   unsigned long time, now;
-   unsigned long add = DIV_ROUND_UP(wakeup_ms, 1000);
-
-   /*
-* Set alarm with the polling interval (wakeup_ms)
-* except when rtc_wkalarm_save comes first.
-* However, the alarm time should be NOW +
-* CM_RTC_SMALL or later.
-*/
-   tmp.enabled = 1;
-   rtc_read_time(rtc_dev, &tmp.time);
-   rtc_tm_to_time(&tmp.time, &now);
-   if (add < CM_RTC_SMALL)
-   add = CM_RTC_SMALL;
-   time = now + add;
+   if (timer_req && cm_timer) {
+   ktime_t now, add;
 
-   ret = true;
+   /*
+* Set alarm with the polling interval (wakeup_ms)
+* The alarm time should be NOW + CM_RTC_SMALL or later.
+*/
+   if (wakeup_ms == UINT_MAX ||
+   wakeup_ms < CM_RTC_SMALL * MSEC_PER_SEC)
+   wakeup_ms = 2 * CM_RTC_SMALL * MSEC_PER_SEC;
 
-   if (rtc_wkalarm_save.enabled &&
-   rtc_wkalarm_save_time &&
-   rtc_wkalarm_save_time < time) {
-   if (rtc_wkalarm_save_time < now + CM_R

[PATCH V3 04/11] power: charger-manager: Remove deprecated function, cm_notify_event().

[Jonghwa Lee]

cm_notify_event() is introduced to get event associated with battery status
externally, but no one had been used. Moreover it makes charger manager
driver more complicated. This patch tries to drop the function and all data
related to simplify the driver.

Signed-off-by: Jonghwa Lee 
---
 .../bindings/power_supply/charger-manager.txt  |1 -
 drivers/power/charger-manager.c|  196 +---
 include/linux/power/charger-manager.h  |   19 +-
 3 files changed, 8 insertions(+), 208 deletions(-)

diff --git a/Documentation/devicetree/bindings/power_supply/charger-manager.txt 
b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
index ec4fe9d..827576e 100644
--- a/Documentation/devicetree/bindings/power_supply/charger-manager.txt
+++ b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
@@ -39,7 +39,6 @@ Example :
cm-poll-mode = <1>;
cm-poll-interval = <3>;
 
-   cm-fullbatt-vchkdrop-ms = <3>;
cm-fullbatt-vchkdrop-volt = <15>;
cm-fullbatt-soc = <100>;
 
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 8c76bce..5482661 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -410,25 +410,18 @@ static int try_charger_restart(struct charger_manager *cm)
 
 /**
  * fullbatt_vchk - Check voltage drop some times after "FULL" event.
- * @work: the work_struct appointing the function
  *
- * If a user has designated "fullbatt_vchkdrop_ms/uV" values with
+ * If a user has designated "fullbatt_vchkdrop_uV" values with
  * charger_desc, Charger Manager checks voltage drop after the battery
  * "FULL" event. It checks whether the voltage has dropped more than
  * fullbatt_vchkdrop_uV by calling this function after fullbatt_vchkrop_ms.
  */
-static void fullbatt_vchk(struct work_struct *work)
+static void fullbatt_vchk(struct charger_manager *cm)
 {
-   struct delayed_work *dwork = to_delayed_work(work);
-   struct charger_manager *cm = container_of(dwork,
-   struct charger_manager, fullbatt_vchk_work);
struct charger_desc *desc = cm->desc;
int batt_uV, err, diff;
 
-   /* remove the appointment for fullbatt_vchk */
-   cm->fullbatt_vchk_jiffies_at = 0;
-
-   if (!desc->fullbatt_vchkdrop_uV || !desc->fullbatt_vchkdrop_ms)
+   if (!desc->fullbatt_vchkdrop_uV)
return;
 
err = get_batt_uV(cm, &batt_uV);
@@ -585,7 +578,7 @@ static bool _cm_monitor(struct charger_manager *cm)
 */
} else if (!cm->emergency_stop && is_ext_pwr_online(cm) &&
!cm->charger_enabled) {
-   fullbatt_vchk(&cm->fullbatt_vchk_work.work);
+   fullbatt_vchk(cm);
 
/*
 * Check whether fully charged state to protect overcharge
@@ -598,7 +591,7 @@ static bool _cm_monitor(struct charger_manager *cm)
 
try_charger_enable(cm, false);
 
-   fullbatt_vchk(&cm->fullbatt_vchk_work.work);
+   fullbatt_vchk(cm);
} else {
cm->emergency_stop = 0;
if (is_ext_pwr_online(cm)) {
@@ -700,66 +693,6 @@ static void cm_monitor_poller(struct work_struct *work)
schedule_work(&setup_polling);
 }
 
-/**
- * fullbatt_handler - Event handler for CM_EVENT_BATT_FULL
- * @cm: the Charger Manager representing the battery.
- */
-static void fullbatt_handler(struct charger_manager *cm)
-{
-   struct charger_desc *desc = cm->desc;
-
-   if (!desc->fullbatt_vchkdrop_uV || !desc->fullbatt_vchkdrop_ms)
-   goto out;
-
-   if (cm_suspended)
-   device_set_wakeup_capable(cm->dev, true);
-
-   mod_delayed_work(cm_wq, &cm->fullbatt_vchk_work,
-msecs_to_jiffies(desc->fullbatt_vchkdrop_ms));
-   cm->fullbatt_vchk_jiffies_at = jiffies + msecs_to_jiffies(
-  desc->fullbatt_vchkdrop_ms);
-
-   if (cm->fullbatt_vchk_jiffies_at == 0)
-   cm->fullbatt_vchk_jiffies_at = 1;
-
-out:
-   dev_info(cm->dev, "EVENT_HANDLE: Battery Fully Charged\n");
-   power_supply_changed(&cm->charger_psy);
-}
-
-/**
- * battout_handler - Event handler for CM_EVENT_BATT_OUT
- * @cm: the Charger Manager representing the battery.
- */
-static void battout_handler(struct charger_manager *cm)
-{
-   if (cm_suspended)
-   device_set_wakeup_capable(cm->dev, true);
-
-   if (!is_batt_present(cm)) {
-   dev_emerg(cm->dev, "Battery Pulled Out!\n");
-   power_supply_changed(&cm->charger_psy);
-   } else {
-   power_supply_changed(&cm->charger_psy);
-   }
-}
-
-/**
- * misc_event_handler - Handler for other evnets
- * @cm: the Charger Manager representing the battery.
- * @type: the Charger Manager representing the battery.
- */
-static void misc_event_handler(struct charger_man

Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[B Viswanath]

On 19 December 2014 at 13:57, Jiri Pirko  wrote:
> Fri, Dec 19, 2014 at 06:14:57AM CET, marichi...@gmail.com wrote:
>>On 19 December 2014 at 05:18, Roopa Prabhu  wrote:
>>> On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:



 We also need an interface to set per-switch attributes. Can this work?
 bridge link set dev sw0 sw_attr bcast_flooding 1 master
 where sw0 is a bridge representing the hardware switch.
>>>
>>>
>>> Not today. We discussed this @ LPC, and one way to do this would be to have
>>> a device
>>> representing the switch asic. This is in the works.
>>
>>
>>Can I assume that on  platforms which house more than one asic (say
>>two 24 port asics, interconnected via a 10G link or equivalent, to get
>>a 48 port 'switch') , the 'rocker' driver (or similar) should expose
>>them as a single set of ports, and not as two 'switch ports' ?
>
> Well that really depends on particular implementation and drivers. If you
> have 2 pci-e devices, I think you should expose them as 2 entities. For
> sure, you can have the driver to do the masking for you. I don't believe
> that is correct though.
>

In a platform that houses two asic chips, IMO, the user is still
expected to manage the router as a single entity. The configuration
being applied on both asic devices need to be matching if not
identical, and may not be conflicting. The FDB is to be synchronized
so that (offloaded) switching can happen across the asics. Some of
this stuff is asic specific anyway. Another example is that of the
learning. The (hardware) learning can't be enabled on one asic, while
being disabled on another one. The general use cases I have seen are
all involving managing the 'router' as a single entity.  That the
'router' is implemented with two asics instead of a single asic (with
more ports) is to be treated as an implementation detail.  This is the
usual router management method that exists today.

I hope I make sense.

So I am trying to figure out what this single entity that will be used
from a user perspective. It can be a bridge, but our bridges are more
802.1q bridges. We can use the 'self' mode, but then it means that it
should reflect the entire port count, and not just an asic.

So I was trying to deduce that in our switchdevice model, the best bet
would be to leave the unification to the driver (i.e., to project the
multiple physical asics as a single virtual switch device). This
allows any 'switch' level configurations to the bridge in 'self' mode.

And  then we would need to consider stacking. Stacking differs from
this multi-asic scenario since  there would be multiple CPU involved.

Thanks
Vissu

>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" 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: [PATCHv9 0/2] Add Allwinner SoCs PWM support

[Olliver Schinagl]

Hey Alexandre!

On 17-12-14 20:58, Alexandre Belloni wrote:

Hi,

I finally got some time to work on that again.

awesome :D


On 18/11/2014 at 14:47:33 +0100, Olliver Schinagl wrote :

What I get from the datasheet is, that sun4i and sun5i are exactly the same,
with the exception that sun5i only has 1 PWM (~exposed~). I belive that is
easily solved with the bindings by having allwinner-sun4i and allwinner
sun5i bindings if I'm not mistaken.

As for sun7i compared to the other ones, according to disp_lcd.c sun5i and
sun7i should behave exactly the same. This is contradicting to the
datasheet, where sun4i and sun5i are the same.

So what are the major differences that I can see between the 3? sun4i
defines the PWM prescaler register value 0b as being undefined, and
sun5i and sun7i as /1? Did you verify this (I haven't I admit, i bumped into
this while looking for your patch ;-) )? I wouldn't be supprised if it where
a typo on allwinners end in the datasheet ... disp_lcd.c stops at 72000 for
the last entry. We should just check sun4i, sun5i and sun7i hardware to see
if it behaves the same with a prescaler of 0b, which I would not be
totally surprised if it did.

The other difference I notice is that sun7i and sun5i use 16bit period
register where sun4i uses a 8bit register. This is probably the only reason
why they put a #ifdef in disp_lcd.c, calculations turn out differently. I
don't recognize this behavior at all in your driver however. I do think they
that there is a difference here, since they did split up the original driver
here because of this difference.


That is something I overlooked and I can't test at all, I only have a
cubietruck. Did you have some time to test on a sun4i?
I have sun4i, sun5i and sun7i to test this on; though my sun5i is a 
tablet so needs some work to setup as a dev environment (solder uart 
etc). On sun7i the pwm worked perfectly; I will find some time to test 
in on sun4i and sun5i in the next few weeks with your v10 patches


But, from the only datasheet I have access to [1], page 56:
Each channel has a dedicated internal 16-bit up counter. If the counter
reaches the value stored in the channel period register, it resets. At
the beginning of a count period cycle, the PWMOUT is set to active state
and count from 0x

So I would say that they all have a 16bits period.


[1] 
http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf
yeah we only have the datasheets available on dl.linux-sunxi.org; but 
don't only rely on the datasheets, it's a horrid copy/paste mess that 
may be very wrong due to lazy editing of the pastes :(


The sorucecode helps a bit in this, as pwm0 is always used as a 
background light driver, so should atleast be somewhat verified to work.


Olliver




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator: max14577: Use regulator_nodes/of_match in the descriptor

[Beomho Seo]

This patch is add regulator_nodes/ofmatch in the regulator descriptor
for using information from DT instead of specific codes.
That will be used regulation_of_get_init_data function for get regulator
property on device tree. Using that make driver simpler.

Cc: Chanwoo Choi 
Cc: Krzysztof Kozlowski 
Cc: Liam Girdwood 
Cc: Mark Brown 
Signed-off-by: Beomho Seo 
---
 drivers/regulator/max14577.c |   62 ++
 1 file changed, 14 insertions(+), 48 deletions(-)

diff --git a/drivers/regulator/max14577.c b/drivers/regulator/max14577.c
index 0ff5a20..bbcc750 100644
--- a/drivers/regulator/max14577.c
+++ b/drivers/regulator/max14577.c
@@ -103,6 +103,8 @@ static struct regulator_ops max14577_charger_ops = {
 static const struct regulator_desc max14577_supported_regulators[] = {
[MAX14577_SAFEOUT] = {
.name   = "SAFEOUT",
+   .of_match   = of_match_ptr("SAFEOUT"),
+   .regulators_node = of_match_ptr("regulators"),
.id = MAX14577_SAFEOUT,
.ops= &max14577_safeout_ops,
.type   = REGULATOR_VOLTAGE,
@@ -114,6 +116,8 @@ static const struct regulator_desc 
max14577_supported_regulators[] = {
},
[MAX14577_CHARGER] = {
.name   = "CHARGER",
+   .of_match   = of_match_ptr("CHARGER"),
+   .regulators_node = of_match_ptr("regulators"),
.id = MAX14577_CHARGER,
.ops= &max14577_charger_ops,
.type   = REGULATOR_CURRENT,
@@ -137,6 +141,8 @@ static struct regulator_ops max77836_ldo_ops = {
 static const struct regulator_desc max77836_supported_regulators[] = {
[MAX14577_SAFEOUT] = {
.name   = "SAFEOUT",
+   .of_match   = of_match_ptr("SAFEOUT"),
+   .regulators_node = of_match_ptr("regulators"),
.id = MAX14577_SAFEOUT,
.ops= &max14577_safeout_ops,
.type   = REGULATOR_VOLTAGE,
@@ -148,6 +154,8 @@ static const struct regulator_desc 
max77836_supported_regulators[] = {
},
[MAX14577_CHARGER] = {
.name   = "CHARGER",
+   .of_match   = of_match_ptr("CHARGER"),
+   .regulators_node = of_match_ptr("regulators"),
.id = MAX14577_CHARGER,
.ops= &max14577_charger_ops,
.type   = REGULATOR_CURRENT,
@@ -157,6 +165,8 @@ static const struct regulator_desc 
max77836_supported_regulators[] = {
},
[MAX77836_LDO1] = {
.name   = "LDO1",
+   .of_match   = of_match_ptr("LDO1"),
+   .regulators_node = of_match_ptr("regulators"),
.id = MAX77836_LDO1,
.ops= &max77836_ldo_ops,
.type   = REGULATOR_VOLTAGE,
@@ -171,6 +181,8 @@ static const struct regulator_desc 
max77836_supported_regulators[] = {
},
[MAX77836_LDO2] = {
.name   = "LDO2",
+   .of_match   = of_match_ptr("LDO2"),
+   .regulators_node = of_match_ptr("regulators"),
.id = MAX77836_LDO2,
.ops= &max77836_ldo_ops,
.type   = REGULATOR_VOLTAGE,
@@ -198,43 +210,6 @@ static struct of_regulator_match 
max77836_regulator_matches[] = {
{ .name = "LDO2", },
 };
 
-static int max14577_regulator_dt_parse_pdata(struct platform_device *pdev,
-   enum maxim_device_type dev_type)
-{
-   int ret;
-   struct device_node *np;
-   struct of_regulator_match *regulator_matches;
-   unsigned int regulator_matches_size;
-
-   np = of_get_child_by_name(pdev->dev.parent->of_node, "regulators");
-   if (!np) {
-   dev_err(&pdev->dev, "Failed to get child OF node for 
regulators\n");
-   return -EINVAL;
-   }
-
-   switch (dev_type) {
-   case MAXIM_DEVICE_TYPE_MAX77836:
-   regulator_matches = max77836_regulator_matches;
-   regulator_matches_size = ARRAY_SIZE(max77836_regulator_matches);
-   break;
-   case MAXIM_DEVICE_TYPE_MAX14577:
-   default:
-   regulator_matches = max14577_regulator_matches;
-   regulator_matches_size = ARRAY_SIZE(max14577_regulator_matches);
-   }
-
-   ret = of_regulator_match(&pdev->dev, np, regulator_matches,
-   regulator_matches_size);
-   if (ret < 0)
-   dev_err(&pdev->dev, "Error parsing regulator init data: %d\n", 
ret);
-   else
-   ret = 0;
-
-   of_node_put(np);
-
-   return ret;
-}
-
 static inline struct regulator_init_data *match_init_data(int index,
enum maxim_device_typ

Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc

[Roger Quadros]

Lokesh,

On 19/12/14 07:21, Lokesh Vutla wrote:
> Hi Roger,
> On Thursday 18 December 2014 09:22 PM, Roger Quadros wrote:
>> Fixing up Paul's email id.
>>
>> cheers,
>> -roger
>>
>> On 18/12/14 17:49, Roger Quadros wrote:
>>> There are quite a few hwmods that don't have sysconfig register and so
>>> _find_mpu_rt_port(oh) will return NULL thus preventing ready state check
>>> on those modules after the module is enabled.
>>>
>>> This can potentially cause a bus access error if the module is accessed
>>> before the module is ready.
>>>
>>> Get rid of the redundant _find_mpu_rt_port() check from the 
>>> _wait_target_ready()
>>> funcion for all the SoCs. The following PRCM register access that checks the
>>> module ready state has nothing to do with module's SYSCONFIG or mpu_rt_port.
> Yes, makes sense. This patch looks good to me.
> Tested this on AM437x-gp-evm.
> 
> Tested-by: Lokesh Vutla 

Thanks.

> 
> May be good idea to warn every time if enabling of module is failed?
> Unrelated to this patch though.

Yes, failing to be ready is serious enough for a warning. Care to send a 
separate patch for that?

cheers,
-roger

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

[Dmitry Monakhov]

Andrew Morton  writes:

> On Wed, 10 Dec 2014 16:49:18 +0300 Dmitry Monakhov  
> wrote:
>
>> 
>> Hello. Someone please take care of this patch.
>> 
>> W/o that patch unprivileged user may abuse system resources simply by 
>> spawning
>> wast number of unkilable busyloops (works on ext2/ext3):
>> 
>> truncate --size 1T test
>> for ((i=0;i<1024;i++))
>> do
>>filefrag test > /dev/null &
>> done
>> 
>> >> --- a/fs/ioctl.c
>> >> +++ b/fs/ioctl.c
>> >> @@ -379,6 +379,11 @@ int __generic_block_fiemap(struct inode *inode,
>> >>   past_eof = true;
>> >>   }
>> >>   cond_resched();
>> >> + if (fatal_signal_pending(current)) {
>> >> + ret = -EINTR;
>> >> + break;
>> >> + }
>> >> +
>> >>   } while (1);
>> >>  
>
> Is FIEMAP documented anywhere (manpage)?  If so, that will need an
> update.
Yes you right. I just thought that it is assumed by default.
The only place I know is Documentation/filesystems/fiemap.txt
Please fold patch attached to original one.


signature.asc
Description: PGP signature
>From f7af425b2ac920065491a478b4f4359f422b3453 Mon Sep 17 00:00:00 2001
From: Dmitry Monakhov 
Date: Fri, 19 Dec 2014 13:11:29 +0400
Subject: [PATCH] doc: fimemap update signal behaviour


Signed-off-by: Dmitry Monakhov 
---
 Documentation/filesystems/fiemap.txt |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Documentation/filesystems/fiemap.txt b/Documentation/filesystems/fiemap.txt
index 1b805a0..f6d9c99 100644
--- a/Documentation/filesystems/fiemap.txt
+++ b/Documentation/filesystems/fiemap.txt
@@ -196,7 +196,8 @@ struct fiemap_extent_info {
 };
 
 It is intended that the file system should not need to access any of this
-structure directly.
+structure directly. Filesystem handlers should be tolerant to signals and return
+EINTR once fatal signal received.
 
 
 Flag checking should be done at the beginning of the ->fiemap callback via the
-- 
1.7.1

Re: [PATCH] ALSA: atmel: fix building the ac97 driver for at91-multiplatform

[Alexandre Belloni]

Hi,

On 19/12/2014 at 09:20:47 +0100, Alexander Stein wrote :
> I recently send 3 patches to make DT working with this driver, you were on CC 
> :). Please refer to http://comments.gmane.org/gmane.linux.alsa.devel/131686
> I wonder though why all 3 are listed there although they were sent to 
> different lists.
> 
I know, my plan was to review them today. Maybe we could change the
commit log if your patches are taken before that one. I must admit I
simply kept what Arnd had written.

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

[git pull] Please pull mpe/linux.git powerpc-3.19-2 tag

[Michael Ellerman]

Hi Linus,

Please pull the second batch of powerpc updates for 3.19:

The following changes since commit 56548fc0e86cb9156af7a7e1f15ba78f251dafaf:

  powerpc/powernv: Return to cpu offline loop when finished in KVM guest 
(2014-12-08 13:16:31 +1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git 
tags/powerpc-3.19-2

for you to fetch changes up to d70a54e2d08510a99b1f10eceeae6f2f7086e226:

  powerpc/powernv: Ignore smt-enabled on Power8 and later (2014-12-18 19:59:21 
+1100)


powerpc updates for 3.19 batch 2

The highlight is the series that reworks the idle management on powernv, which
allows us to use deeper idle states on those machines.

There's the fix from Anton for the "BUG at kernel/smpboot.c:134!" problem.

An i2c driver for powernv. This is acked by Wolfram Sang, and he asked that we
take it through the powerpc tree.

A fix for audit from rgb at Red Hat, acked by Paul Moore who is one of the audit
maintainers.

A patch from Ben to export the symbol map of our OPAL firmware as a sysfs file,
so that tools can use it.

Also some CXL fixes, a couple of powerpc perf fixes, a fix for smt-enabled, and
the patch to add __force to get_user() so we can use bitwise types.


Anton Blanchard (1):
  powerpc: Secondary CPUs must set cpu_callin_map after setting active and 
online

Benjamin Herrenschmidt (1):
  powerpc/powernv: Expose OPAL firmware symbol map

Greg Kurz (1):
  powerpc/powernv: Ignore smt-enabled on Power8 and later

Ian Munsie (3):
  cxl: Change contexts_lock to a mutex to fix sleep while atomic bug
  cxl: Add timeout to process element commands
  cxl: Unmap MMIO regions when detaching a context

Michael S. Tsirkin (1):
  powerpc/uaccess: Allow get_user() with bitwise types

Neelesh Gupta (1):
  i2c: Driver to expose PowerNV platform i2c busses

Paul Mackerras (1):
  powerpc/powernv: Switch off MMU before entering nap/sleep/rvwinkle mode

Richard Guy Briggs (1):
  powerpc: add little endian flag to syscall_get_arch()

Shreyas B. Prabhu (3):
  powerpc/powernv: Enable Offline CPUs to enter deep idle states
  powernv/cpuidle: Redesign idle states management
  powernv/powerpc: Add winkle support for offline cpus

Sukadev Bhattiprolu (1):
  power/perf/hv-24x7: Use kmem_cache_free() instead of kfree

suka...@linux.vnet.ibm.com (1):
  powerpc/perf/hv-24x7: Use per-cpu page buffer

 Documentation/devicetree/bindings/i2c/i2c-opal.txt |  37 +++
 arch/powerpc/include/asm/cpuidle.h |  20 ++
 arch/powerpc/include/asm/opal.h|  42 +++
 arch/powerpc/include/asm/paca.h|  10 +
 arch/powerpc/include/asm/ppc-opcode.h  |   2 +
 arch/powerpc/include/asm/processor.h   |   3 +-
 arch/powerpc/include/asm/reg.h |   4 +
 arch/powerpc/include/asm/syscall.h |   6 +-
 arch/powerpc/include/asm/uaccess.h |   6 +-
 arch/powerpc/kernel/asm-offsets.c  |  11 +
 arch/powerpc/kernel/exceptions-64s.S   |  35 ++-
 arch/powerpc/kernel/idle_power7.S  | 344 ++---
 arch/powerpc/kernel/smp.c  |   9 +-
 arch/powerpc/perf/hv-24x7.c|  23 +-
 arch/powerpc/platforms/powernv/opal-wrappers.S |  39 +++
 arch/powerpc/platforms/powernv/opal.c  |  50 ++-
 arch/powerpc/platforms/powernv/powernv.h   |   2 +
 arch/powerpc/platforms/powernv/setup.c | 166 ++
 arch/powerpc/platforms/powernv/smp.c   |  29 +-
 arch/powerpc/platforms/powernv/subcore.c   |  34 ++
 arch/powerpc/platforms/powernv/subcore.h   |   9 +-
 drivers/cpuidle/cpuidle-powernv.c  |  10 +-
 drivers/i2c/busses/Kconfig |  11 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-opal.c  | 294 ++
 drivers/misc/cxl/context.c |  26 +-
 drivers/misc/cxl/cxl.h |   9 +-
 drivers/misc/cxl/file.c|   6 +-
 drivers/misc/cxl/native.c  |  12 +-
 drivers/misc/cxl/pci.c |   2 +-
 drivers/misc/cxl/sysfs.c   |  10 +-
 include/uapi/linux/audit.h |   2 +
 32 files changed, 1156 insertions(+), 108 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-opal.txt
 create mode 100644 arch/powerpc/include/asm/cpuidle.h
 create mode 100644 drivers/i2c/busses/i2c-opal.c



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

Re: [PATCH] arm64: psci: Support generic pm suspend withtout CPUIDLE subsystem's help.

[Lorenzo Pieralisi]

On Fri, Dec 19, 2014 at 05:32:54AM +, Jonghwa Lee wrote:
> Current psci's cpu_suspend callback can be used only when common cpu idle
> configuration is enabled. However, it's also needed for system which only
> uses generic pm suspend not cpu idle. This patch modifies psci driver to
> support both of cases.
> 
> Signed-off-by: Jonghwa Lee 

NAK. Apart from:

1) being buggy (how can you use your code when both SUSPEND and CPUidle
   are on)
2) not providing a patch to show how you use the API

that's not how I planned to implement system suspend, bear with me for
a couple of days and I will post an RFC publicly beginning of January.

Amit already posted a different solution and I've already replied to him:
http://www.spinics.net/lists/arm-kernel/msg373447.html

Lorenzo

> ---
>  arch/arm64/kernel/psci.c |   41 +
>  1 file changed, 29 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index f1dbca7..06d5527 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -35,6 +35,13 @@
>  #define PSCI_POWER_STATE_TYPE_STANDBY0
>  #define PSCI_POWER_STATE_TYPE_POWER_DOWN 1
>  
> +enum psci_affinity_level {
> + PSCI_AFFINITY_LEVEL_0,
> + PSCI_AFFINITY_LEVEL_1,
> + PSCI_AFFINITY_LEVEL_2,
> + PSCI_AFFINITY_LEVEL_3,
> +};
> +
>  struct psci_power_state {
>   u16 id;
>   u8  type;
> @@ -513,27 +520,37 @@ static int psci_suspend_finisher(unsigned long index)
>  {
>   struct psci_power_state *state = __this_cpu_read(psci_power_state);
>  
> + /* Generic PM suspend without CPUIDLE functionality */
> + if (!state) {
> + struct psci_power_state s = {
> + .affinity_level = PSCI_AFFINITY_LEVEL_3,
> + .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
> + };
> + return psci_ops.cpu_suspend(s, virt_to_phys(cpu_resume));
> + }
> +
>   return psci_ops.cpu_suspend(state[index - 1],
>   virt_to_phys(cpu_resume));
>  }
>  
>  static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
>  {
> - int ret;
>   struct psci_power_state *state = __this_cpu_read(psci_power_state);
> - /*
> -  * idle state index 0 corresponds to wfi, should never be called
> -  * from the cpu_suspend operations
> -  */
> - if (WARN_ON_ONCE(!index))
> - return -EINVAL;
>  
> - if (state[index - 1].type == PSCI_POWER_STATE_TYPE_STANDBY)
> - ret = psci_ops.cpu_suspend(state[index - 1], 0);
> - else
> - ret = __cpu_suspend(index, psci_suspend_finisher);
> + if (state) {
> + if (WARN_ON_ONCE(!index))
> + return -EINVAL;
> +
> + /*
> +  * If idle state initialization is successfully done,
> +  * idle state index 0 corresponds to wfi, should never be
> +  * called from the cpu_suspend operations
> +  */
> + if (state[index - 1].type == PSCI_POWER_STATE_TYPE_STANDBY)
> + return psci_ops.cpu_suspend(state[index - 1], 0);
> + }
>  
> - return ret;
> + return __cpu_suspend(index, psci_suspend_finisher);
>  }
>  
>  const struct cpu_operations cpu_psci_ops = {
> -- 
> 1.7.9.5
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 544/544] Staging: comedi: fix spacing style issues in ni_stc.h This is a patch to the ni_stc.h file that removes spaces before tabs, and adds blank lines after declarations.

[Sage Vaillancourt]

---
 drivers/staging/comedi/drivers/ni_stc.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_stc.h 
b/drivers/staging/comedi/drivers/ni_stc.h
index bd69c3f..a79fd07 100644
--- a/drivers/staging/comedi/drivers/ni_stc.h
+++ b/drivers/staging/comedi/drivers/ni_stc.h
@@ -166,7 +166,7 @@ enum Interrupt_B_Ack_Bits {
 #define AI_SCAN_IN_PROG_Pulse  _bit4
 #define AI_EXTMUX_CLK_Pulse_bit3
 #define AI_LOCALMUX_CLK_Pulse  _bit2
-#define AI_SC_TC_Pulse _bit1
+#define AI_SC_TC_Pulse _bit1
 #define AI_CONVERT_Pulse   _bit0
 
 #define AO_Command_1_Register  9
@@ -326,6 +326,7 @@ static inline unsigned RTSI_Output_Bit(unsigned channel, 
int is_mseries)
 {
unsigned max_channel;
unsigned base_bit_shift;
+
if (is_mseries) {
base_bit_shift = 8;
max_channel = 7;
@@ -642,7 +643,7 @@ static unsigned AO_UPDATE_Output_Select(enum 
ao_update_output_selection
 #define G_Load_Source_Select   _bit7
 #define G_Reload_Source_Switching  _bit15
 #define G_Loading_On_Gate  _bit14
-#define G_Gate_Polarity_bit13
+#define G_Gate_Polarity_bit13
 
 #define G_Counting_Once(a) (((a)&0x03)<<10)
 #define G_Stop_Mode(a) (((a)&0x03)<<5)
@@ -1142,6 +1143,7 @@ static inline unsigned MSeries_AI_Config_Bank_Bits(enum 
ni_reg_type reg_type,
   unsigned channel)
 {
unsigned bits = channel & 0x30;
+
if (reg_type == ni_reg_622x) {
if (channel & 0x40)
bits |= 0x400;
@@ -1191,6 +1193,7 @@ enum MSeries_PLL_Control_Bits {
 static inline unsigned MSeries_PLL_Divisor_Bits(unsigned divisor)
 {
static const unsigned max_divisor = 0x10;
+
if (divisor < 1 || divisor > max_divisor) {
pr_err("%s: bug, invalid divisor=%i\n", __func__, divisor);
return 0;
@@ -1201,6 +1204,7 @@ static inline unsigned MSeries_PLL_Divisor_Bits(unsigned 
divisor)
 static inline unsigned MSeries_PLL_Multiplier_Bits(unsigned multiplier)
 {
static const unsigned max_multiplier = 0x100;
+
if (multiplier < 1 || multiplier > max_multiplier) {
pr_err("%s: bug, invalid multiplier=%i\n", __func__,
   multiplier);
-- 
2.2.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: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[B Viswanath]

On 19 December 2014 at 14:31, B Viswanath  wrote:
> On 19 December 2014 at 13:57, Jiri Pirko  wrote:
>> Fri, Dec 19, 2014 at 06:14:57AM CET, marichi...@gmail.com wrote:
>>>On 19 December 2014 at 05:18, Roopa Prabhu  wrote:
 On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
> 
>
>
> We also need an interface to set per-switch attributes. Can this work?
> bridge link set dev sw0 sw_attr bcast_flooding 1 master
> where sw0 is a bridge representing the hardware switch.


 Not today. We discussed this @ LPC, and one way to do this would be to have
 a device
 representing the switch asic. This is in the works.
>>>
>>>
>>>Can I assume that on  platforms which house more than one asic (say
>>>two 24 port asics, interconnected via a 10G link or equivalent, to get
>>>a 48 port 'switch') , the 'rocker' driver (or similar) should expose
>>>them as a single set of ports, and not as two 'switch ports' ?
>>
>> Well that really depends on particular implementation and drivers. If you
>> have 2 pci-e devices, I think you should expose them as 2 entities. For
>> sure, you can have the driver to do the masking for you. I don't believe
>> that is correct though.
>>
>
> In a platform that houses two asic chips, IMO, the user is still
> expected to manage the router as a single entity. The configuration
> being applied on both asic devices need to be matching if not
> identical, and may not be conflicting. The FDB is to be synchronized
> so that (offloaded) switching can happen across the asics. Some of
> this stuff is asic specific anyway. Another example is that of the
> learning. The (hardware) learning can't be enabled on one asic, while
> being disabled on another one. The general use cases I have seen are
> all involving managing the 'router' as a single entity.  That the
> 'router' is implemented with two asics instead of a single asic (with
> more ports) is to be treated as an implementation detail.  This is the
> usual router management method that exists today.
>
> I hope I make sense.
>
> So I am trying to figure out what this single entity that will be used
> from a user perspective. It can be a bridge, but our bridges are more
> 802.1q bridges. We can use the 'self' mode, but then it means that it
> should reflect the entire port count, and not just an asic.
>
> So I was trying to deduce that in our switchdevice model, the best bet
> would be to leave the unification to the driver (i.e., to project the
> multiple physical asics as a single virtual switch device). This
> allows any 'switch' level configurations to the bridge in 'self' mode.
>
> And  then we would need to consider stacking. Stacking differs from
> this multi-asic scenario since  there would be multiple CPU involved.
>
> Thanks
> Vissu
>

Another example i can provide is that of mirroring. Imagine user
wanted to mirror all traffic from port 1 of asic 1 to port 2 of asic
2. This can be offloaded to hardware. However, user would be able to
enter such a command only if he/she can look at a single management
entity.

Thanks
Vissu

>>>


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

[PATCH] MAINTAINERS: Update rydberg's addresses

[Henrik Rydberg]

My ISP finally gave up on the old mail address, so I am moving things
over to bitmath.org instead. Also change the status fields to better
reflect reality.

Signed-off-by: Henrik Rydberg 
---
 MAINTAINERS | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c721042..62b53e8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -714,15 +714,15 @@ F:include/uapi/linux/apm_bios.h
 F: drivers/char/apm-emulation.c
 
 APPLE BCM5974 MULTITOUCH DRIVER
-M: Henrik Rydberg 
+M: Henrik Rydberg 
 L: linux-in...@vger.kernel.org
-S: Maintained
+S: Odd fixes
 F: drivers/input/mouse/bcm5974.c
 
 APPLE SMC DRIVER
-M: Henrik Rydberg 
+M: Henrik Rydberg 
 L: lm-sens...@lm-sensors.org
-S: Maintained
+S: Odd fixes
 F: drivers/hwmon/applesmc.c
 
 APPLETALK NETWORK LAYER
@@ -4813,10 +4813,10 @@ F:  include/uapi/linux/input.h
 F: include/linux/input/
 
 INPUT MULTITOUCH (MT) PROTOCOL
-M: Henrik Rydberg 
+M: Henrik Rydberg 
 L: linux-in...@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/rydberg/input-mt.git
-S: Maintained
+S: Odd fixes
 F: Documentation/input/multi-touch-protocol.txt
 F: drivers/input/input-mt.c
 K: \b(ABS|SYN)_MT_
-- 
2.1.3

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

Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[Jiri Pirko]

Fri, Dec 19, 2014 at 10:01:46AM CET, marichi...@gmail.com wrote:
>On 19 December 2014 at 13:57, Jiri Pirko  wrote:
>> Fri, Dec 19, 2014 at 06:14:57AM CET, marichi...@gmail.com wrote:
>>>On 19 December 2014 at 05:18, Roopa Prabhu  wrote:
 On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
>
>
>
> We also need an interface to set per-switch attributes. Can this work?
> bridge link set dev sw0 sw_attr bcast_flooding 1 master
> where sw0 is a bridge representing the hardware switch.


 Not today. We discussed this @ LPC, and one way to do this would be to have
 a device
 representing the switch asic. This is in the works.
>>>
>>>
>>>Can I assume that on  platforms which house more than one asic (say
>>>two 24 port asics, interconnected via a 10G link or equivalent, to get
>>>a 48 port 'switch') , the 'rocker' driver (or similar) should expose
>>>them as a single set of ports, and not as two 'switch ports' ?
>>
>> Well that really depends on particular implementation and drivers. If you
>> have 2 pci-e devices, I think you should expose them as 2 entities. For
>> sure, you can have the driver to do the masking for you. I don't believe
>> that is correct though.
>>
>
>In a platform that houses two asic chips, IMO, the user is still
>expected to manage the router as a single entity. The configuration
>being applied on both asic devices need to be matching if not
>identical, and may not be conflicting. The FDB is to be synchronized
>so that (offloaded) switching can happen across the asics. Some of
>this stuff is asic specific anyway. Another example is that of the
>learning. The (hardware) learning can't be enabled on one asic, while
>being disabled on another one. The general use cases I have seen are
>all involving managing the 'router' as a single entity.  That the
>'router' is implemented with two asics instead of a single asic (with
>more ports) is to be treated as an implementation detail.  This is the
>usual router management method that exists today.
>
>I hope I make sense.
>
>So I am trying to figure out what this single entity that will be used
>from a user perspective. It can be a bridge, but our bridges are more
>802.1q bridges. We can use the 'self' mode, but then it means that it
>should reflect the entire port count, and not just an asic.
>
>So I was trying to deduce that in our switchdevice model, the best bet
>would be to leave the unification to the driver (i.e., to project the
>multiple physical asics as a single virtual switch device). This

Is it possible to have the asic as just single one? Or is it possible to
connect asics being multiple chips maybe from multiple vendors together?
I believe that answer is "yes" in both cases. Making two separate asics
to appear as one for user is not correct in my opinion. Driver should
not do such masking. It is unclean, unextendable.


>allows any 'switch' level configurations to the bridge in 'self' mode.
>
>And  then we would need to consider stacking. Stacking differs from
>this multi-asic scenario since  there would be multiple CPU involved.
>
>Thanks
>Vissu
>
>>>


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

[PATCH v3] lib: bitmap: Make the bits parameter of bitmap_remap unsigned

[Rasmus Villemoes]

Also, rename bits to nbits. Both changes for consistency with other
bitmap_* functions.

Signed-off-by: Rasmus Villemoes 
---

Notes:
v3: Hopefully complete and unambiguous commit log.

v2: Only do the signed->unsigned conversion. bitmap_remap only has a
single caller (via nodes_remap), so bloating it by special-casing
empty new isn't justified (and the commit log was wrong; it said
"empty dst").

 include/linux/bitmap.h |  2 +-
 lib/bitmap.c   | 16 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index e1c8d080c427..1a634b0e0cbe 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -133,7 +133,7 @@ extern int bitmap_parselist(const char *buf, unsigned long 
*maskp,
 extern int bitmap_parselist_user(const char __user *ubuf, unsigned int ulen,
unsigned long *dst, int nbits);
 extern void bitmap_remap(unsigned long *dst, const unsigned long *src,
-   const unsigned long *old, const unsigned long *new, int bits);
+   const unsigned long *old, const unsigned long *new, unsigned 
int nbits);
 extern int bitmap_bitremap(int oldbit,
const unsigned long *old, const unsigned long *new, int bits);
 extern void bitmap_onto(unsigned long *dst, const unsigned long *orig,
diff --git a/lib/bitmap.c b/lib/bitmap.c
index b499ab6ada29..5884b974407b 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -788,7 +788,7 @@ int bitmap_ord_to_pos(const unsigned long *buf, int ord, 
int bits)
  * @src: subset to be remapped
  * @old: defines domain of map
  * @new: defines range of map
- * @bits: number of bits in each of these bitmaps
+ * @nbits: number of bits in each of these bitmaps
  *
  * Let @old and @new define a mapping of bit positions, such that
  * whatever position is held by the n-th set bit in @old is mapped
@@ -816,22 +816,22 @@ int bitmap_ord_to_pos(const unsigned long *buf, int ord, 
int bits)
  */
 void bitmap_remap(unsigned long *dst, const unsigned long *src,
const unsigned long *old, const unsigned long *new,
-   int bits)
+   unsigned int nbits)
 {
-   int oldbit, w;
+   unsigned int oldbit, w;
 
if (dst == src) /* following doesn't handle inplace remaps */
return;
-   bitmap_zero(dst, bits);
+   bitmap_zero(dst, nbits);
 
-   w = bitmap_weight(new, bits);
-   for_each_set_bit(oldbit, src, bits) {
-   int n = bitmap_pos_to_ord(old, oldbit, bits);
+   w = bitmap_weight(new, nbits);
+   for_each_set_bit(oldbit, src, nbits) {
+   int n = bitmap_pos_to_ord(old, oldbit, nbits);
 
if (n < 0 || w == 0)
set_bit(oldbit, dst);   /* identity map */
else
-   set_bit(bitmap_ord_to_pos(new, n % w, bits), dst);
+   set_bit(bitmap_ord_to_pos(new, n % w, nbits), dst);
}
 }
 EXPORT_SYMBOL(bitmap_remap);
-- 
2.1.3

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

[PATCH 1/2] regulator: max77693: Let core parse DT and drop board files support

[Krzysztof Kozlowski]

Simplify the driver by removing board file support and letting
regulator core to parse DT.

The max77693 regulator driver is used only on Exynos based boards which
are DT-only. Board files are not supported.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/max77693.c | 93 +---
 1 file changed, 9 insertions(+), 84 deletions(-)

diff --git a/drivers/regulator/max77693.c b/drivers/regulator/max77693.c
index 07b313e51b21..9665a488e2f1 100644
--- a/drivers/regulator/max77693.c
+++ b/drivers/regulator/max77693.c
@@ -128,6 +128,8 @@ static struct regulator_ops max77693_charger_ops = {
 #define regulator_desc_esafeout(_num)  {   \
.name   = "ESAFEOUT"#_num,  \
.id = MAX77693_ESAFEOUT##_num,  \
+   .of_match   = of_match_ptr("ESAFEOUT"#_num),\
+   .regulators_node= of_match_ptr("regulators"),   \
.n_voltages = 4,\
.ops= &max77693_safeout_ops,\
.type   = REGULATOR_VOLTAGE,\
@@ -145,6 +147,8 @@ static const struct regulator_desc regulators[] = {
{
.name = "CHARGER",
.id = MAX77693_CHARGER,
+   .of_match = of_match_ptr("CHARGER"),
+   .regulators_node = of_match_ptr("regulators"),
.ops = &max77693_charger_ops,
.type = REGULATOR_CURRENT,
.owner = THIS_MODULE,
@@ -154,102 +158,23 @@ static const struct regulator_desc regulators[] = {
},
 };
 
-#ifdef CONFIG_OF
-static int max77693_pmic_dt_parse_rdata(struct device *dev,
-   struct max77693_regulator_data **rdata)
-{
-   struct device_node *np;
-   struct of_regulator_match *rmatch;
-   struct max77693_regulator_data *tmp;
-   int i, matched = 0;
-
-   np = of_get_child_by_name(dev->parent->of_node, "regulators");
-   if (!np)
-   return -EINVAL;
-
-   rmatch = devm_kzalloc(dev,
-sizeof(*rmatch) * ARRAY_SIZE(regulators), GFP_KERNEL);
-   if (!rmatch) {
-   of_node_put(np);
-   return -ENOMEM;
-   }
-
-   for (i = 0; i < ARRAY_SIZE(regulators); i++)
-   rmatch[i].name = regulators[i].name;
-
-   matched = of_regulator_match(dev, np, rmatch, ARRAY_SIZE(regulators));
-   of_node_put(np);
-   if (matched <= 0)
-   return matched;
-   *rdata = devm_kzalloc(dev, sizeof(**rdata) * matched, GFP_KERNEL);
-   if (!(*rdata))
-   return -ENOMEM;
-
-   tmp = *rdata;
-
-   for (i = 0; i < matched; i++) {
-   tmp->initdata = rmatch[i].init_data;
-   tmp->of_node = rmatch[i].of_node;
-   tmp->id = regulators[i].id;
-   tmp++;
-   }
-
-   return matched;
-}
-#else
-static int max77693_pmic_dt_parse_rdata(struct device *dev,
-   struct max77693_regulator_data **rdata)
-{
-   return 0;
-}
-#endif /* CONFIG_OF */
-
-static int max77693_pmic_init_rdata(struct device *dev,
-   struct max77693_regulator_data **rdata)
-{
-   struct max77693_platform_data *pdata;
-   int num_regulators = 0;
-
-   pdata = dev_get_platdata(dev->parent);
-   if (pdata) {
-   *rdata = pdata->regulators;
-   num_regulators = pdata->num_regulators;
-   }
-
-   if (!(*rdata) && dev->parent->of_node)
-   num_regulators = max77693_pmic_dt_parse_rdata(dev, rdata);
-
-   return num_regulators;
-}
-
 static int max77693_pmic_probe(struct platform_device *pdev)
 {
struct max77693_dev *iodev = dev_get_drvdata(pdev->dev.parent);
-   struct max77693_regulator_data *rdata = NULL;
-   int num_rdata, i;
+   int i;
struct regulator_config config = { };
 
-   num_rdata = max77693_pmic_init_rdata(&pdev->dev, &rdata);
-   if (!rdata || num_rdata <= 0) {
-   dev_err(&pdev->dev, "No init data supplied.\n");
-   return -ENODEV;
-   }
-
-   config.dev = &pdev->dev;
+   config.dev = iodev->dev;
config.regmap = iodev->regmap;
 
-   for (i = 0; i < num_rdata; i++) {
-   int id = rdata[i].id;
+   for (i = 0; i < ARRAY_SIZE(regulators); i++) {
struct regulator_dev *rdev;
 
-   config.init_data = rdata[i].initdata;
-   config.of_node = rdata[i].of_node;
-
rdev = devm_regulator_register(&pdev->dev,
-   ®ulators[id], &config);
+   ®ulators[i], &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev,
-   "Failed to initialize regulator-%d\n", id);
+

[PATCH 0/2] regulator: Simplify max77693 driver

[Krzysztof Kozlowski]

Hi,

Simplify the max77693 regulator driver by moving DT parse code out
to regulator core.

This removes also board file support. Exynos based boards are DT-only.
This removal allows bigger simplification of driver so overall diffstat
is nice: -95 deletions, 12 additions.

The patch 2/2 depends on first patch so please apply everything at once
or leave second patch for later.

Best regards,
Krzysztof

Krzysztof Kozlowski (2):
  regulator: max77693: Let core parse DT and drop board files support
  mfd: max77693: Remove unused structures

 drivers/regulator/max77693.c | 93 +---
 include/linux/mfd/max77693.h | 12 +-
 2 files changed, 10 insertions(+), 95 deletions(-)

-- 
1.9.1

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

[PATCH 2/2] mfd: max77693: Remove unused structures

[Krzysztof Kozlowski]

The max77693 regulator driver no longer supports board files. Remove the
left-overs. Additionally fix name of device in comment.

Signed-off-by: Krzysztof Kozlowski 
---
 include/linux/mfd/max77693.h | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index f0b6585cd874..09a4dedaeea8 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -30,7 +30,7 @@
 #ifndef __LINUX_MFD_MAX77693_H
 #define __LINUX_MFD_MAX77693_H
 
-/* MAX77686 regulator IDs */
+/* MAX77693 regulator IDs */
 enum max77693_regulators {
MAX77693_ESAFEOUT1 = 0,
MAX77693_ESAFEOUT2,
@@ -38,12 +38,6 @@ enum max77693_regulators {
MAX77693_REG_MAX,
 };
 
-struct max77693_regulator_data {
-   int id;
-   struct regulator_init_data *initdata;
-   struct device_node *of_node;
-};
-
 struct max77693_reg_data {
u8 addr;
u8 data;
@@ -103,10 +97,6 @@ struct max77693_led_platform_data {
 /* MAX77693 */
 
 struct max77693_platform_data {
-   /* regulator data */
-   struct max77693_regulator_data *regulators;
-   int num_regulators;
-
/* muic data */
struct max77693_muic_platform_data *muic_data;
struct max77693_led_platform_data *led_data;
-- 
1.9.1

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

[PATCH] media: Kconfig: drop duplicate dependency of HAS_DMA

[Lad, Prabhakar]

this patch drops duplicate dependency of HAS_DMA from
VIDEO_SH_VEU.

Signed-off-by: Lad, Prabhakar 
---
 drivers/media/platform/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index dba29b8..dac316d 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -213,7 +213,6 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
 config VIDEO_SH_VEU
tristate "SuperH VEU mem2mem video processing driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
-   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
-- 
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: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[Jiri Pirko]

Fri, Dec 19, 2014 at 10:22:24AM CET, marichi...@gmail.com wrote:
>On 19 December 2014 at 14:31, B Viswanath  wrote:
>> On 19 December 2014 at 13:57, Jiri Pirko  wrote:
>>> Fri, Dec 19, 2014 at 06:14:57AM CET, marichi...@gmail.com wrote:
On 19 December 2014 at 05:18, Roopa Prabhu  
wrote:
> On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
>> 
>>
>>
>> We also need an interface to set per-switch attributes. Can this work?
>> bridge link set dev sw0 sw_attr bcast_flooding 1 master
>> where sw0 is a bridge representing the hardware switch.
>
>
> Not today. We discussed this @ LPC, and one way to do this would be to 
> have
> a device
> representing the switch asic. This is in the works.


Can I assume that on  platforms which house more than one asic (say
two 24 port asics, interconnected via a 10G link or equivalent, to get
a 48 port 'switch') , the 'rocker' driver (or similar) should expose
them as a single set of ports, and not as two 'switch ports' ?
>>>
>>> Well that really depends on particular implementation and drivers. If you
>>> have 2 pci-e devices, I think you should expose them as 2 entities. For
>>> sure, you can have the driver to do the masking for you. I don't believe
>>> that is correct though.
>>>
>>
>> In a platform that houses two asic chips, IMO, the user is still
>> expected to manage the router as a single entity. The configuration
>> being applied on both asic devices need to be matching if not
>> identical, and may not be conflicting. The FDB is to be synchronized
>> so that (offloaded) switching can happen across the asics. Some of
>> this stuff is asic specific anyway. Another example is that of the
>> learning. The (hardware) learning can't be enabled on one asic, while
>> being disabled on another one. The general use cases I have seen are
>> all involving managing the 'router' as a single entity.  That the
>> 'router' is implemented with two asics instead of a single asic (with
>> more ports) is to be treated as an implementation detail.  This is the
>> usual router management method that exists today.
>>
>> I hope I make sense.
>>
>> So I am trying to figure out what this single entity that will be used
>> from a user perspective. It can be a bridge, but our bridges are more
>> 802.1q bridges. We can use the 'self' mode, but then it means that it
>> should reflect the entire port count, and not just an asic.
>>
>> So I was trying to deduce that in our switchdevice model, the best bet
>> would be to leave the unification to the driver (i.e., to project the
>> multiple physical asics as a single virtual switch device). This
>> allows any 'switch' level configurations to the bridge in 'self' mode.
>>
>> And  then we would need to consider stacking. Stacking differs from
>> this multi-asic scenario since  there would be multiple CPU involved.
>>
>> Thanks
>> Vissu
>>
>
>Another example i can provide is that of mirroring. Imagine user
>wanted to mirror all traffic from port 1 of asic 1 to port 2 of asic
>2. This can be offloaded to hardware. However, user would be able to
>enter such a command only if he/she can look at a single management
>entity.

I understand your use case. I think this could be handled by higher
entity. In this sase tome userspace agent which would be aware (by
configuration) of all asics and how they are interconnected. Just a
thought. Seem much nice than to do custom masking in drivers.

>
>Thanks
>Vissu
>

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

Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[B Viswanath]

On 19 December 2014 at 14:53, Jiri Pirko  wrote:
> Fri, Dec 19, 2014 at 10:01:46AM CET, marichi...@gmail.com wrote:
>>On 19 December 2014 at 13:57, Jiri Pirko  wrote:
>>> Fri, Dec 19, 2014 at 06:14:57AM CET, marichi...@gmail.com wrote:
On 19 December 2014 at 05:18, Roopa Prabhu  
wrote:
> On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
>>
>>
>>
>> We also need an interface to set per-switch attributes. Can this work?
>> bridge link set dev sw0 sw_attr bcast_flooding 1 master
>> where sw0 is a bridge representing the hardware switch.
>
>
> Not today. We discussed this @ LPC, and one way to do this would be to 
> have
> a device
> representing the switch asic. This is in the works.


Can I assume that on  platforms which house more than one asic (say
two 24 port asics, interconnected via a 10G link or equivalent, to get
a 48 port 'switch') , the 'rocker' driver (or similar) should expose
them as a single set of ports, and not as two 'switch ports' ?
>>>
>>> Well that really depends on particular implementation and drivers. If you
>>> have 2 pci-e devices, I think you should expose them as 2 entities. For
>>> sure, you can have the driver to do the masking for you. I don't believe
>>> that is correct though.
>>>
>>
>>In a platform that houses two asic chips, IMO, the user is still
>>expected to manage the router as a single entity. The configuration
>>being applied on both asic devices need to be matching if not
>>identical, and may not be conflicting. The FDB is to be synchronized
>>so that (offloaded) switching can happen across the asics. Some of
>>this stuff is asic specific anyway. Another example is that of the
>>learning. The (hardware) learning can't be enabled on one asic, while
>>being disabled on another one. The general use cases I have seen are
>>all involving managing the 'router' as a single entity.  That the
>>'router' is implemented with two asics instead of a single asic (with
>>more ports) is to be treated as an implementation detail.  This is the
>>usual router management method that exists today.
>>
>>I hope I make sense.
>>
>>So I am trying to figure out what this single entity that will be used
>>from a user perspective. It can be a bridge, but our bridges are more
>>802.1q bridges. We can use the 'self' mode, but then it means that it
>>should reflect the entire port count, and not just an asic.
>>
>>So I was trying to deduce that in our switchdevice model, the best bet
>>would be to leave the unification to the driver (i.e., to project the
>>multiple physical asics as a single virtual switch device). Thist
>
> Is it possible to have the asic as just single one? Or is it possible to
> connect asics being multiple chips maybe from multiple vendors together?

I didn't understand the first question. Some times, it is possible to
have a single asic replace two, but its a cost factor, and others that
are involved.

AFAIK, the answer to the second question is a No. Two asics from
different vendors may not be connected together. The interconnect
tends to be proprietary.

> I believe that answer is "yes" in both cases. Making two separate asics
> to appear as one for user is not correct in my opinion. Driver should
> not do such masking. It is unclean, unextendable.
>

I am only looking for a single management entity. I am not thinking it
needs to be at driver level. I am not sure of  any other option apart
from creating a 'switchdev' that Roopa was mentioning.

>
>>allows any 'switch' level configurations to the bridge in 'self' mode.
>>
>>And  then we would need to consider stacking. Stacking differs from
>>this multi-asic scenario since  there would be multiple CPU involved.
>>
>>Thanks
>>Vissu
>>

>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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/

[RESEND PATCH v7 0/5] hwmon: ina2xx: implement chip reinitialization and add new attributes

[Bartosz Golaszewski]

This series implements a mechanism to detect if the chip is in its POR state
and reinitialize it if needed. It also extends the sysfs interface to make the
driver configurable at run-time.

The shunt_resistor attribute allows to change the shunt resistance value
at run-time in cases where ina2xx used to do the measurement isn't integrated
with the shunt.

The avg_rate attribute allows to increase/decrease noise reduction.

v7:
- implemented a retry counter for the reinitialization procedure
- using msleep() (since the sleep is > 20ms) instead of mdelay()
  when waiting for the chip update

v6:
https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg787390.html

Bartosz Golaszewski (5):
  hwmon: ina2xx: reinitialize the chip in case it's been reset
  hwmon: ina2xx: remove a stray new line
  hwmon: ina2xx: don't accept shunt values greater than the calibration factor
  hwmon: ina2xx: make shunt resistance configurable at run-time
  hwmon: ina2xx: allow to change the averaging rate at run-time

 Documentation/hwmon/ina2xx |   8 +-
 drivers/hwmon/ina2xx.c | 304 +++--
 2 files changed, 269 insertions(+), 43 deletions(-)

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

[RESEND PATCH v7 4/5] hwmon: ina2xx: make shunt resistance configurable at run-time

[Bartosz Golaszewski]

The shunt resistance can only be set via platform_data or device tree. This
isn't suitable for devices in which the shunt resistance can change/isn't
known at boot-time.

Add a sysfs attribute that allows to read and set the shunt resistance.

Signed-off-by: Bartosz Golaszewski 
---
 Documentation/hwmon/ina2xx |  5 +++--
 drivers/hwmon/ina2xx.c | 48 --
 2 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index 4223c2d..320dd69 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -44,6 +44,7 @@ The INA226 monitors both a shunt voltage drop and bus supply 
voltage.
 The INA230 is a high or low side current shunt and power monitor with an I2C
 interface. The INA230 monitors both a shunt voltage drop and bus supply 
voltage.
 
-The shunt value in micro-ohms can be set via platform data or device tree.
-Please refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for 
bindings
+The shunt value in micro-ohms can be set via platform data or device tree at
+compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
+refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
 if the device tree is used.
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 3234e57..49537ea 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -115,6 +115,12 @@ static const struct ina2xx_config ina2xx_config[] = {
},
 };
 
+static int ina2xx_calibrate(struct ina2xx_data *data)
+{
+   return i2c_smbus_write_word_swapped(data->client, INA2XX_CALIBRATION,
+   data->config->calibration_factor / data->rshunt);
+}
+
 /*
  * Initialize the configuration and calibration registers.
  */
@@ -133,8 +139,7 @@ static int ina2xx_init(struct ina2xx_data *data)
 * Set current LSB to 1mA, shunt is in uOhms
 * (equation 13 in datasheet).
 */
-   return i2c_smbus_write_word_swapped(client, INA2XX_CALIBRATION,
-   data->config->calibration_factor / data->rshunt);
+   return ina2xx_calibrate(data);
 }
 
 static int ina2xx_do_update(struct device *dev)
@@ -231,6 +236,9 @@ static int ina2xx_get_value(struct ina2xx_data *data, u8 
reg)
/* signed register, LSB=1mA (selected), in mA */
val = (s16)data->regs[reg];
break;
+   case INA2XX_CALIBRATION:
+   val = data->config->calibration_factor / data->regs[reg];
+   break;
default:
/* programmer goofed */
WARN_ON_ONCE(1);
@@ -254,6 +262,36 @@ static ssize_t ina2xx_show_value(struct device *dev,
ina2xx_get_value(data, attr->index));
 }
 
+static ssize_t ina2xx_set_shunt(struct device *dev,
+   struct device_attribute *da,
+   const char *buf, size_t count)
+{
+   struct ina2xx_data *data = ina2xx_update_device(dev);
+   unsigned long val;
+   int status;
+
+   if (IS_ERR(data))
+   return PTR_ERR(data);
+
+   status = kstrtoul(buf, 10, &val);
+   if (status < 0)
+   return status;
+
+   if (val == 0 ||
+   /* Values greater than the calibration factor make no sense. */
+   val > data->config->calibration_factor)
+   return -EINVAL;
+
+   mutex_lock(&data->update_lock);
+   data->rshunt = val;
+   status = ina2xx_calibrate(data);
+   mutex_unlock(&data->update_lock);
+   if (status < 0)
+   return status;
+
+   return count;
+}
+
 /* shunt voltage */
 static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, ina2xx_show_value, NULL,
  INA2XX_SHUNT_VOLTAGE);
@@ -270,12 +308,18 @@ static SENSOR_DEVICE_ATTR(curr1_input, S_IRUGO, 
ina2xx_show_value, NULL,
 static SENSOR_DEVICE_ATTR(power1_input, S_IRUGO, ina2xx_show_value, NULL,
  INA2XX_POWER);
 
+/* shunt resistance */
+static SENSOR_DEVICE_ATTR(shunt_resistor, S_IRUGO | S_IWUSR,
+ ina2xx_show_value, ina2xx_set_shunt,
+ INA2XX_CALIBRATION);
+
 /* pointers to created device attributes */
 static struct attribute *ina2xx_attrs[] = {
&sensor_dev_attr_in0_input.dev_attr.attr,
&sensor_dev_attr_in1_input.dev_attr.attr,
&sensor_dev_attr_curr1_input.dev_attr.attr,
&sensor_dev_attr_power1_input.dev_attr.attr,
+   &sensor_dev_attr_shunt_resistor.dev_attr.attr,
NULL,
 };
 ATTRIBUTE_GROUPS(ina2xx);
-- 
2.1.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/

[RESEND PATCH v7 1/5] hwmon: ina2xx: reinitialize the chip in case it's been reset

[Bartosz Golaszewski]

Chips from the ina family don't like to be uninitialized. In case the power
is cut-off and restored again the calibration register will be reset
to 0 and both the power and current registers will remain at 0.

Check the calibration register in ina2xx_update_device() and reinitialize
the chip if needed.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/hwmon/ina2xx.c | 128 +++--
 1 file changed, 91 insertions(+), 37 deletions(-)

diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index e01feba..ffbd60f 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -64,6 +65,9 @@
 
 /* worst case is 68.10 ms (~14.6Hz, ina219) */
 #define INA2XX_CONVERSION_RATE 15
+#define INA2XX_MAX_DELAY   69 /* worst case delay in ms */
+
+#define INA2XX_RSHUNT_DEFAULT  1
 
 enum ina2xx_ids { ina219, ina226 };
 
@@ -81,6 +85,8 @@ struct ina2xx_data {
struct i2c_client *client;
const struct ina2xx_config *config;
 
+   long rshunt;
+
struct mutex update_lock;
bool valid;
unsigned long last_updated;
@@ -110,34 +116,96 @@ static const struct ina2xx_config ina2xx_config[] = {
},
 };
 
-static struct ina2xx_data *ina2xx_update_device(struct device *dev)
+/*
+ * Initialize the configuration and calibration registers.
+ */
+static int ina2xx_init(struct ina2xx_data *data)
 {
-   struct ina2xx_data *data = dev_get_drvdata(dev);
struct i2c_client *client = data->client;
-   struct ina2xx_data *ret = data;
+   int ret;
 
-   mutex_lock(&data->update_lock);
+   /* device configuration */
+   ret = i2c_smbus_write_word_swapped(client, INA2XX_CONFIG,
+  data->config->config_default);
+   if (ret < 0)
+   return ret;
 
-   if (time_after(jiffies, data->last_updated +
-  HZ / INA2XX_CONVERSION_RATE) || !data->valid) {
+   /*
+* Set current LSB to 1mA, shunt is in uOhms
+* (equation 13 in datasheet).
+*/
+   return i2c_smbus_write_word_swapped(client, INA2XX_CALIBRATION,
+   data->config->calibration_factor / data->rshunt);
+}
 
-   int i;
+static int ina2xx_do_update(struct device *dev)
+{
+   struct ina2xx_data *data = dev_get_drvdata(dev);
+   struct i2c_client *client = data->client;
+   int i, rv, retry;
 
-   dev_dbg(&client->dev, "Starting ina2xx update\n");
+   dev_dbg(&client->dev, "Starting ina2xx update\n");
 
+   for (retry = 5; retry; retry--) {
/* Read all registers */
for (i = 0; i < data->config->registers; i++) {
-   int rv = i2c_smbus_read_word_swapped(client, i);
-   if (rv < 0) {
-   ret = ERR_PTR(rv);
-   goto abort;
-   }
+   rv = i2c_smbus_read_word_swapped(client, i);
+   if (rv < 0)
+   return rv;
data->regs[i] = rv;
}
+
+   /*
+* If the current value in the calibration register is 0, the
+* power and current registers will also remain at 0. In case
+* the chip has been reset let's check the calibration
+* register and reinitialize if needed.
+*/
+   if (data->regs[INA2XX_CALIBRATION] == 0) {
+   dev_warn(dev, "chip not calibrated, reinitializing\n");
+
+   rv = ina2xx_init(data);
+   if (rv < 0)
+   return rv;
+
+   /*
+* Let's make sure the power and current registers
+* have been updated before trying again.
+*/
+   msleep(INA2XX_MAX_DELAY);
+   continue;
+   }
+
data->last_updated = jiffies;
data->valid = 1;
+
+   return 0;
}
-abort:
+
+   /*
+* If we're here then although all write operations succeeded, the
+* chip still returns 0 in the calibration register. Nothing more we
+* can do here.
+*/
+   dev_err(dev, "unable to reinitialize the chip\n");
+   return -ENODEV;
+}
+
+static struct ina2xx_data *ina2xx_update_device(struct device *dev)
+{
+   struct ina2xx_data *data = dev_get_drvdata(dev);
+   struct ina2xx_data *ret = data;
+   int rv;
+
+   mutex_lock(&data->update_lock);
+
+   if (time_after(jiffies, data->last_updated +
+  HZ / INA2XX_CONVERSION_RATE) || !data->valid) {
+   rv = ina2xx_do_update(dev);
+   if (rv < 0)
+   r

[RESEND PATCH v7 5/5] hwmon: ina2xx: allow to change the averaging rate at run-time

[Bartosz Golaszewski]

The averaging rate of ina226 is hardcoded to 16 in the driver. Make it
modifiable at run-time via a new sysfs attribute.

While we're at it - add an additional variable to ina2xx_data, which holds
the current configuration settings - this way we'll be able to restore the
configuration in case of an unexpected chip reset.

Signed-off-by: Bartosz Golaszewski 
---
 Documentation/hwmon/ina2xx |   3 ++
 drivers/hwmon/ina2xx.c | 132 +++--
 2 files changed, 131 insertions(+), 4 deletions(-)

diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index 320dd69..a11256d 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -48,3 +48,6 @@ The shunt value in micro-ohms can be set via platform data or 
device tree at
 compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
 refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
 if the device tree is used.
+
+The averaging rate of INA226 and INA230 can be changed via the avg_rate sysfs
+attribute. The available rates are: 1, 4, 16, 64, 128, 256, 512 and 1024.
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 49537ea..d6fccad 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -68,6 +68,15 @@
 
 #define INA2XX_RSHUNT_DEFAULT  1
 
+/* bit masks for the averaging setting in the configuration register */
+#define INA226_AVG_RD_MASK 0x0E00
+#define INA226_AVG_WR_MASK 0xF1FF
+
+#define INA226_READ_AVG(reg) ((reg & INA226_AVG_RD_MASK) >> 9)
+
+/* common attrs, ina226 attrs and NULL */
+#define INA2XX_MAX_ATTRIBUTE_GROUPS3
+
 enum ina2xx_ids { ina219, ina226 };
 
 struct ina2xx_config {
@@ -85,12 +94,14 @@ struct ina2xx_data {
const struct ina2xx_config *config;
 
long rshunt;
+   u16 curr_config;
 
struct mutex update_lock;
bool valid;
unsigned long last_updated;
 
int kind;
+   const struct attribute_group *groups[INA2XX_MAX_ATTRIBUTE_GROUPS];
u16 regs[INA2XX_MAX_REGISTERS];
 };
 
@@ -115,6 +126,38 @@ static const struct ina2xx_config ina2xx_config[] = {
},
 };
 
+/*
+ * Available averaging rates for ina226. The indices correspond with
+ * the bit values expected by the chip (according to the ina226 datasheet,
+ * table 3 AVG bit settings, found at
+ * http://www.ti.com/lit/ds/symlink/ina226.pdf.
+ */
+static const int ina226_avg_tab[] = { 1, 4, 16, 64, 128, 256, 512, 1024 };
+
+static int ina226_avg_bits(int avg)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(ina226_avg_tab); i++) {
+   if (avg == ina226_avg_tab[i])
+   return i;
+   }
+
+   return -EINVAL;
+}
+
+static int ina226_avg_val(int bits)
+{
+   /*
+* Value read from the config register should be correct, but do check
+* the boundary just in case.
+*/
+   if (bits >= ARRAY_SIZE(ina226_avg_tab))
+   return -ENODEV;
+
+   return ina226_avg_tab[bits];
+}
+
 static int ina2xx_calibrate(struct ina2xx_data *data)
 {
return i2c_smbus_write_word_swapped(data->client, INA2XX_CALIBRATION,
@@ -131,7 +174,7 @@ static int ina2xx_init(struct ina2xx_data *data)
 
/* device configuration */
ret = i2c_smbus_write_word_swapped(client, INA2XX_CONFIG,
-  data->config->config_default);
+  data->curr_config);
if (ret < 0)
return ret;
 
@@ -292,6 +335,66 @@ static ssize_t ina2xx_set_shunt(struct device *dev,
return count;
 }
 
+static ssize_t ina226_show_avg(struct device *dev,
+  struct device_attribute *da, char *buf)
+{
+   struct ina2xx_data *data = ina2xx_update_device(dev);
+   int avg, i, written = 0;
+   const char *fmt;
+
+   if (IS_ERR(data))
+   return PTR_ERR(data);
+
+   avg = ina226_avg_val(INA226_READ_AVG(data->regs[INA2XX_CONFIG]));
+   if (avg < 0)
+   return avg;
+
+   for (i = 0; i < ARRAY_SIZE(ina226_avg_tab); i++) {
+   if (avg == ina226_avg_tab[i])
+   fmt = "\t[%d]";
+   else
+   fmt = "\t%d";
+
+   written += snprintf(buf + written, PAGE_SIZE - written,
+   fmt, ina226_avg_tab[i]);
+   }
+   written += snprintf(buf + written, PAGE_SIZE - written, "\n");
+
+   return written;
+}
+
+static ssize_t ina226_set_avg(struct device *dev,
+ struct device_attribute *da,
+ const char *buf, size_t count)
+{
+   struct ina2xx_data *data = ina2xx_update_device(dev);
+   long val;
+   int status, avg;
+
+   if (IS_ERR(data))
+   return PTR_ERR(data);
+
+   status = kstrtol(buf, 10, &val);
+   if (status < 0)
+   return status;
+
+   av

[RESEND PATCH v7 2/5] hwmon: ina2xx: remove a stray new line

[Bartosz Golaszewski]

Signed-off-by: Bartosz Golaszewski 
---
 drivers/hwmon/ina2xx.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index ffbd60f..39e017b 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -52,7 +52,6 @@
 #define INA226_ALERT_LIMIT 0x07
 #define INA226_DIE_ID  0xFF
 
-
 /* register count */
 #define INA219_REGISTERS   6
 #define INA226_REGISTERS   8
-- 
2.1.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/

[RESEND PATCH v7 3/5] hwmon: ina2xx: don't accept shunt values greater than the calibration factor

[Bartosz Golaszewski]

Shunt resistance values greater than the chip's calibration factor make no
sense since the actual value written to the register equals:

 / 

Bail-out from ina2xx_probe() if the configured value is greater than the
calibration factor.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/hwmon/ina2xx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 39e017b..3234e57 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -313,7 +313,8 @@ static int ina2xx_probe(struct i2c_client *client,
data->config = &ina2xx_config[data->kind];
data->client = client;
 
-   if (data->rshunt <= 0)
+   if (data->rshunt <= 0 ||
+   data->rshunt > data->config->calibration_factor)
return -ENODEV;
 
ret = ina2xx_init(data);
-- 
2.1.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: Disabled LocalPlus Controller (LPC) clock on MPC512x

[Matteo Facchinetti]

On 16/12/2014 13:00, Alexander Popov wrote:

02.12.2014 13:47, Matteo Facchinetti пишет:

On 26/11/2014 12:49, Alexander Popov wrote:

So starting Linux with clk_ignore_unused bootparam
or inserting dummy LPB reading to some initcall is a temporary fix.


In fact clk_ignore_unused bootparam helps to avoid disabling NFC clock.
The board crash is reproduced again if I perform the following steps:
1. disable NFC clock in uboot by clearing NFC_EN bit in SCCR1 register,
2. boot Linux with clk_ignore_unused,
3. touch any LPB address.



Could you see the Reset Status Register (RSR) after board crash?
When boad reset, you may stop uboot in console and then print the value 
of this register.


This could be help to see what happen internally to the microcontroller.

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

[Petr Mladek]

On Thu 2014-12-18 09:49:35, Josh Poimboeuf wrote:
> On Thu, Dec 18, 2014 at 08:55:21PM +0900, Masami Hiramatsu wrote:
> > (2014/12/17 2:58), Seth Jennings wrote:
> > > changes in v7:
> > > - TODO: set IPMODIFY (not a blocker to moving forward)
> > 
> > Why don't you set this?
> > IPMODIFY series are not completely applied yet, but you can already
> > use the flag. All you need is just set it :)
> 
> Yeah, I don't see any reason why we can't start using this flag now.
> How about we add this patch to the queue?
> 
> -->8--
> 
> Subject: livepatch: use FTRACE_OPS_FL_IPMODIFY
> 
> Use the FTRACE_OPS_FL_IPMODIFY flag to prevent conflicts with other
> ftrace users who also modify regs->ip.
> 
> Signed-off-by: Josh Poimboeuf 

It makes sense. The flag is available even in 3.19.

Reviewed-by: Petr Mladek 

> ---
>  kernel/livepatch/core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index 0004a71..bdd99975 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -640,7 +640,8 @@ static int klp_init_func(struct klp_object *obj, struct 
> klp_func *func)
>  
>   ops->private = func;
>   ops->func = klp_ftrace_handler;
> - ops->flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_DYNAMIC;
> + ops->flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_DYNAMIC |
> +  FTRACE_FL_IPMODIFY;
>   func->fops = ops;
>   func->state = KLP_DISABLED;
>  
> -- 
> 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/

[PATCH] staging: fpga manager: fix odd_ptr_err.cocci warnings

[kbuild test robot]

drivers/staging/fpga/socfpga.c:647:5-11: inconsistent IS_ERR and PTR_ERR, 
PTR_ERR on line 648

 PTR_ERR should access the value just tested by IS_ERR

Semantic patch information:
 There can be false positives in the patch case, where it is the call
 IS_ERR that is wrong.

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

CC: Alan Tull 
Signed-off-by: Fengguang Wu 
---

 socfpga.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/fpga/socfpga.c
+++ b/drivers/staging/fpga/socfpga.c
@@ -645,7 +645,7 @@ static int socfpga_fpga_probe(struct pla
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
priv->fpga_data_addr = devm_ioremap_resource(dev, res);
if (IS_ERR(priv->fpga_data_addr))
-   return PTR_ERR(priv->fpga_base_addr);
+   return PTR_ERR(priv->fpga_data_addr);
 
priv->irq = platform_get_irq(pdev, 0);
if (priv->irq < 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: bluetooth: Add hci_h4p driver

[Pavel Machek]

Hi!

> And you want to set the QUIRK_INVALID_BADDR. At least you want to do that in 
> the final submission.
> 

Ok, I found out that I can do it and result works, provided that I do
hciconfig hci0 up/down first.

I have trouble understanding... h4p_hci_open() seems to be called as
soon as I insmod the driver. Who does that? Is it some kind of udev
magic?

...
> > +#include "hci_h4p.h"
> > +
> > +#define BT_DBG(a...) do {} while(0)
> 
> Why is this needed? BT_DBG is hooked up with dynamic debug.
...

I did all the changes as requested. Thanks. I did't see harm in
include guards, but I removed them; it is not important.

> > +   if (info->rx_count == 0) {
> > +   /* H4+ devices should always send word aligned packets */
> > +   if (!(info->rx_skb->len % 2))
> > +   info->garbage_bytes++;
> > +   h4p_recv_frame(info, info->rx_skb);
> 
> The h4p_recv_frame should maybe done inline here since it only handles 2 
> exception packets. Also to make it easy, just leave the function if 
> (info->rx_count).
> 
> This packet processing feels like a bit of spaghetti code. I think that is 
> better handled in a proper function that goes through it and not with many 
> tiny sub functions.
>

Well, CodingStyle says something about functions that should be kept
short... And when manually inlined, the inner function would have to
be made less readable, as it uses return to shortcut processing. 


To use __hci_cmd_sync()

> > +
> > +   SET_HCIDEV_DEV(hdev, info->dev);
> > +
> > +   if (hci_register_dev(hdev) >= 0)
> > +   return 0;
> > +
> > +   dev_err(info->dev, "hci_register failed %s.\n", hdev->name);
> > +   hci_free_dev(info->hdev);
> > +   return -ENODEV;
> > +}
> 
> And normally this is folded into the probe handling and not in a
> separate function.

The probe function is too long, already...

> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include "hci_h4p.h"
> 
> Why is this a separate file? And if so, why not all UART specific details are 
> in this file. Including bunch of the defines you have in the header.
> 

Well, you wanted less global functions, so I moved some as inlines to
headers. I guess I can merge nokia_core and nokia_uart if really wanted.

I did rest of requested changes.

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[Jiri Pirko]

Fri, Dec 19, 2014 at 10:35:27AM CET, marichi...@gmail.com wrote:
>On 19 December 2014 at 14:53, Jiri Pirko  wrote:
>> Fri, Dec 19, 2014 at 10:01:46AM CET, marichi...@gmail.com wrote:
>>>On 19 December 2014 at 13:57, Jiri Pirko  wrote:
 Fri, Dec 19, 2014 at 06:14:57AM CET, marichi...@gmail.com wrote:
>On 19 December 2014 at 05:18, Roopa Prabhu  
>wrote:
>> On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
>>>
>>>
>>>
>>> We also need an interface to set per-switch attributes. Can this work?
>>> bridge link set dev sw0 sw_attr bcast_flooding 1 master
>>> where sw0 is a bridge representing the hardware switch.
>>
>>
>> Not today. We discussed this @ LPC, and one way to do this would be to 
>> have
>> a device
>> representing the switch asic. This is in the works.
>
>
>Can I assume that on  platforms which house more than one asic (say
>two 24 port asics, interconnected via a 10G link or equivalent, to get
>a 48 port 'switch') , the 'rocker' driver (or similar) should expose
>them as a single set of ports, and not as two 'switch ports' ?

 Well that really depends on particular implementation and drivers. If you
 have 2 pci-e devices, I think you should expose them as 2 entities. For
 sure, you can have the driver to do the masking for you. I don't believe
 that is correct though.

>>>
>>>In a platform that houses two asic chips, IMO, the user is still
>>>expected to manage the router as a single entity. The configuration
>>>being applied on both asic devices need to be matching if not
>>>identical, and may not be conflicting. The FDB is to be synchronized
>>>so that (offloaded) switching can happen across the asics. Some of
>>>this stuff is asic specific anyway. Another example is that of the
>>>learning. The (hardware) learning can't be enabled on one asic, while
>>>being disabled on another one. The general use cases I have seen are
>>>all involving managing the 'router' as a single entity.  That the
>>>'router' is implemented with two asics instead of a single asic (with
>>>more ports) is to be treated as an implementation detail.  This is the
>>>usual router management method that exists today.
>>>
>>>I hope I make sense.
>>>
>>>So I am trying to figure out what this single entity that will be used
>>>from a user perspective. It can be a bridge, but our bridges are more
>>>802.1q bridges. We can use the 'self' mode, but then it means that it
>>>should reflect the entire port count, and not just an asic.
>>>
>>>So I was trying to deduce that in our switchdevice model, the best bet
>>>would be to leave the unification to the driver (i.e., to project the
>>>multiple physical asics as a single virtual switch device). Thist
>>
>> Is it possible to have the asic as just single one? Or is it possible to
>> connect asics being multiple chips maybe from multiple vendors together?
>
>I didn't understand the first question. Some times, it is possible to

I ment that there is a design with just a single asic of this type,
instead of a pair.

>have a single asic replace two, but its a cost factor, and others that
>are involved.
>
>AFAIK, the answer to the second question is a No. Two asics from
>different vendors may not be connected together. The interconnect
>tends to be proprietary.

Okay. In that case, it might make sense to mask it on driver level.


>
>> I believe that answer is "yes" in both cases. Making two separate asics
>> to appear as one for user is not correct in my opinion. Driver should
>> not do such masking. It is unclean, unextendable.
>>
>
>I am only looking for a single management entity. I am not thinking it
>needs to be at driver level. I am not sure of  any other option apart
>from creating a 'switchdev' that Roopa was mentioning.

Well the thing is there is a common desire to make the offloading as
transparent as possible. For example, have 4 ports of same switch and
put them into br0. Just like that, without need to do anything else
than you would do when bridging ordinary NICs. Introducing some
"management entity" would break this approach.


>
>>
>>>allows any 'switch' level configurations to the bridge in 'self' mode.
>>>
>>>And  then we would need to consider stacking. Stacking differs from
>>>this multi-asic scenario since  there would be multiple CPU involved.
>>>
>>>Thanks
>>>Vissu
>>>
>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] usb: chipidea: Add chipidea revision information

[Sanchayan Maity]

Define ci_get_revision API to know the controller revision
information according to chipidea 1.1a, 2.0a, 2.4 and 2.5a
spec. Besides, add one entry in struct ci_hdrc to indicate
revision information. This can be used for adding different
code for revisions, implementing erratas.

Signed-off-by: Sanchayan Maity 
---
 drivers/usb/chipidea/bits.h |   10 ++
 drivers/usb/chipidea/core.c |   23 +--
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index ca57e3d..e935ccc 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -15,6 +15,16 @@
 
 #include 
 
+/*
+ * ID
+ * For 1.x revision, bit24 - bit31 are reserved
+ * For 2.x revision, bit25 - bit28 are 0x2
+ */
+#define TAG(0x1F << 16)
+#define REVISION   (0xF << 21)
+#define VERSION(0xF << 25)
+#define CIVERSION  (0x7 << 29)
+
 /* HCCPARAMS */
 #define HCCPARAMS_LEN BIT(17)
 
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 9bdc6bd..33a8c4a 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -136,6 +136,22 @@ static int hw_alloc_regmap(struct ci_hdrc *ci, bool is_lpm)
return 0;
 }
 
+static enum CI_REVISION ci_get_revision(struct ci_hdrc *ci)
+{
+   int ver = hw_read_id_reg(ci, ID_ID, VERSION) >> __ffs(VERSION);
+   enum CI_REVISION rev = CI_REVISION_UNKNOWN;
+
+   if (ver == 0x2) {
+   int rev_reg = hw_read_id_reg
+   (ci, ID_ID, REVISION) >> __ffs(REVISION);
+   rev = rev_reg + CI_REVISION_20;
+   } else if (ver == 0x0) {
+   rev = CI_REVISION_1X;
+   }
+
+   return rev;
+}
+
 /**
  * hw_read_intr_enable: returns interrupt enable register
  *
@@ -245,8 +261,11 @@ static int hw_device_init(struct ci_hdrc *ci, void __iomem 
*base)
/* Clear all interrupts status bits*/
hw_write(ci, OP_USBSTS, 0x, 0x);
 
-   dev_dbg(ci->dev, "ChipIdea HDRC found, lpm: %d; cap: %p op: %p\n",
-   ci->hw_bank.lpm, ci->hw_bank.cap, ci->hw_bank.op);
+   ci->rev = ci_get_revision(ci);
+
+   dev_dbg(ci->dev,
+   "ChipIdea HDRC found, revision: %d, lpm: %d; cap: %p op: %p\n",
+   ci->rev, ci->hw_bank.lpm, ci->hw_bank.cap, ci->hw_bank.op);
 
/* setup lock mode ? */
 
-- 
1.7.9.5

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

[PATCH 1/3] usb: chipidea: Add identification registers access APIs

[Sanchayan Maity]

Using hw_write_id_reg and hw_read_id_reg to write and read
identification registers contents. This can be used to get
controller information, change some system configurations
and so on.

Signed-off-by: Sanchayan Maity 
---
 drivers/usb/chipidea/ci.h |   53 +
 1 file changed, 53 insertions(+)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index ea40626..94db636 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -29,6 +29,15 @@
 /**
  * REGISTERS
  */
+/* Identification Registers */
+#define ID_ID  0x0
+#define ID_HWGENERAL   0x4
+#define ID_HWHOST  0x8
+#define ID_HWDEVICE0xc
+#define ID_HWTXBUF 0x10
+#define ID_HWRXBUF 0x14
+#define ID_SBUSCFG 0x90
+
 /* register indices */
 enum ci_hw_regs {
CAP_CAPLENGTH,
@@ -97,6 +106,18 @@ enum ci_role {
CI_ROLE_END,
 };
 
+enum CI_REVISION {
+   CI_REVISION_1X = 10,/* Revision 1.x */
+   CI_REVISION_20 = 20, /* Revision 2.0 */
+   CI_REVISION_21, /* Revision 2.1 */
+   CI_REVISION_22, /* Revision 2.2 */
+   CI_REVISION_23, /* Revision 2.3 */
+   CI_REVISION_24, /* Revision 2.4 */
+   CI_REVISION_25, /* Revision 2.5 */
+   CI_REVISION_25_PLUS, /* Revision above than 2.5 */
+   CI_REVISION_UNKNOWN = 99, /* Unknown Revision */
+};
+
 /**
  * struct ci_role_driver - host/gadget role driver
  * @start: start this role
@@ -168,6 +189,7 @@ struct hw_bank {
  * @b_sess_valid_event: indicates there is a vbus event, and handled
  * at ci_otg_work
  * @imx28_write_fix: Freescale imx28 needs swp instruction for writing
+ * @rev: The revision number for controller
  */
 struct ci_hdrc {
struct device   *dev;
@@ -207,6 +229,7 @@ struct ci_hdrc {
boolid_event;
boolb_sess_valid_event;
boolimx28_write_fix;
+   enum CI_REVISIONrev;
 };
 
 static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
@@ -244,6 +267,36 @@ static inline void ci_role_stop(struct ci_hdrc *ci)
 }
 
 /**
+ * hw_read_id_reg: reads from a identification register
+ * @ci: the controller
+ * @offset: offset from the beginning of identification registers region
+ * @mask: bitfield mask
+ *
+ * This function returns register contents
+ */
+static inline u32 hw_read_id_reg(struct ci_hdrc *ci, u32 offset, u32 mask)
+{
+   return ioread32(ci->hw_bank.abs + offset) & mask;
+}
+
+/**
+ * hw_write_id_reg: writes to a identification register
+ * @ci: the controller
+ * @offset: offset from the beginning of identification registers region
+ * @mask: bitfield mask
+ * @data: new value
+ */
+static inline void hw_write_id_reg(struct ci_hdrc *ci, u32 offset,
+   u32 mask, u32 data)
+{
+   if (~mask)
+   data = (ioread32(ci->hw_bank.abs + offset) & ~mask)
+   | (data & mask);
+
+   iowrite32(data, ci->hw_bank.abs + offset);
+}
+
+/**
  * hw_read: reads from a hw register
  * @ci: the controller
  * @reg:  register index
-- 
1.7.9.5

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

[PATCH 3/3] usb: chipidea: Add errata for revision 2.40a

[Sanchayan Maity]

At chipidea revision 2.40a, there is a below errata:

9000531823  B2-Medium  Adding a dTD to a Primed Endpoint May Not Get Recognized

Title: Adding a dTD to a Primed Endpoint May Not Get Recognized

Impacted Configuration: All device mode configurations.

Description:
There is an issue with the add dTD tripwire semaphore (ATDTW bit in USBCMD 
register)
that can cause the controller to ignore a dTD that is added to a primed 
endpoint.
When this happens, the software can read the tripwire bit and the status bit at 
'1'
even though the endpoint is unprimed.

After executing a dTD, the device controller endpoint state machine executes a 
final
read of the dTD terminate bit to check if the application added a dTD to the 
linked
list at the last moment. This read is done in the finpkt_read_latest_next_td 
(44) state.
After the read is performed, if the terminate bit is still set, the state 
machine moves
to unprime the endpoint. The decision to unprime the endpoint is done in the
checkqh_decision (59) state, based on the value of the terminate bit.
Before reaching the checkqh_decision state, the state machine traverses the
writeqhtd_status (57), writeqh_status (56), and release_prime_mask (42) states.
As shown in the waveform, the ep_addtd_tripwire_clr signal is not set to clear
the tripwire bit in these states.

Workaround:
The software must implement a periodic poll cycle, and check for each dTD
pending on execution (Active = 1), if the enpoint is primed. It can do this by 
reading
the corresponding bits in the ENDPTPRIME and ENDPTSTAT registers. If these bits 
are
read at 0, the software needs to re-prime the endpoint by writing 1 to the 
corresponding
bit in the ENDPTPRIME register. This can be done for every microframe, every 
frame or
with a larger interval, depending on the urgency of transfer execution for the 
application.

Signed-off-by: Sanchayan Maity 
---
 drivers/usb/chipidea/udc.c |   20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 0444d3f..551ab37 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -522,6 +522,20 @@ static void free_pending_td(struct ci_hw_ep *hwep)
kfree(pending);
 }
 
+static int reprime_dtd(struct ci_hdrc *ci, struct ci_hw_ep *hwep,
+  struct td_node *node)
+{
+   hwep->qh.ptr->td.next = node->dma;
+   hwep->qh.ptr->td.token &=
+   cpu_to_le32(~(TD_STATUS_HALTED | TD_STATUS_ACTIVE));
+
+   /* Synchronize before ep prime */
+   wmb();
+
+   return hw_ep_prime(ci, hwep->num, hwep->dir,
+   hwep->type == USB_ENDPOINT_XFER_CONTROL);
+}
+
 /**
  * _hardware_dequeue: handles a request at hardware level
  * @gadget: gadget
@@ -535,6 +549,7 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct 
ci_hw_req *hwreq)
struct td_node *node, *tmpnode;
unsigned remaining_length;
unsigned actual = hwreq->req.length;
+   struct ci_hdrc *ci = hwep->ci;
 
if (hwreq->req.status != -EALREADY)
return -EINVAL;
@@ -544,6 +559,11 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct 
ci_hw_req *hwreq)
list_for_each_entry_safe(node, tmpnode, &hwreq->tds, td) {
tmptoken = le32_to_cpu(node->ptr->token);
if ((TD_STATUS_ACTIVE & tmptoken) != 0) {
+   int n = hw_ep_bit(hwep->num, hwep->dir);
+
+   if (ci->rev == CI_REVISION_24)
+   if (!hw_read(ci, OP_ENDPTSTAT, BIT(n)))
+   reprime_dtd(ci, hwep, node);
hwreq->req.status = -EALREADY;
return -EBUSY;
}
-- 
1.7.9.5

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

[PATCH 0/3] usb: chipidea: add one errata for revision 2.40a

[Sanchayan Maity]

The first two patches add identification register API's. These can
be used to get controller's revision. 

The third patch implements an errata for revision 2.40a. Not sure
which other SOCs implement this version of the Chipidea core but
this fixes the usb client issue observed on Vybrids. The patch was
tested on a Toradex Colibri VF61 module with the 3.18 kernel. iperf
tests ran for three hours plus, with these patches applied have found
the USB client connection to be now reliable.

This patchset is based off on Shawn Guo's for-next branch
https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/tree/?h=for-next

The credit for the patches and fix goes to Matthieu Castet and Peter Chen.
First two patches are by Peter Chen and the third patch which fixed the
bug we observed was reported by Matthieu Castet.

The discussion of the problem and the relevant testing details can be found
at this link: http://www.spinics.net/lists/linux-usb/msg118544.html

The first version of this patchset originally send by Peter Chen can be
found at this link: http://www.spinics.net/lists/linux-usb/msg118753.html

Comments for review are welcome :).
Note: I am going on a vacation so will not be able to reply or do any further
tests till Monday. Will attend and take care of any comments/requests for 
further changes/testing from Tuesday. Apologize for the delay in advance.

Sanchayan Maity (3):
  usb: chipidea: Add identification registers access APIs
  usb: chipidea: Add chipidea revision information
  usb: chipidea: Add errata for revision 2.40a

 drivers/usb/chipidea/bits.h |   10 
 drivers/usb/chipidea/ci.h   |   53 +++
 drivers/usb/chipidea/core.c |   23 +--
 drivers/usb/chipidea/udc.c  |   20 
 4 files changed, 104 insertions(+), 2 deletions(-)

-- 
1.7.9.5

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

[3.16.y-ckt stable] Linux 3.16.7-ckt3

[Luis Henriques]

I am announcing the release of the Linux 3.16.7-ckt3 kernel.

The updated 3.16.y-ckt tree can be found at: 
  git://kernel.ubuntu.com/ubuntu/linux.git linux-3.16.y
and can be browsed at:
  
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.16.y;a=shortlog

The diff from v3.16.7-ckt2 is posted as a follow-up to this email.

The 3.16.y-ckt extended stable tree is maintained by the Canonical Kernel Team.
For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

 -Luis

-- 
 .../bindings/interrupt-controller/interrupts.txt   |   4 -
 Makefile   |   2 +-
 arch/arm/Kconfig.debug |   2 +-
 arch/arm/include/asm/pgtable-3level-hwdef.h|   3 +-
 arch/arm/include/asm/pgtable-3level.h  |  49 ++
 arch/arm/include/asm/pgtable.h |  18 ++--
 arch/arm/include/asm/thread_info.h |  11 ---
 arch/arm/kernel/traps.c|  31 +-
 arch/arm/mach-mvebu/coherency.c|   2 +
 arch/arm/mach-pxa/include/mach/addr-map.h  |   5 +
 arch/arm/mm/dump.c |   4 +-
 arch/arm/mm/proc-v7-3level.S   |   9 +-
 arch/arm/mm/proc-v7.S  |   2 -
 arch/arm/mm/proc-xscale.S  |   4 +-
 arch/arm64/crypto/Makefile |   2 +-
 arch/mips/include/asm/mipsregs.h   |   2 +
 arch/mips/include/asm/r4kcache.h   |   4 +
 arch/mips/include/asm/uaccess.h|   7 +-
 arch/mips/kernel/cpu-probe.c   |  33 ++-
 arch/mips/kernel/signal.c  |   8 +-
 arch/mips/lib/memcpy.S |   1 +
 arch/mips/loongson/common/Makefile |   3 +-
 arch/mips/net/bpf_jit.c|   4 +-
 arch/mips/oprofile/backtrace.c |   2 +-
 arch/mips/sgi-ip27/ip27-memory.c   |   1 +
 arch/powerpc/kernel/vdso32/getcpu.S|   4 +-
 arch/powerpc/platforms/powernv/pci-ioda.c  |   5 +-
 arch/powerpc/platforms/powernv/pci.c   |   3 +-
 arch/powerpc/platforms/pseries/msi.c   |   2 +-
 arch/powerpc/xmon/xmon.c   |   6 +-
 arch/sparc/include/uapi/asm/swab.h |  12 +--
 arch/x86/boot/compressed/Makefile  |   2 +-
 arch/x86/include/asm/cpufeature.h  |   1 +
 arch/x86/include/asm/kvm_para.h|  10 +-
 arch/x86/include/asm/page_32_types.h   |   1 -
 arch/x86/include/asm/page_64_types.h   |  11 +--
 arch/x86/include/asm/thread_info.h |   2 +-
 arch/x86/include/asm/traps.h   |   1 +
 arch/x86/kernel/cpu/amd.c  |   7 ++
 arch/x86/kernel/cpu/common.c   |   2 +
 arch/x86/kernel/dumpstack_64.c |   1 -
 arch/x86/kernel/entry_64.S |  81 +---
 arch/x86/kernel/traps.c|  74 ++
 arch/x86/mm/init_64.c  |  11 ++-
 arch/x86/tools/calc_run_size.pl|  11 ++-
 drivers/acpi/device_pm.c   |   2 +-
 drivers/ata/ahci.c |   4 +
 drivers/ata/sata_fsl.c |   2 +-
 drivers/bluetooth/ath3k.c  |  33 ---
 drivers/bluetooth/btmrvl_main.c|   5 +
 drivers/bluetooth/btusb.c  |  27 +-
 drivers/clk/clk-divider.c  |  18 ++--
 drivers/clocksource/sun4i_timer.c  |  12 +--
 drivers/gpu/drm/i915/i915_dma.c|  22 +++--
 drivers/gpu/drm/i915/intel_display.c   |   6 +-
 drivers/gpu/drm/i915/intel_lvds.c  |  22 ++---
 drivers/gpu/drm/i915/intel_pm.c|   5 -
 drivers/gpu/drm/nouveau/core/engine/device/nvc0.c  |   1 -
 drivers/gpu/drm/nouveau/nouveau_drm.c  |   2 +-
 drivers/gpu/drm/radeon/r600_dpm.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_connectors.c |  13 ++-
 drivers/gpu/drm/radeon/radeon_cs.c |   9 +-
 drivers/gpu/drm/radeon/radeon_irq_kms.c|  10 ++
 drivers/gpu/drm/radeon/radeon_kms.c|   2 +
 drivers/hid/usbhid/hid-core.c  |   6 +-
 drivers/i2c/busses/i2c-cadence.c   |  11 +++
 drivers/i2c/busses/i2c-davinci.c   |   8 +-
 drivers/i2c/busses/i2c-omap.c  |  10 +-
 drivers/iio/adc/men_z188_adc.c |   1 +
 drivers/infiniband/ulp/isert/ib_isert.c|  44 ++---
 drivers/infiniband/ulp/srpt/ib_srpt.c  |   8 ++
 drivers/input/evdev.c  |   2 +-
 drivers/input/joystick/xpad.c 

Re: bluetooth: Add hci_h4p driver

[Marcel Holtmann]

Hi Pavel,

>> And you want to set the QUIRK_INVALID_BADDR. At least you want to do that in 
>> the final submission.
>> 
> 
> Ok, I found out that I can do it and result works, provided that I do
> hciconfig hci0 up/down first.

that should not be the case. Actually hciconfig uses old ioctl. A full 
Bluetooth system running bluetoothd (from BlueZ 5) will never use any old 
ioctl. Only an old system (BlueZ 4) will use ioctl.

> I have trouble understanding... h4p_hci_open() seems to be called as
> soon as I insmod the driver. Who does that? Is it some kind of udev
> magic?

As soon as you do hci_register_dev, it will bring up the device and run the 
basic initialization. That is needed to get the address, version information 
and features. Otherwise the mgmt interface can not work. We need basic 
information about the device.

So what the kernel will do internally when you find a device is bring it up, 
get the basics and then bring it back down (in case nobody uses it). See 
hci_power_on work.

> ...
>>> +#include "hci_h4p.h"
>>> +
>>> +#define BT_DBG(a...) do {} while(0)
>> 
>> Why is this needed? BT_DBG is hooked up with dynamic debug.
> ...
> 
> I did all the changes as requested. Thanks. I did't see harm in
> include guards, but I removed them; it is not important.

There is no harm in including the guards. We just don't do it for internal 
files. And thus if anyone tries to be sneaky and build circular inclusion they 
will fall flat on their faces. That is the only reason.

> 
>>> +   if (info->rx_count == 0) {
>>> +   /* H4+ devices should always send word aligned packets */
>>> +   if (!(info->rx_skb->len % 2))
>>> +   info->garbage_bytes++;
>>> +   h4p_recv_frame(info, info->rx_skb);
>> 
>> The h4p_recv_frame should maybe done inline here since it only handles 2 
>> exception packets. Also to make it easy, just leave the function if 
>> (info->rx_count).
>> 
>> This packet processing feels like a bit of spaghetti code. I think that is 
>> better handled in a proper function that goes through it and not with many 
>> tiny sub functions.
>> 
> 
> Well, CodingStyle says something about functions that should be kept
> short... And when manually inlined, the inner function would have to
> be made less readable, as it uses return to shortcut processing. 

It also should not make me have to follow 3 functions to figure out what it is 
actually doing.

> 
> 
> To use __hci_cmd_sync()
> 
>>> +
>>> +   SET_HCIDEV_DEV(hdev, info->dev);
>>> +
>>> +   if (hci_register_dev(hdev) >= 0)
>>> +   return 0;
>>> +
>>> +   dev_err(info->dev, "hci_register failed %s.\n", hdev->name);
>>> +   hci_free_dev(info->hdev);
>>> +   return -ENODEV;
>>> +}
>> 
>> And normally this is folded into the probe handling and not in a
>> separate function.
> 
> The probe function is too long, already...

Have you compared it to other functions. Normally probe() functions in general 
are all pretty long since they have to do tons of stuff. Having all in one 
function means you can read through it at once.

> 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +#include "hci_h4p.h"
>> 
>> Why is this a separate file? And if so, why not all UART specific details 
>> are in this file. Including bunch of the defines you have in the header.
>> 
> 
> Well, you wanted less global functions, so I moved some as inlines to
> headers. I guess I can merge nokia_core and nokia_uart if really wanted.

Would this become easier when some of the OMAP specific stuff is moved out of 
this driver? If that is possible.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC v4 net-next 1/5] virtio_net: enable tx interrupt

[Jason Wang]

On Fri, Dec 19, 2014 at 3:32 PM, Qin Chuanyu  
wrote:

On 2014/12/1 18:17, Jason Wang wrote:

On newer hosts that support delayed tx interrupts,
we probably don't have much to gain from orphaning
packets early.

Note: this might degrade performance for
hosts without event idx support.
Should be addressed by the next patch.

Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
  drivers/net/virtio_net.c | 132 
+++

  1 file changed, 88 insertions(+), 44 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index ec2a8b4..f68114e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
  static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
  {
struct skb_vnet_hdr *hdr;
@@ -912,7 +951,9 @@ static int xmit_skb(struct send_queue *sq, 
struct sk_buff *skb)

sg_set_buf(sq->sg, hdr, hdr_len);
num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
}
-	return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, 
GFP_ATOMIC);

+
+   return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb,
+   GFP_ATOMIC);
  }

  static netdev_tx_t start_xmit(struct sk_buff *skb, struct 
net_device *dev)
@@ -924,8 +965,7 @@ static netdev_tx_t start_xmit(struct sk_buff 
*skb, struct net_device *dev)

struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
bool kick = !skb->xmit_more;

-   /* Free up any pending old buffers before queueing new ones. */
-   free_old_xmit_skbs(sq);


I think there is no need to remove free_old_xmit_skbs here.
you could add free_old_xmit_skbs in tx_irq's napi func.
also could do this in start_xmit if you handle the race well.


Note, free_old_xmit_skbs() has already called in tx napi.
It was a must after tx interrupt was enabled.



I have done the same thing in ixgbe driver(free skb in ndo_start_xmit 
and both in tx_irq's poll func), and it seems work well:)


Any performance numbers on this change?
I suspect it reduce the effects of interrupt coalescing.


I think there would be no so much interrupts in this way, also tx 
interrupt coalesce is not needed.


Tests (multiple sessions of TCP_RR) does not support this.
Calling free_old_xmit_skbs() in fact damage the performance. 


Any justification that you think it may reduce the interrupts?

Thanks




+   virtqueue_disable_cb(sq->vq);

/* Try to transmit */
err = xmit_skb(sq, skb);
@@ -941,27 +981,19 @@ static netdev_tx_t start_xmit(struct sk_buff 
*skb, struct net_device *dev)

return NETDEV_TX_OK;
}

-   /* Don't wait up for transmitted skbs to be freed. */
-   skb_orphan(skb);
-   nf_reset(skb);
-
/* Apparently nice girls don't return TX_BUSY; stop the queue
 * before it gets out of hand.  Naturally, this wastes entries. */
-   if (sq->vq->num_free < 2+MAX_SKB_FRAGS) {
+   if (sq->vq->num_free < 2+MAX_SKB_FRAGS)
netif_stop_subqueue(dev, qnum);
-   if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
-   /* More just got used, free them then recheck. */
-   free_old_xmit_skbs(sq);
-   if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
-   netif_start_subqueue(dev, qnum);
-   virtqueue_disable_cb(sq->vq);
-   }
-   }
-   }

if (kick || netif_xmit_stopped(txq))
virtqueue_kick(sq->vq);

+   if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
+   virtqueue_disable_cb(sq->vq);
+   napi_schedule(&sq->napi);
+   }
+
return NETDEV_TX_OK;
  }

@@ -1138,8 +1170,10 @@ static int virtnet_close(struct net_device 
*dev)

/* Make sure refill_work doesn't re-enable napi! */
cancel_delayed_work_sync(&vi->refill);

-   for (i = 0; i < vi->max_queue_pairs; i++)
+   for (i = 0; i < vi->max_queue_pairs; i++) {
napi_disable(&vi->rq[i].napi);
+   napi_disable(&vi->sq[i].napi);
+   }

return 0;
  }
@@ -1452,8 +1486,10 @@ static void virtnet_free_queues(struct 
virtnet_info *vi)

  {
int i;

-   for (i = 0; i < vi->max_queue_pairs; i++)
+   for (i = 0; i < vi->max_queue_pairs; i++) {
netif_napi_del(&vi->rq[i].napi);
+   netif_napi_del(&vi->sq[i].napi);
+   }

kfree(vi->rq);
kfree(vi->sq);



--
To unsubscribe from this list: send the line "unsubscribe netdev" 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 rea

Re: [PATCH 1/3] HID: logitech-hidpp: detect HID++ 2.0 errors too

[Jiri Kosina]

On Wed, 17 Dec 2014, Benjamin Tissoires wrote:

> > Devices speaking HID++ 2.0 report a different error code (0xff). Detect
> > these errors too to avoid 5 second delays when the device reports an
> > error. Caught by... well, a bug in the QEMU emulation of this receiver.
> > 
> > Renamed fap to rap for HID++ 1.0 errors because it is more logical,
> > it has no functional difference.
> > 
> > Signed-off-by: Peter Wu 
> > ---
> 
> Jiri, it looks like this one fall off from your radar.
> 
> It's not a problem per-se, I'd like to have some feedbacks from Logitech
> first, but still, there is a bug and Peter fixed it :)

It's actually still on my radar, but that was exactly the reason I have it 
on hold, because my understanding was that you are waiting for Logitech to 
review it.

Nestor ... ?

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

[GIT PULL] target updates for v3.19-rc1

[Nicholas A. Bellinger]

Hello Linus,

Here are the target-pending updates for v3.19-rc1 code.  Please go ahead
and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next

The highlights this merge window include:

  - Allow target fabric drivers to function as built-in. (Roland)
  - Fix tcm_loop multi-TPG endpoint nexus bug. (Hannes)
  - Move per device config_item_type into se_subsystem_api, allowing
configfs attributes to be defined at module_init time. (Jerome + nab)
  - Convert existing IBLOCK/FILEIO/RAMDISK/PSCSI/TCMU drivers to use
external configfs attributes. (nab)
  - A number of iser-target fixes related to active session + network portal
shutdown stability during extended stress testing. (Sagi + Slava)
  - Dynamic allocation of T10-PI contexts for iser-target, fixing a potentially
bogus iscsi_np->tpg_np pointer reference in >= v3.14 code. (Sagi)
  - iser-target performance + scalability improvements.  (Sagi) 
  - Fixes for SPC-4 Persistent Reservation AllRegistrants spec compliance.
(Ilias + James + nab)
  - Avoid potential short kern_sendmsg() in iscsi-target for now until Al's
conversion to use msghdr iteration is merged post -rc1. (Viro)

Also, Sagi has requested a number of iser-target patches (9) that
address stability issues he's encountered during extended stress testing
be considered for v3.10.y + v3.14.y code.  Given the amount of LOC
involved, it will certainly require extra backporting effort.

Apologies in advance to Greg-KH & Co on this.  Sagi and I will be
working post-merge to ensure they each get applied correctly.

Thank you,

--nab

Hannes Reinecke (1):
  tcm_loop: Fix wrong I_T nexus association

Julia Lawall (1):
  target: remove unneeded array

Kyle McMartin (1):
  uapi/linux/target_core_user.h: fix headers_install.sh badness

Lino Sanfilippo (1):
  iscsi-target: fix error path in iscsi_target_init_module()

Markus Elfring (1):
  target: Deletion of unnecessary checks before the function call
"module_put"

Nicholas Bellinger (22):
  target: Move dev_cit to struct se_subsystem_api
  target: Move dev_attrib_cit to struct se_subsystem_api
  target: Move dev_pr_cit to struct se_subsystem_api
  target: Move dev_wwn_cit to struct se_subsystem_api
  target: Move dev_alua_tg_pt_gps_cit to struct se_subsystem_api
  target: Move dev_stat_cit to struct se_subsystem_api
  target: Add target_core_backend_configfs.h helper macros
  target: Add EXPORT_SYMBOL for existing se_dev_set_*
  target: Add DEF_TB_DEFAULT_ATTRIBS macro for virtual device attrs
  target/iblock: Convert to external iblock_backend_dev_attrs
  target/file: Convert to external fileio_backend_dev_attrs
  target/rd: Convert to external rd_mcp_backend_dev_attrs
  target/user: Convert to external tcmu_backend_dev_attrs
  target/pscsi: Convert to external pscsi_backend_dev_attrs
  target: Drop left-over internal dev attribute code
  target: Drop left-over PHBA_PDEV set attr checks
  iser-target: Fix wc->wr_id cast warning
  iscsi-target: Drop left-over bogus iscsi_np->tpg_np
  target: Fix R_HOLDER bit usage for AllRegistrants
  target: Avoid dropping AllRegistrants reservation during unregister
  iscsi-target: Fail connection on short sendmsg writes
  target: Allow AllRegistrants to re-RESERVE existing reservation

Roland Dreier (1):
  target: Fix target_core_register_fabric() for built-in fabric modules

Sagi Grimberg (25):
  iscsi,iser-target: Initiate termination only once
  iser-target: Fix flush + disconnect completion handling
  iser-target: Parallelize CM connection establishment
  iser-target: Fix connected_handler + teardown flow race
  iser-target: Handle ADDR_CHANGE event for listener cm_id
  iser-target: Fix implicit termination of connections
  iser-target: Allocate PI contexts dynamically
  iser-target: Fix NULL dereference in SW mode DIF
  iscsi,iser-target: Expose supported protection ops according to t10_pi
  iser-target: Work-around live target stack shutdown resource cleanup
  iser-target: Remove interrupt coalescing
  iser-target: Unite error completion handler for RX and TX
  iser-target: Cast wr_id with uintptr_t instead of unsinged long
  iser-target: Centralize completion elements to a context
  iser-target: Use single CQ for TX and RX
  iser-target: Remove redundant call to isert_conn_terminate
  iser-target: Remove an atomic operation from the IO path
  iser-target: Introduce isert_poll_budget
  iser-target: Reduce CQ lock contention by batch polling
  iser-target: Don't wait for session commands from completion context
  iser-target: Fix logout sequence
  iser-target: Use debug_level parameter to control logging level
  iser-target: Adjust log levels and prettify some prints
  iser-target: Remove code duplication
  iscsi-target: nullify session in failed login sequence

 drivers/infiniband/ulp/isert/ib_isert.c   | 1599 +
 drivers/infiniband/ulp/isert/ib_isert.h   |   80 +-
 drivers/target/iscsi/iscsi_target.c   |1 +

Re: [drm/fb-helper] BUG: unable to handle kernel paging request at 95d24c70

[Thierry Reding]

On Thu, Dec 18, 2014 at 06:04:45PM -0800, Fengguang Wu wrote:
> 
> Hi Thierry,
> 
> FYI, here is another bisect result.

Thanks. Looking at the cirrus driver more closely it already employs the
big hammer upon failure and ends up calling drm_fb_helper_fini() via the
cirrus_driver_unload() call in cirrus_driver_load()'s cleanup path.

> commit 7bf2844ed14de049a4ccec26eb3d8b4c3d5c1971
> Author: Thierry Reding 
> AuthorDate: Wed Dec 17 16:39:59 2014 +0100
> Commit: Daniel Vetter 
> CommitDate: Wed Dec 17 22:05:08 2014 +0100
> 
> drm/fb-helper: Propagate errors from initial config failure
> 
> Make drm_fb_helper_initial_config() return an int rather than a bool so
> that the error can be properly propagated. While at it, update drivers
> to propagate errors further rather than just ignore them.
> 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Patrik Jakobsson 
> Cc: Rob Clark 
> Cc: Tomi Valkeinen 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Ben Skeggs 
> Signed-off-by: Thierry Reding 
> Reviewed-by: Alex Deucher 
> Reviewed-by: Patrik Jakobsson 
> Signed-off-by: Daniel Vetter 

Using the attached patch on top of this I can no longer reproduce either
this or the earlier result. I'll send a revised patch with this squashed
in.

Thanks,
Thierry
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 0682210b068b..f7e8c6530beb 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -318,26 +318,20 @@ int cirrus_fbdev_init(struct cirrus_device *cdev)
ret = drm_fb_helper_init(cdev->dev, &gfbdev->helper,
 cdev->num_crtc, CIRRUSFB_CONN_LIMIT);
if (ret)
-   goto free;
+   return ret;
 
ret = drm_fb_helper_single_add_all_connectors(&gfbdev->helper);
if (ret)
-   goto fini;
+   return ret;
 
/* disable all the possible outputs/crtcs before entering KMS mode */
drm_helper_disable_unused_functions(cdev->dev);
 
ret = drm_fb_helper_initial_config(&gfbdev->helper, bpp_sel);
if (ret)
-   goto fini;
+   return ret;;
 
return 0;
-
-free:
-   kfree(gfbdev);
-fini:
-   drm_fb_helper_fini(&gfbdev->helper);
-   return ret;
 }
 
 void cirrus_fbdev_fini(struct cirrus_device *cdev)


pgpRZjyyhspy0.pgp
Description: PGP signature

Re: [PATCH RFC v2 08/14] drm: imx: Add MIPI DSI host controller driver

[Philipp Zabel]

Hi Liu,

Am Freitag, den 19.12.2014, 13:53 +0800 schrieb Liu Ying:
[...]
> >> +  mipi_dsi: mipi@021e {
> >> +  #address-cells = <1>;
> >> +  #size-cells = <0>;
> >> +  compatible = "fsl,imx6q-mipi-dsi";
> >> +  reg = <0x021e 0x4000>;
> >> +  interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
> >> +  gpr = <&gpr>;
> >> +  clocks = <&clks IMX6QDL_CLK_VIDEO_27M>,
> >> +   <&clks IMX6QDL_CLK_HSI_TX>,
> >> +   <&clks IMX6QDL_CLK_HSI_TX>;
> >> +  clock-names = "pllref", "pllref_gate", "core_cfg";
> >
> > Not sure about this. Are those names from the Synopsys documentation?
> 
> No, I don't think it's from there.

Do you have access to it? I'd like to see the proper names used if
possible, considering this IP core will be used on other SoCs, too.

> > According to Table 41-1 in the i.MX6Q Reference Manual, this module has
> > 6 clock inputs:
> >   - ac_clk_125m (from ahb_clk_root)
> >   - pixel_clk (from axi_clk_root)
> >   - cfg_clk and pll_refclk (from video_27m)
> >   - ips_clk and ipg_clk_s (from ipg_clk_root)
> > The CCM chapter says that of these, "ac_clk_125m", "cfg_clk", ips_clk",
> > and "pll_refclk" are gated by a single bit called
> > "mipi_core_cfg_clk_enable", that is clk[CLK_HSI_TX].
> > If that is correct, I see no reason for the "pllref_gate" clock.
> > I suppose two clocks "pllref" and "cfg" should suffice.
> 
> Using the two clocks makes the code look like this, perhaps:
> 
>clocks = <&clks IMX6QDL_CLK_VIDEO_27M>,
> <&clks IMX6QDL_CLK_HSI_TX>;
>clock-names = "pllref", "core_cfg";
> 
> Then, it seems that I have no way to disable the pllref clock if
> using the clock tree after applying this patch set?

Correct. In my opinion we should put a new gate clock in the clock path
between video_27m and the pllref input triggers the same bit as hsi_tx,
see below.

> Or, perhaps, this one?
> 
>clocks = <&clks IMX6QDL_CLK_HSI_TX>,
> <&clks IMX6QDL_CLK_HSI_TX>;
>clock-names = "pllref", "core_cfg";
> 
> This only uses the gate clock hsi_tx.  The current clock tree states
> that it comes from:
> 
>   pll3_120m ->
>   | -> hsi_tx_sel -> hsi_tx_podf -> hsi_tx
> pll2_pfd2_396m ->
> 
> So, I can not get the correct pllref clock frequency with this tree.
> The pllref clock should be derived from the video_27m clock.

According to the i.MX6 reference manual, the cfg clock also is derived
from video_27m, so both have the wrong rate if connected to hsi_tx (yes,
for cfg we don't care about the rate).

Currently we have this:

pll2_pfd2_396m -> hsi_tx_sel -> hsi_tx_podf -> hsi_tx
pll3_pfd1_540m -> video_27m -> hdmi_isfr

- hsi_tx_podf represents the hsi_tx_clk_root at its output.
- hsi_tx represents the gate between hsi_tx_clk_root and the tx_ref_clk
  input to the MIPI_HSI module, which is controlled by the
  mipi_core_cfg_clk_enable bit.
- video_27m represents the video_27m_clk_root at its output.

I'd say we should turn hsi_tx into a shared gate clock and add a new
shared gate clock using the same gate bit. Maybe name it mipi_core_cfg,
after the gating bit in the CCM.

pll2_pfd2_396m -> hsi_tx_sel -> hsi_tx_podf -> hsi_tx
pll3_pfd1_540m -> video_27m -> mipi_core_cfg
pll3_pfd1_540m -> video_27m -> hdmi_isfr

- mipi_core_cfg represents the gate between video_27_clk_root and the
  cfg_clk and pllref_clk inputs to the MIPI_DSI module, which is also
  controlled by the mipi_core_cfg_clk_enable bit.

> The way I decided to use the three clocks is:
> 1) PLL related
> * pllref clock only cares about the pll reference rate(the frequency).
>And, the frequency does matter as it has an impact on the lane clock
>frequency.
> * pllref_gate is a gate clock and it only cares about the gate.
>
> 2) register configuration related
> * core_cfg is a gate clock and it only cares about the gate.
> Usually, the register configuration clock frequency is not so important
> and the gate is what we really need.
> 
> I am currently not strong on the way I used.  I am open to any better
> solution.

Since cfg is a real clock input to the MIPI DSI IP, that's ok. But the
two pllref entries in reality are one and the same clock input.

> > Maybe HSI_TX should be split up into multiple shared gate clocks that
> > all set the mipi_core_cfg clock bits (see below).
> 
> Yes, maybe.
> If that's the case, do we need to add two gate clocks in the DT node to
> represent cfg_gate and pllref_gate respectively?

I'd say yes. While on i.MX6 it could be represented by a single clock
because both have the same rate and use the same gate bit, that doesn't
have to be the case on other SoCs. With my suggestion above, that would
be:

clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
 <&clks IMX6QDL_CLK_MIPI_CORE_CFG>;
clock-names = "pllref", "cfg";

> >> diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
[...]
> >> +static int imx_mipi_

Re: [PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Ulf Hansson]

On 3 December 2014 at 00:42, Doug Anderson  wrote:
> Bing Zhao at Marvell found a problem with dw_mmc where interrupts
> weren't firing sometimes.  He tracked it down to a read-modify-write
> problem with the INTMASK.  These patches fix the problem.
>
> Note: I've picked up a > 1-year old series here to make another
> attempt at landing it upstream.  These patches have been in shipping
> Chromebooks for the last year.  Note that v3 to v4 has no changes
> other than a rebase and a small commit message update.
>
> The first two patches extend the "init_card()" mechanism of MMC core
> to actually be called for all card types, not just SDIO.  That could
> be applied any time and should fix at least one longstanding bug
> (untested).
>
> The third patch is a cleanup patch to use init_card() to move things
> around a bit so we don't need to handle SDIO cards in such a strange
> place.  On earlier versions of this patch Seungwon brought up a few
> points which I have _not_ addressed.  See
> .  Other than talk of
> cards with out of band interrupts maybe being able to gate their
> clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING.  I didn't do
> that because of the ordering of init_card() and when the quirks are
> set.  Some users of init_card() like pandora_wl1251_init_card() rely
> on it being called very early in the process.
> pandora_wl1251_init_card() hardcodes a vendor and device and thus need
> to be called super early.  On the other hand the code that adds quirks
> _reads_ the vendor and device.  It can't possibly move before
> init_card().  If folks are willing to take an additional host op of
> init_card_late() I can certainly go that way, though.
>
> The fourth patch is (I think) reviewed and ready to go assuming the
> other two land.

I have queued this up for 3.20. It was a bit hard to follow the
updated the revisions, please don't send patches "in-reply-to" for
future sets.

In v5, I don't find a patch 1/4. Anyway, I have taken patch 2->4.

Kind regards
Uffe

>
> Changes in v5:
> - Split fixup to pandora_wl1251_init_card() into its own patch.
>
> Changes in v3:
> - Add fixup to pandora_wl1251_init_card().
>
> Changes in v2:
> - mmc core change new for this version.
> - Fixed "|" to "&".
> - intmask_lock renamed to irq_lock
>
> Doug Anderson (4):
>   ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only
>   mmc: core: Support the optional init_card() callback for MMC and SD
>   mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts
>   mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock
>
>  arch/arm/mach-omap2/board-omap3pandora.c | 14 +++---
>  drivers/mmc/core/mmc.c   |  6 +++
>  drivers/mmc/core/sd.c|  7 ++-
>  drivers/mmc/host/dw_mmc.c| 80 
> +++-
>  drivers/mmc/host/dw_mmc.h|  1 +
>  include/linux/mmc/dw_mmc.h   |  6 +++
>  6 files changed, 74 insertions(+), 40 deletions(-)
>
> --
> 2.2.0.rc0.207.ga3a616c
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Slab infrastructure for array operations

[Jesper Dangaard Brouer]

On Thu, 18 Dec 2014 14:06:29 -0800 Andrew Morton  
wrote:

> On Thu, 18 Dec 2014 10:33:23 -0600 (CST) Christoph Lameter  
> wrote:
> 
> > This patch adds the basic infrastructure for alloc / free operations
> > on pointer arrays.
> 
> Please provide the justification/reason for making this change.

I agree that this needs more justification.

I (think) the reason behind this is a first step towards "bulk" alloc
and free.  And the reason behind that is to save/amortize the cost of
the locking/CAS operations.


> > Allocators must define _HAVE_SLAB_ALLOCATOR_OPERATIONS in their
> > header files in order to implement their own fast version for
> > these array operations.

I would like to see an implementation of a fast-version.  Else it is
difficult to evaluate if the API is the right one.  E.g. if it would be
beneficial for the MM system, we could likely restrict the API to only
work with power-of-two, from the beginning.


> Why?  What's driving this?

The network stack have a pattern of allocating 64 SKBs while pulling
out packets of the NICs RX-ring.  Packets are placing into the TX-ring,
and later at TX-completing time, we free up-to 256 SKBs (depending on
driver).

Another use-case, which need smaller bulk's, could be tree-structures
that need to expand, allocating two elems in one-shot should cut the
alloc overhead in half.

I'm implemented a prove-of-concept[1] lockless bulk alloc and free
scheme, that demonstrate this can benefit the network stack.  Now,
Christoph and I are trying to integrate some of the ideas into the slub
allocator.


[1] http://thread.gmane.org/gmane.linux.network/342347/focus=126138 
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rfc: remove early_printk from a few arches? (blackfin, m68k, mips)

[Måns Rullgård]

Joe Perches  writes:

> On Fri, 2014-12-19 at 01:43 +, Måns Rullgård wrote:
>> What exactly are you proposing to remove?
>
> Optionally compile out
> kernel/printk/printk.c:early_printk()
> even if CONFIG_EARLY_PRINTK is enabled.
>
>> I see no unused code related
>> to early printk (in any variant) under arch/mips.
>
> I think there could be yet another CONFIG option
> to specifically enable the early_printk function
> for the arches that use it.

Why bother?  On MIPS it would save 132 bytes of compiled code.

> The kernel/printk/early_printk() function seems
> used only by arm/microblaze/tile/x86.

Rather than introduce more config complexity, you could try to remove
the 7 remaining uses of early_printk().

- arch/arm/mach-socfpga
  Single early_printk("Early printk initialized\n") call serving no
  apparent purpose can probably be safely deleted.  Since there are no
  other early_printk() calls, this information seems rather useless.

- arch/microblaze, arch/tile, arch/x86
  These all do a register_console() for the early console, so regular
  printk() should work.  Moreover, x86 allows multiple early consoles,
  but calling early_printk() will only output to the last one specified.

-- 
Måns Rullgård
m...@mansr.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 v4 0/6] mmc: rtsx: add support for sdio card

[Ulf Hansson]

On 5 December 2014 at 06:54,   wrote:
> From: Micky Ching 
>
> v4:
>   split patch in more detailed patches. no code changes diff v3.
>
> v3:
>   rtsx_pci_sdmmc.c:
> - dump_reg_range
>   - remove unused pointer check
>   - fix start index
> v2:
>   rtsx_pci.h:
> - remove unused rtsx_pci_write_le32
> - add SD_CMD_START
>   rtsx_pci_sdmmc.c:
> - dump_reg_range
>   - alloc data on stack
> - remove forward declaration
> - use SD_CMD_START replace magic number 0x40
> - move initialize assignment to error handling
>
> This patch is used to change transfer mode for sdio card support
> by SD interface.
>
>
>
> Micky Ching (6):
>   mfd: rtsx: add func to split u32 into register
>   mmc: rtsx: add dump_reg_range to simplify dump register
>   mmc: rtsx: init cookie at probe/card_event
>   mmc: rtsx: add helper function to simplify code
>   mmc: rtsx: add support for sdio card
>   mmc: rtsx: swap function position to avoid pre declaration
>
>  drivers/mmc/host/rtsx_pci_sdmmc.c | 522 
> +-
>  include/linux/mfd/rtsx_pci.h  |   9 +
>  2 files changed, 296 insertions(+), 235 deletions(-)
>
> --
> 1.9.1
>

Thanks! Queued for 3.20.

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

Re: [PATCH] Staging: comedi: fix redundant parens in return in amplc_dio200_common.c

[Aapo Vienamo]

On Thu, Dec 18, 2014 at 02:45:01PM -0800, Jeremiah Mahler wrote:
> Aapo,
> 
> On Thu, Dec 18, 2014 at 05:32:52PM +0200, Aapo Vienamo wrote:
> > This patch fixes a coding style issue found by the checkpatch.pl tool in
> > amplc_dio200_common.c by removing the unnecessary parentheses around the
> > expression in a return statement.
> > 
> > Signed-off-by: Aapo Vienamo 
> > ---
> >  drivers/staging/comedi/drivers/amplc_dio200_common.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/comedi/drivers/amplc_dio200_common.c 
> > b/drivers/staging/comedi/drivers/amplc_dio200_common.c
> > index 26aad70..6eadbbe 100644
> > --- a/drivers/staging/comedi/drivers/amplc_dio200_common.c
> > +++ b/drivers/staging/comedi/drivers/amplc_dio200_common.c
> > @@ -340,7 +340,7 @@ static int dio200_handle_read_intr(struct comedi_device 
> > *dev,
> >  
> > comedi_handle_events(dev, s);
> >  
> > -   return (triggered != 0);
> > +   return triggered != 0;
> >  }
> >  
> [...]
> 
> When I run checkpatch.pl it doesn't find any errors and the parenthesis
> haven't been removed.  How are you running checkpatch.pl?  Are you using
> any extra options?

It looks like that I accidentally ran the file trough an older version
of checkpatch.pl. The error for this case was quieted in commit 
5b9553a (checkpatch: make "return is not a function" test quieter).

Sorry for the noise.

- Aapo Vienamo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: logitech-hidpp: detect HID++ 2.0 errors too

[Jiri Kosina]

On Tue, 16 Dec 2014, Peter Wu wrote:

> Devices speaking HID++ 2.0 report a different error code (0xff). Detect
> these errors too to avoid 5 second delays when the device reports an
> error. Caught by... well, a bug in the QEMU emulation of this receiver.
> 
> Renamed fap to rap for HID++ 1.0 errors because it is more logical,
> it has no functional difference.
> 
> Signed-off-by: Peter Wu 

Applied to for-3.20/logitech.

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

Re: [PATCH 3/3] HID: logitech-hidpp: avoid unintended fall-through

[Jiri Kosina]

On Tue, 16 Dec 2014, Peter Wu wrote:

> Add a return to avoid a fall-through. Introduced in commit
> 57ac86cf52e903d9e3e0f12b34c814cce6b65550 ("HID: logitech-hidpp: add
> support of the first Logitech Wireless Touchpad").
> 
> Signed-off-by: Peter Wu 

Applied to for-3.19/upstream-fixes.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: logitech-{dj,hidpp}: check report length

[Jiri Kosina]

On Tue, 16 Dec 2014, Benjamin Tissoires wrote:

> This is my personal opinion and Jiri can say something different. I
> tend not to send big patches while there is a window opened. Sometimes
> Jiri has the time to get through them, sometime he does not.
> In this case, I think the patches you sent should be in the bugs fixes
> categories, and, IMO should make into 3.19-rc1 or 3.19-rc2 (especially
> the length check which could lead to CVEs if not tackled soon enough).
> For these kind of things there is no timing, and the sooner the
> better.
> That being said, make sure that you keep track of those patches in
> case they get lost for obvious reasons and be prepared to remind about
> them if they do not make their way in Jiri's tree.
> 
> Jiri, comments?

I don't mind patches being sent during a merge window, it doesn't disturb 
my workflow.

But it's always good to explicitly mark patches which are bugfixes and 
should go to -rc, so that I bump up the priority for reviewing them.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] f2fs: add extent cache base on rb-tree

[Chao Yu]

Now f2fs have page-block mapping cache which can cache only one extent mapping
between contiguous logical address and physical address.
Normally, this design will work well because f2fs will expand coverage area of
the mapping extent when we write forward sequentially. But when we write data
randomly in Out-Place-Update mode, the extent will be shorten and hardly be
expanded for most time as following reasons:
1.The short part of extent will be discarded if we break contiguous mapping in
the middle of extent.
2.The new mapping will be added into mapping cache only at head or tail of the
extent.
3.We will drop the extent cache when the extent became very fragmented.
4.We will not update the extent with mapping which we get from readpages or
readpage.

To solve above problems, this patch adds extent cache base on rb-tree like other
filesystems (e.g.: ext4/btrfs) in f2fs. By this way, f2fs can support another
more effective cache between dnode page cache and disk. It will supply high hit
ratio in the cache with fewer memory when dnode page cache are reclaimed in
environment of low memory.

Todo:
*introduce mount option for extent cache.
*add shrink ability for extent cache.

Signed-off-by: Chao Yu 
---
 fs/f2fs/data.c  | 348 +---
 fs/f2fs/debug.c |   2 +
 fs/f2fs/f2fs.h  |  49 
 fs/f2fs/inode.c |   5 +-
 fs/f2fs/super.c |  11 +-
 5 files changed, 291 insertions(+), 124 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7ec697b..20592e2 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -24,6 +24,8 @@
 #include "segment.h"
 #include 
 
+struct kmem_cache *extent_info_cache;
+
 static void f2fs_read_end_io(struct bio *bio, int err)
 {
struct bio_vec *bvec;
@@ -247,126 +249,264 @@ int f2fs_reserve_block(struct dnode_of_data *dn, 
pgoff_t index)
return err;
 }
 
-static int check_extent_cache(struct inode *inode, pgoff_t pgofs,
-   struct buffer_head *bh_result)
+static struct extent_info *__insert_extent_cache(struct inode *inode,
+   unsigned int fofs, unsigned int len, u32 blk)
 {
-   struct f2fs_inode_info *fi = F2FS_I(inode);
-   pgoff_t start_fofs, end_fofs;
-   block_t start_blkaddr;
-
-   if (is_inode_flag_set(fi, FI_NO_EXTENT))
-   return 0;
-
-   read_lock(&fi->ext.ext_lock);
-   if (fi->ext.len == 0) {
-   read_unlock(&fi->ext.ext_lock);
-   return 0;
+   struct rb_root *root = &F2FS_I(inode)->ei_tree.root;
+   struct rb_node *p = root->rb_node;
+   struct rb_node *parent = NULL;
+   struct extent_info *ei;
+
+   while (p) {
+   parent = p;
+   ei = rb_entry(parent, struct extent_info, rb_node);
+
+   if (fofs < ei->fofs)
+   p = p->rb_left;
+   else if (fofs >= ei->fofs + ei->len)
+   p = p->rb_right;
+   else
+   f2fs_bug_on(F2FS_I_SB(inode), 1);
}
 
-   stat_inc_total_hit(inode->i_sb);
+   ei = kmem_cache_alloc(extent_info_cache, GFP_ATOMIC);
+   ei->fofs = fofs;
+   ei->blk = blk;
+   ei->len = len;
+
+   rb_link_node(&ei->rb_node, parent, &p);
+   rb_insert_color(&ei->rb_node, root);
+   stat_inc_extent_count(inode->i_sb);
+   return ei;
+}
 
-   start_fofs = fi->ext.fofs;
-   end_fofs = fi->ext.fofs + fi->ext.len - 1;
-   start_blkaddr = fi->ext.blk_addr;
+static bool __remove_extent_cache(struct inode *inode, unsigned int fofs,
+   struct extent_info *cei)
+{
+   struct rb_root *root = &F2FS_I(inode)->ei_tree.root;
+   struct rb_node *p = root->rb_node;
+   struct extent_info *ei;
 
-   if (pgofs >= start_fofs && pgofs <= end_fofs) {
-   unsigned int blkbits = inode->i_sb->s_blocksize_bits;
-   size_t count;
+   while (p) {
+   ei = rb_entry(p, struct extent_info, rb_node);
 
-   clear_buffer_new(bh_result);
-   map_bh(bh_result, inode->i_sb,
-   start_blkaddr + pgofs - start_fofs);
-   count = end_fofs - pgofs + 1;
-   if (count < (UINT_MAX >> blkbits))
-   bh_result->b_size = (count << blkbits);
+   if (fofs < ei->fofs)
+   p = p->rb_left;
+   else if (fofs >= ei->fofs + ei->len)
+   p = p->rb_right;
else
-   bh_result->b_size = UINT_MAX;
+   goto found;
+   }
+   return true;
+found:
+   ei = rb_entry(p, struct extent_info, rb_node);
+   cei->fofs = ei->fofs;
+   cei->blk = ei->blk;
+   cei->len = ei->len;
+   rb_erase(&ei->rb_node, root);
+   kmem_cache_free(extent_info_cache, ei);
+   stat_dec_extent_count(inode->i_sb);
+   return

Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration

[B Viswanath]

On 19 December 2014 at 15:25, Jiri Pirko  wrote:
> Fri, Dec 19, 2014 at 10:35:27AM CET, marichi...@gmail.com wrote:
>>On 19 December 2014 at 14:53, Jiri Pirko  wrote:
>>> Fri, Dec 19, 2014 at 10:01:46AM CET, marichi...@gmail.com wrote:
On 19 December 2014 at 13:57, Jiri Pirko  wrote:
> Fri, Dec 19, 2014 at 06:14:57AM CET, marichi...@gmail.com wrote:
>>On 19 December 2014 at 05:18, Roopa Prabhu  
>>wrote:
>>> On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:



 We also need an interface to set per-switch attributes. Can this work?
 bridge link set dev sw0 sw_attr bcast_flooding 1 master
 where sw0 is a bridge representing the hardware switch.
>>>
>>>
>>> Not today. We discussed this @ LPC, and one way to do this would be to 
>>> have
>>> a device
>>> representing the switch asic. This is in the works.
>>
>>
>>Can I assume that on  platforms which house more than one asic (say
>>two 24 port asics, interconnected via a 10G link or equivalent, to get
>>a 48 port 'switch') , the 'rocker' driver (or similar) should expose
>>them as a single set of ports, and not as two 'switch ports' ?
>
> Well that really depends on particular implementation and drivers. If you
> have 2 pci-e devices, I think you should expose them as 2 entities. For
> sure, you can have the driver to do the masking for you. I don't believe
> that is correct though.
>

In a platform that houses two asic chips, IMO, the user is still
expected to manage the router as a single entity. The configuration
being applied on both asic devices need to be matching if not
identical, and may not be conflicting. The FDB is to be synchronized
so that (offloaded) switching can happen across the asics. Some of
this stuff is asic specific anyway. Another example is that of the
learning. The (hardware) learning can't be enabled on one asic, while
being disabled on another one. The general use cases I have seen are
all involving managing the 'router' as a single entity.  That the
'router' is implemented with two asics instead of a single asic (with
more ports) is to be treated as an implementation detail.  This is the
usual router management method that exists today.

I hope I make sense.

So I am trying to figure out what this single entity that will be used
from a user perspective. It can be a bridge, but our bridges are more
802.1q bridges. We can use the 'self' mode, but then it means that it
should reflect the entire port count, and not just an asic.

So I was trying to deduce that in our switchdevice model, the best bet
would be to leave the unification to the driver (i.e., to project the
multiple physical asics as a single virtual switch device). Thist
>>>
>>> Is it possible to have the asic as just single one? Or is it possible to
>>> connect asics being multiple chips maybe from multiple vendors together?
>>
>>I didn't understand the first question. Some times, it is possible to
>
> I ment that there is a design with just a single asic of this type,
> instead of a pair.
>
>>have a single asic replace two, but its a cost factor, and others that
>>are involved.
>>
>>AFAIK, the answer to the second question is a No. Two asics from
>>different vendors may not be connected together. The interconnect
>>tends to be proprietary.
>
> Okay. In that case, it might make sense to mask it on driver level.
>
>
>>
>>> I believe that answer is "yes" in both cases. Making two separate asics
>>> to appear as one for user is not correct in my opinion. Driver should
>>> not do such masking. It is unclean, unextendable.
>>>
>>
>>I am only looking for a single management entity. I am not thinking it
>>needs to be at driver level. I am not sure of  any other option apart
>>from creating a 'switchdev' that Roopa was mentioning.
>
> Well the thing is there is a common desire to make the offloading as
> transparent as possible. For example, have 4 ports of same switch and
> put them into br0. Just like that, without need to do anything else
> than you would do when bridging ordinary NICs. Introducing some
> "management entity" would break this approach.
>

This is a simple and solid approach that works fine as long as the
asics can be viewed as collection of ports. This is true for many
usecases. However, the asics are more than a collection of ports,
having shared and common infrastructure among the ports. They offer
configuration options that are not specific to any port, but
'belonging' to the asic. So there may be a need in some usecases which
involve in setting up these config options, to somehow identify that
these belong to the asic itself. If there is a single asic, we can
have implied identification, but not with multiple asics.

I guess if we can manage multiple asics belonging to same vendor
within the driver, we probably don't need any suc

Re: [PATCH v2] HID: logitech-hidpp: prefix the name with Logitech

[Jiri Kosina]

On Wed, 17 Dec 2014, Benjamin Tissoires wrote:

> Thanks for applying most of the patches (2 are missing, I'll raise them
> in your inbox :-P )
> 
> Regarding this one, I was wondering if we could not force it into 3.19,
> or at least add a stable@ tag. I had requested this in the first
> submission, and the rationale was to not change a third time the name of
> the device (from "Logitech Unifying Device. Wireless PID:" to
> "[TMK]XXX" to "Logitech [TMK]XXX").
> 
> Userspace would be grateful to have a reliable name.

Fair enough. I've cherry-picked it from for-3.20/logitech into 
for-3.19/upstream-fixes as well.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/7] drm_modes: add videomode_from_drm_display_mode

[Philipp Zabel]

Am Donnerstag, den 18.12.2014, 18:00 -0800 schrieb Steve Longerbeam:
> Add conversion from drm_display_mode to videomode.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/gpu/drm/drm_modes.c |   40 
>  include/drm/drm_modes.h |2 ++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 6d8b941..583a391 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -615,6 +615,46 @@ void drm_display_mode_from_videomode(const struct 
> videomode *vm,
>  }
>  EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
>  
> +/**
> + * videomode_from_drm_display_mode - fill in @vm using @dmode,
> + * @dmode: drm_display_mode structure to use as source
> + * @vm: videomode structure to use as destination
> + *
> + * Fills out @vm using the display mode specified in @dmode.
> + */
> +void videomode_from_drm_display_mode(const struct drm_display_mode *dmode,
> +  struct videomode *vm)
> +{
> + vm->hactive = dmode->hdisplay;
> + vm->hfront_porch = dmode->hsync_start - dmode->hdisplay;
> + vm->hsync_len = dmode->hsync_end - dmode->hsync_start;
> + vm->hback_porch = dmode->htotal - dmode->hsync_end;
> +
> + vm->vactive = dmode->vdisplay;
> + vm->vfront_porch = dmode->vsync_start - dmode->vdisplay;
> + vm->vsync_len = dmode->vsync_end - dmode->vsync_start;
> + vm->vback_porch = dmode->vtotal - dmode->vsync_end;
> +
> + vm->pixelclock = dmode->clock * 1000;
> +
> + vm->flags = 0;
> + if (dmode->flags & DRM_MODE_FLAG_PHSYNC)
> + vm->flags |= DISPLAY_FLAGS_HSYNC_HIGH;
> + else if (dmode->flags & DRM_MODE_FLAG_NHSYNC)
> + vm->flags |= DISPLAY_FLAGS_HSYNC_LOW;
> + if (dmode->flags & DRM_MODE_FLAG_PVSYNC)
> + vm->flags |= DISPLAY_FLAGS_VSYNC_HIGH;
> + else if (dmode->flags & DRM_MODE_FLAG_NVSYNC)
> + vm->flags |= DISPLAY_FLAGS_VSYNC_LOW;
> + if (dmode->flags & DRM_MODE_FLAG_INTERLACE)
> + vm->flags |= DISPLAY_FLAGS_INTERLACED;
> + if (dmode->flags & DRM_MODE_FLAG_DBLSCAN)
> + vm->flags |= DISPLAY_FLAGS_DOUBLESCAN;
> + if (dmode->flags & DRM_MODE_FLAG_DBLCLK)
> + vm->flags |= DISPLAY_FLAGS_DOUBLECLK;
> +}
> +EXPORT_SYMBOL_GPL(videomode_from_drm_display_mode);

Is it ok for drm_modes to export a function that doesn't start with
drm_ ? We could just rename this to drm_display_mode_to_videomode if
necessary. I can fix it up as I apply it, but I'd like to know which is
preferred.

regards
Philipp

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

Re: [PATCH v2 1/7] gpu: ipu-di: Add ipu_di_adjust_videomode()

[Philipp Zabel]

Hi Steve,

Am Donnerstag, den 18.12.2014, 18:00 -0800 schrieb Steve Longerbeam:
> From: Jiada Wang 
> 
> On some monitors, high resolution modes are not working, exhibiting
> pixel column truncation problems (for example, 1280x1024 displays as
> 1280x1022).
> 
> The function ipu_di_adjust_videomode() aims to fix these issues by
> adjusting a passed videomode to IPU restrictions. The function can
> be called from the drm_crtc_helper_funcs->mode_fixup() methods.
> 
> Signed-off-by: Jiada Wang 
> Signed-off-by: Deepak Das 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/gpu/ipu-v3/ipu-di.c |   29 +
>  include/video/imx-ipu-v3.h  |2 ++
>  2 files changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
> index c490ba4..46f9570 100644
> --- a/drivers/gpu/ipu-v3/ipu-di.c
> +++ b/drivers/gpu/ipu-v3/ipu-di.c
> @@ -511,6 +511,35 @@ static void ipu_di_config_clock(struct ipu_di *di,
>   clk_get_rate(di->clk_di_pixel) / (clkgen0 >> 4));
>  }
>  
> +/*
> + * This function is called to adjust a video mode to IPU restrictions.
> + * It is meant to be called from drm crtc mode_fixup() methods.
> + */
> +int ipu_di_adjust_videomode(struct ipu_di *di, struct videomode *mode)
> +{
> + u32 diff;
> +
> + if (mode->vfront_porch >= 2)
> + return 0;
> +
> + diff = 2 - mode->vfront_porch;
> +
> + if (mode->vback_porch >= diff) {
> + mode->vfront_porch = 2;
> + mode->vback_porch -= diff;

Should we also add

else if (mode->vback_porch >= 1 && mode->vsync_len > 1) {
mode->vback_porch--;
mode->vsync_len--;

here and maybe move the two "mode->vback_porch = 2" to a single place
below the conditional statement?

> + } else if (mode->vsync_len > diff) {
> + mode->vfront_porch = 2;
> + mode->vsync_len = mode->vsync_len - diff;

Why use "vback_porch -= diff" above, but not "vsync_len -= diff" here?

> + } else {
> + dev_warn(di->ipu->dev, "failed to adjust videomode\n");
> + return -EINVAL;
> + }
> +
> + dev_warn(di->ipu->dev, "videomode adapted for IPU restrictions\n");

Since we can return the adjusted mode to userspace now, I think this
should be dev_dbg.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rcu_sched stall detected, but no state dump

[Miroslav Benes]

On Mon, 15 Dec 2014, Miroslav Benes wrote:

> On Fri, 12 Dec 2014, Paul E. McKenney wrote:
> 
> > On Fri, Dec 12, 2014 at 03:06:20PM +0100, Miroslav Benes wrote:
> > 

[...]

> > > One last thing. Is there a reason that there is not any similar INFO in 
> > > the console for tiny implementation? I enabled RCU_TRACE and still got 
> > > nothing. I have only shallow knowledge of RCU, though.
> > 
> > It is supposed to work given CONFIG_RCU_TRACE=y, and it looks like
> > it should, at least as long as scheduling-clock interrupts are being
> > delivered.  One thing to try for diagnosis is to have every (say) 1000th
> > call to check_cpu_stall() (in kernel/rcu/tiny_plugin.h) do a printk()
> > and same for rcu_check_callbacks() (in kernel/rcu/tiny.c).
> 
> Unfortunately nothing is there. I'll look into it when I have more time 
> later this week and let you know.

So I looked into it. Scheduling-clock interrupts are delivered and 
check_cpu_stall() in tiny_plugin.h is called twice each tick, once for 
rcu_bh and once for rcu_sched. What happens is the following (part of the 
printk output in check_cpu_stall)...

...
[  276.049053] name: rcu_bh, jiffies: 4294943345, jiffies_stall: 4294964342, 
rcp->curtail:   (null)
[  276.050046] name: rcu_sched, jiffies: 4294943345, jiffies_stall: 4294943357, 
rcp->curtail:   (null)
[  276.051312] name: rcu_bh, jiffies: 4294943347, jiffies_stall: 4294964345, 
rcp->curtail:   (null)
[  276.052305] name: rcu_sched, jiffies: 4294943347, jiffies_stall: 4294943357, 
rcp->curtail:   (null)
[  276.054634] name: rcu_bh, jiffies: 4294943356, jiffies_stall: 4294964347, 
rcp->curtail:   (null)
[  276.054634] name: rcu_sched, jiffies: 4294943356, jiffies_stall: 4294943357, 
rcp->curtail:   (null)
[  276.062989] name: rcu_bh, jiffies: 4294943358, jiffies_stall: 4294964356, 
rcp->curtail:   (null)
[  276.063982] name: rcu_sched, jiffies: 4294943358, jiffies_stall: 4294943357, 
rcp->curtail:   (null)
[  276.065285] name: rcu_bh, jiffies: 4294943361, jiffies_stall: 4294964358, 
rcp->curtail:   (null)
[  276.066278] name: rcu_sched, jiffies: 4294943361, jiffies_stall: 4294964358, 
rcp->curtail:   (null)
[  276.068566] name: rcu_bh, jiffies: 4294943370, jiffies_stall: 4294964361, 
rcp->curtail:   (null)
[  276.068566] name: rcu_sched, jiffies: 4294943370, jiffies_stall: 4294964358, 
rcp->curtail:   (null)
[  276.076867] name: rcu_bh, jiffies: 4294943372, jiffies_stall: 4294964370, 
rcp->curtail:   (null)
[  276.077861] name: rcu_sched, jiffies: 4294943372, jiffies_stall: 4294964358, 
rcp->curtail:   (null)
[  276.079199] name: rcu_bh, jiffies: 4294943375, jiffies_stall: 4294964372, 
rcp->curtail:   (null)
[  276.080193] name: rcu_sched, jiffies: 4294943375, jiffies_stall: 4294964358, 
rcp->curtail:   (null)
[  276.082565] name: rcu_bh, jiffies: 4294943384, jiffies_stall: 4294964375, 
rcp->curtail:   (null)
[  276.082565] name: rcu_sched, jiffies: 4294943384, jiffies_stall: 4294964358, 
rcp->curtail:   (null)
[  276.090984] name: rcu_bh, jiffies: 4294943386, jiffies_stall: 4294964384, 
rcp->curtail:   (null)
[  276.091976] name: rcu_sched, jiffies: 4294943386, jiffies_stall: 4294964358, 
rcp->curtail:   (null)
[  276.093296] name: rcu_bh, jiffies: 4294943389, jiffies_stall: 4294964386, 
rcp->curtail:   (null)
[  276.094289] name: rcu_sched, jiffies: 4294943389, jiffies_stall: 4294964358, 
rcp->curtail:   (null)
...

In case of rcu_bh jiffies_stall is regularly updated and no stall is thus 
detected (if I understand the code correctly). In case of rcu_sched the 
situation is different. jiffies_stall is updated every 21 seconds (my 
RCU_CPU_STALL_TIMEOUT). So I would say the stall should be detected there. 
Unfortunately it is bound to *rcp->curtail being not NULL, and it is in my 
case (in printk output there is rcp->curtail, but it is *rcp->curtail in 
fact). The patch below did the trick for me and cpu stall was detected and 
info printed.

...
[  138.534004] INFO: rcu_sched stall on CPU (41980 ticks this GP) 
idle=141 (t=42000 jiffies q=64)
[  138.534004] CPU: 0 PID: 4140 Comm: test_thread Tainted: G   O   
3.18.0-next-20141218-rcu_tiny_patched+ #1
[  138.534004] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.7.5-0-ge51488c-20141015_183547-build31 04/01/2014
[  138.534004]   81e2ce28 81881b77 
81e2ce48
[  138.534004]  810925c1 81e2ce68  
81e2ce68
[  138.534004]  810932c2  8801395bc650 
81e2ce88
[  138.534004] Call Trace:
[  138.534004][] dump_stack+0x19/0x1b
[  138.534004]  [] check_cpu_stall.part.6+0x61/0xb0
[  138.534004]  [] rcu_check_callbacks+0x82/0x90
[  138.534004]  [] update_process_times+0x38/0x60
[  138.534004]  [] tick_sched_handle.isra.22+0x35/0x50
[  1

[PATCH 0/3] Minor clean up in mpt2sas

[Quentin Lambert]

The first patch merges two similar functions. Since the resulting
function is only called three times, it adds a parameter to differenciate
between the two behaviours.

The second patch proposes a simplification of the function code. The function
previously used a variable to skip through the rest of the loop. It now
uses a break statement to exit it.

The third patch simplifies an unnecesary complicated use of a boolean variable.

Quentin Lambert (3):
  [SCSI] mpt2sas: Merge two similar functions
  [SCSI] mpt2sas: Simplify the code of mpt2sas_scsih_tm_flag
  [SCSI] mpt2sas: Remove unnecessary use of a boolean variable

 drivers/scsi/mpt2sas/mpt2sas_base.c  |  6 +
 drivers/scsi/mpt2sas/mpt2sas_scsih.c | 48 +++-
 2 files changed, 10 insertions(+), 44 deletions(-)

-- 
1.9.1

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

Re: [PATCH] media: ti-vpe: Use mem-to-mem ioctl helpers

[Hans Verkuil]

Hi Prabhakar,

I haven't seen any movement with Nikhil's patches, so it is probably better if
you just post a new version of this patch based on the latest media_tree.

This patch no longer applies cleanly.

Regards,

Hans

On 12/01/2014 12:23 PM, Hans Verkuil wrote:
> On 11/18/2014 02:00 PM, Lad, Prabhakar wrote:
>> This patch does the following:
>>
>> 1: Simplify the vpe mem-to-mem driver by using the m2m ioctl
>>and vb2 helpers.
>> 2: Minor code cleanup
> 
> FYI: I want to postpone this patch until Nikhil's ti-vpe changes are in 
> (assuming
> that will happen soon). I think his series conflicts with this, and it is 
> likely
> to be easier for you to rebase once his code is in.
> 
> Regards,
> 
>   Hans
> 
>>
>> Signed-off-by: Lad, Prabhakar 
>> ---
>>  drivers/media/platform/ti-vpe/vpe.c | 152 
>> +++-
>>  1 file changed, 47 insertions(+), 105 deletions(-)
>>
>> diff --git a/drivers/media/platform/ti-vpe/vpe.c 
>> b/drivers/media/platform/ti-vpe/vpe.c
>> index 74b858d..faf38d4 100644
>> --- a/drivers/media/platform/ti-vpe/vpe.c
>> +++ b/drivers/media/platform/ti-vpe/vpe.c
>> @@ -21,6 +21,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -377,7 +378,6 @@ struct vpe_dev {
>>  struct vpe_ctx {
>>  struct v4l2_fh  fh;
>>  struct vpe_dev  *dev;
>> -struct v4l2_m2m_ctx *m2m_ctx;
>>  struct v4l2_ctrl_handler hdl;
>>  
>>  unsigned intfield;  /* current field */
>> @@ -916,8 +916,8 @@ static int job_ready(void *priv)
>>   * When called by m2m framework, this will always satisy, but when
>>   * called from vpe_irq, this might fail. (src stream with zero buffers)
>>   */
>> -if (v4l2_m2m_num_src_bufs_ready(ctx->m2m_ctx) <= 0 ||
>> -v4l2_m2m_num_dst_bufs_ready(ctx->m2m_ctx) <= 0)
>> +if (v4l2_m2m_num_src_bufs_ready(ctx->fh.m2m_ctx) <= 0 ||
>> +v4l2_m2m_num_dst_bufs_ready(ctx->fh.m2m_ctx) <= 0)
>>  return 0;
>>  
>>  return 1;
>> @@ -1155,14 +1155,14 @@ static void device_run(void *priv)
>>   * in the same buffer. (so that job_ready won't fail)
>>   * It will be removed when using bottom field
>>   */
>> -ctx->src_vbs[0] = v4l2_m2m_next_src_buf(ctx->m2m_ctx);
>> +ctx->src_vbs[0] = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
>>  WARN_ON(ctx->src_vbs[0] == NULL);
>>  } else {
>> -ctx->src_vbs[0] = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
>> +ctx->src_vbs[0] = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
>>  WARN_ON(ctx->src_vbs[0] == NULL);
>>  }
>>  
>> -ctx->dst_vb = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
>> +ctx->dst_vb = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
>>  WARN_ON(ctx->dst_vb == NULL);
>>  
>>  if (ctx->deinterlacing) {
>> @@ -1422,7 +1422,7 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
>>  finished:
>>  vpe_dbg(ctx->dev, "finishing transaction\n");
>>  ctx->bufs_completed = 0;
>> -v4l2_m2m_job_finish(dev->m2m_dev, ctx->m2m_ctx);
>> +v4l2_m2m_job_finish(dev->m2m_dev, ctx->fh.m2m_ctx);
>>  handled:
>>  return IRQ_HANDLED;
>>  }
>> @@ -1483,7 +1483,7 @@ static int vpe_g_fmt(struct file *file, void *priv, 
>> struct v4l2_format *f)
>>  struct vpe_q_data *q_data;
>>  int i;
>>  
>> -vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
>> +vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, f->type);
>>  if (!vq)
>>  return -EINVAL;
>>  
>> @@ -1624,7 +1624,7 @@ static int __vpe_s_fmt(struct vpe_ctx *ctx, struct 
>> v4l2_format *f)
>>  struct vb2_queue *vq;
>>  int i;
>>  
>> -vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
>> +vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, f->type);
>>  if (!vq)
>>  return -EINVAL;
>>  
>> @@ -1852,55 +1852,6 @@ static int vpe_s_selection(struct file *file, void 
>> *fh,
>>  return set_srcdst_params(ctx);
>>  }
>>  
>> -static int vpe_reqbufs(struct file *file, void *priv,
>> -   struct v4l2_requestbuffers *reqbufs)
>> -{
>> -struct vpe_ctx *ctx = file2ctx(file);
>> -
>> -return v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
>> -}
>> -
>> -static int vpe_querybuf(struct file *file, void *priv, struct v4l2_buffer 
>> *buf)
>> -{
>> -struct vpe_ctx *ctx = file2ctx(file);
>> -
>> -return v4l2_m2m_querybuf(file, ctx->m2m_ctx, buf);
>> -}
>> -
>> -static int vpe_qbuf(struct file *file, void *priv, struct v4l2_buffer *buf)
>> -{
>> -struct vpe_ctx *ctx = file2ctx(file);
>> -
>> -return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
>> -}
>> -
>> -static int vpe_dqbuf(struct file *file, void *priv, struct v4l2_buffer *buf)
>> -{
>> -struct vpe_ctx *ctx = file2ctx(file);
>> -
>> -return v4l2_m2m_dqbuf(file, ctx->m2m_ctx, buf);
>> -}
>> -
>> -static int vpe_streamon(struct file *file, void *priv, enum v4l2_buf_type 
>> type)
>>

[PATCH 1/3] [SCSI] mpt2sas: Merge two similar functions

[Quentin Lambert]

mpt2sas_scsih_set_tm_flag and mpt2sas_scsih_clear_tm_flag
shared a lot of code. Therefore, they are merged into one
function whose behaviour is given by a new parameter
named action.

Signed-off-by: Quentin Lambert 
---
 drivers/scsi/mpt2sas/mpt2sas_scsih.c | 43 +++-
 1 file changed, 8 insertions(+), 35 deletions(-)

diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c 
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 6a1c036..a6f89fd 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -2253,14 +2253,15 @@ _scsih_tm_done(struct MPT2SAS_ADAPTER *ioc, u16 smid, 
u8 msix_index, u32 reply)
 }
 
 /**
- * mpt2sas_scsih_set_tm_flag - set per target tm_busy
+ * mpt2sas_scsih_tm_flag - set/clear per target tm_busy
  * @ioc: per adapter object
  * @handle: device handle
+ * @action: 1 set per target tm_busy, 0 clear per target tm_busy
  *
  * During taskmangement request, we need to freeze the device queue.
  */
 void
-mpt2sas_scsih_set_tm_flag(struct MPT2SAS_ADAPTER *ioc, u16 handle)
+mpt2sas_scsih_tm_flag(struct MPT2SAS_ADAPTER *ioc, u16 handle, u8 action)
 {
struct MPT2SAS_DEVICE *sas_device_priv_data;
struct scsi_device *sdev;
@@ -2273,37 +2274,9 @@ mpt2sas_scsih_set_tm_flag(struct MPT2SAS_ADAPTER *ioc, 
u16 handle)
if (!sas_device_priv_data)
continue;
if (sas_device_priv_data->sas_target->handle == handle) {
-   sas_device_priv_data->sas_target->tm_busy = 1;
+   sas_device_priv_data->sas_target->tm_busy = action;
skip = 1;
-   ioc->ignore_loginfos = 1;
-   }
-   }
-}
-
-/**
- * mpt2sas_scsih_clear_tm_flag - clear per target tm_busy
- * @ioc: per adapter object
- * @handle: device handle
- *
- * During taskmangement request, we need to freeze the device queue.
- */
-void
-mpt2sas_scsih_clear_tm_flag(struct MPT2SAS_ADAPTER *ioc, u16 handle)
-{
-   struct MPT2SAS_DEVICE *sas_device_priv_data;
-   struct scsi_device *sdev;
-   u8 skip = 0;
-
-   shost_for_each_device(sdev, ioc->shost) {
-   if (skip)
-   continue;
-   sas_device_priv_data = sdev->hostdata;
-   if (!sas_device_priv_data)
-   continue;
-   if (sas_device_priv_data->sas_target->handle == handle) {
-   sas_device_priv_data->sas_target->tm_busy = 0;
-   skip = 1;
-   ioc->ignore_loginfos = 0;
+   ioc->ignore_loginfos = action;
}
}
 }
@@ -2401,7 +2374,7 @@ mpt2sas_scsih_issue_tm(struct MPT2SAS_ADAPTER *ioc, u16 
handle, uint channel,
mpi_request->TaskType = type;
mpi_request->TaskMID = cpu_to_le16(smid_task);
int_to_scsilun(lun, (struct scsi_lun *)mpi_request->LUN);
-   mpt2sas_scsih_set_tm_flag(ioc, handle);
+   mpt2sas_scsih_tm_flag(ioc, handle, 1);
init_completion(&ioc->tm_cmds.done);
mpt2sas_base_put_smid_hi_priority(ioc, smid);
timeleft = wait_for_completion_timeout(&ioc->tm_cmds.done, timeout*HZ);
@@ -2415,7 +2388,7 @@ mpt2sas_scsih_issue_tm(struct MPT2SAS_ADAPTER *ioc, u16 
handle, uint channel,
FORCE_BIG_HAMMER);
rc = (!rc) ? SUCCESS : FAILED;
ioc->tm_cmds.status = MPT2_CMD_NOT_USED;
-   mpt2sas_scsih_clear_tm_flag(ioc, handle);
+   mpt2sas_scsih_tm_flag(ioc, handle, 0);
goto err_out;
}
}
@@ -2465,7 +2438,7 @@ mpt2sas_scsih_issue_tm(struct MPT2SAS_ADAPTER *ioc, u16 
handle, uint channel,
break;
}
 
-   mpt2sas_scsih_clear_tm_flag(ioc, handle);
+   mpt2sas_scsih_tm_flag(ioc, handle, 0);
ioc->tm_cmds.status = MPT2_CMD_NOT_USED;
if (m_type == TM_MUTEX_ON)
mutex_unlock(&ioc->tm_cmds.mutex);
-- 
1.9.1

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

[PATCH 2/3] [SCSI] mpt2sas: Simplify the code of mpt2sas_scsih_tm_flag

[Quentin Lambert]

Since skip was only used to pass through the rest of the loop,
a break statment is called where skip was previously assigned 1.

Signed-off-by: Quentin Lambert 
---
 drivers/scsi/mpt2sas/mpt2sas_scsih.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c 
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index a6f89fd..6162a89 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -2265,18 +2265,15 @@ mpt2sas_scsih_tm_flag(struct MPT2SAS_ADAPTER *ioc, u16 
handle, u8 action)
 {
struct MPT2SAS_DEVICE *sas_device_priv_data;
struct scsi_device *sdev;
-   u8 skip = 0;
 
shost_for_each_device(sdev, ioc->shost) {
-   if (skip)
-   continue;
sas_device_priv_data = sdev->hostdata;
if (!sas_device_priv_data)
continue;
if (sas_device_priv_data->sas_target->handle == handle) {
sas_device_priv_data->sas_target->tm_busy = action;
-   skip = 1;
ioc->ignore_loginfos = action;
+   break;
}
}
 }
-- 
1.9.1

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

[PATCH 3/3] [SCSI] mpt2sas: Remove unnecessary use of a boolean variable

[Quentin Lambert]

Signed-off-by: Quentin Lambert 
---
 drivers/scsi/mpt2sas/mpt2sas_base.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c 
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 58e4521..c31de9d 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1414,12 +1414,8 @@ _base_enable_msix(struct MPT2SAS_ADAPTER *ioc)
struct msix_entry *entries, *a;
int r;
int i;
-   u8 try_msix = 0;
 
-   if (msix_disable == -1 || msix_disable == 0)
-   try_msix = 1;
-
-   if (!try_msix)
+   if (msix_disable != -1 || msix_disable != 0)
goto try_ioapic;
 
if (_base_check_enable_msix(ioc) != 0)
-- 
1.9.1

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

[PATCH] drm/fb-helper: fix simple_return.cocci warnings

[kbuild test robot]

drivers/gpu/drm/cirrus/cirrus_fbdev.c:330:1-4: WARNING: end returns can be 
simpified

 Simplify a trivial if-return sequence.  Possibly combine with a
 preceding function call.
Generated by: scripts/coccinelle/misc/simple_return.cocci

CC: Thierry Reding 
Signed-off-by: Fengguang Wu 
---

 cirrus_fbdev.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -327,11 +327,7 @@ int cirrus_fbdev_init(struct cirrus_devi
/* disable all the possible outputs/crtcs before entering KMS mode */
drm_helper_disable_unused_functions(cdev->dev);
 
-   ret = drm_fb_helper_initial_config(&gfbdev->helper, bpp_sel);
-   if (ret)
-   return ret;
-
-   return 0;
+   return drm_fb_helper_initial_config(&gfbdev->helper, bpp_sel);
 }
 
 void cirrus_fbdev_fini(struct cirrus_device *cdev)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sched: odd values for effective load calculations

[Peter Zijlstra]

On Fri, Dec 19, 2014 at 08:29:56AM +0800, Yuyang Du wrote:
> Subject: [PATCH] sched: Fix long and unsigned long multiplication error in 
> effective_load
> 
> In effective_load, we have (long w * unsigned long tg->shares) / long W,
> when w is negative, it is cast to unsigned long and hence the product is
> insanely large. Fix this by casting tg->shares to long.
> 
> Reported-by: Sasha Levin 
> Signed-off-by: Yuyang Du 
> ---
>  kernel/sched/fair.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index df2cdf7..6b99659 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4424,7 +4424,7 @@ static long effective_load(struct task_group *tg, int 
> cpu, long wl, long wg)
>* wl = S * s'_i; see (2)
>*/
>   if (W > 0 && w < W)
> - wl = (w * tg->shares) / W;
> + wl = (w * (long)tg->shares) / W;
>   else
>   wl = tg->shares;


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