Re: Debugging Thinkpad T430s occasional suspend failure.

[Dave Jones]

On Tue, Feb 12, 2013 at 04:26:22PM -0800, Hugh Dickins wrote:
 
 > Me too on T420s, except that is blessed with a blinking CapsLk.
 > 
 > It's so erratic (though I think I see more failures than you do: I'd say
 > a quick resume never fails, but an overnight resume fails half the time):
 > I'm afraid I didn't have the patience to embark on pm_trace at all.
 > 
 > I did try to bisect it during the -rc5 week.  I'm not sure, but I have
 > no record of seeing it on -rc1 or -rc2, but definitely saw it on -rc3.
 > So I tried bisecting between -rc2 and -rc3, persisting for a day if it
 > looked good; but the bisection didn't seem to be converging anywhere
 > likely when -rc6 came out, and I switched to see if -rc6 solved it.
 > 
 > I had no problem with -rc6; but with -rc7 it happens more than ever.
 > Though still not on "quick" resumes, the kind you want to do when
 > bisecting.
 > 
 > Sharing these anecdotes in case they match or diverge from your
 > experience and others, and might help towards finding the cause.
 > Not-to-be-trusted bisection log appended: of course the bads are
 > reliable, but perhaps none of the goods.

Yeah, my first bisection results look totally different.
I can do 100 suspend/resumes fine on 3.6.0, but it fails after just 2-3
on 3.7.0, so it looks like the bug I'm chasing happened before whatever
is affecting you.  (Or maybe you just didn't get 'lucky' when testing rc1,
and it wasn't good after all).

Now that I have what appears to be a 'good' candidate, hopefully
a bisection can quickly get to the bottom of this.

Dave

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

linux-next: manual merge of the ia64 tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the ia64 tree got a conflict in
drivers/firmware/efivars.c between commit 83e68189745a ("efi: Make
'efi_enabled' a function to query EFI facilities") from the  tree and
commit a93bc0c6e07e ("efi_pstore: Introducing workqueue updating sysfs")
from the ia64 tree.

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

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

diff --cc drivers/firmware/efivars.c
index f5596db,6922511..000
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@@ -790,10 -798,9 +798,10 @@@ static ssize_t efivarfs_file_write(stru
  
} else if (status == EFI_NOT_FOUND) {
list_del(>list);
-   spin_unlock(>lock);
+   spin_unlock_irq(>lock);
efivar_unregister(var);
drop_nlink(inode);
 +  d_delete(file->f_dentry);
dput(file->f_dentry);
  
} else {
@@@ -993,9 -1000,9 +1001,9 @@@ static int efivarfs_unlink(struct inod
  
if (status == EFI_SUCCESS || status == EFI_NOT_FOUND) {
list_del(>list);
-   spin_unlock(>lock);
+   spin_unlock_irq(>lock);
efivar_unregister(var);
 -  drop_nlink(dir);
 +  drop_nlink(dentry->d_inode);
dput(dentry);
return 0;
}
@@@ -1823,7 -1906,9 +1907,9 @@@ err_put
  static void __exit
  efivars_exit(void)
  {
+   cancel_work_sync(_work);
+ 
 -  if (efi_enabled) {
 +  if (efi_enabled(EFI_RUNTIME_SERVICES)) {
unregister_efivars(&__efivars);
kobject_put(efi_kobj);
}


pgpTlcYnz8WMc.pgp
Description: PGP signature

RE: [tip:x86/hyperv] x86, hyperv: HYPERV depends on X86_LOCAL_APIC

[KY Srinivasan]

> -Original Message-
> From: tip tree robot [mailto:tip...@zytor.com] On Behalf Of tip-bot for H. 
> Peter
> Anvin
> Sent: Tuesday, February 12, 2013 8:59 PM
> To: linux-tip-comm...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; h...@zytor.com; mi...@kernel.org; KY
> Srinivasan; t...@linutronix.de; h...@linux.intel.com
> Subject: [tip:x86/hyperv] x86, hyperv: HYPERV depends on X86_LOCAL_APIC
> 
> Commit-ID:  cb20e5f2c8d6ba7440a32f4d70c0755bceb36e78
> Gitweb:
> http://git.kernel.org/tip/cb20e5f2c8d6ba7440a32f4d70c0755bceb36e78
> Author: H. Peter Anvin 
> AuthorDate: Tue, 12 Feb 2013 17:46:23 -0800
> Committer:  H. Peter Anvin 
> CommitDate: Tue, 12 Feb 2013 17:46:23 -0800
> 
> x86, hyperv: HYPERV depends on X86_LOCAL_APIC
> 
> In order to compile in the special Hyper-V interrupt vector, we need
> infrastructure in arch/x86/apic/apic.c.  At least for now, simply
> require CONFIG_X86_LOCAL_APIC in order to enable CONFIG_HYPERV.
> 
> Link: http://lkml.kernel.org/r/tip-
> bc2b0331e077f576369a2b6c75d15ed4de4ef...@git.kernel.org
> Cc: K. Y. Srinivasan 
> Signed-off-by: H. Peter Anvin 
> ---
>  drivers/hv/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index b38ef6d..64630f1 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -2,7 +2,7 @@ menu "Microsoft Hyper-V guest support"
> 
>  config HYPERV
>   tristate "Microsoft Hyper-V client drivers"
> - depends on X86 && ACPI && PCI
> + depends on X86 && ACPI && PCI && X86_LOCAL_APIC
>   help
> Select this option to run Linux as a Hyper-V client operating
> system.
> 
Thank you.

K. Y
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[tip:x86/hyperv] x86, hyperv: HYPERV depends on X86_LOCAL_APIC

[tip-bot for H. Peter Anvin]

Commit-ID:  cb20e5f2c8d6ba7440a32f4d70c0755bceb36e78
Gitweb: http://git.kernel.org/tip/cb20e5f2c8d6ba7440a32f4d70c0755bceb36e78
Author: H. Peter Anvin 
AuthorDate: Tue, 12 Feb 2013 17:46:23 -0800
Committer:  H. Peter Anvin 
CommitDate: Tue, 12 Feb 2013 17:46:23 -0800

x86, hyperv: HYPERV depends on X86_LOCAL_APIC

In order to compile in the special Hyper-V interrupt vector, we need
infrastructure in arch/x86/apic/apic.c.  At least for now, simply
require CONFIG_X86_LOCAL_APIC in order to enable CONFIG_HYPERV.

Link: 
http://lkml.kernel.org/r/tip-bc2b0331e077f576369a2b6c75d15ed4de4ef...@git.kernel.org
Cc: K. Y. Srinivasan 
Signed-off-by: H. Peter Anvin 
---
 drivers/hv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index b38ef6d..64630f1 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -2,7 +2,7 @@ menu "Microsoft Hyper-V guest support"
 
 config HYPERV
tristate "Microsoft Hyper-V client drivers"
-   depends on X86 && ACPI && PCI
+   depends on X86 && ACPI && PCI && X86_LOCAL_APIC
help
  Select this option to run Linux as a Hyper-V client operating
  system.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / hotplug: Fix concurrency issues and memory leaks

[Yinghai Lu]

On Tue, Feb 12, 2013 at 4:19 PM, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> This changeset is aimed at fixing a few different but related
> problems in the ACPI hotplug infrastructure.
>
> First of all, since notify handlers may be run in parallel with
> acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
> and some of them are installed for ACPI handles that have no struct
> acpi_device objects attached (i.e. before those objects are created),
> those notify handlers have to take acpi_scan_lock to prevent races
> from taking place (e.g. a struct acpi_device is found to be present
> for the given ACPI handle, but right after that it is removed by
> acpi_bus_trim() running in parallel to the given notify handler).
> Moreover, since some of them call acpi_bus_scan() and
> acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
> should be acquired by the callers of these two funtions rather by
> these functions themselves.
>
> For these reasons, make all notify handlers that can handle device
> addition and eject events take acpi_scan_lock and remove the
> acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
> Accordingly, update all of their users to make sure that they
> are always called under acpi_scan_lock.
>
> Furthermore, since eject operations are carried out asynchronously
> with respect to the notify events that trigger them, with the help
> of acpi_bus_hot_remove_device(), even if notify handlers take the
> ACPI scan lock, it still is possible that, for example,
> acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
> the notify handler that scheduled its execution and that
> acpi_bus_trim() will remove the device node passed to
> acpi_bus_hot_remove_device() for ejection.  In that case, the struct
> acpi_device object obtained by acpi_bus_hot_remove_device() will be
> invalid and not-so-funny things will ensue.  To protect agaist that,
> make the users of acpi_bus_hot_remove_device() run get_device() on
> ACPI device node objects that are about to be passed to it and make
> acpi_bus_hot_remove_device() run put_device() on them and check if
> their ACPI handles are not NULL (make acpi_device_unregister() clear
> the device nodes' ACPI handles for that check to work).
>
> Finally, observe that acpi_os_hotplug_execute() actually can fail,
> in which case its caller ought to free memory allocated for the
> context object to prevent leaks from happening.  It also needs to
> run put_device() on the device node that it ran get_device() on
> previously in that case.  Modify the code accordingly.
>
> Signed-off-by: Rafael J. Wysocki 

Acked-by: Yinghai Lu 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / PCI: Initialize PCI root drivers after PCI bus enumeration

[Yinghai Lu]

On Tue, Feb 12, 2013 at 4:16 PM, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> After commit 1aeae82 (ACPI / PCI: avoid building pci_slot as module)
> the pci_slot driver's .add() callback routine, acpi_pci_slot_add(),
> is executed from within acpi_pci_root_add() before the PCI devices on
> the bus are enumerated and that triggers the WARN_ON() in
> kobject_get():
>
> WARNING: at /scratch/rafael/work/test/include/linux/kref.h:42 
> kobject_get+0x33/0x40()
> Hardware name: PORTEGE R500
> Modules linked in:
> Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc7+ #160
> Call Trace:
>  [] warn_slowpath_common+0x7a/0xb0
>  [] warn_slowpath_null+0x15/0x20
>  [] kobject_get+0x33/0x40
>  [] get_device+0x12/0x30
>  [] register_slot+0x243/0x295
>  [] ? trace_hardirqs_on+0xd/0x10
>  [] acpi_ns_walk_namespace+0x10f/0x24a
>  [] ? walk_p2p_bridge+0x13b/0x13b
>  [] ? walk_p2p_bridge+0x13b/0x13b
>  [] acpi_walk_namespace+0xe9/0x132
>  [] ? walk_p2p_bridge+0x13b/0x13b
>  [] walk_p2p_bridge+0xf8/0x13b
>  [] ? acpi_os_signal_semaphore+0x76/0x87
>  [] ? walk_p2p_bridge+0x13b/0x13b
>  [] acpi_ns_walk_namespace+0x10f/0x24a
>  [] ? do_sta_before_sun+0x2b/0x2b
>  [] ? do_sta_before_sun+0x2b/0x2b
>  [] acpi_walk_namespace+0xe9/0x132
>  [] ? acpi_pci_root_add+0x3e7/0x49a
>  [] acpi_pci_slot_add+0xb2/0x103
>  [] ? walk_p2p_bridge+0x13b/0x13b
>  [] acpi_pci_root_add+0x3ff/0x49a
>
> which means that pci_bus->dev used in register_slot() has not been
> registered yet at that point.
>
> To fix this use the observation that before commit 1aeae82
> acpi_pci_slot_add() was always run after pci_bus_add_devices()
> and that happened to the acpiphp's .add() callback routine too.
> Thus it is safe to reorder acpi_pci_root_add() to make the PCI root
> drivers' .add() callbacks be run after pci_bus_add_devices(), so do
> that.
>
> This approach was previously proposed by Myron Stowe.
>
> References: https://patchwork.kernel.org/patch/1848781/
> Signed-off-by: Rafael J. Wysocki 
> ---
>
> The commit mentioned in the changelog above is in linux-pm.git/linux-next.
>
> Thanks,
> Rafael
>
> ---
>  drivers/acpi/pci_root.c |   13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> Index: test/drivers/acpi/pci_root.c
> ===
> --- test.orig/drivers/acpi/pci_root.c
> +++ test/drivers/acpi/pci_root.c
> @@ -600,17 +600,20 @@ static int acpi_pci_root_add(struct acpi
> if (system_state != SYSTEM_BOOTING)
> pci_assign_unassigned_bus_resources(root->bus);
>
> +   /* need to after hot-added ioapic is registered */
> +   if (system_state != SYSTEM_BOOTING)
> +   pci_enable_bridges(root->bus);
> +
> +   pci_bus_add_devices(root->bus);
> +
> mutex_lock(_pci_root_lock);
> +
> list_for_each_entry(driver, _pci_drivers, node)
> if (driver->add)
> driver->add(root);
> -   mutex_unlock(_pci_root_lock);
>
> -   /* need to after hot-added ioapic is registered */
> -   if (system_state != SYSTEM_BOOTING)
> -   pci_enable_bridges(root->bus);
> +   mutex_unlock(_pci_root_lock);
>
> -   pci_bus_add_devices(root->bus);
> return 1;
>
>  out_del_root:
>

No, we don't need this after

| commit 4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4
| PCI: Put pci_dev in device tree as early as possible

in pci/next.

So we can move that Jiang's patch from your tree to Bjorn's tree?

Thanks

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

[Simon Glass]

Hi Samuel,

On Tue, Feb 12, 2013 at 4:37 PM, Simon Glass  wrote:
> Hi Samuel,
>
> On Wed, Dec 12, 2012 at 1:33 PM, Simon Glass  wrote:
>> (get_maintainer.pl has produced an enormous list - I hope you are all
>> interested.)
>>
>> The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
>> used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
>> connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
>> line is used to indicate when the EC needs service.
>>
>> Functions performed by the EC vary by platform, but typically include
>> battery charging, keyboard scanning and power sequencing.
>>
>> This series includes support for the EC message protocol, and implements
>> a matrix keyboard handler for Linux using the protocol. The EC performs
>> key scanning and passes scan data in response to AP requests. This is
>> used on the Samsung ARM Chromebook. No driver is available for LPC at
>> present.
>>
>> This series can in principle operate on any hardware, but for it to actually
>> work on the Samsung ARM Chromebook, it needs patches which are currently in
>> progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.
>>
>> The driver is device-tree-enabled and a suitable binding is included in
>> this series. Example device tree nodes are included in the examples,
>> but no device tree patch for exynos5250-snow is provided at this stage, since
>> we must wait for the above-mentioned patches to land to avoid errors from
>> dtc. This can be added with a follow-on patch when that work is complete.
>>
>>
>> Simon Glass (5):
>>   mfd: Add ChromeOS EC messages header
>>   mfd: Add ChromeOS EC implementation
>>   mfd: Add ChromeOS EC I2C driver
>>   mfd: Add ChromeOS EC SPI driver
>>   Input: Add ChromeOS EC keyboard driver
>
> Are you planning to pick the mfd part of this series please? I am
> going to send a new version of the input patch on its own now that the
> DT binding is agreed.

Actually I see that __devinit/__devexit are gone in next/master. I
will resend the whole series again as v2. The first four patches are
for mfd and there will be two more for input.

Regards,
Simon

>>
>>  .../devicetree/bindings/input/cros-ec-keyb.txt |   77 ++
>>  Documentation/devicetree/bindings/mfd/cros-ec.txt  |   56 +
>>  drivers/input/keyboard/Kconfig |   10 +
>>  drivers/input/keyboard/Makefile|1 +
>>  drivers/input/keyboard/cros_ec_keyb.c  |  413 ++
>>  drivers/mfd/Kconfig|   28 +
>>  drivers/mfd/Makefile   |3 +
>>  drivers/mfd/cros_ec.c  |  219 
>>  drivers/mfd/cros_ec_i2c.c  |  262 
>>  drivers/mfd/cros_ec_spi.c  |  412 ++
>>  include/linux/mfd/cros_ec.h|  190 +++
>>  include/linux/mfd/cros_ec_commands.h   | 1369 
>> 
>>  12 files changed, 3040 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
>>  create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
>>  create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
>>  create mode 100644 drivers/mfd/cros_ec.c
>>  create mode 100644 drivers/mfd/cros_ec_i2c.c
>>  create mode 100644 drivers/mfd/cros_ec_spi.c
>>  create mode 100644 include/linux/mfd/cros_ec.h
>>  create mode 100644 include/linux/mfd/cros_ec_commands.h
>>
>> --
>> 1.7.7.3
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regulator: as3711: Fix checking if no platform initialization data

[Axel Lin]

To skip registering regulator if no platform initialization data,
we should check reg_data rather than ri->desc.name.

Signed-off-by: Axel Lin 
---
 drivers/regulator/as3711-regulator.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/as3711-regulator.c 
b/drivers/regulator/as3711-regulator.c
index 2f1341d..f0ba8c4 100644
--- a/drivers/regulator/as3711-regulator.c
+++ b/drivers/regulator/as3711-regulator.c
@@ -303,7 +303,7 @@ static int as3711_regulator_probe(struct platform_device 
*pdev)
reg_data = pdata ? pdata->init_data[id] : NULL;
 
/* No need to register if there is no regulator data */
-   if (!ri->desc.name)
+   if (!reg_data)
continue;
 
reg = [id];
-- 
1.7.9.5



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

[PATCH 2/2] regulator: s5m8767: Prevent possible NULL pointer dereference

[Axel Lin]

s5m8767_pmic_dt_parse_pdata dereferenes pdata, thus check pdata earlier to
avoid NULL pointer dereference.

Signed-off-by: Axel Lin 
---
 drivers/regulator/s5m8767.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index ef0532d..8a83194 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -659,17 +659,17 @@ static int s5m8767_pmic_probe(struct platform_device 
*pdev)
struct s5m8767_info *s5m8767;
int i, ret, size, buck_init;
 
+   if (!pdata) {
+   dev_err(pdev->dev.parent, "Platform data not supplied\n");
+   return -ENODEV;
+   }
+
if (iodev->dev->of_node) {
ret = s5m8767_pmic_dt_parse_pdata(pdev, pdata);
if (ret)
return ret;
}
 
-   if (!pdata) {
-   dev_err(pdev->dev.parent, "Platform data not supplied\n");
-   return -ENODEV;
-   }
-
if (pdata->buck2_gpiodvs) {
if (pdata->buck3_gpiodvs || pdata->buck4_gpiodvs) {
dev_err(>dev, "S5M8767 GPIO DVS NOT VALID\n");
-- 
1.7.9.5



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

[PATCH 1/2] regulator: s5m8767: Fix dev argument for devm_kzalloc and of_get_regulator_init_data

[Axel Lin]

Use >dev rather than iodev->dev for devm_kzalloc() and
of_get_regulator_init_data(), this fixes memory leak.

Signed-off-by: Axel Lin 
---
 drivers/regulator/s5m8767.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 194b5dd..ef0532d 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -515,9 +515,10 @@ static int s5m8767_pmic_dt_parse_ds_gpio(struct 
sec_pmic_dev *iodev,
return 0;
 }
 
-static int s5m8767_pmic_dt_parse_pdata(struct sec_pmic_dev *iodev,
+static int s5m8767_pmic_dt_parse_pdata(struct platform_device *pdev,
struct sec_platform_data *pdata)
 {
+   struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
struct device_node *pmic_np, *regulators_np, *reg_np;
struct sec_regulator_data *rdata;
struct sec_opmode_data *rmode;
@@ -538,7 +539,7 @@ static int s5m8767_pmic_dt_parse_pdata(struct sec_pmic_dev 
*iodev,
/* count the number of regulators to be supported in pmic */
pdata->num_regulators = of_get_child_count(regulators_np);
 
-   rdata = devm_kzalloc(iodev->dev, sizeof(*rdata) *
+   rdata = devm_kzalloc(>dev, sizeof(*rdata) *
pdata->num_regulators, GFP_KERNEL);
if (!rdata) {
dev_err(iodev->dev,
@@ -546,7 +547,7 @@ static int s5m8767_pmic_dt_parse_pdata(struct sec_pmic_dev 
*iodev,
return -ENOMEM;
}
 
-   rmode = devm_kzalloc(iodev->dev, sizeof(*rmode) *
+   rmode = devm_kzalloc(>dev, sizeof(*rmode) *
pdata->num_regulators, GFP_KERNEL);
if (!rdata) {
dev_err(iodev->dev,
@@ -570,7 +571,7 @@ static int s5m8767_pmic_dt_parse_pdata(struct sec_pmic_dev 
*iodev,
 
rdata->id = i;
rdata->initdata = of_get_regulator_init_data(
-   iodev->dev, reg_np);
+   >dev, reg_np);
rdata->reg_node = reg_np;
rdata++;
rmode->id = i;
@@ -642,7 +643,7 @@ static int s5m8767_pmic_dt_parse_pdata(struct sec_pmic_dev 
*iodev,
return 0;
 }
 #else
-static int s5m8767_pmic_dt_parse_pdata(struct sec_pmic_dev *iodev,
+static int s5m8767_pmic_dt_parse_pdata(struct platform_device *pdev,
struct sec_platform_data *pdata)
 {
return 0;
@@ -659,7 +660,7 @@ static int s5m8767_pmic_probe(struct platform_device *pdev)
int i, ret, size, buck_init;
 
if (iodev->dev->of_node) {
-   ret = s5m8767_pmic_dt_parse_pdata(iodev, pdata);
+   ret = s5m8767_pmic_dt_parse_pdata(pdev, pdata);
if (ret)
return ret;
}
-- 
1.7.9.5



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

Re: [PATCH 0/3] scheduler include file reorganization

[Namhyung Kim]

Hi,

On Mon, 11 Feb 2013 10:54:58 +0100, Ingo Molnar wrote:
> * Clark Williams  wrote:
>
>> I figured that was coming. :)
>
> ;-)
>
>> I'll look at it again and see about pulling the 
>> autogroup/cgroup stuff into it's own header. After that it's 
>> probably going to require some serious changes.
>> 
>> Any suggestions?
>
> I'd suggest doing it as finegrained as possible - potentially 
> one concept at a time. I wouldn't mind a dozen small files in 
> include/linux/sched/ - possibly more.

What about the .c files?  AFAICS the sched/core.c and sched/fair.c are
rather huge and contain various concepts which might be separated to
their own files.  It'd be better reorganizing them too IMHO.

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

Re: [PATCH] usb: musb: fix context save over suspend.

[Kevin Hilman]

NeilBrown  writes:

> On Tue, 12 Feb 2013 13:03:36 -0800 Kevin Hilman  wrote:
>
>> NeilBrown  writes:
>> 

[...]

>> My patch was fixing a real hang when musb was built-in (or loaded), in
>> host-mode (mini-A cable attached) but no devices attached.  I just tried
>> to reproduce this, and with your patch, the system hangs during suspend.
>> 
>
> Odd.  I plug in a mini-A cable, note that the 'mode' file holds
> 'a_idle' (sometimes just plugging in the cable isn't enough to trigger that,
> but sometimes it is) and suspend/resume work perfectly.  Though after
> resume it is back to b_idle.
>
> unplug/replug and it is back to  a_idle.  suspend/resume and back to b_idle.
>
>> That being said, your description makes sense why this context
>> save/restore is needed.  Perhaps your patch needs to add a check whether
>> the device is runtime suspended (I gather this is what Ruslan's patch is
>> doing.)
>
> I'm not sure it is possible for the device to be runtime suspended at this
> point.  Certainly my device never is, even if it was just before the suspend
> sequence started. Something is waking it up...
> (instruments the code).
>
> Ahh - usb_suspend() calls choose_wakeup() which might call
> pm_runtime_resume() if the could be a need to reprogram the wakeup setting.
> As that is a 'might', the device might not be runtime-awake when 'suspend'
> runs.
>
> Can you see if this, on top of my previous patch, does any better on your
> hardware?

Yes, this patch adding the check on top of your previous one makes
things work just fine on my hardware (3530/Overo).

Kevin

> Thanks,
> NeilBrown
>
>
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 956db0e..00deb94 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -2278,7 +2278,8 @@ static int musb_suspend(struct device *dev)
>   }
>  
>   spin_unlock_irqrestore(>lock, flags);
> - musb_save_context(musb);
> + if (!pm_runtime_status_suspended(dev))
> + musb_save_context(musb);
>   return 0;
>  }
>  
> @@ -2289,7 +2290,8 @@ static int musb_resume_noirq(struct device *dev)
>* module got reset through the PSC (vs just being disabled).
>*/
>   struct musb *musb = dev_to_musb(dev);
> - musb_restore_context(musb);
> + if (!pm_runtime_status_suspended(dev))
> + musb_restore_context(musb);
>   return 0;
>  }
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: musb: fix context save over suspend.

[NeilBrown]

On Tue, 12 Feb 2013 13:03:36 -0800 Kevin Hilman  wrote:

> NeilBrown  writes:
> 
> > On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg 
> > wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >> 
> >> Hi Neil,
> >> 
> >> On 01/21/13 11:28, NeilBrown wrote:
> >> > 
> >> > 
> >> > The standard suspend sequence involves runtime_resuming
> >> > devices before suspending the system.
> >> > So just saving context in runtime_suspend and restoring it
> >> > in runtime resume isn't enough.  We  must also save in "suspend"
> >> > and restore in "resume".
> >> > 
> >> > Without this patch, and OMAP3 system with off_mode enabled will find
> >> > the musb port non-functional after suspend/resume.  With the patch it
> >> > works perfectly.
> >> 
> >> Hmmm... Some time ago, this has been removed in
> >> 5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path)
> >> 
> >> Am I missing something? Or things changed and now this patch is correct?
> >
> > Hi Igor,
> >  thanks for alerting me to that patch  does anyone else get the feeling
> >  that power management to too complex to be understood by a mere human?
> 
> Yes.  ;)
> 
> >  That commit (5d193ce8) suggests that the musb-hdrc device is an
> >  'omap_device', or maybe has a PM domain set to something else.
> >  However it isn't/doesn't.  dev->pm_domain is NULL.  So no PM domain layer
> >  will ever call the musb_core musb_runtime_suspend/resume.
> >
> >  The parent device - musb-omap2430 - is an omap device, does have pm_domain
> >  set, and does have its omap2430_runtime_suspend/resume called for system
> >  suspend and so the context for that device is saved and restored.
> >  However that doesn't help the context for musb-hdrc.
> >
> >  Whether musb ever was an omap_device is beyond my archaeological skills to
> >  determine.
> >
> >  Kevin:  Was musb-hdrc ever a device with a pm_domain? or was it only ever
> >  the various possible parents that had domains?
> >  Are you able to defend your earlier patch in today's kernel?  It
> >  certainly causes my device not to work properly.
> 
> Sorry for the delay here, I'm back to a place where I can test this on
> real hardware.
> 
> My patch was fixing a real hang when musb was built-in (or loaded), in
> host-mode (mini-A cable attached) but no devices attached.  I just tried
> to reproduce this, and with your patch, the system hangs during suspend.
> 

Odd.  I plug in a mini-A cable, note that the 'mode' file holds
'a_idle' (sometimes just plugging in the cable isn't enough to trigger that,
but sometimes it is) and suspend/resume work perfectly.  Though after
resume it is back to b_idle.

unplug/replug and it is back to  a_idle.  suspend/resume and back to b_idle.

> That being said, your description makes sense why this context
> save/restore is needed.  Perhaps your patch needs to add a check whether
> the device is runtime suspended (I gather this is what Ruslan's patch is
> doing.)

I'm not sure it is possible for the device to be runtime suspended at this
point.  Certainly my device never is, even if it was just before the suspend
sequence started. Something is waking it up...
(instruments the code).

Ahh - usb_suspend() calls choose_wakeup() which might call
pm_runtime_resume() if the could be a need to reprogram the wakeup setting.
As that is a 'might', the device might not be runtime-awake when 'suspend'
runs.

Can you see if this, on top of my previous patch, does any better on your
hardware?

Thanks,
NeilBrown


diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 956db0e..00deb94 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2278,7 +2278,8 @@ static int musb_suspend(struct device *dev)
}
 
spin_unlock_irqrestore(>lock, flags);
-   musb_save_context(musb);
+   if (!pm_runtime_status_suspended(dev))
+   musb_save_context(musb);
return 0;
 }
 
@@ -2289,7 +2290,8 @@ static int musb_resume_noirq(struct device *dev)
 * module got reset through the PSC (vs just being disabled).
 */
struct musb *musb = dev_to_musb(dev);
-   musb_restore_context(musb);
+   if (!pm_runtime_status_suspended(dev))
+   musb_restore_context(musb);
return 0;
 }
 


signature.asc
Description: PGP signature

Re: [PATCH 1/1] Drivers: hv: vmbus: Use the new infrastructure for delivering VMBUS interrupts

[H. Peter Anvin]

On 02/12/2013 04:50 PM, KY Srinivasan wrote:
> 
> Apply them and I will rebase this patch and send it out.
> 

Pull the -tip tree and you can base it on the x86/hyperv branch.

-hpa


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

[tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

[tip-bot for K. Y. Srinivasan]

Commit-ID:  bc2b0331e077f576369a2b6c75d15ed4de4ef91f
Gitweb: http://git.kernel.org/tip/bc2b0331e077f576369a2b6c75d15ed4de4ef91f
Author: K. Y. Srinivasan 
AuthorDate: Sun, 3 Feb 2013 17:22:39 -0800
Committer:  H. Peter Anvin 
CommitDate: Tue, 12 Feb 2013 16:27:15 -0800

X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

Starting with win8, vmbus interrupts can be delivered on any VCPU in the guest
and furthermore can be concurrently active on multiple VCPUs. Support this
interrupt delivery model by setting up a separate IDT entry for Hyper-V vmbus.
interrupts. I would like to thank Jan Beulich  and
Thomas Gleixner , for their help.

In this version of the patch, based on the feedback, I have merged the IDT
vector for Xen and Hyper-V and made the necessary adjustments. Furhermore,
based on Jan's feedback I have added the necessary compilation switches.

Signed-off-by: K. Y. Srinivasan 
Link: 
http://lkml.kernel.org/r/1359940959-32168-3-git-send-email-...@microsoft.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/irq_vectors.h |  4 ++--
 arch/x86/include/asm/mshyperv.h|  4 
 arch/x86/kernel/cpu/mshyperv.c | 44 ++
 arch/x86/kernel/entry_32.S |  9 +++-
 arch/x86/kernel/entry_64.S |  7 +-
 drivers/xen/events.c   |  7 +++---
 6 files changed, 68 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/irq_vectors.h 
b/arch/x86/include/asm/irq_vectors.h
index 1508e51..aac5fa6 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -109,8 +109,8 @@
 
 #define UV_BAU_MESSAGE 0xf5
 
-/* Xen vector callback to receive events in a HVM domain */
-#define XEN_HVM_EVTCHN_CALLBACK0xf3
+/* Vector on which hypervisor callbacks will be delivered */
+#define HYPERVISOR_CALLBACK_VECTOR 0xf3
 
 /*
  * Local APIC timer IRQ vector is on a different priority level,
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 79ce568..c2934be 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -11,4 +11,8 @@ struct ms_hyperv_info {
 
 extern struct ms_hyperv_info ms_hyperv;
 
+void hyperv_callback_vector(void);
+void hyperv_vector_handler(struct pt_regs *regs);
+void hv_register_vmbus_handler(int irq, irq_handler_t handler);
+
 #endif
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 4dab317..a7d26d8 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -14,10 +14,15 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 struct ms_hyperv_info ms_hyperv;
 EXPORT_SYMBOL_GPL(ms_hyperv);
@@ -77,6 +82,12 @@ static void __init ms_hyperv_init_platform(void)
 
if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
clocksource_register_hz(_cs, NSEC_PER_SEC/100);
+#if IS_ENABLED(CONFIG_HYPERV)
+   /*
+* Setup the IDT for hypervisor callback.
+*/
+   alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, hyperv_callback_vector);
+#endif
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
@@ -85,3 +96,36 @@ const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = 
{
.init_platform  = ms_hyperv_init_platform,
 };
 EXPORT_SYMBOL(x86_hyper_ms_hyperv);
+
+#if IS_ENABLED(CONFIG_HYPERV)
+static int vmbus_irq = -1;
+static irq_handler_t vmbus_isr;
+
+void hv_register_vmbus_handler(int irq, irq_handler_t handler)
+{
+   vmbus_irq = irq;
+   vmbus_isr = handler;
+}
+
+void hyperv_vector_handler(struct pt_regs *regs)
+{
+   struct pt_regs *old_regs = set_irq_regs(regs);
+   struct irq_desc *desc;
+
+   irq_enter();
+   exit_idle();
+
+   desc = irq_to_desc(vmbus_irq);
+
+   if (desc)
+   generic_handle_irq_desc(vmbus_irq, desc);
+
+   irq_exit();
+   set_irq_regs(old_regs);
+}
+#else
+void hv_register_vmbus_handler(int irq, irq_handler_t handler)
+{
+}
+#endif
+EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 6ed91d9..8831176 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1091,11 +1091,18 @@ ENTRY(xen_failsafe_callback)
_ASM_EXTABLE(4b,9b)
 ENDPROC(xen_failsafe_callback)
 
-BUILD_INTERRUPT3(xen_hvm_callback_vector, XEN_HVM_EVTCHN_CALLBACK,
+BUILD_INTERRUPT3(xen_hvm_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
xen_evtchn_do_upcall)
 
 #endif /* CONFIG_XEN */
 
+#if IS_ENABLED(CONFIG_HYPERV)
+
+BUILD_INTERRUPT3(hyperv_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
+   hyperv_vector_handler)
+
+#endif /* CONFIG_HYPERV */
+
 #ifdef CONFIG_FUNCTION_TRACER
 #ifdef CONFIG_DYNAMIC_FTRACE
 
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index cb3c591..048f224 100644
--- 

[tip:x86/hyperv] X86: Add a check to catch Xen emulation of Hyper-V

[tip-bot for K. Y. Srinivasan]

Commit-ID:  db34bbb767bdfa1ebed7214b876fe01c5b7ee457
Gitweb: http://git.kernel.org/tip/db34bbb767bdfa1ebed7214b876fe01c5b7ee457
Author: K. Y. Srinivasan 
AuthorDate: Sun, 3 Feb 2013 17:22:38 -0800
Committer:  H. Peter Anvin 
CommitDate: Tue, 12 Feb 2013 16:27:03 -0800

X86: Add a check to catch Xen emulation of Hyper-V

Xen emulates Hyper-V to host enlightened Windows. Looks like this
emulation may be turned on by default even for Linux guests. Check and
fail Hyper-V detection if we are on Xen.

[ hpa: the problem here is that Xen doesn't emulate Hyper-V well
  enough, and if the Xen support isn't compiled in, we end up stubling
  over the Hyper-V emulation and try to activate it -- and it fails. ]

Signed-off-by: K. Y. Srinivasan 
Link: 
http://lkml.kernel.org/r/1359940959-32168-2-git-send-email-...@microsoft.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/cpu/mshyperv.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 646d192..4dab317 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
return false;
 
+   /*
+* Xen emulates Hyper-V to support enlightened Windows.
+* Check to see first if we are on a Xen Hypervisor.
+*/
+   if (xen_cpuid_base())
+   return false;
+
cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
  , _signature[0], _signature[1], _signature[2]);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/hyperv] x86: Hyper-V: register clocksource only if its advertised

[tip-bot for Olaf Hering]

Commit-ID:  32068f6527b8f1822a30671dedaf59c567325026
Gitweb: http://git.kernel.org/tip/32068f6527b8f1822a30671dedaf59c567325026
Author: Olaf Hering <[mailto:o...@aepfle.de]>
AuthorDate: Sun, 3 Feb 2013 17:22:37 -0800
Committer:  H. Peter Anvin 
CommitDate: Tue, 12 Feb 2013 16:25:48 -0800

x86: Hyper-V: register clocksource only if its advertised

Enable hyperv_clocksource only if its advertised as a feature.
XenServer 6 returns the signature which is checked in
ms_hyperv_platform(), but it does not offer all features. Currently the
clocksource is enabled unconditionally in ms_hyperv_init_platform(), and
the result is a hanging guest.

Hyper-V spec Bit 1 indicates the availability of Partition Reference
Counter.  Register the clocksource only if this bit is set.

The guest in question prints this in dmesg:
 [0.00] Hypervisor detected: Microsoft HyperV
 [0.00] HyperV: features 0x70, hints 0x0

This bug can be reproduced easily be setting 'viridian=1' in a HVM domU
.cfg file. A workaround without this patch is to boot the HVM guest with
'clocksource=jiffies'.

Signed-off-by: Olaf Hering 
Link: 
http://lkml.kernel.org/r/1359940959-32168-1-git-send-email-...@microsoft.com
Signed-off-by: K. Y. Srinivasan 
Cc: 
Cc: Greg KH 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/cpu/mshyperv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 0a630dd..646d192 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -68,7 +68,8 @@ static void __init ms_hyperv_init_platform(void)
printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
   ms_hyperv.features, ms_hyperv.hints);
 
-   clocksource_register_hz(_cs, NSEC_PER_SEC/100);
+   if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
+   clocksource_register_hz(_cs, NSEC_PER_SEC/100);
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Debugging Thinkpad T430s occasional suspend failure.

[Hugh Dickins]

On Tue, 12 Feb 2013, Dave Jones wrote:
> On Tue, Feb 12, 2013 at 04:26:22PM -0800, Hugh Dickins wrote:
>  > On Tue, 12 Feb 2013, Dave Jones wrote:
>  > 
>  > > My Thinkpad T430s suspend/resumes fine most of the time. But every so 
> often
>  > > (like one in ten times or so), as soon as I suspend, I get a black 
> screen,
>  > > and a blinking power button.
>  > > 
>  > > (Note: Not the capslock lights like when we panic, this laptop 
> 'conveniently
>  > >  doesn't have those. This is the light surrounding the power button, 
> which afaik
>  > >  isn't even OS controlled, so maybe we're dying somewhere in SMI/BIOS 
> land?)
>  > 
>  > Me too on T420s, except that is blessed with a blinking CapsLk.
>  > 
>  > It's so erratic (though I think I see more failures than you do: I'd say
>  > a quick resume never fails, but an overnight resume fails half the time):
>  > I'm afraid I didn't have the patience to embark on pm_trace at all.
> 
> Sounds like yours successfully suspends all the time though ?

So far as I can tell.

> For me, as soon as I shut the lid, the moon light starts flashing indicating 
> failure.

My moon light shines steadily.

> 
> That said, we saw that I was failing on the resume path after a failed 
> suspend,
> so it could still be the same problem.
> 
>  > I did try to bisect it during the -rc5 week.  I'm not sure, but I have
>  > no record of seeing it on -rc1 or -rc2, but definitely saw it on -rc3.
>  > So I tried bisecting between -rc2 and -rc3, persisting for a day if it
>  > looked good; but the bisection didn't seem to be converging anywhere
>  > likely when -rc6 came out, and I switched to see if -rc6 solved it.
>  > 
>  > I had no problem with -rc6; but with -rc7 it happens more than ever.
>  > Though still not on "quick" resumes, the kind you want to do when
>  > bisecting.
> 
> so I can hit this pretty quickly with this..
> 
> while [ 1 ];
> do
>  rtcwake -s 5 -m no ; pm-suspend
> done
> 
> Which should make it bisectable at least..

Thanks, I'll give that a try this evening.

> 
>  > Sharing these anecdotes in case they match or diverge from your
>  > experience and others, and might help towards finding the cause.
>  > Not-to-be-trusted bisection log appended: of course the bads are
>  > reliable, but perhaps none of the goods.
> 
> I didn't have this laptop pre 3.8rc, so I've not had a 'good' reference,
> pretty sure I saw it during rc1 though, so I might have to go back further
> a version or two.
> 
>   Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] Drivers: hv: vmbus: Use the new infrastructure for delivering VMBUS interrupts

[KY Srinivasan]

> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Tuesday, February 12, 2013 7:46 PM
> To: KY Srinivasan
> Cc: Greg KH; x...@kernel.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; t...@linutronix.de; jbeul...@suse.com; b...@alien8.de
> Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Use the new infrastructure for
> delivering VMBUS interrupts
> 
> On 02/12/2013 04:43 PM, KY Srinivasan wrote:
> >>
> >> This does not apply to v3.8-rc7 + the set of three vmbus patches for
> >> x86.  I take it there are additional dependencies -- K.Y., what do I
> >> need here?
> >
> > Do none of the earlier patches apply or just this patch. If none of them
> > apply, I could rebase all of them and resend them. Please let me know.
> >
> 
> The earlier (set of 3) patches apply just fine.

Apply them and I will rebase this patch and send it out.

Regards,

K. Y 
> 
>   -hpa
> 
> 
> 


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

Re: [PATCH] x86: Lock down MSR writing in secure boot

[H. Peter Anvin]

On 02/09/2013 07:11 AM, Matthew Garrett wrote:
> On Sat, 2013-02-09 at 10:29 +0100, Borislav Petkov wrote:
>> On Fri, Feb 08, 2013 at 10:45:35PM -0800, Kees Cook wrote:
>>> Also, _reading_ MSRs from userspace arguably has utility that doesn't
>>> compromise ring-0.
>>
>> And to come back to the original question: what is that utility, who
>> would need it on a secure boot system and why?
> 
> Things like Turbostat are useful, although perhaps that information
> should be exposed in a better way.
> 

OK... what none of this gets into:

Why should CAP_RAWIO be allowed on a secure boot system, when there are
2^n known ways of compromise a system with CAP_RAWIO?

-hpa

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

Re: [PATCH 1/1] Drivers: hv: vmbus: Use the new infrastructure for delivering VMBUS interrupts

[H. Peter Anvin]

On 02/12/2013 04:43 PM, KY Srinivasan wrote:
>>
>> This does not apply to v3.8-rc7 + the set of three vmbus patches for
>> x86.  I take it there are additional dependencies -- K.Y., what do I
>> need here?
> 
> Do none of the earlier patches apply or just this patch. If none of them
> apply, I could rebase all of them and resend them. Please let me know.
> 

The earlier (set of 3) patches apply just fine.

-hpa


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

Re: MAINTAINERS: Remove Mark M. Hoffman

[Andrew Morton]

On Fri, 8 Feb 2013 10:54:37 +0100
Jean Delvare  wrote:

> Mark M. Hoffman stopped working on the Linux kernel several years
> ago, so he should no longer be listed as a driver maintainer. I'm not
> even sure if his e-mail address still works.
> 
> I can take over 3 drivers he was responsible for, the 4th one will
> fall down to the subsystem maintainer.

It's nice to give developers a mention in ./CREDITS if we're to expunge
them from ./MAINTAINERS.  Something like this?

--- a/CREDITS~maintainers-remove-mark-m-hoffman-fix
+++ a/CREDITS
@@ -1510,6 +1510,11 @@ D: Natsemi ethernet
 D: Cobalt Networks (x86) support
 D: This-and-That
 
+N: Mark M. Hoffman
+E: mhoff...@lightlink.com
+D: Maintenance of drivers/hwmon/asb100.c, drivers/i2c/busses/i2c-sis96x.c
+D: i2c core contributions
+
 N: Dirk Hohndel
 E: hohn...@suse.de
 D: The XFree86[tm] Project
_

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

RE: [PATCH 1/1] Drivers: hv: vmbus: Use the new infrastructure for delivering VMBUS interrupts

[KY Srinivasan]

> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Tuesday, February 12, 2013 7:31 PM
> To: Greg KH
> Cc: KY Srinivasan; x...@kernel.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; t...@linutronix.de; jbeul...@suse.com; b...@alien8.de
> Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Use the new infrastructure for
> delivering VMBUS interrupts
> 
> On 02/06/2013 11:13 AM, Greg KH wrote:
> > On Wed, Feb 06, 2013 at 07:25:59AM -0800, K. Y. Srinivasan wrote:
> >> Use the infrastructure for delivering VMBUS interrupts using a
> >> special vector. With this patch, we can now properly handle
> >> the VMBUS interrupts that can be delivered on any CPU. Also,
> >> turn on interrupt load balancing as well.
> >>
> >> This patch requires the infrastructure that was implemented in the patch:
> >> X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
> >>
> >
> > Because of the dependancy, this should go through the x86 tree as well:
> > Acked-by: Greg Kroah-Hartman 
> >
> 
> This does not apply to v3.8-rc7 + the set of three vmbus patches for
> x86.  I take it there are additional dependencies -- K.Y., what do I
> need here?

Do none of the earlier patches apply or just this patch. If none of them
apply, I could rebase all of them and resend them. Please let me know.

Regards,

K. Y
> 
>   -hpa
> 
> 
> 


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

Re: Debugging Thinkpad T430s occasional suspend failure.

[Dave Jones]

On Tue, Feb 12, 2013 at 04:26:22PM -0800, Hugh Dickins wrote:
 > On Tue, 12 Feb 2013, Dave Jones wrote:
 > 
 > > My Thinkpad T430s suspend/resumes fine most of the time. But every so often
 > > (like one in ten times or so), as soon as I suspend, I get a black screen,
 > > and a blinking power button.
 > > 
 > > (Note: Not the capslock lights like when we panic, this laptop 
 > > 'conveniently
 > >  doesn't have those. This is the light surrounding the power button, which 
 > > afaik
 > >  isn't even OS controlled, so maybe we're dying somewhere in SMI/BIOS 
 > > land?)
 > 
 > Me too on T420s, except that is blessed with a blinking CapsLk.
 > 
 > It's so erratic (though I think I see more failures than you do: I'd say
 > a quick resume never fails, but an overnight resume fails half the time):
 > I'm afraid I didn't have the patience to embark on pm_trace at all.

Sounds like yours successfully suspends all the time though ?
For me, as soon as I shut the lid, the moon light starts flashing indicating 
failure.

That said, we saw that I was failing on the resume path after a failed suspend,
so it could still be the same problem.

 > I did try to bisect it during the -rc5 week.  I'm not sure, but I have
 > no record of seeing it on -rc1 or -rc2, but definitely saw it on -rc3.
 > So I tried bisecting between -rc2 and -rc3, persisting for a day if it
 > looked good; but the bisection didn't seem to be converging anywhere
 > likely when -rc6 came out, and I switched to see if -rc6 solved it.
 > 
 > I had no problem with -rc6; but with -rc7 it happens more than ever.
 > Though still not on "quick" resumes, the kind you want to do when
 > bisecting.

so I can hit this pretty quickly with this..

while [ 1 ];
do
 rtcwake -s 5 -m no ; pm-suspend
done

Which should make it bisectable at least..

 > Sharing these anecdotes in case they match or diverge from your
 > experience and others, and might help towards finding the cause.
 > Not-to-be-trusted bisection log appended: of course the bads are
 > reliable, but perhaps none of the goods.

I didn't have this laptop pre 3.8rc, so I've not had a 'good' reference,
pretty sure I saw it during rc1 though, so I might have to go back further
a version or two.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Bisected][-next-20130204+] [x86/kvm] udevd:[97]: segfault at ffffffffff5fd020 ip 00007fff069e277f sp 00007fff068c9ef8 error d

[H. Peter Anvin]

On 02/12/2013 04:26 PM, Peter Hurley wrote:
> With -next-20130204+ in ubuntu 12.10 VM (so the 80x25 VGA
> device/console):
> 
> [0.666410] udevd[97]: starting version 175
> [0.674043] udevd[97]: udevd:[97]: segfault at ff5fd020 ip 
> 7fff069e277f sp 7fff068c9ef8 error d
> 
> and boots to an initramfs prompt.
> 
> git bisect (log attached) blames:
> 
> commit 7b5c4a65cc27f017c170b025f8d6d75dabb11c6f
> Merge: 3596f5b 949db15
> Author: H. Peter Anvin 
> Date:   Fri Jan 25 16:31:21 2013 -0800
> 
> Merge tag 'v3.8-rc5' into x86/mm
> 
> The __pa() fixup series that follows touches KVM code that is not
> present in the existing branch based on v3.7-rc5, so merge in the
> current upstream from Linus.
> 
> Signed-off-by: H. Peter Anvin 
> 
> 
> This only happens with the VGA device/console but that is the default
> configuration for Ubuntu/KVM because it blacklists pretty much every fb
> driver.
> 

I am guessing this is another bad use of __pa()... need to look into that.

-hpa


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

Re: [PATCH 0/5] Add ChromeOS Embedded Controller support

[Simon Glass]

Hi Samuel,

On Wed, Dec 12, 2012 at 1:33 PM, Simon Glass  wrote:
> (get_maintainer.pl has produced an enormous list - I hope you are all
> interested.)
>
> The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
> used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
> connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
> line is used to indicate when the EC needs service.
>
> Functions performed by the EC vary by platform, but typically include
> battery charging, keyboard scanning and power sequencing.
>
> This series includes support for the EC message protocol, and implements
> a matrix keyboard handler for Linux using the protocol. The EC performs
> key scanning and passes scan data in response to AP requests. This is
> used on the Samsung ARM Chromebook. No driver is available for LPC at
> present.
>
> This series can in principle operate on any hardware, but for it to actually
> work on the Samsung ARM Chromebook, it needs patches which are currently in
> progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.
>
> The driver is device-tree-enabled and a suitable binding is included in
> this series. Example device tree nodes are included in the examples,
> but no device tree patch for exynos5250-snow is provided at this stage, since
> we must wait for the above-mentioned patches to land to avoid errors from
> dtc. This can be added with a follow-on patch when that work is complete.
>
>
> Simon Glass (5):
>   mfd: Add ChromeOS EC messages header
>   mfd: Add ChromeOS EC implementation
>   mfd: Add ChromeOS EC I2C driver
>   mfd: Add ChromeOS EC SPI driver
>   Input: Add ChromeOS EC keyboard driver

Are you planning to pick the mfd part of this series please? I am
going to send a new version of the input patch on its own now that the
DT binding is agreed.

Regards,
Simon

>
>  .../devicetree/bindings/input/cros-ec-keyb.txt |   77 ++
>  Documentation/devicetree/bindings/mfd/cros-ec.txt  |   56 +
>  drivers/input/keyboard/Kconfig |   10 +
>  drivers/input/keyboard/Makefile|1 +
>  drivers/input/keyboard/cros_ec_keyb.c  |  413 ++
>  drivers/mfd/Kconfig|   28 +
>  drivers/mfd/Makefile   |3 +
>  drivers/mfd/cros_ec.c  |  219 
>  drivers/mfd/cros_ec_i2c.c  |  262 
>  drivers/mfd/cros_ec_spi.c  |  412 ++
>  include/linux/mfd/cros_ec.h|  190 +++
>  include/linux/mfd/cros_ec_commands.h   | 1369 
> 
>  12 files changed, 3040 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
>  create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
>  create mode 100644 drivers/mfd/cros_ec.c
>  create mode 100644 drivers/mfd/cros_ec_i2c.c
>  create mode 100644 drivers/mfd/cros_ec_spi.c
>  create mode 100644 include/linux/mfd/cros_ec.h
>  create mode 100644 include/linux/mfd/cros_ec_commands.h
>
> --
> 1.7.7.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Drivers: hv: vmbus: Use the new infrastructure for delivering VMBUS interrupts

[H. Peter Anvin]

On 02/06/2013 11:13 AM, Greg KH wrote:
> On Wed, Feb 06, 2013 at 07:25:59AM -0800, K. Y. Srinivasan wrote:
>> Use the infrastructure for delivering VMBUS interrupts using a
>> special vector. With this patch, we can now properly handle
>> the VMBUS interrupts that can be delivered on any CPU. Also,
>> turn on interrupt load balancing as well.
>>
>> This patch requires the infrastructure that was implemented in the patch:
>> X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
>>
> 
> Because of the dependancy, this should go through the x86 tree as well:
>   Acked-by: Greg Kroah-Hartman 
> 

This does not apply to v3.8-rc7 + the set of three vmbus patches for
x86.  I take it there are additional dependencies -- K.Y., what do I
need here?

-hpa


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

Re: [PATCH V3] ia64/mm: fix a bad_page bug when crash kernel booting

[Tony Luck]

On Tue, Feb 12, 2013 at 4:19 PM, Andrew Morton
 wrote:
> But, umm, why am I sitting here trying to maintain an ia64 bugfix and
> handling bug reports from the ia64 maintainer?  Wanna swap?

That sounds like a plan.  I'll look out for a new version with the
missing #include
and less silly global variable names and try to take it before you
pull it into -mm

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

Re: [tip:x86/cpu] x86, AMD: Enable WC+ memory type on family 10 processors

[Borislav Petkov]

On Tue, Feb 12, 2013 at 04:21:13PM -0800, H. Peter Anvin wrote:
> On 02/12/2013 04:16 PM, Borislav Petkov wrote:
> >
> >This family check is redundant, we're already in a 0x10 if-branch
> >above. Boris had sent a second version which doesn't have that check:
> >http://marc.info/?l=linux-kernel=135949774114910 but I don't know how this
> >other version has gotten in.
> >
> >@hpa: maybe replace - patch is still at the top of tip:x86/cpu?
> >
> 
> I'll check with Ingo if that is doable.
> 
> >>+   rdmsrl(MSR_AMD64_BU_CFG2, value);
> >>+   value &= ~(1ULL << 24);
> >>+   wrmsrl(MSR_AMD64_BU_CFG2, value);
> >>+   }
> >>}
> >>
> >>rdmsr_safe(MSR_AMD64_PATCH_LEVEL, >microcode, );
> >
> >However, the more serious issue is that that same kernel #GPs when
> >booted in kvm. It seems it cannot stomach that specific MSR, see the
> >second "<-- trapping instruction" below and that BU_CFG2 MSR landing in
> >%ecx in the line before that.
> >
> >Oh, and this happens only with the kvm executable (/usr/bin/kvm) in
> >debian testing. If I use qemu from git, it passes over init_amd just
> >fine.
> >
> >Hmmm..
> >
> 
> It #GPs on an MSR, which tends to be a bug in the VMM; RDMSR/WRMSR
> generally kick out to the VMM.  There isn't a huge lot of work we
> can do about that...

Yeah, kvm.ko which runs on the host says that it ignores this MSR:

[160716.170333] kvm [29093]: vcpu0 unhandled rdmsr: 0xc001102a

> I think Qemu defaults to ignoring unknown-to-it MSRs whereas maybe
> kvmtool croaks?  Pekka?

Actually that's the qemu kvm thing you get from http://www.linux-kvm.org
not the kvmtool.

Let me add the kvm ML to CC.

Guys, when I start the guest in kvm, it #GPs early when
it tries to RDMSR 0xc001102a. Here's the oops message:
http://marc.info/?l=linux-kernel=136071460803452

qemu-kvm is qemu-kvm (1.1.2+dfsg-5) from debian testing. Command line is:

kvm -snapshot -gdb tcp::1234 -cpu phenom -hda 
/home/boris/kvm/debian/sid-x86_64.img -name "Debian x86_64:1235" -boot 
menu=off,order=c -m 2048 -localtime -net nic -net user,hostfwd=tcp::1235-:22 
-usbdevice tablet -kernel /w/kernel/linux-2.6/arch/x86/boot/bzImage -append 
"vga=0 root=/dev/sda1 debug ignore_loglevel console=ttyS0,115200 console=tty0" 
-serial file:/home/boris/kvm/test-x86_64.log

Any ideas?

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] avr32: atmel_default_console_device depends on CONFIG_SERIAL_ATMEL

[Hans-Christian Egtvedt]

Around Tue 12 Feb 2013 15:27:35 +0100 or thereabout, Geert Uytterhoeven wrote:
> allnoconfig:
> 
> arch/avr32/mach-at32ap/built-in.o: In function `at32_select_gpio':
> (.init.text+0x548): undefined reference to `atmel_default_console_device'

Indeed, I guess building without serial support has never been done.

> Signed-off-by: Geert Uytterhoeven 
>

Acked-by: Hans-Christian Egtvedt 

> ---
>  arch/avr32/mach-at32ap/at32ap700x.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/avr32/mach-at32ap/at32ap700x.c 
> b/arch/avr32/mach-at32ap/at32ap700x.c
> index b323d8d..a2fe61b 100644
> --- a/arch/avr32/mach-at32ap/at32ap700x.c
> +++ b/arch/avr32/mach-at32ap/at32ap700x.c
> @@ -1060,7 +1060,9 @@ struct platform_device *__init 
> at32_add_device_usart(unsigned int id)
>  
>  void __init at32_setup_serial_console(unsigned int usart_id)
>  {
> +#ifdef CONFIG_SERIAL_ATMEL
>   atmel_default_console_device = at32_usarts[usart_id];
> +#endif
>  }
>  
>  /* 
-- 
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Bisected][-next-20130204+] [x86/kvm] udevd:[97]: segfault at ffffffffff5fd020 ip 00007fff069e277f sp 00007fff068c9ef8 error d

[Peter Hurley]

With -next-20130204+ in ubuntu 12.10 VM (so the 80x25 VGA
device/console):

[0.666410] udevd[97]: starting version 175
[0.674043] udevd[97]: udevd:[97]: segfault at ff5fd020 ip 
7fff069e277f sp 7fff068c9ef8 error d

and boots to an initramfs prompt.

git bisect (log attached) blames:

commit 7b5c4a65cc27f017c170b025f8d6d75dabb11c6f
Merge: 3596f5b 949db15
Author: H. Peter Anvin 
Date:   Fri Jan 25 16:31:21 2013 -0800

Merge tag 'v3.8-rc5' into x86/mm

The __pa() fixup series that follows touches KVM code that is not
present in the existing branch based on v3.7-rc5, so merge in the
current upstream from Linus.

Signed-off-by: H. Peter Anvin 


This only happens with the VGA device/console but that is the default
configuration for Ubuntu/KVM because it blacklists pretty much every fb
driver.

I can confirm this _does not_ happen with same config on mainline
3.8-rc7.
Just confirmed that the same fault occurs with next-20130211.

Regards,
Peter Hurley
git bisect start
# good: [6bacaa9ddacb71c691d32c678d37bc59ffc71fac] Merge tag 'sound-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect good 6bacaa9ddacb71c691d32c678d37bc59ffc71fac
# bad: [164708bec016c6ceb76a2bb2e29b086bf0ad4e37] Add linux-next specific files for 20130204
git bisect bad 164708bec016c6ceb76a2bb2e29b086bf0ad4e37
# good: [0231bb5336758426b44ccd798ccd3c5419c95d58] perf: Fix event group context move
git bisect good 0231bb5336758426b44ccd798ccd3c5419c95d58
# good: [0ba3b2ccc72b3df5c305d61f59d93ab0f0e87991] USB: ftdi_sio: add Zolix FTDI PID
git bisect good 0ba3b2ccc72b3df5c305d61f59d93ab0f0e87991
# good: [8b31849a113a8868eb2de692be5c9ecadae93ac9] Merge git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
git bisect good 8b31849a113a8868eb2de692be5c9ecadae93ac9
# good: [972f7c832229781f09f03284cde484ccdb44d3ee] x86, doc: Boot protocol 2.12 is in 3.8
git bisect good 972f7c832229781f09f03284cde484ccdb44d3ee
# good: [da57b936ea7b328d1009b37a0a0ad1f14148e104] xtensa: Provide dummy dma_mmap_coherent() and dma_get_sgtable()
git bisect good da57b936ea7b328d1009b37a0a0ad1f14148e104
# good: [1927661b1748480692f1fa2c390fe031c86d862a] ASoC: fsl: fix snd-soc-imx-pcm module build
git bisect good 1927661b1748480692f1fa2c390fe031c86d862a
# good: [cff3c124a7e82ca0ea1d6864b27ef18c403c0773] sched/debug: Fix format string for 32-bit platforms
git bisect good cff3c124a7e82ca0ea1d6864b27ef18c403c0773
# good: [ce4a3d52888a95473914bd54bcf6c566014fc03e] [media] radio: set vfl_dir correctly to fix modulator regression
git bisect good ce4a3d52888a95473914bd54bcf6c566014fc03e
# good: [d36b7b9643faca8aab8cee8d824f75c800b337ac] Merge branch 'rcu/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/urgent
git bisect good d36b7b9643faca8aab8cee8d824f75c800b337ac
# good: [0ce82b7f7b7373b16ecf7b5725e21e2975204500] mtd: nand: onfi don't WARN if we are in 16 bits mode
git bisect good 0ce82b7f7b7373b16ecf7b5725e21e2975204500
# good: [58c49df378cde4ff64172483d593a1a5689c13a8] mtip32xx: fix for crash when the device surprise removed during rebuild
git bisect good 58c49df378cde4ff64172483d593a1a5689c13a8
# good: [11f6d5d6564613befc240ebf9620c80fabe74c1a] Merge remote-tracking branch 'spi-mb/spi-next'
git bisect good 11f6d5d6564613befc240ebf9620c80fabe74c1a
# bad: [df3de4831a52f71e3f5ce3ca67de885f9bcf6fed] Merge remote-tracking branch 'driver-core/driver-core-next'
git bisect bad df3de4831a52f71e3f5ce3ca67de885f9bcf6fed
# good: [ce68648792ba859fe11075f507909970ae5e1ba4] kvm tools: remove unused field from virtio-blk
git bisect good ce68648792ba859fe11075f507909970ae5e1ba4
# bad: [81f3c277544d5359e4bf3fdfd2c4495a288d67ff] Merge remote-tracking branch 'fw-nohz/nohz/next'
git bisect bad 81f3c277544d5359e4bf3fdfd2c4495a288d67ff
# good: [0e04f53a4310c2376a40a3eaf4cd74822534b7c2] Merge branch 'x86/microcode'
git bisect good 0e04f53a4310c2376a40a3eaf4cd74822534b7c2
# bad: [e761e0bbb991c0a0eaf59b5d61feebf3185f58bd] Merge remote-tracking branch 'rcu/rcu/next'
git bisect bad e761e0bbb991c0a0eaf59b5d61feebf3185f58bd
# good: [38dbe0b137bfe6ea92be495017885c0785179a02] tracing: Remove second iterator initializer
git bisect good 38dbe0b137bfe6ea92be495017885c0785179a02
# bad: [152aa0e8ad77111b82ebe655c559b58f5dec0981] Merge remote-tracking branch 'tip/auto-latest'
git bisect bad 152aa0e8ad77111b82ebe655c559b58f5dec0981
# bad: [5dfd486c4750c9278c63fa96e6e85bdd2fb58e9d] x86, kvm: Fix kvm's use of __pa() on percpu areas
git bisect bad 5dfd486c4750c9278c63fa96e6e85bdd2fb58e9d
# good: [6a3956bd242926f8956992f6ed7805b0811be003] x86/lguest: Use __pa_symbol instead of __pa on C visible symbols
git bisect good 6a3956bd242926f8956992f6ed7805b0811be003
# bad: [7b5c4a65cc27f017c170b025f8d6d75dabb11c6f] Merge tag 'v3.8-rc5' into x86/mm
git bisect bad 7b5c4a65cc27f017c170b025f8d6d75dabb11c6f
# good: [5e4bf1a55da976a5ed60901bb8801f1024ef9774] x86/mm: Don't flush the TLB on #WP pmd fixups
git bisect 

Re: Debugging Thinkpad T430s occasional suspend failure.

[Hugh Dickins]

On Tue, 12 Feb 2013, Dave Jones wrote:

> My Thinkpad T430s suspend/resumes fine most of the time. But every so often
> (like one in ten times or so), as soon as I suspend, I get a black screen,
> and a blinking power button.
> 
> (Note: Not the capslock lights like when we panic, this laptop 'conveniently
>  doesn't have those. This is the light surrounding the power button, which 
> afaik
>  isn't even OS controlled, so maybe we're dying somewhere in SMI/BIOS land?)

Me too on T420s, except that is blessed with a blinking CapsLk.

It's so erratic (though I think I see more failures than you do: I'd say
a quick resume never fails, but an overnight resume fails half the time):
I'm afraid I didn't have the patience to embark on pm_trace at all.

I did try to bisect it during the -rc5 week.  I'm not sure, but I have
no record of seeing it on -rc1 or -rc2, but definitely saw it on -rc3.
So I tried bisecting between -rc2 and -rc3, persisting for a day if it
looked good; but the bisection didn't seem to be converging anywhere
likely when -rc6 came out, and I switched to see if -rc6 solved it.

I had no problem with -rc6; but with -rc7 it happens more than ever.
Though still not on "quick" resumes, the kind you want to do when
bisecting.

Sharing these anecdotes in case they match or diverge from your
experience and others, and might help towards finding the cause.
Not-to-be-trusted bisection log appended: of course the bads are
reliable, but perhaps none of the goods.

Hugh

> 
> I tried debugging this with pm_trace, which told me..
> 
> [4.576035]   Magic number: 0:455:740
> [4.576037]   hash matches drivers/base/power/main.c:645
> 
> Which points me at..
> 
>  642  Complete:
>  643 complete_all(>power.completion);
>  644 
>  645 TRACE_RESUME(error);
>  646 
>  647 return error;
>  648 }
> 
> The only thing interesting here I think is that this is the resume path.
> So perhaps something failed to suspend, and we tried to back out of 
> suspending,
> but something was too screwed up to abort cleanly ?
> 
> I've tried hooking up a serial console, and even tried console_noblank, 
> which yielded no additional info at all. (I'm guessing the consoles are 
> suspended
> at the time of panic)
> 
> I also tried unloading all the modules I have loaded before the suspend, which
> seemed to reduce the chances of it happening, but eventually it reoccurred.
> 
> Any ideas on how I can further debug this ?
> 
>   Dave

git bisect start
# good: [d1c3ed669a2d452cacfb48c2d171a1f364dae2ed] Linux 3.8-rc2
git bisect good d1c3ed669a2d452cacfb48c2d171a1f364dae2ed
# bad: [9931faca02c604c22335f5a935a501bb2ace6e20] Linux 3.8-rc3
git bisect bad 9931faca02c604c22335f5a935a501bb2ace6e20
# bad: [36a25de23359940b7713fc40cbcbb046b3797511] sctp: fix Kconfig bug in 
default cookie hmac selection
git bisect bad 36a25de23359940b7713fc40cbcbb046b3797511
# good: [49569646b2413ee1a4fb7c4537fca058ac22292e] Merge tag 
'driver-core-3.8-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
git bisect good 49569646b2413ee1a4fb7c4537fca058ac22292e
# good: [251741b130c4396d5076f8e0e685cd8883ba39c0] MAINTAINERS: fix 
drivers/ieee802154/
git bisect good 251741b130c4396d5076f8e0e685cd8883ba39c0
# good: [d0631c6e09f51e094ae5aec1eabe81cc63d78178] Merge branch 'akpm' (fixes 
from Andrew)
git bisect good d0631c6e09f51e094ae5aec1eabe81cc63d78178
# good: [5ce2955e04a80da7287dc12f32da7f870039bf8f] Merge branch 'upstream' of 
git://git.linux-mips.org/pub/scm/ralf/upstream-linus
git bisect good 5ce2955e04a80da7287dc12f32da7f870039bf8f
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 for-3.8] net, sctp: remove CONFIG_EXPERIMENTAL

[David Rientjes]

From: Kees Cook 

This config item has not carried much meaning for a while now and is
almost always enabled by default. As agreed during the Linux kernel
summit, remove it.

Acked-by: David S. Miller 
Acked-by: Vlad Yasevich 
Signed-off-by: Kees Cook 
Signed-off-by: David Rientjes 
---
 Ah, look what I found in my mailbox from October 23.  The patch for dlm
 was merged, but this wasn't for some reason.  It's acked by the 
 maintainer so it should be good to go and fixes the reported build error:

net/built-in.o: In function `sctp_crc32c':
include/net/sctp/checksum.h:51: undefined reference to `crc32c'
include/net/sctp/checksum.h:51: undefined reference to `crc32c'
include/net/sctp/checksum.h:51: undefined reference to `crc32c'
include/net/sctp/checksum.h:51: undefined reference to `crc32c'
include/net/sctp/checksum.h:51: undefined reference to `crc32c'
net/built-in.o:include/net/sctp/checksum.h:51: more undefined 
references to `crc32c' follow

 And I guess "dlm not being marked experimental for a long time" meant
 three months.

 net/sctp/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
--- a/net/sctp/Kconfig
+++ b/net/sctp/Kconfig
@@ -3,8 +3,8 @@
 #
 
 menuconfig IP_SCTP
-   tristate "The SCTP Protocol (EXPERIMENTAL)"
-   depends on INET && EXPERIMENTAL
+   tristate "The SCTP Protocol"
+   depends on INET
depends on IPV6 || IPV6=n
select CRYPTO
select CRYPTO_HMAC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:x86/cpu] x86, AMD: Enable WC+ memory type on family 10 processors

[H. Peter Anvin]

On 02/12/2013 04:16 PM, Borislav Petkov wrote:


This family check is redundant, we're already in a 0x10 if-branch
above. Boris had sent a second version which doesn't have that check:
http://marc.info/?l=linux-kernel=135949774114910 but I don't know how this
other version has gotten in.

@hpa: maybe replace - patch is still at the top of tip:x86/cpu?



I'll check with Ingo if that is doable.


+   rdmsrl(MSR_AMD64_BU_CFG2, value);
+   value &= ~(1ULL << 24);
+   wrmsrl(MSR_AMD64_BU_CFG2, value);
+   }
}

rdmsr_safe(MSR_AMD64_PATCH_LEVEL, >microcode, );


However, the more serious issue is that that same kernel #GPs when
booted in kvm. It seems it cannot stomach that specific MSR, see the
second "<-- trapping instruction" below and that BU_CFG2 MSR landing in
%ecx in the line before that.

Oh, and this happens only with the kvm executable (/usr/bin/kvm) in
debian testing. If I use qemu from git, it passes over init_amd just
fine.

Hmmm..



It #GPs on an MSR, which tends to be a bug in the VMM; RDMSR/WRMSR 
generally kick out to the VMM.  There isn't a huge lot of work we can do 
about that...


I think Qemu defaults to ignoring unknown-to-it MSRs whereas maybe 
kvmtool croaks?  Pekka?


-hpa


--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ia64/mm: fix a bad_page bug when crash kernel booting

[Andrew Morton]

On Tue, 12 Feb 2013 16:11:33 -0800
Tony Luck  wrote:

> Building linux-next today (tag next-20130212) I get the following errors when
> building arch/ia64/configs/{tiger_defconfig, zx1_defconfig, bigsur_defconfig,
> sim_defconfig}
> 
> arch/ia64/mm/init.c: In function 'free_initrd_mem':
> arch/ia64/mm/init.c:215: error: 'max_addr' undeclared (first use in
> this function)
> arch/ia64/mm/init.c:215: error: (Each undeclared identifier is
> reported only once
> arch/ia64/mm/init.c:215: error: for each function it appears in.)
> arch/ia64/mm/init.c:216: error: implicit declaration of function
> 'GRANULEROUNDDOWN'
> 

`max_addr' is an awesomely bad name for a global identifier, btw.

And this:

-static u64 mem_limit = ~0UL, max_addr = ~0UL, min_addr = 0UL;
+u64 mem_limit = ~0UL, max_addr = ~0UL, min_addr = 0UL;

needlessly exported `mem_limit' and `min_addr' as well.  These too are
very poor global identifiers.

Also, Matt suggested an alternative implementation which afaik hasn't
been responded to.


I think I'll just drop the 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 V3] ia64/mm: fix a bad_page bug when crash kernel booting

[Andrew Morton]

On Tue, 12 Feb 2013 16:11:33 -0800
Tony Luck  wrote:

> Building linux-next today (tag next-20130212) I get the following errors when
> building arch/ia64/configs/{tiger_defconfig, zx1_defconfig, bigsur_defconfig,
> sim_defconfig}
> 
> arch/ia64/mm/init.c: In function 'free_initrd_mem':
> arch/ia64/mm/init.c:215: error: 'max_addr' undeclared (first use in
> this function)
> arch/ia64/mm/init.c:215: error: (Each undeclared identifier is
> reported only once
> arch/ia64/mm/init.c:215: error: for each function it appears in.)
> arch/ia64/mm/init.c:216: error: implicit declaration of function
> 'GRANULEROUNDDOWN'
> 
> with "git blame" saying that these lines in init.c were added/changed by
> 
> commit 5a54b4fb8f554b15c6113e30ca8412b7fe11c62e
> Author: Xishi Qiu 
> Date:   Thu Feb 7 12:25:59 2013 +1100
> 
> ia64/mm: fix a bad_page bug when crash kernel booting
> 

Presumably this:

--- 
a/arch/ia64/mm/init.c~ia64-mm-fix-a-bad_page-bug-when-crash-kernel-booting-fix
+++ a/arch/ia64/mm/init.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
_


But, umm, why am I sitting here trying to maintain an ia64 bugfix and
handling bug reports from the ia64 maintainer?  Wanna swap?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 109/173] drm/i915: Close race between processing unpin task and queueing the flip

[Ben Hutchings]

On Tue, Feb 12, 2013 at 09:02:45PM -0200, Herton Ronaldo Krzesinski wrote:
> On Fri, Dec 28, 2012 at 08:05:19PM +0100, Ben Hutchings wrote:
> > 3.2-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Chris Wilson 
> > 
> > commit e7d841ca03b7ab668620045cd7b428eda9f41601 upstream.
> > 
> [...]
> > @@ -7157,6 +7176,10 @@ static int intel_gen4_queue_flip(struct
> > pf = 0;
> > pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff;
> > OUT_RING(pf | pipesrc);
> > +
> > +   intel_mark_page_flip_active(intel_crtc);
> > +
> > +   intel_mark_page_flip_active(intel_crtc);
> > ADVANCE_LP_RING();
> > return 0;
> >  
> 
> There is a problem with this patch on 3.2. First we have
> intel_mark_page_flip_active duplicated on intel_gen4_queue_flip here
> (harmless), but one missing call for it in intel_gen6_queue_flip

Yes, Julien Cristau also pointed this out.  I'm not sure how this
happened.

It does seem that quilt (presumably calling GNU patch?) can sometimes
apply two hunks that overlap, and maybe that's part of the explanation
for this.  In 3.2.38 there was one patch where a blank line was the
last line of context in one hunk and also the first line of context
for the next hunk.  (Upstream, there was an extra statement in
between, but this was not present in 3.2.y.)  quilt applied the patch
without complaint (with --fuzz=0) but git am rejected it.

> Reached to this after reproducing which is probably the same
> problem people are reporting here: http://bugs.launchpad.net/bugs/1119809
> A bisect pointed to this change, and the following diff fixed the issue
> on the i915 based machine I used to reproduce:
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 4da3c7e..ce23961 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7155,8 +7155,6 @@ static int intel_gen4_queue_flip(struct drm_device *dev,
>   OUT_RING(pf | pipesrc);
>  
>   intel_mark_page_flip_active(intel_crtc);
> -
> - intel_mark_page_flip_active(intel_crtc);
>   ADVANCE_LP_RING();
>   return 0;
>  
> @@ -7192,6 +7190,8 @@ static int intel_gen6_queue_flip(struct drm_device *dev,
>   pf = I915_READ(PF_CTL(intel_crtc->pipe)) & PF_ENABLE;
>   pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff;
>   OUT_RING(pf | pipesrc);
> +
> + intel_mark_page_flip_active(intel_crtc);
>   ADVANCE_LP_RING();
>   return 0;
>  
 
Thanks, but I have the same fix in the patch queue already.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:x86/cpu] x86, AMD: Enable WC+ memory type on family 10 processors

[Borislav Petkov]

Two issues I got with this one, see below.

On Thu, Jan 31, 2013 at 02:45:06PM -0800, tip-bot for Boris Ostrovsky wrote:
> Commit-ID:  f0322bd341fd63261527bf84afd3272bcc2e8dd3
> Gitweb: http://git.kernel.org/tip/f0322bd341fd63261527bf84afd3272bcc2e8dd3
> Author: Boris Ostrovsky 
> AuthorDate: Tue, 29 Jan 2013 16:32:49 -0500
> Committer:  H. Peter Anvin 
> CommitDate: Thu, 31 Jan 2013 13:35:38 -0800
> 
> x86, AMD: Enable WC+ memory type on family 10 processors
> 
> In some cases BIOS may not enable WC+ memory type on family 10
> processors, instead converting what would be WC+ memory to CD type.
> On guests using nested pages this could result in performance
> degradation. This patch enables WC+.
> 
> Signed-off-by: Boris Ostrovsky 
> Link: 
> http://lkml.kernel.org/r/1359495169-23278-1-git-send-email-o...@amd64.org
> Signed-off-by: H. Peter Anvin 
> ---
>  arch/x86/include/uapi/asm/msr-index.h |  1 +
>  arch/x86/kernel/cpu/amd.c | 21 -
>  2 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/include/uapi/asm/msr-index.h 
> b/arch/x86/include/uapi/asm/msr-index.h
> index 433a59f..158cde9 100644
> --- a/arch/x86/include/uapi/asm/msr-index.h
> +++ b/arch/x86/include/uapi/asm/msr-index.h
> @@ -173,6 +173,7 @@
>  #define MSR_AMD64_OSVW_ID_LENGTH 0xc0010140
>  #define MSR_AMD64_OSVW_STATUS0xc0010141
>  #define MSR_AMD64_DC_CFG 0xc0011022
> +#define MSR_AMD64_BU_CFG20xc001102a
>  #define MSR_AMD64_IBSFETCHCTL0xc0011030
>  #define MSR_AMD64_IBSFETCHLINAD  0xc0011031
>  #define MSR_AMD64_IBSFETCHPHYSAD 0xc0011032
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index dd4a5b6..721ef32 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -698,13 +698,11 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
>   if (c->x86 > 0x11)
>   set_cpu_cap(c, X86_FEATURE_ARAT);
>  
> - /*
> -  * Disable GART TLB Walk Errors on Fam10h. We do this here
> -  * because this is always needed when GART is enabled, even in a
> -  * kernel which has no MCE support built in.
> -  */
>   if (c->x86 == 0x10) {
>   /*
> +  * Disable GART TLB Walk Errors on Fam10h. We do this here
> +  * because this is always needed when GART is enabled, even in a
> +  * kernel which has no MCE support built in.
>* BIOS should disable GartTlbWlk Errors themself. If
>* it doesn't do it here as suggested by the BKDG.
>*
> @@ -718,6 +716,19 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
>   mask |= (1 << 10);
>   wrmsrl_safe(MSR_AMD64_MCx_MASK(4), mask);
>   }
> +
> + /*
> +  * On family 10h BIOS may not have properly enabled WC+ support,
> +  * causing it to be converted to CD memtype. This may result in
> +  * performance degradation for certain nested-paging guests.
> +  * Prevent this conversion by clearing bit 24 in
> +  * MSR_AMD64_BU_CFG2.
> +  */
> + if (c->x86 == 0x10) {

This family check is redundant, we're already in a 0x10 if-branch
above. Boris had sent a second version which doesn't have that check:
http://marc.info/?l=linux-kernel=135949774114910 but I don't know how this
other version has gotten in.

@hpa: maybe replace - patch is still at the top of tip:x86/cpu?

> + rdmsrl(MSR_AMD64_BU_CFG2, value);
> + value &= ~(1ULL << 24);
> + wrmsrl(MSR_AMD64_BU_CFG2, value);
> + }
>   }
>  
>   rdmsr_safe(MSR_AMD64_PATCH_LEVEL, >microcode, );

However, the more serious issue is that that same kernel #GPs when
booted in kvm. It seems it cannot stomach that specific MSR, see the
second "<-- trapping instruction" below and that BU_CFG2 MSR landing in
%ecx in the line before that.

Oh, and this happens only with the kvm executable (/usr/bin/kvm) in
debian testing. If I use qemu from git, it passes over init_amd just
fine.

Hmmm..

[0.018000] general protection fault:  [#1] PREEMPT SMP 
[0.018000] Modules linked in:
[0.018000] CPU 0 
[0.018000] Pid: 0, comm: swapper/0 Not tainted 3.8.0-rc6+ #3 Bochs Bochs
[0.018000] RIP: 0010:[]  [] 
init_amd+0x4d6/0x50d
[0.018000] RSP: :81813ed8  EFLAGS: 00010246
[0.018000] RAX:  RBX: 00726f73 RCX: c001102a
[0.018000] RDX: 8268b021 RSI: fffb RDI: 0005
[0.018000] RBP: 81813f28 R08:  R09: 
[0.018000] R10: 0001 R11:  R12: 8189e140
[0.018000] R13: 81af82e0 R14: 88007ffd0300 R15: 
[0.018000] FS:  () GS:88007fc0() 

[PATCH] ACPI / hotplug: Fix concurrency issues and memory leaks

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.

First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.

For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.

Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection.  In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue.  To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).

Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening.  It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case.  Modify the code accordingly.

Signed-off-by: Rafael J. Wysocki 
---

On top of linux-pm.git/linux-next.

Thanks,
Rafael

---
 drivers/acpi/acpi_memhotplug.c |   56 +++---
 drivers/acpi/container.c   |   10 +++--
 drivers/acpi/dock.c|   19 --
 drivers/acpi/processor_driver.c|   24 +---
 drivers/acpi/scan.c|   69 +
 drivers/pci/hotplug/acpiphp_glue.c |6 +++
 drivers/pci/hotplug/sgi_hotplug.c  |5 ++
 include/acpi/acpi_bus.h|3 +
 8 files changed, 138 insertions(+), 54 deletions(-)

Index: test/drivers/acpi/scan.c
===
--- test.orig/drivers/acpi/scan.c
+++ test/drivers/acpi/scan.c
@@ -42,6 +42,18 @@ struct acpi_device_bus_id{
struct list_head node;
 };
 
+void acpi_scan_lock_acquire(void)
+{
+   mutex_lock(_scan_lock);
+}
+EXPORT_SYMBOL_GPL(acpi_scan_lock_acquire);
+
+void acpi_scan_lock_release(void)
+{
+   mutex_unlock(_scan_lock);
+}
+EXPORT_SYMBOL_GPL(acpi_scan_lock_release);
+
 int acpi_scan_add_handler(struct acpi_scan_handler *handler)
 {
if (!handler || !handler->attach)
@@ -95,8 +107,6 @@ acpi_device_modalias_show(struct device
 }
 static DEVICE_ATTR(modalias, 0444, acpi_device_modalias_show, NULL);
 
-static void __acpi_bus_trim(struct acpi_device *start);
-
 /**
  * acpi_bus_hot_remove_device: hot-remove a device and its children
  * @context: struct acpi_eject_event pointer (freed in this func)
@@ -107,7 +117,7 @@ static void __acpi_bus_trim(struct acpi_
  */
 void acpi_bus_hot_remove_device(void *context)
 {
-   struct acpi_eject_event *ej_event = (struct acpi_eject_event *) context;
+   struct acpi_eject_event *ej_event = context;
struct acpi_device *device = ej_event->device;
acpi_handle handle = device->handle;
acpi_handle temp;
@@ -118,11 +128,19 @@ void acpi_bus_hot_remove_device(void *co
 
mutex_lock(_scan_lock);
 
+   /* If there is no handle, the device node has been unregistered. */
+   if (!device->handle) {
+   dev_dbg(>dev, "ACPI handle missing\n");
+   put_device(>dev);
+   goto out;
+   }
+
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Hot-removing device %s...\n", dev_name(>dev)));
 
-   __acpi_bus_trim(device);
-   /* Device node has been released. */
+   acpi_bus_trim(device);
+   /* Device node has been unregistered. */
+   put_device(>dev);
  

[tip:x86/asm] x86, head_32: Give the 6 label a real name

[tip-bot for Borislav Petkov]

Commit-ID:  5e2a044daf0c6f897eb69de931e3b29020e874a9
Gitweb: http://git.kernel.org/tip/5e2a044daf0c6f897eb69de931e3b29020e874a9
Author: Borislav Petkov 
AuthorDate: Mon, 11 Feb 2013 15:22:18 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 12 Feb 2013 15:48:42 -0800

x86, head_32: Give the 6 label a real name

Jumping here we are about to enable paging so rename the label
accordingly.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1360592538-10643-5-git-send-email...@alien8.de
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/head_32.S | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 2e8532e..3c3f58a 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -329,7 +329,7 @@ default_entry:
pushfl
popl %eax   # get EFLAGS
testl $X86_EFLAGS_ID,%eax   # did EFLAGS.ID remained set?
-   jz 6f   # hw disallowed setting of ID bit
+   jz enable_paging# hw disallowed setting of ID bit
# which means no CPUID and no CR4
 
xorl %eax,%eax
@@ -339,13 +339,13 @@ default_entry:
movl $1,%eax
cpuid
andl $~1,%edx   # Ignore CPUID.FPU
-   jz 6f   # No flags or only CPUID.FPU = no CR4
+   jz enable_paging# No flags or only CPUID.FPU = no CR4
 
movl pa(mmu_cr4_features),%eax
movl %eax,%cr4
 
testb $X86_CR4_PAE, %al # check if PAE is enabled
-   jz 6f
+   jz enable_paging
 
/* Check if extended functions are implemented */
movl $0x8000, %eax
@@ -353,7 +353,7 @@ default_entry:
/* Value must be in the range 0x8001 to 0x8000 */
subl $0x8001, %eax
cmpl $(0x8000-0x8001), %eax
-   ja 6f
+   ja enable_paging
 
/* Clear bogus XD_DISABLE bits */
call verify_cpu
@@ -362,7 +362,7 @@ default_entry:
cpuid
/* Execute Disable bit supported? */
btl $(X86_FEATURE_NX & 31), %edx
-   jnc 6f
+   jnc enable_paging
 
/* Setup EFER (Extended Feature Enable Register) */
movl $MSR_EFER, %ecx
@@ -372,7 +372,7 @@ default_entry:
/* Make changes effective */
wrmsr
 
-6:
+enable_paging:
 
 /*
  * Enable paging
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/asm] x86, head_32: Remove second CPUID detection from default_entry

[tip-bot for Borislav Petkov]

Commit-ID:  c3a22a26d07d928e2b74b58e2f9d2436958620f0
Gitweb: http://git.kernel.org/tip/c3a22a26d07d928e2b74b58e2f9d2436958620f0
Author: Borislav Petkov 
AuthorDate: Mon, 11 Feb 2013 15:22:17 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 12 Feb 2013 15:48:42 -0800

x86, head_32: Remove second CPUID detection from default_entry

We do that once earlier now and cache it into new_cpu_data.cpuid_level
so no need for the EFLAGS.ID toggling dance anymore.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1360592538-10643-4-git-send-email...@alien8.de
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/head_32.S | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index e3725a0..2e8532e 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -399,18 +399,7 @@ default_entry:
 /*
  * Check if it is 486
  */
-   movl $-1,X86_CPUID  # -1 for no CPUID initially
-   movb $4,X86 # at least 486
-   pushfl  # push EFLAGS
-   popl %eax   # get EFLAGS
-   movl %eax,%ecx  # save original EFLAGS
-   xorl $0x20,%eax # flip ID bit in EFLAGS
-   pushl %eax  # copy to EFLAGS
-   popfl   # set EFLAGS
-   pushfl  # get new EFLAGS
-   popl %eax   # put it in eax
-   xorl %ecx,%eax  # change in flags
-   testl $0x20,%eax# check if ID bit changed
+   cmpl $-1,X86_CPUID
je is486
 
/* get vendor info */
@@ -436,7 +425,9 @@ default_entry:
movb %cl,X86_MASK
movl %edx,X86_CAPABILITY
 
-is486: movl $0x50022,%ecx  # set AM, WP, NE and MP
+is486:
+   movb $4,X86
+   movl $0x50022,%ecx  # set AM, WP, NE and MP
movl %cr0,%eax
andl $0x8011,%eax   # Save PG,PE,ET
orl %ecx,%eax
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ia64/mm: fix a bad_page bug when crash kernel booting

[Tony Luck]

Building linux-next today (tag next-20130212) I get the following errors when
building arch/ia64/configs/{tiger_defconfig, zx1_defconfig, bigsur_defconfig,
sim_defconfig}

arch/ia64/mm/init.c: In function 'free_initrd_mem':
arch/ia64/mm/init.c:215: error: 'max_addr' undeclared (first use in
this function)
arch/ia64/mm/init.c:215: error: (Each undeclared identifier is
reported only once
arch/ia64/mm/init.c:215: error: for each function it appears in.)
arch/ia64/mm/init.c:216: error: implicit declaration of function
'GRANULEROUNDDOWN'

with "git blame" saying that these lines in init.c were added/changed by

commit 5a54b4fb8f554b15c6113e30ca8412b7fe11c62e
Author: Xishi Qiu 
Date:   Thu Feb 7 12:25:59 2013 +1100

ia64/mm: fix a bad_page bug when crash kernel booting

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

[tip:x86/asm] x86: Detect CPUID support early at boot

[tip-bot for Borislav Petkov]

Commit-ID:  9efb58de919efa8312861d454be014094f6f0ffc
Gitweb: http://git.kernel.org/tip/9efb58de919efa8312861d454be014094f6f0ffc
Author: Borislav Petkov 
AuthorDate: Mon, 11 Feb 2013 15:22:16 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 12 Feb 2013 15:48:41 -0800

x86: Detect CPUID support early at boot

We detect CPUID function support on each CPU and save it for later use,
obviating the need to play the toggle EFLAGS.ID game every time. C code
is looking at ->cpuid_level anyway.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1360592538-10643-3-git-send-email...@alien8.de
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/head_32.S | 50 +++
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index a9c5cc8..e3725a0 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -307,30 +307,39 @@ default_entry:
movl %eax,%cr0
 
 /*
- * New page tables may be in 4Mbyte page mode and may
- * be using the global pages. 
+ * We want to start out with EFLAGS unambiguously cleared. Some BIOSes leave
+ * bits like NT set. This would confuse the debugger if this code is traced. So
+ * initialize them properly now before switching to protected mode. That means
+ * DF in particular (even though we have cleared it earlier after copying the
+ * command line) because GCC expects it.
+ */
+   pushl $0
+   popfl
+
+/*
+ * New page tables may be in 4Mbyte page mode and may be using the global 
pages.
  *
- * NOTE! If we are on a 486 we may have no cr4 at all!
- * Specifically, cr4 exists if and only if CPUID exists
- * and has flags other than the FPU flag set.
+ * NOTE! If we are on a 486 we may have no cr4 at all! Specifically, cr4 exists
+ * if and only if CPUID exists and has flags other than the FPU flag set.
  */
+   movl $-1,pa(X86_CPUID)  # preset CPUID level
movl $X86_EFLAGS_ID,%ecx
pushl %ecx
-   popfl
-   pushfl
-   popl %eax
-   pushl $0
-   popfl
+   popfl   # set EFLAGS=ID
pushfl
-   popl %edx
-   xorl %edx,%eax
-   testl %ecx,%eax
-   jz 6f   # No ID flag = no CPUID = no CR4
+   popl %eax   # get EFLAGS
+   testl $X86_EFLAGS_ID,%eax   # did EFLAGS.ID remained set?
+   jz 6f   # hw disallowed setting of ID bit
+   # which means no CPUID and no CR4
+
+   xorl %eax,%eax
+   cpuid
+   movl %eax,pa(X86_CPUID) # save largest std CPUID function
 
movl $1,%eax
cpuid
-   andl $~1,%edx   # Ignore CPUID.FPU
-   jz 6f   # No flags or only CPUID.FPU = no CR4
+   andl $~1,%edx   # Ignore CPUID.FPU
+   jz 6f   # No flags or only CPUID.FPU = no CR4
 
movl pa(mmu_cr4_features),%eax
movl %eax,%cr4
@@ -378,14 +387,6 @@ default_entry:
addl $__PAGE_OFFSET, %esp
 
 /*
- * Initialize eflags.  Some BIOS's leave bits like NT set.  This would
- * confuse the debugger if this code is traced.
- * XXX - best to initialize before switching to protected mode.
- */
-   pushl $0
-   popfl
-
-/*
  * start system 32-bit setup. We need to re-do some of the things done
  * in 16-bit mode for the "real" operations.
  */
@@ -461,7 +462,6 @@ is486:  movl $0x50022,%ecx  # set AM, WP, NE and MP
xorl %eax,%eax  # Clear LDT
lldt %ax
 
-   cld # gcc2 wants the direction flag cleared at all 
times
pushl $0# fake return address for unwinder
jmp *(initial_code)
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ACPI / PCI: Initialize PCI root drivers after PCI bus enumeration

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

After commit 1aeae82 (ACPI / PCI: avoid building pci_slot as module)
the pci_slot driver's .add() callback routine, acpi_pci_slot_add(),
is executed from within acpi_pci_root_add() before the PCI devices on
the bus are enumerated and that triggers the WARN_ON() in
kobject_get():

WARNING: at /scratch/rafael/work/test/include/linux/kref.h:42 
kobject_get+0x33/0x40()
Hardware name: PORTEGE R500
Modules linked in:
Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc7+ #160
Call Trace:
 [] warn_slowpath_common+0x7a/0xb0
 [] warn_slowpath_null+0x15/0x20
 [] kobject_get+0x33/0x40
 [] get_device+0x12/0x30
 [] register_slot+0x243/0x295
 [] ? trace_hardirqs_on+0xd/0x10
 [] acpi_ns_walk_namespace+0x10f/0x24a
 [] ? walk_p2p_bridge+0x13b/0x13b
 [] ? walk_p2p_bridge+0x13b/0x13b
 [] acpi_walk_namespace+0xe9/0x132
 [] ? walk_p2p_bridge+0x13b/0x13b
 [] walk_p2p_bridge+0xf8/0x13b
 [] ? acpi_os_signal_semaphore+0x76/0x87
 [] ? walk_p2p_bridge+0x13b/0x13b
 [] acpi_ns_walk_namespace+0x10f/0x24a
 [] ? do_sta_before_sun+0x2b/0x2b
 [] ? do_sta_before_sun+0x2b/0x2b
 [] acpi_walk_namespace+0xe9/0x132
 [] ? acpi_pci_root_add+0x3e7/0x49a
 [] acpi_pci_slot_add+0xb2/0x103
 [] ? walk_p2p_bridge+0x13b/0x13b
 [] acpi_pci_root_add+0x3ff/0x49a

which means that pci_bus->dev used in register_slot() has not been
registered yet at that point.

To fix this use the observation that before commit 1aeae82
acpi_pci_slot_add() was always run after pci_bus_add_devices()
and that happened to the acpiphp's .add() callback routine too.
Thus it is safe to reorder acpi_pci_root_add() to make the PCI root
drivers' .add() callbacks be run after pci_bus_add_devices(), so do
that.

This approach was previously proposed by Myron Stowe.

References: https://patchwork.kernel.org/patch/1848781/
Signed-off-by: Rafael J. Wysocki 
---

The commit mentioned in the changelog above is in linux-pm.git/linux-next.

Thanks,
Rafael

---
 drivers/acpi/pci_root.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

Index: test/drivers/acpi/pci_root.c
===
--- test.orig/drivers/acpi/pci_root.c
+++ test/drivers/acpi/pci_root.c
@@ -600,17 +600,20 @@ static int acpi_pci_root_add(struct acpi
if (system_state != SYSTEM_BOOTING)
pci_assign_unassigned_bus_resources(root->bus);
 
+   /* need to after hot-added ioapic is registered */
+   if (system_state != SYSTEM_BOOTING)
+   pci_enable_bridges(root->bus);
+
+   pci_bus_add_devices(root->bus);
+
mutex_lock(_pci_root_lock);
+
list_for_each_entry(driver, _pci_drivers, node)
if (driver->add)
driver->add(root);
-   mutex_unlock(_pci_root_lock);
 
-   /* need to after hot-added ioapic is registered */
-   if (system_state != SYSTEM_BOOTING)
-   pci_enable_bridges(root->bus);
+   mutex_unlock(_pci_root_lock);
 
-   pci_bus_add_devices(root->bus);
return 1;
 
 out_del_root:

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/asm] x86, head_32: Remove i386 pieces

[tip-bot for Borislav Petkov]

Commit-ID:  166df91daf38f619d4ca90b58ff90983de6e40d2
Gitweb: http://git.kernel.org/tip/166df91daf38f619d4ca90b58ff90983de6e40d2
Author: Borislav Petkov 
AuthorDate: Mon, 11 Feb 2013 15:22:15 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 12 Feb 2013 15:48:40 -0800

x86, head_32: Remove i386 pieces

Remove code fragments detecting a 386 CPU since we don't support those
anymore. Also, do not do alignment checks because they're done only at
CPL3. Also, no need to preserve EFLAGS.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1360592538-10643-2-git-send-email...@alien8.de
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/head_32.S | 22 +-
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index c8932c7..a9c5cc8 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -394,30 +394,21 @@ default_entry:
jz 1f   # Did we do this already?
call *%eax
 1:
-   
-/* check if it is 486 or 386. */
+
 /*
- * XXX - this does a lot of unnecessary setup.  Alignment checks don't
- * apply at our cpl of 0 and the stack ought to be aligned already, and
- * we don't need to preserve eflags.
+ * Check if it is 486
  */
movl $-1,X86_CPUID  # -1 for no CPUID initially
-   movb $3,X86 # at least 386
+   movb $4,X86 # at least 486
pushfl  # push EFLAGS
popl %eax   # get EFLAGS
movl %eax,%ecx  # save original EFLAGS
-   xorl $0x24,%eax # flip AC and ID bits in EFLAGS
+   xorl $0x20,%eax # flip ID bit in EFLAGS
pushl %eax  # copy to EFLAGS
popfl   # set EFLAGS
pushfl  # get new EFLAGS
popl %eax   # put it in eax
xorl %ecx,%eax  # change in flags
-   pushl %ecx  # restore original EFLAGS
-   popfl
-   testl $0x4,%eax # check if AC bit changed
-   je is386
-
-   movb $4,X86 # at least 486
testl $0x20,%eax# check if ID bit changed
je is486
 
@@ -445,10 +436,7 @@ default_entry:
movl %edx,X86_CAPABILITY
 
 is486: movl $0x50022,%ecx  # set AM, WP, NE and MP
-   jmp 2f
-
-is386: movl $2,%ecx# set MP
-2: movl %cr0,%eax
+   movl %cr0,%eax
andl $0x8011,%eax   # Save PG,PE,ET
orl %ecx,%eax
movl %eax,%cr0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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, doc: Clarify the use of asm("%edx") in uaccess.h

[tip-bot for H. Peter Anvin]

Commit-ID:  ff52c3b02b3f73178bfe0c219cd22abdcb0e46c3
Gitweb: http://git.kernel.org/tip/ff52c3b02b3f73178bfe0c219cd22abdcb0e46c3
Author: H. Peter Anvin 
AuthorDate: Tue, 12 Feb 2013 15:37:02 -0800
Committer:  H. Peter Anvin 
CommitDate: Tue, 12 Feb 2013 15:37:02 -0800

x86, doc: Clarify the use of asm("%edx") in uaccess.h

Put in a comment that explains that the use of asm("%edx") in
uaccess.h doesn't actually necessarily mean %edx alone.

Cc: Jamie Lokier 
Cc: Ville Syrjälä 
Cc: Borislav Petkov 
Cc: Russell King 
Cc: Linus Torvalds 
Cc: H. J. Lu 
Link: http://lkml.kernel.org/r/511acdfb.1050...@zytor.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/uaccess.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index d710a25..5ee2687 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -148,9 +148,16 @@ __typeof__(__builtin_choose_expr(sizeof(x) > sizeof(0UL), 
0ULL, 0UL))
  *
  * Returns zero on success, or -EFAULT on error.
  * On error, the variable @x is set to zero.
- *
+ */
+/*
  * Careful: we have to cast the result to the type of the pointer
  * for sign reasons.
+ *
+ * The use of %edx as the register specifier is a bit of a
+ * simplification, as gcc only cares about it as the starting point
+ * and not size: for a 64-bit value it will use %ecx:%edx on 32 bits
+ * (%ecx being the next register in gcc's x86 register sequence), and
+ * %rdx on 64 bits.
  */
 #define get_user(x, ptr)   \
 ({ \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] nbd: support FLUSH requests

[Alex Bligh]

On 12 Feb 2013, at 21:32, Andrew Morton wrote:

> 
> Obviously the changelog was inadequate.  Please send along a new one
> which fully describes the reasons for this change.

To be clear I have no complaints about the rest of the patch being
merged. Supporting FLUSH but not FUA is far better than supporting
neither. I just didn't understand dropping FUA given the semantics
of nbd is in essence 'linux bios over tcp'.

-- 
Alex Bligh




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

Re: [PATCH 1/3] nbd: support FLUSH requests

[Alex Bligh]

Paolo,

On 12 Feb 2013, at 18:06, Paolo Bonzini wrote:

> Il 12/02/2013 18:37, Alex Bligh ha scritto:
>> For my education, why remove the FUA stuff?
> 
> Because I had no way to test it.

I think my mods to the official NBD code support FUA (albeit not very 
efficiently)

>> Hmmm... the underlying storage could be md/dm RAIDs in which case FUA
>> should be cheaper than FLUSH.
 
 If someone ever wrote a virtio-blk backend that sits directly ontop
 of the Linux block layer that would be true.
>> In this case we don't know what the backend is sitting on top of
>> a-priori. It might be the current nbd server code, but it might
>> not be.
> 
> Do you know of any other NBD server than the "official" one and qemu-nbd?


Yes. I know one well (but it's not open source). NBD seems to be the 'goto 
protocol' for writing distributed block store drivers in user space.

-- 
Alex Bligh




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

[Andrew Morton]

On Fri, 08 Feb 2013 18:02:44 +0800
Jeremy Kerr  wrote:

> On 08/02/13 07:13, Andrew Morton wrote:
> 
> > The general ruleset for selftests is: do as much as you can if you're not
> > root and don't take too long and don't break the build on any
> > architecture and don't cause the top-level "make run_tests" to fail if
> > your feature is unconfigured.
> 
> This change adds a little documentation to the tests under
> tools/testing/selftests/, based on akpm's explanation.

Looks nice, thanks ;)

I'm thinking we move it from Documentation/selftests.txt to
tools/testing/selftests/README.txt, where people are more likely to
notice it?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:x86/mm] x86, mm: Redesign get_user with a __builtin_choose_expr hack

[H. Peter Anvin]

On 02/12/2013 03:49 PM, Linus Torvalds wrote:
> On Tue, Feb 12, 2013 at 3:19 PM, H. Peter Anvin  wrote:
>>
>> Yes, but there doesn't seem to be any other way to do this.  gcc won't
>> even allow "=cd" even if we know the variable is 64 bits, even though
>> "=A" is documented to be equivalent to "=da".
> 
> No, "=da" means value "in edx _or_ %eax". Not the same as "A".
> 

Actually, if you look at how gcc implements them, they are the same, and
if you are luckless enough to try to use a 32-bit value with an "A"
constraint you have it end up in either %eax or %edx.

However, they seem to have added some additional linting which prohibits
the compound form.  I'm not sure it would have worked anyway since we
need the two-register bit to be conditional.

> But you're right, there's nothing similar for %ebx:%ecx. I thought
> there was. I was really sure we did something special for 64-bit adc
> etc.
> 
>> Let me know what you think.
> 
> I guess we don't have any choice. And the other cleanups certainly look good.

OK, will commit the comment.  We can add the additional copy if we need it.

-hpa


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

Re: [PATCH 1/3 v3] selftests: Add tests for efivarfs

[Andrew Morton]

On Fri, 08 Feb 2013 10:08:49 +
Matt Fleming  wrote:

> On Fri, 2013-02-08 at 18:05 +0800, Jeremy Kerr wrote:
> > However, the tests expose a bug at the moment, so run_tests will fail. 
> > Matt will have that fixed soon though :)
> 
> In which case, would it make more sense for me to take these tests
> through the efi tree? I'm fine either way, I'm just looking for the
> least surprising option.

I don't think it matters much at this stage.  selftests is new and is
used by approximately zero people so if the tests fail, few will
notice.  Let's just get it in there and get it settled down.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:x86/mm] x86, mm: Redesign get_user with a __builtin_choose_expr hack

[Linus Torvalds]

On Tue, Feb 12, 2013 at 3:19 PM, H. Peter Anvin  wrote:
>
> Yes, but there doesn't seem to be any other way to do this.  gcc won't
> even allow "=cd" even if we know the variable is 64 bits, even though
> "=A" is documented to be equivalent to "=da".

No, "=da" means value "in edx _or_ %eax". Not the same as "A".

But you're right, there's nothing similar for %ebx:%ecx. I thought
there was. I was really sure we did something special for 64-bit adc
etc.

> Let me know what you think.

I guess we don't have any choice. And the other cleanups certainly look good.

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

Re: [PATCH] net: ethernet: ti: remove redundant NULL check.

[David Miller]

From: Cyril Roelandt 
Date: Tue, 12 Feb 2013 23:54:41 +0100

> Ok, I resent, though I forgot to add "v2".

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

Re: [PATCH 1/3 v3] selftests: Add tests for efivarfs

[Andrew Morton]

On Fri, 08 Feb 2013 18:05:52 +0800
Jeremy Kerr  wrote:

> > I'll do this for now:
> >
> > --- 
> > a/tools/testing/selftests/efivarfs/Makefile~selftests-add-tests-for-efivarfs-fix
> > +++ a/tools/testing/selftests/efivarfs/Makefile
> > @@ -6,7 +6,7 @@ test_objs = open-unlink
> >   all: $(test_objs)
> >
> >   run_tests: all
> > -   @./efivarfs.sh || echo "efivarfs selftests: [FAIL]"
> > +   @/bin/sh ./efivarfs.sh || echo "efivarfs selftests: [FAIL]"
> >
> >   clean:
> > rm -f $(test_objs)
> >
> > but I'm not sure I did it right :(
> 
> efivarfs.sh requires bash currently, so we'll need to call this explicitly:
> 
> + @/bin/bash ./efivarfs.sh || echo "efivarfs selftests: [FAIL]"
> 
> Is this okay?

Judging from ./Makefile:

# SHELL used by kbuild
CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
  else if [ -x /bin/bash ]; then echo /bin/bash; \
  else echo sh; fi ; fi)

bash is "optional" (this seems dumb, because all of us have
bash and we won't test /bin/sh).

But I expect that anyone who has an interest in running the selftests
is capable of making /bin/bash appear, so I'll make that change.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/3]trace,x86: irq vector tracepoint support

[Seiji Aguchi]

Peter,

Could you please review this patchset?
I have updated it in accordance with Steven's comment.

Seiji

> -Original Message-
> From: Seiji Aguchi
> Sent: Monday, February 04, 2013 5:49 PM
> To: 'Steven Rostedt'; x...@kernel.org; H. Peter Anvin (h...@zytor.com); 
> linux-kernel@vger.kernel.org
> Cc: Thomas Gleixner (t...@linutronix.de); 'mi...@elte.hu' (mi...@elte.hu); 
> Borislav Petkov (b...@alien8.de); Satoru Moriya; dle-
> deve...@lists.sourceforge.net; linux-e...@vger.kernel.org; Luck, Tony 
> (tony.l...@intel.com)
> Subject: [PATCH v9 0/3]trace,x86: irq vector tracepoint support
> 
> Change log
> 
>  v8 -> v9
>  - Rebase to 3.8-rc6
>  - Add Steven's email address at the top of the message and
>move my signed-off-by below Steven's one because it is
>originally created by Steven. (patch 1/3)
>  - Introduce a irq_vector_mutex to avoid a race at registering/unregistering
>time. (patch 2/3)
>  - Use a per_cpu data to orig_idt_descr because IDT descritor is needed to 
> each cpu
>and the appropriate data type is per_cpu data. It is suggested by Steven.
>(patch 2/3)
> 
>  v7 -> v8
>  - Rebase to 3.8-rc4
>  - Add a patch 1 introducing DEFINE_EVENT_FN() macro.
>  - Rename original patches 1 and 2 to 2 and 3.
>  - Change a definition of tracepoint to use DEFINE_EVENT_FN(). (patch 2)
>  - Change alloc_intr_gate() to use do{}while(0) to avoid a warning
>of checkpatch.pl. (patch 2)
>  - Move entering_irq()/exiting_irq() to arch/x86/include/asm/apic.h (patch 3)
> 
>  v6 -> v7
>  - Divide into two patches to make a code review easier.
>Summery of each patch is as follows.
> - Patch 1/2
>   - Add an irq_vector tracing infrastructure.
>   - Create idt_table for tracing. It is refactored to avoid duplicating
> existing logic.
>   - Duplicate new irq handlers inserted tracepoints.
> 
> - Patch 2/2
>   - Share a common logic among irq handlers to make them
> manageable and readable.
> 
>  v5 -> v6
>  - Rebased to 3.7
> 
>  v4 -> v5
>  - Rebased to 3.6.0
> 
>  - Introduce a logic switching IDT at enabling/disabling TP time
>so that a time penalty makes a zero when tracepoints are disabled.
>This IDT is created only when CONFIG_TRACEPOINTS is enabled.
> 
>  - Remove arch_irq_vector_entry/exit and add followings again
>so that we can add each tracepoint in a generic way.
>- error_apic_vector
>- thermal_apic_vector
>- threshold_apic_vector
>- spurious_apic_vector
>- x86_platform_ipi_vector
> 
>  - Drop nmi tracepoints to begin with apic interrupts and discuss a logic 
> switching
>IDT first.
> 
>  - Move irq_vectors.h in the directory of arch/x86/include/asm/trace because
>I'm not sure if a logic switching IDT is sharable with other architectures.
> 
>  v3 -> v4
>  - Add a latency measurement of each tracepoint
>  - Rebased to 3.6-rc6
> 
>  v2 -> v3
>  - Remove an invalidate_tlb_vector event because it was replaced by a call 
> function vector
>in a following commit.
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=52aec3308db85f4e9f5c8b9f5dc4fbd0138c6fa4
> 
>  v1 -> v2
>  - Modify variable name from irq to vector.
>  - Merge arch-specific tracepoints below to an arch_irq_vector_entry/exit.
>- error_apic_vector
>- thermal_apic_vector
>- threshold_apic_vector
>- spurious_apic_vector
>- x86_platform_ipi_vector
> 
> [Purpose of this patch]
> 
> As Vaibhav explained in the thread below, tracepoints for irq vectors are 
> useful.
> 
> http://www.spinics.net/lists/mm-commits/msg85707.html
> 
> 
> The current interrupt traces from irq_handler_entry and irq_handler_exit 
> provide when an interrupt is handled.  They provide good
> data about when the system has switched to kernel space and how it affects 
> the currently running processes.
> 
> There are some IRQ vectors which trigger the system into kernel space, which 
> are not handled in generic IRQ handlers.  Tracing such
> events gives us the information about IRQ interaction with other system 
> events.
> 
> The trace also tells where the system is spending its time.  We want to know 
> which cores are handling interrupts and how they are
> affecting other processes in the system.  Also, the trace provides 
> information about when the cores are idle and which interrupts are
> changing that state.
> 
> 
> On the other hand, my usecase is tracing just local timer event and getting a 
> value of instruction pointer.
> 
> I suggested to add an argument local timer event to get instruction pointer 
> before.
> But there is another way to get it with external module like systemtap.
> So, I don't need to add any argument to irq vector tracepoints now.
> 
> [Patch Description]
> 
> Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in 
> all events.
> But there is an above use case to trace specific irq_vector rather than 
> tracing all events.
> In this case, we are concerned about 

Re: [tip:x86/mm] x86, mm: Redesign get_user with a __builtin_choose_expr hack

[Russell King - ARM Linux]

On Tue, Feb 12, 2013 at 03:06:51PM -0800, Linus Torvalds wrote:
> So this looks clean, but I noticed something (that was true even of
> the old 64-bit accesses)
> 
> On Tue, Feb 12, 2013 at 12:55 PM, tip-bot for H. Peter Anvin
>  wrote:
> > +   register __inttype(*(ptr)) __val_gu asm("%edx");\
> 
> How does gcc even alllow this?
> 
> On x86-32, you cannot put a 64-bit value in %edx.
> 
> Where do the upper bits go? It clearly cannot be %edx:%eax, since we
> put the error value in %eax.

I can't talk for x86, but the ARM version is this:

register __inttype(*p) __r2 asm("r2");

r2 is only 32-bit, so you can ask the same question there.  The answer
is, it ends up in r3, the next register, as required by the compiler
ABI.  (64-bit values are always contained in a consecutive even, odd
register pair.)

> Also, come to think of it, we have tried the "named register
> variables" thing before, and it has resulted in problems with scope.
> In particular, two variables within the same scope and the same
> register have been problematic. And it *does* happen, when you have
> things like
> 
>/* copy_user */
>put_user(get_user(.., addr), addr2);
> 
> and then things go downhill.

Umm.  Why would you want to put_user() the error code from get_user() ?
That's just weird, don't we normally want to return the error code?

But yes, I can see that kind of thing causing problems - I'll check
what the behaviour is on ARM.  What we _do_ have is a bit of assembly
level checking which verifies that the arguments are passed in the
correct registers, so at least we get build errors should things go
wrong.  We haven't seen that though.

> Maybe we do not have these issues, but there are good reasons why
> we've tried very hard on x86 to avoid named register variables.

Unfortunately on ARM there's no other way to get close to specifying
registers for asm code. :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:x86/mm] x86, mm: Redesign get_user with a __builtin_choose_expr hack

[H. Peter Anvin]

On 02/12/2013 03:06 PM, Linus Torvalds wrote:
> So this looks clean, but I noticed something (that was true even of
> the old 64-bit accesses)
> 
> On Tue, Feb 12, 2013 at 12:55 PM, tip-bot for H. Peter Anvin
>  wrote:
>> +   register __inttype(*(ptr)) __val_gu asm("%edx");\
> 
> How does gcc even alllow this?
> 
> On x86-32, you cannot put a 64-bit value in %edx.
> 
> Where do the upper bits go? It clearly cannot be %edx:%eax, since we
> put the error value in %eax.
> 
> So is the rule for x86-32 that naming "long long" register values
> names the first register, and the high bits go into the next one (I
> forget the crazy register numbering, I assume it's %ecx). Or what?
> This should have a comment.
> 

Yes, it goes into the next register in gcc's register numbering, which
is %ecx.  This works with the register variable because the named
register is treated as a starting point, whereas using "=d" is treated
as a singleton register set.

I'll add a comment.

gcc's register numbering isn't all that crazy, incidentally: the only
difference from the standard x86 register numbering is that %ecx and
%edx is swapped, so that the standard %edx:%eax and %ebx:%ecx register
pairs end up consecutive.  It isn't really gcc's fault that the x86
register numbering doesn't match its (hard-coded!) register conventions...

> Also, come to think of it, we have tried the "named register
> variables" thing before, and it has resulted in problems with scope.
> In particular, two variables within the same scope and the same
> register have been problematic. And it *does* happen, when you have
> things like
> 
>/* copy_user */
>put_user(get_user(.., addr), addr2);
> 
> and then things go downhill.
> 
> Maybe we do not have these issues, but there are good reasons why
> we've tried very hard on x86 to avoid named register variables.

Yes, but there doesn't seem to be any other way to do this.  gcc won't
even allow "=cd" even if we know the variable is 64 bits, even though
"=A" is documented to be equivalent to "=da".

I don't think we have any additional problem here,though.  If we are
inside a scope with "%edx" as a named register variable *and* that
variable is live at the point get_user() happens, then yes, we can and
will have a problem, regardless if we use "=d" or a named register
variable.  The only solution to that is to keep the named register
variable live for as short time as possible.

If we do run into trouble, we could introduce a second copy, thus
reducing the lifespan of the named variable to the absolute minimum:

register __inttype(*(ptr)) __val_gu asm("%edx");
__inttype(*(ptr)) __val_gv;

asm volatile(...);

__val_gv = __val_gu;
(x) = (__typeof__(*(ptr))) __val_gv;

That way if the evaluation of (x) as an lvalue somehow requires specific
registers they don't collide.

I would prefer if we could worry about that when we actually need to,
though.  It will trigger a compile error if relevant, so it shouldn't
cause any risk of silent corruption.

> (I realize that they happen, and some other architectures don't even
> have good support for naming registers any other way so they are way
> more common there, so I probably worry needlessly, but it does worry
> me).

Let me know what you think.

-hpa

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

Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional

[Mimi Zohar]

On Tue, 2013-02-12 at 13:52 -0500, Vivek Goyal wrote:
> On Tue, Feb 12, 2013 at 12:14:07PM -0500, Mimi Zohar wrote:
> 
> [..]
> > > > > --- a/security/integrity/ima/ima_appraise.c
> > > > > +++ b/security/integrity/ima/ima_appraise.c
> > > > > @@ -124,19 +124,26 @@ int ima_appraise_measurement(int func, struct 
> > > > > integrity_iint_cache *iint,
> > > > >   enum integrity_status status = INTEGRITY_UNKNOWN;
> > > > >   const char *op = "appraise_data";
> > > > >   char *cause = "unknown";
> > > > > - int rc;
> > > > > + int rc, audit_info = 0;
> > > > > 
> > > > >   if (!ima_appraise)
> > > > >   return 0;
> > > > > - if (!inode->i_op->getxattr)
> > > > > + if (!inode->i_op->getxattr) {
> > > > > + /* getxattr not supported. file couldn't have been 
> > > > > signed */
> > > > > + if (iint->flags & IMA_DIGSIG_OPTIONAL)
> > > > > + return INTEGRITY_PASS;
> > > > >   return INTEGRITY_UNKNOWN;
> > > > > + }
> > > > > 
> > > > 
> > > > Please don't change the result of the appraisal like this.  A single
> > > > change can be made towards the bottom of process_measurement().
> > > 
> > > I don't want to pass integrity in all cases of INTEGRITY_UNKNOWN. So
> > > I can probably maintain a bool variable, say pass_appraisal, and set
> > > that here and at the end of function, parse that variable and change
> > > the status accordingly.
> > 
> > process_measurement() is the only caller of ima_appraise_measurement().
> > Leave the results of ima_appraise_measurement() alone.  There's already
> > code at the end of process_measurement() which decides what to return.
> > Just modify it based on the appraisal results.
> 
> Ok, I can do that. There is a small concern though. That is what to do
> when rc = INTEGRITY_UKNOWN and IMA_DIGSIG_OPTIONAL flag is set.
> 
> ima_appraise_measurement() returns INTEGRITY_UKNOWN when file system
> does not support xattrs or if security xattr is not enabled. In this
> case it is desirable to allow access if IMA_DIGSIG_OPTIONAL flag is
> set.

Right, 'INTEGRITY_UNKNOWN' means that we can't reason, for whatever
reason, about the integrity of the file.

> But INTEGRITY_UNKNOWN is also also returned when integrity_digsig_verify()
> fails and returns -EOPNOTSUPP. 

In this case, it is Kconfig based. 

> I feel that in this case it is not very appropriate to pass appraisal and
> let executable run. If digital signatures are present but we can't verify
> those (Say some algorithm is not supported in kernel). In that case I
> think it makes sense to fail the signature. 
> 
>rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA,
>  xattr_value->digest, rc - 1,
>  iint->ima_xattr.digest,
>  IMA_DIGEST_SIZE);
> if (rc == -EOPNOTSUPP) {
> status = INTEGRITY_UNKNOWN;
> 
> 
> So how to handle this case.
> 
> I am wondering why do we reutrn INTEGRITY_UNKNOWN above and not
> INTEGRITY_FAIL.

We still can't reason about the integrity of the file.  For all we know,
it could be a validly signed file, just verification wasn't enabled.

> Will it make sense to fail signature in case of -EOPNOTSUPP.
>rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA,
>  xattr_value->digest, rc - 1,
>  iint->ima_xattr.digest,
>  IMA_DIGEST_SIZE);
>   if (rc)
>   status = INTEGRITY_FAIL;
>   else
>   status = INTEGRITY_PASS;
> 
> 

Please don't.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kbuild: limit dtc+cpp include path

[Grant Likely]

On Tue, 12 Feb 2013 15:03:37 -0700, Stephen Warren  
wrote:
> From: Stephen Warren 
> 
> Device tree source files may now include header files. The intent is
> that those header files define/name constants used as part of the DT
> bindings. Currently this feature is open to abuse, since any kernel
> header file at all can be included, This could allow device tree files
> to become dependant on kernel headers files, and thus make them no
> longer OS-independent. This would also prevent separating the device
> tree source files from the kernel repository.
> 
> Solve this by limiting the cpp include path for device tree files to
> separate directories.
> 
> Signed-off-by: Stephen Warren 
> ---
> Here, I allow header files in the .dts source directory, or in a per-arch
> include directory. Perhaps rather than:
> 
> -I$(srctree)/arch/$(SRCARCH)/include/dts

That seems reasonable for now.

Applied, thanks.
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: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host

[Arnd Bergmann]

On Tuesday 12 February 2013, gre...@linuxfoundation.org wrote:
> > 
> > > Please let's find something that makes both hw and Linux happy
> > I still believe it makes sense to use mei_device for what we add to the MEI
> > bus. I'd be fine with mei_bus_device as well, but that would somehow look
> > a bit awkward. Greg, Arnd, any preference ?
> 
> "mei_device" works the best for me.  Tomas, what you think of as a "MEI
> Device" really is a "MEI Controller", it bridges the difference between
> the PCI bus and your new MEI bus, so you will need to start thinking of
> these things a bit differently now that you have created your own little
> virtual bus.

Yes, I agree. mei_bus_device would also work as the name for the controller,
but not for the devices attached to it IMO.

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/

[PATCH v3 4/5] of: Create function for counting number of phandles in a property

[Grant Likely]

This patch creates of_count_phandle_with_args(), a new function for
counting the number of phandle+argument tuples in a given property. This
is better than the existing method of parsing each phandle individually
until parsing fails which is a horribly slow way to do the count.

Tested on ARM using the selftest code.

v3: - Rebased on top of selftest code cleanup patch
v2: - fix bug where of_parse_phandle_with_args() could behave like _count_.
- made of_gpio_named_count() into a static inline regardless of 
CONFIG_OF_GPIO

Signed-off-by: Grant Likely 
Cc: Linus Walleij 
Cc: Rob Herring 
Cc: Andreas Larsson 
---
 drivers/of/base.c |   41 +
 drivers/of/selftest.c |   15 +++
 include/linux/of.h|9 +
 3 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index c4538ab..f21794c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1082,9 +1082,10 @@ EXPORT_SYMBOL(of_parse_phandle);
  * To get a device_node of the `node2' node you may call this:
  * of_parse_phandle_with_args(node3, "list", "#list-cells", 1, );
  */
-int of_parse_phandle_with_args(const struct device_node *np, const char 
*list_name,
-   const char *cells_name, int index,
-   struct of_phandle_args *out_args)
+static int __of_parse_phandle_with_args(const struct device_node *np,
+   const char *list_name,
+   const char *cells_name, int index,
+   struct of_phandle_args *out_args)
 {
const __be32 *list, *list_end;
int rc = 0, size, cur_index = 0;
@@ -1174,15 +1175,47 @@ int of_parse_phandle_with_args(const struct device_node 
*np, const char *list_na
 * Unlock node before returning result; will be one of:
 * -ENOENT : index is for empty phandle
 * -EINVAL : parsing error on data
+* [1..n]  : Number of phandle (count mode; when index = -1)
 */
-   rc = -ENOENT;
+   rc = index < 0 ? cur_index : -ENOENT;
  err:
if (node)
of_node_put(node);
return rc;
 }
+
+int of_parse_phandle_with_args(const struct device_node *np, const char 
*list_name,
+   const char *cells_name, int index,
+   struct of_phandle_args *out_args)
+{
+   if (index < 0)
+   return -EINVAL;
+   return __of_parse_phandle_with_args(np, list_name, cells_name, index, 
out_args);
+}
 EXPORT_SYMBOL(of_parse_phandle_with_args);
 
+/**
+ * of_count_phandle_with_args() - Find the number of phandles references in a 
property
+ * @np:pointer to a device tree node containing a list
+ * @list_name: property name that contains a list
+ * @cells_name:property name that specifies phandles' arguments count
+ *
+ * Returns the number of phandle + argument tuples within a property. It
+ * is a typical pattern to encode a list of phandle and variable
+ * arguments into a single property. The number of arguments is encoded
+ * by a property in the phandle-target node. For example, a gpios
+ * property would contain a list of GPIO specifies consisting of a
+ * phandle and 1 or more arguments. The number of arguments are
+ * determined by the #gpio-cells property in the node pointed to by the
+ * phandle.
+ */
+int of_count_phandle_with_args(const struct device_node *np, const char 
*list_name,
+   const char *cells_name)
+{
+   return __of_parse_phandle_with_args(np, list_name, cells_name, -1, 
NULL);
+}
+EXPORT_SYMBOL(of_count_phandle_with_args);
+
 #if defined(CONFIG_OF_DYNAMIC)
 static int of_property_notify(int action, struct device_node *np,
  struct property *prop)
diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
index 01b4174..0eb5c38 100644
--- a/drivers/of/selftest.c
+++ b/drivers/of/selftest.c
@@ -36,6 +36,9 @@ static void __init of_selftest_parse_phandle_with_args(void)
return;
}
 
+   rc = of_count_phandle_with_args(np, "phandle-list", "#phandle-cells");
+   selftest(rc == 7, "of_count_phandle_with_args() returned %i, expected 
7\n", rc);
+
for (i = 0; i < 8; i++) {
bool passed = true;
rc = of_parse_phandle_with_args(np, "phandle-list",
@@ -94,21 +97,33 @@ static void __init of_selftest_parse_phandle_with_args(void)
rc = of_parse_phandle_with_args(np, "phandle-list-missing",
"#phandle-cells", 0, );
selftest(rc == -ENOENT, "expected:%i got:%i\n", -ENOENT, rc);
+   rc = of_count_phandle_with_args(np, "phandle-list-missing",
+   "#phandle-cells");
+   selftest(rc == -ENOENT, "expected:%i got:%i\n", -ENOENT, rc);
 
/* Check for missing cells property */
rc = 

[PATCH v3 3/5] of/base: Clean up exit paths for of_parse_phandle_with_args()

[Grant Likely]

Some of the exit paths were not correctly releasing the node. Fix it by
creating an 'err' label for collecting the error paths and releasing the
node.

Cc: Rob Herring 
Signed-off-by: Grant Likely 
---
 drivers/of/base.c |   26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index e2d44e0..c4538ab 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1087,7 +1087,7 @@ int of_parse_phandle_with_args(const struct device_node 
*np, const char *list_na
struct of_phandle_args *out_args)
 {
const __be32 *list, *list_end;
-   int size, cur_index = 0;
+   int rc = 0, size, cur_index = 0;
uint32_t count = 0;
struct device_node *node = NULL;
phandle phandle;
@@ -1100,6 +1100,7 @@ int of_parse_phandle_with_args(const struct device_node 
*np, const char *list_na
 
/* Loop over the phandles until all the requested entry is found */
while (list < list_end) {
+   rc = -EINVAL;
count = 0;
 
/*
@@ -1116,13 +1117,13 @@ int of_parse_phandle_with_args(const struct device_node 
*np, const char *list_na
if (!node) {
pr_err("%s: could not find phandle\n",
 np->full_name);
-   break;
+   goto err;
}
if (of_property_read_u32(node, cells_name, )) {
pr_err("%s: could not get %s for %s\n",
 np->full_name, cells_name,
 node->full_name);
-   break;
+   goto err;
}
 
/*
@@ -1132,7 +1133,7 @@ int of_parse_phandle_with_args(const struct device_node 
*np, const char *list_na
if (list + count > list_end) {
pr_err("%s: arguments longer than property\n",
 np->full_name);
-   break;
+   goto err;
}
}
 
@@ -1142,9 +1143,10 @@ int of_parse_phandle_with_args(const struct device_node 
*np, const char *list_na
 * index matches, then fill the out_args structure and return,
 * or return -ENOENT for an empty entry.
 */
+   rc = -ENOENT;
if (cur_index == index) {
if (!phandle)
-   return -ENOENT;
+   goto err;
 
if (out_args) {
int i;
@@ -1155,6 +1157,10 @@ int of_parse_phandle_with_args(const struct device_node 
*np, const char *list_na
for (i = 0; i < count; i++)
out_args->args[i] = 
be32_to_cpup(list++);
}
+
+   /* Found it! return success */
+   if (node)
+   of_node_put(node);
return 0;
}
 
@@ -1164,10 +1170,16 @@ int of_parse_phandle_with_args(const struct device_node 
*np, const char *list_na
cur_index++;
}
 
-   /* Loop exited without finding a valid entry; return an error */
+   /*
+* Unlock node before returning result; will be one of:
+* -ENOENT : index is for empty phandle
+* -EINVAL : parsing error on data
+*/
+   rc = -ENOENT;
+ err:
if (node)
of_node_put(node);
-   return -EINVAL;
+   return rc;
 }
 EXPORT_SYMBOL(of_parse_phandle_with_args);
 
-- 
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/

[PATCH v3 0/5] of: Add helper for counting phandle refernces

[Grant Likely]

Well, this started as a single patch to get rid of horrible brute-force
counting of phandles and ended with fixes to the selftest code and
cleanups to the existing phandle parser before actually getting to the
new feature.

The selftest code is still a little fiddly to execute, but at least it
is consistent now. Sometime soon I'll link the selftest data directly
into the kernel so nothing special has to be done to run it, but I think
the DT grafting support needs to go in first.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/5] of/selftest: Fix GPIOs selftest to cover the 7th case

[Grant Likely]

The of_gpio_named_count() self test doesn't hit the out-of-range
condition even though it is coded. Fix the bug by increasing the for
loop range by one.

Reported-by: Andreas Larsson 
Cc: Rob Herring 
Signed-off-by: Grant Likely 
---
 drivers/of/selftest.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
index f24ffd7..9f62eb5 100644
--- a/drivers/of/selftest.c
+++ b/drivers/of/selftest.c
@@ -35,7 +35,7 @@ static void __init of_selftest_parse_phandle_with_args(void)
return;
}
 
-   for (i = 0; i < 7; i++) {
+   for (i = 0; i < 8; i++) {
bool passed = true;
rc = of_parse_phandle_with_args(np, "phandle-list",
"#phandle-cells", i, );
-- 
1.7.10.4

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

Re: [tip:x86/mm] x86, mm: Redesign get_user with a __builtin_choose_expr hack

[Linus Torvalds]

So this looks clean, but I noticed something (that was true even of
the old 64-bit accesses)

On Tue, Feb 12, 2013 at 12:55 PM, tip-bot for H. Peter Anvin
 wrote:
> +   register __inttype(*(ptr)) __val_gu asm("%edx");\

How does gcc even alllow this?

On x86-32, you cannot put a 64-bit value in %edx.

Where do the upper bits go? It clearly cannot be %edx:%eax, since we
put the error value in %eax.

So is the rule for x86-32 that naming "long long" register values
names the first register, and the high bits go into the next one (I
forget the crazy register numbering, I assume it's %ecx). Or what?
This should have a comment.

Also, come to think of it, we have tried the "named register
variables" thing before, and it has resulted in problems with scope.
In particular, two variables within the same scope and the same
register have been problematic. And it *does* happen, when you have
things like

   /* copy_user */
   put_user(get_user(.., addr), addr2);

and then things go downhill.

Maybe we do not have these issues, but there are good reasons why
we've tried very hard on x86 to avoid named register variables.

(I realize that they happen, and some other architectures don't even
have good support for naming registers any other way so they are way
more common there, so I probably worry needlessly, but it does worry
me).

 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/5] of/selftest: Use selftest() macro throughout

[Grant Likely]

Some of the selftests are open-coded. Others use the selftest() macro
defined in drivers/of/selftest.c. The macro makes for cleaner selftest
code, so refactor the of_parse_phandle_with_args() tests to use it.

Cc: Rob Herring 
Signed-off-by: Grant Likely 
---
 drivers/of/selftest.c |   37 ++---
 1 file changed, 14 insertions(+), 23 deletions(-)

diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
index 9f62eb5..01b4174 100644
--- a/drivers/of/selftest.c
+++ b/drivers/of/selftest.c
@@ -2,7 +2,7 @@
  * Self tests for device tree subsystem
  */
 
-#define pr_fmt(fmt) "### %s(): " fmt, __func__
+#define pr_fmt(fmt) "### dt-test ### " fmt
 
 #include 
 #include 
@@ -16,19 +16,20 @@
 
 static bool selftest_passed = true;
 #define selftest(result, fmt, ...) { \
-   selftest_passed &= (result); \
-   if (!(result)) \
+   if (!(result)) { \
pr_err("FAIL %s:%i " fmt, __FILE__, __LINE__, ##__VA_ARGS__); \
+   selftest_passed = false; \
+   } else { \
+   pr_info("pass %s:%i\n", __FILE__, __LINE__); \
+   } \
 }
 
 static void __init of_selftest_parse_phandle_with_args(void)
 {
struct device_node *np;
struct of_phandle_args args;
-   int rc, i;
-   bool passed_all = true;
+   int i, rc;
 
-   pr_info("start\n");
np = of_find_node_by_path("/testcase-data/phandle-tests/consumer-a");
if (!np) {
pr_err("missing testcase data\n");
@@ -79,45 +80,35 @@ static void __init of_selftest_parse_phandle_with_args(void)
passed &= (args.args[0] == (i + 1));
break;
case 7:
-   passed &= (rc == -EINVAL);
+   passed &= (rc == -ENOENT);
break;
default:
passed = false;
}
 
-   if (!passed) {
-   int j;
-   pr_err("index %i - data error on node %s rc=%i regs=[",
-   i, args.np->full_name, rc);
-   for (j = 0; j < args.args_count; j++)
-   printk(" %i", args.args[j]);
-   printk(" ]\n");
-
-   passed_all = false;
-   }
+   selftest(passed, "index %i - data error on node %s rc=%i\n",
+i, args.np->full_name, rc);
}
 
/* Check for missing list property */
rc = of_parse_phandle_with_args(np, "phandle-list-missing",
"#phandle-cells", 0, );
-   passed_all &= (rc == -EINVAL);
+   selftest(rc == -ENOENT, "expected:%i got:%i\n", -ENOENT, rc);
 
/* Check for missing cells property */
rc = of_parse_phandle_with_args(np, "phandle-list",
"#phandle-cells-missing", 0, );
-   passed_all &= (rc == -EINVAL);
+   selftest(rc == -EINVAL, "expected:%i got:%i\n", -EINVAL, rc);
 
/* Check for bad phandle in list */
rc = of_parse_phandle_with_args(np, "phandle-list-bad-phandle",
"#phandle-cells", 0, );
-   passed_all &= (rc == -EINVAL);
+   selftest(rc == -EINVAL, "expected:%i got:%i\n", -EINVAL, rc);
 
/* Check for incorrectly formed argument list */
rc = of_parse_phandle_with_args(np, "phandle-list-bad-args",
"#phandle-cells", 1, );
-   passed_all &= (rc == -EINVAL);
-
-   pr_info("end - %s\n", passed_all ? "PASS" : "FAIL");
+   selftest(rc == -EINVAL, "expected:%i got:%i\n", -EINVAL, rc);
 }
 
 static void __init of_selftest_property_match_string(void)
-- 
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/

[PATCH v3 5/5] gpio: Make of_count_named_gpios() use new of_count_phandle_with_args()

[Grant Likely]

This patch replaces the horribly coded of_count_named_gpios() with a
call to of_count_phandle_with_args() which is far more efficient. This
also changes the return value of of_gpio_count() & of_gpio_named_count()
from 'unsigned int' to 'int' so that it can return an error code. All
the users of that function are fixed up to correctly handle a negative
return value.

v2: Split GPIO portion into a separate patch

Signed-off-by: Grant Likely 
Cc: Linus Walleij 
Cc: Rob Herring 
Cc: Andreas Larsson 
---
 drivers/gpio/gpiolib-of.c  |   35 
 drivers/hwmon/gpio-fan.c   |4 ++--
 drivers/input/keyboard/matrix_keypad.c |8 +++
 drivers/net/phy/mdio-mux-gpio.c|4 ++--
 drivers/spi/spi-fsl-spi.c  |4 ++--
 drivers/spi/spi-oc-tiny.c  |8 +++
 drivers/spi/spi-ppc4xx.c   |4 ++--
 drivers/spi/spi.c  |5 ++--
 include/linux/of_gpio.h|   40 ++--
 9 files changed, 41 insertions(+), 71 deletions(-)

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index d542a14..dd8a212 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -89,41 +89,6 @@ int of_get_named_gpio_flags(struct device_node *np, const 
char *propname,
 EXPORT_SYMBOL(of_get_named_gpio_flags);
 
 /**
- * of_gpio_named_count - Count GPIOs for a device
- * @np:device node to count GPIOs for
- * @propname:  property name containing gpio specifier(s)
- *
- * The function returns the count of GPIOs specified for a node.
- *
- * Note that the empty GPIO specifiers counts too. For example,
- *
- * gpios = <0
- *   1 2
- *  0
- *   3 4>;
- *
- * defines four GPIOs (so this function will return 4), two of which
- * are not specified.
- */
-unsigned int of_gpio_named_count(struct device_node *np, const char* propname)
-{
-   unsigned int cnt = 0;
-
-   do {
-   int ret;
-
-   ret = of_parse_phandle_with_args(np, propname, "#gpio-cells",
-cnt, NULL);
-   /* A hole in the gpios = <> counts anyway. */
-   if (ret < 0 && ret != -EEXIST)
-   break;
-   } while (++cnt);
-
-   return cnt;
-}
-EXPORT_SYMBOL(of_gpio_named_count);
-
-/**
  * of_gpio_simple_xlate - translate gpio_spec to the GPIO number and flags
  * @gc:pointer to the gpio_chip structure
  * @np:device node of the GPIO chip
diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
index 4e04c12..3978194 100644
--- a/drivers/hwmon/gpio-fan.c
+++ b/drivers/hwmon/gpio-fan.c
@@ -422,7 +422,7 @@ static int gpio_fan_get_of_pdata(struct device *dev,
 
/* Fill GPIO pin array */
pdata->num_ctrl = of_gpio_count(node);
-   if (!pdata->num_ctrl) {
+   if (pdata->num_ctrl <= 0) {
dev_err(dev, "gpios DT property empty / missing");
return -ENODEV;
}
@@ -477,7 +477,7 @@ static int gpio_fan_get_of_pdata(struct device *dev,
pdata->speed = speed;
 
/* Alarm GPIO if one exists */
-   if (of_gpio_named_count(node, "alarm-gpios")) {
+   if (of_gpio_named_count(node, "alarm-gpios") > 0) {
struct gpio_fan_alarm *alarm;
int val;
enum of_gpio_flags flags;
diff --git a/drivers/input/keyboard/matrix_keypad.c 
b/drivers/input/keyboard/matrix_keypad.c
index f4ff0dd..71d7719 100644
--- a/drivers/input/keyboard/matrix_keypad.c
+++ b/drivers/input/keyboard/matrix_keypad.c
@@ -403,7 +403,7 @@ matrix_keypad_parse_dt(struct device *dev)
struct matrix_keypad_platform_data *pdata;
struct device_node *np = dev->of_node;
unsigned int *gpios;
-   int i;
+   int i, nrow, ncol;
 
if (!np) {
dev_err(dev, "device lacks DT data\n");
@@ -416,9 +416,9 @@ matrix_keypad_parse_dt(struct device *dev)
return ERR_PTR(-ENOMEM);
}
 
-   pdata->num_row_gpios = of_gpio_named_count(np, "row-gpios");
-   pdata->num_col_gpios = of_gpio_named_count(np, "col-gpios");
-   if (!pdata->num_row_gpios || !pdata->num_col_gpios) {
+   pdata->num_row_gpios = nrow = of_gpio_named_count(np, "row-gpios");
+   pdata->num_col_gpios = ncol = of_gpio_named_count(np, "col-gpios");
+   if (nrow <= 0 || ncol <= 0) {
dev_err(dev, "number of keypad rows/columns not specified\n");
return ERR_PTR(-EINVAL);
}
diff --git a/drivers/net/phy/mdio-mux-gpio.c b/drivers/net/phy/mdio-mux-gpio.c
index 0c9accb..e91d7d7 100644
--- a/drivers/net/phy/mdio-mux-gpio.c
+++ b/drivers/net/phy/mdio-mux-gpio.c
@@ -53,7 +53,7 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
 {
enum of_gpio_flags f;
struct mdio_mux_gpio_state *s;
-   unsigned int num_gpios;
+   int num_gpios;
 

Re: [GIT PULL] at91: fixes for 3.9-rc1

[Olof Johansson]

On Tue, Feb 12, 2013 at 09:32:42AM +0100, Nicolas Ferre wrote:
> On 02/05/2013 11:20 AM, Nicolas Ferre :
> > Arnd, Olof,
> > 
> > As I realized reading Linus' email that it was not possible to queue more
> > fixes for 3.8, I took my time to send this tiny pull request. But now that
> > the merge window is approaching, I prefer not to wait for more material.
> > So, here is a "fixes" pull-request embedding a single patch. I have placed 
> > this
> > one on top of material that you already have from me in your "fixes" and
> > "for-next" branches.
> 
> Olof,
> 
> Ping?
> 
> As the other AT91 related branches have been pulled in, I suspect this
> little pull-request had been forgotten.

Yeah, due to the hold-off on fixes in general I let this one sit for a bit
while I sorted out what we were going to send to Linus. I've pulled it in now.

Thanks for the reminder.


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

Re: [PATCH] net: ethernet: ti: remove redundant NULL check.

[Cyril Roelandt]

On 02/12/2013 11:06 PM, David Miller wrote:

From: Cyril Roelandt
Date: Tue, 12 Feb 2013 22:54:46 +0100


cpdma_chan_destroy() on a NULL pointer is a no-op, so the NULL check in
cpdma_ctlr_destroy() can safely be removed.

Signed-off-by: Cyril Roelandt

  ...

@@ -450,8 +450,7 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
cpdma_ctlr_stop(ctlr);

for (i = 0; i<  ARRAY_SIZE(ctlr->channels); i++) {
-   if (ctlr->channels[i])
-   cpdma_chan_destroy(ctlr->channels[i]);
+   cpdma_chan_destroy(ctlr->channels[i]);
}


SInce this is now a single statement basic block, remove the
surrounding braces.


Ok, I resent, though I forgot to add "v2".

Regards,
Cyril Roelandt.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 109/173] drm/i915: Close race between processing unpin task and queueing the flip

[Herton Ronaldo Krzesinski]

On Fri, Dec 28, 2012 at 08:05:19PM +0100, Ben Hutchings wrote:
> 3.2-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Chris Wilson 
> 
> commit e7d841ca03b7ab668620045cd7b428eda9f41601 upstream.
> 
[...]
> @@ -7157,6 +7176,10 @@ static int intel_gen4_queue_flip(struct
>   pf = 0;
>   pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff;
>   OUT_RING(pf | pipesrc);
> +
> + intel_mark_page_flip_active(intel_crtc);
> +
> + intel_mark_page_flip_active(intel_crtc);
>   ADVANCE_LP_RING();
>   return 0;
>  

There is a problem with this patch on 3.2. First we have
intel_mark_page_flip_active duplicated on intel_gen4_queue_flip here
(harmless), but one missing call for it in intel_gen6_queue_flip

Reached to this after reproducing which is probably the same
problem people are reporting here: http://bugs.launchpad.net/bugs/1119809
A bisect pointed to this change, and the following diff fixed the issue
on the i915 based machine I used to reproduce:

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4da3c7e..ce23961 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7155,8 +7155,6 @@ static int intel_gen4_queue_flip(struct drm_device *dev,
OUT_RING(pf | pipesrc);
 
intel_mark_page_flip_active(intel_crtc);
-
-   intel_mark_page_flip_active(intel_crtc);
ADVANCE_LP_RING();
return 0;
 
@@ -7192,6 +7190,8 @@ static int intel_gen6_queue_flip(struct drm_device *dev,
pf = I915_READ(PF_CTL(intel_crtc->pipe)) & PF_ENABLE;
pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff;
OUT_RING(pf | pipesrc);
+
+   intel_mark_page_flip_active(intel_crtc);
ADVANCE_LP_RING();
return 0;
 

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

[PATCH] net: ethernet: ti: remove redundant NULL check.

[Cyril Roelandt]

cpdma_chan_destroy() on a NULL pointer is a no-op, so the NULL check in
cpdma_ctlr_destroy() can safely be removed.

Signed-off-by: Cyril Roelandt 
---
 drivers/net/ethernet/ti/davinci_cpdma.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c 
b/drivers/net/ethernet/ti/davinci_cpdma.c
index f862918..1c4b0aa 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -449,10 +449,8 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
if (ctlr->state != CPDMA_STATE_IDLE)
cpdma_ctlr_stop(ctlr);
 
-   for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++) {
-   if (ctlr->channels[i])
-   cpdma_chan_destroy(ctlr->channels[i]);
-   }
+   for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++)
+   cpdma_chan_destroy(ctlr->channels[i]);
 
cpdma_desc_pool_destroy(ctlr->pool);
spin_unlock_irqrestore(>lock, flags);
-- 
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/

[PATCH 2/3] sched: Move idle_balance() to post_schedule

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

The idle_balance() code is called to do task load balancing just before
going to idle. This makes sense as the CPU is about to sleep anyway.
But currently it's called in the middle of the scheduler and in a place
that must have interrupts disabled. That means, while the load balancing
is going on, if a task wakes up on this CPU, it wont get to run while
the interrupts are disabled. The idle task doing the balancing will be
clueless about it.

There's no real reason that the idle_balance() needs to be called in the
middle of schedule anyway. The only benefit is that if a task is pulled
to this CPU, it can be scheduled without the need to schedule the idle
task. But load balancing and migrating the task makes a switch to idle
and back negligible.

By using the post_schedule function pointer of the sched class, the
unlikely branch in the hot path of the scheduler can be removed, and
the idle task itself can do the load balancing.

Another advantage of this, is that by moving the idle_balance to the
post_schedule routine, interrupts can now be enabled in the load balance
allowing for interrupts and wakeups to still occur on that CPU while a
balance is taking place. The enabling of interrupts will come as a separate
patch.

Cc: Peter Zijlstra 
Signed-off-by: Steven Rostedt 
---
 kernel/sched/core.c  |3 ---
 kernel/sched/idle_task.c |   10 ++
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1dff78a..a9317b7 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2927,9 +2927,6 @@ need_resched:
 
pre_schedule(rq, prev);
 
-   if (unlikely(!rq->nr_running))
-   idle_balance(cpu, rq);
-
put_prev_task(rq, prev);
next = pick_next_task(rq);
clear_tsk_need_resched(prev);
diff --git a/kernel/sched/idle_task.c b/kernel/sched/idle_task.c
index b6baf37..66b5220 100644
--- a/kernel/sched/idle_task.c
+++ b/kernel/sched/idle_task.c
@@ -13,6 +13,11 @@ select_task_rq_idle(struct task_struct *p, int sd_flag, int 
flags)
 {
return task_cpu(p); /* IDLE tasks as never migrated */
 }
+
+static void post_schedule_idle(struct rq *rq)
+{
+   idle_balance(smp_processor_id(), rq);
+}
 #endif /* CONFIG_SMP */
 /*
  * Idle tasks are unconditionally rescheduled:
@@ -25,6 +30,10 @@ static void check_preempt_curr_idle(struct rq *rq, struct 
task_struct *p, int fl
 static struct task_struct *pick_next_task_idle(struct rq *rq)
 {
schedstat_inc(rq, sched_goidle);
+#ifdef CONFIG_SMP
+   /* Trigger the post schedule to do an idle_balance */
+   rq->post_schedule = 1;
+#endif
return rq->idle;
 }
 
@@ -86,6 +95,7 @@ const struct sched_class idle_sched_class = {
 
 #ifdef CONFIG_SMP
.select_task_rq = select_task_rq_idle,
+   .post_schedule  = post_schedule_idle,
 #endif
 
.set_curr_task  = set_curr_task_idle,
-- 
1.7.10.4




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

[PATCH 1/3] sched/rt: Fix push_rt_task() to have the same checks as the caller did

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

Currently, push_rt_task() only pushes the task if it is lower
priority than the currently running task.

But it can be called for other reasons. Namely, if the current process
that is about to be preempted, is a real time task and is also pinned
to the CPU. This happens on wake up of high priority task. A check
is made in wake_up_rt() to see if the woken task can preempt the
task on its CPU, and the running task is not a pinned RT task. If
the task is pinned, and the woken task can migrate, it will try to
migrate it by calling push_rt_task().

Now in push_rt_task(), it will check if it can preempt the current
task but does not check if that task is pinned. If the woken task
is of higher priority, it wont try to migrate the woken task, even
if the other task is pinned. It will simply not push the task, which
is not consistent with the reason that push_rt_task() was called for
in the first place. Even for other callers of push_rt_task(), the task
should try to avoid preempting pinned RT tasks.

A helper routine is created call "ok_to_push_task()" that is now
used by both the wake_up_rt() and push_rt_task() code.

Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Steven Rostedt 
---
 kernel/sched/rt.c |   15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index c25de14..6f3108e 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1613,6 +1613,14 @@ static struct task_struct 
*pick_next_pushable_task(struct rq *rq)
return p;
 }
 
+static int ok_to_push_task(struct task_struct *p, struct task_struct *curr)
+{
+   return p->nr_cpus_allowed > 1 &&
+   rt_task(curr) &&
+   (curr->nr_cpus_allowed < 2 ||
+curr->prio <= p->prio);
+}
+
 /*
  * If the current CPU has more than one RT task, see if the non
  * running task can migrate over to a CPU that is running a task
@@ -1642,7 +1650,7 @@ retry:
 * higher priority than current. If that's the case
 * just reschedule current.
 */
-   if (unlikely(next_task->prio < rq->curr->prio)) {
+   if (!ok_to_push_task(next_task, rq->curr)) {
resched_task(rq->curr);
return 0;
}
@@ -1807,10 +1815,7 @@ static void task_woken_rt(struct rq *rq, struct 
task_struct *p)
if (!task_running(rq, p) &&
!test_tsk_need_resched(rq->curr) &&
has_pushable_tasks(rq) &&
-   p->nr_cpus_allowed > 1 &&
-   rt_task(rq->curr) &&
-   (rq->curr->nr_cpus_allowed < 2 ||
-rq->curr->prio <= p->prio))
+   ok_to_push_task(p, rq->curr))
push_rt_tasks(rq);
 }
 
-- 
1.7.10.4




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

[PATCH 0/3] [GIT PULL] sched: clean ups and a minor fix

[Steven Rostedt]

Ingo,

The first of the patches is a minor fix to when a woken RT task is about
to preempt a pinned RT task, push_rt_task() is called to try to
migrate the woken task if possible (to avoid preempting a pinned RT
task that may be the second highest priority task in the system).

But the issue is that push_rt_task() won't push it if the woken task
is higher priority even if the task to be preempted is pinned.

The second two patches is more of a clean up to remove the idle
hooks in the scheduler proper, and to use the pre/post schedule
methods instead.

This allows interrupts to be enabled in the idle balance, which slightly
helps latencies, especially for the -rt kernel. Other patches can be
added on top. Maybe in the future preemption could be enabled during
the idle balance as well. But that remains to be seen.

Please pull the latest tip/sched/core tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/sched/core

Head SHA1: 1db13ecf89054d39922e7b3323d124c7e2921560


Steven Rostedt (Red Hat) (3):
  sched/rt: Fix push_rt_task() to have the same checks as the caller did
  sched: Move idle_balance() to post_schedule
  sched: Enable interrupts in idle_balance()


 kernel/sched/core.c  |3 ---
 kernel/sched/fair.c  |8 +---
 kernel/sched/idle_task.c |   10 ++
 kernel/sched/rt.c|   15 ++-
 4 files changed, 25 insertions(+), 11 deletions(-)


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

[PATCH 3/3] sched: Enable interrupts in idle_balance()

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

Now that the idle_balance is called from the post_schedule of the
idle task sched class, it is safe to enable interrupts. This allows
for better interaction of tasks waking up and other interrupts that
are triggered while the idle balance is in process.

Preemption is still disabled, but perhaps that can change as well.
That may need some more investigation.

It may be safe to also enable preemption, but we'll leave that change
for another time.

Cc: Peter Zijlstra 
Signed-off-by: Steven Rostedt 
---
 kernel/sched/fair.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ed18c74..0fcdbff 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5222,9 +5222,10 @@ void idle_balance(int this_cpu, struct rq *this_rq)
update_rq_runnable_avg(this_rq, 1);
 
/*
-* Drop the rq->lock, but keep IRQ/preempt disabled.
+* Drop the rq->lock, but keep preempt disabled.
 */
-   raw_spin_unlock(_rq->lock);
+   preempt_disable();
+   raw_spin_unlock_irq(_rq->lock);
 
update_blocked_averages(this_cpu);
rcu_read_lock();
@@ -5251,7 +5252,8 @@ void idle_balance(int this_cpu, struct rq *this_rq)
}
rcu_read_unlock();
 
-   raw_spin_lock(_rq->lock);
+   raw_spin_lock_irq(_rq->lock);
+   preempt_enable();
 
if (pulled_task || time_after(jiffies, this_rq->next_balance)) {
/*
-- 
1.7.10.4




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

Re: [PATCH] ARM: exynos: move exynos4210-combiner to drivers/irqchip

[Olof Johansson]

On Tue, Feb 12, 2013 at 04:04:52PM -0600, Rob Herring wrote:
> From: Rob Herring 
> 
> Exynos boot is broken with commit 0529e315 (ARM: use common irqchip_init
> for GIC init). This commit split the irqchip initialization into 2 calls
> to of_irq_init. This does not work because of_irq_init requires interrupt
> parents to be in the match list.
> 
> Rather than reverting exynos changes, make it do the proper thing by using
> IRQCHIP_DECLARE. This requires moving the combiner code to drivers/irqchip.
> 
> Reported-by: Doug Anderson 
> Signed-off-by: Rob Herring 
> Cc: Kukjin Kim 
> Cc: Russell King 
> Cc: Thomas Gleixner 
> Cc: linux-samsung-...@vger.kernel.org
> ---
> 
> I thought there may be other platforms broken in the same way, but I
> checked and exynos is the only one.
> 
> This is based on my gic/vic irqchip branch in arm-soc.

Applied to next/cleanup.

I guess this answers whether anyone boots linux-next regularly on Exynos
hardware. :(


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/16] intel_idle: remove use and definition of MWAIT_MAX_NUM_CSTATES

[Daniel Lezcano]

On 02/12/2013 12:46 AM, Len Brown wrote:
> On 02/11/2013 03:53 AM, Daniel Lezcano wrote:
>> On 02/09/2013 02:08 AM, Len Brown wrote:
> 
>>> The reason to change is that intel_idle will soon be able
>>> to export more than the 8 "major" states supported by MWAIT.
>>> When we hit that limit, it is important to know
>>> where the limit comes from.
>>
>> Does it mean CPUIDLE_STATE_MAX may increase in a near future ?
> 
> Yes, perhaps to 10.
> Let me know if you anticipate issues with doing that.

No, I don't see any issue so far. Maybe the array state is increasing
more and more, so for most architecture it is a waste of memory, but
anyway ...



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/9] block: xd: replace all printks with pr_*

[Linus Walleij]

This replaces all the printk() statements with pr_* messages
tagged with the apropriate log level. Errors are printed as
pr_err() etc.

Signed-off-by: Linus Walleij 
---
 drivers/block/xd.c | 97 ++
 1 file changed, 62 insertions(+), 35 deletions(-)

diff --git a/drivers/block/xd.c b/drivers/block/xd.c
index 7ecebd4..8ee500f 100644
--- a/drivers/block/xd.c
+++ b/drivers/block/xd.c
@@ -331,7 +331,7 @@ static inline u_int xd_wait_for_IRQ(void)
release_dma_lock(flags);
 
if (xd_error) {
-   printk("xd: missed IRQ - command aborted\n");
+   pr_err("xd: missed IRQ - command aborted\n");
xd_error = 0;
return (1);
}
@@ -397,7 +397,7 @@ static u_int xd_command(u_char *command, u_char mode, 
u_char *indata,
if (csb & CSB_ERROR) {  
/* read sense data if error */
xd_build(cmdblk,CMD_SENSE,(csb & CSB_LUN) >> 5,0,0,0,0,0);
if (xd_command(cmdblk,0,sense,NULL,NULL,XD_TIMEOUT))
-   printk("xd: warning! sense command failed!\n");
+   pr_warning("xd: warning! sense command failed!\n");
}
 
pr_debug("%s: completed with csb = 0x%X\n", __func__, csb);
@@ -426,7 +426,8 @@ static void __init xd_setparam (u_char command, u_char 
drive, u_char heads,
 
/* Some controllers require geometry info as data, not command */
if (xd_command(cmdblk,PIO_MODE,NULL,[6],NULL,XD_TIMEOUT * 2))
-   printk("xd: error setting characteristics for xd%c\n", 
'a'+drive);
+   pr_err("xd: error setting characteristics for xd%c\n",
+  'a' + drive);
 }
 
 /**
@@ -439,7 +440,8 @@ static void xd_recalibrate(u_char drive)
 
xd_build(cmdblk,CMD_RECALIBRATE,drive,0,0,0,0,0);
if (xd_command(cmdblk,PIO_MODE,NULL,NULL,NULL,XD_TIMEOUT * 8))
-   printk("xd%c: warning! error recalibrating, controller may be 
unstable\n", 'a'+drive);
+   pr_warning("xd%c: warning! error recalibrating, controller may 
be unstable\n",
+  'a' + drive);
 }
 
 /**
@@ -488,29 +490,40 @@ static int xd_readwrite(u_char operation, struct xd_info 
*p, char *buffer,
 
switch (xd_command(cmdblk,mode,(u_char *)(*real_buffer),(u_char 
*)(*real_buffer),sense,XD_TIMEOUT)) {
case 1:
-   printk("xd%c: %s timeout, recalibrating 
drive\n",'a'+drive,(operation == READ ? "read" : "write"));
+   pr_err("xd%c: %s timeout, recalibrating 
drive\n",
+  'a' + drive,
+  (operation == READ ? "read" : "write"));
xd_recalibrate(drive);
spin_lock_irq(_lock);
return -EIO;
case 2:
if (sense[0] & 0x30) {
-   printk("xd%c: %s - 
",'a'+drive,(operation == READ ? "reading" : "writing"));
+   pr_err("xd%c: %s - ", 'a' + drive,
+  (operation == READ ? "reading" : 
"writing"));
switch ((sense[0] & 0x30) >> 4) {
-   case 0: printk("drive error, code = 
0x%X",sense[0] & 0x0F);
+   case 0:
+   pr_cont("drive error, code = 
0x%X",
+  sense[0] & 0x0F);
break;
-   case 1: printk("controller error, code 
= 0x%X",sense[0] & 0x0F);
+   case 1:
+   pr_cont("controller error, code 
= 0x%X",
+  sense[0] & 0x0F);
break;
-   case 2: printk("command error, code = 
0x%X",sense[0] & 0x0F);
+   case 2:
+   pr_cont("command error, code = 
0x%X",
+  sense[0] & 0x0F);
break;
-   case 3: printk("miscellaneous error, 
code = 0x%X",sense[0] & 0x0F);
+   case 3:
+   pr_cont("miscellaneous error, 
code = 0x%X",
+  sense[0] & 0x0F);
break;
}
}
 

[PATCH 4/9] block: xd: some whitespace and #if 0 removal

[Linus Walleij]

Structure some whitespace that I personally found very irritating
when reading the code, like sole tabs on lines and dangling
spaces. (We get very used to our code looking the same these
days.) Also delete a few instances of commenting the obvious
like heads = 12 /* assign number of heads */ and some to git
they will not be fixed down the road either. Made some attempts
to document functions into legal kerneldoc (far from all).

Signed-off-by: Linus Walleij 
---
 drivers/block/xd.c | 319 +
 1 file changed, 174 insertions(+), 145 deletions(-)

diff --git a/drivers/block/xd.c b/drivers/block/xd.c
index 549a7fa..18f51e9 100644
--- a/drivers/block/xd.c
+++ b/drivers/block/xd.c
@@ -4,7 +4,7 @@
  *
  * Author: Pat Mackinlay, p...@it.com.au
  * Date: 29/09/92
- * 
+ *
  * Revised: 01/01/93, ...
  *
  * Ref: DTC 5150X Controller Specification (thanks to Kevin Fowler,
@@ -31,6 +31,8 @@
  *
  * Bugfix: 15/02/01, Paul G. - inform queue layer of tiny xd_maxsect.
  *
+ * Revised 12/02/13, Linus Walleij - add delays after outb(), increase
+ *   timeouts, fix whitespace and checkpatch issues.
  */
 
 #include 
@@ -65,38 +67,54 @@ static void __init do_xd_setup (int *integers);
 static int xd[5] = { -1,-1,-1,-1, };
 #endif
 
-#define XD_DONT_USE_DMA0  /* Initial value. may be overriden 
using
- "nodma" module option */
-#define XD_INIT_DISK_DELAY (30)  /* 30 ms delay during disk initialization 
*/
+/* Initial value. may be overriden using "nodma" module option */
+#define XD_DONT_USE_DMA0
+/* 30 ms delay during disk initialization */
+#define XD_INIT_DISK_DELAY (30)
 
-/* Above may need to be increased if a problem with the 2nd drive detection
-   (ST11M controller) or resetting a controller (WD) appears */
+/*
+ * Above may need to be increased if a problem with the 2nd drive detection
+ * (ST11M controller) or resetting a controller (WD) appears
+ */
 
 static XD_INFO xd_info[XD_MAXDRIVES];
 
-/* If you try this driver and find that your card is not detected by the 
driver at bootup, you need to add your BIOS
-   signature and details to the following list of signatures. A BIOS signature 
is a string embedded into the first
-   few bytes of your controller's on-board ROM BIOS. To find out what yours 
is, use something like MS-DOS's DEBUG
-   command. Run DEBUG, and then you can examine your BIOS signature with:
-
-   d :
-
-   where  is the segment of your controller (like C800 or D000 or 
something). On the ASCII dump at the right, you should
-   be able to see a string mentioning the manufacturer's copyright etc. Add 
this string into the table below. The parameters
-   in the table are, in order:
-
-   offset  ; this is the offset (in bytes) from the start 
of your ROM where the signature starts
-   signature   ; this is the actual text of the signature
-   xd_?_init_controller; this is the controller init routine used by 
your controller
-   xd_?_init_drive ; this is the drive init routine used by your 
controller
-
-   The controllers directly supported at the moment are: DTC 5150x, WD 
1004A27X, ST11M/R and override. If your controller is
-   made by the same manufacturer as one of these, try using the same init 
routines as they do. If that doesn't work, your
-   best bet is to use the "override" routines. These routines use a "portable" 
method of getting the disk's geometry, and
-   may work with your card. If none of these seem to work, try sending me some 
email and I'll see what I can do .
-
-   NOTE: You can now specify your XT controller's parameters from the command 
line in the form xd=TYPE,IRQ,IO,DMA. The driver
-   should be able to detect your drive's geometry from this info. (eg: 
xd=0,5,0x320,3 is the "standard"). */
+/*
+ * If you try this driver and find that your card is not detected by the
+ * driver at bootup, you need to add your BIOS signature and details to the
+ * following list of signatures. A BIOS signature is a string embedded into
+ * the first few bytes of your controller's on-board ROM BIOS. To find out
+ * what yours is, use something like MS-DOS's DEBUG command. Run DEBUG, and
+ * then you can examine your BIOS signature with:
+ *
+ * d :
+ *
+ * where  is the segment of your controller (like C800 or D000 or
+ * something). On the ASCII dump at the right, you should be able to see a
+ * string mentioning the manufacturer's copyright etc. Add this string into
+ * the table below. The parameters in the table are, in order:
+ *
+ * offset  ; this is the offset (in bytes) from the
+ * ; start of your ROM where the signature starts
+ * signature   ; this is the actual text of the signature
+ * xd_?_init_controller; this is the controller init routine used by
+ * ; your 

[PATCH 6/9] block: xd: avoid some forward declarations

[Linus Walleij]

This moves the code around so that we can avoid a dozen
forward-declarations, then move the few remaining ones above the
table that use them. No semantic changes.

Signed-off-by: Linus Walleij 
---
 drivers/block/xd.c | 801 +++--
 drivers/block/xd.h |  33 ---
 2 files changed, 415 insertions(+), 419 deletions(-)

diff --git a/drivers/block/xd.c b/drivers/block/xd.c
index 9e00753..ffa6e76 100644
--- a/drivers/block/xd.c
+++ b/drivers/block/xd.c
@@ -121,6 +121,20 @@ static struct xd_info xd_info[XD_MAXDRIVES];
 #define xd_dma_mem_free(addr, size) free_pages(addr, get_order(size))
 static char *xd_dma_buffer;
 
+/* card specific setup and geometry gathering code */
+static void xd_dtc_init_controller (unsigned int address);
+static void xd_dtc5150cx_init_drive (u_char drive);
+static void xd_dtc_init_drive (u_char drive);
+static void xd_wd_init_controller (unsigned int address);
+static void xd_wd_init_drive (u_char drive);
+static void xd_seagate_init_controller (unsigned int address);
+static void xd_seagate_init_drive (u_char drive);
+static void xd_omti_init_controller (unsigned int address);
+static void xd_omti_init_drive (u_char drive);
+static void xd_xebec_init_controller (unsigned int address);
+static void xd_xebec_init_drive (u_char drive);
+static void xd_override_init_drive (u_char drive);
+
 static struct xd_signature xd_sigs[] __initdata = {
{ 0x,"Override geometry handler",NULL,xd_override_init_drive,"n 
unknown" }, /* Pat Mackinlay, p...@it.com.au */
{ 0x0008,"[BXD06 (C) DTC 
17-MAY-1985]",xd_dtc_init_controller,xd_dtc5150cx_init_drive," DTC 5150CX" }, 
/* Andrzej Krzysztofowicz, an...@mif.pg.gda.pl */
@@ -150,13 +164,6 @@ static DEFINE_SPINLOCK(xd_lock);
 
 static struct gendisk *xd_gendisk[2];
 
-static int xd_getgeo(struct block_device *bdev, struct hd_geometry *geo);
-
-static const struct block_device_operations xd_fops = {
-   .owner  = THIS_MODULE,
-   .ioctl  = xd_ioctl,
-   .getgeo = xd_getgeo,
-};
 static DECLARE_WAIT_QUEUE_HEAD(xd_wait_int);
 static u_char xd_drives, xd_irq = 5, xd_dma = 3, xd_maxsectors;
 static u_char xd_override __initdata = 0, xd_type __initdata = 0;
@@ -171,251 +178,206 @@ static bool nodma = XD_DONT_USE_DMA;
 
 static struct request_queue *xd_queue;
 
-/* xd_init: register the block device number and set up pointer tables */
-static int __init xd_init(void)
+/**
+ * xd_setup_dma() - set up the DMA controller for a data transfer
+ */
+static u_char xd_setup_dma(u_char mode, u_char *buffer, u_int count)
 {
-   u_char i,controller;
-   unsigned int address;
-   int err;
+   unsigned long f;
 
-#ifdef MODULE
-   {
-   u_char count = 0;
-   for (i = 4; i > 0; i--)
-   if (((xd[i] = xd[i-1]) >= 0) && !count)
-   count = i;
-   if ((xd[0] = count))
-   do_xd_setup(xd);
+   if (nodma)
+   return (PIO_MODE);
+   if (((unsigned long) buffer & 0x) != (((unsigned long) buffer + 
count) & 0x)) {
+#ifdef DEBUG_OTHER
+   printk("xd_setup_dma: using PIO, transfer overlaps 64k 
boundary\n");
+#endif /* DEBUG_OTHER */
+   return (PIO_MODE);
}
-#endif
 
-   init_timer (_watchdog_int); xd_watchdog_int.function = xd_watchdog;
-
-   err = -EBUSY;
-   if (register_blkdev(XT_DISK_MAJOR, "xd"))
-   goto out1;
+   f=claim_dma_lock();
+   disable_dma(xd_dma);
+   clear_dma_ff(xd_dma);
+   set_dma_mode(xd_dma,mode);
+   set_dma_addr(xd_dma, (unsigned long) buffer);
+   set_dma_count(xd_dma,count);
 
-   err = -ENOMEM;
-   xd_queue = blk_init_queue(do_xd_request, _lock);
-   if (!xd_queue)
-   goto out1a;
+   release_dma_lock(f);
 
-   if (xd_detect(,)) {
+   return (DMA_MODE); /* use DMA and INT */
+}
 
-   printk("Detected a%s controller (type %d) at address %06x\n",
-   xd_sigs[controller].name,controller,address);
-   if (!request_region(xd_iobase,4,"xd")) {
-   printk("xd: Ports at 0x%x are not available\n",
-   xd_iobase);
-   goto out2;
-   }
-   if (controller)
-   xd_sigs[controller].init_controller(address);
-   xd_drives = xd_initdrives(xd_sigs[controller].init_drive);
+/**
+ * xd_build() - put stuff into an array in a format suitable for
+ * the controller
+ */
+static u_char *xd_build(u_char *cmdblk, u_char command, u_char drive,
+   u_char head, u_short cylinder, u_char sector,
+   u_char count, u_char control)
+{
+   cmdblk[0] = command;
+   cmdblk[1] = ((drive & 0x07) << 5) | (head & 0x1F);
+   cmdblk[2] = ((cylinder & 0x300) >> 2) | (sector & 0x3F);
+   cmdblk[3] = cylinder & 0xFF;
+   cmdblk[4] 

[PATCH 5/9] block: xd: avoid using typedefs

[Linus Walleij]

Two of the structs in the driver were using typedef, which we
avoid since ages in the kernel.

Signed-off-by: Linus Walleij 
---
 drivers/block/xd.c | 12 ++--
 drivers/block/xd.h | 10 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/block/xd.c b/drivers/block/xd.c
index 18f51e9..9e00753 100644
--- a/drivers/block/xd.c
+++ b/drivers/block/xd.c
@@ -77,7 +77,7 @@ static int xd[5] = { -1,-1,-1,-1, };
  * (ST11M controller) or resetting a controller (WD) appears
  */
 
-static XD_INFO xd_info[XD_MAXDRIVES];
+static struct xd_info xd_info[XD_MAXDRIVES];
 
 /*
  * If you try this driver and find that your card is not detected by the
@@ -121,7 +121,7 @@ static XD_INFO xd_info[XD_MAXDRIVES];
 #define xd_dma_mem_free(addr, size) free_pages(addr, get_order(size))
 static char *xd_dma_buffer;
 
-static XD_SIGNATURE xd_sigs[] __initdata = {
+static struct xd_signature xd_sigs[] __initdata = {
{ 0x,"Override geometry handler",NULL,xd_override_init_drive,"n 
unknown" }, /* Pat Mackinlay, p...@it.com.au */
{ 0x0008,"[BXD06 (C) DTC 
17-MAY-1985]",xd_dtc_init_controller,xd_dtc5150cx_init_drive," DTC 5150CX" }, 
/* Andrzej Krzysztofowicz, an...@mif.pg.gda.pl */
{ 0x000B,"CRD18A   Not an IBM rom. (C) Copyright Data Technology Corp. 
05/31/88",xd_dtc_init_controller,xd_dtc_init_drive," DTC 5150X" }, /* Todd 
Fries, tfr...@umr.edu */
@@ -235,7 +235,7 @@ static int __init xd_init(void)
goto out3;
 
for (i = 0; i < xd_drives; i++) {
-   XD_INFO *p = _info[i];
+   struct xd_info *p = _info[i];
struct gendisk *disk = alloc_disk(64);
if (!disk)
goto Enomem;
@@ -339,7 +339,7 @@ static void do_xd_request(struct request_queue * q)
while (req) {
unsigned block = blk_rq_pos(req);
unsigned count = blk_rq_cur_sectors(req);
-   XD_INFO *disk = req->rq_disk->private_data;
+   struct xd_info *disk = req->rq_disk->private_data;
int res = 0;
int retry;
 
@@ -365,7 +365,7 @@ static void do_xd_request(struct request_queue * q)
 
 static int xd_getgeo(struct block_device *bdev, struct hd_geometry *geo)
 {
-   XD_INFO *p = bdev->bd_disk->private_data;
+   struct xd_info *p = bdev->bd_disk->private_data;
 
geo->heads = p->heads;
geo->sectors = p->sectors;
@@ -416,7 +416,7 @@ static int xd_ioctl(struct block_device *bdev, fmode_t mode,
 }
 
 /* xd_readwrite: handle a read/write request */
-static int xd_readwrite(u_char operation, XD_INFO *p, char *buffer,
+static int xd_readwrite(u_char operation, struct xd_info *p, char *buffer,
u_int block, u_int count)
 {
int drive = p->unit;
diff --git a/drivers/block/xd.h b/drivers/block/xd.h
index 489e1ce..40630db 100644
--- a/drivers/block/xd.h
+++ b/drivers/block/xd.h
@@ -81,22 +81,22 @@
 #endif /* DEBUG */
 
 /* this structure defines the XT drives and their types */
-typedef struct {
+struct xd_info {
u_char heads;
u_short cylinders;
u_char sectors;
u_char control;
int unit;
-} XD_INFO;
+};
 
 /* this structure defines a ROM BIOS signature */
-typedef struct {
+struct xd_signature {
unsigned int offset;
const char *string;
void (*init_controller)(unsigned int address);
void (*init_drive)(u_char drive);
const char *name;
-} XD_SIGNATURE;
+};
 
 #ifndef MODULE
 static int xd_manual_geo_init (char *command);
@@ -106,7 +106,7 @@ static u_char xd_initdrives (void (*init_drive)(u_char 
drive));
 
 static void do_xd_request (struct request_queue * q);
 static int xd_ioctl (struct block_device *bdev,fmode_t mode,unsigned int 
cmd,unsigned long arg);
-static int xd_readwrite (u_char operation,XD_INFO *disk,char *buffer,u_int 
block,u_int count);
+static int xd_readwrite (u_char operation, struct xd_info *disk,char 
*buffer,u_int block,u_int count);
 static void xd_recalibrate (u_char drive);
 
 static irqreturn_t xd_interrupt_handler(int irq, void *dev_id);
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] block: xd: introduce a delay before every outb operation

[Linus Walleij]

When I plug an ISA XT 8bit card into a 16bit compatible EISA
slot, the outb() operations seemingly stumble over each other
so we need to introduce a small delay after each outb()
operation. After this my MFM MiniScribe harddrive is properly
detected like this:

Detected 1 hard drive (using IRQ5 & DMA3)
 xda: CHS=615/4/17

Signed-off-by: Linus Walleij 
---
 drivers/block/xd.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xd.c b/drivers/block/xd.c
index ff54052..303e9f2 100644
--- a/drivers/block/xd.c
+++ b/drivers/block/xd.c
@@ -57,6 +57,8 @@
 
 #include "xd.h"
 
+#define OUTB_DELAY 100
+
 static DEFINE_MUTEX(xd_mutex);
 static void __init do_xd_setup (int *integers);
 #ifdef MODULE
@@ -485,7 +487,8 @@ static irqreturn_t xd_interrupt_handler(int irq, void 
*dev_id)
 #ifdef DEBUG_OTHER
printk("xd_interrupt_handler: interrupt detected\n");
 #endif /* DEBUG_OTHER */
-   outb(0,XD_CONTROL); 
/* acknowledge interrupt */
+   outb(0,XD_CONTROL); /* acknowledge interrupt */
+   udelay(OUTB_DELAY);
wake_up(_wait_int);  /* and wake up sleeping processes */
return IRQ_HANDLED;
}
@@ -588,7 +591,9 @@ static u_int xd_command (u_char *command,u_char mode,u_char 
*indata,u_char *outd
 #endif /* DEBUG_COMMAND */
 
outb(0,XD_SELECT);
+   udelay(OUTB_DELAY);
outb(mode,XD_CONTROL);
+   udelay(OUTB_DELAY);
 
if (xd_waitport(XD_STATUS,STAT_SELECT,STAT_SELECT,timeout))
return (1);
@@ -602,8 +607,10 @@ static u_int xd_command (u_char *command,u_char 
mode,u_char *indata,u_char *outd
if (mode == DMA_MODE) {
if (xd_wait_for_IRQ())
return (1);
-   } else
+   } else {
outb(outdata ? *outdata++ : 0,XD_DATA);
+   udelay(OUTB_DELAY);
+   }
break;
case STAT_INPUT:
if (mode == DMA_MODE) {
@@ -617,6 +624,7 @@ static u_int xd_command (u_char *command,u_char mode,u_char 
*indata,u_char *outd
break;
case STAT_COMMAND:
outb(command ? *command++ : 0,XD_DATA);
+   udelay(OUTB_DELAY);
break;
case STAT_COMMAND | STAT_INPUT:
complete = 1;
@@ -680,6 +688,7 @@ static void __init xd_dtc_init_controller (unsigned int 
address)
xd_maxsectors = 0x01;   /* my card seems to have trouble doing 
multi-block transfers? */
 
outb(0,XD_RESET);   /* reset the controller */
+   udelay(OUTB_DELAY);
 }
 
 
@@ -773,6 +782,7 @@ static void __init xd_wd_init_controller (unsigned int 
address)
xd_maxsectors = 0x01;   /* this one doesn't wrap properly 
either... */
 
outb(0,XD_RESET);   /* reset the controller */
+   udelay(OUTB_DELAY);
 
msleep(XD_INIT_DISK_DELAY);
 }
@@ -875,6 +885,7 @@ static void __init xd_seagate_init_controller (unsigned int 
address)
xd_maxsectors = 0x40;
 
outb(0,XD_RESET);   /* reset the controller */
+   udelay(OUTB_DELAY);
 }
 
 static void __init xd_seagate_init_drive (u_char drive)
@@ -908,6 +919,7 @@ static void __init xd_omti_init_controller (unsigned int 
address)
xd_maxsectors = 0x40;
 
outb(0,XD_RESET);   /* reset the controller */
+   udelay(OUTB_DELAY);
 }
 
 static void __init xd_omti_init_drive (u_char drive)
@@ -947,6 +959,7 @@ If you need non-standard settings use the xd=... command */
 
xd_maxsectors = 0x01;
outb(0,XD_RESET);   /* reset the controller */
+   udelay(OUTB_DELAY);
 
msleep(XD_INIT_DISK_DELAY);
 }
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/9] block: xd: merge header file into driver

[Linus Walleij]

This consolidates the XD driver in one single file.
No semantic changes.

Signed-off-by: Linus Walleij 
---
 drivers/block/xd.c |  84 +++-
 drivers/block/xd.h | 101 -
 2 files changed, 83 insertions(+), 102 deletions(-)
 delete mode 100644 drivers/block/xd.h

diff --git a/drivers/block/xd.c b/drivers/block/xd.c
index ffa6e76..1875590 100644
--- a/drivers/block/xd.c
+++ b/drivers/block/xd.c
@@ -53,11 +53,93 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 
-#include "xd.h"
+/* XT hard disk controller registers */
+#define XD_DATA(xd_iobase + 0x00)  /* data RW register */
+#define XD_RESET   (xd_iobase + 0x01)  /* reset WO register */
+#define XD_STATUS  (xd_iobase + 0x01)  /* status RO register */
+#define XD_SELECT  (xd_iobase + 0x02)  /* select WO register */
+#define XD_JUMPER  (xd_iobase + 0x02)  /* jumper RO register */
+#define XD_CONTROL (xd_iobase + 0x03)  /* DMAE/INTE WO register */
+#define XD_RESERVED(xd_iobase + 0x03)  /* reserved */
+
+/* XT hard disk controller commands (incomplete list) */
+#define CMD_TESTREADY  0x00/* test drive ready */
+#define CMD_RECALIBRATE0x01/* recalibrate drive */
+#define CMD_SENSE  0x03/* request sense */
+#define CMD_FORMATDRV  0x04/* format drive */
+#define CMD_VERIFY 0x05/* read verify */
+#define CMD_FORMATTRK  0x06/* format track */
+#define CMD_FORMATBAD  0x07/* format bad track */
+#define CMD_READ   0x08/* read */
+#define CMD_WRITE  0x0A/* write */
+#define CMD_SEEK   0x0B/* seek */
+
+/* Controller specific commands */
+#define CMD_DTCSETPARAM0x0C/* set drive parameters (DTC 5150X & CX 
only?) */
+#define CMD_DTCGETECC  0x0D/* get ecc error length (DTC 5150X only?) */
+#define CMD_DTCREADBUF 0x0E/* read sector buffer (DTC 5150X only?) */
+#define CMD_DTCWRITEBUF 0x0F   /* write sector buffer (DTC 5150X only?) */
+#define CMD_DTCREMAPTRK0x11/* assign alternate track (DTC 5150X 
only?) */
+#define CMD_DTCGETPARAM0xFB/* get drive parameters (DTC 5150X 
only?) */
+#define CMD_DTCSETSTEP 0xFC/* set step rate (DTC 5150X only?) */
+#define CMD_DTCSETGEOM 0xFE/* set geometry data (DTC 5150X only?) */
+#define CMD_DTCGETGEOM 0xFF/* get geometry data (DTC 5150X only?) */
+#define CMD_ST11GETGEOM 0xF8   /* get geometry data (Seagate ST11R/M only?) */
+#define CMD_WDSETPARAM 0x0C/* set drive parameters (WD 1004A27X only?) */
+#define CMD_XBSETPARAM 0x0C/* set drive parameters (XEBEC only?) */
+
+/* Bits for command status byte */
+#define CSB_ERROR  0x02/* error */
+#define CSB_LUN0x20/* logical Unit Number */
+
+/* XT hard disk controller status bits */
+#define STAT_READY 0x01/* controller is ready */
+#define STAT_INPUT 0x02/* data flowing from controller to host */
+#define STAT_COMMAND   0x04/* controller in command phase */
+#define STAT_SELECT0x08/* controller is selected */
+#define STAT_REQUEST   0x10/* controller requesting data */
+#define STAT_INTERRUPT 0x20/* controller requesting interrupt */
+
+/* XT hard disk controller control bits */
+#define PIO_MODE   0x00/* control bits to set for PIO */
+#define DMA_MODE   0x03/* control bits to set for DMA & interrupt */
+
+#define XD_MAXDRIVES   2   /* maximum 2 drives */
+#define XD_TIMEOUT (HZ * 30)   /* 30 second timeout */
+#define XD_RETRIES 4   /* maximum 4 retries */
+
+#undef DEBUG   /* define for debugging output */
+
+#ifdef DEBUG
+   #define DEBUG_STARTUP   /* debug driver initialisation */
+   #define DEBUG_OVERRIDE  /* debug override geometry detection */
+   #define DEBUG_READWRITE /* debug each read/write command */
+   #define DEBUG_OTHER /* debug misc. interrupt/DMA stuff */
+   #define DEBUG_COMMAND   /* debug each controller command */
+#endif /* DEBUG */
+
+/* this structure defines the XT drives and their types */
+struct xd_info {
+   u_char heads;
+   u_short cylinders;
+   u_char sectors;
+   u_char control;
+   int unit;
+};
+
+/* this structure defines a ROM BIOS signature */
+struct xd_signature {
+   unsigned int offset;
+   const char *string;
+   void (*init_controller)(unsigned int address);
+   void (*init_drive)(u_char drive);
+   const char *name;
+};
 
 #define OUTB_DELAY 100
 
diff --git a/drivers/block/xd.h b/drivers/block/xd.h
deleted file mode 100644
index f09a33d..000
--- a/drivers/block/xd.h
+++ /dev/null
@@ -1,101 +0,0 @@
-#ifndef _LINUX_XD_H
-#define _LINUX_XD_H
-
-/*
- * This file contains the definitions for the IO ports and errors etc. for XT 
hard disk controllers (at least the DTC 5150X).
- *
- * Author: Pat Mackinlay, p...@it.com.au
- * Date: 29/09/92
- *
- * Revised: 

[PATCH 8/9] block: xd: remove custom DEBUG print system

[Linus Walleij]

The driver used a variant of debug levels, convert this over to
using the kernel pr_debug() macro for all instances. Instead
of hard-coding function names in debug messages, pass __func__.

Signed-off-by: Linus Walleij 
---
 drivers/block/xd.c | 46 +++---
 1 file changed, 15 insertions(+), 31 deletions(-)

diff --git a/drivers/block/xd.c b/drivers/block/xd.c
index 1875590..7ecebd4 100644
--- a/drivers/block/xd.c
+++ b/drivers/block/xd.c
@@ -113,16 +113,6 @@
 #define XD_TIMEOUT (HZ * 30)   /* 30 second timeout */
 #define XD_RETRIES 4   /* maximum 4 retries */
 
-#undef DEBUG   /* define for debugging output */
-
-#ifdef DEBUG
-   #define DEBUG_STARTUP   /* debug driver initialisation */
-   #define DEBUG_OVERRIDE  /* debug override geometry detection */
-   #define DEBUG_READWRITE /* debug each read/write command */
-   #define DEBUG_OTHER /* debug misc. interrupt/DMA stuff */
-   #define DEBUG_COMMAND   /* debug each controller command */
-#endif /* DEBUG */
-
 /* this structure defines the XT drives and their types */
 struct xd_info {
u_char heads;
@@ -270,9 +260,8 @@ static u_char xd_setup_dma(u_char mode, u_char *buffer, 
u_int count)
if (nodma)
return (PIO_MODE);
if (((unsigned long) buffer & 0x) != (((unsigned long) buffer + 
count) & 0x)) {
-#ifdef DEBUG_OTHER
-   printk("xd_setup_dma: using PIO, transfer overlaps 64k 
boundary\n");
-#endif /* DEBUG_OTHER */
+   pr_debug("%s: using PIO, transfer overlaps 64k boundary\n",
+__func__);
return (PIO_MODE);
}
 
@@ -357,10 +346,8 @@ static u_int xd_command(u_char *command, u_char mode, 
u_char *indata,
 {
u_char cmdblk[6], csb, complete = 0;
 
-#ifdef DEBUG_COMMAND
-   printk("xd_command: command = 0x%X, mode = 0x%X, indata = 0x%X, outdata 
= 0x%X, sense = 0x%X\n",command,mode,indata,outdata,sense);
-#endif /* DEBUG_COMMAND */
-
+   pr_debug("%s: command = 0x%p, mode = 0x%X, indata = 0x%p, outdata = 
0x%p, sense = 0x%p\n",
+__func__, command, mode, indata, outdata, sense);
outb(0,XD_SELECT);
udelay(OUTB_DELAY);
outb(mode,XD_CONTROL);
@@ -413,9 +400,7 @@ static u_int xd_command(u_char *command, u_char mode, 
u_char *indata,
printk("xd: warning! sense command failed!\n");
}
 
-#ifdef DEBUG_COMMAND
-   printk("xd_command: completed with csb = 0x%X\n",csb);
-#endif /* DEBUG_COMMAND */
+   pr_debug("%s: completed with csb = 0x%X\n", __func__, csb);
 
return (csb & CSB_ERROR);
 }
@@ -470,9 +455,9 @@ static int xd_readwrite(u_char operation, struct xd_info 
*p, char *buffer,
char **real_buffer;
register int i;
 
-#ifdef DEBUG_READWRITE
-   printk("xd_readwrite: operation = %s, drive = %d, buffer = 0x%X, block 
= %d, count = %d\n",operation == READ ? "read" : 
"write",drive,buffer,block,count);
-#endif /* DEBUG_READWRITE */
+   pr_debug("%s: operation = %s, drive = %d, buffer = 0x%p, block = %d, 
count = %d\n",
+__func__, operation == READ ? "read" : "write",
+drive, buffer, block, count);
 
spin_unlock_irq(_lock);
 
@@ -487,9 +472,8 @@ static int xd_readwrite(u_char operation, struct xd_info 
*p, char *buffer,
cylinder = track / p->heads;
sector = block % p->sectors;
 
-#ifdef DEBUG_READWRITE
-   printk("xd_readwrite: drive = %d, head = %d, cylinder = %d, 
sector = %d, count = %d\n",drive,head,cylinder,sector,temp);
-#endif /* DEBUG_READWRITE */
+   pr_debug("%s: drive = %d, head = %d, cylinder = %d, sector = 
%d, count = %d\n",
+__func__, drive, head, cylinder, sector, temp);
 
if (xd_dma_buffer) {
mode = xd_setup_dma(operation == READ ? DMA_MODE_READ : 
DMA_MODE_WRITE,(u_char *)(xd_dma_buffer),temp * 0x200);
@@ -588,12 +572,14 @@ static void do_xd_request(struct request_queue * q)
int retry;
 
if (req->cmd_type != REQ_TYPE_FS) {
-   pr_err("unsupported request: %d\n", req->cmd_type);
+   pr_err("%s: unsupported request: %d\n",
+  __func__, req->cmd_type);
res = -EIO;
goto done;
}
if (block + count > get_capacity(req->rq_disk)) {
-   pr_err("request beyond device capacity\n");
+   pr_err("%s: request beyond device capacity\n",
+  __func__);
res = -EIO;
goto done;
}
@@ -671,9 +657,7 @@ static const struct block_device_operations xd_fops = {
 static irqreturn_t xd_interrupt_handler(int irq, void *dev_id)
 {
if (inb(XD_STATUS) & STAT_INTERRUPT) {  

[PATCH 3/9] block: xd: raise timeouts

[Linus Walleij]

The timeouts for the XD driver were set pretty low, probably
tested out on an error-free disk. When there are bad sectors
on the disk, the controller card will autonomously perform a
bump of the drive head, a quite slow mechanical operation
which takes way more than one second, or even the 8 seconds
allowed for the IRQ to arrive. Raise both timeouts to 30
seconds.

Signed-off-by: Linus Walleij 
---
 drivers/block/xd.c | 2 +-
 drivers/block/xd.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xd.c b/drivers/block/xd.c
index ce088f8..549a7fa 100644
--- a/drivers/block/xd.c
+++ b/drivers/block/xd.c
@@ -564,7 +564,7 @@ static inline u_char xd_waitport (u_short port,u_char 
flags,u_char mask,u_long t
 static inline u_int xd_wait_for_IRQ (void)
 {
unsigned long flags;
-   xd_watchdog_int.expires = jiffies + 8 * HZ;
+   xd_watchdog_int.expires = jiffies + 30 * HZ;
add_timer(_watchdog_int);

flags=claim_dma_lock();
diff --git a/drivers/block/xd.h b/drivers/block/xd.h
index 37cacef..489e1ce 100644
--- a/drivers/block/xd.h
+++ b/drivers/block/xd.h
@@ -67,7 +67,7 @@
 #define DMA_MODE   0x03/* control bits to set for DMA & interrupt */
 
 #define XD_MAXDRIVES   2   /* maximum 2 drives */
-#define XD_TIMEOUT HZ  /* 1 second timeout */
+#define XD_TIMEOUT (HZ * 30)   /* 30 second timeout */
 #define XD_RETRIES 4   /* maximum 4 retries */
 
 #undef DEBUG   /* define for debugging output */
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] block: introduce a delay before every outb operation

[Linus Walleij]

When I plug an ISA XT 8bit card into a 16bit compatible EISA
slot, the outb() operations seemingly stumble over each other
so we need to introduce a small delay after each outb()
operation. After this my MFM MiniScribe harddrive is properly
detected like this:

Detected 1 hard drive (using IRQ5 & DMA3)
 xda: CHS=615/4/17

Signed-off-by: Linus Walleij 
---
 drivers/block/xd.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xd.c b/drivers/block/xd.c
index ff54052..303e9f2 100644
--- a/drivers/block/xd.c
+++ b/drivers/block/xd.c
@@ -57,6 +57,8 @@
 
 #include "xd.h"
 
+#define OUTB_DELAY 100
+
 static DEFINE_MUTEX(xd_mutex);
 static void __init do_xd_setup (int *integers);
 #ifdef MODULE
@@ -485,7 +487,8 @@ static irqreturn_t xd_interrupt_handler(int irq, void 
*dev_id)
 #ifdef DEBUG_OTHER
printk("xd_interrupt_handler: interrupt detected\n");
 #endif /* DEBUG_OTHER */
-   outb(0,XD_CONTROL); 
/* acknowledge interrupt */
+   outb(0,XD_CONTROL); /* acknowledge interrupt */
+   udelay(OUTB_DELAY);
wake_up(_wait_int);  /* and wake up sleeping processes */
return IRQ_HANDLED;
}
@@ -588,7 +591,9 @@ static u_int xd_command (u_char *command,u_char mode,u_char 
*indata,u_char *outd
 #endif /* DEBUG_COMMAND */
 
outb(0,XD_SELECT);
+   udelay(OUTB_DELAY);
outb(mode,XD_CONTROL);
+   udelay(OUTB_DELAY);
 
if (xd_waitport(XD_STATUS,STAT_SELECT,STAT_SELECT,timeout))
return (1);
@@ -602,8 +607,10 @@ static u_int xd_command (u_char *command,u_char 
mode,u_char *indata,u_char *outd
if (mode == DMA_MODE) {
if (xd_wait_for_IRQ())
return (1);
-   } else
+   } else {
outb(outdata ? *outdata++ : 0,XD_DATA);
+   udelay(OUTB_DELAY);
+   }
break;
case STAT_INPUT:
if (mode == DMA_MODE) {
@@ -617,6 +624,7 @@ static u_int xd_command (u_char *command,u_char mode,u_char 
*indata,u_char *outd
break;
case STAT_COMMAND:
outb(command ? *command++ : 0,XD_DATA);
+   udelay(OUTB_DELAY);
break;
case STAT_COMMAND | STAT_INPUT:
complete = 1;
@@ -680,6 +688,7 @@ static void __init xd_dtc_init_controller (unsigned int 
address)
xd_maxsectors = 0x01;   /* my card seems to have trouble doing 
multi-block transfers? */
 
outb(0,XD_RESET);   /* reset the controller */
+   udelay(OUTB_DELAY);
 }
 
 
@@ -773,6 +782,7 @@ static void __init xd_wd_init_controller (unsigned int 
address)
xd_maxsectors = 0x01;   /* this one doesn't wrap properly 
either... */
 
outb(0,XD_RESET);   /* reset the controller */
+   udelay(OUTB_DELAY);
 
msleep(XD_INIT_DISK_DELAY);
 }
@@ -875,6 +885,7 @@ static void __init xd_seagate_init_controller (unsigned int 
address)
xd_maxsectors = 0x40;
 
outb(0,XD_RESET);   /* reset the controller */
+   udelay(OUTB_DELAY);
 }
 
 static void __init xd_seagate_init_drive (u_char drive)
@@ -908,6 +919,7 @@ static void __init xd_omti_init_controller (unsigned int 
address)
xd_maxsectors = 0x40;
 
outb(0,XD_RESET);   /* reset the controller */
+   udelay(OUTB_DELAY);
 }
 
 static void __init xd_omti_init_drive (u_char drive)
@@ -947,6 +959,7 @@ If you need non-standard settings use the xd=... command */
 
xd_maxsectors = 0x01;
outb(0,XD_RESET);   /* reset the controller */
+   udelay(OUTB_DELAY);
 
msleep(XD_INIT_DISK_DELAY);
 }
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] block: xd: fix up request handler loop

[Linus Walleij]

The result (res) variable was set to -EIO in this loop, however
since the iteratively retried request execution loop would
exit on !res this means that loop is never taken.

Instead, assign zero to the res variable, and explicitly set
it to -EIO on error.

Signed-off-by: Linus Walleij 
---
 drivers/block/xd.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xd.c b/drivers/block/xd.c
index 303e9f2..ce088f8 100644
--- a/drivers/block/xd.c
+++ b/drivers/block/xd.c
@@ -322,13 +322,19 @@ static void do_xd_request (struct request_queue * q)
unsigned block = blk_rq_pos(req);
unsigned count = blk_rq_cur_sectors(req);
XD_INFO *disk = req->rq_disk->private_data;
-   int res = -EIO;
+   int res = 0;
int retry;
 
-   if (req->cmd_type != REQ_TYPE_FS)
+   if (req->cmd_type != REQ_TYPE_FS) {
+   pr_err("unsupported request: %d\n", req->cmd_type);
+   res = -EIO;
goto done;
-   if (block + count > get_capacity(req->rq_disk))
+   }
+   if (block + count > get_capacity(req->rq_disk)) {
+   pr_err("request beyond device capacity\n");
+   res = -EIO;
goto done;
+   }
for (retry = 0; (retry < XD_RETRIES) && !res; retry++)
res = xd_readwrite(rq_data_dir(req), disk, req->buffer,
   block, count);
-- 
1.8.1.2

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

[Linus Walleij]

Yes, I use this driver. I have an old PC XT 8088, and the fact
that it was in the kernel tree SAVED MY DATA.

Of course I couldn't boot Linux on that old machine. But I
removed the disk and the controller card and put it into
a Pentium MMX. The ROM on the card has to be removed or it
will kill the boot by trying to patchextends the BIOS. Then
you have to configure out the IRQ and DMA manually in the
BIOS menu.

But then you pass the controller type to the driver with
xd=3 and it *WORKS*, well after the first two patches in
this series. I proceeded to do some rough cleanups to get
it more maintainable.

Linus Walleij (9):
  block: xd: introduce a delay before every outb operation
  block: xd: fix up request handler loop
  block: xd: raise timeouts
  block: xd: some whitespace and #if 0 removal
  block: xd: avoid using typedefs
  block: xd: avoid some forward declarations
  block: xd: merge header file into driver
  block: xd: remove custom DEBUG print system
  block: xd: replace all printks with pr_*

 drivers/block/xd.c | 1202 ++--
 drivers/block/xd.h |  134 --
 2 files changed, 686 insertions(+), 650 deletions(-)
 delete mode 100644 drivers/block/xd.h

-- 
1.8.1.2

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

Re: [PATCH 05/32] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT

[Arnd Bergmann]

On Tuesday 12 February 2013, Thomas Petazzoni wrote:
> > Any driver that requires a
> > linear mapping of I/O ports to __iomem pointers must depend
> > CONFIG_HAS_IOPORT with the current definition of that symbol (as
> > mentioned before, we should really rename that to
> > CONFIG_HAS_IOPORT_MAP). Having these functions not defined is a
> > compile time check that is necessary to ensure that all drivers have
> > the correct annotation.
> 
> I have the feeling that the problem is more complex than that. My
> understanding is that the pcim_iomap_regions() function used by
> drivers/ata/libata-sff.c can perfectly be used to map memory BARs, and
> not necessarily I/O BARs. Therefore, this driver can perfectly be used
> in an architecture where CONFIG_NO_IOPORT is selected.

That is correct.

> The thing is that pcim_iomap_regions() transparently allows to remap an
> I/O BAR is such a BAR is passed as argument, or a memory BAR if such a
> BAR is passed as argument.
> 
> Therefore, I continue to believe that the pcim_*() functions are useful
> even if the platform doesn't have CONFIG_HAS_IOPORT.

Yes, the pcim_ functions are useful in principle, but it falls back
to the __pci_ioport_map() for IORESOURCE_IO, and that needs to
return an error if CONFIG_HAS_IOPORT is not set.
I think it would be correct if you add this hunk:

diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index 0d83ea8..f9b6387 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -33,7 +33,7 @@ void __iomem *pci_iomap(struct pci_dev *dev, int bar, 
unsigned long maxlen)
return NULL;
if (maxlen && len > maxlen)
len = maxlen;
-   if (flags & IORESOURCE_IO)
+   if (IS_ENABLED(CONFIG_HAS_IOPORT) && (flags & IORESOURCE_IO))
return __pci_ioport_map(dev, start, len);
if (flags & IORESOURCE_MEM) {
if (flags & IORESOURCE_CACHEABLE)

in order to prevent a link error when CONFIG_HAS_IOPORT is unset.

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: [RFC][PATCH v2] tracing/syscalls: Allow archs to ignore tracing compat syscalls

[H. Peter Anvin]

On 02/12/2013 01:42 PM, Steven Rostedt wrote:
> On Tue, 2013-02-12 at 13:33 -0800, H. Peter Anvin wrote:
>> On 02/12/2013 01:18 PM, Steven Rostedt wrote:
>>> [
>>>   Peter, how about this patch. Instead of showing garbage, just never
>>>   trace compat syscalls, if the arch needs to ignore it.
>>>
>>>   However, users can still use the raw_syscall interface if they need to
>>>   trace them.
>>> ]
>>>
>>
>> I can go for that.  At least it doesn't make the current situation any
>> messier than it currently is, and it prevents incorrect information from
>> being output.
>>
> 
> Great, can I have your Acked-by. Then I'll start testing it and get it
> ready to push for 3.9.
> 

Acked-by: H. Peter Anvin 


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

[Stephen Rothwell]

Hi Len,

On Mon, 11 Feb 2013 18:34:06 -0500 Len Brown  wrote:
>
> BTW. Rafael's "pm" tree now carries the ACPI patch stream,
> so it is probably a mis-representation to call my tree the "acpi" tree.
> My tree is primarily focused on the "idle" part of pm these days.

OK, I have renamed your tree to "idle".

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


pgpUjdeiV68QR.pgp
Description: PGP signature

Re: [v2 3/3] ARM: tegra: Unify Device tree board files

[Arnd Bergmann]

On Tuesday 12 February 2013, Stephen Warren wrote:
> I believe U-Boot enabled -ffunction-sections -fdata-sections or similar
> (recently?) to get this kind of behaviour. I wonder why the kernel
> didn't need that. Perhaps -O2 is more aggressive (within a file at
> least) than I thought.

-ffunction-sections works across files, while the trick I described
only works on file static symbols. David Woodhouse at some point
had a working kernel build with -ffunction-sections but for some
reason that never got merged.

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/

[Fwd: Re: [PATCH] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers]

[Joe Perches]

Jerod?  Remove you from MAINTAINERS or not?

Your wilsonet address is bouncing.

https://lkml.org/lkml/2013/2/12/531

cheers, Joe

 Forwarded Message 
From: Hans de Goede 
To: Joe Perches 
Subject: Re: [PATCH] MAINTAINERS: Remove Jarod Wilson and orphan LIRC
drivers

Hi

On 02/12/2013 10:20 PM, Joe Perches wrote:
> His email bounces

jwil...@redhat.com should work I think.

Note I think this may be the right call,
but asking him directly is better :)

Regards,

Hans



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

Re: [PATCH 3/3] nbd: show read-only state in sysfs

[Paul Clements]

On Tue, Feb 12, 2013 at 11:06 AM, Paolo Bonzini  wrote:
> Pass the read-only flag to set_device_ro, so that it will be
> visible to the block layer and in sysfs.

Looks good


> Cc: 
> Cc: Paul Clements 
> Cc: Andrew Morton 
> Signed-off-by: Paolo Bonzini 
> ---
>  drivers/block/nbd.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index a9c5c7a..ef17c2e 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -703,6 +703,8 @@ static int __nbd_ioctl(struct block_device *bdev, struct 
> nbd_device *nbd,
>
> mutex_unlock(>tx_lock);
>
> +   if (nbd->flags & NBD_FLAG_READ_ONLY)
> +   set_device_ro(bdev, true);
> if (nbd->flags & NBD_FLAG_SEND_TRIM)
> queue_flag_set_unlocked(QUEUE_FLAG_DISCARD,
> nbd->disk->queue);
> @@ -730,6 +732,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct 
> nbd_device *nbd,
> dev_warn(disk_to_dev(nbd->disk), "queue cleared\n");
> kill_bdev(bdev);
> queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, 
> nbd->disk->queue);
> +   set_device_ro(bdev, false);
> if (file)
> fput(file);
> nbd->flags = 0;
> --
> 1.7.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] nbd: fsync and kill block device on shutdown

[Paul Clements]

On Tue, Feb 12, 2013 at 11:06 AM, Paolo Bonzini  wrote:
> There are two problems with shutdown in the NBD driver.  The first is
> that receiving the NBD_DISCONNECT ioctl does not sync the filesystem;
> this is useful because BLKFLSBUF is restricted to processes that have
> CAP_SYS_ADMIN, and the NBD client may not possess it (fsync of the
> block device does not sync the filesystem, either).

> The second is that once we clear the socket we have no guarantee that
> later reads will come from the same backing storage.  Thus the page cache
> must be cleaned, lest reads that hit on the page cache will return stale
> data from the previously-accessible disk.

Paolo,

Thanks for this. A problem indeed...

Acked-by: paul.cleme...@steeleye.com


> Cc: 
> Cc: 
> Cc: Paul Clements 
> Cc: Andrew Morton 
> Signed-off-by: Paolo Bonzini 
> ---
>  drivers/block/nbd.c |   10 ++
>  1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index 5603765..a9c5c7a 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -608,12 +608,20 @@ static int __nbd_ioctl(struct block_device *bdev, 
> struct nbd_device *nbd,
> struct request sreq;
>
> dev_info(disk_to_dev(nbd->disk), "NBD_DISCONNECT\n");
> +   if (!nbd->sock)
> +   return -EINVAL;
>
> +   mutex_unlock(>tx_lock);
> +   fsync_bdev(bdev);
> +   mutex_lock(>tx_lock);
> blk_rq_init(NULL, );
> sreq.cmd_type = REQ_TYPE_SPECIAL;
> nbd_cmd() = NBD_CMD_DISC;
> +
> +   /* Check again after getting mutex back.  */
> if (!nbd->sock)
> return -EINVAL;
> +
> nbd_send_req(nbd, );
>  return 0;
> }
> @@ -627,6 +635,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct 
> nbd_device *nbd,
> nbd_clear_que(nbd);
> BUG_ON(!list_empty(>queue_head));
> BUG_ON(!list_empty(>waiting_queue));
> +   kill_bdev(bdev);
> if (file)
> fput(file);
> return 0;
> @@ -719,6 +728,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct 
> nbd_device *nbd,
> nbd->file = NULL;
> nbd_clear_que(nbd);
> dev_warn(disk_to_dev(nbd->disk), "queue cleared\n");
> +   kill_bdev(bdev);
> queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, 
> nbd->disk->queue);
> if (file)
> fput(file);
> --
> 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: compositing broken in -next (idr bug)

[Tejun Heo]

Hello, Jiri.

On Tue, Feb 12, 2013 at 11:08:41PM +0100, Jiri Slaby wrote:
> > Oh my, maybe: return ret < 0 ? ret : 0... Let's try.
> 
> Bull's eye.

Aieee

> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -459,6 +459,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
> 
> if (ret < 0)
> goto err;
> +   ret = 0;
> 
> /* Allocate a reference for the name table.  */
> drm_gem_object_reference(obj);

Care to write up a proper patch w/ SOB?

Thanks!

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

Re: [PATCH 3/3 RESEND] mmc: sdhci: check voltage range only on regulators aware of voltage value

[Guennadi Liakhovetski]

Hi Marek

On Tue, 12 Feb 2013, Marek Szyprowski wrote:

> Some regulators don't report any voltage values, so checking supported
> voltage range results in disabling all SDHCI_CAN_VDD_* flags and
> registration failure. This patch finally provides a correct fix for the
> registration of SDHCI driver with all possible voltage regulators:
> dummy, fixed and regulated without using regulator_count_voltages()
> hacks.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/mmc/host/sdhci.c |6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index ba586ae..735526b 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2976,7 +2976,11 @@ int sdhci_add_host(struct sdhci_host *host)
>   }
>  
>  #ifdef CONFIG_REGULATOR
> - if (host->vmmc) {
> + /*
> +  * Voltage range check makes sense only if regulator reports
> +  * any voltage value.
> +  */
> + if (host->vmmc && regulator_get_voltage(host->vmmc) > 0) {
>   ret = regulator_is_supported_voltage(host->vmmc, 270,
>   360);

Wouldn't using mmc_regulator_get_ocrmask() be a better option?

Thanks
Guennadi

>   if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_330)))
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] nbd: support FLUSH requests

[Paul Clements]

On Tue, Feb 12, 2013 at 11:06 AM, Paolo Bonzini  wrote:
> From: Alex Bligh 
>
> The NBD device does not support writeback caching, thus it is not safe
> against power losses unless the client opens the target with O_DSYNC or
> O_SYNC.
>
> Add support for a new flag that the server can pass.  If the flag is
> enabled, we translate REQ_FLUSH requests into the NBD_CMD_FLUSH
> command.
>
> Cc: 
> Cc: Paul Clements 
> Cc: Andrew Morton 
> Signed-off-by: Alex Bligh 

Looks good.

Acked-by: paul.cleme...@steeleye.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: compositing broken in -next (idr bug)

[Jiri Slaby]

On 02/12/2013 11:03 PM, Jiri Slaby wrote:
> On 02/12/2013 10:55 PM, Jiri Slaby wrote:
>> --- a/drivers/gpu/drm/drm_gem.c
>> +++ b/drivers/gpu/drm/drm_gem.c
>> @@ -453,7 +453,8 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
>> spin_lock(>object_name_lock);
>> if (!obj->name) {
>> ret = idr_alloc(>object_name_idr, obj, 1, 0,
>> GFP_NOWAIT);
>> -   obj->name = ret;
>> +   if (ret >= 0)
>> +   obj->name = ret;
>> args->name = (uint64_t) obj->name;
>> spin_unlock(>object_name_lock);
>>
>> @@ -469,6 +470,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
>> }
>>
>>  err:
>> +   idr_preload_end();
>> drm_gem_object_unreference_unlocked(obj);
>> return ret;
> 
> Oh my, maybe: return ret < 0 ? ret : 0... Let's try.

Bull's eye.

--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -459,6 +459,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,

if (ret < 0)
goto err;
+   ret = 0;

/* Allocate a reference for the name table.  */
drm_gem_object_reference(obj);

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

Re: [PATCH] net: ethernet: ti: remove redundant NULL check.

[David Miller]

From: Cyril Roelandt 
Date: Tue, 12 Feb 2013 22:54:46 +0100

> cpdma_chan_destroy() on a NULL pointer is a no-op, so the NULL check in
> cpdma_ctlr_destroy() can safely be removed.
> 
> Signed-off-by: Cyril Roelandt 
 ...
> @@ -450,8 +450,7 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
>   cpdma_ctlr_stop(ctlr);
>  
>   for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++) {
> - if (ctlr->channels[i])
> - cpdma_chan_destroy(ctlr->channels[i]);
> + cpdma_chan_destroy(ctlr->channels[i]);
>   }

SInce this is now a single statement basic block, remove the
surrounding braces.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/