Re: [Patch -v4 1/4] Migrate shutdown/reboot to boot cpu.

[Srivatsa S. Bhat]

On 04/16/2013 05:36 PM, Robin Holt wrote:
> On Tue, Apr 16, 2013 at 01:32:56PM +0200, Ingo Molnar wrote:
>>
>> * Robin Holt  wrote:
>>
>>> We recently noticed that reboot of a 1024 cpu machine takes approx 16
>>> minutes of just stopping the cpus.  The slowdown was tracked to commit
>>> f96972f.
>>>
>>> The current implementation does all the work of hot removing the cpus
>>> before halting the system.  We are switching to just migrating to the
>>> boot cpu and then continuing with shutdown/reboot.
>>>
>>> This also has the effect of not breaking x86's command line parameter for
>>> specifying the reboot cpu.  Note, this code was shamelessly copied from
>>> arch/x86/kernel/reboot.c with bits removed pertaining to the reboot_cpu
>>> command line parameter.
>>>
>>> Signed-off-by: Robin Holt 
>>> Tested-by: Shawn Guo 
>>> To: Ingo Molnar 
>>> To: Russ Anderson 
>>> To: Oleg Nesterov 
>>> Cc: Andrew Morton 
>>> Cc: "H. Peter Anvin" 
>>> Cc: Lai Jiangshan 
>>> Cc: Linus Torvalds 
>>> Cc: Linux Kernel Mailing List 
>>> Cc: Michel Lespinasse 
>>> Cc: Oleg Nesterov 
>>> Cc: "Paul E. McKenney" 
>>> Cc: Paul Mackerras 
>>> Cc: Peter Zijlstra 
>>> Cc: Robin Holt 
>>> Cc: "ru...@rustcorp.com.au" 
>>> Cc: Tejun Heo 
>>> Cc: the arch/x86 maintainers 
>>> Cc: Thomas Gleixner 
>>> Cc: 
>>>
>>> ---
>>>
>>> Changes since -v1.
>>> - Set PF_THREAD_BOUND before migrating to eliminate potential race.
>>> - Modified kernel_power_off to also migrate instead of using
>>>   disable_nonboot_cpus().
>>> ---
>>>  kernel/sys.c | 22 +++---
>>>  1 file changed, 19 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/kernel/sys.c b/kernel/sys.c
>>> index 0da73cf..5ef7aa2 100644
>>> --- a/kernel/sys.c
>>> +++ b/kernel/sys.c
>>> @@ -357,6 +357,22 @@ int unregister_reboot_notifier(struct notifier_block 
>>> *nb)
>>>  }
>>>  EXPORT_SYMBOL(unregister_reboot_notifier);
>>>  
>>> +void migrate_to_reboot_cpu(void)
>>
>> It appears to be file-scope, so should be static I guess?
> 
> Done.
> 
>>> +{
>>> +   /* The boot cpu is always logical cpu 0 */
>>> +   int reboot_cpu_id = 0;
>>> +
>>> +   /* Make certain the cpu I'm about to reboot on is online */
>>> +   if (!cpu_online(reboot_cpu_id))
>>> +   reboot_cpu_id = smp_processor_id();
>>
>> Shouldn't we pick the first online CPU instead, to make it deterministic?
> 
> Done.
> 
>   reboot_cpu_id = cpumask_first(cpu_online_mask);
> 

Let me ask again: if CPU 0 (or whatever the preferred reboot cpu is)
is offline, then why should we even bother pinning the task to (another)
CPU? Why not just proceed with the reboot?

Regards,
Srivatsa S. Bhat


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [NEW DRIVER V4 2/7] DA9058 ADC driver

[Lars-Peter Clausen]

On 04/16/2013 04:22 PM, Opensource [Anthony Olech] wrote:
>> [...]
>> please always test your drivers against the latest upstream version before 
>> submitting them.
>> [...]
> 
> Hi Lars,
> 
> The driver was tested against linux mainline tag v3.9-rc6, because that was 
> the most recent
> tagged commit in 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git on the day
> that I sent in the patches.
> 
> What exactly do you mean by "latest upstream version" ?
> Did I use the correct repository ?

So, there are usually subsystem specific trees. You can usually find them in
the MAINTAINERS file. E.g. for the IIO subsystem it is
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
The subsystem trees can be up to 3 months (one release) ahead of Linus'
tree. If in doubt place your changes ontop of the next tree, which should
have all the changes from the subsystem trees.

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

Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Stephen Warren]

On 04/16/2013 03:36 AM, Wolfram Sang wrote:
> Doug,
> 
> On Tue, Apr 09, 2013 at 02:34:28PM -0700, Doug Anderson wrote:
>> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
>> where masters need to claim the bus with a GPIO before they can start
>> a transcation.  This should generally only be used when standard I2C
>> multimaster isn't appropriate for some reason (errata/bugs).
>>
>> This driver is based on code that Simon Glass added to the i2c-s3c2410
>> driver in the Chrome OS kernel 3.4 tree.  The current incarnation as a
>> mux driver is as suggested by Grant Likely.  See
>>  for some history.

>> diff --git 
>> a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt 
>> b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt

>> +GPIO-based I2C Arbitration
>> +==
>> +This uses GPIO lines to arbitrate who is the master of an I2C bus in a
>> +multimaster situation.
> 
> "uses GPIO lines and a challange & response mechanism" or something like
> that. There might be other GPIO based arbitrations in the future (though
> I hope there won't).

The existing text appears clearer to me; this document should spell out
the exact details of the protocol in later paragraphs, so there's no
need to try and spell it out here.

>> +- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
>> +  Note that some implementations may only support a single other master.
> 
> Stronger? "Currently, only one other master is supported"?

The DT binding documentation, which should be OS-/driver-agnostic,
should describe the binding, not the implementation. The limitation that
Linux imposes is OS-specific and hence should not be mentioned here as
an absolute, or perhaps even at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: musb: gadget: fix enumeration on heavy-loaded systems

[Ruslan Bilovol]

>From musb point of view, the Address Assignment sequence during
device enumeration is next:
 - first ep0 interrupt:
* read the address from USB_REQ_SET_ADDRESS request
* set up CSR0L.DataEnd bit (that is ACK
  signalization for the host)
 - second ep0 interrupt:
* indicates that the request completed successfully
* set up musb device address
  Now musb device should answer to this address

>From the host perspective, if peripheral device acquires
SET_ADDRESS request, it now may be accessed only using that address.
However, on heavy loaded systems, time between first and
second musb ep0 interrupts may be too long and musb controller
misses requests between. As result, device enumeration may be
unsuccessful. This can be checked on USB3.0 Host and
using USB3.0 test suite (from usb.org) running ch9 tests
for USB2.0 devices.
Usually 'Addressed state/TD9.1: Device Descriptor Test' will fail

The fix consists in checking CSR0L.DataEnd state and assigning
the device address in the first ep0 interrupt handling, so
delay is as minimal as possible

Signed-off-by: Ruslan Bilovol 
---
 drivers/usb/musb/musb_gadget_ep0.c |   31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/usb/musb/musb_gadget_ep0.c 
b/drivers/usb/musb/musb_gadget_ep0.c
index c9c1ac4..59bc5a5 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -885,6 +885,37 @@ stall:
 finish:
musb_writew(regs, MUSB_CSR0,
musb->ackpend);
+
+   /*
+* If we are at end of SET_ADDRESS sequence,
+* update the address immediately if possible,
+* otherwise we may miss packets between
+* sending ACK from musb side and musb's next
+* interrupt handler firing (in which we update
+* the address). At least this fixes next
+* USB2.0 ch9 test of USB30CV utility:
+* "Addressed state - Device Descriptor test"
+*/
+   if (musb->set_address && (musb->ackpend &
+   MUSB_CSR0_P_DATAEND) &&
+   (musb->ep0_state ==
+   MUSB_EP0_STAGE_STATUSIN)) {
+   u16 ack_delay = 500;
+
+   while ((musb_readw(regs, MUSB_CSR0) &
+   MUSB_CSR0_P_DATAEND) &&
+   --ack_delay) {
+   cpu_relax();
+   udelay(1);
+   }
+
+   if (ack_delay) {
+   musb->set_address = false;
+   musb_writeb(mbase, MUSB_FADDR,
+   musb->address);
+   }
+   }
+
musb->ackpend = 0;
}
}
-- 
1.7.9.5

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

Re: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with Freescale P1020

[Alan Stern]

On Mon, 15 Apr 2013, Michael Braun wrote:

> Hi,
> 
> I'm running OpenWRT Kernel 3.8.3 (which already has 
> f66dea709cd9309b2ee9f715697818001fb518de and 
> 5ed338778f917a035f0f0a52327fc4f72e36f7a1 applied) on a P1020WLAN (QorlQ, 
> PPC) device.
> Before updating the kernel from 3.3.0, USB host support was working 
> fine. Now I get "fsl-ehci: USB PHY clock invalid" messages in dmesg and 
> the lsusb output is empty, so USB host support is not working. When I 
> apply the following patch, USB host support starts working again, so I 
> guess 3735ba8db8e6ea22ad3ff524328926d8d780a884 is the cause.

Why didn't you CC: the author of that commit?  Isn't he the person most 
likely to be able to fix it?

Alan Stern

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

[Mike Snitzer]

You misunderstood me.  I was just making sure Darrick knew about this other 
migration change because without it the specific commit you pointed to for mq 
won't get the performance improvement.  So I was just trying to make sure if 
Darrick or others cherry picked they didn't miss out.

[PATCH -next] staging/media: fix go7007 dependencies and build

[Randy Dunlap]

From: Randy Dunlap 

VIDEO_GO7007 uses usb interfaces so it should depend on USB.
It also selects CYPRESS_FIRMWARE, which depends on USB.

Fixes build errors and a kconfig warning:

go7007-loader.c:(.text+0xcc7d0): undefined reference to `usb_get_dev'
go7007-loader.c:(.init.text+0x49f0): undefined reference to 
`usb_register_driver'
go7007-loader.c:(.exit.text+0x17ce): undefined reference to `usb_deregister'

warning: (DVB_USB_AZ6007 && VIDEO_GO7007) selects CYPRESS_FIRMWARE which has 
unmet direct dependencies (MEDIA_SUPPORT && USB)

Signed-off-by: Randy Dunlap 
---
 drivers/staging/media/go7007/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20130416.orig/drivers/staging/media/go7007/Kconfig
+++ linux-next-20130416/drivers/staging/media/go7007/Kconfig
@@ -1,7 +1,7 @@
 config VIDEO_GO7007
tristate "WIS GO7007 MPEG encoder support"
depends on VIDEO_DEV && I2C
-   depends on SND
+   depends on SND && USB
select VIDEOBUF2_VMALLOC
select VIDEO_TUNER
select CYPRESS_FIRMWARE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] regulator: ab8500-ext: Remove enable() and disable() functions

[Axel Lin]

Both enable() and disable() functions have only one caller, thus remove them.

Signed-off-by: Axel Lin 
---
 drivers/regulator/ab8500-ext.c |   64 +++-
 1 file changed, 23 insertions(+), 41 deletions(-)

diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index 03faf9c..b4d4547 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -54,32 +54,44 @@ struct ab8500_ext_regulator_info {
u8 update_val_hw;
 };
 
-static int enable(struct ab8500_ext_regulator_info *info, u8 *regval)
+static int ab8500_ext_regulator_enable(struct regulator_dev *rdev)
 {
int ret;
+   struct ab8500_ext_regulator_info *info = rdev_get_drvdata(rdev);
+   u8 regval;
 
-   *regval = info->update_val;
+   if (info == NULL) {
+   dev_err(rdev_get_dev(rdev), "regulator info null pointer\n");
+   return -EINVAL;
+   }
 
/*
 * To satisfy both HW high power request and SW request, the regulator
 * must be on in high power.
 */
if (info->cfg && info->cfg->hwreq)
-   *regval = info->update_val_hp;
+   regval = info->update_val_hp;
+   else
+   regval = info->update_val;
 
ret = abx500_mask_and_set_register_interruptible(info->dev,
info->update_bank, info->update_reg,
-   info->update_mask, *regval);
+   info->update_mask, regval);
if (ret < 0) {
dev_err(rdev_get_dev(info->rdev),
"couldn't set enable bits for regulator\n");
return ret;
}
 
-   return ret;
+   dev_dbg(rdev_get_dev(rdev),
+   "%s-enable (bank, reg, mask, value): 0x%02x, 0x%02x, 0x%02x, 
0x%02x\n",
+   info->desc.name, info->update_bank, info->update_reg,
+   info->update_mask, regval);
+
+   return 0;
 }
 
-static int ab8500_ext_regulator_enable(struct regulator_dev *rdev)
+static int ab8500_ext_regulator_disable(struct regulator_dev *rdev)
 {
int ret;
struct ab8500_ext_regulator_info *info = rdev_get_drvdata(rdev);
@@ -90,59 +102,29 @@ static int ab8500_ext_regulator_enable(struct 
regulator_dev *rdev)
return -EINVAL;
}
 
-   ret = enable(info, );
-
-   dev_dbg(rdev_get_dev(rdev), "%s-enable (bank, reg, mask, value):"
-   " 0x%02x, 0x%02x, 0x%02x, 0x%02x\n",
-   info->desc.name, info->update_bank, info->update_reg,
-   info->update_mask, regval);
-
-   return ret;
-}
-
-static int disable(struct ab8500_ext_regulator_info *info, u8 *regval)
-{
-   int ret;
-
-   *regval = 0x0;
-
/*
 * Set the regulator in HW request mode if configured
 */
if (info->cfg && info->cfg->hwreq)
-   *regval = info->update_val_hw;
+   regval = info->update_val_hw;
+   else
+   regval = 0;
 
ret = abx500_mask_and_set_register_interruptible(info->dev,
info->update_bank, info->update_reg,
-   info->update_mask, *regval);
+   info->update_mask, regval);
if (ret < 0) {
dev_err(rdev_get_dev(info->rdev),
"couldn't set disable bits for regulator\n");
return ret;
}
 
-   return ret;
-}
-
-static int ab8500_ext_regulator_disable(struct regulator_dev *rdev)
-{
-   int ret;
-   struct ab8500_ext_regulator_info *info = rdev_get_drvdata(rdev);
-   u8 regval;
-
-   if (info == NULL) {
-   dev_err(rdev_get_dev(rdev), "regulator info null pointer\n");
-   return -EINVAL;
-   }
-
-   ret = disable(info, );
-
dev_dbg(rdev_get_dev(rdev), "%s-disable (bank, reg, mask, value):"
" 0x%02x, 0x%02x, 0x%02x, 0x%02x\n",
info->desc.name, info->update_bank, info->update_reg,
info->update_mask, regval);
 
-   return ret;
+   return 0;
 }
 
 static int ab8500_ext_regulator_is_enabled(struct regulator_dev *rdev)
-- 
1.7.10.4



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

Re: [PATCH 2/2] USB: ehci-omap: Improve PHY error handling

[Alan Stern]

On Mon, 15 Apr 2013, Roger Quadros wrote:

> As the USB PHY layer never returns NULL we don't need
> to check for that condition.
> 
> If we fail to get the PHY device it could be due
> to missing USB PHY drivers. Give this hint to the user
> in the error message.
> 
> CC: Alan Stern 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/host/ehci-omap.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
> index 5de3e43..2e34ddd 100644
> --- a/drivers/usb/host/ehci-omap.c
> +++ b/drivers/usb/host/ehci-omap.c
> @@ -175,13 +175,13 @@ static int ehci_hcd_omap_probe(struct platform_device 
> *pdev)
>   phy = devm_usb_get_phy_by_phandle(dev, "phys", i);
>   else
>   phy = devm_usb_get_phy_dev(dev, i);
> - if (IS_ERR(phy) || !phy) {
> + if (IS_ERR(phy)) {
>   /* Don't bail out if PHY is not absolutely necessary */
>   if (pdata->port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
>   continue;
>  
> - ret = IS_ERR(phy) ? PTR_ERR(phy) : -ENODEV;
> - dev_err(dev, "Can't get PHY device for port %d: %d\n",
> + ret = PTR_ERR(phy);
> + dev_err(dev, "Can't get PHY device for port %d: %d. Is 
> USB_PHY driver enabled?\n",
>   i, ret);
>   goto err_phy;
>   }

Getting rid of the !phy test is good.  But I'm doubtful about the 
change to the error message.  Are you going to make a similar change to 
every platform driver?  There doesn't seem to be any reason to do this 
for ehci-omap but not the others.

Alan Stern

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

Re: [PATCH 1/2] USB: ehci-omap: Don't select any PHY driver

[Alan Stern]

On Mon, 15 Apr 2013, Roger Quadros wrote:

> Don't select NOP_USB_XCEIV. Instead, board config
> must select USB_PHY and the appropriate PHY driver.
> 
> Also add a hint in Kconfig so that users enabling
> this driver manually enable the right PHY drivers as well.
> 
> Gets rid of the below warnings when USB_EHCI_HCD_OMAP
> is enabled.
> 
> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct 
> dependencies (USB_SUPPORT && USB_PHY)
> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct 
> dependencies (USB_SUPPORT && USB_PHY)
> 
> CC: Alan Stern 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/host/Kconfig |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index c0be25c..c558472 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -150,11 +150,13 @@ config USB_EHCI_MXC
>  config USB_EHCI_HCD_OMAP
>   tristate "EHCI support for OMAP3 and later chips"
>   depends on ARCH_OMAP
> - select NOP_USB_XCEIV
>   default y
>   ---help---
> Enables support for the on-chip EHCI controller on
> OMAP3 and later chips.
> +   If your system uses a PHY on the USB port, you will need to
> +   enable USB_PHY and the appropriate PHY driver as well. Most
> +   boards need the NOP_USB_XCEIV PHY driver.
>  
>  config USB_EHCI_HCD_ORION
>   tristate  "Support for Marvell EBU on-chip EHCI USB controller"

Acked-by: Alan Stern 

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

[PATCH v2 1/2] regulator: ab8500-ext: Don't update info->update_val if set_mode() fails

[Axel Lin]

This ensures info->update_val status is still correct if set_mode() call fails.
Otherwise, get_mode() may return wrong status if a set_mode() call fails.

Signed-off-by: Axel Lin 
---
 drivers/regulator/ab8500-ext.c |   26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index 20680f3..03faf9c 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -181,6 +181,7 @@ static int ab8500_ext_regulator_set_mode(struct 
regulator_dev *rdev,
 {
int ret = 0;
struct ab8500_ext_regulator_info *info = rdev_get_drvdata(rdev);
+   u8 regval;
 
if (info == NULL) {
dev_err(rdev_get_dev(rdev), "regulator info null pointer\n");
@@ -189,23 +190,30 @@ static int ab8500_ext_regulator_set_mode(struct 
regulator_dev *rdev,
 
switch (mode) {
case REGULATOR_MODE_NORMAL:
-   info->update_val = info->update_val_hp;
+   regval = info->update_val_hp;
break;
case REGULATOR_MODE_IDLE:
-   info->update_val = info->update_val_lp;
+   regval = info->update_val_lp;
break;
 
default:
return -EINVAL;
}
 
-   if (ab8500_ext_regulator_is_enabled(rdev)) {
-   u8 regval;
-
-   ret = enable(info, );
-   if (ret < 0)
+   /* If regulator is enabled and info->cfg->hwreq is set, the regulator
+  must be on in high power, so we don't need to write the register with
+  the same value.
+*/
+   if (ab8500_ext_regulator_is_enabled(rdev) &&
+   !(info->cfg && info->cfg->hwreq)) {
+   ret = abx500_mask_and_set_register_interruptible(info->dev,
+   info->update_bank, info->update_reg,
+   info->update_mask, regval);
+   if (ret < 0) {
dev_err(rdev_get_dev(rdev),
"Could not set regulator mode.\n");
+   return ret;
+   }
 
dev_dbg(rdev_get_dev(rdev),
"%s-set_mode (bank, reg, mask, value): "
@@ -214,7 +222,9 @@ static int ab8500_ext_regulator_set_mode(struct 
regulator_dev *rdev,
info->update_mask, regval);
}
 
-   return ret;
+   info->update_val = regval;
+
+   return 0;
 }
 
 static unsigned int ab8500_ext_regulator_get_mode(struct regulator_dev *rdev)
-- 
1.7.10.4



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

Re: [RFT][PATCH 1/3] regulator: ab8500-ext: Don't allow set idle mode if info->cfg->hwreq is set

[Axel Lin]

2013/4/16 Bengt Jönsson :
> On 04/10/2013 02:54 PM, Axel Lin wrote:
>>
>> The regulator always on with high power mode if info->cfg->hwreq is set.
>>
>> If we allow set idle mode when info->cfg->hwreq is set, get_mode() returns
>> REGULATOR_MODE_IDLE but the regulator actually is in REGULATOR_MODE_NORMAL
>> mode.
>> This patch avoid inconsistent status return by get_mode().
>>
>> Signed-off-by: Axel Lin z
>>
>> ---
>>   drivers/regulator/ab8500-ext.c |4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/regulator/ab8500-ext.c
>> b/drivers/regulator/ab8500-ext.c
>> index 9aee21c..f0a1bbf 100644
>> --- a/drivers/regulator/ab8500-ext.c
>> +++ b/drivers/regulator/ab8500-ext.c
>> @@ -192,6 +192,10 @@ static int ab8500_ext_regulator_set_mode(struct
>> regulator_dev *rdev,
>> info->update_val = info->update_val_hp;
>> break;
>> case REGULATOR_MODE_IDLE:
>> +   /* Always on with high power mode if info->cfg->hwreq is
>> set */
>> +   if (info->cfg && info->cfg->hwreq)
>> +   return -EINVAL;
>> +
>> info->update_val = info->update_val_lp;
>> break;
>>
>
> I prefer to have info->update_val updated to reflect requested mode (in
> get_mode) instead of returning -EINVAL. This is how I interpret Mark's
> comment on the other patch ([PATCH] regulator: ab8500: Fix get_mode for
> shared mode regulators).Otherwise, the patch should work fine.

Well, I drop this path and send v2 for other patches now.

Thanks for the review,
Axel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/3] sched: Scale load contribution by CPU Capacity

[Chris Redpath]

Modulate the tracked load of a task using the measure of current
and maximum compute capacity for the core it is executing on.

Change-Id: If6aea806e631f2313fd925c8902260a522663dbd

Conflicts:

kernel/sched/fair.c
---
 kernel/sched/fair.c |   51 +++
 1 file changed, 43 insertions(+), 8 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f6bbe1e..3f3ee08 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1319,11 +1319,15 @@ static inline void update_cpu_capacity(int cpu)
 static __always_inline int __update_entity_runnable_avg(u64 now,
struct sched_avg *sa,
int runnable,
-   int running)
+   int running,
+   int cpu)
 {
u64 delta, periods;
u32 runnable_contrib;
int delta_w, decayed = 0;
+#ifdef CONFIG_ARCH_SCALE_INVARIANT_CPU_CAPACITY
+   u32 curr_scale = 1last_runnable_update = now;
 
+#ifdef CONFIG_ARCH_SCALE_INVARIANT_CPU_CAPACITY
+   update_cpu_capacity(cpu);
+   curr_scale = (compute_capacity_of(cpu) << SCHED_ARCH_SCALE_POWER_SHIFT)
+   / (max_compute_capacity_of(cpu)+1);
+#endif
+
/* delta_w is the amount already accumulated against our next period */
delta_w = sa->runnable_avg_period % 1024;
if (delta + delta_w >= 1024) {
@@ -1356,13 +1366,17 @@ static __always_inline int 
__update_entity_runnable_avg(u64 now,
 * period and accrue it.
 */
delta_w = 1024 - delta_w;
+   sa->runnable_avg_period += delta_w;
+   delta -= delta_w;
+   /* scale runnable time if necessary */
+#ifdef CONFIG_ARCH_SCALE_INVARIANT_CPU_CAPACITY
+   delta_w = (delta_w * curr_scale)
+   >> SCHED_ARCH_SCALE_POWER_SHIFT;
+#endif
if (runnable)
sa->runnable_avg_sum += delta_w;
if (running)
sa->usage_avg_sum += delta_w;
-   sa->runnable_avg_period += delta_w;
-
-   delta -= delta_w;
 
/* Figure out how many additional periods this update spans */
periods = delta / 1024;
@@ -1376,19 +1390,31 @@ static __always_inline int 
__update_entity_runnable_avg(u64 now,
 
/* Efficiently calculate \sum (1..n_period) 1024*y^i */
runnable_contrib = __compute_runnable_contrib(periods);
+   sa->runnable_avg_period += runnable_contrib;
+   /* Apply load scaling if necessary.
+* Note that multiplying the whole series is same as
+* multiplying all terms
+*/
+#ifdef CONFIG_ARCH_SCALE_INVARIANT_CPU_CAPACITY
+   runnable_contrib = (runnable_contrib * curr_scale)
+   >> SCHED_ARCH_SCALE_POWER_SHIFT;
+#endif 
if (runnable)
sa->runnable_avg_sum += runnable_contrib;
if (running)
sa->usage_avg_sum += runnable_contrib;
-   sa->runnable_avg_period += runnable_contrib;
}
 
/* Remainder of delta accrued against u_0` */
+   sa->runnable_avg_period += delta;
+   /* scale if necessary */
+#ifdef CONFIG_ARCH_SCALE_INVARIANT_CPU_CAPACITY
+   delta = ((delta * curr_scale) >> SCHED_ARCH_SCALE_POWER_SHIFT);
+#endif
if (runnable)
sa->runnable_avg_sum += delta;
if (running)
sa->usage_avg_sum += delta;
-   sa->runnable_avg_period += delta;
 
return decayed;
 }
@@ -1551,7 +1577,11 @@ static inline void update_entity_load_avg(struct 
sched_entity *se,
struct cfs_rq *cfs_rq = cfs_rq_of(se);
long contrib_delta;
u64 now;
+   int cpu = -1;   /* not used in normal case */
 
+#ifdef CONFIG_ARCH_SCALE_INVARIANT_CPU_CAPACITY
+   cpu = cfs_rq->rq->cpu;
+#endif
/*
 * For a group entity we need to use their owned cfs_rq_clock_task() in
 * case they are the parent of a throttled hierarchy.
@@ -1562,7 +1592,7 @@ static inline void update_entity_load_avg(struct 
sched_entity *se,
now = cfs_rq_clock_task(group_cfs_rq(se));
 
if (!__update_entity_runnable_avg(now, >avg, se->on_rq,
- cfs_rq->curr == se))
+   cfs_rq->curr == se, cpu))
return;
 
contrib_delta = __update_entity_load_avg_contrib(se);
@@ -1607,8 +1637,13 @@ static void update_cfs_rq_blocked_load(struct cfs_rq 

[RFC PATCH 1/3] ARM: (Experimental) Provide Estimated CPU Capacity measure

[Chris Redpath]

Bsed upon the CPU Power of a core, computes a capacity measure
between 0 and 1024 scaling in line with the frequency using a
simple linear scale derived from the maximum frequency reported
by CPUFreq.

Scaling CPU Power with frequency and estimated capacity gives an
estimate of the amount of potential compute capacity available to
a specific core relative to any other in the system.

Change-Id: I8048a23fe5999536b6325a5ec64549dd69f5a865
---
 arch/arm/Kconfig  |   16 +++
 arch/arm/include/asm/topology.h   |7 ++
 arch/arm/kernel/topology.c|  216 -
 drivers/base/topology.c   |   18 
 linaro/configs/big-LITTLE-MP.conf |3 +-
 5 files changed, 258 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 71d5b22..86ea8e8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1624,6 +1624,22 @@ config SCHED_SMT
  MultiThreading at a cost of slightly increased overhead in some
  places. If unsure say N here.

+config ARCH_SCALE_INVARIANT_CPU_CAPACITY
+   bool "Scale-Invariant CPU Compute Capacity Recording (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
+   depends on CPU_FREQ
+   help
+ Provides a new measure of maximum and instantaneous CPU compute
+ capacity, derived from a table of relative compute performance
+ for each core type present in the system. The table is an
+ estimate and specific core performance may be different for
+ any particular workload. The measure includes the relative
+ performance and a linear scale of current to maximum frequency
+ such that at maximum frequency (as expressed in the DTB) the
+ reported compute capacity will be equal to the estimated
+ performance from the table. Values range between 0 and 1023 where
+ 1023 is the highest capacity available in the system.
+
 config HAVE_ARM_SCU
bool
help
diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index 417cf43..3e3c1cd 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -19,6 +19,13 @@ extern struct cputopo_arm cpu_topology[NR_CPUS];
 #define topology_core_id(cpu)  (cpu_topology[cpu].core_id)
 #define topology_core_cpumask(cpu) (_topology[cpu].core_sibling)
 #define topology_thread_cpumask(cpu)   (_topology[cpu].thread_sibling)
+#ifdef CONFIG_ARCH_SCALE_INVARIANT_CPU_CAPACITY
+extern unsigned long arch_get_max_cpu_capacity(int);
+extern unsigned long arch_get_cpu_capacity(int);
+
+#define topology_max_cpu_capacity(cpu) (arch_get_max_cpu_capacity(cpu))
+#define topology_cpu_capacity(cpu) (arch_get_cpu_capacity(cpu))
+#endif

 #define mc_capable()   (cpu_topology[0].socket_id != -1)
 #define smt_capable()  (cpu_topology[0].thread_id != -1)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 354e279..8c4650a 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -40,12 +40,65 @@
  * rebalance_domains for all idle cores and the cpu_power can be updated
  * during this sequence.
  */
+
+/* when CONFIG_ARCH_SCALE_INVARIANT_CPU_CAPACITY is in use, a new measure of
+ * compute capacity is available. This is limited to a maximum of 1024 and
+ * scaled between 0 and 1023 according to frequency.
+ * Cores with different base CPU powers are scaled in line with this.
+ * CPU capacity for each core represents a comparable ratio to maximum
+ * achievable core compute capacity for a core in this system.
+ *
+ * e.g.1 If all cores in the system have a base CPU power of 1024 according to
+ * efficiency calculations and are DVFS scalable between 500MHz and 1GHz, the
+ * cores currently at 1GHz will have CPU power of 1024 whilst the cores
+ * currently at 500MHz will have CPU power of 512.
+ *
+ * e.g.2
+ * If core 0 has a base CPU power of 2048 and runs at 500MHz & 1GHz whilst
+ * core 1 has a base CPU power of 1024 and runs at 100MHz and 200MHz, then
+ * the following possibilities are available:
+ *
+ * cpu power\| 1GHz:100Mhz | 1GHz : 200MHz | 500MHz:100MHz | 500MHz:200MHz |
+ * --|-|---|---|---|
+ *core 0 |1024 | 1024  | 512   | 512   |
+ *core 1 | 256 |  512  | 256   | 512   |
+ *
+ * This information may be useful to the scheduler when load balancing,
+ * so that the compute capacity of the core a task ran on can be baked into
+ * task load histories.
+ */
 static DEFINE_PER_CPU(unsigned long, cpu_scale);
+static DEFINE_PER_CPU(unsigned long, base_cpu_capacity);
+static DEFINE_PER_CPU(unsigned long, invariant_cpu_capacity);
+static DEFINE_PER_CPU(unsigned long, prescaled_cpu_capacity);
+
+static int frequency_invariant_power_enabled = 1;
+
+/* >0=1, <=0=0 */
+void set_invariant_power_enabled(int val)
+{
+   if(val>0)
+   

[RFC PATCH 2/3] sched: introduce compute capacity for CPUs, groups and domains

[Chris Redpath]

Using the per-cpu compute capacity exported from topology
when CONFIG_ARCH_SCALE_INVARIANT_CPU_CAPACITY is active, place this
information alongside cpu_power in the scheduler and combine for the
various aggregating entities.

Change-Id: I4984c335bcdc128680e7459b3f86bb05e04593cc
---
 include/linux/sched.h|7 +
 include/trace/events/sched.h |   24 +++
 kernel/sched/core.c  |2 ++
 kernel/sched/debug.c |3 ++
 kernel/sched/fair.c  |   69 ++
 kernel/sched/sched.h |4 +++
 6 files changed, 103 insertions(+), 6 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 7c64f30..f2ee59a 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -863,6 +863,13 @@ struct sched_group_power {
unsigned int power, power_orig;
unsigned long next_update;
/*
+* Compute capacity of this group, where each CPU has a compute
+* capacity expressed as a value [0..SCHED_POWER_SCALE] against
+* the most powerful CPU in the system of capacity SCHED_POWER_SCALE.
+*/
+   unsigned int compute_capacity;
+   unsigned int max_compute_capacity;
+   /*
 * Number of busy cpus in this group.
 */
atomic_t nr_busy_cpus;
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 8932919..45e27bc 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -985,6 +985,30 @@ TRACE_EVENT(sched_fsi,
 );
 
 /*
+ * Extra debug trace points
+ */
+TRACE_EVENT(sched_upd_cap,
+
+   TP_PROTO(int dst_cpu, unsigned long curr, unsigned long max ),
+
+   TP_ARGS(dst_cpu, curr, max ),
+
+   TP_STRUCT__entry(
+   __field(int,  dst_cpu)
+   __field(unsigned long,  curr)
+   __field(unsigned long,  max)
+   ),
+
+   TP_fast_assign(
+   __entry->dst_cpu = dst_cpu;
+   __entry->curr = curr;
+   __entry->max = max;
+   ),
+
+   TP_printk("cpu=%d curr=%lu max=%lu",
+   __entry->dst_cpu, __entry->curr, __entry->max)
+);
+/*
  * Tracepoint for showing priority inheritance modifying a tasks
  * priority.
  */
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ec7406d..e535222 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6940,6 +6940,8 @@ void __init sched_init(void)
rq->sd = NULL;
rq->rd = NULL;
rq->cpu_power = SCHED_POWER_SCALE;
+   rq->curr_compute_capacity = SCHED_POWER_SCALE;
+   rq->max_compute_capacity = SCHED_POWER_SCALE;
rq->post_schedule = 0;
rq->active_balance = 0;
rq->next_balance = jiffies;
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index b9d54d0..9102bb4 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -290,6 +290,9 @@ do {
\
 #define PN(x) \
SEQ_printf(m, "  .%-30s: %Ld.%06ld\n", #x, SPLIT_NS(rq->x))
 
+   P(cpu_power);
+   P(curr_compute_capacity);
+   P(max_compute_capacity);
P(nr_running);
SEQ_printf(m, "  .%-30s: %lu\n", "load",
   rq->load.weight);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d9af9c1..f6bbe1e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1267,6 +1267,27 @@ static u32 __compute_runnable_contrib(u64 n)
return contrib + runnable_avg_yN_sum[n];
 }
 
+#ifdef CONFIG_ARCH_SCALE_INVARIANT_CPU_CAPACITY
+#define SCHED_ARCH_SCALE_POWER_SHIFT 10
+#endif
+static inline unsigned long compute_capacity_of(int cpu)
+{
+   return cpu_rq(cpu)->curr_compute_capacity;
+}
+
+static inline unsigned long max_compute_capacity_of(int cpu)
+{
+   return cpu_rq(cpu)->max_compute_capacity;
+}
+
+static inline void update_cpu_capacity(int cpu)
+{
+   int tmp_capacity = arch_get_cpu_capacity(cpu);
+   int tmp_max_capacity = arch_get_max_cpu_capacity(cpu);
+   trace_sched_upd_cap(cpu, tmp_capacity, tmp_max_capacity);
+   cpu_rq(cpu)->max_compute_capacity = tmp_max_capacity;
+   cpu_rq(cpu)->curr_compute_capacity = tmp_capacity;
+}
 /*
  * We can represent the historical contribution to runnable average as the
  * coefficients of a geometric series.  To do this we sub-divide our runnable
@@ -4360,6 +4381,8 @@ struct sd_lb_stats {
unsigned long total_load;  /* Total load of all groups in sd */
unsigned long total_pwr;   /*   Total power of all groups in sd */
unsigned long avg_load;/* Average load across all groups in sd */
+   unsigned long total_cap;   /* Total current compute capacity of all 
groups in sd */
+   unsigned long total_maxcap; /* Total max compute capacity of all groups 
in sd */
 
/** Statistics of this group */
unsigned long this_load;
@@ -4388,7 +4411,9 

[RFC PATCH 0/3] Per-Task Load Tracking in the presence of DVFS

[Chris Redpath]

Firstly, I realise this is rather a long cover letter but a lot of it is
the ascii graphs. My apologies. For skim readers the tl;dr version is:

The presence of CPUfreq in a system with more than one CPU frequency
domain causes the tracked load of tasks to be high when the CPU
frequency is low. When you use these stats to optimise task placement,
this can cause you to move tasks early. If you only have one frequency
domain, there are no side effects.

The long version:
While experimenting with big.LITTLE MP scheduling (e.g.
http://lwn.net/Articles/539089/) using the per-task load tracking
introduced in the recent patch set, we saw a situation where the load of
periodic tasks (like audio playback) would be higher when CPUfreq was
running the CPU at a low frequency.

Although this is an obvious result of the increased time required to
perform a constant amount of processing when the frequency of a CPU is
lowered, it was not without impact on our ability to use the load
statistic for balancing. 

While our problem is pretty specific to how we are using the load stats,
I think we are reasonably representative of the kinds of things that
people will want to use load tracking for. The interaction of DVFS and
reported load stats are therefore something I believe we ought to
discuss on the list.

I will not call the load profile incorrect since it is accurately
reflecting the historical compute consumption of the task. Where this
can become misleading is if we then wish to use the tracked load
statistic for load balancing between domains where there are different
compute capacities available either through microarchitectural means
(big.LITTLE) or separate frequencies (e.g. Qualcomm Krait systems). It
may also be an issue (as far as I can see) in any multi-socket system.

The issue is easiest to see using a busy loop driven by a periodic alarm
signal running on a CPU whose frequency is controlled by the ondemand
cpufreq governor. Although it's an artificial workload the issue is seen
in real traces, but the task is simpler to understand. The sample task
code is at the end of this mail. I use an ARM CoreTile Express 
V2P-CA15_A7, which has 2xA15 and 3xA7 CPUs. The test is run pinned to
one CPU.

For my A7 core running at 1GHz, running the alarm signal at 1024us
intervals with a busy loop count of 35500 generates a reasonably stable
50% load. Here I have used the performance governor and traced the task
contribution when the calculation is updated.

static inline void __update_task_entity_contrib(struct sched_entity *se)
{
  u32 contrib;

  /* avoid overflowing a 32-bit type w/ SCHED_LOAD_SCALE */
  contrib = se->avg.runnable_avg_sum * scale_load_down(se->load.weight);
  contrib /= (se->avg.runnable_avg_period + 1);
  se->avg.load_avg_contrib = scale_load(contrib);
  trace_sched_task_load_avg_contrib(task_of(se), scale_load(contrib),

se->load.weight);
}

This produces the following load contribution (gnuplotted on dumb term
from ftrace data). The lack of time accounted to the period in early
task life is visible here but the load stabilises around 50% which the
busy loop count was calibrated for.


   +-++-+-+-+-+
   + + A  + + "contrib_filtered.csv"   A  +
1k ++++
   |   A  |
   |   A  |
800++  A ++
   |   A  |
   |   A  |
   |   A  |
600++  AA++
   |A |
   |   A  |
400++++
   |  |
   |  |
   |  |
200++++
   |  |
   + ++ + + + +
 0 ++++-+-+-+-+
  3043  3044 3045  3046  3047  3048 3049

Repeating the exercise using ondemand shows how the changing frequency
causes the task to be more busy, reflecting that the CPU is busy for
more time to do the same amount of work. The result is what you'd expect.

   +--+---+--+--+---+
   +A +  + "contrib.csv"   A+
1k++AA  A  ++
   |A   A 

Re: [PATCH] MAINTAINERS: Update Grant's email address and maintainership

[Joe Perches]

On Tue, 2013-04-16 at 11:43 +0100, grant.lik...@linaro.org wrote:
> From: Grant Likely 
> It has also been many years
> since I've touched any of the Xilinx related code so mark those items as
> unmaintained.

Hi Grant.

Please use "Orphan" as described in MAINTAINERS instead.
get_maintainers.pl doesn't understand "Unmaintained".

> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -4806,11 +4806,8 @@ F: arch/powerpc/platforms/40x/
[]
>  LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
> -M:   Grant Likely 
> -W:   http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
>  L:   linuxppc-...@lists.ozlabs.org
> -T:   git git://git.secretlab.ca/git/linux-2.6.git
> -S:   Maintained
> +S:   Unmaintained
[]
> @@ -8942,9 +8938,7 @@ S:  Maintained
[]
>  XILINX SYSTEMACE DRIVER
> -M:   Grant Likely 
> -W:   http://www.secretlab.ca/
> -S:   Maintained
> +S:   Unmaintained


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [NEW DRIVER V4 3/7] DA9058 ONKEY driver

[Randy Dunlap]

On 04/16/13 03:33, Opensource [Anthony Olech] wrote:
>> -Original Message-
>> From: Randy Dunlap [mailto:rdun...@infradead.org]
>> Sent: 12 April 2013 21:02
>> To: Opensource [Anthony Olech]
>> Cc: Dmitry Torokhov; Mark Brown; Samuel Ortiz; Ashish Jangam; Eric
>> Andersson; Andrew Jones; linux-in...@vger.kernel.org; LKML; David Dajun Chen
>> Subject: Re: [NEW DRIVER V4 3/7] DA9058 ONKEY driver
>>
>> On 04/12/13 06:05, Anthony Olech wrote:
>>> This is the ONKEY component driver of the Dialog DA9058 PMIC.
>>> This driver is just one component of the whole DA9058 PMIC driver.
>>> It depends on the CORE component driver of the DA9058 MFD.
>>>
>>> Signed-off-by: Anthony Olech 
>>> Signed-off-by: David Dajun Chen 
>>> ---
>>>  drivers/input/misc/Kconfig|   10 +++
>>>  drivers/input/misc/Makefile   |1 +
>>>  drivers/input/misc/da9058_onkey.c |  177
>>> +
>>>  3 files changed, 188 insertions(+)
>>>  create mode 100644 drivers/input/misc/da9058_onkey.c
>>>
>>> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
>>> index 259ef31..bd07b38 100644
>>> --- a/drivers/input/misc/Kconfig
>>> +++ b/drivers/input/misc/Kconfig
>>> @@ -93,6 +93,16 @@ config INPUT_BMA150
>>>   To compile this driver as a module, choose M here: the
>>>   module will be called bma150.
>>>
>>> +config INPUT_DA9058_ONKEY
>>> +   tristate "DA9058 ONKEY support"
>>> +   depends on MFD_DA9058
>>> +   help
>>> + Support the ONKEY of DA9058 PMICs as an input device
>>> + reporting power button status.
>>
>> What possible values can a power button status have?
>> Must be more than my KISS guess:
>>  this software is running => ON
>>  software not running => OFF
>> eh?
> 
> Pressing the button briefly and pressing and holding the button will have
> different effects in a mobile device. The press and hold on phones normally
> switches them into a sleep state. So the "power button status" is the fact
> that the ONKEY is still being held down.
> 
> Does that answer your question? or have I missed your point??

Yes, that answers my question.  I get it.

> 
> [...]
>>> +   onkey->irq = platform_get_irq(pdev, 0);
>>> +   if (onkey->irq < 0) {
>>> +   dev_err(>dev, "can not get ONKEY IRQ error=%d\n",
>>
>>   cannot
> 
> The Washington State University language site says:
> 
> "These two spellings [cannot/can not] are largely interchangeable, but by far
> the most common is 'cannot' and you should probably use it except when you
> want to be emphatic: 'No, you can not wash the dog in the Maytag.'"
> 
> Since I was not trying to be particularly emphatic, I will change to using 
> 'cannot'
> as per your suggestion.

thanks.


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] ARM: mmp: add wakeup function for ICU

[Haojian Zhuang]

>> > From: Haojian Zhuang [mailto:haojian.zhu...@gmail.com]
>> > Sent: 2013年4月13日 20:50
>> > To: Neil Zhang
>> > Cc: Grant Likely; linux-arm-ker...@lists.infradead.org;
>> > linux-kernel@vger.kernel.org; Chao Xie
>> > Subject: Re: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
>> >
>> > On Thu, Apr 11, 2013 at 11:37 AM, Neil Zhang 
>> > wrote:
>> > > From: Chao Xie 
>> > >
>> > > PXA988 will use GIC as its interrupt controller, and ICU is used as
>> > > wakeup logic. When AP subsystem is powered off, GIC will lose its
>> > > context, the PMU will need ICU to wakeup the AP subsystem.
>> > > When ICU works as wakeup logic, there is no need to know
>> > > intc-nr-irqs, change the corresponding code.
>> > >
>> > > Signed-off-by: Chao Xie 
>> > > Signed-off-by: Neil Zhang 
>> > > ---
>> >
>> > Since it's totally different from original ICU irq initialization, I
>> > suggest to create a new entry to handle this kind of wakeup event. And
>> > we could create a new mask/unmask function.
>>
>> Ok, I'll update it.
> Are you OK if use icu_mask_irq_wakeup / icu_unmask_irq_wakeup for the new 
> functions.

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

Re: [Bug fix PATCH v2] Reusing a resource structure allocated by bootmem

[Toshi Kani]

On Tue, 2013-04-16 at 10:10 +0900, Yasuaki Ishimatsu wrote:
> When hot removing memory presented at boot time, following messages are shown:

 :

> The reason why the messages are shown is to release a resource structure,
> allocated by bootmem, by kfree(). So when we release a resource structure,
> we should check whether it is allocated by bootmem or not.
> 
> But even if we know a resource structure is allocated by bootmem, we cannot
> release it since SLxB cannot treat it. So for reusing a resource structure,
> this patch remembers it by using bootmem_resource as follows:
> 
> When releasing a resource structure by free_resource(), free_resource() checks
> whether the resource structure is allocated by bootmem or not. If it is
> allocated by bootmem, free_resource() adds it to bootmem_resource. If it is
> not allocated by bootmem, free_resource() release it by kfree().
> 
> And when getting a new resource structure by get_resource(), get_resource()
> checks whether bootmem_resource has released resource structures or not. If
> there is a released resource structure, get_resource() returns it. If there is
> not a releaed resource structure, get_resource() returns new resource 
> structure
> allocated by kzalloc().
> 
> Signed-off-by: Yasuaki Ishimatsu 
> ---
> v2:
> Based on following Toshi's works:
>   Support memory hot-delete to boot memory
> https://lkml.org/lkml/2013/4/10/469
>   resource: Update config option of release_mem_region_adjustable()
> https://lkml.org/lkml/2013/4/11/694
> Added a NULL check into free_resource()
> Remove __free_resource()

Thanks for the update.  Looks good.  Can you also address Rui's comment?

-Toshi


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

Re: [PATCHv3, RFC 09/34] thp: represent file thp pages in meminfo and friends

[Dave Hansen]

On 04/16/2013 07:49 AM, Kirill A. Shutemov wrote:
> Dave Hansen wrote:
>> On 04/05/2013 04:59 AM, Kirill A. Shutemov wrote:
>>> The patch adds new zone stat to count file transparent huge pages and
>>> adjust related places.
>>>
>>> For now we don't count mapped or dirty file thp pages separately.
>>
>> I can understand tracking NR_FILE_TRANSPARENT_HUGEPAGES itself.  But,
>> why not also account for them in NR_FILE_PAGES?  That way, you don't
>> have to special-case each of the cases below:
> 
> Good point.
> To be consistent I'll also convert NR_ANON_TRANSPARENT_HUGEPAGES to be
> accounted in NR_ANON_PAGES.

Hmm...  I didn't realize we did that for the anonymous version.  But,
looking at the meminfo code:

> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> K(global_page_state(NR_ANON_PAGES)
>   + global_page_state(NR_ANON_TRANSPARENT_HUGEPAGES) *
>   HPAGE_PMD_NR),
> #else
> K(global_page_state(NR_ANON_PAGES)),
> #endif

That #ifdef and a couple others like it would just go away if we did
this.  It would be a nice cleanup.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch -v3 3/4] checkpatch.pl the new kernel/reboot.c file.

[Joe Perches]

(trimmed cc's)

On Tue, 2013-04-16 at 04:41 -0500, Robin Holt wrote:
> On Mon, Apr 15, 2013 at 10:45:38AM -0700, Joe Perches wrote:
> > trivia:
> > I'd make these changes on top of your patch:
> > o Additional OOM messages aren't necessary as a dump_stack is done
> I am not sure what I should be doing with this one.

It could be removed eventually.

> The only message
> that seems close is the pr_warn("%s failed to allocate memory for...
> but I don't see how dump_stack is getting invoked so I think either
> you did not mean this message or you intended me to replace that with a
> dump_stack, in which case, the error message would still be informative
> and the dump_stack would be relatively useless.

All failed mallocs without __GFP_NOWARN get a dump_stack via
mm/page_alloc:warn_alloc_failed() so that pr_warn isn't really
required.

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

Re: [PATCH v7 0/3] of/pci: Provide common support for PCI DT parsing

[Jason Cooper]

On Tue, Apr 16, 2013 at 11:18:25AM +0100, Andrew Murray wrote:
> This patchset factors out duplicated code associated with parsing PCI
> DT "ranges" properties across the architectures and introduces a
> "ranges" parser. This parser "of_pci_range_parser" can be used directly
> by ARM host bridge drivers enabling them to obtain ranges from device
> trees.
> 
> I've included the Reviewed-by and Tested-by's received from v5/v6 in this
> patchset, earlier versions of this patchset (v3) have been tested-by:
> 
> Thierry Reding 
> Jingoo Han 
> 
> I've tested that this patchset builds and runs on ARM and that it builds on
> PowerPC and x86_64.

Series replaces v6 in mvebu/drivers

thx,

Jason.

> 
> Compared to the v6 sent by Andrew Murray, the following changes have
> been made in response to build errors/warnings:
> 
>  * Inclusion of linux/of_address.h in of_pci.c as suggested by Michal
>Simek to prevent compilation failures on Microblaze (and others) and his
>ack.
> 
>  * Use of externs, static inlines and a typo in linux/of_address.h in response
>to linker errors (multiple defination) on x86_64 as spotted by a kbuild 
> test
>robot on (jcooper/linux.git mvebu/drivers)
> 
>  * Add EXPORT_SYMBOL_GPL to of_pci_range_parser function to be consistent
>with of_pci_process_ranges function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/5] dump_stack: unify debug information printed by show_regs()

[James Hogan]

On 30/03/13 03:24, Tejun Heo wrote:
> show_regs() is inherently arch-dependent but it does make sense to
> print generic debug information and some archs already do albeit in
> slightly different forms.  This patch introduces a generic function to
> print debug information from show_regs() so that different archs print
> out the same information and it's much easier to modify what's
> printed.
> 
> show_regs_print_current() prints out the same debug info as
> dump_stack() does plus CPU, task and thread_info pointers.
> 
> * Archs which didn't print debug info now do.
> 
>   alpha, arc, blackfin, c6x, cris, frv, h8300, hexagon, ia64, m32r,
>   metag, microblaze, mn10300, openrisc, parisc, score, sh64, sparc,
>   um, xtensa
> 
> * Already prints debug info.  Replaced with show_regs_print_current().
>   The printed information is superset of what used to be there.
> 
>   arm, arm64, avr32, mips, powerpc, sh32, tile, unicore32, x86
> 
> * The printed debug information includes arch-specific bits.  Left
>   alone.
> 
>   s390
> 
> Note that now all archs print the debug info before actual register
> dumps.
> 
> An example BUG() dump follows.
> 
>  kernel BUG at /work/os/work/kernel/workqueue.c:4841!
>  invalid opcode:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
>  Modules linked in:
>  Pid: 1, comm: swapper/0 Tainted: GW3.9.0-rc1-work+ #20 empty 
> empty/S3992
>  CPU:0 task: 88007c85e040 ti: 88007c86 task.ti: 88007c86
>  RIP: 0010:[]  [] 
> init_workqueues+0x15/0x17
>  RSP: :88007c861ec8  EFLAGS: 00010296
>  RAX: 0024 RBX: 82446608 RCX: 0001
>  RDX: 0046 RSI:  RDI: 0009
>  RBP: 88007c861ec8 R08:  R09: 
>  R10: 0001 R11:  R12: 8234a02d
>  R13:  R14:  R15: 
>  FS:  () GS:88007dc0() knlGS:
>  CS:  0010 DS:  ES:  CR0: 8005003b
>  CR2: 88015f7ff000 CR3: 021f1000 CR4: 07f0
>  DR0:  DR1:  DR2: 
>  DR3:  DR6: 0ff0 DR7: 0400
>  Stack:
>   88007c861ef8 81000312 82446608 88007c85e650
>   0003  88007c861f38 82335e5d
>   88007c862080 8223d8c0 88007c862080 81c47730
>  Call Trace:
>   [] do_one_initcall+0x122/0x170
>   [] kernel_init_freeable+0x9b/0x1c8
>   ...
> 
> v2: Typo fix in x86-32.
> 
> Signed-off-by: Tejun Heo 

For metag:
Acked-by: James Hogan 

Cheers
James

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

Re: [RFC PATCH v1 00/19] kill free_all_bootmem() and clean up VALID_PAGE()

[Jiang Liu]

On 04/15/2013 12:56 PM, Paul Mackerras wrote:
> On Sat, Apr 13, 2013 at 11:36:20PM +0800, Jiang Liu wrote:
>> Commit 600cc5b7f6 "mm: Kill NO_BOOTMEM version free_all_bootmem_node()"
>> has kill free_all_bootmem_node() for NO_BOOTMEM.
>>
>> Currently the usage pattern for free_all_bootmem_node() is like:
>> for_each_online_pgdat(pgdat)
>>  free_all_bootmem_node(pgdat);
>>
>> It's equivalent to free_all_bootmem(), so this patchset goes one
>> step further to kill free_all_bootmem_node() for BOOTMEM too.
>>
>> This patchset also tries to clean up code and comments related to
>> VALID_PAGE() because it has been removed from kernel long time ago.
>>
>> Patch 1-11:
>>  Kill free_all_bootmem_node()
>> Patch 12-16:
>>  Clean up code and comments related to VALID_PAGE()
>> Patch 17:
>>  Fix a minor build warning for m68k
>> Patch 18:
>>  merge Alpha's mem_init() for UMA and NUMA.
>> Patch 19:
>>  call register_page_bootmem_info_node() from mm core
> 
> How does this not break bisection?  Will a kernel still boot with
> patches 1-11 applied but not patch 19?  As far as I can see such a
> kernel would have no memory available to it after mem_init() time
> and would therefore crash early in boot.
Hi Paul,
Thanks for review!
Patch 1-11 replace free_all_bootmem_node() with free_all_bootmem(),
so all normal pages will be freed into the buddy system as before. And
patch 1-11 are independent with patch 19.
Gerry
> 
> Paul.
> 

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

[PATCH v7] i2c-designware: make SDA hold time configurable

[Christian Ruppert]

Looks like this was eaten by the spam filter last time so i'm resending
it to the lists only:
This patch makes the SDA hold time configurable through device tree.

Signed-off-by: Christian Ruppert 
Signed-off-by: Pierrick Hascoet 
---
 .../devicetree/bindings/i2c/i2c-designware.txt |   14 ++
 drivers/i2c/busses/i2c-designware-core.c   |5 +
 drivers/i2c/busses/i2c-designware-core.h   |1 +
 drivers/i2c/busses/i2c-designware-platdrv.c|9 +
 4 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt 
b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
index e42a2ee..21fabe7 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
@@ -10,6 +10,9 @@ Recommended properties :
 
  - clock-frequency : desired I2C bus clock frequency in Hz.
 
+Optional properties :
+ - sda-hold-time : should contain the SDA hold time in nanoseconds.
+
 Example :
 
i2c@f {
@@ -20,3 +23,14 @@ Example :
interrupts = <11>;
clock-frequency = <40>;
};
+
+   i2c@112 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "snps,designware-i2c";
+   reg = <0x112 0x1000>;
+   interrupt-parent = <>;
+   interrupts = <12 1>;
+   clock-frequency = <40>;
+   sda-hold-time = <300>;
+   };
diff --git a/drivers/i2c/busses/i2c-designware-core.c 
b/drivers/i2c/busses/i2c-designware-core.c
index 94fd818..ba40e14 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -67,6 +67,7 @@
 #define DW_IC_STATUS   0x70
 #define DW_IC_TXFLR0x74
 #define DW_IC_RXFLR0x78
+#define DW_IC_SDA_HOLD 0x7c
 #define DW_IC_TX_ABRT_SOURCE   0x80
 #define DW_IC_COMP_PARAM_1 0xf4
 #define DW_IC_COMP_TYPE0xfc
@@ -310,6 +311,10 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
dw_writel(dev, lcnt, DW_IC_FS_SCL_LCNT);
dev_dbg(dev->dev, "Fast-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);
 
+   /* Configure SDA Hold Time if required */
+   if (dev->sda_hold_time)
+   dw_writel(dev, dev->sda_hold_time, DW_IC_SDA_HOLD);
+
/* Configure Tx/Rx FIFO threshold levels */
dw_writel(dev, dev->tx_fifo_depth - 1, DW_IC_TX_TL);
dw_writel(dev, 0, DW_IC_RX_TL);
diff --git a/drivers/i2c/busses/i2c-designware-core.h 
b/drivers/i2c/busses/i2c-designware-core.h
index 9c1840e..33dfec3 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -88,6 +88,7 @@ struct dw_i2c_dev {
u32 master_cfg;
unsigned inttx_fifo_depth;
unsigned intrx_fifo_depth;
+   u32 sda_hold_time;
 };
 
 #define ACCESS_SWAP0x0001
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 0ceb6e1..0a6e29b 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -136,6 +137,14 @@ static int dw_i2c_probe(struct platform_device *pdev)
}
clk_prepare_enable(dev->clk);
 
+   if (pdev->dev.of_node) {
+   u32 ht;
+   u32 ic_clk = dev->get_clk_rate_khz(dev);
+
+   of_property_read_u32(pdev->dev.of_node, "sda-hold-time", );
+   dev->sda_hold_time = ((u64)ic_clk * ht + 50) / 100;
+   }
+
dev->functionality =
I2C_FUNC_I2C |
I2C_FUNC_10BIT_ADDR |
-- 
1.7.1

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

Re: No serial since kernel 3.8

[Josh Boyer]

On Tue, Apr 16, 2013 at 04:55:25PM +0200, richard -rw- weinberger wrote:
>On Tue, Apr 16, 2013 at 4:20 PM, Stephan von Krawczynski
> wrote:
>> Hello,
>>
>> can some kind soul please explain how I can get my serial port back under
>> kernel 3.8.X. Earlier kernels showed:
>>
>> Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O 0x3f8
>> (irq = 4) is a 16550A
>>
>> But 3.8.4:
>>
>> Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled
>>
>> Only kernel is replaced, no change in distro
>> Is there some kernel boot parameter needed now?
>> I tried 3.4.X and it works, even 3.7.X works...
>
>So, 3.8.3 worked and 3.8.4 introduced a regression?
>If so please confirm.
>
>CC'ing gregkh, just in case...

We had a report of this in Fedora that was fixed with 3.8.7.  An upstream
change had been brought back to the 3.8.x series, and it was subsequently
reverted.  3.8.7 picked up the revert.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] dump_stack: consolidate dump_stack() implementations and unify their behaviors

[James Hogan]

On 30/03/13 02:27, Tejun Heo wrote:
> Both dump_stack() and show_stack() are currently implemented by each
> architecture.  show_stack(NULL, NULL) dumps the backtrace for the
> current task as does dump_stack().  On some archs, dump_stack() prints
> extra information - pid, utsname and so on - in addition to the
> backtrace while the two are identical on other archs.
> 
> The usages in arch-independent code of the two functions indicate
> show_stack(NULL, NULL) should print out bare backtrace while
> dump_stack() is used for debugging purposes when something went wrong,
> so it does make sense to print additional information on the task
> which triggered dump_stack().
> 
> There's no reason to require archs to implement two separate but
> mostly identical functions.  It leads to unnecessary subtle
> differences among archs and makes it very tedius to add generic debug
> information.
> 
> This patch expands the dummy fallback dump_stack() implementation in
> lib/dump_stack.c such that it prints out debug information (taken from
> x86) and invokes show_stack(NULL, NULL) and drops arch-specific
> dump_stack() implementations in all archs except blackfin and s390.
> Blackfin's dump_stack() does something wonky that I don't understand
> and s390 prints its own debug information which includes fields which
> aren't accessible from arch-indepdent code.
> 
> Debug information can be printed separately by calling
> dump_stack_print_info() so that arch-specific dump_stack()
> implementation can still emit the same debug information.  This is
> used in blackfin.
> 
> This patch brings the following behavior changes.
> 
> * On some archs, an extra level in backtrace for show_stack() could be
>   printed.  This is because the top frame was determined in
>   dump_stack() on those archs while generic dump_stack() can't do that
>   reliably.  It can be compensated by inlining dump_stack() but not
>   sure whether that'd be necessary.
> 
> * Most archs didn't use to print debug info on dump_stack().  They do
>   now.
> 
> An example WARN dump follows.
> 
>  WARNING: at /work/os/work/kernel/workqueue.c:4840 
> init_workqueues+0x35/0x505()
>  Hardware name: empty
>  Modules linked in:
>  Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1-work+ #17
>   0009 88007c861e08 81c61545 88007c861e48
>   8108f50f 82228240 0040 8234a03c
>      88007c861e58
>  Call Trace:
>   [] dump_stack+0x19/0x1b
>   [] warn_slowpath_common+0x7f/0xc0
>   [] warn_slowpath_null+0x1a/0x20
>   [] init_workqueues+0x35/0x505
>   ...
> 
> Signed-off-by: Tejun Heo 
> Cc: Martin Schwidefsky 
> Cc: Heiko Carstens 
> Cc: linux-s...@vger.kernel.org
> Cc: Mike Frysinger 
> Cc: uclinux-dist-de...@blackfin.uclinux.org

For metag:
Acked-by: James Hogan 

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

Re: [PATCH] mmc: dw_mmc: exynos: Turn SDIO interrupts on

[Doug Anderson]

Seungwon,

On Tue, Apr 16, 2013 at 2:30 AM, Seungwon Jeon  wrote:
> If needed for specific channel, it can be got from dts as property.
> if (of_find_property(np, "cap-sdio-irq", NULL))
> pdata->caps |= MMC_CAP_SDIO_IRQ;

Oh!  I missed that these new properties had gone in.  That is a much
better way to do it.  Let's abandon this patch and I'll post up a
device tree change that turns interrupts for the right ports on the
exynos5250-snow and we can call it done.

Thanks for the review and for pointing me to the new properties!

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

Re: No serial since kernel 3.8

[richard -rw- weinberger]

On Tue, Apr 16, 2013 at 4:20 PM, Stephan von Krawczynski
 wrote:
> Hello,
>
> can some kind soul please explain how I can get my serial port back under
> kernel 3.8.X. Earlier kernels showed:
>
> Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O 0x3f8
> (irq = 4) is a 16550A
>
> But 3.8.4:
>
> Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled
>
> Only kernel is replaced, no change in distro
> Is there some kernel boot parameter needed now?
> I tried 3.4.X and it works, even 3.7.X works...

So, 3.8.3 worked and 3.8.4 introduced a regression?
If so please confirm.

CC'ing gregkh, just in case...

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

Re: [PATCHv3, RFC 09/34] thp: represent file thp pages in meminfo and friends

[Kirill A. Shutemov]

Dave Hansen wrote:
> On 04/05/2013 04:59 AM, Kirill A. Shutemov wrote:
> > The patch adds new zone stat to count file transparent huge pages and
> > adjust related places.
> > 
> > For now we don't count mapped or dirty file thp pages separately.
> 
> I can understand tracking NR_FILE_TRANSPARENT_HUGEPAGES itself.  But,
> why not also account for them in NR_FILE_PAGES?  That way, you don't
> have to special-case each of the cases below:

Good point.
To be consistent I'll also convert NR_ANON_TRANSPARENT_HUGEPAGES to be
accounted in NR_ANON_PAGES.

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

[PATCH v2] regulator: ab8500: Fix set voltage for AB8540_LDO_AUX3

[Axel Lin]

When setting voltage for AB8540_LDO_AUX3, current code only updates one of
info->voltage_reg and info->expand_register registers which is wrong.
To ensure we set to correct voltage, it always needs to clear or set
expand_register.voltage_mask bit of expand_register.

The function of the expand register bit is the following (from the user manual):
0: VAUX3 output voltage is determined by Vaux3Sel bit settings in register
   VldoCVaux3Sel
1: VAUX3 output voltage is set to 3.05V regardless of Vaux3Sel settings in
   register VldoCVaux3Sel (VldoCVaux3Sel is the register at 0x0421)

So when going to 3.05V, set the expand register bit.
When leaving 3.05V for another voltage, set the target voltage before clearing
the expand register bit.

Signed-off-by: Axel Lin 
---
 drivers/regulator/ab8500.c |   69 
 1 file changed, 51 insertions(+), 18 deletions(-)

diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 0a62ef9..84e064b 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -612,32 +612,65 @@ static int ab8540_aux3_regulator_set_voltage_sel(struct 
regulator_dev *rdev,
return -EINVAL;
}
 
+   /* Set the expand register bit for 3.05V.
+  Once expand register bit is set, VAUX3 output voltage is set to 3.05V
+  regardless of Vaux3Sel settings in register VldoCVaux3Sel.
+*/
if (selector >= info->expand_register.voltage_limit) {
-   /* Vaux3 bit4 has different layout */
-   regval = (u8)selector << info->expand_register.voltage_shift;
-   ret = abx500_mask_and_set_register_interruptible(info->dev,
-   info->expand_register.voltage_bank,
-   info->expand_register.voltage_reg,
-   info->expand_register.voltage_mask,
-   regval);
-   } else {
-   /* set the registers for the request */
-   regval = (u8)selector << info->voltage_shift;
ret = abx500_mask_and_set_register_interruptible(info->dev,
-   info->voltage_bank, info->voltage_reg,
-   info->voltage_mask, regval);
+   info->expand_register.voltage_bank,
+   info->expand_register.voltage_reg,
+   info->expand_register.voltage_mask,
+   info->expand_register.voltage_mask);
+   if (ret < 0) {
+   dev_err(rdev_get_dev(rdev),
+   "couldn't set expand voltage reg for 
regulator\n");
+   return ret;
+   }
+
+   dev_vdbg(rdev_get_dev(rdev),
+"%s-set_voltage expand (bank, reg, mask, value): 0x%x, 
0x%x, 0x%x, 0x%x\n",
+info->desc.name, info->expand_register.voltage_bank,
+info->expand_register.voltage_reg,
+info->expand_register.voltage_mask,
+info->expand_register.voltage_mask);
+
+   return 0;
}
-   if (ret < 0)
+
+   /* Set target voltage before clearing the expand register bit */
+   regval = (u8)selector << info->voltage_shift;
+   ret = abx500_mask_and_set_register_interruptible(info->dev,
+   info->voltage_bank, info->voltage_reg,
+   info->voltage_mask, regval);
+   if (ret < 0) {
dev_err(rdev_get_dev(rdev),
"couldn't set voltage reg for regulator\n");
+   return ret;
+   }
 
dev_vdbg(rdev_get_dev(rdev),
-   "%s-set_voltage (bank, reg, mask, value): 0x%x, 0x%x, 
0x%x,"
-   " 0x%x\n",
-   info->desc.name, info->voltage_bank, info->voltage_reg,
-   info->voltage_mask, regval);
+"%s-set_voltage (bank, reg, mask, value): 0x%x, 0x%x, 0x%x, 
0x%x\n",
+info->desc.name, info->voltage_bank, info->voltage_reg,
+info->voltage_mask, regval);
 
-   return ret;
+   ret = abx500_mask_and_set_register_interruptible(info->dev,
+   info->expand_register.voltage_bank,
+   info->expand_register.voltage_reg,
+   info->expand_register.voltage_mask, 0);
+   if (ret < 0) {
+   dev_err(rdev_get_dev(rdev),
+   "couldn't clear expand voltage reg for regulator\n");
+   return ret;
+   }
+
+   dev_vdbg(rdev_get_dev(rdev),
+"%s-set_voltage expand (bank, reg, mask, value): 0x%x, 0x%x, 
0x%x, 0x%x\n",
+info->desc.name, info->expand_register.voltage_bank,
+info->expand_register.voltage_reg,
+

Re: [PATCH 1/6] signal x86: Propage RF EFLAGS bit throught the signal restore call

[Oleg Nesterov]

On 04/16, Frederic Weisbecker wrote:
>
> On Sun, Mar 10, 2013 at 07:41:06PM +0100, Jiri Olsa wrote:
> > Adding RF EFLAGS bit to be restored on return from signal from
> > the original register context before the signal was entered.
> >
> > This will prevent the RF flag to disappear when returning
> > from exception due to the signal handler being executed.
>
> So that happens if, say, we get a breakpoint exception and then we
> run a signal handler before returning to the ip that triggered the
> breakpoint?

Afaics these changes (1 and 2) should fix the bug.

Suppose that the first insn in the signal handler should trigger
another bp, we should clear X86_EFLAGS_RF (2/6).

Otoh, we should restore it when we return to the original insn
which triggered the trap to avoid another trap.

But. it seems that we have yet another problem? Suppose that
the signal handler does siglongjmp() and jumps to yet another
insn which should trigger the trap?

Oleg.

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

Re: linux-next: manual merge of the mfd tree with the v4l-dvb tree

[Mauro Carvalho Chehab]

Em 16-04-2013 10:51, Samuel Ortiz escreveu:

Hi Mauro,

On Wed, Apr 10, 2013 at 06:48:28AM -0300, Mauro Carvalho Chehab wrote:

Em Wed, 10 Apr 2013 08:42:53 +0200
Samuel Ortiz  escreveu:


Hi Stephen,

On Wed, Apr 10, 2013 at 01:48:13PM +1000, Stephen Rothwell wrote:

Hi Samuel,

Today's linux-next merge of the mfd tree got a conflict in
drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
mfd tree.

I'm surprised the v4l-dvb tree is carrying this patchset because I haven't
ACKed it.


Sorry. Not sure why I understood that you gave your ack. Perhaps I miss-read
one of the comments of that thread.

I haven't heard back from Andrey yet. If I don't get anything from him on
Wednesday, would you mind reverting this patchset ? I have not ACKed it
because it breaks bisectability, and it conflicts with mfd-next.


Sure. Just ping me and I'll revert it.



Andrey, any plans to adress my comments from last week ?

Cheers,
Samuel.



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

[PATCH V2] gpio: palmas: add dt support

[Laxman Dewangan]

Add of_device_id table for Palma GPIO to be enable the
driver from DT file.

The driver can be registered from DT file as:
palmas: tps65913@58 {
:::
palmas_gpio: palmas_gpio {
compatible = "ti,palmas-gpio";
gpio-controller;
#gpio-cells = <2>;
};
};

Signed-off-by: Laxman Dewangan 
---
Changes from V1:
Remove the ifdefs of CONFIG_OF around of_device_id structure for
defining compatible values.

 drivers/gpio/gpio-palmas.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/gpio/gpio-palmas.c b/drivers/gpio/gpio-palmas.c
index e3a4e56..5802662 100644
--- a/drivers/gpio/gpio-palmas.c
+++ b/drivers/gpio/gpio-palmas.c
@@ -134,7 +134,7 @@ static int palmas_gpio_probe(struct platform_device *pdev)
palmas_gpio->gpio_chip.get  = palmas_gpio_get;
palmas_gpio->gpio_chip.dev = >dev;
 #ifdef CONFIG_OF_GPIO
-   palmas_gpio->gpio_chip.of_node = palmas->dev->of_node;
+   palmas_gpio->gpio_chip.of_node = pdev->dev.of_node;
 #endif
palmas_pdata = dev_get_platdata(palmas->dev);
if (palmas_pdata && palmas_pdata->gpio_base)
@@ -159,9 +159,16 @@ static int palmas_gpio_remove(struct platform_device *pdev)
return gpiochip_remove(_gpio->gpio_chip);
 }
 
+static struct of_device_id of_palmas_gpio_match[] = {
+   { .compatible = "ti,palmas-gpio"},
+   { },
+};
+MODULE_DEVICE_TABLE(of, of_palmas_gpio_match);
+
 static struct platform_driver palmas_gpio_driver = {
.driver.name= "palmas-gpio",
.driver.owner   = THIS_MODULE,
+   .driver.of_match_table = of_palmas_gpio_match,
.probe  = palmas_gpio_probe,
.remove = palmas_gpio_remove,
 };
-- 
1.7.1.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] efi: Export efi_query_variable_store() for efivars.ko

[Sergey Vlasov]

Fixes build with CONFIG_EFI_VARS=m which was broken after the commit
"x86, efivars: firmware bug workarounds should be in platform code".

Signed-off-by: Sergey Vlasov 
---
 arch/x86/platform/efi/efi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 4959e3f..4f364c7 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -1144,3 +1144,4 @@ efi_status_t efi_query_variable_store(u32 attributes, 
unsigned long size)
 
return EFI_SUCCESS;
 }
+EXPORT_SYMBOL_GPL(efi_query_variable_store);
-- 
1.8.1.1

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

[PATCH 1/2] x86/Kconfig: Make EFI select UCS2_STRING

[Sergey Vlasov]

The commit "efi: Distinguish between "remaining space" and actually used
space" added usage of ucs2_*() functions to arch/x86/platform/efi/efi.c,
but the only thing which selected UCS2_STRING was EFI_VARS, which is
technically optional and can be built as a module.

Signed-off-by: Sergey Vlasov 
---
 arch/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a4f24f5..01af853 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1549,6 +1549,7 @@ config X86_SMAP
 config EFI
bool "EFI runtime service support"
depends on ACPI
+   select UCS2_STRING
---help---
  This enables the kernel to use EFI runtime services that are
  available (such as the EFI variable services).
-- 
1.8.1.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] binfmt_elf: fix return value in case of interpreter load failure

[Oleg Nesterov]

On 04/15, Andrew Morton wrote:
>
> On Fri, 12 Apr 2013 16:49:50 +0200 Matthieu CASTET 
>  wrote:
>
> > The only valid remaining part of my patch is to return SIGKILL when
> > load_elf_interp fail (IS_ERR((void *)elf_entry) is true) (for example load
> > address of linker is bad) instead of SIGSEGV. This will follow what is done 
> > when
> > loading binary.
> >
> > But is it even worth doing?
>
> SIGSEGV can be caught

Actually it can't be, flush_signal_handlers() was already called.
SIGSEGV can be blocked/ignored after that, but please note that
force_sig_info(SIGSEGV) will unblock and set SIG_DFL if necessary.

In short, force_sig() will actuallu kill the task in any case.

But: afaics send_sig(SIGSEGV) above load_elf_interp() is wrong,
we should either use SIGKILL (which can't be ignored/blocked) or
force_sig.

> that would be a user-visible change.

Yes. waitpid() can notice the difference.

> I just
> don't know what the implications of such a change would be :(

Mee too... Looks harmless but still.

OTOH, I do not know why/when we should use SIGKILL or SIGSEGV in
this code.

Oleg.

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

No serial since kernel 3.8

[Stephan von Krawczynski]

Hello,

can some kind soul please explain how I can get my serial port back under
kernel 3.8.X. Earlier kernels showed:

Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O 0x3f8
(irq = 4) is a 16550A

But 3.8.4:

Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled

Only kernel is replaced, no change in distro
Is there some kernel boot parameter needed now?
I tried 3.4.X and it works, even 3.7.X works...

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

Re: [PATCH v2 2/3] mutex: Queue mutex spinners with MCS lock to reduce cacheline contention

[Waiman Long]

On 04/16/2013 05:10 AM, Ingo Molnar wrote:

* Waiman Long  wrote:


--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3021,9 +3021,6 @@ static inline bool owner_running(struct mutex *lock, 
struct task_struct *owner)
   */
  int mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
  {
-   if (!sched_feat(OWNER_SPIN))
-   return 0;
-
rcu_read_lock();
while (owner_running(lock, owner)) {
if (need_resched())
@@ -3040,6 +3037,27 @@ int mutex_spin_on_owner(struct mutex *lock, struct 
task_struct *owner)
 */
return lock->owner == NULL;
  }
+
+/*
+ * Initial check for entering the mutex spinning loop
+ */
+int mutex_can_spin_on_owner(struct mutex *lock)
+{
+   int retval = 1;
+
+   if (!sched_feat(OWNER_SPIN))
+   return 0;
+
+   rcu_read_lock();
+   if (lock->owner)
+   retval = lock->owner->on_cpu;
+   rcu_read_unlock();
+   /*
+* if lock->owner is not set, the mutex owner may have just acquired
+* it and not set the owner yet or the mutex has been released.
+*/
+   return retval;
+}

The SCHED_FEAT_OWNER_SPIN was really just an early hack we did to make
with/without mutex-spinning testable.

I see.


I'd suggest a preparatory patch that gets rid of that flag and moves these two
functions from sched/core.c to mutex.c where they belong.

This will also allow the removal of the mutex prototypes from sched.h.


Yes, I can certainly prepare a patch to remove SCHED_FEAT_OWNER_SPIN & 
move those functions back to mutex.c after my patch set goes in. As for 
the timing, do you want me to do it now or it can wait as I will start 
my vacation later this week and will be back by the end of the month.


Regards,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Bonding driver has bad load balancing for forwarded traffic, 3.7+

[Eric Dumazet]

On Tue, 2013-04-16 at 06:51 -0700, Eric Dumazet wrote:

> Perfect, thanks a lot for all this !
> 
> Tested-by: Vitaly V. Bursov 
> 
> 

By the way, we probably should use skb_flow_dissect() to get proper
hashing for tunnels users.



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

Re: [PATCH v3] edac: Handle EDAC ECC errors for Family 16h

[Borislav Petkov]

On Mon, Apr 15, 2013 at 01:56:00PM -0500, Aravind Gopalakrishnan wrote:
> Add code to handle ECC decoding for fam16h. Support exists for
> previous families already, so code has been reused werever applicable
> and some code has been added to handle fam16h specific operations.
> 
> The patch was tested on Fam16h with ECC turned on
> using the mce_amd_inj facility and works fine.
> 
> Signed-off-by: Aravind Gopalakrishnan 
> ---
>  arch/x86/kernel/amd_nb.c  |4 +-
>  drivers/edac/amd64_edac.c |   96 
> +++--
>  drivers/edac/amd64_edac.h |4 +-
>  include/linux/pci_ids.h   |2 +
>  4 files changed, 101 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
> index 4c39baa..a8bbcf6 100644
> --- a/arch/x86/kernel/amd_nb.c
> +++ b/arch/x86/kernel/amd_nb.c
> @@ -16,12 +16,14 @@ const struct pci_device_id amd_nb_misc_ids[] = {
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB_MISC) },
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_10H_NB_MISC) },
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
> + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },

This chunk doesn't apply even on current Linus. For the future,
if you're sending x86 patches, always create them against current
tip/master which contains the latest x86 patch queue.

This one case in point, please redo it against tip/master.

>   {}
>  };
>  EXPORT_SYMBOL(amd_nb_misc_ids);
>  
>  static struct pci_device_id amd_nb_link_ids[] = {
>   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) },
> + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
>   {}
>  };
>  
> @@ -77,7 +79,7 @@ int amd_cache_northbridges(void)
>   next_northbridge(link, amd_nb_link_ids);
>  }
>  
> - /* some CPU families (e.g. family 0x11) do not support GART */
> + /* some CPU families (e.g. family 0x11, 0x16) do not support GART */
>   if (boot_cpu_data.x86 == 0xf || boot_cpu_data.x86 == 0x10 ||
>   boot_cpu_data.x86 == 0x15)
>   amd_northbridges.flags |= AMD_NB_GART;
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 9a8bebc..9173173 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -98,6 +98,7 @@ int __amd64_write_pci_cfg_dword(struct pci_dev *pdev, int 
> offset,
>   *
>   * F15h: we select which DCT we access using F1x10C[DctCfgSel]
>   *
> + * F16h has only 1 DCT
>   */
>  static int k8_read_dct_pci_cfg(struct amd64_pvt *pvt, int addr, u32 *val,
>  const char *func)
> @@ -133,6 +134,15 @@ static int f15_read_dct_pci_cfg(struct amd64_pvt *pvt, 
> int addr, u32 *val,
>   return __amd64_read_pci_cfg_dword(pvt->F2, addr, val, func);
>  }
>  
> +static int f16_read_dct_pci_cfg(struct amd64_pvt *pvt, int addr, u32 *val,
> + const char *func)
> +{
> + if (addr >= 0x100)
> + return -EINVAL;

I'm very sceptical F16h doesn't have F2 extended PCI config addresses.
Please check the BKDG.

If it does have, use f10_read_dct_pci_cfg, if it doesn't, use
k8_read_dct_pci_cfg without introducing a new accessor while the other
ones can be used.

Whichever one you take, please add a comment somewhere explaining why it
is ok to use it on F16h.

> + return __amd64_read_pci_cfg_dword(pvt->F2, addr, val, func);
> +}
> +
>  /*
>   * Memory scrubber control interface. For K8, memory scrubbing is handled by
>   * hardware and can involve L2 cache, dcache as well as the main memory. With
> @@ -326,7 +336,42 @@ static void get_cs_base_and_mask(struct amd64_pvt *pvt, 
> int csrow, u8 dct,
>   base_bits   = GENMASK(21, 31) | GENMASK(9, 15);
>   mask_bits   = GENMASK(21, 29) | GENMASK(9, 15);
>   addr_shift  = 4;
> - } else {
> + }
> +
> + /*
> + * there are two addr_shift values for F16h.
> + * addr_shift of 8 for high bits and addr_shift of 6
> + * for low bits. So handle it differently.
> + */
> + else if (boot_cpu_data.x86 == 0x16) {
> + /* variables specific to F16h */

Well, no need for that comment - we know what local variables are.

> + u64 base_bits_low, base_bits_high;
> + u64 mask_bits_low, mask_bits_high;
> + u8 addr_shift_low, addr_shift_high;
> +
> + csbase  = pvt->csels[dct].csbases[csrow];
> + csmask  = pvt->csels[dct].csmasks[csrow >> 1];
> + base_bits_low = mask_bits_low = GENMASK(5 , 15);
> + base_bits_high = mask_bits_high = GENMASK(19 , 30);
> + addr_shift_low = 6;
> + addr_shift_high = 8;

Hold on, are you saying "D18F2x[5C:40]_dct[1:0] DRAM CS Base Address"
register definitions in the F16h BKDG has this:

30:19 -> BaseAddr[38:27]: normalized physical base address bits [38:27]

and

15:5  

RE: [NEW DRIVER V4 2/7] DA9058 ADC driver

[Opensource [Anthony Olech]]

> [...]
> please always test your drivers against the latest upstream version before 
> submitting them.
> [...]

Hi Lars,

The driver was tested against linux mainline tag v3.9-rc6, because that was the 
most recent
tagged commit in 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git on the day
that I sent in the patches.

What exactly do you mean by "latest upstream version" ?
Did I use the correct repository ?

Tony Olech
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fuse: use kernel headers when __KERNEL__ is set

[Miklos Szeredi]

On Mon, Apr 15, 2013 at 11:47 PM, Colin Cross  wrote:
> On Mon, Apr 15, 2013 at 1:41 PM, Colin Cross  wrote:
>> Commit 7e98d53086d18c877cb44e9065219335184024de (Synchronize fuse
>> header with one used in library) added #ifdef __linux__ around
>> defines if it is not set.  The kernel build is self-contained and
>> can be built on non-Linux toolchains.  After the mentioned commit
>> builds on non-Linux toolchains will try to include stdint.h and
>> fail due to -nostdinc, and then fail with a bunch of undefined
>> type errors.
>>
>> Change the #ifdef to check for __linux__ or __KERNEL__ so that
>> it uses the kernel typedefs if __KERNEL__ is set.
>>
>> Signed-off-by: Colin Cross 
>> ---
>> I think this should go in v3.9, without it bare-metal toolchains
>> that don't define __linux__ will fail to compile the kernel, and
>> cross-compiles from non-linux hosts will probably also fail.
>
> Miklos, I see Arve sent an equivalent patch to you a month ago
> (https://lkml.org/lkml/2013/3/11/620), and I agree with his response
> to your question (checking for __linux__ and __KERNEL__ is better than
> just checking for __KERNEL__ if you want this header to be used in
> userspace builds on linux targets).

And I still disagree.  Why should userspace use the linux internal
header when there's a perfectly good standard header that it can use?

Patch committed and pushed to for-next and for-linus.  I'll push to
Linus tomorrow.

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

How to override GMA500 resolution set by BIOS?

[Marcin Szewczyk]

Hello,

I've got a problem with GMA500 on my EVOC EC2-1711. The graphics
adapter's resolution is set by selecting an option in BIOS but I would
like to override it. Can kernel or Xorg do this?

There are two modes "almost" right for an 800x600 16bit LVDS screen I
have.  The first one is 800x600 but in 24bit LVDS mode, so colors are
mangled. The second one is 800x480 16bit -- colors are right, but the
screen cuts the image at line 480.

I've tried video=, overwriting modes via patched 915resolution, vga= and
Xorg modesetting driver. Nothing works.

Does anyone know if it's possible to override the mode?

-- 
Marcin Szewczyk   http://wodny.org
mailto:marcin.szewc...@wodny.borg  <- remove b / usuń b
xmpp:wo...@ubuntu.pl  xmpp:wo...@jabster.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] menuconfig: Add "breadcrumbs" navigation aid

[Benjamin Poirier]

Displays a trail of the menu entries used to get to the current menu.

Signed-off-by: Benjamin Poirier 
Tested-by: "Yann E. MORIN" 
[yann.morin.1...@free.fr: small, trivial code re-ordering]
Signed-off-by: "Yann E. MORIN" 
---

Indeed Yann, we can even remove one wmove() and one level of indentation in
dialog_clear().

I'm not sure who's pulling from who and where patches are going, but this
would supersede what's in yem-kconfig-for-next now.


 scripts/kconfig/list.h|   27 ++
 scripts/kconfig/lxdialog/dialog.h |7 
 scripts/kconfig/lxdialog/util.c   |   45 +--
 scripts/kconfig/mconf.c   |   71 -
 4 files changed, 147 insertions(+), 3 deletions(-)

diff --git a/scripts/kconfig/list.h b/scripts/kconfig/list.h
index 0ae730b..2f02a3b 100644
--- a/scripts/kconfig/list.h
+++ b/scripts/kconfig/list.h
@@ -88,4 +88,31 @@ static inline void list_add_tail(struct list_head *_new, 
struct list_head *head)
__list_add(_new, head->prev, head);
 }
 
+/*
+ * Delete a list entry by making the prev/next entries
+ * point to each other.
+ *
+ * This is only for internal list manipulation where we know
+ * the prev/next entries already!
+ */
+static inline void __list_del(struct list_head *prev, struct list_head *next)
+{
+   next->prev = prev;
+   prev->next = next;
+}
+
+#define LIST_POISON1  ((void *) 0x00100100)
+#define LIST_POISON2  ((void *) 0x00200200)
+/**
+ * list_del - deletes entry from list.
+ * @entry: the element to delete from the list.
+ * Note: list_empty() on entry does not return true after this, the entry is
+ * in an undefined state.
+ */
+static inline void list_del(struct list_head *entry)
+{
+   __list_del(entry->prev, entry->next);
+   entry->next = LIST_POISON1;
+   entry->prev = LIST_POISON2;
+}
 #endif
diff --git a/scripts/kconfig/lxdialog/dialog.h 
b/scripts/kconfig/lxdialog/dialog.h
index 307022a..10993370 100644
--- a/scripts/kconfig/lxdialog/dialog.h
+++ b/scripts/kconfig/lxdialog/dialog.h
@@ -106,8 +106,14 @@ struct dialog_color {
int hl; /* highlight this item */
 };
 
+struct subtitle_list {
+   struct subtitle_list *next;
+   const char *text;
+};
+
 struct dialog_info {
const char *backtitle;
+   struct subtitle_list *subtitles;
struct dialog_color screen;
struct dialog_color shadow;
struct dialog_color dialog;
@@ -196,6 +202,7 @@ int on_key_resize(void);
 
 int init_dialog(const char *backtitle);
 void set_dialog_backtitle(const char *backtitle);
+void set_dialog_subtitles(struct subtitle_list *subtitles);
 void end_dialog(int x, int y);
 void attr_clear(WINDOW * win, int height, int width, chtype attr);
 void dialog_clear(void);
diff --git a/scripts/kconfig/lxdialog/util.c b/scripts/kconfig/lxdialog/util.c
index 109d531..a0e97c2 100644
--- a/scripts/kconfig/lxdialog/util.c
+++ b/scripts/kconfig/lxdialog/util.c
@@ -257,12 +257,48 @@ void dialog_clear(void)
attr_clear(stdscr, LINES, COLS, dlg.screen.atr);
/* Display background title if it exists ... - SLH */
if (dlg.backtitle != NULL) {
-   int i;
+   int i, len = 0, skip = 0;
+   struct subtitle_list *pos;
 
wattrset(stdscr, dlg.screen.atr);
mvwaddstr(stdscr, 0, 1, (char *)dlg.backtitle);
+
+   for (pos = dlg.subtitles; pos != NULL; pos = pos->next) {
+   /* 3 is for the arrow and spaces */
+   len += strlen(pos->text) + 3;
+   }
+
wmove(stdscr, 1, 1);
-   for (i = 1; i < COLS - 1; i++)
+   if (len > COLS - 2) {
+   const char *ellipsis = "[...] ";
+   waddstr(stdscr, ellipsis);
+   skip = len - (COLS - 2 - strlen(ellipsis));
+   }
+
+   for (pos = dlg.subtitles; pos != NULL; pos = pos->next) {
+   if (skip == 0)
+   waddch(stdscr, ACS_RARROW);
+   else
+   skip--;
+
+   if (skip == 0)
+   waddch(stdscr, ' ');
+   else
+   skip--;
+
+   if (skip < strlen(pos->text)) {
+   waddstr(stdscr, pos->text + skip);
+   skip = 0;
+   } else
+   skip -= strlen(pos->text);
+
+   if (skip == 0)
+   waddch(stdscr, ' ');
+   else
+   skip--;
+   }
+
+   for (i = len + 1; i < COLS - 1; i++)
waddch(stdscr, ACS_HLINE);
}
wnoutrefresh(stdscr);
@@ -302,6 +338,11 @@ void set_dialog_backtitle(const char *backtitle)
dlg.backtitle = 

RE: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver

[Opensource [Anthony Olech]]

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 16 April 2013 14:36
> To: Opensource [Anthony Olech]
> Cc: LKML
> Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
> 
> On Tue, Apr 16, 2013 at 09:17:27AM +, Opensource [Anthony Olech]
> wrote:
> > > -Original Message-
> > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > Sent: 15 April 2013 18:46
> > > To: Opensource [Anthony Olech]
> > > Cc: LKML
> > > Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
> > >
> > > On Mon, Apr 15, 2013 at 05:29:13PM +, Opensource [Anthony Olech]
> > > wrote:
> > > > > -Original Message-
> > > > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > > > Sent: 15 April 2013 17:36
> > > > > To: Opensource [Anthony Olech]
> > > > > Cc: LKML
> > > > > Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
> > > > >
> > > > > On Mon, Apr 15, 2013 at 03:00:58PM +, Opensource [Anthony
> > > > > Olech]
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > > > > > Sent: 12 April 2013 14:32
> > > > > > > To: Opensource [Anthony Olech]
> > > > > > > Cc: Mark Brown; Liam Girdwood; Jean Delvare; Randy Dunlap;
> > > > > > > LKML; David Dajun Chen
> > > > > > > Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
> > > > > > >
> > > > > > > On Fri, Apr 12, 2013 at 02:05:28PM +0100, Anthony Olech wrote:
> > > > > > > > This is the REGULATOR component driver of the Dialog DA9058
> PMIC.
> > > > > > > > This driver is just one component of the whole DA9058 PMIC
> driver.
> > > > > > > > It depends on the CORE component driver of the DA9058 MFD.
> > > > > > > >
> > > > > > > > There are 6 warnings from scripts/checkpatch.pl, but since
> > > > > > > > it seems to be complaining about variable names such as
> > > > > > > > min_uV are in CamelCase, when it is obvious that they are
> > > > > > > > not in CamelCase I have
> > > > > ignored them.
> > > > > > > >
> > > > > > > ??? min_uV _is_ CamelCase ???
> > > > > > >
> > > > > > > Ok, maybe it is camelcasE, but you are splitting hairs here.
> > > > > >
> > > > > > it is not me splitting hairs, it is scripts/checkpatch.pl
> > > > > >
> > > > > Maybe you did not understand what I meant. Per your logic,
> > > > >
> > > > >   MicroVolt is CamelCase
> > > > >   uVolt is ???
> > > > >   uV is not CamelCase
> > > > >
> > > > > By abbreviating CamelCase to camelCase to cC you make it, in
> > > > > your opinion, acceptable.
> > > > >
> > > > > If you want to declare CamelCase variables, just do it, but
> > > > > don't claim that they are not really CamelCase.
> > > > >
> > > > > Guenter
> > > >
> > > > I always thought that camel case meant "changing from lower case
> > > > to upper case the first letter of each word and then joining the
> > > > capitalized words together", so by that definition uV or mW are
> > > > not camel
> > > case because "v" and "w" are not words!
> >
> > The definition of CamelCase From Wikipedia, the free encyclopedia is:
> >
> > "CamelCase (camel case) is a term which refers to the practice of
> > writing compound words where the first letter of an identifier is
> > lowercase and the first letter of each subsequent concatenated word is
> capitalized."
> >
> Maybe the rule should read "don't mix lowercase and uppercase letters in
> variable names and defines" to prevent variable names such as cAmelcAse or
> cameLcasE, which would be permitted with your logic :).

It is really good to have a definition that anyone can work with!
 
> > > > Either way it seems that the algorithm in scripts/checkpatch.pl is
> > > > wrong! and
> > > that was my point.
> > >
> > > Guess we'll have to agree to disagree here, as I happen to think
> > > that checkpatch is perfectly right.
> > > Guenter
> >
> > Hi Guenter,
> >
> > I am quite happy to accept the algorithm in scripts/checkpatch.pl as
> > the arbiter for correctly formed linux kernel variable names.
> >
> > On that basis "old_mV", "new_uA" etc are incorrectly formed variable names.
> > Could you possibly suggest legal alternatives to "mA", "uV", "kW" ??
> >
> I just changed it to lowercase in the ntc_thermistor driver. What you use is
> really your call as long as it does not mix uppercase and lowercase letters.
> 
> Guenter

many thanks, I will do the same.

Tony Olech

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

Re: [Patch -v4 1/4] Migrate shutdown/reboot to boot cpu.

[Robin Holt]

> > > +{
> > > + /* The boot cpu is always logical cpu 0 */
> > > + int reboot_cpu_id = 0;
> > > +
> > > + /* Make certain the cpu I'm about to reboot on is online */
> > > + if (!cpu_online(reboot_cpu_id))
> > > + reboot_cpu_id = smp_processor_id();
> > 
> > Shouldn't we pick the first online CPU instead, to make it deterministic?
> 
> Done.
> 
>   reboot_cpu_id = cpumask_first(cpu_online_mask);
> 
> > Also, does this codepath prevent hotplug from going on in parallel?
> 
> Not sure.  I have not considered hotplug.  I will look that over when I
> am in the office.

OK.  I have been mulling this over for a bit and I don't think I
understand what you are asking.

I would expect that if an architecture depends upon a certain cpu for
shutdown/reboot/halt/suspend/hibernate and that support has been compiled
in, then the arch should be preventing that cpu from being removed.
I do not know how that would work and think that is far beyond the scope
of the initial problem I have been trying to solve.  If that is your
question, I certainly do not know how to address it.  I get the feeling
this is off your mark due to the "parallel" wording above.

The other question I think you might be asking is something about the
shutdown/reboot/halt task trying to migrate to a cpu which is in the
process of being off-lined.  I believe the code will "work" in that
we will have selected a cpu to migrate to, that migration may fail,
in which case our task remains on the current cpu, may succeed and the
cpu is immediately offlined, in which case the hotplug code should move
us to another cpu, or we complete the shutdown before the hotplug code
gets a chance to run, in which case it is irrelevant.

Have I addressed your concern?  Are you asking me to look into a method
for preventing the arch from hot removing the shutdown/reboot cpu?

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

[tip:x86/cpu] x86, CPU, AMD: Drop useless label

[tip-bot for Borislav Petkov]

Commit-ID:  1077c932db63ecc571c31df1c24d4a44e30928e5
Gitweb: http://git.kernel.org/tip/1077c932db63ecc571c31df1c24d4a44e30928e5
Author: Borislav Petkov 
AuthorDate: Mon, 8 Apr 2013 17:57:46 +0200
Committer:  Borislav Petkov 
CommitDate: Tue, 16 Apr 2013 11:50:51 +0200

x86, CPU, AMD: Drop useless label

All we want to do is return from this function so stop jumping around
like a flea for no good reason.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/136543-9837-5-git-send-email...@alien8.de
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/cpu/amd.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index cea02d7..5013a48 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -192,11 +192,11 @@ static void __cpuinit amd_k7_smp_check(struct cpuinfo_x86 
*c)
/* Athlon 660/661 is valid. */
if ((c->x86_model == 6) && ((c->x86_mask == 0) ||
(c->x86_mask == 1)))
-   goto valid_k7;
+   return;
 
/* Duron 670 is valid */
if ((c->x86_model == 7) && (c->x86_mask == 0))
-   goto valid_k7;
+   return;
 
/*
 * Athlon 662, Duron 671, and Athlon >model 7 have capability
@@ -209,7 +209,7 @@ static void __cpuinit amd_k7_smp_check(struct cpuinfo_x86 
*c)
((c->x86_model == 7) && (c->x86_mask >= 1)) ||
 (c->x86_model > 7))
if (cpu_has_mp)
-   goto valid_k7;
+   return;
 
/* If we get here, not a certified SMP capable AMD system. */
 
@@ -220,9 +220,6 @@ static void __cpuinit amd_k7_smp_check(struct cpuinfo_x86 
*c)
WARN_ONCE(1, "WARNING: This combination of AMD"
" processors is not suitable for SMP.\n");
add_taint(TAINT_UNSAFE_SMP, LOCKDEP_NOW_UNRELIABLE);
-
-valid_k7:
-   ;
 }
 
 static void __cpuinit init_amd_k7(struct cpuinfo_x86 *c)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/cpu] x86, AMD: Correct {rd,wr}msr_amd_safe warnings

[tip-bot for Borislav Petkov]

Commit-ID:  682469a5db6fade318a72406935b5000186e5643
Gitweb: http://git.kernel.org/tip/682469a5db6fade318a72406935b5000186e5643
Author: Borislav Petkov 
AuthorDate: Mon, 8 Apr 2013 17:57:45 +0200
Committer:  Borislav Petkov 
CommitDate: Tue, 16 Apr 2013 11:50:51 +0200

x86, AMD: Correct {rd,wr}msr_amd_safe warnings

The idea with those routines is to slowly phase them out and not call
them on anything else besides K8. They even have a check for that which,
when called too early, fails. Let me explain:

It gets the cpuinfo_x86 pointer from the per_cpu array and when this
happens for cpu0, before its boot_cpu_data has been copied back to the
per_cpu array in smp_store_boot_cpu_info(), we get an empty struct and
thus the check fails.

Use boot_cpu_data directly instead.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/136543-9837-4-git-send-email...@alien8.de
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/cpu/amd.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 9a2a716..cea02d7 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -20,11 +20,11 @@
 
 static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
 {
-   struct cpuinfo_x86 *c = _data(smp_processor_id());
u32 gprs[8] = { 0 };
int err;
 
-   WARN_ONCE((c->x86 != 0xf), "%s should only be used on K8!\n", __func__);
+   WARN_ONCE((boot_cpu_data.x86 != 0xf),
+ "%s should only be used on K8!\n", __func__);
 
gprs[1] = msr;
gprs[7] = 0x9c5a203a;
@@ -38,10 +38,10 @@ static inline int rdmsrl_amd_safe(unsigned msr, unsigned 
long long *p)
 
 static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
 {
-   struct cpuinfo_x86 *c = _data(smp_processor_id());
u32 gprs[8] = { 0 };
 
-   WARN_ONCE((c->x86 != 0xf), "%s should only be used on K8!\n", __func__);
+   WARN_ONCE((boot_cpu_data.x86 != 0xf),
+ "%s should only be used on K8!\n", __func__);
 
gprs[0] = (u32)val;
gprs[1] = msr;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/cpu] x86: Fold-in trivial check_config function

[tip-bot for Borislav Petkov]

Commit-ID:  55a36b65ee7107d6bb557c96fd202c4e90164542
Gitweb: http://git.kernel.org/tip/55a36b65ee7107d6bb557c96fd202c4e90164542
Author: Borislav Petkov 
AuthorDate: Mon, 8 Apr 2013 17:57:44 +0200
Committer:  Borislav Petkov 
CommitDate: Tue, 16 Apr 2013 11:50:50 +0200

x86: Fold-in trivial check_config function

Fold it into its single call site. No functionality change.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/136543-9837-3-git-send-email...@alien8.de
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/cpu/bugs.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index c59635e..4112be9 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -81,21 +81,6 @@ static void __init check_fpu(void)
}
 }
 
-/*
- * Check whether we are able to run this kernel safely on SMP.
- *
- * - i386 is no longer supported.
- * - In order to run on anything without a TSC, we need to be
- *   compiled for a i486.
- */
-
-static void __init check_config(void)
-{
-   if (boot_cpu_data.x86 < 4)
-   panic("Kernel requires i486+ for 'invlpg' and other features");
-}
-
-
 void __init check_bugs(void)
 {
identify_boot_cpu();
@@ -103,7 +88,17 @@ void __init check_bugs(void)
pr_info("CPU: ");
print_cpu_info(_cpu_data);
 #endif
-   check_config();
+
+   /*
+* Check whether we are able to run this kernel safely on SMP.
+*
+* - i386 is no longer supported.
+* - In order to run on anything without a TSC, we need to be
+*   compiled for a i486.
+*/
+   if (boot_cpu_data.x86 < 4)
+   panic("Kernel requires i486+ for 'invlpg' and other features");
+
init_utsname()->machine[1] =
'0' + (boot_cpu_data.x86 > 6 ? 6 : boot_cpu_data.x86);
alternative_instructions();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] kill ptrace_{get,put}_breakpoints()

[Oleg Nesterov]

On 04/16, Michael Neuling wrote:
>
> > Benjamin, Paul, arch_dup_task_struct()->flush_ptrace_hw_breakpoint(src)
> > on powerpc looks "obviously wrong". Don't we need
> >
> > - flush_ptrace_hw_breakpoint(src);
> > + dst->thread->ptrace_bps[0] = NULL;
>
> Do you mean the following?
>
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 59dd545..559804e 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -911,7 +911,7 @@ int arch_dup_task_struct(struct task_struct *dst, struct 
> tas
> flush_vsx_to_thread(src);
> flush_spe_to_thread(src);
>  #ifdef CONFIG_HAVE_HW_BREAKPOINT
> -   flush_ptrace_hw_breakpoint(src);
> +   dst->thread.ptrace_bps[0] = NULL;
>  #endif /* CONFIG_HAVE_HW_BREAKPOINT */

Almost.

This is what I think we should do, but it is pointless to do this
in arch_dup_task_struct(), setup_thread_stack() will copy ptrace_bps[]
from parent later.

> Unable to handle kernel paging request for data at address 0x00100108
> Faulting instruction address: 0xc014d5e4
> cpu 0x0: Vector: 300 (Data Access) at [c0007e5836a0]
> pc: c014d5e4: .toggle_bp_slot+0x74/0x1c0
> lr: c014dc14: .release_bp_slot+0x44/0x70
> sp: c0007e583920
>msr: 90009032
>dar: 100108
>  dsisr: 4200
>   current = 0xc0007e56
>   paca= 0xcfe0 softe: 0irq_happened: 0x08
> pid   = 1, comm = init
> enter ? for help
> [c0007e5839d0] c014dc14 .release_bp_slot+0x44/0x70
> [c0007e583a50] c0144bbc .free_event+0x6c/0x1e0
> [c0007e583ad0] c0144dc4 .perf_event_release_kernel+0x94/0x110
> [c0007e583b60] c014cf08 .unregister_hw_breakpoint+0x18/0x30
> [c0007e583bd0] c000e5f8 .ptrace_set_debugreg+0x158/0x230
> [c0007e583cd0] c000eb4c .arch_ptrace+0x43c/0x7b0
> [c0007e583d90] c008cbf8 .SyS_ptrace+0x98/0x170
> [c0007e583e30] c0009d54 syscall_exit+0x0/0x98
> --- Exception: c01 (System Call) at 1001d1d4
> SP (3fffdf7459f0) is in userspace
>
> The crash seems to happen some time after the fork.  Might be when the
> new processes exits or get another ptrace call on it (I'm not sure which
> one sorry).

Yes, probably because both parent and child have the same ->ptrace_bps[]
pointers.

> Without your suggestion it doesn't crash this case (ie. mainline passes).

This is clear. flush_ptrace_hw_breakpoint() nullifies ->ptrace_bps[], so
setup_thread_stack() copies NULL.

But, unless I missed something, this is wrong. Why should the parent lose
its bps after fork?

IOW, I think we need something like the patch below, but I do not have
a powerpc machine for the testing.

> Acked-by: Michael Neuling 

Thanks!

Oleg.

[PATCH] ptrace/powerpc: dont flush_ptrace_hw_breakpoint() on fork()

arch_dup_task_struct() does flush_ptrace_hw_breakpoint(src), this
is not what we want. We should clear child->thread.ptrace_bps[]
copied by dup_task_struct().

--- x/arch/powerpc/kernel/process.c
+++ x/arch/powerpc/kernel/process.c
@@ -910,10 +910,6 @@ int arch_dup_task_struct(struct task_str
flush_altivec_to_thread(src);
flush_vsx_to_thread(src);
flush_spe_to_thread(src);
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
-   flush_ptrace_hw_breakpoint(src);
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
-
*dst = *src;
return 0;
 }
@@ -984,6 +980,10 @@ int copy_thread(unsigned long clone_flag
p->thread.ksp_limit = (unsigned long)task_stack_page(p) +
_ALIGN_UP(sizeof(struct thread_info), 16);
 
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+   p->thread.ptrace_bps[0] = NULL;
+#endif
+
 #ifdef CONFIG_PPC_STD_MMU_64
if (mmu_has_feature(MMU_FTR_SLB)) {
unsigned long sp_vsid;

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

Re: [RFC PATCH v2 14/15] mm: Add alloc-free handshake to trigger memory region compaction

[Srivatsa S. Bhat]

Hi Cody,

Thank you for your review comments and sorry for the delay in replying!

On 04/11/2013 04:56 AM, Cody P Schafer wrote:
> On 04/09/2013 02:48 PM, Srivatsa S. Bhat wrote:
>> We need a way to decide when to trigger the worker threads to perform
>> region evacuation/compaction. So the strategy used is as follows:
>>
>> Alloc path of page allocator:
>> 
>>
>> This accurately tracks the allocations and detects the first allocation
>> in a new region and notes down that region number. Performing compaction
>> rightaway is not going to be helpful because we need free pages in the
>> lower regions to be able to do that. And the page allocator allocated in
>> this region precisely because there was no memory available in lower
>> regions.
>> So the alloc path just notes down the freshly used region's id.
>>
>> Free path of page allocator:
>> ---
>>
>> When we enter this path, we know that some memory is being freed. Here we
>> check if the alloc path had noted down any region for compaction. If so,
>> we trigger the worker function that tries to compact that memory.
>>
>> Also, we avoid any locking/synchronization overhead over this worker
>> function in the alloc/free path, by attaching appropriate semantics to
>> the
>> available status flags etc, such that we won't need any special locking
>> around them.
>>
> 
> Can you explain why avoiding locking works in this case?
> 

Sure, see below. BTW, the whole idea behind doing this is to avoid additional
overhead as much as possible, since these are quite hot paths in the kernel.

> It appears the lack of locking is only on the worker side, and the
> mem_power_ctrl is implicitly protected by zone->lock on the alloc & free
> side.
> 

That's right. What I meant to say is that I don't introduce any *extra*
locking overhead in the alloc/free path, just to synchronize the updates to
mem_power_ctrl. On the alloc/free side, as you rightly noted, I piggyback
on the zone->lock to get the synchronization right.

On the worker side, I don't need any locking, due to the following reasons:

a. Only 1 worker (at max) is active at any given time.

   The free path of the page allocator (which queues the worker) never
   queues more than 1 worker at a time. If a worker is still busy doing a
   previously queued work, the free path just ignores new hints from the
   alloc path about region evacuation. So essentially no 2 workers run at
   the same time. So the worker need not worry about being re-entrant.

b. The ->work_status field in the mem_power_ctrl structure is never written
   to by 2 different tasks at the same time.
 
   The free path always avoids updates to the ->work_status field in presence
   of an active worker. That is, until the ->work_status is set to
   MEM_PWR_WORK_COMPLETE by the worker, the free path won't write to it.

   So the ->work_status field can be written to by the worker and read by
   the free path at the same time - which is fine, because in that case,
   if the free path read the old value, it will just assume that the worker
   is still active and ignores the alloc path's hint, which is harmless.
   Similar is the case about why the alloc path can read the ->work_status
   without locking out the worker : if it reads the old value, it doesn't
   set any new hints in ->region, which is again fine.

c. The ->region field in the mem_power_ctrl structure is also never written
   to by 2 different tasks at the same time. This goes by extending the logic
   in 'b'.

Yes, this scheme could mean that sometimes we might lose a few opportunities to
perform region evacuation, but that is OK, because that's the price we pay
in order to avoid hurting performance too much. Besides, there's a more
important reason why its actually critical that we aren't too aggressive
and jump at every opportunity to do compaction; see below.

> In the previous patch I see smp_mb(), but no explanation is provided for
> why they are needed. Are they related to/necessary for this lack of
> locking?
> 

Hmm, looking at that again, I don't think it is needed. I'll remove it in
the next version.

> What happens when a region is passed over for compaction because the
> worker is already compacting another region? Can this occur?

Yes it can occur. But since we try to allocate pages in increasing order of
regions, if this situation does occur, there is a very good chance that we
won't benefit from compacting both regions, see below.

> Will the
> compaction re-trigger appropriately?
> 

No, there is no re-trigger and that's by design. A particular region being
suitable for compaction is only a transient/temporary condition; it might
not persist forever. So it might not be worth trying over and over.
So if the worker was busy compacting some other region when the alloc path
hinted a new region for compaction, we simply ignore it because, there is
no guarantee that that situation (the new region being suitable for 

Re: linux-next: manual merge of the mfd tree with the v4l-dvb tree

[Samuel Ortiz]

Hi Mauro,

On Wed, Apr 10, 2013 at 06:48:28AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 10 Apr 2013 08:42:53 +0200
> Samuel Ortiz  escreveu:
> 
> > Hi Stephen,
> > 
> > On Wed, Apr 10, 2013 at 01:48:13PM +1000, Stephen Rothwell wrote:
> > > Hi Samuel,
> > > 
> > > Today's linux-next merge of the mfd tree got a conflict in
> > > drivers/mfd/Kconfig between commit 3f8ec5df11aa ("[media] mfd: Add header
> > > files and Kbuild plumbing for SI476x MFD core") from the v4l-dvb tree and
> > > commit ab85b120e692 ("mfd: Kconfig alphabetical re-ordering") from the
> > > mfd tree.
> > I'm surprised the v4l-dvb tree is carrying this patchset because I haven't
> > ACKed it. 
> 
> Sorry. Not sure why I understood that you gave your ack. Perhaps I miss-read
> one of the comments of that thread.
I haven't heard back from Andrey yet. If I don't get anything from him on
Wednesday, would you mind reverting this patchset ? I have not ACKed it
because it breaks bisectability, and it conflicts with mfd-next.

Andrey, any plans to adress my comments from last week ?

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.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: Bonding driver has bad load balancing for forwarded traffic, 3.7+

[Eric Dumazet]

On Tue, 2013-04-16 at 12:01 +0300, Vitaly V. Bursov wrote:

> Testing under real load for almost 2 hours now, works as expected.
> xmit_hash_policy=layer3+4
> 
> I made a few simple test with layer2+3 policy too, looks OK.
> 
> Thanks!

Perfect, thanks a lot for all this !

Tested-by: Vitaly V. Bursov 



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

[tip:x86/mm] x86/mm/gart: Drop unnecessary check

[tip-bot for Wang YanQing]

Commit-ID:  26bfc540f6f2dcbd93d0b9ed8f37830419ded7e8
Gitweb: http://git.kernel.org/tip/26bfc540f6f2dcbd93d0b9ed8f37830419ded7e8
Author: Wang YanQing 
AuthorDate: Tue, 16 Apr 2013 09:37:34 +0800
Committer:  Ingo Molnar 
CommitDate: Tue, 16 Apr 2013 10:54:40 +0200

x86/mm/gart: Drop unnecessary check

The memblock_find_in_range() return value addr is guaranteed
to be within "addr + aper_size" and not beyond GART_MAX_ADDR.

Signed-off-by: Wang YanQing 
Cc: ying...@kernel.org
Link: http://lkml.kernel.org/r/20130416013734.GA14641@udknight
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/aperture_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index d5fd66f..fd972a3 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -87,7 +87,7 @@ static u32 __init allocate_aperture(void)
 */
addr = memblock_find_in_range(GART_MIN_ADDR, GART_MAX_ADDR,
  aper_size, aper_size);
-   if (!addr || addr + aper_size > GART_MAX_ADDR) {
+   if (!addr) {
printk(KERN_ERR
"Cannot allocate aperture memory hole (%lx,%uK)\n",
addr, aper_size>>10);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cris: drop unused Kconfig symbols

[Jesper Nilsson]

On Tue, Apr 16, 2013 at 10:34:04AM +0200, Paul Bolle wrote:
> Signed-off-by: Paul Bolle 
> ---
> 0) The first version had the subject "[PATCH 21/21] cris: drop unused
> Kconfig symbols".
> 
> 1) This version was redone on top of v3.9-rc7. The changes since the
> first version are:
> - dropped OOM_REBOOT (I sent a separate patch for that symbol because I
> didn't realize it was part of the first version, as it is the only
> symbol without the EXTRAX_ prefix);
> - added ETRAX_ETHERNET_IFACE0, ETRAX_ETHERNET_IFACE1, and
> ETRAX_SERIAL_PORT4 (my scripts got smarter).
> 
> 2) This patch can be tested (after applying) with this one-liner:
> for symbol in $(git log -1 -p | grep "^-config" | awk '{ print $2 }'); do 
> git grep -n "$symbol\b"; done
> 
> That should show no output.

Thanks, applied to the CRIS-tree.

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

Re: [RFC PATCH 1/3] pstore-ram: use write-combine mappings

[Catalin Marinas]

On Tue, Apr 16, 2013 at 01:58:27PM +0100, Rob Herring wrote:
> On 04/16/2013 03:44 AM, Will Deacon wrote:
> > On Tue, Apr 16, 2013 at 01:43:09AM +0100, Colin Cross wrote:
> >> On Mon, Apr 15, 2013 at 4:59 PM, Rob Herring  wrote:
> >>> Exclusive accesses still have further restrictions. From section 3.4.5:
> >>>
> >>> • It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be
> >>> performed to a memory region
> >>>with the Device or Strongly-ordered memory attribute. Unless the
> >>> implementation documentation explicitly
> >>>   states that LDREX and STREX operations to a memory region with the
> >>> Device or Strongly-ordered attribute are
> >>>  permitted, the effect of such operations is UNPREDICTABLE.
> >>>
> >>>
> >>> Given that it is implementation defined, I don't see how Linux can rely
> >>> on that behavior.
> >>
> >> I see, the problem is that while noncached and writecombined appear to
> >> be similar mappings, noncached is mapped in PRRR to strongly-ordered,
> >> while writecombined is mapped to unbufferable normal memory.
> >>
> >> I think adding a wmb() to persistent_ram_write is going to be
> >> expensive on cpus with outer caches like the L2X0, where wmb() will
> >> result in a spinlock.  Is there a real SoC where this doesn't work?
> > 
> > A real SoC where exclusives don't work to memory not mapped as normal? Take
> > your pick...
> 
> This patch doesn't actually fix problems for me. Exclusives to DDR work
> for any memory type for me as the DDR controller has an exclusive
> monitor. It takes write-thru cache mapping to get internal RAM to work.

I can't find any reference in the ARM ARM but I think you would need
cacheable memory for the exclusives to work. A9 for example uses the
cacheline exclusiveness to emulate the global monitor.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Linaro-QA-Service] [linux-next] Snowball build broken

[Naresh Kamboju]

On 12 April 2013 04:07, Linus Walleij  wrote:
> On Thu, Apr 11, 2013 at 8:28 PM, Naresh Kamboju
>  wrote:
>
>> One of those ARM targets is Snowball. Snowball build broken log can be found
>> here
>>
>> Build Error:
>>
>> 04:48:08   CC  drivers/mfd/ab8500-debugfs.o
>> 04:48:09
>> /mnt/ci_build/workspace/linux-next/hwpack/snowball/label/precise_hwpack_cloud/drivers/mfd/ab8500-debugfs.c:95:23:
>> fatal error: mach/irqs.h: No such file or directory
>> 04:48:09 compilation terminated.
>> 04:48:09 make[3]: *** [drivers/mfd/ab8500-debugfs.o] Error 1
>> 04:48:09 make[2]: *** [drivers/mfd] Error 2
>> 04:48:09 make[1]: *** [drivers] Error 2
>
> Hey it works. Didn't see this before I fixed it tho :-)
> http://marc.info/?l=linux-kernel=136567139910888=2
This commit not yet been merged in to linux-next  "next-20130416".
Due to this reason still snowball build fails at above error.

Best regards
Naresh Kamboju
>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dmaengine: at_hdmac: fix race condition in atc_advance_work()

[Vinod Koul]

On Tue, Apr 16, 2013 at 01:49:34PM +0200, Nicolas Ferre wrote:
> From: Ludovic Desroches 
> 
> The BUG_ON() directive is triggered probably due to a latency modification
> following inclusion of c10d736 (softirq: reduce latencies).
> This condition has not been met before 3.9-rc1 and doesn't trigger without
> this patch.
> 
> We now make sure that DMA channel is idle before calling atc_complete_all()
> which makes the BUG_ON() "protection" useless.
> 
> Signed-off-by: Ludovic Desroches 
> Signed-off-by: Nicolas Ferre 
Acked-by: Vinod Koul 
> ---
> Linus,
> 
> We have identified a race condition on the Atmel ARM-based AT91 DMA controller
> driver that leads to hitting a BUG_ON() directive.
> This error, only triggered after the inclusion of a patch that reduces the
> softirq latency, is affecting several AT91 SoCs and can be seen
> as a regression by people using the dmaengine driver (on NAND flash
> accesses for instance).
> 
> I know that it is late in the development cycle but can you please consider
> including it in your tree before 3.9-final?
> 
> This patch can also go through dmaengine tree (Vinod Koul) but I do not know 
> if
> there is enough time remaining.
> 
> Thanks a lot, best regards,
> 
> Nicolas Ferre
> 
> 
>  drivers/dma/at_hdmac.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index 6e13f26..88cfc61 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -310,8 +310,6 @@ static void atc_complete_all(struct at_dma_chan *atchan)
>  
>   dev_vdbg(chan2dev(>chan_common), "complete all\n");
>  
> - BUG_ON(atc_chan_is_enabled(atchan));
> -
>   /*
>* Submit queued descriptors ASAP, i.e. before we go through
>* the completed ones.
> @@ -368,6 +366,9 @@ static void atc_advance_work(struct at_dma_chan *atchan)
>  {
>   dev_vdbg(chan2dev(>chan_common), "advance_work\n");
>  
> + if (atc_chan_is_enabled(atchan))
> + return;
> +
>   if (list_empty(>active_list) ||
>   list_is_singular(>active_list)) {
>   atc_complete_all(atchan);
> @@ -1078,9 +1079,7 @@ static void atc_issue_pending(struct dma_chan *chan)
>   return;
>  
>   spin_lock_irqsave(>lock, flags);
> - if (!atc_chan_is_enabled(atchan)) {
> - atc_advance_work(atchan);
> - }
> + atc_advance_work(atchan);
>   spin_unlock_irqrestore(>lock, flags);
>  }
>  
> -- 
> 1.8.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 4/4] mfd: SPI interface with AIC platform

[Mehar Bajwa]

Texas Instruments TLV320AIC family of audio SoC
core functionality controlled via SPI. This driver
provides common support for accessing the device.

Signed-off-by: Mehar Bajwa 
---
 drivers/mfd/Kconfig |   11 +
 drivers/mfd/Makefile|1 +
 drivers/mfd/tlv320aic-spi.c |   97 +++
 3 files changed, 109 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/tlv320aic-spi.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 40eb328..b1d6269 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -81,6 +81,17 @@ config MFD_AIC_I2C
  core functionality controlled via I2C. This driver provides common
  support for accessing the device, additional drivers must be enabled
  in order to use the functionality of the device.
+
+config MFD_AIC_SPI
+   bool "AIC SPI Interface"
+   select REGMAP_SPI
+   depends on MFD_AIC
+   depends on SPI_MASTER
+   help
+ Support for the Texas Instruments TLV320AIC family of audio SoC
+ core functionality controlled via SPI.  This driver provides common
+ support for accessing the device, additional drivers must be enabled
+ in order to use the functionality of the device.
 endmenu
 
 config MFD_SM501
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 1e2c96a..dfdcfa2 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_MFD_88PM805)   += 88pm805.o 88pm80x.o
 obj-$(CONFIG_MFD_AIC)  += tlv320aic-core.o
 obj-$(CONFIG_MFD_AIC_IRQ)  += tlv320aic-irq.o
 obj-$(CONFIG_MFD_AIC_I2C)  += tlv320aic-i2c.o
+obj-$(CONFIG_MFD_AIC_SPI)  += tlv320aic-spi.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
 
diff --git a/drivers/mfd/tlv320aic-spi.c b/drivers/mfd/tlv320aic-spi.c
new file mode 100644
index 000..2faeb40
--- /dev/null
+++ b/drivers/mfd/tlv320aic-spi.c
@@ -0,0 +1,97 @@
+/*
+ * tlv320aic-spi.c  -- driver for TLV320AIC
+ *
+ * Author:  Mukund Navada 
+ * Mehar Bajwa 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct regmap_config aic_spi_regmap = {
+   .reg_bits = 7,
+   .val_bits = 8,
+   .cache_type = REGCACHE_NONE,
+   .read_flag_mask = 0x1,
+   .pad_bits = 1,
+};
+
+static int tlv320aic_spi_probe(struct spi_device *spi)
+{
+   const struct spi_device_id *id = spi_get_device_id(spi);
+   struct aic *aic;
+   const struct regmap_config *regmap_config;
+   int ret;
+
+   regmap_config = _spi_regmap;
+
+   aic = devm_kzalloc(>dev, sizeof(struct aic), GFP_KERNEL);
+   if (aic == NULL)
+   return -ENOMEM;
+
+   aic->regmap = devm_regmap_init_spi(spi, regmap_config);
+   if (IS_ERR(aic->regmap)) {
+   ret = PTR_ERR(aic->regmap);
+   dev_err(>dev, "Failed to allocate register map: %d\n",
+   ret);
+   return ret;
+   }
+
+   aic->type = id->driver_data;
+   aic->dev = >dev;
+   aic->irq = spi->irq;
+
+   return aic_device_init(aic);
+}
+
+static int tlv320aic_spi_remove(struct spi_device *spi)
+{
+   struct aic *aic = dev_get_drvdata(>dev);
+   aic_device_exit(aic);
+   return 0;
+}
+
+static const struct spi_device_id aic_spi_ids[] = {
+   {"tlv320aic3262", TLV320AIC3262},
+   { }
+};
+MODULE_DEVICE_TABLE(spi, aic_spi_ids);
+
+static struct spi_driver tlv320aic_spi_driver = {
+   .driver = {
+   .name   = "tlv320aic",
+   .owner  = THIS_MODULE,
+   },
+   .probe  = tlv320aic_spi_probe,
+   .remove = tlv320aic_spi_remove,
+   .id_table   = aic_spi_ids,
+};
+
+module_spi_driver(tlv320aic_spi_driver);
+
+MODULE_DESCRIPTION("TLV320AIC SPI bus interface");
+MODULE_AUTHOR("Mukund Navada ");
+MODULE_AUTHOR("Mehar Bajwa ");
+MODULE_LICENSE("GPL");
-- 
1.7.0.4

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

[PATCH V2 3/4] mfd: I2C interface with AIC platform

[Mehar Bajwa]

Texas Instruments TLV320AIC family of audio SoC
core functionality controlled via I2C. This driver
provides common support for accessing the device.

Signed-off-by: Mehar Bajwa 
---
 drivers/mfd/Kconfig |   12 +
 drivers/mfd/Makefile|1 +
 drivers/mfd/tlv320aic-i2c.c |   98 +++
 3 files changed, 111 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/tlv320aic-i2c.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3019897..40eb328 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -64,11 +64,23 @@ menu "AIC Interface Drivers"
 config MFD_AIC_IRQ
bool "Support of IRQ for AIC"
depends on MFD_AIC
+   default y
help
  Say yes here if you want support of IRQ for Texas Instruments
  AIC codec family.
  You have to select individual components like codec device
  under the corresponding menus.
+
+config MFD_AIC_I2C
+   bool "AIC I2C Interface"
+   select REGMAP_I2C
+   depends on MFD_AIC
+   depends on I2C
+   help
+ Support for the Texas Instruments TLV320AIC family of audio SoC
+ core functionality controlled via I2C. This driver provides common
+ support for accessing the device, additional drivers must be enabled
+ in order to use the functionality of the device.
 endmenu
 
 config MFD_SM501
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 3b39454..1e2c96a 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM800)   += 88pm800.o 88pm80x.o
 obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
 obj-$(CONFIG_MFD_AIC)  += tlv320aic-core.o
 obj-$(CONFIG_MFD_AIC_IRQ)  += tlv320aic-irq.o
+obj-$(CONFIG_MFD_AIC_I2C)  += tlv320aic-i2c.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
 
diff --git a/drivers/mfd/tlv320aic-i2c.c b/drivers/mfd/tlv320aic-i2c.c
new file mode 100644
index 000..18987b1
--- /dev/null
+++ b/drivers/mfd/tlv320aic-i2c.c
@@ -0,0 +1,98 @@
+/*
+ * tlv320aic-i2c.c  -- driver for TLV320AIC Codecs Family
+ *
+ * Author: Mukund Navada 
+ * Mehar Bajwa 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct regmap_config aic_i2c_regmap = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .cache_type = REGCACHE_NONE,
+};
+
+static int aic_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+   struct aic *aic;
+   const struct regmap_config *regmap_config;
+   int ret;
+
+   regmap_config = _i2c_regmap;
+
+   aic = devm_kzalloc(>dev, sizeof(*aic), GFP_KERNEL);
+   if (aic == NULL)
+   return -ENOMEM;
+
+   aic->regmap = devm_regmap_init_i2c(i2c, regmap_config);
+
+   if (IS_ERR(aic->regmap)) {
+   ret = PTR_ERR(aic->regmap);
+   dev_err(>dev, "Failed to allocate register map: %d\n",
+   ret);
+   return ret;
+   }
+
+   aic->type = id->driver_data;
+   aic->dev = >dev;
+   aic->irq = i2c->irq;
+
+   return aic_device_init(aic);
+}
+
+static int aic_i2c_remove(struct i2c_client *i2c)
+{
+   struct aic *aic = dev_get_drvdata(>dev);
+
+   aic_device_exit(aic);
+   return 0;
+}
+
+static const struct i2c_device_id aic_i2c_id[] = {
+   {"tlv320aic3262", TLV320AIC3262},
+   { }
+};
+MODULE_DEVICE_TABLE(i2c, aic_i2c_id);
+
+static struct i2c_driver aic_i2c_driver = {
+   .driver = {
+   .name   = "tlv320aic",
+   .owner  = THIS_MODULE,
+   },
+   .probe  = aic_i2c_probe,
+   .remove = aic_i2c_remove,
+   .id_table   = aic_i2c_id,
+};
+
+module_i2c_driver(aic_i2c_driver);
+
+MODULE_DESCRIPTION("TLV320AIC I2C bus interface");
+MODULE_AUTHOR("Mukund Navada ");
+MODULE_AUTHOR("Mehar Bajwa ");
+MODULE_LICENSE("GPL");
-- 
1.7.0.4

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

[PATCH V2 2/4] mfd: Interrupt handling support for AIC family

[Mehar Bajwa]

This provides Interrupt handling features for common interface
to series of low power AIC audio CODECS.

Signed-off-by: Mehar Bajwa 
---
 drivers/mfd/Kconfig |   13 ++
 drivers/mfd/Makefile|1 +
 drivers/mfd/tlv320aic-irq.c |  234 +++
 include/linux/mfd/tlv320aic-core.h  |   49 ++-
 include/linux/mfd/tlv320aic-registers.h |   57 
 5 files changed, 348 insertions(+), 6 deletions(-)
 create mode 100644 drivers/mfd/tlv320aic-irq.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 629d374..3019897 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -58,6 +58,19 @@ config MFD_AIC
  you have to select individual components like codec device
  to use AIC features.
 
+menu "AIC Interface Drivers"
+   depends on MFD_AIC
+
+config MFD_AIC_IRQ
+   bool "Support of IRQ for AIC"
+   depends on MFD_AIC
+   help
+ Say yes here if you want support of IRQ for Texas Instruments
+ AIC codec family.
+ You have to select individual components like codec device
+ under the corresponding menus.
+endmenu
+
 config MFD_SM501
tristate "Support for Silicon Motion SM501"
 ---help---
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b975c94..3b39454 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_MFD_88PM860X)  += 88pm860x.o
 obj-$(CONFIG_MFD_88PM800)  += 88pm800.o 88pm80x.o
 obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
 obj-$(CONFIG_MFD_AIC)  += tlv320aic-core.o
+obj-$(CONFIG_MFD_AIC_IRQ)  += tlv320aic-irq.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
 
diff --git a/drivers/mfd/tlv320aic-irq.c b/drivers/mfd/tlv320aic-irq.c
new file mode 100644
index 000..e299495
--- /dev/null
+++ b/drivers/mfd/tlv320aic-irq.c
@@ -0,0 +1,234 @@
+/*
+ * tlv320aic-irq.c  --  Interrupt controller support for
+ *  TI TLV320AIC family
+ *
+ * Author:  Mukund Navada 
+ *  Mehar Bajwa 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+struct aic_irq_data {
+   int mask;
+   int status;
+};
+
+static struct aic_irq_data aic_irqs[] = {
+   {
+.mask = AIC_HEADSET_IN_M,
+.status = AIC_HEADSET_PLUG_UNPLUG_INT,
+},
+   {
+.mask = AIC_BUTTON_PRESS_M,
+.status = AIC_BUTTON_PRESS_INT,
+},
+   {
+.mask = AIC_DAC_DRC_THRES_M,
+.status = AIC_LEFT_DRC_THRES_INT | AIC_RIGHT_DRC_THRES_INT,
+},
+   {
+.mask = AIC_AGC_NOISE_M,
+.status = AIC_LEFT_AGC_NOISE_INT | AIC_RIGHT_AGC_NOISE_INT,
+},
+   {
+.mask = AIC_OVER_CURRENT_M,
+.status = AIC_LEFT_OUTPUT_DRIVER_OVERCURRENT_INT
+| AIC_RIGHT_OUTPUT_DRIVER_OVERCURRENT_INT,
+},
+   {
+.mask = AIC_OVERFLOW_M,
+.status =
+AIC_LEFT_DAC_OVERFLOW_INT | AIC_RIGHT_DAC_OVERFLOW_INT |
+AIC_MINIDSP_D_BARREL_SHIFT_OVERFLOW_INT |
+AIC_LEFT_ADC_OVERFLOW_INT | AIC_RIGHT_ADC_OVERFLOW_INT |
+AIC_MINIDSP_D_BARREL_SHIFT_OVERFLOW_INT,
+},
+   {
+.mask = AIC_SPK_OVERCURRENT_M,
+.status = AIC_SPK_OVER_CURRENT_INT,
+},
+
+};
+
+static void aic_irq_lock(struct irq_data *data)
+{
+   struct aic *aic = irq_data_get_irq_chip_data(data);
+
+   mutex_lock(>irq_lock);
+}
+
+static void aic_irq_sync_unlock(struct irq_data *data)
+{
+   struct aic *aic = irq_data_get_irq_chip_data(data);
+
+   /* write back to hardware any change in irq mask */
+   if (aic->irq_masks_cur != aic->irq_masks_cache) {
+   aic->irq_masks_cache = aic->irq_masks_cur;
+   aic_reg_write(aic, AIC_INT1_CNTL,
+ aic->irq_masks_cur);
+   }
+
+   mutex_unlock(>irq_lock);
+}
+
+
+static void aic_irq_enable(struct irq_data *data)
+{
+   struct aic *aic = irq_data_get_irq_chip_data(data);
+   struct aic_irq_data *irq_data = _irqs[data->hwirq];
+   aic->irq_masks_cur |= irq_data->mask;
+}
+
+static void aic_irq_disable(struct irq_data *data)
+{

[PATCH V2 1/4] mfd: Initial support for Texas Instruments AIC family of CODECs

[Mehar Bajwa]

Initial support for Texas Instruments's AIC CODEC device.

The AIC platform provides common interface to series of low power audio CODECS.
This MFD core driver instantiates subdevices that help in supporting range
of features provided by AIC family of devices

Signed-off-by: Mehar Bajwa 
---
 drivers/mfd/Kconfig |   13 +
 drivers/mfd/Makefile|1 +
 drivers/mfd/tlv320aic-core.c|  462 +++
 include/linux/mfd/tlv320aic-core.h  |  112 
 include/linux/mfd/tlv320aic-registers.h |   32 +++
 5 files changed, 620 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/tlv320aic-core.c
 create mode 100644 include/linux/mfd/tlv320aic-core.h
 create mode 100644 include/linux/mfd/tlv320aic-registers.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 671f5b1..629d374 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -45,6 +45,19 @@ config MFD_88PM805
  components like codec device, headset/Mic device under the
  corresponding menus.
 
+config MFD_AIC
+   bool "Support for Texas Instruments TLV320AIC platform"
+   select REGMAP
+   select MFD_CORE
+   help
+ Say yes here if you want support for Texas Instruments AIC audio
+ codec.
+ You have to select individual I2C or SPI depending on
+ AIC interfacing with platform. To enable IRQ handling
+ facilities select IRQ component under corresponding menus.
+ you have to select individual components like codec device
+ to use AIC features.
+
 config MFD_SM501
tristate "Support for Silicon Motion SM501"
 ---help---
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b90409c..b975c94 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
 obj-$(CONFIG_MFD_88PM800)  += 88pm800.o 88pm80x.o
 obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
+obj-$(CONFIG_MFD_AIC)  += tlv320aic-core.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
 
diff --git a/drivers/mfd/tlv320aic-core.c b/drivers/mfd/tlv320aic-core.c
new file mode 100644
index 000..4b8a424
--- /dev/null
+++ b/drivers/mfd/tlv320aic-core.c
@@ -0,0 +1,462 @@
+/*
+ * tlv320aic-core.c  -- driver for TLV320AIC
+ *
+ * Author:  Mukund Navada 
+ *  Mehar Bajwa 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+/**
+ * set_aic_book: change book which we have to write/read to.
+ *
+ * @aic: Device to write/read to.
+ * @book: Book to write/read to.
+ */
+int set_aic_book(struct aic *aic, int book)
+{
+   int ret = 0;
+   u8 page_buf[] = { 0x0, 0x0 };
+   u8 book_buf[] = { 0x7f, 0x0 };
+
+   ret = regmap_write(aic->regmap, page_buf[0], page_buf[1]);
+
+   if (ret < 0)
+   return ret;
+   book_buf[1] = book;
+   ret = regmap_write(aic->regmap, book_buf[0], book_buf[1]);
+
+   if (ret < 0)
+   return ret;
+   aic->book_no = book;
+   aic->page_no = 0;
+
+   return ret;
+}
+
+/**
+ * set_aic_page: change page which we have to write/read to.
+ *
+ * @aic: Device to write/read to.
+ * @page: Book to write/read to.
+ */
+int set_aic_page(struct aic *aic, int page)
+{
+   int ret = 0;
+   u8 page_buf[] = { 0x0, 0x0 };
+
+   page_buf[1] = page;
+   ret = regmap_write(aic->regmap, page_buf[0], page_buf[1]);
+
+   if (ret < 0)
+   return ret;
+   aic->page_no = page;
+   return ret;
+}
+/**
+ * aic_reg_read: Read a single TLV320AIC register.
+ *
+ * @aic: Device to read from.
+ * @reg: Register to read.
+ */
+int aic_reg_read(struct aic *aic, unsigned int reg)
+{
+   unsigned int val;
+   int ret;
+   union aic_reg_union *aic_reg = (union aic_reg_union *) 
+   u8 book, page, offset;
+
+   page = aic_reg->aic_register.page;
+   book = aic_reg->aic_register.book;
+   offset = aic_reg->aic_register.offset;
+
+   mutex_lock(>io_lock);
+   if (aic->book_no != book) {
+   ret = set_aic_book(aic, book);
+   if (ret < 0) 

Re: [PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver

[Guenter Roeck]

On Tue, Apr 16, 2013 at 11:36:33AM +0200, Wolfram Sang wrote:
> Doug,
> 
[ ... ]
> 
> "callenge & response"?
> 
> ...
> 
> > diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c 
> > b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> > new file mode 100644
> > index 000..bda020a
> > --- /dev/null
> > +++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> > @@ -0,0 +1,252 @@
> > +/*
> > + * GPIO-based I2C Arbitration
> 
> "callenge & response"?
> 
s/callenge/challenge/g
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver

[Guenter Roeck]

On Tue, Apr 16, 2013 at 09:17:27AM +, Opensource [Anthony Olech] wrote:
> > -Original Message-
> > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > Sent: 15 April 2013 18:46
> > To: Opensource [Anthony Olech]
> > Cc: LKML
> > Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
> > 
> > On Mon, Apr 15, 2013 at 05:29:13PM +, Opensource [Anthony Olech]
> > wrote:
> > > > -Original Message-
> > > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > > Sent: 15 April 2013 17:36
> > > > To: Opensource [Anthony Olech]
> > > > Cc: LKML
> > > > Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
> > > >
> > > > On Mon, Apr 15, 2013 at 03:00:58PM +, Opensource [Anthony Olech]
> > > > wrote:
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > > > > Sent: 12 April 2013 14:32
> > > > > > To: Opensource [Anthony Olech]
> > > > > > Cc: Mark Brown; Liam Girdwood; Jean Delvare; Randy Dunlap; LKML;
> > > > > > David Dajun Chen
> > > > > > Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
> > > > > >
> > > > > > On Fri, Apr 12, 2013 at 02:05:28PM +0100, Anthony Olech wrote:
> > > > > > > This is the REGULATOR component driver of the Dialog DA9058 PMIC.
> > > > > > > This driver is just one component of the whole DA9058 PMIC driver.
> > > > > > > It depends on the CORE component driver of the DA9058 MFD.
> > > > > > >
> > > > > > > There are 6 warnings from scripts/checkpatch.pl, but since it
> > > > > > > seems to be complaining about variable names such as min_uV
> > > > > > > are in CamelCase, when it is obvious that they are not in
> > > > > > > CamelCase I have
> > > > ignored them.
> > > > > > >
> > > > > > ??? min_uV _is_ CamelCase ???
> > > > > >
> > > > > > Ok, maybe it is camelcasE, but you are splitting hairs here.
> > > > >
> > > > > it is not me splitting hairs, it is scripts/checkpatch.pl
> > > > >
> > > > Maybe you did not understand what I meant. Per your logic,
> > > >
> > > > MicroVolt is CamelCase
> > > > uVolt is ???
> > > > uV is not CamelCase
> > > >
> > > > By abbreviating CamelCase to camelCase to cC you make it, in your
> > > > opinion, acceptable.
> > > >
> > > > If you want to declare CamelCase variables, just do it, but don't
> > > > claim that they are not really CamelCase.
> > > >
> > > > Guenter
> > >
> > > I always thought that camel case meant "changing from lower case to
> > > upper case the first letter of each word and then joining the
> > > capitalized words together", so by that definition uV or mW are not camel
> > case because "v" and "w" are not words!
> 
> The definition of CamelCase From Wikipedia, the free encyclopedia is:
> 
> "CamelCase (camel case) is a term which refers to the practice of writing
> compound words where the first letter of an identifier is lowercase and the
> first letter of each subsequent concatenated word is capitalized."
> 
Maybe the rule should read "don't mix lowercase and uppercase letters in
variable names and defines" to prevent variable names such as cAmelcAse or
cameLcasE, which would be permitted with your logic :).

> > > Either way it seems that the algorithm in scripts/checkpatch.pl is wrong! 
> > > and
> > that was my point.
> >
> > Guess we'll have to agree to disagree here, as I happen to think that
> > checkpatch is perfectly right.
> > Guenter
> 
> Hi Guenter,
> 
> I am quite happy to accept the algorithm in scripts/checkpatch.pl as the
> arbiter for correctly formed linux kernel variable names.
> 
> On that basis "old_mV", "new_uA" etc are incorrectly formed variable names.
> Could you possibly suggest legal alternatives to "mA", "uV", "kW" ??
> 
I just changed it to lowercase in the ntc_thermistor driver. What you use is
really your call as long as it does not mix uppercase and lowercase letters.

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

Re: [PATCH v9] irq: add quirk for broken interrupt remapping on 55XX chipsets

[Neil Horman]

On Tue, Apr 16, 2013 at 12:24:54PM +0200, Joerg Roedel wrote:
> On Mon, Apr 15, 2013 at 06:41:17PM -0400, Neil Horman wrote:
> > +#ifdef CONFIG_IRQ_REMAP
> > +static void __init intel_remapping_check(int num, int slot, int func)
> > +{
> > +   u8 revision;
> > +
> > +   revision = read_pci_config_byte(num, slot, func, PCI_REVISION_ID);
> > +
> > +   /*
> > +* Revision 0x13 of this chipset supports irq remapping
> > +* but has an erratum that breaks its behavior, flag it as such
> > +*/
> > +   if (revision == 0x13)
> > +   irq_remap_broken = 1;
> > +
> > +}
> > +#else
> 
> Any reason why you don't check this in the Intel IOMMU init code? You
> would safe the ifdefs and you don't have to include
> irq-remapping-internal header files somewhere else in the tree.
> 
> 
>   Joerg
> 
> 
> 
Actually, hold on that last note, the intel iommu init code doesn't seem to
create any direct relationship between the set of iommu's and the pci_dev's that
implement them.  In the intel_irq_remapping_supported path I can loop over each
dmar_dhrd_unit, and interrogate each of the devices on its **devices list to see
if the device/vendor and revision ids match, but looking at the dhrd parsing
code, I'm not sure the iommu pci_dev is always going to be on that list.  That
seems like its going to be pretty ugly in and of itself.  Do you have a
suggested way to identify the pci_dev of the device we need in that path without
having to simply iterate over every device in that scope?

Neil

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ptrace/x86: dont delay perf_event_disable() till second pass in ptrace_write_dr7()

[Oleg Nesterov]

On 04/16, Frederic Weisbecker wrote:
>
> On Sun, Apr 14, 2013 at 09:12:32PM +0200, Oleg Nesterov wrote:
> > ptrace_write_dr7() skips ptrace_modify_breakpoint(disabled => true)
> > unless second_pass, this buys nothing but complicates the code and
> > means that we always do the main loop twice even if "disabled" was
> > never true.
> >
> > The comment says:
> >
> > Don't unregister the breakpoints right-away,
> > unless all register_user_hw_breakpoint()
> > requests have succeeded.
> >
> > I think this logic was always wrong, hw_breakpoint_del() does not
> > free the slot so perf_event_disable() can't hurt.
>
> For the record, I think it was necessary before
> 44234adcdce38f83c56e05f808ce656175b4beeb
> ("hw-breakpoints: Modify breakpoints without unregistering them") because
> modifying a breakpoint implied that the old bp was released and a new one
> was created, opening a little race window in between against concurrent
> breakpoint users.

Aah, thank, I'll update the changelog.

> Acked-by: Frederic Weisbecker 

Thanks!

> > old_dr7 = ptrace_get_dr7(thread->ptrace_bps);
> > @@ -651,35 +643,31 @@ restore:
> > bool disabled = !decode_dr7(data, i, , );
> > struct perf_event *bp = thread->ptrace_bps[i];
> >
> > -   if (disabled) {
> > +   if (!bp) {
> > +   if (disabled)
> > +   continue;
> > /*
> > -* Don't unregister the breakpoints right-away, unless
> > -* all register_user_hw_breakpoint() requests have
> > -* succeeded. This prevents any window of opportunity
> > -* for debug register grabbing by other users.
> > +* We should have at least an inactive breakpoint at
> > +* this slot. It means the user is writing dr7 without
> > +* having written the address register first.
> >  */
> > -   if (!bp || !second_pass)
> > -   continue;
> > +   rc = -EINVAL;
> > +   break;
> > }
> >
> > rc = ptrace_modify_breakpoint(bp, len, type, tsk, disabled);
> > if (rc)
> > break;
>
> It would be nice to warn here:
>
>WARN_ON_ONCE(rc && second_pass);

Well, I disagree.

To clarify, I agree with WARN_ON_ONCE(), but afaics it has nothing to
do with "second_pass",

> And these are indeed supposed
> to.

Indeed, but this is because ptrace_modify_breakpoint() should not fail.

So, what do you think if I change the main loop above

rc = ptrace_modify_breakpoint(...)
-   if (rc)
+   if (WARN_ON_ONCE(rc))
break;

instead?

Oleg.

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

Re: [PATCH 0/2] ptrace/x86: simplify ptrace_write_dr7()

[Oleg Nesterov]

On 04/16, Frederic Weisbecker wrote:
>
> On Sun, Apr 14, 2013 at 09:12:05PM +0200, Oleg Nesterov wrote:
>
> Looking at the bug report, it seems they only reproduced with a homemade
> test. No real app has reported that issue?

iirc (Jan can correct me) gdb hit this problem, but it was already
changed to change DR0 first.

> > Jan, Frederic, et all. What do you think we should do?
> >
> > 1. Change ptrace_write_dr7() to do register_user_hw_breakpoint()
> >if necessary.
> >
> >This is what I was going to do, but I am no longer sure
> >we want this. For what? Unlikely it is very useful to use
> >the "default" addr == 0 for debugging.
>
> So you mean assume that the addr is 0 in dr[0-3] if we write dr7 before 
> writing
> the addr register?

Yes,

> Yes, I'm convinced that's the right direction!

OK. Thanks Jan and Frederic.

I'll send v2 tomorrow with the 3rd patch which adds _register into
write_dr7. Plus another minor/offtopic fix I forgot to send.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:smp/hotplug] idle: Implement generic idle function

[Thomas Gleixner]

On Mon, 15 Apr 2013, Tony Luck wrote:

> Built next-20130415 and got this on ia64 early in boot:
> 
> WARNING: at kernel/cpu/idle.c:94 cpu_idle_loop+0x360/0x380()

Hmm, is safe_halt() returning with interrupts disabled? If yes, it
lacks a local_irq_enable().

Thanks,

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

Re: [PATCH 6/6] x86: kaslr: relocate base offset at boot

[H. Peter Anvin]

Well... G is it's own problem (doing actively broken thinks for political 
reasons), but the real issue mostly is that there are a lot of them simply 
because there are a lot of ways one may want to load the kernel.

This is why things like decompression and the BIOS and EFI stubs are part of 
the kernel and not the bootloader.  In this case moving the randomization into 
the decompressor send like the right thing to do - C code, and no additional 
copy.

Ingo Molnar  wrote:

>
>* H. Peter Anvin  wrote:
>
>> No.  Fixing one bootloader is almost impossible.  Fixing them all is
>a 
>> Sisiphyean task.
>
>It's a self inflicted wound really: if only we had a reference
>bootloader in the 
>kernel tree, which we could fix. The effort that went into fixing
>various 
>bootloader interactions would have been enough to write two new
>bootloaders from 
>scratch.
>
>Thanks,
>
>   Ingo

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

Re: [PATCH 0/3 v2] mutex: Improve mutex performance by doing less atomic-ops & better spinning

[Ingo Molnar]

* Waiman Long  wrote:

> On 04/16/2013 05:12 AM, Ingo Molnar wrote:
> >* Waiman Long  wrote:
> >
> >>[...]
> >>
> >>Patches 2 improves the mutex spinning process by reducing contention among 
> >>the
> >>spinners when competing for the mutex. This is done by using a MCS lock to 
> >>put
> >>the spinners in a queue so that only the first spinner will try to acquire 
> >>the
> >>mutex when it is available. This patch showed significant performance
> >>improvement of +30% on the AIM7 fserver and new_fserver workload.
> >Ok, that's really nice - and this approach has no arbitrary limits/tunings 
> >in it.
> >
> >Do you have a performance comparison to your first series (patches 1+2+3 
> >IIRC) -
> >how does this new series with MCS locking compare to the best previous 
> >result from
> >that old series? Do we now achieve that level of performance?
> 
> Compared with the old patch set, the new patches 1+2 have over 30%
> performance gain in high user load (1100-1500) in the fserver and
> new_fserver workloads. The old patches 1+2 or 1+3 only manages
> around 10% gain. In the intermediate range of 200-1000, the 2 sets
> are more comparable in performance gain.

Ok, that's cool!

Thanks,

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

Re: [PATCH 6/6] x86: kaslr: relocate base offset at boot

[Ingo Molnar]

* H. Peter Anvin  wrote:

> No.  Fixing one bootloader is almost impossible.  Fixing them all is a 
> Sisiphyean task.

It's a self inflicted wound really: if only we had a reference bootloader in 
the 
kernel tree, which we could fix. The effort that went into fixing various 
bootloader interactions would have been enough to write two new bootloaders 
from 
scratch.

Thanks,

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

Re: [PATCH v9] irq: add quirk for broken interrupt remapping on 55XX chipsets

[Neil Horman]

On Tue, Apr 16, 2013 at 12:24:54PM +0200, Joerg Roedel wrote:
> On Mon, Apr 15, 2013 at 06:41:17PM -0400, Neil Horman wrote:
> > +#ifdef CONFIG_IRQ_REMAP
> > +static void __init intel_remapping_check(int num, int slot, int func)
> > +{
> > +   u8 revision;
> > +
> > +   revision = read_pci_config_byte(num, slot, func, PCI_REVISION_ID);
> > +
> > +   /*
> > +* Revision 0x13 of this chipset supports irq remapping
> > +* but has an erratum that breaks its behavior, flag it as such
> > +*/
> > +   if (revision == 0x13)
> > +   irq_remap_broken = 1;
> > +
> > +}
> > +#else
> 
> Any reason why you don't check this in the Intel IOMMU init code? You
> would safe the ifdefs and you don't have to include
> irq-remapping-internal header files somewhere else in the tree.
> 
> 
>   Joerg
> 
Mostly because we've spent so much time early in this thread talking about where
the quirk should go, that after this last revision, it didn't even occur to me
that, using this new approach, we don't even need a quirk anymore.  That makes
way more sense to me though, I'll revise the patch again :(.

Neil

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: mmu_notifier: re-fix freed page still mapped in secondary MMU

[Xiao Guangrong]

On 04/16/2013 07:43 PM, Robin Holt wrote:
> Argh.  Taking a step back helped clear my head.
> 
> For the -stable releases, I agree we should just go with your
> revert-plus-hlist_del_init_rcu patch.  I will give it a test
> when I am in the office.

Okay. Wait for your test report. Thank you in advance.

> 
> For the v3.10 release, we should work on making this more
> correct and completely documented.

Better document is always welcomed.

Double call ->release is not bad, like i mentioned it in the changelog:

it is really rare (e.g, can not happen on kvm since mmu-notify is unregistered
after exit_mmap()) and the later call of multiple ->release should be
fast since all the pages have already been released by the first call.

But, of course, it's great if you have a _light_ way to avoid this.

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

Re: [RFC PATCH 1/3] pstore-ram: use write-combine mappings

[Rob Herring]

On 04/16/2013 03:44 AM, Will Deacon wrote:
> On Tue, Apr 16, 2013 at 01:43:09AM +0100, Colin Cross wrote:
>> On Mon, Apr 15, 2013 at 4:59 PM, Rob Herring  wrote:
>>> Exclusive accesses still have further restrictions. From section 3.4.5:
>>>
>>> • It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be
>>> performed to a memory region
>>>with the Device or Strongly-ordered memory attribute. Unless the
>>> implementation documentation explicitly
>>>   states that LDREX and STREX operations to a memory region with the
>>> Device or Strongly-ordered attribute are
>>>  permitted, the effect of such operations is UNPREDICTABLE.
>>>
>>>
>>> Given that it is implementation defined, I don't see how Linux can rely
>>> on that behavior.
>>
>> I see, the problem is that while noncached and writecombined appear to
>> be similar mappings, noncached is mapped in PRRR to strongly-ordered,
>> while writecombined is mapped to unbufferable normal memory.
>>
>> I think adding a wmb() to persistent_ram_write is going to be
>> expensive on cpus with outer caches like the L2X0, where wmb() will
>> result in a spinlock.  Is there a real SoC where this doesn't work?
> 
> A real SoC where exclusives don't work to memory not mapped as normal? Take
> your pick...

This patch doesn't actually fix problems for me. Exclusives to DDR work
for any memory type for me as the DDR controller has an exclusive
monitor. It takes write-thru cache mapping to get internal RAM to work.

Rob

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

[PATCH 0/5] powerpc, perf: BHRB based branch stack enablement on POWER8

[Anshuman Khandual]

Branch History Rolling Buffer (BHRB) is a new PMU feaure in IBM
POWER8 processor which records the branch instructions inside the execution
pipeline. This patchset enables the basic functionality of the feature through
generic perf branch stack sampling framework.

Sample output
-
$./perf record -b top
$./perf report

Overhead  Command  Source Shared Object   Source Symbol 
 Target Shared ObjectTarget Symbol
#   ...    
..    
...
#

 7.82%  top  libc-2.11.2.so[k] _IO_vfscanf  
   libc-2.11.2.so[k] _IO_vfscanf
 6.17%  top  libc-2.11.2.so[k] _IO_vfscanf  
   [unknown] [k]    
 2.37%  top  [unknown] [k] 0xf7aafb30   
   [unknown] [k]    
 1.80%  top  [unknown] [k] 0x0fe07978   
   libc-2.11.2.so[k] _IO_vfscanf
 1.60%  top  libc-2.11.2.so[k] _IO_vfscanf  
   [kernel.kallsyms] [k] .do_task_stat  
 1.20%  top  [kernel.kallsyms] [k] .do_task_stat
   [kernel.kallsyms] [k] .do_task_stat  
 1.02%  top  libc-2.11.2.so[k] vfprintf 
   libc-2.11.2.so[k] vfprintf   
 0.92%  top  top   [k] _init
   [unknown] [k] 0x0fe037f4 

Anshuman Khandual (5):
  powerpc, perf: Add new BHRB related instructions on POWER8
  powerpc, perf: Add basic assembly code to read BHRB entries on POWER8
  powerpc, perf: Add new BHRB related generic functions, data and flags
  powerpc, perf: Define BHRB generic functions, data and flags for POWER8
  powerpc, perf: Enable branch stack sampling framework support with BHRB

 arch/powerpc/include/asm/perf_event_server.h |  6 ++
 arch/powerpc/include/asm/ppc-opcode.h|  7 ++
 arch/powerpc/perf/Makefile   |  2 +-
 arch/powerpc/perf/bhrb.S | 34 ++
 arch/powerpc/perf/core-book3s.c  | 96 +++-
 arch/powerpc/perf/perf_event_bhrb.c  | 75 ++
 arch/powerpc/perf/power8-pmu.c   | 57 -
 7 files changed, 272 insertions(+), 5 deletions(-)
 create mode 100644 arch/powerpc/perf/bhrb.S
 create mode 100644 arch/powerpc/perf/perf_event_bhrb.c

-- 
1.7.11.7

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

[PATCH 1/5] powerpc, perf: Add new BHRB related instructions on POWER8

[Anshuman Khandual]

This patch adds new instructions support for reading various
BHRB entries and also clearing the BHRB buffer.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/include/asm/ppc-opcode.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
b/arch/powerpc/include/asm/ppc-opcode.h
index 8752bc8..93ae5a1 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -82,6 +82,7 @@
 #define__REGA0_R31 31
 
 /* sorted alphabetically */
+#define PPC_INST_BHRBE 0x7c00025c
 #define PPC_INST_DCBA  0x7c0005ec
 #define PPC_INST_DCBA_MASK 0xfc0007fe
 #define PPC_INST_DCBAL 0x7c2005ec
@@ -297,6 +298,12 @@
 #define PPC_NAPstringify_in_c(.long PPC_INST_NAP)
 #define PPC_SLEEP  stringify_in_c(.long PPC_INST_SLEEP)
 
+/* BHRB instructions */
+#define PPC_CLRBHRBstringify_in_c(.long 0x7c00035c)
+#define PPC_MFBHRBE(r, n)  stringify_in_c(.long PPC_INST_BHRBE | \
+   __PPC_RS(r) | \
+   (((n) & 0x1f) << 11))
+
 /* Transactional memory instructions */
 #define TRECHKPT   stringify_in_c(.long PPC_INST_TRECHKPT)
 #define TRECLAIM(r)stringify_in_c(.long PPC_INST_TRECLAIM \
-- 
1.7.11.7

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

[PATCH 2/5] powerpc, perf: Add basic assembly code to read BHRB entries on POWER8

[Anshuman Khandual]

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/perf/Makefile |  2 +-
 arch/powerpc/perf/bhrb.S   | 34 ++
 2 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/perf/bhrb.S

diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index 472db18..510fae1 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -2,7 +2,7 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
 
 obj-$(CONFIG_PERF_EVENTS)  += callchain.o
 
-obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o
+obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o bhrb.o
 obj64-$(CONFIG_PPC_PERF_CTRS)  += power4-pmu.o ppc970-pmu.o power5-pmu.o \
   power5+-pmu.o power6-pmu.o power7-pmu.o \
   power8-pmu.o
diff --git a/arch/powerpc/perf/bhrb.S b/arch/powerpc/perf/bhrb.S
new file mode 100644
index 000..cffb815
--- /dev/null
+++ b/arch/powerpc/perf/bhrb.S
@@ -0,0 +1,34 @@
+#include 
+#include 
+
+   .text
+
+.balign 8
+
+/* r3 = n  (where n = [0-1023])
+ * The maximum number of BHRB entries supported with PPC_MFBHRBE instruction
+ * is 1024. We have limited number of table entries here as POWER8 implements
+ * 32 BHRB entries.
+ */
+
+/* .global read_bhrb */
+_GLOBAL(read_bhrb)
+   cmpldi  r3,1023
+   bgt 1f
+   ld  r4,bhrb_table@got(r2)
+   sldir3,r3,3
+   add r3,r4,r3
+   mtctr   r3
+   bctr
+1: li  r3,0
+   blr
+
+#define MFBHRB_TABLE1(n) PPC_MFBHRBE(R3,n); blr
+#define MFBHRB_TABLE2(n) MFBHRB_TABLE1(n); MFBHRB_TABLE1(n+1)
+#define MFBHRB_TABLE4(n) MFBHRB_TABLE2(n); MFBHRB_TABLE2(n+2)
+#define MFBHRB_TABLE8(n) MFBHRB_TABLE4(n); MFBHRB_TABLE4(n+4)
+#define MFBHRB_TABLE16(n) MFBHRB_TABLE8(n); MFBHRB_TABLE8(n+8)
+#define MFBHRB_TABLE32(n) MFBHRB_TABLE16(n); MFBHRB_TABLE16(n+16)
+
+bhrb_table:
+   MFBHRB_TABLE32(0)
-- 
1.7.11.7

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

[PATCH 5/5] powerpc, perf: Enable branch stack sampling framework support with BHRB

[Anshuman Khandual]

This patch provides basic enablement for perf branch stack sampling framework
on POWER8 processor with a new PMU feature called BHRB (Branch History Rolling
Buffer).

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/perf/core-book3s.c | 96 +++--
 arch/powerpc/perf/perf_event_bhrb.c | 75 +
 2 files changed, 168 insertions(+), 3 deletions(-)
 create mode 100644 arch/powerpc/perf/perf_event_bhrb.c

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 4ac6e64..f4d1347 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 
+#define BHRB_MAX_ENTRIES   32
+
 struct cpu_hw_events {
int n_events;
int n_percpu;
@@ -38,11 +40,21 @@ struct cpu_hw_events {
 
unsigned int group_flag;
int n_txn_start;
+
+   /* BHRB bits */
+   u64 bhrb_filter;/* BHRB HW branch 
filter */
+   int bhrb_users;
+   void*bhrb_context;
+   struct  perf_branch_stack   bhrb_stack;
+   struct  perf_branch_entry   bhrb_entries[BHRB_MAX_ENTRIES];
 };
+
 DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
 
 struct power_pmu *ppmu;
 
+#include "perf_event_bhrb.c"
+
 /*
  * Normally, to ignore kernel events we set the FCS (freeze counters
  * in supervisor mode) bit in MMCR0, but if the kernel runs with the
@@ -858,6 +870,9 @@ static void power_pmu_enable(struct pmu *pmu)
}
 
  out:
+   if (cpuhw->bhrb_users)
+   ppmu->config_bhrb(cpuhw->bhrb_filter);
+
local_irq_restore(flags);
 }
 
@@ -888,6 +903,47 @@ static int collect_events(struct perf_event *group, int 
max_count,
return n;
 }
 
+/* Reset all possible BHRB entries */
+static void power_pmu_bhrb_reset(void)
+{
+   asm volatile(PPC_CLRBHRB);
+}
+
+void power_pmu_bhrb_enable(struct perf_event *event)
+{
+   struct cpu_hw_events *cpuhw = &__get_cpu_var(cpu_hw_events);
+
+   if (!ppmu->bhrb_nr)
+   return;
+
+   /* Clear BHRB if we changed task context to avoid data leaks */
+   if (event->ctx->task && cpuhw->bhrb_context != event->ctx) {
+   power_pmu_bhrb_reset();
+   cpuhw->bhrb_context = event->ctx;
+   }
+   cpuhw->bhrb_users++;
+}
+
+void power_pmu_bhrb_disable(struct perf_event *event)
+{
+   struct cpu_hw_events *cpuhw = &__get_cpu_var(cpu_hw_events);
+
+   if (!ppmu->bhrb_nr)
+   return;
+
+   cpuhw->bhrb_users--;
+   WARN_ON_ONCE(cpuhw->bhrb_users < 0);
+
+   if (!cpuhw->disabled && !cpuhw->bhrb_users) {
+   /* BHRB cannot be turned off when other
+* events are active on the PMU.
+*/
+
+   /* avoid stale pointer */
+   cpuhw->bhrb_context = NULL;
+   }
+}
+
 /*
  * Add a event to the PMU.
  * If all events are not already frozen, then we disable and
@@ -947,6 +1003,9 @@ nocheck:
 
ret = 0;
  out:
+   if (has_branch_stack(event))
+   power_pmu_bhrb_enable(event);
+
perf_pmu_enable(event->pmu);
local_irq_restore(flags);
return ret;
@@ -999,6 +1058,9 @@ static void power_pmu_del(struct perf_event *event, int 
ef_flags)
cpuhw->mmcr[0] &= ~(MMCR0_PMXE | MMCR0_FCECE);
}
 
+   if (has_branch_stack(event))
+   power_pmu_bhrb_disable(event);
+
perf_pmu_enable(event->pmu);
local_irq_restore(flags);
 }
@@ -1117,6 +1179,15 @@ int power_pmu_commit_txn(struct pmu *pmu)
return 0;
 }
 
+/* Called from ctxsw to prevent one process's branch entries to
+ * mingle with the other process's entries during context switch.
+ */
+void power_pmu_flush_branch_stack(void)
+{
+   if (ppmu->bhrb_nr)
+   power_pmu_bhrb_reset();
+}
+
 /*
  * Return 1 if we might be able to put event on a limited PMC,
  * or 0 if not.
@@ -1231,9 +1302,11 @@ static int power_pmu_event_init(struct perf_event *event)
if (!ppmu)
return -ENOENT;
 
-   /* does not support taken branch sampling */
-   if (has_branch_stack(event))
-   return -EOPNOTSUPP;
+   if (has_branch_stack(event)) {
+   /* PMU has BHRB enabled */
+   if (!(ppmu->flags & PPMU_BHRB))
+   return -EOPNOTSUPP;
+   }
 
switch (event->attr.type) {
case PERF_TYPE_HARDWARE:
@@ -1314,6 +1387,15 @@ static int power_pmu_event_init(struct perf_event *event)
 
cpuhw = _cpu_var(cpu_hw_events);
err = power_check_constraints(cpuhw, events, cflags, n + 1);
+
+   if (has_branch_stack(event)) {
+   cpuhw->bhrb_filter = ppmu->bhrb_filter_map(
+   event->attr.branch_sample_type);
+
+   if(cpuhw->bhrb_filter == -1)
+   return 

[PATCH 4/5] powerpc, perf: Define BHRB generic functions, data and flags for POWER8

[Anshuman Khandual]

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/perf/power8-pmu.c | 57 +-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 106ae0b..153408c 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -109,6 +109,16 @@
 #define EVENT_IS_MARKED(EVENT_MARKED_MASK << 
EVENT_MARKED_SHIFT)
 #define EVENT_PSEL_MASK0xff/* PMCxSEL value */
 
+/* MMCRA IFM bits - POWER8 */
+#definePOWER8_MMCRA_IFM1   0x4000UL
+#definePOWER8_MMCRA_IFM2   0x8000UL
+#definePOWER8_MMCRA_IFM3   0xC000UL
+
+#define ONLY_PLM \
+   (PERF_SAMPLE_BRANCH_USER|\
+PERF_SAMPLE_BRANCH_KERNEL  |\
+PERF_SAMPLE_BRANCH_HV)
+
 /*
  * Layout of constraint bits:
  *
@@ -428,6 +438,48 @@ static int power8_generic_events[] = {
[PERF_COUNT_HW_BRANCH_MISSES] = PM_BR_MPRED_CMPL,
 };
 
+static u64 power8_bhrb_filter_map(u64 branch_sample_type)
+{
+   u64 pmu_bhrb_filter = 0;
+   u64 br_privilege = branch_sample_type & ONLY_PLM;
+
+   /* BHRB and regular PMU events share the same prvillege state
+* filter configuration. BHRB is always recorded along with a
+* regular PMU event. So privilege state filter criteria for BHRB
+* and the companion PMU events has to be the same. As a default
+* "perf record" tool sets all privillege bits ON when no filter
+* criteria is provided in the command line. So as along as all
+* privillege bits are ON or they are OFF, we are good to go.
+*/
+   if ((br_privilege != 7) && (br_privilege != 0))
+   return -1;
+
+   /* No branch filter requested */
+   if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY)
+   return pmu_bhrb_filter;
+
+   /* Invalid branch filter options - HW does not support */
+   if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY_RETURN)
+   return -1;
+
+   if (branch_sample_type & PERF_SAMPLE_BRANCH_IND_CALL)
+   return -1;
+
+   if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY_CALL) {
+   pmu_bhrb_filter |= POWER8_MMCRA_IFM1;
+   return pmu_bhrb_filter;
+   }
+
+   /* Every thing else is unsupported */
+   return -1;
+}
+
+static void power8_config_bhrb(u64 pmu_bhrb_filter)
+{
+   /* Enable BHRB filter in PMU */
+   mtspr(SPRN_MMCRA, (mfspr(SPRN_MMCRA) | pmu_bhrb_filter));
+}
+
 static struct power_pmu power8_pmu = {
.name   = "POWER8",
.n_counter  = 6,
@@ -435,12 +487,15 @@ static struct power_pmu power8_pmu = {
.add_fields = POWER8_ADD_FIELDS,
.test_adder = POWER8_TEST_ADDER,
.compute_mmcr   = power8_compute_mmcr,
+   .config_bhrb= power8_config_bhrb,
+   .bhrb_filter_map= power8_bhrb_filter_map,
.get_constraint = power8_get_constraint,
.disable_pmc= power8_disable_pmc,
-   .flags  = PPMU_HAS_SSLOT | PPMU_HAS_SIER,
+   .flags  = PPMU_HAS_SSLOT | PPMU_HAS_SIER | PPMU_BHRB,
.n_generic  = ARRAY_SIZE(power8_generic_events),
.generic_events = power8_generic_events,
.attr_groups= power8_pmu_attr_groups,
+   .bhrb_nr= 32,
 };
 
 static int __init init_power8_pmu(void)
-- 
1.7.11.7

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

[PATCH 3/5] powerpc, perf: Add new BHRB related generic functions, data and flags

[Anshuman Khandual]

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/include/asm/perf_event_server.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/include/asm/perf_event_server.h 
b/arch/powerpc/include/asm/perf_event_server.h
index 57b42da..3f0c15c 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -33,6 +33,8 @@ struct power_pmu {
unsigned long *valp);
int (*get_alternatives)(u64 event_id, unsigned int flags,
u64 alt[]);
+   u64 (*bhrb_filter_map)(u64 branch_sample_type);
+   void(*config_bhrb)(u64 pmu_bhrb_filter);
void(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
int (*limited_pmc_event)(u64 event_id);
u32 flags;
@@ -42,6 +44,9 @@ struct power_pmu {
int (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
   [PERF_COUNT_HW_CACHE_OP_MAX]
   [PERF_COUNT_HW_CACHE_RESULT_MAX];
+
+   /* BHRB entries in the PMU */
+   int bhrb_nr;
 };
 
 /*
@@ -54,6 +59,7 @@ struct power_pmu {
 #define PPMU_SIAR_VALID0x0010 /* Processor has SIAR Valid 
bit */
 #define PPMU_HAS_SSLOT 0x0020 /* Has sampled slot in MMCRA */
 #define PPMU_HAS_SIER  0x0040 /* Has SIER */
+#define PPMU_BHRB  0x0080 /* has BHRB feature enabled */
 
 /*
  * Values for flags to get_alternatives()
-- 
1.7.11.7

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

[Luis Henriques]

Hi Daniel,

On Sat, Apr 13, 2013 at 11:01:24AM -0700, D M German wrote:
>  vinod> 
>  vinod> 
>  vinod> 
>  vinod> On Fri, 2013-04-12 at 13:22 -0700, D M German wrote:
>  vinod> > Hi Everybody,
>  vinod> > 
>  vinod> > I am professor of computer science at the University of Victoria
>  vinod> > (Canada).
>  vinod> > 
>  vinod> > During the last year and a half, we have been trying to track the
>  vinod> > commits as they move in the entire linux git repos ecosystem. We 
> have
>  vinod> > amassed a good amount of data that tell us for every commit (and in 
> fact
>  vinod> > for every unique patch inside a commit) where it has been and 
> whether it
>  vinod> > has reached linus or not ---or any other repository, as a matter of
>  vinod> > fact.
>  vinod> i see some of the commits shown not in linus tree, although they 
> are...
>  vinod> perhaps a bug?
>  vinod> 
> http://o.cs.uvic.ca:20810/perl/cid.pl?cid=765024697807ad1e1cac332aa891253ca4a339da
>  vinod> 
>  vinod> It shows the same for linus's merge!
>  vinod> 
> http://o.cs.uvic.ca:20810/perl/cid.pl?cid=cfb63bafdb87bbcdc5d6dbbca623d3f69475f118
>  
> Hi Vinod,
> 
> the tracking of the path-to-linus is something that is not done
> automatically yet (I have to start the process manually, as there are
> some issues I need to verify--it is a heuristic), but I plan to run it
> automatically.
> 
> Nonetheless, it might be run once a day, so the commits of the day will
> always be slightly behind.
> 
> One thing that will help me is that if any of you feel I am not tracking
> your repository, please send me an email with its address.

While looking at the repos list, I realised you are tracking some ubuntu
git trees that are not actually useful, namely:

git://kernel.ubuntu.com/roc/linux-2.6
git://kernel.ubuntu.com/rtg/net-next

I would like to ask if you could remove these two and add instead the
linux-3.5.y branch in the git://kernel.ubuntu.com/ubuntu/linux.git repo
(I'm not sure if you track the branches separately).

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

Re: [PATCH/RFC 3/6] DMA: shdma: add DT support

[Arnd Bergmann]

On Monday 15 April 2013 23:34:57 Guennadi Liakhovetski wrote:
> 
> > 
> > This patch is missing the DT binding document, which is necessary for a 
> > proper
> > review, and as a documentation for anyone trying to write device tree source
> > files.
> 
> The documentation was left off consciously, because this driver isn't 
> using any non-standard DMA DT bindings, only those, already described in 
> Documentation/devicetree/bindings/dma/dma.txt.
>
> > In particular, it is not clear what mid/rid refer to here and whether they 
> > should
> > be represented as one or two cells. The driver here uses one cell, which is 
> > probably
> > ok, but I'd like to understand that anyway.
> 
> Yes, mid/rid is a kind of a DMA request line number on these controllers, 
> IIUC. It does have some internal hardware meaning, so, it's not a plane 
> index, but for a high-level view it's just an 8-bit DMA request ID.

Ok, this needs to be in the binding then.

You have to at least describe the meaning of the dma descriptor, because
the generic binding only defines that the descriptor contains a phandle of the
dma engine device, followed by a hardware specific number of cells to identify
a channel. The description of the device itself should mention the valid
strings for the "compatible" property and the required value of #dma-cells 
(<1>).

> > > > + * NOTE 2: This filter function is also used in the DT case by 
> > > > shdma_xlate().
> > > > + * In that case the MID-RID value is used for slave channel filtering 
> > > > and is
> > > > + * passed to this function in the "arg" parameter.
> > > >   */
> > > >  bool shdma_chan_filter(struct dma_chan *chan, void *arg)
> > > >  {
> > > >   struct shdma_chan *schan = to_shdma_chan(chan);
> > > >   struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> > > >   const struct shdma_ops *ops = sdev->ops;
> > > > - int slave_id = (int)arg;
> > > > + int match = (int)arg;
> > > >   int ret;
> > > >  
> > > > - if (slave_id < 0)
> > > > + if (match < 0)
> > > >   /* No slave requested - arbitrary channel */
> > > >   return true;
> > > >  
> > > > - if (slave_id >= slave_num)
> > > > + if (!schan->dev->of_node && match >= slave_num)
> > > >   return false;
> > > >  
> > > > - ret = ops->set_slave(schan, slave_id, true);
> > > > + ret = ops->set_slave(schan, match, true);
> > > >   if (ret < 0)
> > > >   return false;
> > 
> > The filter function should really ensure that the dma_chan.device matches
> > the device passed as the argument before accessing any members of
> > the outer structures. This seems to be a preexisting bug.
> 
> Also this I wouldn't necessarily call a bug, but a pre-existing and known 
> limitation  So far no platform, using such DMA controllers, has DMA 
> controllers, driven by different dmaengine drivers, so, no confusion is 
> possible, since those request line IDs are unique across SoCs. If in the 
> future need arises, this limitation can certainly be lifted.

I think it's a bit dangerous to rely on this. There are PCI add-on cards
with general-purpose DMA engines on them, so all it takes to make this
a real bug is a system with a PCI slot.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] Make reboot_cpuid a kernel parameter. other cpus.

[Robin Holt]

On Tue, Apr 16, 2013 at 05:05:45AM -0700, H. Peter Anvin wrote:
> Why not just support the existing syntax everywhere?

I have not given it much consideration, but IIRC, the other arches that
were using reboot= were only looking for an 'h' or something like that.

I will consider making the syntax parse reboot=s when I get to
the office.

Robin
> 
> Robin Holt  wrote:
> 
> >Moving the reboot=s<##> parameter for x86 to a kernel parameter
> >proper.  I did not find any other arch that was specifying the
> >reboot cpu.
> >
> >I left a compatibility mode in there.  The new parameter always
> >takes precedence.  I also fixed up the current code to support
> >up to cpuid's up to the current max of 4096.
> >
> >Signed-off-by: Robin Holt 
> >To: Ingo Molnar 
> >To: Russ Anderson 
> >Cc: Shawn Guo 
> >Cc: Oleg Nesterov 
> >Cc: Andrew Morton 
> >Cc: "H. Peter Anvin" 
> >Cc: Lai Jiangshan 
> >Cc: Linus Torvalds 
> >Cc: Linux Kernel Mailing List 
> >Cc: Michel Lespinasse 
> >Cc: Oleg Nesterov 
> >Cc: "Paul E. McKenney" 
> >Cc: Paul Mackerras 
> >Cc: Peter Zijlstra 
> >Cc: Robin Holt 
> >Cc: "ru...@rustcorp.com.au" 
> >Cc: Tejun Heo 
> >Cc: the arch/x86 maintainers 
> >Cc: Thomas Gleixner 
> >
> >---
> >
> >Changes since -v3
> >- Added a reboot=s compatibility mode for x86.
> >
> > Documentation/kernel-parameters.txt |  2 ++
> >arch/x86/kernel/reboot.c| 39
> >+
> > kernel/reboot.c |  8 +++-
> > 3 files changed, 22 insertions(+), 27 deletions(-)
> >
> >diff --git a/Documentation/kernel-parameters.txt
> >b/Documentation/kernel-parameters.txt
> >index 4609e81..11ebb48 100644
> >--- a/Documentation/kernel-parameters.txt
> >+++ b/Documentation/kernel-parameters.txt
> >@@ -2597,6 +2597,8 @@ bytes respectively. Such letter suffixes can also
> >be entirely omitted.
> > Format: [,[,...]]
> > See arch/*/kernel/reboot.c or arch/*/kernel/process.c
> > 
> >+reboot_cpuid=   [KNL] cpuid to use for reboot/halt, etc operations.
> >+
> > relax_domain_level=
> > [KNL, SMP] Set scheduler's default relax_domain_level.
> > See Documentation/cgroups/cpusets.txt.
> >diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> >index 76fa1e9..cdcf28f 100644
> >--- a/arch/x86/kernel/reboot.c
> >+++ b/arch/x86/kernel/reboot.c
> >@@ -49,10 +49,6 @@ int reboot_force;
> >  */
> > static int reboot_default = 1;
> > 
> >-#ifdef CONFIG_SMP
> >-static int reboot_cpu = -1;
> >-#endif
> >-
> > /*
> >  * This is set if we need to go through the 'emergency' path.
> >  * When machine_emergency_restart() is called, we may be on
> >@@ -63,6 +59,8 @@ static int reboot_emergency;
> >/* This is set by the PCI code if either type 1 or type 2 PCI is
> >detected */
> > bool port_cf9_safe = false;
> > 
> >+extern int reboot_cpuid;
> >+
> > /*
> >* reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old]
> >| p[ci]
> >  * warm   Don't set the cold reboot flag
> >@@ -97,10 +95,14 @@ static int __init reboot_setup(char *str)
> > 
> > #ifdef CONFIG_SMP
> > case 's':
> >-if (isdigit(*(str+1))) {
> >-reboot_cpu = (int) (*(str+1) - '0');
> >-if (isdigit(*(str+2)))
> >-reboot_cpu = reboot_cpu*10 + 
> >(int)(*(str+2) - '0');
> >+if (reboot_cpuid < 0) {
> >+int coffset;
> >+
> >+reboot_cpuid = 0;
> >+for (coffset = 1; isdigit(*(str + coffset)); 
> >coffset++) {
> >+reboot_cpuid *= 10;
> >+reboot_cpuid += (int)(*(str+2) - '0');
> >+}
> > }
> > /*
> >  * We will leave sorting out the final value
> >@@ -615,25 +617,10 @@ void native_machine_shutdown(void)
> > /* Stop the cpus and apics */
> > #ifdef CONFIG_SMP
> > 
> >-/* The boot cpu is always logical cpu 0 */
> >-int reboot_cpu_id = 0;
> >-
> >-/* See if there has been given a command line override */
> >-if ((reboot_cpu != -1) && (reboot_cpu < nr_cpu_ids) &&
> >-cpu_online(reboot_cpu))
> >-reboot_cpu_id = reboot_cpu;
> >-
> >-/* Make certain the cpu I'm about to reboot on is online */
> >-if (!cpu_online(reboot_cpu_id))
> >-reboot_cpu_id = smp_processor_id();
> >-
> >-/* Make certain I only run on the appropriate processor */
> >-set_cpus_allowed_ptr(current, cpumask_of(reboot_cpu_id));
> >-
> > /*
> >- * O.K Now that I'm on the appropriate processor, stop all of the
> >- * others. Also disable the local irq to not receive the per-cpu
> >- * timer interrupt which may trigger scheduler's load balance.
> >+ * Stop all of the others. Also disable the local irq to
> >+ * 

Re: [PATCH -mm -next] ipc,sem: untangle RCU locking with find_alloc_undo

[Mike Galbraith]

On Fri, 2013-04-05 at 09:21 -0400, Rik van Riel wrote: 
> On 04/05/2013 12:38 AM, Mike Galbraith wrote:
> > On Tue, 2013-03-26 at 16:00 -0400, Rik van Riel wrote:
> 
> >> The ipc semaphore code has a nasty RCU locking tangle, with both
> >> find_alloc_undo and semtimedop taking the rcu_read_lock(). The
> >> code can be cleaned up somewhat by only taking the rcu_read_lock
> >> once.
> >>
> >> There are no other callers to find_alloc_undo.
> >>
> >> This should also solve the trinity issue reported by Sasha Levin.
> >
> > I take it this is on top of the patchlet Sasha submitted?
> 
> Indeed, and all the other fixes that got submitted :)

I plugged it into my 64 core rt box and beat on it again, no stalls or
any other troubles noted.

-Mike

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

Re: [PATCH] MAINTAINERS: Update Grant's email address and maintainership

[Linus Walleij]

On Tue, Apr 16, 2013 at 12:43 PM,   wrote:

> From: Grant Likely 
>
> I've taken a full time position with Linaro and so I'll be using my
> Linaro email address from this point on. It has also been many years
> since I've touched any of the Xilinx related code so mark those items as
> unmaintained.
>
> In addition, Mark Brown is taking the lead on SPI maintainership now, so
> I've reversed the order of our names for that entry.
>
> Signed-off-by: Grant Likely 
> Cc: Mark Brown 
> Cc: Linus Walleij 
> Cc: Rob Herring 

Acked-by: Linus Walleij 

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFT][PATCH 3/3] regulator: ab8500-ext: Remove enable() and disable() functions

[Bengt Jönsson]

On 04/10/2013 02:56 PM, Axel Lin wrote:

Both enable() and disable() functions have only one caller, thus remove them.

Signed-off-by: Axel Lin 
This patch depends on the first one in the series so I would like to get 
first patch sorted out first.


If the first patch goes in, I am fine with this one too.

Regards,

Bengt

---
  drivers/regulator/ab8500-ext.c |   62 ++--
  1 file changed, 22 insertions(+), 40 deletions(-)

diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index 1efe702..dd582be 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -54,32 +54,44 @@ struct ab8500_ext_regulator_info {
u8 update_val_hw;
  };
  
-static int enable(struct ab8500_ext_regulator_info *info, u8 *regval)

+static int ab8500_ext_regulator_enable(struct regulator_dev *rdev)
  {
int ret;
+   struct ab8500_ext_regulator_info *info = rdev_get_drvdata(rdev);
+   u8 regval;
  
-	*regval = info->update_val;

+   if (info == NULL) {
+   dev_err(rdev_get_dev(rdev), "regulator info null pointer\n");
+   return -EINVAL;
+   }
  
  	/*

 * To satisfy both HW high power request and SW request, the regulator
 * must be on in high power.
 */
if (info->cfg && info->cfg->hwreq)
-   *regval = info->update_val_hp;
+   regval = info->update_val_hp;
+   else
+   regval = info->update_val;
  
  	ret = abx500_mask_and_set_register_interruptible(info->dev,

info->update_bank, info->update_reg,
-   info->update_mask, *regval);
+   info->update_mask, regval);
if (ret < 0) {
dev_err(rdev_get_dev(info->rdev),
"couldn't set enable bits for regulator\n");
return ret;
}
  
-	return ret;

+   dev_dbg(rdev_get_dev(rdev), "%s-enable (bank, reg, mask, value):"
+   " 0x%02x, 0x%02x, 0x%02x, 0x%02x\n",
+   info->desc.name, info->update_bank, info->update_reg,
+   info->update_mask, regval);
+
+   return 0;
  }
  
-static int ab8500_ext_regulator_enable(struct regulator_dev *rdev)

+static int ab8500_ext_regulator_disable(struct regulator_dev *rdev)
  {
int ret;
struct ab8500_ext_regulator_info *info = rdev_get_drvdata(rdev);
@@ -90,53 +102,23 @@ static int ab8500_ext_regulator_enable(struct 
regulator_dev *rdev)
return -EINVAL;
}
  
-	ret = enable(info, );

-
-   dev_dbg(rdev_get_dev(rdev), "%s-enable (bank, reg, mask, value):"
-   " 0x%02x, 0x%02x, 0x%02x, 0x%02x\n",
-   info->desc.name, info->update_bank, info->update_reg,
-   info->update_mask, regval);
-
-   return ret;
-}
-
-static int disable(struct ab8500_ext_regulator_info *info, u8 *regval)
-{
-   int ret;
-
-   *regval = 0x0;
-
/*
 * Set the regulator in HW request mode if configured
 */
if (info->cfg && info->cfg->hwreq)
-   *regval = info->update_val_hw;
+   regval = info->update_val_hw;
+   else
+   regval = 0;
  
  	ret = abx500_mask_and_set_register_interruptible(info->dev,

info->update_bank, info->update_reg,
-   info->update_mask, *regval);
+   info->update_mask, regval);
if (ret < 0) {
dev_err(rdev_get_dev(info->rdev),
"couldn't set disable bits for regulator\n");
return ret;
}
  
-	return ret;

-}
-
-static int ab8500_ext_regulator_disable(struct regulator_dev *rdev)
-{
-   int ret;
-   struct ab8500_ext_regulator_info *info = rdev_get_drvdata(rdev);
-   u8 regval;
-
-   if (info == NULL) {
-   dev_err(rdev_get_dev(rdev), "regulator info null pointer\n");
-   return -EINVAL;
-   }
-
-   ret = disable(info, );
-
dev_dbg(rdev_get_dev(rdev), "%s-disable (bank, reg, mask, value):"
" 0x%02x, 0x%02x, 0x%02x, 0x%02x\n",
info->desc.name, info->update_bank, info->update_reg,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] module: add kset_obj_exists() and use it

[Veaceslav Falico]

On Mon, Apr 15, 2013 at 11:56:03AM +0930, Rusty Russell wrote:

Veaceslav Falico  writes:

On Wed, Apr 10, 2013 at 04:47:34PM +0930, Rusty Russell wrote:

That's a bug.  We should be cleaning up sysfs before we unlike the
removed module from the list.

Because the same thing applies to ddebug info, which is also keyed by
module name.

Something like this (untested!):


Sorry for the late response - I wanted to test it for a longer time.

Your patch works flawlessly and fixes this race, with just a small
addition, cause otherwise we could BUG() in show_initstate().

Can you apply this patch or should I (re-)send it somehow?

Thank you!

diff --git a/kernel/module.c b/kernel/module.c
index d0afe23..8be6e97 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1063,6 +1063,9 @@ static ssize_t show_initstate(struct module_attribute 
*mattr,
case MODULE_STATE_GOING:
state = "going";
break;
+   case MODULE_STATE_UNFORMED:
+   state = "unformed";
+   break;
default:
BUG();
}


Prefer to remove from sysfs before marking it unformed, like so:

diff --git a/kernel/module.c b/kernel/module.c
index 2468fda..2e7189f 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1862,12 +1862,12 @@ static void free_module(struct module *mod)
{
trace_module_free(mod);

-   /* We leave it in list to prevent duplicate loads while we clean
-* up sysfs, ddebug and any other external exposure. */
-   mod->state = MODULE_STATE_UNFORMED;
-
mod_sysfs_teardown(mod);

+   /* We leave it in list to prevent duplicate loads, but make sure
+* that noone uses it while it's being deconstructed. */
+   mod->state = MODULE_STATE_UNFORMED;
+
/* Remove dynamic debug info */
ddebug_remove_module(mod->name);

Here's the updated total patch:


Tested for a day on two reproducers on the latest upstream kernel, with the
recent kobject fix a49b7e82 ("kobject: fix kset_find_obj() race with
concurrent last kobject_put()") - it fixes the issue, no regressions met.

Without the patch (but with that kobject fix) it gives the following, for
parallel modprobe/rmmod of pch_gbe module (it's easier to reproduce on less
powerful boxes, like this one):

[  103.981925] [ cut here ]
[  103.986902] WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0xab/0xd0()
[  103.993606] Hardware name: CrownBay Platform
[  103.998075] sysfs: cannot create duplicate filename '/module/pch_gbe'
[  104.004784] Modules linked in: pch_gbe(+) [last unloaded: pch_gbe]
[  104.011362] Pid: 3021, comm: modprobe Tainted: GW3.9.0-rc5+ #5
[  104.018662] Call Trace:
[  104.021286]  [] warn_slowpath_common+0x6d/0xa0
[  104.026933]  [] ? sysfs_add_one+0xab/0xd0
[  104.031986]  [] ? sysfs_add_one+0xab/0xd0
[  104.037000]  [] warn_slowpath_fmt+0x2e/0x30
[  104.042188]  [] sysfs_add_one+0xab/0xd0
[  104.046982]  [] create_dir+0x5e/0xa0
[  104.051633]  [] sysfs_create_dir+0x78/0xd0
[  104.056774]  [] kobject_add_internal+0x83/0x1f0
[  104.062351]  [] ? kvasprintf+0x46/0x60
[  104.067231]  [] kobject_add_varg+0x2d/0x50
[  104.072450]  [] kobject_init_and_add+0x27/0x30
[  104.078075]  [] mod_sysfs_setup+0x80/0x540
[  104.083207]  [] ? module_bug_finalize+0x51/0xc0
[  104.088720]  [] load_module+0x1429/0x18b0
[  104.093712]  [] ? free_notes_attrs+0x40/0x40
[  104.098973]  [] ? _copy_from_user+0x38/0x130
[  104.104225]  [] sys_init_module+0x93/0xb0
[  104.109211]  [] sysenter_do_call+0x12/0x22
[  104.114272] ---[ end trace aa239ae9897b5680 ]---
[  104.119029] [ cut here ]
[  104.123901] WARNING: at lib/kobject.c:196 kobject_add_internal+0x1da/0x1f0()
[  104.131254] Hardware name: CrownBay Platform
[  104.135792] kobject_add_internal failed for pch_gbe with -EEXIST, don't try 
to register things with the same name in the same directory.
[  104.148539] Modules linked in: pch_gbe(+) [last unloaded: pch_gbe]
[  104.155256] Pid: 3021, comm: modprobe Tainted: GW3.9.0-rc5+ #5
[  104.162437] Call Trace:
[  104.165057]  [] warn_slowpath_common+0x6d/0xa0
[  104.170715]  [] ? kobject_add_internal+0x1da/0x1f0
[  104.176683]  [] ? kobject_add_internal+0x1da/0x1f0
[  104.182644]  [] warn_slowpath_fmt+0x2e/0x30
[  104.187937]  [] kobject_add_internal+0x1da/0x1f0
[  104.193750]  [] kobject_add_varg+0x2d/0x50
[  104.198891]  [] kobject_init_and_add+0x27/0x30
[  104.204489]  [] mod_sysfs_setup+0x80/0x540
[  104.209706]  [] ? module_bug_finalize+0x51/0xc0
[  104.215362]  [] load_module+0x1429/0x18b0
[  104.220530]  [] ? free_notes_attrs+0x40/0x40
[  104.226001]  [] ? _copy_from_user+0x38/0x130
[  104.231442]  [] sys_init_module+0x93/0xb0
[  104.236629]  [] sysenter_do_call+0x12/0x22
[  104.241855] ---[ end trace aa239ae9897b5681 ]---


With the patch it worked flawlessly for a day.



diff --git a/kernel/module.c b/kernel/module.c
index 69d2600..2e7189f 100644
--- a/kernel/module.c
+++ 

Re: [RFT][PATCH 2/3] regulator: ab8500-ext: Don't update info->update_val if set_mode() fails

[Bengt Jönsson]

On 04/10/2013 02:55 PM, Axel Lin wrote:

This ensures info->update_val status is still correct if set_mode() call fails.
Otherwise, get_mode() may return wrong status if a set_mode() call fails.

Signed-off-by: Axel Lin 
---
  drivers/regulator/ab8500-ext.c |   19 ---
  1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index f0a1bbf..1efe702 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -181,6 +181,7 @@ static int ab8500_ext_regulator_set_mode(struct 
regulator_dev *rdev,
  {
int ret = 0;
struct ab8500_ext_regulator_info *info = rdev_get_drvdata(rdev);
+   u8 regval;
  
  	if (info == NULL) {

dev_err(rdev_get_dev(rdev), "regulator info null pointer\n");
@@ -189,14 +190,14 @@ static int ab8500_ext_regulator_set_mode(struct 
regulator_dev *rdev,
  
  	switch (mode) {

case REGULATOR_MODE_NORMAL:
-   info->update_val = info->update_val_hp;
+   regval = info->update_val_hp;
break;
case REGULATOR_MODE_IDLE:
/* Always on with high power mode if info->cfg->hwreq is set */
if (info->cfg && info->cfg->hwreq)
return -EINVAL;
  
-		info->update_val = info->update_val_lp;

+   regval = info->update_val_lp;
break;
  
  	default:

@@ -204,12 +205,14 @@ static int ab8500_ext_regulator_set_mode(struct 
regulator_dev *rdev,
}
  
  	if (ab8500_ext_regulator_is_enabled(rdev)) {

-   u8 regval;
-
-   ret = enable(info, );
-   if (ret < 0)
+   ret = abx500_mask_and_set_register_interruptible(info->dev,
+   info->update_bank, info->update_reg,
+   info->update_mask, regval);
+   if (ret < 0) {
dev_err(rdev_get_dev(rdev),
"Could not set regulator mode.\n");
+   return ret;
+   }
  
  		dev_dbg(rdev_get_dev(rdev),

"%s-set_mode (bank, reg, mask, value): "
@@ -218,7 +221,9 @@ static int ab8500_ext_regulator_set_mode(struct 
regulator_dev *rdev,
info->update_mask, regval);
}
  
-	return ret;

+   info->update_val = regval;
+
+   return 0;
  }
  
  static unsigned int ab8500_ext_regulator_get_mode(struct regulator_dev *rdev)
This patch is needed to fix the error path but it partly depends on the 
previous patch so I would like to get that one sorted out before ack-ing 
this patch.


Regards,

Bengt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: print out hardware name & modules list when we encounter bad page tables.

[Josh Boyer]

On Thu, Apr 11, 2013 at 2:56 PM, Dave Jones  wrote:
> Given we have been seeing a lot of reports of page table corruption
> for a while now, perhaps if we print out the hardware name, and list
> of modules loaded, we might see some patterns emerging.
>
> Signed-off-by: Dave Jones 
>
> diff -durpN '--exclude-from=/home/davej/.exclude' 
> /home/davej/src/kernel/git-trees/linux/include/asm-generic/bug.h 
> linux-dj/include/asm-generic/bug.h
> --- linux/include/asm-generic/bug.h 2013-01-04 18:57:12.604282214 -0500
> +++ linux-dj/include/asm-generic/bug.h  2013-02-28 20:04:37.649304147 -0500
> @@ -55,6 +55,8 @@ struct bug_entry {
>  #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
>  #endif
>
> +void print_hardware_dmi_name(void);
> +
>  /*
>   * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
>   * significant issues that need prompt attention if they should ever
> diff -durpN '--exclude-from=/home/davej/.exclude' 
> /home/davej/src/kernel/git-trees/linux/kernel/panic.c linux-dj/kernel/panic.c
> --- linux/kernel/panic.c2013-02-26 14:41:18.544116674 -0500
> +++ linux-dj/kernel/panic.c 2013-02-28 20:04:37.666304115 -0500
> @@ -397,16 +397,22 @@ struct slowpath_args {
> va_list args;
>  };
>
> -static void warn_slowpath_common(const char *file, int line, void *caller,
> -unsigned taint, struct slowpath_args *args)
> +void print_hardware_dmi_name(void)
>  {

This fails to build on arches that define __WARN_TAINT.  Just move the
new function definition above the WANT_WARN_ON_SLOWPATH define and it
should be fine.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [oss-security] Summary of security bugs (now fixed) in user namespaces

[Florian Weimer]

On 04/13/2013 07:16 PM, Andy Lutomirski wrote:

I previously reported these bugs privatley.  I'm summarizing them for
the historical record.  These bugs were never exploitable on a
default-configured released kernel, but some 3.8 versions are
vulnerable depending on configuration.


Looking at this list, is there some way to restrict this new 
functionality to, say, membership in a certain group?  At present, most 
system users (daemons) do not need this functionality, so it would make 
sense to restrict access to it.


Or is the expectation that we disable CONFIG_USER_NS until things 
stabilize further?


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

Re: [PATCH v2 0/5] dmaengine: add ACPI DMA helpers and use them in dw_dmac

[Andy Shevchenko]

On Mon, 2013-04-15 at 22:06 +0530, Vinod Koul wrote: 
> On Tue, Apr 09, 2013 at 02:05:42PM +0300, Andy Shevchenko wrote:
> > There is a patch series which introduces ACPI DMA helpers in similar way 
> > like
> > we have for DeviceTree.
> > 
> > In addition it applies this to the first user, namely dw_dmac driver.
> Applied w/o 3 & 5.2 they failed, can you pls rebase and resend
> 

Actually those two (at least 5/5) can't be applied on top of slave-dma.
The patches requires slave-dma and linux-pm together. I heard it's
usually achieved by creating a specific branch in one subsystem
(linux-pm in our case) for another.

Rafael, what could we do here?

> --
> ~Vinod
> > 
> > Since v1:
> >  - address one Vinod's comment
> >  - replace 5/6 & 6/6 by 5/5 from Rafael
> >  - tested on Intel Lynxpoint system
> > 
> > Andy Shevchenko (4):
> >   dma: acpi-dma: introduce ACPI DMA helpers
> >   dmaengine: call acpi_dma_request_slave_channel as well
> >   dma: acpi-dma: parse CSRT to extract additional resources
> >   dw_dmac: add ACPI support
> > 
> > Rafael J. Wysocki (1):
> >   ACPI / LPSS: add support of shared clock
> > 
> >  Documentation/acpi/enumeration.txt |  77 ++
> >  drivers/acpi/Makefile  |   1 -
> >  drivers/acpi/acpi_lpss.c   |  26 +-
> >  drivers/acpi/csrt.c| 159 
> >  drivers/acpi/internal.h|   1 -
> >  drivers/acpi/scan.c|   1 -
> >  drivers/clk/x86/clk-lpt.c  |  15 +-
> >  drivers/dma/Kconfig|   4 +
> >  drivers/dma/Makefile   |   1 +
> >  drivers/dma/acpi-dma.c | 445 
> > +
> >  drivers/dma/dmaengine.c|   6 +
> >  drivers/dma/dw_dmac.c  |  68 +++--
> >  drivers/dma/dw_dmac_regs.h |   1 -
> >  include/linux/acpi_dma.h   | 120 +
> >  include/linux/platform_data/clk-lpss.h |   5 +
> >  15 files changed, 741 insertions(+), 189 deletions(-)
> >  delete mode 100644 drivers/acpi/csrt.c
> >  create mode 100644 drivers/dma/acpi-dma.c
> >  create mode 100644 include/linux/acpi_dma.h
> > 
> > -- 
> > 1.8.2.rc0.22.gb3600c3
> > 

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

Re: [PATCH V4 2/5] spi: s3c64xx: added support for polling mode

[Mark Brown]

On Tue, Apr 16, 2013 at 04:58:47PM +0530, Girish KS wrote:
> On Tue, Apr 16, 2013 at 4:50 PM, Mark Brown  wrote:

> > I'm missing patch 1 of this series.

> its already  merged to stable tree after your review

The patch numbering should reflect what you're posting.  If you're only
sending four patches they should be numbered 1-4, otherwise it looks
like there's something missing.  The goal with the numbers is to help
people get the patches in the right order, the name should be enough to
associate with other versions of the same patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 optional 3/3] mutex: back out architecture specific check for negative mutex count

[Waiman Long]

On 04/16/2013 06:05 AM, Will Deacon wrote:

On Mon, Apr 15, 2013 at 03:37:59PM +0100, Waiman Long wrote:

If it is confirmed that all the supported architectures can allow a
negative mutex count without incorrect behavior, we can then back
out the architecture specific change and allow the mutex count to
go to any negative number. That should further reduce contention for
non-x86 architecture.

If this is not the case, this patch should be dropped.

A good starting point might be to look at the asm-generic mutex
implementations, which clears up the majority of architectures. A cursory
glance at mutex-dec.h suggests that it's OK to me...


I think the generic version is fine with negative mutex count. However, 
it is the architecture specific versions (we have 22 of them as of 3.8) 
that I am worry about. I just don't have enough know-how and test 
machines to verify that.


Regards,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFT][PATCH 1/3] regulator: ab8500-ext: Don't allow set idle mode if info->cfg->hwreq is set

[Bengt Jönsson]

On 04/10/2013 02:54 PM, Axel Lin wrote:

The regulator always on with high power mode if info->cfg->hwreq is set.

If we allow set idle mode when info->cfg->hwreq is set, get_mode() returns
REGULATOR_MODE_IDLE but the regulator actually is in REGULATOR_MODE_NORMAL mode.
This patch avoid inconsistent status return by get_mode().

Signed-off-by: Axel Lin z
---
  drivers/regulator/ab8500-ext.c |4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index 9aee21c..f0a1bbf 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -192,6 +192,10 @@ static int ab8500_ext_regulator_set_mode(struct 
regulator_dev *rdev,
info->update_val = info->update_val_hp;
break;
case REGULATOR_MODE_IDLE:
+   /* Always on with high power mode if info->cfg->hwreq is set */
+   if (info->cfg && info->cfg->hwreq)
+   return -EINVAL;
+
info->update_val = info->update_val_lp;
break;
  
I prefer to have info->update_val updated to reflect requested mode (in 
get_mode) instead of returning -EINVAL. This is how I interpret Mark's 
comment on the other patch ([PATCH] regulator: ab8500: Fix get_mode for 
shared mode regulators).Otherwise, the patch should work fine.


Regards,

Bengt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] em28xx: Put remaining .vidioc_g_chip_info instance under ADV_DEBUG

[Michal Marek]

Commit cd634f1 ("[media] v4l2: put VIDIOC_DBG_G_CHIP_NAME under
ADV_DEBUG") missed the initializer of radio_ioctl_ops:

drivers/media/usb/em28xx/em28xx-video.c:1830:2: error: unknown field 
'vidioc_g_chip_info' specified in initializer
drivers/media/usb/em28xx/em28xx-video.c:1830:26: error: 'vidioc_g_chip_info' 
undeclared here (not in a function)

Signed-off-by: Michal Marek 
---
 drivers/media/usb/em28xx/em28xx-video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx-video.c 
b/drivers/media/usb/em28xx/em28xx-video.c
index c27c1f6..32d60e5 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1827,8 +1827,8 @@ static const struct v4l2_ioctl_ops radio_ioctl_ops = {
.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
.vidioc_g_chip_ident  = vidioc_g_chip_ident,
-   .vidioc_g_chip_info   = vidioc_g_chip_info,
 #ifdef CONFIG_VIDEO_ADV_DEBUG
+   .vidioc_g_chip_info   = vidioc_g_chip_info,
.vidioc_g_register= vidioc_g_register,
.vidioc_s_register= vidioc_s_register,
 #endif
-- 
1.8.2.1

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

Re: [Patch -v4 1/4] Migrate shutdown/reboot to boot cpu.

[Robin Holt]

On Tue, Apr 16, 2013 at 01:32:56PM +0200, Ingo Molnar wrote:
> 
> * Robin Holt  wrote:
> 
> > We recently noticed that reboot of a 1024 cpu machine takes approx 16
> > minutes of just stopping the cpus.  The slowdown was tracked to commit
> > f96972f.
> > 
> > The current implementation does all the work of hot removing the cpus
> > before halting the system.  We are switching to just migrating to the
> > boot cpu and then continuing with shutdown/reboot.
> > 
> > This also has the effect of not breaking x86's command line parameter for
> > specifying the reboot cpu.  Note, this code was shamelessly copied from
> > arch/x86/kernel/reboot.c with bits removed pertaining to the reboot_cpu
> > command line parameter.
> > 
> > Signed-off-by: Robin Holt 
> > Tested-by: Shawn Guo 
> > To: Ingo Molnar 
> > To: Russ Anderson 
> > To: Oleg Nesterov 
> > Cc: Andrew Morton 
> > Cc: "H. Peter Anvin" 
> > Cc: Lai Jiangshan 
> > Cc: Linus Torvalds 
> > Cc: Linux Kernel Mailing List 
> > Cc: Michel Lespinasse 
> > Cc: Oleg Nesterov 
> > Cc: "Paul E. McKenney" 
> > Cc: Paul Mackerras 
> > Cc: Peter Zijlstra 
> > Cc: Robin Holt 
> > Cc: "ru...@rustcorp.com.au" 
> > Cc: Tejun Heo 
> > Cc: the arch/x86 maintainers 
> > Cc: Thomas Gleixner 
> > Cc: 
> > 
> > ---
> > 
> > Changes since -v1.
> > - Set PF_THREAD_BOUND before migrating to eliminate potential race.
> > - Modified kernel_power_off to also migrate instead of using
> >   disable_nonboot_cpus().
> > ---
> >  kernel/sys.c | 22 +++---
> >  1 file changed, 19 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/sys.c b/kernel/sys.c
> > index 0da73cf..5ef7aa2 100644
> > --- a/kernel/sys.c
> > +++ b/kernel/sys.c
> > @@ -357,6 +357,22 @@ int unregister_reboot_notifier(struct notifier_block 
> > *nb)
> >  }
> >  EXPORT_SYMBOL(unregister_reboot_notifier);
> >  
> > +void migrate_to_reboot_cpu(void)
> 
> It appears to be file-scope, so should be static I guess?

Done.

> > +{
> > +   /* The boot cpu is always logical cpu 0 */
> > +   int reboot_cpu_id = 0;
> > +
> > +   /* Make certain the cpu I'm about to reboot on is online */
> > +   if (!cpu_online(reboot_cpu_id))
> > +   reboot_cpu_id = smp_processor_id();
> 
> Shouldn't we pick the first online CPU instead, to make it deterministic?

Done.

reboot_cpu_id = cpumask_first(cpu_online_mask);

> Also, does this codepath prevent hotplug from going on in parallel?

Not sure.  I have not considered hotplug.  I will look that over when I
am in the office.

> ( Plus, the smp_processor_id() is in a preemptible section AFAICS, so it will 
>   throw a warning with preempt debug on. )
> 
> > +
> > +   /* Prevent races with other tasks migrating this task. */
> 
> (I guess the colon can be dropped here, like in the other comments.)

Done.

> 
> > +   current->flags |= PF_THREAD_BOUND;
> > +
> > +   /* Make certain I only run on the appropriate processor */
> > +   set_cpus_allowed_ptr(current, cpumask_of(reboot_cpu_id));
> > +}

I will resubmit when I have the hotplug stuff understood and after giving
the set some more time for comments.

Robin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] Make reboot_cpuid a kernel parameter. other cpus.

[H. Peter Anvin]

Why not just support the existing syntax everywhere?

Robin Holt  wrote:

>Moving the reboot=s<##> parameter for x86 to a kernel parameter
>proper.  I did not find any other arch that was specifying the
>reboot cpu.
>
>I left a compatibility mode in there.  The new parameter always
>takes precedence.  I also fixed up the current code to support
>up to cpuid's up to the current max of 4096.
>
>Signed-off-by: Robin Holt 
>To: Ingo Molnar 
>To: Russ Anderson 
>Cc: Shawn Guo 
>Cc: Oleg Nesterov 
>Cc: Andrew Morton 
>Cc: "H. Peter Anvin" 
>Cc: Lai Jiangshan 
>Cc: Linus Torvalds 
>Cc: Linux Kernel Mailing List 
>Cc: Michel Lespinasse 
>Cc: Oleg Nesterov 
>Cc: "Paul E. McKenney" 
>Cc: Paul Mackerras 
>Cc: Peter Zijlstra 
>Cc: Robin Holt 
>Cc: "ru...@rustcorp.com.au" 
>Cc: Tejun Heo 
>Cc: the arch/x86 maintainers 
>Cc: Thomas Gleixner 
>
>---
>
>Changes since -v3
>- Added a reboot=s compatibility mode for x86.
>
> Documentation/kernel-parameters.txt |  2 ++
>arch/x86/kernel/reboot.c| 39
>+
> kernel/reboot.c |  8 +++-
> 3 files changed, 22 insertions(+), 27 deletions(-)
>
>diff --git a/Documentation/kernel-parameters.txt
>b/Documentation/kernel-parameters.txt
>index 4609e81..11ebb48 100644
>--- a/Documentation/kernel-parameters.txt
>+++ b/Documentation/kernel-parameters.txt
>@@ -2597,6 +2597,8 @@ bytes respectively. Such letter suffixes can also
>be entirely omitted.
>   Format: [,[,...]]
>   See arch/*/kernel/reboot.c or arch/*/kernel/process.c
> 
>+  reboot_cpuid=   [KNL] cpuid to use for reboot/halt, etc operations.
>+
>   relax_domain_level=
>   [KNL, SMP] Set scheduler's default relax_domain_level.
>   See Documentation/cgroups/cpusets.txt.
>diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
>index 76fa1e9..cdcf28f 100644
>--- a/arch/x86/kernel/reboot.c
>+++ b/arch/x86/kernel/reboot.c
>@@ -49,10 +49,6 @@ int reboot_force;
>  */
> static int reboot_default = 1;
> 
>-#ifdef CONFIG_SMP
>-static int reboot_cpu = -1;
>-#endif
>-
> /*
>  * This is set if we need to go through the 'emergency' path.
>  * When machine_emergency_restart() is called, we may be on
>@@ -63,6 +59,8 @@ static int reboot_emergency;
>/* This is set by the PCI code if either type 1 or type 2 PCI is
>detected */
> bool port_cf9_safe = false;
> 
>+extern int reboot_cpuid;
>+
> /*
>* reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old]
>| p[ci]
>  * warm   Don't set the cold reboot flag
>@@ -97,10 +95,14 @@ static int __init reboot_setup(char *str)
> 
> #ifdef CONFIG_SMP
>   case 's':
>-  if (isdigit(*(str+1))) {
>-  reboot_cpu = (int) (*(str+1) - '0');
>-  if (isdigit(*(str+2)))
>-  reboot_cpu = reboot_cpu*10 + 
>(int)(*(str+2) - '0');
>+  if (reboot_cpuid < 0) {
>+  int coffset;
>+
>+  reboot_cpuid = 0;
>+  for (coffset = 1; isdigit(*(str + coffset)); 
>coffset++) {
>+  reboot_cpuid *= 10;
>+  reboot_cpuid += (int)(*(str+2) - '0');
>+  }
>   }
>   /*
>* We will leave sorting out the final value
>@@ -615,25 +617,10 @@ void native_machine_shutdown(void)
>   /* Stop the cpus and apics */
> #ifdef CONFIG_SMP
> 
>-  /* The boot cpu is always logical cpu 0 */
>-  int reboot_cpu_id = 0;
>-
>-  /* See if there has been given a command line override */
>-  if ((reboot_cpu != -1) && (reboot_cpu < nr_cpu_ids) &&
>-  cpu_online(reboot_cpu))
>-  reboot_cpu_id = reboot_cpu;
>-
>-  /* Make certain the cpu I'm about to reboot on is online */
>-  if (!cpu_online(reboot_cpu_id))
>-  reboot_cpu_id = smp_processor_id();
>-
>-  /* Make certain I only run on the appropriate processor */
>-  set_cpus_allowed_ptr(current, cpumask_of(reboot_cpu_id));
>-
>   /*
>-   * O.K Now that I'm on the appropriate processor, stop all of the
>-   * others. Also disable the local irq to not receive the per-cpu
>-   * timer interrupt which may trigger scheduler's load balance.
>+   * Stop all of the others. Also disable the local irq to
>+   * not receive the per-cpu timer interrupt which may trigger
>+   * scheduler's load balance.
>*/
>   local_irq_disable();
>   stop_other_cpus();
>diff --git a/kernel/reboot.c b/kernel/reboot.c
>index 8cfef20..b2ef798 100644
>--- a/kernel/reboot.c
>+++ b/kernel/reboot.c
>@@ -10,6 +10,7 @@
> #include 
> #include 
> #include 
>+#include 
> #include 
> #include 
> #include 
>@@ -69,13 +70,18 @@ int unregister_reboot_notifier(struct
>notifier_block *nb)
> }
> 

Re: [PATCH v2 2/3] mutex: Queue mutex spinners with MCS lock to reduce cacheline contention

[Waiman Long]

On 04/16/2013 12:24 AM, Davidlohr Bueso wrote:

On Mon, 2013-04-15 at 10:37 -0400, Waiman Long wrote:
[...]

+typedef struct mspin_node {
+   struct mspin_node *next;
+   intlocked;  /* 1 if lock acquired */
+} mspin_node_t;
+
+typedef mspin_node_t   *mspin_lock_t;

I think we could do without the typedefs, specially mspin_lock_t.

Yes, we can do without the typedefs.


+
+#defineMLOCK(mutex)((mspin_lock_t *)&((mutex)->spin_mlock))
+
+static noinline void mspin_lock(mspin_lock_t *lock,  mspin_node_t *node)
+{
+   mspin_node_t *prev;
+
+   /* Init node */
+   node->locked = 0;
+   node->next   = NULL;
+
+   prev = xchg(lock, node);
+   if (likely(prev == NULL)) {
+   /* Lock acquired */
+   node->locked = 1;
+   return;
+   }
+   ACCESS_ONCE(prev->next) = node;
+   smp_wmb();
+   /* Wait until the lock holder passes the lock down */
+   while (!ACCESS_ONCE(node->locked))
+   arch_mutex_cpu_relax();
+}
+
+static void mspin_unlock(mspin_lock_t *lock,  mspin_node_t *node)
+{
+   mspin_node_t *next = ACCESS_ONCE(node->next);
+
+   if (likely(!next)) {
+   /*
+* Release the lock by setting it to NULL
+*/
+   if (cmpxchg(lock, node, NULL) == node)
+   return;
+   /* Wait until the next pointer is set */
+   while (!(next = ACCESS_ONCE(node->next)))
+   arch_mutex_cpu_relax();
+   }
+   barrier();
+   ACCESS_ONCE(next->locked) = 1;
+   smp_wmb();

Do we really need the compiler barrier call? The CPUs can reorder
anyway. I assume the smp_wbm() call makes sure no there's no funny
business before the next lock is acquired, might be worth commenting.


The smp_wmb() calls are to make sure that the writes are committed to 
memory rather than staying in the cache only. They are safety measures. 
The barrier() call probably is not needed because of the next pointer 
data dependency, but it doesn't have an actual cost either as it doesn't 
translate to any instruction.


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