[PATCH] nouveau: Do not use nva3 engine for 0xaf chipset

[Henrik Rydberg]

The nva3 copy engine exhibits random memory corruption in at least one
case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1.  This patch
omits creating the engine for the specific chipset, falling back to
M2MF, which kills the symptoms.

Signed-off-by: Henrik Rydberg 
---
Hi Ben,

this patch is still needed in 3.6-rc1, so perhaps we should apply it
after all. I have been running it without problems for a long time
now.

Thanks,
Henrik

 drivers/gpu/drm/nouveau/nouveau_state.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
b/drivers/gpu/drm/nouveau/nouveau_state.c
index 1cdfd6e..1866dbb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev)
case 0xa3:
case 0xa5:
case 0xa8:
-   case 0xaf:
nva3_copy_create(dev);
break;
}
-- 
1.7.11.4

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

Re: [PATCH V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR

[Francois Rigaut]

Seth,

[CC'd people, sorry we exchanged a few emails with Seth outside of the 
lists, I passed him the acpi tables and here are gmux dumps]


Allright. thanks for gmux-dump. There seems to be progress, as I can see 
the gmux dumps for the nividia-selected and intel-selected are clearly 
different (I did it twice to be sure, it checks out).

The 2 dumps are at
http://maumae.net/retina/gmux-dump_intel.dat
and
http://maumae.net/retina/gmux-dump_nvidia_only.dat
I hope you'll be able to get something from these.
Francois



On 04/08/12 13:58, Seth Forshee wrote:

On Sat, Aug 04, 2012 at 11:34:21AM +1000, Francois Rigaut wrote:

Seth,

I've put the acpi table dump in http://maumae.net/retina/acpi_tables.tgz

The ACPI stuff for the gmux looks exactly the same as for the machine
I've got. The I/O range is still 0x700 to 0x7ff.


As far as the mem dump, I've done it but can not see any difference
(between case where one or the other graphic card are selected) in
the first 3000 bytes. Not sure I'm doing that well though. I'm just
dd'ing /dev/mem with
dd bs=1000 count=3 if=/dev/mem of=some_file
Am I addressing the right memory or is the switch going to be (or
likely to be) somewhere else?

That's going to access sytem memory, not the I/O space for the gmux. Try
the attached instead. It's going to output the raw binary, so if you
want to view the output do something like

  gmux-dump | xxd -g1

Seth


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

[Artem Bityutskiy]

On Fri, 2012-08-03 at 13:23 -0700, Linus Torvalds wrote:
> On Thu, Aug 2, 2012 at 11:47 PM, Artem Bityutskiy  wrote:
> >
> > We have had 11 of 13 pieces of the 'sync_supers()' removal patch-sets
> > merged. The 12th piece removes dead code in exofs was supposed to go
> > through the exofs tree and blocked the 13th piece which removes
> > 'sync_supers()' and was supposed to go via the VFS tree.
> >
> > Both 12th and 13th pieces zap dead code. I man not sure delaying that to
> > v3.7 would be very beneficial for the kernel (why having a useless
> > thread waking up every 5 secs?). Would you let us merge this to -rc1?
> 
> Ok. I'm pulling the exofs changes, they're small and remove more lines
> than they add. And if the last piece then just kills dead code, I
> won't mind that either.

Thanks Linus. Yes, the first patch of the series removes dead code, and
there are additional patches which amend comments and documentation
without touching any functionality, just remove words pdflush, s_dirt,
and write_super.

-- 
Best Regards,
Artem Bityutskiy


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

Re: Gaming and the kernel

[Mike Galbraith]

On Sat, 2012-08-04 at 06:49 +0200, Mike Galbraith wrote: 
> On Sat, 2012-08-04 at 00:12 -0400, valdis.kletni...@vt.edu wrote: 
> > On Sat, 04 Aug 2012 10:51:49 +1000, Chris Jones said:
> > 
> > > documentation, hopefully things will work out. And this might actually
> > > be the kick in the rear-end that AMD and NVIDIA need to get into gear
> > > and start developer some useful and Windows equivalent hardware drivers
> > > for ALL their cards for Linux.
> > 
> > The truly ironic part is that the current NVidia binary blob driver that
> > everybody dislikes so much *IS* the "Windows equivalent" driver (in
> > fact, it's the same driver, with a Linux shim layer wrapped around it).
> 
> Hm.. so windows can be kept in kernel for a full second of IPI blasting
> all cores too.  That driver seems to work very nicely once things are
> running, but whatever the heck it does when you first fire up rendering
> is.. something to keep far far away from realtime tasks :)

That seems to have gotten about a ton better.  Worst just measured with
295.53 under 3.0-rt58 was 7.7ms, with typical being < 1ms.

-Mike

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

Re: Linux 3.6-rc1

[Artem Bityutskiy]

On Sat, 2012-08-04 at 05:46 +0100, Al Viro wrote:
> OK...  I've ported Artem's patchset on top of exofs merge; Artem, could
> you check if you are OK with the result currently in vfs.git#for-linus?

Thanks Al, yes, it looks all right.

-- 
Best Regards,
Artem Bityutskiy


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

Re: [PATCH 01/22] ARM: add mechanism for late code patching

[Nicolas Pitre]

On Tue, 31 Jul 2012, Cyril Chemparathy wrote:

> The original phys_to_virt/virt_to_phys patching implementation relied on early
> patching prior to MMU initialization.  On PAE systems running out of >4G
> address space, this would have entailed an additional round of patching after
> switching over to the high address space.
> 
> The approach implemented here conceptually extends the original PHYS_OFFSET
> patching implementation with the introduction of "early" patch stubs.  Early
> patch code is required to be functional out of the box, even before the patch
> is applied.  This is implemented by inserting functional (but inefficient)
> load code into the .patch.code init section.  Having functional code out of
> the box then allows us to defer the init time patch application until later
> in the init sequence.
> 
> In addition to fitting better with our need for physical address-space
> switch-over, this implementation should be somewhat more extensible by virtue
> of its more readable (and hackable) C implementation.  This should prove
> useful for other similar init time specialization needs, especially in light
> of our multi-platform kernel initiative.
> 
> This code has been boot tested in both ARM and Thumb-2 modes on an ARMv7
> (Cortex-A8) device.
> 
> Note: the obtuse use of stringified symbols in patch_stub() and
> early_patch_stub() is intentional.  Theoretically this should have been
> accomplished with formal operands passed into the asm block, but this requires
> the use of the 'c' modifier for instantiating the long (e.g. .long %c0).
> However, the 'c' modifier has been found to ICE certain versions of GCC, and
> therefore we resort to stringified symbols here.
> 
> Signed-off-by: Cyril Chemparathy 

This looks very nice.  Comments below.

> ---
>  arch/arm/include/asm/patch.h  |  123 +

Please find a better name for this file. "patch" is way too generic and 
commonly referring to something different. "runtime-patching" or similar 
would be more descriptive.

>  arch/arm/kernel/module.c  |4 +
>  arch/arm/kernel/setup.c   |  175 
> +

This is complex enough to waarrant aa separate source file.  Please move 
those additions out from setup.c.  Given a good name for the header file 
above, the c file could share the same name.

> new file mode 100644
> index 000..a89749f
> --- /dev/null
> +++ b/arch/arm/include/asm/patch.h
> @@ -0,0 +1,123 @@
> +/*
> + *  arch/arm/include/asm/patch.h
> + *
> + *  Copyright (C) 2012, Texas Instruments
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + *  Note: this file should not be included by non-asm/.h files
> + */
> +#ifndef __ASM_ARM_PATCH_H
> +#define __ASM_ARM_PATCH_H
> +
> +#include 
> +
> +#ifndef __ASSEMBLY__
> +
> extern unsigned __patch_table_begin, __patch_table_end;

You could use "exttern void __patch_table_begin" so those symbols don't 
get any type that could be misused by mistake, while you still can take 
their addresses.

> +
> +struct patch_info {
> + u32  type;
> + u32  size;

Given the possibly large number of table entries, some effort at making 
those entries as compact as possible should be considered. For instance, 
the type and size fields could be u8's and insn_end pointer replaced 
with another size expressed as an u8.  By placing all the u8's together 
they would occupy a single word by themselves.  The assembly stub would 
only need a .align statement to reflect the c structure's padding.

[...]

Did you verify with some test program that your patching routines do 
produce the same opcodes as the assembled equivalent for all possible 
shift values?  Especially for Thumb2 code which isn't as trivial to get 
right as the ARM one.


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

Re: [PATCH v2] printk: add option to print cpu id

[Borislav Petkov]

On Fri, Aug 03, 2012 at 09:46:15AM -0700, Pandita, Vikram wrote:
> I mostly work with ARM Soc - specifically on OMAP. SMP multi core
> systems in ARM-v7 world started to show up only few years back -
> unlike x86 world.

This is exactly the thing: other SMP vendors have made it so far without
emitting which core is doing what in dmesg.

> ARM systems are a bit unique when it comes to security( read trust
> zone ), and handling of FIQ's. Most of the ARM cortex-A series SoC's
> out there have some kind of affinity to CPU0 being the master. One use
> case has been, it has helped to know with this printk logging, if such
> constraints are honored.
>
> Sometimes, tracking of some lockup cases between cpu's because of bad
> code has also been helpful with this logging support. For now i will
> post v3 of the patch and add arm-list and linux-omap list, and there
> might be users there can benefit.

Right, so if arm people need this thing, why not make it arm-only? I
still fail to see the need for this (... at all, actually).

Thanks.

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

[Mike Galbraith]

On Sat, 2012-08-04 at 00:12 -0400, valdis.kletni...@vt.edu wrote: 
> On Sat, 04 Aug 2012 10:51:49 +1000, Chris Jones said:
> 
> > documentation, hopefully things will work out. And this might actually
> > be the kick in the rear-end that AMD and NVIDIA need to get into gear
> > and start developer some useful and Windows equivalent hardware drivers
> > for ALL their cards for Linux.
> 
> The truly ironic part is that the current NVidia binary blob driver that
> everybody dislikes so much *IS* the "Windows equivalent" driver (in
> fact, it's the same driver, with a Linux shim layer wrapped around it).

Hm.. so windows can be kept in kernel for a full second of IPI blasting
all cores too.  That driver seems to work very nicely once things are
running, but whatever the heck it does when you first fire up rendering
is.. something to keep far far away from realtime tasks :)

-Mike

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

Re: Linux 3.6-rc1

[Al Viro]

On Fri, Aug 03, 2012 at 01:23:29PM -0700, Linus Torvalds wrote:
> On Thu, Aug 2, 2012 at 11:47 PM, Artem Bityutskiy  wrote:
> >
> > We have had 11 of 13 pieces of the 'sync_supers()' removal patch-sets
> > merged. The 12th piece removes dead code in exofs was supposed to go
> > through the exofs tree and blocked the 13th piece which removes
> > 'sync_supers()' and was supposed to go via the VFS tree.
> >
> > Both 12th and 13th pieces zap dead code. I man not sure delaying that to
> > v3.7 would be very beneficial for the kernel (why having a useless
> > thread waking up every 5 secs?). Would you let us merge this to -rc1?
> 
> Ok. I'm pulling the exofs changes, they're small and remove more lines
> than they add. And if the last piece then just kills dead code, I
> won't mind that either.

OK...  I've ported Artem's patchset on top of exofs merge; Artem, could
you check if you are OK with the result currently in vfs.git#for-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: Gaming and the kernel

[valdis . kletnieks]

On Sat, 04 Aug 2012 10:51:49 +1000, Chris Jones said:

> documentation, hopefully things will work out. And this might actually
> be the kick in the rear-end that AMD and NVIDIA need to get into gear
> and start developer some useful and Windows equivalent hardware drivers
> for ALL their cards for Linux.

The truly ironic part is that the current NVidia binary blob driver that
everybody dislikes so much *IS* the "Windows equivalent" driver (in
fact, it's the same driver, with a Linux shim layer wrapped around it).

You can flame them for having a non-GPL binary blob, but you can't flame
NVidia for not having equivalent drivers...


pgpalpgUrHJMp.pgp
Description: PGP signature

[RFC PATCH v1 03/15] firmware loader: remove unnecessary wmb()

[Ming Lei]

The wmb() inside fw_load_abort is not necessary, since
complete() and wait_on_completion() has implied one pair
of memory barrier.

Also wmb() isn't a correct usage, so just remove it.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 1915ad8..0bd09c7 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -112,7 +112,6 @@ static struct firmware_priv *to_firmware_priv(struct device 
*dev)
 static void fw_load_abort(struct firmware_priv *fw_priv)
 {
set_bit(FW_STATUS_ABORT, _priv->status);
-   wmb();
complete(_priv->completion);
 }
 
-- 
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/

[RFC PATCH v1 15/15] wireless: ath9k-htc: only load firmware in need

[Ming Lei]

It is not necessary to hold the firmware memory during the whole
driver lifetime, and obviously it does waste memory. Suppose there
are 4 ath9k-htc usb dongles working, kernel has to consume about
4*50KBytes RAM to cache firmware for all dongles. After applying the
patch, kernel only caches one single firmware image in RAM for
all ath9k-htc devices just during system suspend/resume cycle.

When system is ready for loading firmware, ath9k-htc can request
the loading from usersapce. During system resume, ath9k-htc still
can load the firmware which was cached in kernel memory before
system suspend.

Cc: linux-wirel...@vger.kernel.org
Cc: "Luis R. Rodriguez" 
Cc: Jouni Malinen 
Cc: Vasanthakumar Thiagarajan 
Cc: Senthil Balasubramanian 
Cc: "John W. Linville" 
Signed-off-by: Ming Lei 
---
 drivers/net/wireless/ath/ath9k/hif_usb.c |   34 --
 drivers/net/wireless/ath/ath9k/hif_usb.h |4 +++-
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index aa327ad..d35a19c 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -973,8 +973,8 @@ static void ath9k_hif_usb_dealloc_urbs(struct 
hif_device_usb *hif_dev)
 static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
 {
int transfer, err;
-   const void *data = hif_dev->firmware->data;
-   size_t len = hif_dev->firmware->size;
+   const void *data = hif_dev->fw_data;
+   size_t len = hif_dev->fw_size;
u32 addr = AR9271_FIRMWARE;
u8 *buf = kzalloc(4096, GFP_KERNEL);
u32 firm_offset;
@@ -1017,7 +1017,7 @@ static int ath9k_hif_usb_download_fw(struct 
hif_device_usb *hif_dev)
return -EIO;
 
dev_info(_dev->udev->dev, "ath9k_htc: Transferred FW: %s, size: 
%ld\n",
-hif_dev->fw_name, (unsigned long) hif_dev->firmware->size);
+hif_dev->fw_name, (unsigned long) hif_dev->fw_size);
 
return 0;
 }
@@ -1099,11 +1099,11 @@ static void ath9k_hif_usb_firmware_cb(const struct 
firmware *fw, void *context)
 
hif_dev->htc_handle = ath9k_htc_hw_alloc(hif_dev, _usb,
 _dev->udev->dev);
-   if (hif_dev->htc_handle == NULL) {
-   goto err_fw;
-   }
+   if (hif_dev->htc_handle == NULL)
+   goto err_dev_alloc;
 
-   hif_dev->firmware = fw;
+   hif_dev->fw_data = fw->data;
+   hif_dev->fw_size = fw->size;
 
/* Proceed with initialization */
 
@@ -,6 +,8 @@ static void ath9k_hif_usb_firmware_cb(const struct 
firmware *fw, void *context)
if (ret)
goto err_dev_init;
 
+   release_firmware(fw);
+
ret = ath9k_htc_hw_init(hif_dev->htc_handle,
_dev->interface->dev,
hif_dev->usb_device_id->idProduct,
@@ -1121,6 +1123,7 @@ static void ath9k_hif_usb_firmware_cb(const struct 
firmware *fw, void *context)
goto err_htc_hw_init;
}
 
+   hif_dev->flags |= HIF_USB_READY;
complete(_dev->fw_done);
 
return;
@@ -1129,8 +1132,8 @@ err_htc_hw_init:
ath9k_hif_usb_dev_deinit(hif_dev);
 err_dev_init:
ath9k_htc_hw_free(hif_dev->htc_handle);
+err_dev_alloc:
release_firmware(fw);
-   hif_dev->firmware = NULL;
 err_fw:
ath9k_hif_usb_firmware_fail(hif_dev);
 }
@@ -1277,11 +1280,10 @@ static void ath9k_hif_usb_disconnect(struct 
usb_interface *interface)
 
wait_for_completion(_dev->fw_done);
 
-   if (hif_dev->firmware) {
+   if (hif_dev->flags & HIF_USB_READY) {
ath9k_htc_hw_deinit(hif_dev->htc_handle, unplugged);
ath9k_htc_hw_free(hif_dev->htc_handle);
ath9k_hif_usb_dev_deinit(hif_dev);
-   release_firmware(hif_dev->firmware);
}
 
usb_set_intfdata(interface, NULL);
@@ -1317,13 +1319,23 @@ static int ath9k_hif_usb_resume(struct usb_interface 
*interface)
struct hif_device_usb *hif_dev = usb_get_intfdata(interface);
struct htc_target *htc_handle = hif_dev->htc_handle;
int ret;
+   const struct firmware *fw;
 
ret = ath9k_hif_usb_alloc_urbs(hif_dev);
if (ret)
return ret;
 
-   if (hif_dev->firmware) {
+   if (hif_dev->flags & HIF_USB_READY) {
+   /* request cached firmware during suspend/resume cycle */
+   ret = request_firmware(, hif_dev->fw_name,
+  _dev->udev->dev);
+   if (ret)
+   goto fail_resume;
+
+   hif_dev->fw_data = fw->data;
+   hif_dev->fw_size = fw->size;
ret = ath9k_hif_usb_download_fw(hif_dev);
+   release_firmware(fw);
if (ret)
goto fail_resume;
} else {
diff --git 

[RFC PATCH v1 14/15] firmware loader: cache devices firmware during suspend/resume cycle

[Ming Lei]

This patch implements caching devices' firmware automatically
during system syspend/resume cycle, so any device drivers can
call request_firmware or request_firmware_nowait inside resume
path to get the cached firmware if they have loaded firmwares
successfully at least once before entering suspend.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |   32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8ca0052..5bd2100 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "base.h"
 #include "power/power.h"
@@ -108,6 +109,8 @@ struct firmware_cache {
wait_queue_head_t wait_queue;
int cnt;
struct delayed_work work;
+
+   struct notifier_block   pm_notify;
 };
 
 struct firmware_buf {
@@ -1217,6 +1220,31 @@ static void device_uncache_fw_images_delay(unsigned long 
delay)
msecs_to_jiffies(delay));
 }
 
+#ifdef CONFIG_PM
+static int fw_pm_notify(struct notifier_block *notify_block,
+   unsigned long mode, void *unused)
+{
+   switch (mode) {
+   case PM_HIBERNATION_PREPARE:
+   case PM_SUSPEND_PREPARE:
+   device_cache_fw_images();
+   break;
+
+   case PM_POST_SUSPEND:
+   case PM_POST_HIBERNATION:
+   case PM_POST_RESTORE:
+   device_uncache_fw_images_delay(10 * MSEC_PER_SEC);
+   break;
+   }
+
+   return 0;
+}
+#else
+static int fw_pm_notify(struct notifier_block *notify_block,
+   unsigned long mode, void *unused)
+{}
+#endif
+
 static void __init fw_cache_init(void)
 {
spin_lock_init(_cache.lock);
@@ -1229,6 +1257,9 @@ static void __init fw_cache_init(void)
init_waitqueue_head(_cache.wait_queue);
INIT_DELAYED_WORK(_cache.work,
  device_uncache_fw_images_work);
+
+   fw_cache.pm_notify.notifier_call = fw_pm_notify;
+   register_pm_notifier(_cache.pm_notify);
 }
 
 static int __init firmware_class_init(void)
@@ -1239,6 +1270,7 @@ static int __init firmware_class_init(void)
 
 static void __exit firmware_class_exit(void)
 {
+   unregister_pm_notifier(_cache.pm_notify);
class_unregister(_class);
 }
 
-- 
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/

[RFC PATCH v1 13/15] firmware loader: use small timeout for cache device firmware

[Ming Lei]

Because device_cache_fw_images only cache the firmware which has been
loaded sucessfully at leat once, using a small loading timeout should
be reasonable.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 68fd4c6..8ca0052 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1146,10 +1146,22 @@ static void device_cache_fw_images(void)
 {
struct firmware_cache *fwc = _cache;
struct device *dev;
+   int old_timeout;
DEFINE_WAIT(wait);
 
pr_debug("%s\n", __func__);
 
+   /*
+* use small loading timeout for caching devices' firmware
+* because all these firmware images have been loaded
+* successfully at lease once, also system is ready for
+* completing firmware loading now. The maximum size of
+* firmware in current distributions is about 2M bytes,
+* so 10 secs should be enough.
+*/
+   old_timeout = loading_timeout;
+   loading_timeout = 10;
+
device_pm_lock();
list_for_each_entry(dev, _list, power.entry)
dev_cache_fw_image(dev);
@@ -1171,6 +1183,8 @@ static void device_cache_fw_images(void)
}
spin_unlock(>name_lock);
finish_wait(>wait_queue, );
+
+   loading_timeout = old_timeout;
 }
 
 /**
-- 
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/

[RFC PATCH v1 12/15] firmware: introduce device_cache/uncache_fw_images

[Ming Lei]

This patch introduces the three helpers below:

void device_cache_fw_images(void)
void device_uncache_fw_images(void)
void device_uncache_fw_images_delay(unsigned long)

so we can use device_cache_fw_images() to cache firmware for
all devices which need firmware to work, and the device driver
can get the firmware easily from kernel memory when system isn't
ready for completing requests of loading firmware.

After system is ready for completing firmware loading, driver core
will call device_uncache_fw_images() or its delay version to free
the cached firmware.

The above helpers will be used to cache device firmware during
system suspend/resume cycle in the following patches.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |  221 +++--
 1 file changed, 215 insertions(+), 6 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 65c6066..68fd4c6 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -22,6 +22,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#include "base.h"
+#include "power/power.h"
 
 MODULE_AUTHOR("Manuel Estrada Sainz");
 MODULE_DESCRIPTION("Multi purpose firmware loading support");
@@ -90,6 +95,19 @@ struct firmware_cache {
/* firmware_buf instance will be added into the below list */
spinlock_t lock;
struct list_head head;
+
+   /*
+* Names of firmware images which have been cached successfully
+* will be added into the below list so that device uncache
+* helper can trace which firmware images have been cached
+* before.
+*/
+   spinlock_t name_lock;
+   struct list_head fw_names;
+
+   wait_queue_head_t wait_queue;
+   int cnt;
+   struct delayed_work work;
 };
 
 struct firmware_buf {
@@ -106,6 +124,11 @@ struct firmware_buf {
char fw_id[];
 };
 
+struct fw_cache_entry {
+   struct list_head list;
+   char name[];
+};
+
 struct firmware_priv {
struct timer_list timeout;
bool nowait;
@@ -220,12 +243,6 @@ static void fw_free_buf(struct firmware_buf *buf)
kref_put(>ref, __fw_free_buf);
 }
 
-static void __init fw_cache_init(void)
-{
-   spin_lock_init(_cache.lock);
-   INIT_LIST_HEAD(_cache.head);
-}
-
 static struct firmware_priv *to_firmware_priv(struct device *dev)
 {
return container_of(dev, struct firmware_priv, dev);
@@ -1008,6 +1025,198 @@ int uncache_firmware(const char *fw_name)
return -EINVAL;
 }
 
+static struct fw_cache_entry *alloc_fw_cache_entry(const char *name)
+{
+   struct fw_cache_entry *fce;
+
+   fce = kzalloc(sizeof(*fce) + strlen(name) + 1, GFP_ATOMIC);
+   if (!fce)
+   goto exit;
+
+   strcpy(fce->name, name);
+exit:
+   return fce;
+}
+
+static void free_fw_cache_entry(struct fw_cache_entry *fce)
+{
+   kfree(fce);
+}
+
+static void __async_dev_cache_fw_image(void *fw_entry,
+  async_cookie_t cookie)
+{
+   struct fw_cache_entry *fce = fw_entry;
+   struct firmware_cache *fwc = _cache;
+   int ret;
+
+   ret = cache_firmware(fce->name);
+   if (ret)
+   goto free;
+
+   spin_lock(>name_lock);
+   list_add(>list, >fw_names);
+   spin_unlock(>name_lock);
+   goto drop_ref;
+
+free:
+   free_fw_cache_entry(fce);
+drop_ref:
+   spin_lock(>name_lock);
+   fwc->cnt--;
+   spin_unlock(>name_lock);
+
+   wake_up(>wait_queue);
+}
+
+/* called with dev->devres_lock held */
+static void dev_create_fw_entry(struct device *dev, void *res,
+   void *data)
+{
+   struct fw_name_devm *fwn = res;
+   const char *fw_name = fwn->name;
+   struct list_head *head = data;
+   struct fw_cache_entry *fce;
+
+   fce = alloc_fw_cache_entry(fw_name);
+   if (fce)
+   list_add(>list, head);
+}
+
+static int devm_name_match(struct device *dev, void *res,
+  void *match_data)
+{
+   struct fw_name_devm *fwn = res;
+   return (fwn->magic == (unsigned long)match_data);
+}
+
+static void dev_cache_fw_image(struct device *dev)
+{
+   LIST_HEAD(todo);
+   struct fw_cache_entry *fce;
+   struct fw_cache_entry *fce_next;
+   struct firmware_cache *fwc = _cache;
+
+   devres_for_each_res(dev, fw_name_devm_release,
+   devm_name_match, _cache,
+   dev_create_fw_entry, );
+
+   list_for_each_entry_safe(fce, fce_next, , list) {
+   list_del(>list);
+
+   spin_lock(>name_lock);
+   fwc->cnt++;
+   spin_unlock(>name_lock);
+
+   async_schedule(__async_dev_cache_fw_image, (void *)fce);
+   }
+}
+
+static void __device_uncache_fw_images(void)
+{
+   struct firmware_cache *fwc = _cache;
+   struct fw_cache_entry *fce;
+
+   

[RFC PATCH v1 11/15] driver core: devres: introduce devres_for_each_res

[Ming Lei]

This patch introduces one devres API of devres_for_each_res
so that the device's driver can iterate each resource it has
interest in.

The firmware loader will use the API to get each firmware name
from the device instance.

Signed-off-by: Ming Lei 
---
 drivers/base/devres.c  |   42 ++
 include/linux/device.h |4 
 2 files changed, 46 insertions(+)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 2360adb..8731979 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -144,6 +144,48 @@ EXPORT_SYMBOL_GPL(devres_alloc);
 #endif
 
 /**
+ * devres_for_each_res - Resource iterator
+ * @dev: Device to iterate resource from
+ * @release: Look for resources associated with this release function
+ * @match: Match function (optional)
+ * @match_data: Data for the match function
+ * @fn: Function to be called for each matched resource.
+ * @data: Data for @fn, the 3rd parameter of @fn
+ *
+ * Call @fn for each devres of @dev which is associated with @release
+ * and for which @match returns 1.
+ *
+ * RETURNS:
+ * void
+ */
+void devres_for_each_res(struct device *dev, dr_release_t release,
+   dr_match_t match, void *match_data,
+   void (*fn)(struct device *, void *, void *),
+   void *data)
+{
+   struct devres_node *node;
+   struct devres_node *tmp;
+   unsigned long flags;
+
+   if (!fn)
+   return;
+
+   spin_lock_irqsave(>devres_lock, flags);
+   list_for_each_entry_safe_reverse(node, tmp,
+   >devres_head, entry) {
+   struct devres *dr = container_of(node, struct devres, node);
+
+   if (node->release != release)
+   continue;
+   if (match && !match(dev, dr->data, match_data))
+   continue;
+   fn(dev, dr->data, data);
+   }
+   spin_unlock_irqrestore(>devres_lock, flags);
+}
+EXPORT_SYMBOL_GPL(devres_for_each_res);
+
+/**
  * devres_free - Free device resource data
  * @res: Pointer to devres data to free
  *
diff --git a/include/linux/device.h b/include/linux/device.h
index 52a5f15..ecd9006 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -536,6 +536,10 @@ extern void *__devres_alloc(dr_release_t release, size_t 
size, gfp_t gfp,
 #else
 extern void *devres_alloc(dr_release_t release, size_t size, gfp_t gfp);
 #endif
+extern void devres_for_each_res(struct device *dev, dr_release_t release,
+   dr_match_t match, void *match_data,
+   void (*fn)(struct device *, void *, void *),
+   void *data);
 extern void devres_free(void *res);
 extern void devres_add(struct device *dev, void *res);
 extern void *devres_find(struct device *dev, dr_release_t release,
-- 
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/

[RFC PATCH v1 10/15] firmware loader: store firmware name into devres list

[Ming Lei]

This patch will store firmware name into devres list of the device
which is requesting firmware loading, so that we can implement
auto cache and uncache firmware for devices in need.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |   64 +
 1 file changed, 64 insertions(+)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index a47266c..65c6066 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -114,6 +114,11 @@ struct firmware_priv {
struct firmware *fw;
 };
 
+struct fw_name_devm {
+   unsigned long magic;
+   char name[];
+};
+
 #define to_fwbuf(d) container_of(d, struct firmware_buf, ref)
 
 /* fw_lock could be moved to 'struct firmware_priv' but since it is just
@@ -590,6 +595,55 @@ static void fw_set_page_data(struct firmware_buf *buf, 
struct firmware *fw)
 (unsigned int)buf->size);
 }
 
+static void fw_name_devm_release(struct device *dev, void *res)
+{
+   struct fw_name_devm *fwn = res;
+
+   if (fwn->magic == (unsigned long)_cache)
+   pr_debug("%s: fw_name-%s devm-%p released\n",
+   __func__, fwn->name, res);
+}
+
+static int fw_devm_match(struct device *dev, void *res,
+   void *match_data)
+{
+   struct fw_name_devm *fwn = res;
+
+   return (fwn->magic == (unsigned long)_cache) &&
+   !strcmp(fwn->name, match_data);
+}
+
+static struct fw_name_devm *fw_find_devm_name(struct device *dev,
+   const char *name)
+{
+   struct fw_name_devm *fwn;
+
+   fwn = devres_find(dev, fw_name_devm_release,
+ fw_devm_match, (void *)name);
+   return fwn;
+}
+
+/* add firmware name into devres list */
+static int fw_add_devm_name(struct device *dev, const char *name)
+{
+   struct fw_name_devm *fwn;
+
+   fwn = fw_find_devm_name(dev, name);
+   if (fwn)
+   return 1;
+
+   fwn = devres_alloc(fw_name_devm_release, sizeof(struct fw_name_devm) +
+  strlen(name) + 1, GFP_KERNEL);
+   if (!fwn)
+   return -ENOMEM;
+
+   fwn->magic = (unsigned long)_cache;
+   strcpy(fwn->name, name);
+   devres_add(dev, fwn);
+
+   return 0;
+}
+
 static void _request_firmware_cleanup(const struct firmware **firmware_p)
 {
release_firmware(*firmware_p);
@@ -709,6 +763,16 @@ static int _request_firmware_load(struct firmware_priv 
*fw_priv, bool uevent,
if (!buf->size || test_bit(FW_STATUS_ABORT, >status))
retval = -ENOENT;
 
+   /*
+* add firmware name into devres list so that we can auto cache
+* and uncache firmware for device.
+*
+* f_dev->parent may has been deleted already, but the problem
+* should be fixed in devres or driver core.
+*/
+   if (!retval && f_dev->parent)
+   fw_add_devm_name(f_dev->parent, buf->fw_id);
+
if (!retval)
retval = fw_map_pages_buf(buf);
 
-- 
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/

[RFC PATCH v1 09/15] firmware loader: fix comments on request_firmware_nowait

[Ming Lei]

request_firmware_nowait is allowed to be called in atomic
context now if @gfp is GFP_ATOMIC, so fix the obsolete
comments and states which situations are suitable for using
it.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 7d3a83b..a47266c 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -846,9 +846,13 @@ static void request_firmware_work_func(struct work_struct 
*work)
  *
  * Caller must hold the reference count of @device.
  *
- * Asynchronous variant of request_firmware() for user contexts where
- * it is not possible to sleep for long time. It can't be called
- * in atomic contexts.
+ * Asynchronous variant of request_firmware() for user contexts:
+ * - sleep for as small periods as possible since it may
+ * increase kernel boot time of built-in device drivers
+ * requesting firmware in their ->probe() methods, if
+ * @gfp is GFP_KERNEL.
+ *
+ * - can't sleep at all if @gfp is GFP_ATOMIC.
  **/
 int
 request_firmware_nowait(
-- 
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/

[RFC PATCH v1 08/15] firmware loader: fix device lifetime

[Ming Lei]

Callers of request_firmware* must hold the reference count of
@device, otherwise it is easy to trigger oops since the firmware
loader device is the child of @device.

This patch adds comments about the usage. In fact, most of drivers
call request_firmware* in its probe() or open(), so the constraint
should be reasonable and can be satisfied.

Also this patch holds the reference count of @device before
schedule_work() in request_firmware_nowait() to avoid that
the @device is released after request_firmware_nowait returns
and before the worker function is scheduled.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index fc119ce..7d3a83b 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -742,6 +742,8 @@ err_put_dev:
  *  @name will be used as $FIRMWARE in the uevent environment and
  *  should be distinctive enough not to be confused with any other
  *  firmware image for this or any other device.
+ *
+ * Caller must hold the reference count of @device.
  **/
 int
 request_firmware(const struct firmware **firmware_p, const char *name,
@@ -823,6 +825,7 @@ static void request_firmware_work_func(struct work_struct 
*work)
 
  out:
fw_work->cont(fw, fw_work->context);
+   put_device(fw_work->device);
 
module_put(fw_work->module);
kfree(fw_work);
@@ -841,6 +844,8 @@ static void request_firmware_work_func(struct work_struct 
*work)
  * @cont: function will be called asynchronously when the firmware
  * request is over.
  *
+ * Caller must hold the reference count of @device.
+ *
  * Asynchronous variant of request_firmware() for user contexts where
  * it is not possible to sleep for long time. It can't be called
  * in atomic contexts.
@@ -869,6 +874,7 @@ request_firmware_nowait(
return -EFAULT;
}
 
+   get_device(fw_work->device);
INIT_WORK(_work->work, request_firmware_work_func);
schedule_work(_work->work);
return 0;
-- 
1.7.9.5

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

[RFC PATCH v1 07/15] firmware loader: introduce cache_firmware and uncache_firmware

[Ming Lei]

This patches introduce two kernel APIs of cache_firmware and
uncache_firmware, both of which take the firmware file name
as the only parameter.

So any drivers can call cache_firmware to cache the specified
firmware file into kernel memory, and can use the cached firmware
in situations which can't request firmware from user space.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |  100 +
 include/linux/firmware.h  |   12 +
 2 files changed, 104 insertions(+), 8 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 848ad97..fc119ce 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -142,6 +142,17 @@ static struct firmware_buf *__allocate_fw_buf(const char 
*fw_name,
return buf;
 }
 
+static struct firmware_buf *__fw_lookup_buf(const char *fw_name)
+{
+   struct firmware_buf *tmp;
+   struct firmware_cache *fwc = _cache;
+
+   list_for_each_entry(tmp, >head, list)
+   if (!strcmp(tmp->fw_id, fw_name))
+   return tmp;
+   return NULL;
+}
+
 static int fw_lookup_and_allocate_buf(const char *fw_name,
  struct firmware_cache *fwc,
  struct firmware_buf **buf)
@@ -149,14 +160,13 @@ static int fw_lookup_and_allocate_buf(const char *fw_name,
struct firmware_buf *tmp;
 
spin_lock(>lock);
-   list_for_each_entry(tmp, >head, list)
-   if (!strcmp(tmp->fw_id, fw_name)) {
-   kref_get(>ref);
-   spin_unlock(>lock);
-   *buf = tmp;
-   return 1;
-   }
-
+   tmp = __fw_lookup_buf(fw_name);
+   if (tmp) {
+   kref_get(>ref);
+   spin_unlock(>lock);
+   *buf = tmp;
+   return 1;
+   }
tmp = __allocate_fw_buf(fw_name, fwc);
if (tmp)
list_add(>list, >head);
@@ -167,6 +177,18 @@ static int fw_lookup_and_allocate_buf(const char *fw_name,
return tmp ? 0 : -ENOMEM;
 }
 
+static struct firmware_buf *fw_lookup_buf(const char *fw_name)
+{
+   struct firmware_buf *tmp;
+   struct firmware_cache *fwc = _cache;
+
+   spin_lock(>lock);
+   tmp = __fw_lookup_buf(fw_name);
+   spin_unlock(>lock);
+
+   return tmp;
+}
+
 static void __fw_free_buf(struct kref *ref)
 {
struct firmware_buf *buf = to_fwbuf(ref);
@@ -852,6 +874,66 @@ request_firmware_nowait(
return 0;
 }
 
+/**
+ * cache_firmware - cache one firmware image in kernel memory space
+ * @fw_name: the firmware image name
+ *
+ * Cache firmware in kernel memory so that drivers can use it when
+ * system isn't ready for them to request firmware image from userspace.
+ * Once it returns successfully, driver can use request_firmware or its
+ * nowait version to get the cached firmware without any interacting
+ * with userspace
+ *
+ * Return 0 if the firmware image has been cached successfully
+ * Return !0 otherwise
+ *
+ */
+int cache_firmware(const char *fw_name)
+{
+   int ret;
+   const struct firmware *fw;
+
+   pr_debug("%s: %s\n", __func__, fw_name);
+
+   ret = request_firmware(, fw_name, NULL);
+   if (!ret)
+   kfree(fw);
+
+   pr_debug("%s: %s ret=%d\n", __func__, fw_name, ret);
+
+   return ret;
+}
+
+/**
+ * uncache_firmware - remove one cached firmware image
+ * @fw_name: the firmware image name
+ *
+ * Uncache one firmware image which has been cached successfully
+ * before.
+ *
+ * Return 0 if the firmware cache has been removed successfully
+ * Return !0 otherwise
+ *
+ */
+int uncache_firmware(const char *fw_name)
+{
+   struct firmware_buf *buf;
+   struct firmware fw;
+
+   pr_debug("%s: %s\n", __func__, fw_name);
+
+   if (fw_get_builtin_firmware(, fw_name))
+   return 0;
+
+   buf = fw_lookup_buf(fw_name);
+   if (buf) {
+   fw_free_buf(buf);
+   return 0;
+   }
+
+   return -EINVAL;
+}
+
 static int __init firmware_class_init(void)
 {
fw_cache_init();
@@ -869,3 +951,5 @@ module_exit(firmware_class_exit);
 EXPORT_SYMBOL(release_firmware);
 EXPORT_SYMBOL(request_firmware);
 EXPORT_SYMBOL(request_firmware_nowait);
+EXPORT_SYMBOL_GPL(cache_firmware);
+EXPORT_SYMBOL_GPL(uncache_firmware);
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index e85b771..e4279fe 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -47,6 +47,8 @@ int request_firmware_nowait(
void (*cont)(const struct firmware *fw, void *context));
 
 void release_firmware(const struct firmware *fw);
+int cache_firmware(const char *name);
+int uncache_firmware(const char *name);
 #else
 static inline int request_firmware(const struct firmware **fw,
   const char *name,
@@ -65,6 +67,16 @@ static inline 

[RFC PATCH v1 06/15] firmware loader: always let firmware_buf own the pages buffer

[Ming Lei]

This patch always let firmware_buf own the pages buffer allocated
inside firmware_data_write, and add all instances of firmware_buf
into the firmware cache global list. Also introduce one private field
in 'struct firmware', so release_firmware will see the instance of
firmware_buf associated with the current firmware instance, then just
'free' the instance of firmware_buf.

The firmware_buf instance represents one pages buffer for one
firmware image, so lots of firmware loading requests can share
the same firmware_buf instance if they request the same firmware
image file.

This patch will make implementation of the following cache_firmware/
uncache_firmware very easy and simple.

In fact, the patch improves request_formware/release_firmware:

- only request userspace to write firmware image once if
several devices share one same firmware image and its drivers
call request_firmware concurrently.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |  240 +
 include/linux/firmware.h  |3 +
 2 files changed, 174 insertions(+), 69 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 5f2076e..848ad97 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("Manuel Estrada Sainz");
 MODULE_DESCRIPTION("Multi purpose firmware loading support");
@@ -85,13 +86,17 @@ static inline long firmware_loading_timeout(void)
return loading_timeout > 0 ? loading_timeout * HZ : 
MAX_SCHEDULE_TIMEOUT;
 }
 
-/* fw_lock could be moved to 'struct firmware_priv' but since it is just
- * guarding for corner cases a global lock should be OK */
-static DEFINE_MUTEX(fw_lock);
+struct firmware_cache {
+   /* firmware_buf instance will be added into the below list */
+   spinlock_t lock;
+   struct list_head head;
+};
 
 struct firmware_buf {
+   struct kref ref;
+   struct list_head list;
struct completion completion;
-   struct firmware *fw;
+   struct firmware_cache *fwc;
unsigned long status;
void *data;
size_t size;
@@ -106,8 +111,94 @@ struct firmware_priv {
bool nowait;
struct device dev;
struct firmware_buf *buf;
+   struct firmware *fw;
 };
 
+#define to_fwbuf(d) container_of(d, struct firmware_buf, ref)
+
+/* fw_lock could be moved to 'struct firmware_priv' but since it is just
+ * guarding for corner cases a global lock should be OK */
+static DEFINE_MUTEX(fw_lock);
+
+static struct firmware_cache fw_cache;
+
+static struct firmware_buf *__allocate_fw_buf(const char *fw_name,
+ struct firmware_cache *fwc)
+{
+   struct firmware_buf *buf;
+
+   buf = kzalloc(sizeof(*buf) + strlen(fw_name) + 1 , GFP_ATOMIC);
+
+   if (!buf)
+   return buf;
+
+   kref_init(>ref);
+   strcpy(buf->fw_id, fw_name);
+   buf->fwc = fwc;
+   init_completion(>completion);
+
+   pr_debug("%s: fw-%s buf=%p\n", __func__, fw_name, buf);
+
+   return buf;
+}
+
+static int fw_lookup_and_allocate_buf(const char *fw_name,
+ struct firmware_cache *fwc,
+ struct firmware_buf **buf)
+{
+   struct firmware_buf *tmp;
+
+   spin_lock(>lock);
+   list_for_each_entry(tmp, >head, list)
+   if (!strcmp(tmp->fw_id, fw_name)) {
+   kref_get(>ref);
+   spin_unlock(>lock);
+   *buf = tmp;
+   return 1;
+   }
+
+   tmp = __allocate_fw_buf(fw_name, fwc);
+   if (tmp)
+   list_add(>list, >head);
+   spin_unlock(>lock);
+
+   *buf = tmp;
+
+   return tmp ? 0 : -ENOMEM;
+}
+
+static void __fw_free_buf(struct kref *ref)
+{
+   struct firmware_buf *buf = to_fwbuf(ref);
+   struct firmware_cache *fwc = buf->fwc;
+   int i;
+
+   pr_debug("%s: fw-%s buf=%p data=%p size=%u\n",
+__func__, buf->fw_id, buf, buf->data,
+(unsigned int)buf->size);
+
+   spin_lock(>lock);
+   list_del(>list);
+   spin_unlock(>lock);
+
+   vunmap(buf->data);
+   for (i = 0; i < buf->nr_pages; i++)
+   __free_page(buf->pages[i]);
+   kfree(buf->pages);
+   kfree(buf);
+}
+
+static void fw_free_buf(struct firmware_buf *buf)
+{
+   kref_put(>ref, __fw_free_buf);
+}
+
+static void __init fw_cache_init(void)
+{
+   spin_lock_init(_cache.lock);
+   INIT_LIST_HEAD(_cache.head);
+}
+
 static struct firmware_priv *to_firmware_priv(struct device *dev)
 {
return container_of(dev, struct firmware_priv, dev);
@@ -118,7 +209,7 @@ static void fw_load_abort(struct firmware_priv *fw_priv)
struct firmware_buf *buf = fw_priv->buf;
 
set_bit(FW_STATUS_ABORT, >status);
-   

[RFC PATCH v1 05/15] firmware loader: introduce firmware_buf

[Ming Lei]

This patch introduces struct firmware_buf to describe the buffer
which holds the firmware data, which will make the following
cache_firmware/uncache_firmware implemented easily.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |  180 +++--
 1 file changed, 102 insertions(+), 78 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 04c75b5..5f2076e 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -89,7 +89,7 @@ static inline long firmware_loading_timeout(void)
  * guarding for corner cases a global lock should be OK */
 static DEFINE_MUTEX(fw_lock);
 
-struct firmware_priv {
+struct firmware_buf {
struct completion completion;
struct firmware *fw;
unsigned long status;
@@ -98,10 +98,14 @@ struct firmware_priv {
struct page **pages;
int nr_pages;
int page_array_size;
+   char fw_id[];
+};
+
+struct firmware_priv {
struct timer_list timeout;
-   struct device dev;
bool nowait;
-   char fw_id[];
+   struct device dev;
+   struct firmware_buf *buf;
 };
 
 static struct firmware_priv *to_firmware_priv(struct device *dev)
@@ -111,8 +115,10 @@ static struct firmware_priv *to_firmware_priv(struct 
device *dev)
 
 static void fw_load_abort(struct firmware_priv *fw_priv)
 {
-   set_bit(FW_STATUS_ABORT, _priv->status);
-   complete(_priv->completion);
+   struct firmware_buf *buf = fw_priv->buf;
+
+   set_bit(FW_STATUS_ABORT, >status);
+   complete(>completion);
 }
 
 static ssize_t firmware_timeout_show(struct class *class,
@@ -152,15 +158,21 @@ static struct class_attribute firmware_class_attrs[] = {
__ATTR_NULL
 };
 
-static void fw_dev_release(struct device *dev)
+static void fw_free_buf(struct firmware_buf *buf)
 {
-   struct firmware_priv *fw_priv = to_firmware_priv(dev);
int i;
 
-   /* free untransfered pages buffer */
-   for (i = 0; i < fw_priv->nr_pages; i++)
-   __free_page(fw_priv->pages[i]);
-   kfree(fw_priv->pages);
+   if (!buf)
+   return;
+
+   for (i = 0; i < buf->nr_pages; i++)
+   __free_page(buf->pages[i]);
+   kfree(buf->pages);
+}
+
+static void fw_dev_release(struct device *dev)
+{
+   struct firmware_priv *fw_priv = to_firmware_priv(dev);
 
kfree(fw_priv);
 
@@ -171,7 +183,7 @@ static int firmware_uevent(struct device *dev, struct 
kobj_uevent_env *env)
 {
struct firmware_priv *fw_priv = to_firmware_priv(dev);
 
-   if (add_uevent_var(env, "FIRMWARE=%s", fw_priv->fw_id))
+   if (add_uevent_var(env, "FIRMWARE=%s", fw_priv->buf->fw_id))
return -ENOMEM;
if (add_uevent_var(env, "TIMEOUT=%i", loading_timeout))
return -ENOMEM;
@@ -192,7 +204,7 @@ static ssize_t firmware_loading_show(struct device *dev,
 struct device_attribute *attr, char *buf)
 {
struct firmware_priv *fw_priv = to_firmware_priv(dev);
-   int loading = test_bit(FW_STATUS_LOADING, _priv->status);
+   int loading = test_bit(FW_STATUS_LOADING, _priv->buf->status);
 
return sprintf(buf, "%d\n", loading);
 }
@@ -231,32 +243,33 @@ static ssize_t firmware_loading_store(struct device *dev,
  const char *buf, size_t count)
 {
struct firmware_priv *fw_priv = to_firmware_priv(dev);
+   struct firmware_buf *fw_buf = fw_priv->buf;
int loading = simple_strtol(buf, NULL, 10);
int i;
 
mutex_lock(_lock);
 
-   if (!fw_priv->fw)
+   if (!fw_buf)
goto out;
 
switch (loading) {
case 1:
/* discarding any previous partial load */
-   if (!test_bit(FW_STATUS_DONE, _priv->status)) {
-   for (i = 0; i < fw_priv->nr_pages; i++)
-   __free_page(fw_priv->pages[i]);
-   kfree(fw_priv->pages);
-   fw_priv->pages = NULL;
-   fw_priv->page_array_size = 0;
-   fw_priv->nr_pages = 0;
-   set_bit(FW_STATUS_LOADING, _priv->status);
+   if (!test_bit(FW_STATUS_DONE, _buf->status)) {
+   for (i = 0; i < fw_buf->nr_pages; i++)
+   __free_page(fw_buf->pages[i]);
+   kfree(fw_buf->pages);
+   fw_buf->pages = NULL;
+   fw_buf->page_array_size = 0;
+   fw_buf->nr_pages = 0;
+   set_bit(FW_STATUS_LOADING, _buf->status);
}
break;
case 0:
-   if (test_bit(FW_STATUS_LOADING, _priv->status)) {
-   set_bit(FW_STATUS_DONE, _priv->status);
-   clear_bit(FW_STATUS_LOADING, _priv->status);
-   

[RFC PATCH v1 04/15] firmware loader: fix creation failure of fw loader device

[Ming Lei]

If one device driver calls request_firmware_nowait() to request
several different firmwares' loading, device_add() will return
failure since all firmware loader device use same name of the
device who is requesting firmware.

This patch always use the name of firmware image as the firmware
loader device name to fix the problem since the following patches
for caching firmware will make sure only one loading for same
firmware is alllowd at the same time.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 0bd09c7..04c75b5 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -452,7 +452,7 @@ fw_create_instance(struct firmware *firmware, const char 
*fw_name,
f_dev = _priv->dev;
 
device_initialize(f_dev);
-   dev_set_name(f_dev, "%s", dev_name(device));
+   dev_set_name(f_dev, "%s", fw_name);
f_dev->parent = device;
f_dev->class = _class;
 
-- 
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/

[RFC PATCH v1 02/15] firmware loader: fix races during loading firmware

[Ming Lei]

This patch fixes two races in loading firmware:

1, FW_STATUS_DONE should be set before waking up the task waitting
on _request_firmware_load, otherwise FW_STATUS_ABORT may be
thought as DONE mistakenly.

2, Inside _request_firmware_load(), there is a small window between
wait_for_completion() and mutex_lock(_lock), and 'echo 1 > loading'
still may happen during the period, so this patch checks FW_STATUS_DONE
to prevent pages' buffer completed from being freed in firmware_loading_store.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |   20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 1cbefcf..1915ad8 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -243,18 +243,21 @@ static ssize_t firmware_loading_store(struct device *dev,
switch (loading) {
case 1:
/* discarding any previous partial load */
-   for (i = 0; i < fw_priv->nr_pages; i++)
-   __free_page(fw_priv->pages[i]);
-   kfree(fw_priv->pages);
-   fw_priv->pages = NULL;
-   fw_priv->page_array_size = 0;
-   fw_priv->nr_pages = 0;
-   set_bit(FW_STATUS_LOADING, _priv->status);
+   if (!test_bit(FW_STATUS_DONE, _priv->status)) {
+   for (i = 0; i < fw_priv->nr_pages; i++)
+   __free_page(fw_priv->pages[i]);
+   kfree(fw_priv->pages);
+   fw_priv->pages = NULL;
+   fw_priv->page_array_size = 0;
+   fw_priv->nr_pages = 0;
+   set_bit(FW_STATUS_LOADING, _priv->status);
+   }
break;
case 0:
if (test_bit(FW_STATUS_LOADING, _priv->status)) {
-   complete(_priv->completion);
+   set_bit(FW_STATUS_DONE, _priv->status);
clear_bit(FW_STATUS_LOADING, _priv->status);
+   complete(_priv->completion);
break;
}
/* fallthrough */
@@ -557,7 +560,6 @@ static int _request_firmware_load(struct firmware_priv 
*fw_priv, bool uevent,
 
wait_for_completion(_priv->completion);
 
-   set_bit(FW_STATUS_DONE, _priv->status);
del_timer_sync(_priv->timeout);
 
mutex_lock(_lock);
-- 
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/

[RFC PATCH v1 01/15] firmware loader: simplify pages ownership transfer

[Ming Lei]

This patch doesn't transfer ownership of pages' buffer to the
instance of firmware until the firmware loading is completed,
which will simplify firmware_loading_store a lot, so help
to introduce the following cache_firmware and uncache_firmware
mechanism during system suspend-resume cycle.

In fact, this patch fixes one bug: if writing data into
firmware loader device is bypassed between writting 1 and 0 to
'loading', OOPS will be triggered without the patch.

Also handle the vmap failure case, and add some comments to make
code more readable.

Signed-off-by: Ming Lei 
---
 drivers/base/firmware_class.c |   62 ++---
 1 file changed, 39 insertions(+), 23 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 803cfc1..1cbefcf 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -93,6 +93,8 @@ struct firmware_priv {
struct completion completion;
struct firmware *fw;
unsigned long status;
+   void *data;
+   size_t size;
struct page **pages;
int nr_pages;
int page_array_size;
@@ -156,9 +158,11 @@ static void fw_dev_release(struct device *dev)
struct firmware_priv *fw_priv = to_firmware_priv(dev);
int i;
 
+   /* free untransfered pages buffer */
for (i = 0; i < fw_priv->nr_pages; i++)
__free_page(fw_priv->pages[i]);
kfree(fw_priv->pages);
+
kfree(fw_priv);
 
module_put(THIS_MODULE);
@@ -194,6 +198,7 @@ static ssize_t firmware_loading_show(struct device *dev,
return sprintf(buf, "%d\n", loading);
 }
 
+/* firmware holds the ownership of pages */
 static void firmware_free_data(const struct firmware *fw)
 {
int i;
@@ -237,9 +242,7 @@ static ssize_t firmware_loading_store(struct device *dev,
 
switch (loading) {
case 1:
-   firmware_free_data(fw_priv->fw);
-   memset(fw_priv->fw, 0, sizeof(struct firmware));
-   /* If the pages are not owned by 'struct firmware' */
+   /* discarding any previous partial load */
for (i = 0; i < fw_priv->nr_pages; i++)
__free_page(fw_priv->pages[i]);
kfree(fw_priv->pages);
@@ -250,20 +253,6 @@ static ssize_t firmware_loading_store(struct device *dev,
break;
case 0:
if (test_bit(FW_STATUS_LOADING, _priv->status)) {
-   vunmap(fw_priv->fw->data);
-   fw_priv->fw->data = vmap(fw_priv->pages,
-fw_priv->nr_pages,
-0, PAGE_KERNEL_RO);
-   if (!fw_priv->fw->data) {
-   dev_err(dev, "%s: vmap() failed\n", __func__);
-   goto err;
-   }
-   /* Pages are now owned by 'struct firmware' */
-   fw_priv->fw->pages = fw_priv->pages;
-   fw_priv->pages = NULL;
-
-   fw_priv->page_array_size = 0;
-   fw_priv->nr_pages = 0;
complete(_priv->completion);
clear_bit(FW_STATUS_LOADING, _priv->status);
break;
@@ -273,7 +262,6 @@ static ssize_t firmware_loading_store(struct device *dev,
dev_err(dev, "%s: unexpected value (%d)\n", __func__, loading);
/* fallthrough */
case -1:
-   err:
fw_load_abort(fw_priv);
break;
}
@@ -299,12 +287,12 @@ static ssize_t firmware_data_read(struct file *filp, 
struct kobject *kobj,
ret_count = -ENODEV;
goto out;
}
-   if (offset > fw->size) {
+   if (offset > fw_priv->size) {
ret_count = 0;
goto out;
}
-   if (count > fw->size - offset)
-   count = fw->size - offset;
+   if (count > fw_priv->size - offset)
+   count = fw_priv->size - offset;
 
ret_count = count;
 
@@ -396,6 +384,7 @@ static ssize_t firmware_data_write(struct file *filp, 
struct kobject *kobj,
retval = -ENODEV;
goto out;
}
+
retval = fw_realloc_buffer(fw_priv, offset + count);
if (retval)
goto out;
@@ -418,7 +407,7 @@ static ssize_t firmware_data_write(struct file *filp, 
struct kobject *kobj,
count -= page_cnt;
}
 
-   fw->size = max_t(size_t, offset, fw->size);
+   fw_priv->size = max_t(size_t, offset, fw_priv->size);
 out:
mutex_unlock(_lock);
return retval;
@@ -504,6 +493,29 @@ static void _request_firmware_cleanup(const struct 
firmware **firmware_p)
*firmware_p = NULL;
 }
 
+/* transfer the ownership of pages to firmware */
+static int fw_set_page_data(struct firmware_priv 

[RFC PATCH v1 00/15] firmware loader: introduce cache/uncache firmware

[Ming Lei]

Hi,

In [1][2], the problem below has been discussed for some time:

device's firmware may be lost during suspend/resume
cycle because device might be unplugged and plugged again
or device experiences system power loss during the period.
But in resume path, system is still not ready(process
frozen, rootfs not usable, ...) to complete loading firmware
from user space for devices.

The conclusion is that caching firmware during suspend/resume cycle
is capable of solving the problem.

This patchset implements cache/uncache firmware mechanism,
and apply the mechnism to cache device's firmware in kernel memory
space automatically during suspend/resume cyclye, so device can
load its firmware easily in its resume path. When resume is completed
and system is ready, the cached firmware will be removed from
kernel memory later.

The patch 15/15 is one example to apply the firmware cache mechanism on
ath9k-htc driver.

Even there are some corener cases[3] which can't be solved by the
cache approach, but as discussed in[4], the problem can be easily
fixed by a simple patch written by Linus.

This patch set is against 3.6.0-rc1-next-20120803.

[1]. http://marc.info/?t=13427879084=1=2
[2]. http://marc.info/?t=13252895602=10=2
[3]. http://marc.info/?l=linux-usb=132554118928398=2
[4]. http://marc.info/?l=linux-kernel=134323730805443=2  

--
V1:
-handle vmap failure case(1/15)
-fix a memory leak of 'firmware_buf'(5/15)
-fix oops during failure path of requesting firmware(6/15)
-fix vmap more than one time(6/15)
-introduce __fw_lookup_buf to avoid code duplication(7/15)
-fix comment of request_firmware_nowait(9/15)
-avoid releasing lock in devres_for_each_res(11/15)
-use new devres iterator API to create fw cache entry(12/15)
-rename some functions and data structures(12/15)
-some code style fixes

Thanks for Borislav's review!

--
 drivers/base/devres.c|   42 ++
 drivers/base/firmware_class.c|  764 ++
 drivers/net/wireless/ath/ath9k/hif_usb.c |   34 +-
 drivers/net/wireless/ath/ath9k/hif_usb.h |4 +-
 include/linux/device.h   |4 +
 include/linux/firmware.h |   15 +
 6 files changed, 747 insertions(+), 116 deletions(-)


Thanks,
--
Ming Lei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scripts/get_maintainer.pl: Default to --no-rolestats when output not a terminal

[Josh Triplett]

On Fri, Aug 03, 2012 at 05:37:30PM -0700, Joe Perches wrote:
> On Fri, 2012-08-03 at 11:47 -0700, Josh Triplett wrote:
> > On Fri, Aug 03, 2012 at 11:33:21AM -0700, Joe Perches wrote:
> > > On Fri, 2012-08-03 at 11:27 -0700, Josh Triplett wrote:
> > > > scripts/get_maintainer.pl defaults to showing --rolestats, which
> > > > provides annotations explaining why each person or list might want to
> > > > know about a patch.  This works well for interactive use, but breaks
> > > > when used with git send-email's --to-cmd or --cc-cmd, resulting in
> > > > malformed email headers and mails sent to some but not all recipients.
> > > > 
> > > > To avoid the need to explicitly pass --no-rolestats for batch use,
> > > > enable --rolestats by default only when outputting to a terminal.
> > > 
> > > Hi Josh.
> > > 
> > > I think it's preferable to add --no-rolestats
> > > to the uses that need them.
> > 
> > Why?
> > 
> > > I have different scripts that I use for git send-email
> > > options --to-cmd and --cc-cmd
> > [...snip scripts...]
> > 
> > You've submitted enough patches that you've automated as much of the
> > process as you can; I don't think that makes the defaults less
> > error-prone.
> 
> I think the default use of the get_maintainer script is
> actually not scripted but interactive, where the user is
> just trying to figure out who the maintainer is.

I agree entirely; that's why I didn't change the default to always use
--no-rolestats, but rather to continue using --rolestats when
interactive and --no-rolestats when scripted.

> > As it stands now, the current default of --rolestats makes the obvious
> > command line of
> > git send-email --to-cmd='scripts/get_maintainer.pl' *.patch
> > send broken emails that go to some maintainers but not all.  I think it
> > makes sense to change the default so that the obvious usage becomes the
> > correct one.
> 
> There were some discussions awhile back in 2010 about the
> preferred defaults.
> 
> Perhaps you can read those discussions about why the default
> is the way it is.

I found commit 7e1863af1636b304a5f59aab6fb78d38e4079875, but that commit
does not serve the intended purpose.  Defaulting to --rolestats doesn't
make it "harder" to use get_maintainer.pl with git send-email, it just
makes it broken when used.  Meanwhile, the few discussions I see about
get_maintainer.pl just mention the problems caused by using --git, and
get_maintainer.pl has already improved to address those problems by not
using git commit signers for patches to files with active maintainers.

I don't see any value in making it intentionally harder to invoke
correctly while making it easier to invoke incorrectly.  Why not make it
actually work?

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: fix migration thread runtime bogosity

[Mike Galbraith]

On Fri, 2012-08-03 at 22:39 +0200, Peter Zijlstra wrote:

> Now the question is, how did that stop thing get any time to begin with?
> Are we hotplugging or somesuch sillyness?

Nope, high frequency exec.

> Anyway, I think I like B best, could you re-submit as a proper patch so
> I can press the magic button that queues stuff?

Ok, B it is.  Since that SUSE guy munged my mailboxes again (twit), he
can write the changelog, and take the blame.

-Mike

From: Mike Galbraith 

sched: fix migration thread runtime bogosity

Make stop scheduler class do the same accounting as other classes,

Migration threads can be caught in the act while doing exec balancing,
leading to the below due to use of unmaintained ->se.exec_start.  The
load that triggered this particular instance was an apparently out of
control heavily threaded application that does system monitoring in
what equated to an exec bomb, with one of the VERY frequently migrated
tasks being ps.

%CPU   PID USER CMD
99.345 root [migration/10]
97.753 root [migration/12]
97.057 root [migration/13]
90.149 root [migration/11]
89.665 root [migration/15]
88.717 root [migration/3]
80.437 root [migration/8]
78.141 root [migration/9]
44.213 root [migration/2]

Signed-off-by: Mike Galbraith 

diff --git a/kernel/sched/stop_task.c b/kernel/sched/stop_task.c
index 7b386e8..da5eb5b 100644
--- a/kernel/sched/stop_task.c
+++ b/kernel/sched/stop_task.c
@@ -27,8 +27,10 @@ static struct task_struct *pick_next_task_stop(struct rq *rq)
 {
struct task_struct *stop = rq->stop;
 
-   if (stop && stop->on_rq)
+   if (stop && stop->on_rq) {
+   stop->se.exec_start = rq->clock_task;
return stop;
+   }
 
return NULL;
 }
@@ -52,6 +54,21 @@ static void yield_task_stop(struct rq *rq)
 
 static void put_prev_task_stop(struct rq *rq, struct task_struct *prev)
 {
+   struct task_struct *curr = rq->curr;
+   u64 delta_exec;
+
+   delta_exec = rq->clock_task - curr->se.exec_start;
+   if (unlikely((s64)delta_exec < 0))
+   delta_exec = 0;
+
+   schedstat_set(curr->se.statistics.exec_max,
+   max(curr->se.statistics.exec_max, delta_exec));
+
+   curr->se.sum_exec_runtime += delta_exec;
+   account_group_exec_runtime(curr, delta_exec);
+
+   curr->se.exec_start = rq->clock_task;
+   cpuacct_charge(curr, delta_exec);
 }
 
 static void task_tick_stop(struct rq *rq, struct task_struct *curr, int queued)
@@ -60,6 +77,9 @@ static void task_tick_stop(struct rq *rq, struct task_struct 
*curr, int queued)
 
 static void set_curr_task_stop(struct rq *rq)
 {
+   struct task_struct *stop = rq->stop;
+
+   stop->se.exec_start = rq->clock_task;
 }
 
 static void switched_to_stop(struct rq *rq, struct task_struct *p)


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

[David Miller]

From: Tim Gardner 
Date: Thu, 02 Aug 2012 06:28:58 -0600

>   git://kernel.ubuntu.com/rtg/net-next.git master
> 
> for you to fetch changes up to 044b722f36a17bc5f7f472cc3246cb15a430bb0e:
> 
>   firmware: Remove obsolete Chelsio cxgb3 firmware (2012-08-02 06:23:25
> -0600)

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

Re: [PATCH] cris: fix eth_v10.c build error

[David Miller]

From: Randy Dunlap 
Date: Fri, 03 Aug 2012 17:38:07 -0700

> From: Randy Dunlap 
> 
> Fix build error on cris (not tested, no toolchain here):
> 
> drivers/net/cris/eth_v10.c: error: too many arguments to function 
> 'e100rxtx_interrupt'
> 
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Randy Dunlap 

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

[PATCH] Extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices

[Anish Kumar]

From: anish kumar 

External connector devices that decides connection information based on
ADC values may use adc-jack device driver. The user simply needs to
provide a table of adc range and connection states. Then, extcon
framework will automatically notify others.

Signed-off-by: anish kumar 
---
 drivers/extcon/Kconfig  |6 +-
 drivers/extcon/Makefile |1 +
 drivers/extcon/adc_jack.c   |  183 +++
 include/linux/extcon/adc_jack.h |  109 +++
 4 files changed, 298 insertions(+), 1 deletions(-)
 create mode 100644 drivers/extcon/adc_jack.c
 create mode 100644 include/linux/extcon/adc_jack.h

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index e175c8e..3a35117 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -16,11 +16,15 @@ comment "Extcon Device Drivers"
 
 config EXTCON_GPIO
tristate "GPIO extcon support"
-   depends on GENERIC_GPIO
help
  Say Y here to enable GPIO based extcon support. Note that GPIO
  extcon supports single state per extcon instance.
 
+config EXTCON_ADC_JACK
+tristate "ADC Jack extcon support"
+help
+  Say Y here to enable extcon device driver based on ADC values.
+
 config EXTCON_MAX77693
tristate "MAX77693 EXTCON Support"
depends on MFD_MAX77693
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 88961b3..d95c5ea 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_EXTCON)   += extcon_class.o
 obj-$(CONFIG_EXTCON_GPIO)  += extcon_gpio.o
+obj-$(CONFIG_EXTCON_ADC_JACK)   += adc_jack.o
 obj-$(CONFIG_EXTCON_MAX77693)  += extcon-max77693.o
 obj-$(CONFIG_EXTCON_MAX8997)   += extcon-max8997.o
 obj-$(CONFIG_EXTCON_ARIZONA)   += extcon-arizona.o
diff --git a/drivers/extcon/adc_jack.c b/drivers/extcon/adc_jack.c
new file mode 100644
index 000..fef8334
--- /dev/null
+++ b/drivers/extcon/adc_jack.c
@@ -0,0 +1,183 @@
+/*
+ * drivers/extcon/adc_jack.c
+ *
+ * Analog Jack extcon driver with ADC-based detection capability.
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * MyungJoo Ham 
+ *
+ * Modified for calling to IIO to get adc by 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void adc_jack_handler(struct work_struct *work)
+{
+   struct adc_jack_data *data = container_of(to_delayed_work(work),
+ struct adc_jack_data,
+ handler);
+   u32 state = 0;
+   int ret, adc_val;
+   int i;
+
+   if (!data->ready)
+   return;
+
+   ret = iio_read_channel_raw(data->chan, _val);
+   if (ret < 0) {
+   dev_err(data->edev.dev, "read channel() error: %d\n", ret);
+   return;
+   }
+
+   /* Get state from adc value with adc_condition */
+   for (i = 0; i < data->num_conditions; i++) {
+   struct adc_jack_cond *def = >adc_condition[i];
+   if (!def->state)
+   break;
+   if (def->min_adc <= adc_val && def->max_adc >= adc_val) {
+   state = def->state;
+   break;
+   }
+   }
+   /* if no def has met, it means state = 0 (no cables attached) */
+
+   extcon_set_state(>edev, state);
+}
+
+static irqreturn_t adc_jack_irq_thread(int irq, void *_data)
+{
+   struct adc_jack_data *data = _data;
+
+   schedule_delayed_work(>handler, data->handling_delay);
+
+   return IRQ_HANDLED;
+}
+
+static int adc_jack_probe(struct platform_device *pdev)
+{
+   struct adc_jack_data *data;
+   struct adc_jack_pdata *pdata = pdev->dev.platform_data;
+   int i, err = 0;
+
+   data = kzalloc(sizeof(struct adc_jack_data), GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
+
+   data->edev.name = pdata->name;
+
+   if (pdata->cable_names)
+   data->edev.supported_cable = pdata->cable_names;
+   else
+   data->edev.supported_cable = extcon_cable_name;
+
+   /* Check the length of array and set num_cables */
+   for (i = 0; data->edev.supported_cable[i]; i++)
+   ;
+   if (i == 0 || i > SUPPORTED_CABLE_MAX) {
+   err = -EINVAL;
+   dev_err(>dev, "error: pdata->cable_names size = %d\n",
+   i - 1);
+   goto err_alloc;
+   }
+   data->num_cables = i;
+
+   if (!pdata->adc_condition ||
+   !pdata->adc_condition[0].state) {
+   err = -EINVAL;
+   dev_err(>dev, "error: adc_condition not defined.\n");
+   goto err_alloc;
+   }

Re: oops in pci_acs_path_enabled

[Alex Williamson]

On Fri, 2012-08-03 at 16:08 -0600, David Ahern wrote:
> On 8/3/12 3:52 PM, Alex Williamson wrote:
> > Is this the chunk that's causing the oops?
> 
> Yes. And taking it out fixes passthrough as well.

Hey David,

One more test please.  It looks like sriov creates buses with bus->self
is NULL.  I think what we want to do in this case is to look at
bus->parent->self.  The patch below redefines pci_acs_path_enabled
slightly to allow it to do this.  The caller needs to change too, but
this also allows us to be more consistent about applying quirks and
dealing with multifunction devices.  If this works I'll apply the same
change to amd_iommu and submit.  Thanks,

Alex

Signed-off-by: Alex Williamson 

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 7469b53..4e37e9b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4124,8 +4124,14 @@ static int intel_iommu_add_device(struct device *dev)
} else
dma_pdev = pci_dev_get(pdev);
 
+acs_retest:
+   /* Account for quirked devices */
swap_pci_ref(_pdev, pci_get_dma_source(dma_pdev));
 
+   /*
+* If it's a multifunction device that does not support our
+* required ACS flags, add to the same group as function 0.
+*/
if (dma_pdev->multifunction &&
!pci_acs_enabled(dma_pdev, REQ_ACS_FLAGS))
swap_pci_ref(_pdev,
@@ -4133,14 +4139,29 @@ static int intel_iommu_add_device(struct device *dev)
  PCI_DEVFN(PCI_SLOT(dma_pdev->devfn),
  0)));
 
-   while (!pci_is_root_bus(dma_pdev->bus)) {
-   if (pci_acs_path_enabled(dma_pdev->bus->self,
-NULL, REQ_ACS_FLAGS))
-   break;
+   /*
+* Test ACS support from our current DMA device up to the top of the
+* hierarchy.  If the test fails, go to the next upstream device and
+* try again.  Devices on the root bus always go through the iommu.
+*/
+   if (!pci_is_root_bus(dma_pdev->bus)) {
+   struct pci_bus *bus = dma_pdev->bus;
+
+   if (pci_acs_path_enabled(bus, NULL, REQ_ACS_FLAGS))
+   goto done;
+
+   while (!bus->self) {
+   if (!pci_is_root_bus(bus))
+   bus = bus->parent;
+   else
+   goto done;
+   }
 
-   swap_pci_ref(_pdev, pci_dev_get(dma_pdev->bus->self));
+   swap_pci_ref(_pdev, pci_dev_get(bus->self));
+   goto acs_retest;
}
 
+done:
group = iommu_group_get(_pdev->dev);
pci_dev_put(dma_pdev);
if (!group) {
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f3ea977..995c13f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2475,21 +2475,28 @@ bool pci_acs_enabled(struct pci_dev *pdev, u16 
acs_flags)
 }
 
 /**
- * pci_acs_path_enable - test ACS flags from start to end in a hierarchy
- * @start: starting downstream device
+ * pci_acs_path_enabled - test ACS flags from a starting bus to an end device
+ * @bus: starting downstream bus
  * @end: ending upstream device or NULL to search to the root bus
  * @acs_flags: required flags
  *
- * Walk up a device tree from start to end testing PCI ACS support.  If
+ * Walk up a PCI hiearchy from bus to end testing PCI ACS support.  If
  * any step along the way does not support the required flags, return false.
  */
-bool pci_acs_path_enabled(struct pci_dev *start,
+bool pci_acs_path_enabled(struct pci_bus *bus,
  struct pci_dev *end, u16 acs_flags)
 {
-   struct pci_dev *pdev, *parent = start;
+   struct pci_dev *pdev;
 
do {
-   pdev = parent;
+   while (!bus->self) {
+   if (!pci_is_root_bus(bus))
+   bus = bus->parent;
+   else
+   return (end == NULL);
+   }
+
+   pdev = bus->self;
 
if (!pci_acs_enabled(pdev, acs_flags))
return false;
@@ -2497,7 +2504,7 @@ bool pci_acs_path_enabled(struct pci_dev *start,
if (pci_is_root_bus(pdev->bus))
return (end == NULL);
 
-   parent = pdev->bus->self;
+   bus = bus->self->bus;
} while (pdev != end);
 
return true;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 5faa831..eb9773c 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1652,7 +1652,7 @@ static inline bool pci_is_pcie(struct pci_dev *dev)
 
 void pci_request_acs(void);
 bool pci_acs_enabled(struct pci_dev *pdev, u16 acs_flags);
-bool pci_acs_path_enabled(struct pci_dev *start,
+bool pci_acs_path_enabled(struct pci_bus *bus,
  struct pci_dev *end, u16 

Re: [PATCH] thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR

[Henrique de Moraes Holschuh]

On Fri, 03 Aug 2012, Manoj Iyer wrote:
> Oops! This is embarrassing! my logic is flawed. Please ignore this
> patch, I will resend it

Presumably with at least one sentence to let us know how well the driver
does operate on the V-series since you want it to load there  ;-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pstore: fix printk format warning

[Kees Cook]

On Fri, Aug 3, 2012 at 6:32 PM, Randy Dunlap  wrote:
> On 08/03/2012 06:15 PM, Anton Vorontsov wrote:
>
>> On Fri, Aug 03, 2012 at 05:02:48PM -0700, Randy Dunlap wrote:
>>> From: Randy Dunlap 
>>>
>>> Fix printk format warning (on i386) in pstore:
>>>
>>> fs/pstore/ram.c:409:3: warning: format '%lu' expects type 'long unsigned 
>>> int', but argument 2 has type 'size_t'
>>>
>>> Signed-off-by: Randy Dunlap 
>>> Acked-by: Kees Cook 
>>> Cc: Anton Vorontsov 
>>> ---
>>> I posted this patch on June 15 and July 23 but it has not been
>>> merged anywhere afaict, so I'm sending it directly to the man.
>>
>> (I believe it's the first time I see that patch.)
>
> That's quite possible.  When Kees acked it, he advised
> me to send it to GregKH, which I did, to no avail.
>
>
>> Btw, I see no maintainers for the pstore, and it surely no longer
>> belongs to staging. Tony, I can send patches to you, or I can create
>> a git tree (actually, I already had it for my own convenience).. So
>> how about the following patch?
>
> Thanks for adding a MAINTAINERS entry for it.
>
>> Kees, Colin, as you're also pstore authors, I assume you're interested
>> in reviewing/[n]acking any possible changes, so I also added you to
>> the M: entries, is that OK?

Cool with me; thanks!

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pstore: fix printk format warning

[Randy Dunlap]

On 08/03/2012 06:15 PM, Anton Vorontsov wrote:

> On Fri, Aug 03, 2012 at 05:02:48PM -0700, Randy Dunlap wrote:
>> From: Randy Dunlap 
>>
>> Fix printk format warning (on i386) in pstore:
>>
>> fs/pstore/ram.c:409:3: warning: format '%lu' expects type 'long unsigned 
>> int', but argument 2 has type 'size_t'
>>
>> Signed-off-by: Randy Dunlap 
>> Acked-by: Kees Cook 
>> Cc: Anton Vorontsov 
>> ---
>> I posted this patch on June 15 and July 23 but it has not been
>> merged anywhere afaict, so I'm sending it directly to the man.
> 
> (I believe it's the first time I see that patch.)

That's quite possible.  When Kees acked it, he advised
me to send it to GregKH, which I did, to no avail.


> Btw, I see no maintainers for the pstore, and it surely no longer
> belongs to staging. Tony, I can send patches to you, or I can create
> a git tree (actually, I already had it for my own convenience).. So
> how about the following patch?

Thanks for adding a MAINTAINERS entry for it.

> Kees, Colin, as you're also pstore authors, I assume you're interested
> in reviewing/[n]acking any possible changes, so I also added you to
> the M: entries, is that OK?
> 
> - - - -
> From: Anton Vorontsov 
> Subject: [PATCH] MAINTAINERS: Add pstore maintainers
> 
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  MAINTAINERS |   12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 94b823f..9aa40c1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5496,6 +5496,18 @@ L: cbe-oss-...@lists.ozlabs.org
>  S:   Maintained
>  F:   drivers/block/ps3vram.c
>  
> +PSTORE FILESYSTEM
> +M:   Anton Vorontsov 
> +M:   Colin Cross 
> +M:   Kees Cook 
> +M:   Tony Luck 
> +S:   Maintained
> +T:   git git://git.infradead.org/users/cbou/linux-pstore.git
> +F:   fs/pstore/
> +F:   include/linux/pstore*
> +F:   drivers/firmware/efivars.c
> +F:   drivers/acpi/apei/erst.c
> +
>  PTP HARDWARE CLOCK SUPPORT
>  M:   Richard Cochran 
>  S:   Maintained



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

Re: [PATCH] pstore: fix printk format warning

[Anton Vorontsov]

On Fri, Aug 03, 2012 at 05:02:48PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Fix printk format warning (on i386) in pstore:
> 
> fs/pstore/ram.c:409:3: warning: format '%lu' expects type 'long unsigned 
> int', but argument 2 has type 'size_t'
> 
> Signed-off-by: Randy Dunlap 
> Acked-by: Kees Cook 
> Cc: Anton Vorontsov 
> ---
> I posted this patch on June 15 and July 23 but it has not been
> merged anywhere afaict, so I'm sending it directly to the man.

(I believe it's the first time I see that patch.)

Btw, I see no maintainers for the pstore, and it surely no longer
belongs to staging. Tony, I can send patches to you, or I can create
a git tree (actually, I already had it for my own convenience).. So
how about the following patch?

Kees, Colin, as you're also pstore authors, I assume you're interested
in reviewing/[n]acking any possible changes, so I also added you to
the M: entries, is that OK?

- - - -
From: Anton Vorontsov 
Subject: [PATCH] MAINTAINERS: Add pstore maintainers


Signed-off-by: Anton Vorontsov 
---
 MAINTAINERS |   12 
 1 file changed, 12 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 94b823f..9aa40c1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5496,6 +5496,18 @@ L:   cbe-oss-...@lists.ozlabs.org
 S: Maintained
 F: drivers/block/ps3vram.c
 
+PSTORE FILESYSTEM
+M: Anton Vorontsov 
+M: Colin Cross 
+M: Kees Cook 
+M: Tony Luck 
+S: Maintained
+T: git git://git.infradead.org/users/cbou/linux-pstore.git
+F: fs/pstore/
+F: include/linux/pstore*
+F: drivers/firmware/efivars.c
+F: drivers/acpi/apei/erst.c
+
 PTP HARDWARE CLOCK SUPPORT
 M: Richard Cochran 
 S: Maintained
-- 
1.7.10.4

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

Re: [PATCH] regulator: tps6586x: add support for SYS rail

[Mark Brown]

On Thu, Aug 02, 2012 at 10:44:05AM -0600, Stephen Warren wrote:
> On 08/02/2012 05:16 AM, Laxman Dewangan wrote:

> > .desc   = { \
> > +   .supply_name = "sys",   \
> > .name   = "REG-SYS",\
> > .ops= _sys_regulator_ops,  \
> > .type   = REGULATOR_VOLTAGE,\

> BTW, this patch touches both the regulator and MFD trees. I'm not sure
> who will apply it. I think it relies on the patch to this driver Mark
> recently applied in the regulator tree (for 3.7 I think) doesn't it, at
> least for context?

It varies - it's usually whichever tree the change logically belongs in
(so adding a define for a new regulator in the MFD would go with the
rest of the implementation of a new regulator but a change in the
register I/O interface of the core would go via MFD).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Gaming and the kernel

[Chris Jones]

On 04/08/12 10:32, da...@lang.hm wrote:

On Sat, 4 Aug 2012, Chris Jones wrote:


On 04/08/12 08:44, Cruz Julian Bishop wrote:

On 04/08/12 08:12, Chris Jones wrote:
There's a lot of attention at the moment focused toward Linux and 
the future of gaming support on the platform. And it got me 
thinking, is there any particular improvements that are planned to 
improve the kernel from better support for gaming?


It's hard to describe what I mean. Basically, to the outside world 
via media, it is presented as "Valve is taking gaming to Linux. Wow, 
Linux is now capable of gaming!" That's all fine and everything. But 
we need to ensure that the kernel and all other aspects of code under 
our control is up to the task of handling a massive dump of games for 
Linux. Otherwise, it's going to backfire on us and Linux overall. 
It's moving very quickly.


Other than drivers, what problems do you think that the Linux kernel 
has in supporting games?


Drivers are bad due to the video card vendors opting to not provide 
the information needed for them to be good, so while I wish they were 
better, I don't really see anything for the "Linux kernel community" 
to do.


David Lang


Well you are right I guess. There really is nothing technically wrong 
with the kernel in its current state. And there probably isn't really an 
essential to-do list, so to speak. But I guess I know that we know this 
because we're all developers. However, if new gamers move to Linux and 
find they're experience is not the same as their experience was when 
gaming under Windows, then the eventual blame-game will fall back on us. 
The kernel developers. Even though the responsibility lies with video 
card and hardware developers.


I guess I am just a little concerned that it might not be a smooth and 
happy introduction as Valve is making out. However, if Valve handle this 
correctly and provide the gamer community with enough information and 
documentation, hopefully things will work out. And this might actually 
be the kick in the rear-end that AMD and NVIDIA need to get into gear 
and start developer some useful and Windows equivalent hardware drivers 
for ALL their cards for Linux.



Regards

--
Chris Jones @ kernel.devproj...@gmail.com
also on oracle.kernel...@gmail.com and netbsd.kernel...@gmail.com

Ubuntu 12.04 (PC)|Android (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming)
Linux kernel developer|Solaris kernel developer|BSD kernel developer|Lead 
Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web 
Services|Digital Imaging Services
Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 
controller|Logitech Attack 3 j/stick
Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [alsa-devel] [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all subsequent widgets to fail too

[Mark Brown]

On Fri, Aug 03, 2012 at 09:30:10AM +0100, Lee Jones wrote:

> I do agree that it should be correct, but the difference between getting
> it 90% correct and absolutely perfect increases the effort at least x2.
> With so much left to do, I think it would be better to get everything in
> and functioning, then fix the minor issues as we come across them later.

If you're going to do this the usual way is to do it by leaving bits
out, and see below.

> If only it were that easy. We're not bursting at the seems with resources
> here. I'm working in a very customer focused ecosystem. If they don't 
> request it, or file a bug about it, there's no resource allocation to fix

Right, I work in the same industry - but this shouldn't be a problem,
if it's not urgent for people to help it's probably not urgent to do
whatever's blocked by it either.

> > You're not telling us about the problems you see so it's very difficult
> > for anyone to help you.

> > For example with this patch the only information you've sent is the
> > patch and the fact that you're seeing the error you're ignoring going
> > off on the system you're working with (which I had to ask to find out

> I only went off what I knew. Some objects (which wouldn't have
> prevented playing audio) were failing. It seemed wrong to shut down the
> entire audio system because for instance, 'headset mute' or the 'vibrator'
> links were broken. As I said to you before, time is a big factor and I
> have a massive TODO list. Fixing audio links a) isn't my subject of

This isn't the point, and it's a *very* important point which is the
main reason I'm replying here.

The immediate point here is that you're not communicating about what
you're trying to which is the source of a lot of problems.  Things would
run a lot more smoothly if when you try to cut corners you were explicit
about the corners you cut, and if when you run into problems you report
those problems as well as sending whatever code you're using to work
around things.  Set people's expecations about what they're seeing and
provide them with context.

Consider the patch that's in the subject line here - it took me a couple
of goes before you even said you'd seen an issue on your system which
you were working around (I still don't know what the actual errors are).
As far as I could tell looking at the patch description it was something
done for taste reasons which was being sent as a bug fix.

The usual approach for things like this is a changelog or cover mail
which says something like "I'm seeing this error, here's the code I'm
using to get things working on my system and I think this is a good idea
because..." (or "...but that can't be right", or whatever).  This works
a whole lot better, it makes it clear what the underlying motivation for
the change is and understand the submitter's expecation for the quality
of the patch.

Similarly with the missing device tree binding documentation, had you
said something about the patches not being complete and writing the
binding documentation later that'd have helped a lot.  Having it there
is a basic checklist thing for new DT bindings which is easy to spot
from a diffstat, it's really not something a reviewer should ever need
to ask about especially from someone doing a lot of DT work and it's a
big red flag for the quality of the code.

Things like this are really important, especially for people doing lots
of work, as they have such a big impact on communication and so much of
what makes this thing tick is about communication.

> expertise, so it would take me much longer to fix than someone with
> a good knowledge of the system and b) isn't really my responsibility.

That's fine, just tell people about the problem and move on to
something else from what's probably a large task list if it's blocking
you (and start nagging people if it doesn't get fixed and it seems
important).  This happens fairly often, it works well most of the time.
Sending a fix is of course ideal but it's not essential.

> Well I know my submissions are not always 100% perfect, but I hope 
> you're not implying that they're poor quality. Writing code and fixing
> things you view as bugs in code you have no prior knowledge of isn't the 

This is process stuff more than code stuff, it's all about communication.

> easiest task in the world. All I can do is attempt to fix the issues that
> I see, which get things off the ground or make drivers work again and
> submit the changes. If they're wrong they're wrong, but I don't think this
> should be viewed as poor quality code!

What you can do here is to commmunicate about what you're doing more.
Don't just think about the code, think about the communication
surrounding the code - this is the core of the issue.

> the experience. Some Maintainers say things like, "That's wrong. This
> is wrong. Why are you doing this?" etc without explaining what the
> issues are. That's not a good review, and will put people off trying
> again.

Like I 

[PATCH] cris: fix eth_v10.c build error

[Randy Dunlap]

From: Randy Dunlap 

Fix build error on cris (not tested, no toolchain here):

drivers/net/cris/eth_v10.c: error: too many arguments to function 
'e100rxtx_interrupt'

Reported-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Mikael Starvik 
Cc: Jesper Nilsson 
Cc: linux-cris-ker...@axis.com
---
 drivers/net/cris/eth_v10.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-36-rc1.orig/drivers/net/cris/eth_v10.c
+++ lnx-36-rc1/drivers/net/cris/eth_v10.c
@@ -1712,7 +1712,7 @@ e100_set_network_leds(int active)
 static void
 e100_netpoll(struct net_device* netdev)
 {
-   e100rxtx_interrupt(NETWORK_DMA_TX_IRQ_NBR, netdev, NULL);
+   e100rxtx_interrupt(NETWORK_DMA_TX_IRQ_NBR, netdev);
 }
 #endif
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/2] I2C: SIS964: Bus driver

[Amaury Decrême]

> There's nothing confusing, drivers supporting several devices are
> legion. If the devices are really almost compatible, reusing an
> existing driver is the way to go.

With that in mind, here is an alpha preview of what the patch will
look like if SIS964 support is added in i2c-sis630.


diff --git a/drivers/i2c/busses/i2c-sis630.c b/drivers/i2c/busses/i2c-sis630.c
index 5d6723b..861d58b 100644
--- a/drivers/i2c/busses/i2c-sis630.c
+++ b/drivers/i2c/busses/i2c-sis630.c
@@ -33,6 +33,8 @@
Fixed logical error by restoring of Host Master Clock
31.07.2003
Added block data read/write support.
+   03.08.2012
+   Added support of SiS964 - Amaury Decrême 
 */

 /*
@@ -41,6 +43,7 @@
Supports:
SIS 630
SIS 730
+   SIS 964

Note: we assume there can only be one device, with one SMBus interface.
 */
@@ -55,22 +58,22 @@
 #include 
 #include 

+/* SIS964 id, defined here as we are the only file using it */
+#define PCI_DEVICE_ID_SI_964   0x0964
+
 /* SIS630 SMBus registers */
-#define SMB_STS0x80/* status */
-#define SMB_EN 0x81/* status enable */
-#define SMB_CNT0x82
-#define SMBHOST_CNT0x83
-#define SMB_ADDR   0x84
-#define SMB_CMD0x85
-#define SMB_PCOUNT 0x86/* processed count */
-#define SMB_COUNT  0x87
-#define SMB_BYTE   0x88/* ~0x8F data byte field */
-#define SMBDEV_ADDR0x90
-#define SMB_DB00x91
-#define SMB_DB10x92
-#define SMB_SAA0x93
-
-/* register count for request_region */
+#define SMB_STS0x00 + offset   /* status */
+#define SMB_CNT0x02 + offset   /* control */
+#define SMBHOST_CNT0x03 + offset   /* host control */
+#define SMB_ADDR   0x04 + offset   /* address */
+#define SMB_CMD0x05 + offset   /* command */
+#define SMB_COUNT  0x07 + offset   /* byte count */
+#define SMB_BYTE   0x08 + offset   /* ~0x8F data byte field */
+#define SMB_SAA0x13 + offset   /* host slave
alias address */
+
+/* register count for request_region
+ * As we don't use SMB_PCOUNT 20 is ok for SiS630 and SiS964
+ */
 #define SIS630_SMB_IOREGION20

 /* PCI address constants */
@@ -107,9 +110,13 @@ static unsigned short acpi_base;
 static int supported[] = {
PCI_DEVICE_ID_SI_630,
PCI_DEVICE_ID_SI_730,
+   PCI_DEVICE_ID_SI_964,
0 /* terminates the list */
 };

+/* SMB registers offset */
+static int offset;
+
 static inline u8 sis630_read(u8 reg)
 {
return inb(acpi_base + reg);
@@ -412,6 +419,10 @@ static int __devinit sis630_setup(struct pci_dev
*sis630_dev)
return -ENODEV;
}

+   if (supported[i] == PCI_DEVICE_ID_SI_964)
+   offset = 0xE0;
+   else
+   offset = 0x80;
/*
   Enable ACPI first , so we can accsess reg 74-75
   in acpi io space and read acpi base addr
@@ -474,6 +485,7 @@ static struct i2c_adapter sis630_adapter = {

 static DEFINE_PCI_DEVICE_TABLE(sis630_ids) = {
{ PCI_DEVICE(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_503) },
+   { PCI_DEVICE(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_964) },
{ PCI_DEVICE(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_LPC) },
{ 0, }
 };
@@ -482,6 +494,7 @@ MODULE_DEVICE_TABLE (pci, sis630_ids);

 static int __devinit sis630_probe(struct pci_dev *dev, const struct
pci_device_id *id)
 {
+   dev_dbg(>dev, "salut");
if (sis630_setup(dev)) {
dev_err(>dev, "SIS630 comp. bus not detected,
module not inserted.\n");
return -ENODEV;


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

Re: [PATCH] scripts/get_maintainer.pl: Default to --no-rolestats when output not a terminal

[Joe Perches]

On Fri, 2012-08-03 at 11:47 -0700, Josh Triplett wrote:
> On Fri, Aug 03, 2012 at 11:33:21AM -0700, Joe Perches wrote:
> > On Fri, 2012-08-03 at 11:27 -0700, Josh Triplett wrote:
> > > scripts/get_maintainer.pl defaults to showing --rolestats, which
> > > provides annotations explaining why each person or list might want to
> > > know about a patch.  This works well for interactive use, but breaks
> > > when used with git send-email's --to-cmd or --cc-cmd, resulting in
> > > malformed email headers and mails sent to some but not all recipients.
> > > 
> > > To avoid the need to explicitly pass --no-rolestats for batch use,
> > > enable --rolestats by default only when outputting to a terminal.
> > 
> > Hi Josh.
> > 
> > I think it's preferable to add --no-rolestats
> > to the uses that need them.
> 
> Why?
> 
> > I have different scripts that I use for git send-email
> > options --to-cmd and --cc-cmd
> [...snip scripts...]
> 
> You've submitted enough patches that you've automated as much of the
> process as you can; I don't think that makes the defaults less
> error-prone.

I think the default use of the get_maintainer script is
actually not scripted but interactive, where the user is
just trying to figure out who the maintainer is.

Anyone using get_maintainer in a scripted way should go
through the effort of figuring out in advance who will
be a recipient.

>   Given that you've had to explicitly add --no-rolestats to
> your scripts, that seems like evidence in *favor* of making this change.

Probably not.

> As it stands now, the current default of --rolestats makes the obvious
> command line of
> git send-email --to-cmd='scripts/get_maintainer.pl' *.patch
> send broken emails that go to some maintainers but not all.  I think it
> makes sense to change the default so that the obvious usage becomes the
> correct one.

There were some discussions awhile back in 2010 about the
preferred defaults.

Perhaps you can read those discussions about why the default
is the way it is.

cheers, Joe

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

Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Sasha Levin]

On 08/04/2012 02:05 AM, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 5:03 PM, Sasha Levin  wrote:
>>
>> The problem with that code was that it doesn't work with dynamically 
>> allocated hashtables, or hashtables that grow/shrink.
> 
> Sure. But once you have that kind of complexity, why would you care
> about the trivial cases?

Because there are far more trivial cases than complex ones - I've counted 50+ 
of these "trivial" cases.

None of them need the complexity we're trying to deal with at the moment.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Gaming and the kernel

[david]

On Sat, 4 Aug 2012, Chris Jones wrote:


On 04/08/12 08:44, Cruz Julian Bishop wrote:

On 04/08/12 08:12, Chris Jones wrote:
There's a lot of attention at the moment focused toward Linux and the 
future of gaming support on the platform. And it got me thinking, is there 
any particular improvements that are planned to improve the kernel from 
better support for gaming?


It's hard to describe what I mean. Basically, to the outside world via media, 
it is presented as "Valve is taking gaming to Linux. Wow, Linux is now 
capable of gaming!" That's all fine and everything. But we need to ensure 
that the kernel and all other aspects of code under our control is up to the 
task of handling a massive dump of games for Linux. Otherwise, it's going to 
backfire on us and Linux overall. It's moving very quickly.


Other than drivers, what problems do you think that the Linux kernel has 
in supporting games?


Drivers are bad due to the video card vendors opting to not provide the 
information needed for them to be good, so while I wish they were better, 
I don't really see anything for the "Linux kernel community" to do.


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

[Chris Jones]

On 04/08/12 08:44, Cruz Julian Bishop wrote:

On 04/08/12 08:12, Chris Jones wrote:
There's a lot of attention at the moment focused toward Linux and the 
future of gaming support on the platform. And it got me thinking, is 
there any particular improvements that are planned to improve the 
kernel from better support for gaming?



Regards


Hi Chris,

The biggest problem I can see at the moment is supporting dual-GPU 
setups in unusual ways.


For example, NVIDIA Optimus uses an Intel Core i* processor and 
integrated Intel 3/4000 graphics,
but also has a NVIDIA GeForge GT *M graphics card. However, this card 
cannot be accessed
directly, and all instructions effectively pass through the Intel 
graphics system.


I'm not entirely sure how that works, but it's what I've managed to 
gather from some tinkering.
It's being worked on at the moment (RandR 1.(5? 6? 7?) and DMA-BUF 
PRIME) - Which is good,
since the majority of laptops that I have seen being sold in my area 
either use NVIDIA

Optimus or some other similar system if they cost under $1000 or so.

Until these are implemented, there is no way for the kernel to access 
the dedicated graphics
card on these systems. There is, however, a project (Bumblebee) that 
seems to be doing
a good job performance-wise, but doesn't support automatic switching 
to the dedicated

graphics card.



On another note, not kernel based, Wine has actually managed to run
Grand Theft Auto: San Andreas faster on Ubuntu 12.04 than the default 
Windows 7
installation on this laptop. Valve has also committed to developing 
games on Linux
(starting with Ubuntu) with frame rates that, so far, have been higher 
than on Windows.


I guess we'll just have to wait and see what happens. There are a 
couple of things (some

of which are major, but thankfully not impossible)


It just seems to me that Valve is pressing ahead with games for Linux 
and no doubt there will be another influx of games and companies to 
follow not far behind if Valve make it a running success. And good luck 
to them. But on the other hand, it seems that kernel development is not 
quite up to scratch yet when it comes to full support for hardware 
graphics. And bring drivers in to the mix. Albeit, I do understand that 
graphics drivers should be handled and worked on by AMD and NVIDIA etc.


It's hard to describe what I mean. Basically, to the outside world via 
media, it is presented as "Valve is taking gaming to Linux. Wow, Linux 
is now capable of gaming!" That's all fine and everything. But we need 
to ensure that the kernel and all other aspects of code under our 
control is up to the task of handling a massive dump of games for Linux. 
Otherwise, it's going to backfire on us and Linux overall. It's moving 
very quickly.



Regards

--
Chris Jones @ kernel.devproj...@gmail.com
also on oracle.kernel...@gmail.com and netbsd.kernel...@gmail.com

Ubuntu 12.04 (PC)|Android (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming)
Linux kernel developer|Solaris kernel developer|BSD kernel developer|Lead 
Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web 
Services|Digital Imaging Services
Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 
controller|Logitech Attack 3 j/stick
Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox

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

Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Linus Torvalds]

On Fri, Aug 3, 2012 at 5:03 PM, Sasha Levin  wrote:
>
> The problem with that code was that it doesn't work with dynamically 
> allocated hashtables, or hashtables that grow/shrink.

Sure. But once you have that kind of complexity, why would you care
about the trivial cases?

 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: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Tejun Heo]

Hello,

On Fri, Aug 03, 2012 at 04:47:47PM -0700, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo  wrote:
> >
> > I suppose you mean unsized.  I remember this working.  Maybe I'm
> > confusing it with zero-sized array.  Hmm... gcc doesn't complain about
> > the following.  --std=c99 seems happy too.
> 
> Ok, I'm surprised, but maybe it's supposed to work if you do it inside
> another struct like that, exactly so that you can preallocate things..

Yeah, I think the rule is var array should be the last member of any
given struct definition.  Once a struct is defined, its alignment and
size are fixed and it behaves like any other struct.

> Or maybe it's just a gcc bug. I do think this all is way hackier than
> Sasha's original simple code that didn't need these kinds of games,
> and didn't need a size member at all.
> 
> I really think all the extra complexity and overhead is just *bad*.
> The first simple version was much nicer and likely generated better
> code too.

The size member could have performance impact in extreme cases.  If
we're looking for something simple & fast, maybe just pass in @size as
argument and be done with it?

Thanks.

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

[PATCH] pstore: fix printk format warning

[Randy Dunlap]

From: Randy Dunlap 

Fix printk format warning (on i386) in pstore:

fs/pstore/ram.c:409:3: warning: format '%lu' expects type 'long unsigned int', 
but argument 2 has type 'size_t'

Signed-off-by: Randy Dunlap 
Acked-by: Kees Cook 
Cc: Anton Vorontsov 
---
I posted this patch on June 15 and July 23 but it has not been
merged anywhere afaict, so I'm sending it directly to the man.

 fs/pstore/ram.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-36-rc1.orig/fs/pstore/ram.c
+++ lnx-36-rc1/fs/pstore/ram.c
@@ -406,7 +406,7 @@ static int __devinit ramoops_probe(struc
goto fail_init_fprz;
 
if (!cxt->przs && !cxt->cprz && !cxt->fprz) {
-   pr_err("memory size too small, minimum is %lu\n",
+   pr_err("memory size too small, minimum is %zu\n",
cxt->console_size + cxt->record_size +
cxt->ftrace_size);
goto fail_cnt;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Sasha Levin]

Hi Linus,

On 08/04/2012 01:47 AM, Linus Torvalds wrote:
> Or maybe it's just a gcc bug. I do think this all is way hackier than
> Sasha's original simple code that didn't need these kinds of games,
> and didn't need a size member at all.
> 
> I really think all the extra complexity and overhead is just *bad*.
> The first simple version was much nicer and likely generated better
> code too.

The problem with that code was that it doesn't work with dynamically allocated 
hashtables, or hashtables that grow/shrink.

The alternative to going down this path, is going back to the old code and 
saying that it only works for the simple case, and if you're interested in 
something more complex it should have it's own different implementation.

Does it make sense? We'll keep the simple & common case simple, and let anyone 
who needs something more complex than this write it as an extension?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] isdnloop: fix and simplify isdnloop_init()

[David Miller]

From: Fengguang Wu 
Date: Fri, 3 Aug 2012 17:10:01 +0800

> Fix a buffer overflow bug by removing the revision and printk.
> 
> [   22.016214] isdnloop-ISDN-driver Rev 1.11.6.7 
> [   22.097508] isdnloop: (loop0) virtual card added
> [   22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is 
> corrupted in: 83244972
> [   22.174400] 
> [   22.436157] Pid: 1, comm: swapper Not tainted 
> 3.5.0-bisect-00018-gfa8bbb1-dirty #129
> [   22.624071] Call Trace:
> [   22.720558]  [] ? CallcNew+0x56/0x56
> [   22.815248]  [] panic+0x110/0x329
> [   22.914330]  [] ? isdnloop_init+0xaf/0xb1
> [   23.014800]  [] ? CallcNew+0x56/0x56
> [   23.090763]  [] __stack_chk_fail+0x2b/0x30
> [   23.185748]  [] isdnloop_init+0xaf/0xb1
> 
> Signed-off-by: Fengguang Wu 

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

Re: [PATCH net-next,1/1] hyperv: Move wait completion msg code into rndis_filter_halt_device()

[David Miller]

From: Haiyang Zhang 
Date: Fri,  3 Aug 2012 12:32:18 -0700

> We need to wait for send_completion msg before put_rndis_request() at
> the end of rndis_filter_halt_device(). Otherwise, netvsc_send_completion()
> may reference freed memory which is overwritten, and cause panic.
> 
> Reported-by: Long Li 
> Reported-by: Jason Wang 
> Signed-off-by: Haiyang Zhang 

This is a bug fix, so applied to 'net'.  Please target your patches
properly.

Don't just be afraid that I'll reject the patch if you target it
at 'net', and therefore just target everything at 'net-next'.  That
is certainly worse.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 pcmcia bug - unable to map card memory on old laptops

[Yinghai Lu]

On Fri, Aug 3, 2012 at 2:53 PM, Piotr Gluszenia Slawinski
 wrote:
>>> bug is present in all kernels since late 2.6.36
>>
>>
>> can you send the boot log with working and not working kernel?
>> Please make sure you have PCI_DEBUG set in your config.
>
>
> system is ISA based :) but i've enabled it for sake of clarity.

Good.

>
> logs are attached both systems are 3.5 kernel, working is one where i've
> simply commented out the code preventing low mem allocation in resource.c
>
> btw. note that if i would enable pci support in older kernels
> bug would most likely resurface even there.

pcmcia :: nonstatic_find_mem_region
do try to allocate mem under 1M.

should replace
arch_remove_reservations()

with reserve resource in iomem resource tree if needed for some platform.

current arch_remove_reservations keep clip the with e820 table.

also there are two local resource_clip have different meaning. one is
"include" and another one is "exclude"

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: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Linus Torvalds]

On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo  wrote:
>
> I suppose you mean unsized.  I remember this working.  Maybe I'm
> confusing it with zero-sized array.  Hmm... gcc doesn't complain about
> the following.  --std=c99 seems happy too.

Ok, I'm surprised, but maybe it's supposed to work if you do it inside
another struct like that, exactly so that you can preallocate things..

Or maybe it's just a gcc bug. I do think this all is way hackier than
Sasha's original simple code that didn't need these kinds of games,
and didn't need a size member at all.

I really think all the extra complexity and overhead is just *bad*.
The first simple version was much nicer and likely generated better
code too.

   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] emulex: benet: Add a missing CR in the end of message

[David Miller]

From: Masanari Iida 
Date: Fri,  3 Aug 2012 21:36:51 +0900

> Missing a CR in printk causes 2 messages printed in one line.
> 
> Signed-off-by: Masanari Iida 

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

Re: pull request: wireless 2012-08-03

[David Miller]

From: "John W. Linville" 
Date: Fri, 3 Aug 2012 10:56:04 -0400

> This request covers a batch of fixes intended for the 3.6 stream.

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

Re: [PATCH v2] tmscsim: spin_unlock_irq in interrupt handler fix

[Guennadi Liakhovetski]

On Tue, 31 Jul 2012, Denis Efremov wrote:

> The replacement of spin_lock_irq/spin_unlock_irq pairs which
> can be called from interrupt handler by irqsave/irqrestore
> versions.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Denis Efremov 

Acked-by: Guennadi Liakhovetski 

Note: I didn't test this. I still have a dc390 card in my PC, so, I could 
test it, but I haven't yet got time for this and I'll be away the next 
week. The patch looks correct and safe. If it does break anything, well, 
we'll get to know about that sooner or later...

Thanks
Guennadi

> ---
>  drivers/scsi/tmscsim.c |   12 ++--
>  drivers/scsi/tmscsim.h |1 +
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c
> index a1baccc..e9b7148 100644
> --- a/drivers/scsi/tmscsim.c
> +++ b/drivers/scsi/tmscsim.c
> @@ -665,7 +665,7 @@ DC390_Interrupt(void *dev_id)
>  //dstatus = DC390_read8 (DMA_Status);
>  //DC390_write32 (DMA_ScsiBusCtrl, EN_INT_ON_PCI_ABORT);
>  
> -spin_lock_irq(pACB->pScsiHost->host_lock);
> +spin_lock_irqsave(pACB->pScsiHost->host_lock, pACB->hlock_flags);
>  
>  istate = DC390_read8 (Intern_State);
>  istatus = DC390_read8 (INT_Status); /* This clears Scsi_Status, 
> Intern_State and INT_Status ! */
> @@ -736,7 +736,7 @@ DC390_Interrupt(void *dev_id)
>  }
>  
>   unlock:
> -spin_unlock_irq(pACB->pScsiHost->host_lock);
> +spin_unlock_irqrestore(pACB->pScsiHost->host_lock, pACB->hlock_flags);
>  return IRQ_HANDLED;
>  }
>  
> @@ -771,9 +771,9 @@ dc390_DataOut_0(struct dc390_acb* pACB, struct dc390_srb* 
> pSRB, u8 *psstatus)
>   /* Function called from the ISR with the host_lock held and 
> interrupts disabled */
>   if (pSRB->SGToBeXferLen)
>   while (time_before(jiffies, timeout) && !((dstate = DC390_read8 
> (DMA_Status)) & DMA_XFER_DONE)) {
> - spin_unlock_irq(pACB->pScsiHost->host_lock);
> + spin_unlock_irqrestore(pACB->pScsiHost->host_lock, 
> pACB->hlock_flags);
>   udelay(50);
> - spin_lock_irq(pACB->pScsiHost->host_lock);
> + spin_lock_irqsave(pACB->pScsiHost->host_lock, 
> pACB->hlock_flags);
>   }
>   if (!time_before(jiffies, timeout))
>   printk (KERN_CRIT "DC390: Deadlock in DataOut_0: DMA aborted 
> unfinished: %06x bytes remain!!\n",
> @@ -830,9 +830,9 @@ dc390_DataIn_0(struct dc390_acb* pACB, struct dc390_srb* 
> pSRB, u8 *psstatus)
>   /* Function called from the ISR with the host_lock held and 
> interrupts disabled */
>   if (pSRB->SGToBeXferLen)
>   while (time_before(jiffies, timeout) && !((dstate = DC390_read8 
> (DMA_Status)) & DMA_XFER_DONE)) {
> - spin_unlock_irq(pACB->pScsiHost->host_lock);
> + spin_unlock_irqrestore(pACB->pScsiHost->host_lock, 
> pACB->hlock_flags);
>   udelay(50);
> - spin_lock_irq(pACB->pScsiHost->host_lock);
> + spin_lock_irqsave(pACB->pScsiHost->host_lock, 
> pACB->hlock_flags);
>   }
>   if (!time_before(jiffies, timeout)) {
>   printk (KERN_CRIT "DC390: Deadlock in DataIn_0: DMA aborted 
> unfinished: %06x bytes remain!!\n",
> diff --git a/drivers/scsi/tmscsim.h b/drivers/scsi/tmscsim.h
> index 77adc54..3f9ea2b 100644
> --- a/drivers/scsi/tmscsim.h
> +++ b/drivers/scsi/tmscsim.h
> @@ -107,6 +107,7 @@ u8SyncOffset; /*;for reg. and 
> nego.(low nibble) */
>  struct dc390_acb
>  {
>  struct Scsi_Host *pScsiHost;
> +unsigned long hlock_flags;
>  u16  IOPortBase;
>  u8   IRQLevel;
>  u8   status;
> -- 
> 1.7.7
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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/

[PATCH/TRIVIAL] ARM: Drop duplicate select for GENERIC_IRQ_PROBE

[Stephen Boyd]

Seems that Thomas' and my patches collided during the last merge
window.

Signed-off-by: Stephen Boyd 
---
 arch/arm/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cd..b528d04 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -38,7 +38,6 @@ config ARM
select HARDIRQS_SW_RESEND
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
-   select GENERIC_IRQ_PROBE
select ARCH_WANT_IPC_PARSE_VERSION
select HARDIRQS_SW_RESEND
select CPU_PM if (SUSPEND || CPU_IDLE)
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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

[Pandita, Vikram]

On Fri, Aug 3, 2012 at 3:36 PM, Greg KH  wrote:
> On Fri, Aug 03, 2012 at 03:25:17PM -0700, Pandita, Vikram wrote:
>> >> This was something that got used internally and helped at times.
>> >
>> > Could you have used the trace point instead?
>>
>> As i understood the trace_prink(), one would need to modify existing
>> printk -> trace_printk. Is my understanding correct?
>
> No, you should just be able to watch the tracepoint, right?

yes.
Assumption being you know _EXACTLY_ what code piece to watch for.
Which may not be the case all times.

>
>> Most of the times the problem exhibits as a random hang, without having a 
>> clue
>> which code to modify. That time one generic defconfig global switch is
>> your first tool.
>>
>> Other issue i found, using this patch, that on multi-core ARM systems,
>> almost 99% of times, IRQ's are handled by CPU0,
>> even if CPU0 was really busy and other CPU's were free. I am yet to
>> understand a good reason why.
>
> Can't you see that from /proc/interrupts today?

You are right that was the next step i did and that shows the problem as well.
The point i was trying to make, with printk showing cpu-id, there are
problems in system that could get highlighted,
given printk almost always runs with linux kernel.

>
>> this patch also helped in other areas as mentioned in the thread
>> http://marc.info/?l=linux-omap=134401269106619=2
>
> I still don't understand how adding the cpu number to printk enabled you
> to find any problem like this.  Can't you just add the cpu number to the
> printk messages you care about for your specific hardware?
>

The assumption here is that a developer knows well enough, which code
to modify for logging.
I my experience, that is not true most of the times. A global
defconfig switch is much easier to enable.

Eg: when i have some timing related issue, first thing i go for is to
enable PRINTK_TIME, without even
having to think about the erring code. Then time-stamps lead to bad code.

That is the same though process behind the cpu-id in printk.


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

[Cruz Julian Bishop]

Sorry, had to send this again so it could go to the mailing list. I 
accidentally replied to you personally :\


On 04/08/12 08:12, Chris Jones wrote:
There's a lot of attention at the moment focused toward Linux and the 
future of gaming support on the platform. And it got me thinking, is 
there any particular improvements that are planned to improve the 
kernel from better support for gaming?



Regards


Hi Chris,

The biggest problem I can see at the moment is supporting dual-GPU 
setups in unusual ways.


For example, NVIDIA Optimus uses an Intel Core i* processor and 
integrated Intel 3/4000 graphics,
but also has a NVIDIA GeForge GT *M graphics card. However, this card 
cannot be accessed
directly, and all instructions effectively pass through the Intel 
graphics system.


I'm not entirely sure how that works, but it's what I've managed to 
gather from some tinkering.
It's being worked on at the moment (RandR 1.(5? 6? 7?) and DMA-BUF 
PRIME) - Which is good,
since the majority of laptops that I have seen being sold in my area 
either use NVIDIA

Optimus or some other similar system if they cost under $1000 or so.

Until these are implemented, there is no way for the kernel to access 
the dedicated graphics
card on these systems. There is, however, a project (Bumblebee) that 
seems to be doing
a good job performance-wise, but doesn't support automatic switching to 
the dedicated

graphics card.



On another note, not kernel based, Wine has actually managed to run
Grand Theft Auto: San Andreas faster on Ubuntu 12.04 than the default 
Windows 7
installation on this laptop. Valve has also committed to developing 
games on Linux
(starting with Ubuntu) with frame rates that, so far, have been higher 
than on Windows.


I guess we'll just have to wait and see what happens. There are a couple 
of things (some

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

[PATCH] ARM: Don't enable GENERIC_LOCKBREAK with ticket spinlocks

[Stephen Boyd]

Now that ARM has implemented its spinlocks with tickets we don't
need to use the generic lockbreak algorithm. Remove the Kconfig
from ARM so that we use the arch_spin_is_contended() definition
from the asm header. This also saves a word in each lock because
we don't need the break_lock member anymore.

Signed-off-by: Stephen Boyd 
---

It seems we define the arch_spin_is_contended() macro but we don't
use it on SMP && PREEMPT kernels?

 arch/arm/Kconfig | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cd..e4191cc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -126,11 +126,6 @@ config TRACE_IRQFLAGS_SUPPORT
bool
default y
 
-config GENERIC_LOCKBREAK
-   bool
-   default y
-   depends on SMP && PREEMPT
-
 config RWSEM_GENERIC_SPINLOCK
bool
default y
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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

Re: [PATCH V2] regulator: tps6586x: add support for SYS rail

[Mark Brown]

On Fri, Aug 03, 2012 at 11:29:56AM +0530, Laxman Dewangan wrote:
> Device have SYS rail which is always ON. It is system
> power bus. LDO5 and LDO_RTC get powered through this rail
> internally. Add support for this rail and make the
> LDO5/LDO_RTC input supply to "sys".
> Update document accordingly.

This doesn't apply against current code, please regenerate.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Tejun Heo]

On Fri, Aug 03, 2012 at 03:29:10PM -0700, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 3:23 PM, Tejun Heo  wrote:
> >
> > I actually meant an enclosing struct.  When you're defining a struct
> > member, simply putting the storage after a struct with var array
> > should be good enough.  If that doesn't work, quite a few things in
> > the kernel will break.
> 
> The unsigned member of a struct has to be the last one, so your struct
> won't work.

I suppose you mean unsized.  I remember this working.  Maybe I'm
confusing it with zero-sized array.  Hmm... gcc doesn't complain about
the following.  --std=c99 seems happy too.

  #include 

  struct A {
  int i;
  long ar[];
  };

  struct B {
  struct A a;
  long ar_storage[32];
  };

  int main(void)
  {
  printf("sizeof(A)=%zd sizeof(B)=%zd\n", sizeof(struct A), 
sizeof(struct B));
  return 0;
  }

$ ./a.out
sizeof(A)=8 sizeof(B)=264

-- 
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 v3] printk: add option to print cpu id

[Greg KH]

On Fri, Aug 03, 2012 at 03:25:17PM -0700, Pandita, Vikram wrote:
> >> This was something that got used internally and helped at times.
> >
> > Could you have used the trace point instead?
> 
> As i understood the trace_prink(), one would need to modify existing
> printk -> trace_printk. Is my understanding correct?

No, you should just be able to watch the tracepoint, right?

> Most of the times the problem exhibits as a random hang, without having a clue
> which code to modify. That time one generic defconfig global switch is
> your first tool.
> 
> Other issue i found, using this patch, that on multi-core ARM systems,
> almost 99% of times, IRQ's are handled by CPU0,
> even if CPU0 was really busy and other CPU's were free. I am yet to
> understand a good reason why.

Can't you see that from /proc/interrupts today?

> this patch also helped in other areas as mentioned in the thread
> http://marc.info/?l=linux-omap=134401269106619=2

I still don't understand how adding the cpu number to printk enabled you
to find any problem like this.  Can't you just add the cpu number to the
printk messages you care about for your specific hardware?

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

Re: [RESEND PATCH 0/5 V2] x86: mce: Bugfixes, cleanups and a new CMCI poll version

[Luck, Tony]

I applied this series on top of v3.6-rc1 and took it for
a test drive with a little storm of 20 corrected interrupts.

The series worked ... but the console log was entirely unhelpful
in letting me know what had just happened to my system.  All I saw
was:

mce: [Hardware Error]: Machine check events logged
mce: [Hardware Error]: Machine check events logged
... several seconds pass ...
CPU 35 MCA banks CMCI:0 CMCI:1 CMCI:3 CMCI:5 CMCI:6 CMCI:7 CMCI:8 CMCI:9 
CMCI:10 CMCI:11
mce_notify_irq: 3 callbacks suppressed
CPU 1 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 39 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 38 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 32 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 37 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 36 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 34 MCA banks CMCI:0 CMCI:1 CMCI:3
mce: [Hardware Error]: Machine check events logged

No mention of the storm, no mention that we switched to polling
mode (and so missed some of the reports). Just the cryptic output
as the kernel re-established the CMCI on processors that had been
affected by the storm.

I tried the patch below to log the start/end of the storm. But I
may be doing something wrong with printk_timed_ratelimit() because
I saw two "storm detected" and two "storm subsided" messages.

It would also be nice to avoid all the "CPU 1 MCA banks CMCI:0 CMCI:1 CMCI:3"
messages.

-Tony

diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c 
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index 693bc7d..236f60e 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -87,6 +87,8 @@ void mce_intel_hcpu_update(unsigned long cpu)
 
 unsigned long mce_intel_adjust_timer(unsigned long interval)
 {
+   static unsigned long jiffie_state;
+
if (interval < CMCI_POLL_INTERVAL)
return interval;
 
@@ -108,6 +110,8 @@ unsigned long mce_intel_adjust_timer(unsigned long interval)
 */
if (!atomic_read(_storm_on_cpus)) {
__this_cpu_write(cmci_storm_state, CMCI_STORM_NONE);
+   if (printk_timed_ratelimit(_state, 
CMCI_STORM_INTERVAL/HZ*1000))
+   pr_notice("CMCI storm subsided, switching to 
interrupt mode\n");
cmci_reenable();
cmci_recheck();
}
@@ -126,6 +130,7 @@ static bool cmci_storm_detect(void)
unsigned int cnt = __this_cpu_read(cmci_storm_cnt);
unsigned long ts = __this_cpu_read(cmci_time_stamp);
unsigned long now = jiffies;
+   static unsigned long jiffie_state;
 
if (__this_cpu_read(cmci_storm_state) != CMCI_STORM_NONE)
return true;
@@ -145,6 +150,9 @@ static bool cmci_storm_detect(void)
__this_cpu_write(cmci_storm_state, CMCI_STORM_ACTIVE);
atomic_inc(_storm_on_cpus);
mce_timer_kick(CMCI_POLL_INTERVAL);
+
+   if (printk_timed_ratelimit(_state, CMCI_STORM_INTERVAL/HZ*1000))
+   pr_notice("CMCI storm detected, switching to poll mode\n");
return true;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Linus Torvalds]

On Fri, Aug 3, 2012 at 3:23 PM, Tejun Heo  wrote:
>
> I actually meant an enclosing struct.  When you're defining a struct
> member, simply putting the storage after a struct with var array
> should be good enough.  If that doesn't work, quite a few things in
> the kernel will break.

The unsigned member of a struct has to be the last one, so your struct
won't work.

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: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Sasha Levin]

On 08/04/2012 12:23 AM, Tejun Heo wrote:
> Hello,
> 
> On Sat, Aug 04, 2012 at 12:20:02AM +0200, Sasha Levin wrote:
>> On 08/03/2012 11:48 PM, Tejun Heo wrote:
>>> On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
 I forgot to comment on that one, sorry.

 If we put hash entries after struct hash_table we don't take the
 bits field size into account, or did I miss something?
>>>
>>> So, if you do the following,
>>>
>>> struct {
>>> struct {
>>> int i;
>>> long ar[];
>>> } B;
>>> long __ar_storage[32];
>>> } A;
>>
>> struct A should have been an union, right?
> 
> I actually meant an enclosing struct.  When you're defining a struct
> member, simply putting the storage after a struct with var array
> should be good enough.  If that doesn't work, quite a few things in
> the kernel will break.

Ah, I see, I've missed that part.

Thanks!

> Thanks.
> 

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

Re: [PATCH v3] printk: add option to print cpu id

[Pandita, Vikram]

On Fri, Aug 3, 2012 at 3:13 PM, Greg KH  wrote:
> On Fri, Aug 03, 2012 at 03:07:39PM -0700, Pandita, Vikram wrote:
>> On Fri, Aug 3, 2012 at 2:59 PM, Greg KH  wrote:
>> > On Fri, Aug 03, 2012 at 02:24:20PM -0700, Pandita, Vikram wrote:
>> >> Aaro
>> >>
>> >> On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen  
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote:
>> >> >> > And really: Wasting 1/3 of the 80 character line is too much.
>> >> >>
>> >> >> You _WASTE_ 4 chars only if you are interested in this info by
>> >> >> enabling: CONFIG_PRINTK_CPUID
>> >> >
>> >> > I guess you waste 4 + 3 chars? You could optimize the length by checking
>> >> > CONFIG_NR_CPUS?
>> >>
>> >> Good point.
>> >> Looks there is a variable 'nr_cpu_ids' that could be used as well.
>> >>
>> >> If there is general consensus that the patch can help the arm
>> >> community, and others in general,
>> >> this optimization should be easy to implement - saving few chars space
>> >> in each line of console output.
>> >>
>> >> For now i will stick to this v3 version of path, unless you think 
>> >> otherwise.
>> >
>> > I don't think is is something that anyone needs, and if you do, as
>> > pointed out, you can use the trace function to make it happen.
>> >
>>
>> This was something that got used internally and helped at times.
>
> Could you have used the trace point instead?

As i understood the trace_prink(), one would need to modify existing
printk -> trace_printk. Is my understanding correct?

Most of the times the problem exhibits as a random hang, without having a clue
which code to modify. That time one generic defconfig global switch is
your first tool.

Other issue i found, using this patch, that on multi-core ARM systems,
almost 99% of times, IRQ's are handled by CPU0,
even if CPU0 was really busy and other CPU's were free. I am yet to
understand a good reason why.

this patch also helped in other areas as mentioned in the thread
http://marc.info/?l=linux-omap=134401269106619=2

Not sure how easy its to use trace_printk for such issues, i found
having one defconfig option was much easier
to get going. Correct me if i have not understood trace_printk well enough.


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

Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Tejun Heo]

Hello,

On Sat, Aug 04, 2012 at 12:20:02AM +0200, Sasha Levin wrote:
> On 08/03/2012 11:48 PM, Tejun Heo wrote:
> > On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
> >> I forgot to comment on that one, sorry.
> >>
> >> If we put hash entries after struct hash_table we don't take the
> >> bits field size into account, or did I miss something?
> > 
> > So, if you do the following,
> > 
> > struct {
> > struct {
> > int i;
> > long ar[];
> > } B;
> > long __ar_storage[32];
> > } A;
> 
> struct A should have been an union, right?

I actually meant an enclosing struct.  When you're defining a struct
member, simply putting the storage after a struct with var array
should be good enough.  If that doesn't work, quite a few things in
the kernel will break.

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: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Sasha Levin]

On 08/03/2012 11:48 PM, Tejun Heo wrote:
> Hello,
> 
> On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
>> I forgot to comment on that one, sorry.
>>
>> If we put hash entries after struct hash_table we don't take the
>> bits field size into account, or did I miss something?
> 
> So, if you do the following,
> 
>   struct {
>   struct {
>   int i;
>   long ar[];
>   } B;
>   long __ar_storage[32];
>   } A;

struct A should have been an union, right?

> It should always be safe to dereference A.B.ar[31].  I'm not sure
> whether this is something guaranteed by C tho.  Maybe compilers are
> allowed to put members in reverse order but I think we already depend
> on the above.

why is accessing A.B.ar[31] safe?

__ar_storage is only 32*sizeof(long) bytes long, while struct B would need to 
be 32*sizeof(long) + sizeof(int) bytes long so that A.B.ar[31] access would be 
safe.


> Thanks.
> 

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

Gaming and the kernel

[Chris Jones]

There's a lot of attention at the moment focused toward Linux and the 
future of gaming support on the platform. And it got me thinking, is 
there any particular improvements that are planned to improve the kernel 
from better support for gaming?



Regards

--
Chris Jones @ kernel.devproj...@gmail.com
also on oracle.kernel...@gmail.com and netbsd.kernel...@gmail.com

Ubuntu 12.04 (PC)|Android (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming)
Linux kernel developer|Solaris kernel developer|BSD kernel developer|Lead 
Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web 
Services|Digital Imaging Services
Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 
controller|Logitech Attack 3 j/stick
Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox

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

[Greg KH]

On Fri, Aug 03, 2012 at 03:07:39PM -0700, Pandita, Vikram wrote:
> On Fri, Aug 3, 2012 at 2:59 PM, Greg KH  wrote:
> > On Fri, Aug 03, 2012 at 02:24:20PM -0700, Pandita, Vikram wrote:
> >> Aaro
> >>
> >> On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen  wrote:
> >> > Hi,
> >> >
> >> > On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote:
> >> >> > And really: Wasting 1/3 of the 80 character line is too much.
> >> >>
> >> >> You _WASTE_ 4 chars only if you are interested in this info by
> >> >> enabling: CONFIG_PRINTK_CPUID
> >> >
> >> > I guess you waste 4 + 3 chars? You could optimize the length by checking
> >> > CONFIG_NR_CPUS?
> >>
> >> Good point.
> >> Looks there is a variable 'nr_cpu_ids' that could be used as well.
> >>
> >> If there is general consensus that the patch can help the arm
> >> community, and others in general,
> >> this optimization should be easy to implement - saving few chars space
> >> in each line of console output.
> >>
> >> For now i will stick to this v3 version of path, unless you think 
> >> otherwise.
> >
> > I don't think is is something that anyone needs, and if you do, as
> > pointed out, you can use the trace function to make it happen.
> >
> 
> This was something that got used internally and helped at times.

Could you have used the trace point instead?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Debug ] fs : export debugfs_file_operations symbol

[Greg KH]

On Sat, Aug 04, 2012 at 03:30:44AM +0530, Akhilesh Kumar wrote:
> Hi Hartman
> 
> This patch just exports debugfs_file_operations which improve debugfs
> interface .
> Please review below patch for main line and share your review comments.
> 
> Thanks,
> Akhilesh
> 
> 
> 
> 
> From fd68900cd32f220beee70b55c20b3c74a38d7df8 Mon Sep 17 00:00:00 2001
> From: Akhilesh Kumar 
> Date: Tue, 31 Jul 2012 17:17:12 +0530
> Subject:[Debug ] fs : export debugfs_file_operations symbol
>  
>  debugfs_file_operations is usefull for file system
>  debugging debugfs_file_operations is not an exported
>  symbol.
> 
> Any kernel module (http://lwn.net/Articles/371208/) using
> 
> debugfs_file_operations will result in build failures
> because of this.
> 
> This patch just exports debugfs_file_operations to fix such problems in
> future
> 
> Signed-off-by: Akhilesh Kumar 
> ---
>  fs/debugfs/file.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index 2340f69..a5150d8 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -40,6 +40,7 @@ const struct file_operations debugfs_file_operations = {
>   .open = simple_open,
>   .llseek = noop_llseek,
>  };
> +EXPORT_SYMBOL(debugfs_file_operations);

I fail to understand how this will help you out at all.  You should not
be using this symbol, why would you?

Please show the in-kernel code that needs it, and I will be glad to
reconsider this patch, after it it fixed to use EXPORT_SYMBOL_GPL() as
well, to be consistant with the other debugfs symbols.

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

[David Ahern]

On 8/3/12 3:52 PM, Alex Williamson wrote:

Is this the chunk that's causing the oops?


Yes. And taking it out fixes passthrough as well.

David




diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 7469b53..27d8c97 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4133,6 +4133,7 @@ static int intel_iommu_add_device(struct device *dev)
   PCI_DEVFN(PCI_SLOT(dma_pdev->devfn),
   0)));

+#if 0
 while (!pci_is_root_bus(dma_pdev->bus)) {
 if (pci_acs_path_enabled(dma_pdev->bus->self,
  NULL, REQ_ACS_FLAGS))
@@ -4140,6 +4141,7 @@ static int intel_iommu_add_device(struct device *dev)

 swap_pci_ref(_pdev, pci_dev_get(dma_pdev->bus->self));
 }
+#endif

 group = iommu_group_get(_pdev->dev);
 pci_dev_put(dma_pdev);




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

[Pandita, Vikram]

On Fri, Aug 3, 2012 at 2:59 PM, Greg KH  wrote:
> On Fri, Aug 03, 2012 at 02:24:20PM -0700, Pandita, Vikram wrote:
>> Aaro
>>
>> On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen  wrote:
>> > Hi,
>> >
>> > On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote:
>> >> > And really: Wasting 1/3 of the 80 character line is too much.
>> >>
>> >> You _WASTE_ 4 chars only if you are interested in this info by
>> >> enabling: CONFIG_PRINTK_CPUID
>> >
>> > I guess you waste 4 + 3 chars? You could optimize the length by checking
>> > CONFIG_NR_CPUS?
>>
>> Good point.
>> Looks there is a variable 'nr_cpu_ids' that could be used as well.
>>
>> If there is general consensus that the patch can help the arm
>> community, and others in general,
>> this optimization should be easy to implement - saving few chars space
>> in each line of console output.
>>
>> For now i will stick to this v3 version of path, unless you think otherwise.
>
> I don't think is is something that anyone needs, and if you do, as
> pointed out, you can use the trace function to make it happen.
>

This was something that got used internally and helped at times.
This attempt to give back to community, but i understand the rationale to go
with larger consensus.

At least the patch is out there in public for anyone to make use of.

> Adding features are not "free", someone has to maintain them and all of
> the other work involved with it.  So don't just think that because it is
> hidden behind a config option, that it doesn't affect people.

At least the v3 patch is a complete working implementation wrt
kernel/printk.c file
as it exists on linus tree master today.

Understand long term this does have maintenance overhead just like
printk_time does.

>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] printk: add option to print cpu id

[Greg KH]

On Fri, Aug 03, 2012 at 02:24:20PM -0700, Pandita, Vikram wrote:
> Aaro
> 
> On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen  wrote:
> > Hi,
> >
> > On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote:
> >> > And really: Wasting 1/3 of the 80 character line is too much.
> >>
> >> You _WASTE_ 4 chars only if you are interested in this info by
> >> enabling: CONFIG_PRINTK_CPUID
> >
> > I guess you waste 4 + 3 chars? You could optimize the length by checking
> > CONFIG_NR_CPUS?
> 
> Good point.
> Looks there is a variable 'nr_cpu_ids' that could be used as well.
> 
> If there is general consensus that the patch can help the arm
> community, and others in general,
> this optimization should be easy to implement - saving few chars space
> in each line of console output.
> 
> For now i will stick to this v3 version of path, unless you think otherwise.

I don't think is is something that anyone needs, and if you do, as
pointed out, you can use the trace function to make it happen.

Adding features are not "free", someone has to maintain them and all of
the other work involved with it.  So don't just think that because it is
hidden behind a config option, that it doesn't affect people.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 pcmcia bug - unable to map card memory on old laptops

[Piotr Gluszenia Slawinski]

bug is present in all kernels since late 2.6.36


can you send the boot log with working and not working kernel?
Please make sure you have PCI_DEBUG set in your config.


system is ISA based :) but i've enabled it for sake of clarity.

logs are attached 
both systems are 3.5 kernel, working is one where i've simply commented 
out the code preventing low mem allocation in resource.c


btw. note that if i would enable pci support in older kernels
bug would most likely resurface even there.

--<5>Linux version 3.5.0-mini (root@solidstate) (gcc version 4.4.5 (Gentoo 4.4.5 
p1.2, pie-0.4.5) ) #13 Fri Aug 3 21:32:49 UTC 2012
<6>e820: BIOS-provided physical RAM map:
<6>BIOS-88: [mem 0x-0x0009efff] usable
<6>BIOS-88: [mem 0x0010-0x0102] usable
<5>Notice: NX (Execute Disable) protection missing in CPU!
<7>e820: update [mem 0x-0x] usable ==> reserved
<7>e820: remove [mem 0x000a-0x000f] usable
<6>e820: last_pfn = 0x1030 max_arch_pfn = 0x10
<7>initial memory mapped: [mem 0x-0x007f]
<7>Base memory trampoline at [c009b000] 9b000 size 16384
<6>init_memory_mapping: [mem 0x-0x0102]
<7> [mem 0x-0x003f] page 4k
<7> [mem 0x0040-0x00ff] page 2M
<7> [mem 0x0100-0x0102] page 4k
<7>kernel direct mapping tables up to 0x102 @ [mem 0x007fa000-0x007f]
<4>ACPI Error: A valid RSDP was not found (20120320/tbxfroot-219)
<5>16MB LOWMEM available.
<6>  mapped low ram: 0 - 0103
<6>  low ram: 0 - 0103
<4>Zone ranges:
<4>  DMA  [mem 0x0001-0x00ff]
<4>  Normal   [mem 0x0100-0x0102]
<4>Movable zone start for each node
<4>Early memory node ranges
<4>  node   0: [mem 0x0001-0x0009efff]
<4>  node   0: [mem 0x0010-0x0102]
<7>On node 0 totalpages: 4031
<7>  DMA zone: 32 pages used for memmap
<7>  DMA zone: 0 pages reserved
<7>  DMA zone: 3951 pages, LIFO batch:0
<7>  Normal zone: 1 pages used for memmap
<7>  Normal zone: 47 pages, LIFO batch:0
<6>PM: Registered nosave memory: 0009f000 - 0010
<6>e820: [mem 0x0103-0x] available for PCI devices
<7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>pcpu-alloc: [0] 0 
<4>Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 3998
<5>Kernel command line: vga=06 rw resume=/dev/sda1 root=/dev/sda2 rw panic=40 
<6>PID hash table entries: 64 (order: -4, 256 bytes)
<6>Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
<6>Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
<5>__ex_table already sorted, skipping sort
<6>Initializing CPU#0
<6>Memory: 12172k/16576k available (2370k kernel code, 3952k reserved, 551k 
data, 220k init, 0k highmem)
<6>virtual kernel memory layout:
<6>fixmap  : 0xfffe3000 - 0xf000   ( 112 kB)
<6>vmalloc : 0xc183 - 0xfffe1000   ( 999 MB)
<6>lowmem  : 0xc000 - 0xc103   (  16 MB)
<6>  .init : 0xc03db000 - 0xc0412000   ( 220 kB)
<6>  .data : 0xc0350982 - 0xc03da7c0   ( 551 kB)
<6>  .text : 0xc010 - 0xc0350982   (2370 kB)
<6>Checking if this processor honours the WP bit even in supervisor mode...Ok.
<6>NR_IRQS:16 nr_irqs:16 16
<7>CPU 0 irqstacks, hard=c009 soft=c0092000
<6>Console: colour VGA+ 80x60
<6>console [tty0] enabled
<4>Fast TSC calibration using PIT
<4>Detected 99.950 MHz processor.
<6>Calibrating delay loop (skipped), value calculated using timer frequency.. 
199.90 BogoMIPS (lpj=999500)
<6>pid_max: default: 4096 minimum: 301
<6>Mount-cache hash table entries: 512
<5>Intel Pentium with F0 0F bug - workaround enabled.
<6>CPU: Intel Pentium 75 - 200 stepping 0c
<6>Performance Events: no PMU driver, software events only.
<6>devtmpfs: initialized
<6>NET: Registered protocol family 16
<3>PCI: Fatal: No config space access function found
<6>bio: create slab  at 0
<6>ACPI: Interpreter disabled.
<5>SCSI subsystem initialized
<7>libata version 3.00 loaded.
<4>PCI: System does not support PCI
<4>PCI: System does not support PCI
<6>Switching to clocksource pit
<6>pnp: PnP ACPI: disabled
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
<6>TCP established hash table entries: 512 (order: 0, 4096 bytes)
<6>TCP bind hash table entries: 512 (order: -1, 2048 bytes)
<6>TCP: Hash tables configured (established 512 bind 512)
<6>TCP: reno registered
<6>UDP hash table entries: 256 (order: 0, 4096 bytes)
<6>UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
<6>NET: Registered protocol family 1
<7>PCI: CLS 0 bytes, default 32
<6>platform rtc_cmos: registered platform RTC device (no PNP device found)
<6>apm: BIOS version 1.1 Flags 0x02 (Driver version 1.16ac)
<6>squashfs: version 4.0 (2009/01/31) Phillip Lougher
<6>Btrfs loaded
<6>io scheduler noop registered (default)
<6>isapnp: Scanning for PnP cards...
<6>isapnp: No Plug & Play device found
<6>Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
<6>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

Re: oops in pci_acs_path_enabled

[Alex Williamson]

On Fri, 2012-08-03 at 15:12 -0600, David Ahern wrote:
> On 8/3/12 2:21 PM, Alex Williamson wrote:
> > On Fri, 2012-08-03 at 11:39 -0600, David Ahern wrote:
> >> Hi Alex:
> >>
> >> Hitting an oops with 3.6-rc1. Backtrace from console attached. git blame
> >> for the top function points to ad805758.
> >
> > Hey David,
> >
> > Hmm, what's special about your system?  I've got an 82576 here and the
> > same path works fine.  Any way you can get the top of the oops message?
> > Thanks,
> >
> > Alex
> >
> 
> Dell R410 I believe. pair of 5620 processors. 3 overlapping screen shots 
> attached. objdump on pci.o suggests the pdev is NULL:
> 
> /opt/sw/ahern/kernels/kernel.git/drivers/pci/pci.c:2454
> 
>  ret = pci_dev_specific_acs_enabled(pdev, acs_flags);
>  if (ret >= 0)
>  return ret > 0;
> 
>  if (!pci_is_pcie(pdev))
>  408a:   41 80 7c 24 4a 00   cmpb   $0x0,0x4a(%r12)
>  4090:   74 e8   je 407a 
> 
> 
> Perhaps this bug explains the larger the issue which is that device 
> passthrough in 3.6-rc1 (0d7614f) is broken for me -- config field for 
> the PCI device does not exist. e.g.,
> 
> pcilib: Cannot open /sys/bus/pci/devices/:06:10.0/config
> lspci: Unable to read the standard configuration space header of device 
> :06:10.0
> pcilib: Cannot open /sys/bus/pci/devices/:06:10.0/config
> lspci: Unable to read the standard configuration space header of device 
> :06:10.0
> failed to find vendor-product id for PCI id "06:10.0"
> Failed to claim PCI device 06:10.0
> 
> git bisect points to:
> 
> 783f157bc5a7fa30ee17b4099b27146bd1b68af4 is the first bad commit
> commit 783f157bc5a7fa30ee17b4099b27146bd1b68af4
> Author: Alex Williamson 
> Date:   Wed May 30 14:19:43 2012 -0600
> 
>  intel-iommu: Make use of DMA quirks and ACS checks in IOMMU groups
> 
>  Work around broken devices and adhere to ACS support when determining
>  IOMMU grouping.
> 
>  Signed-off-by: Alex Williamson 
>  Signed-off-by: Joerg Roedel 
> 
> :04 04 83890398dabbf225fd0f5b3c8c3713a75b3fb5e1 
> b674ce2ecb315393a8c6c1ac98b3796d5ba09708 Mdrivers
> 
> I triggered the oops in a number of the bisect points as well -- in 
> those cases the machine had to be power cycled.

Is this the chunk that's causing the oops?

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 7469b53..27d8c97 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4133,6 +4133,7 @@ static int intel_iommu_add_device(struct device *dev)
  PCI_DEVFN(PCI_SLOT(dma_pdev->devfn),
  0)));
 
+#if 0
while (!pci_is_root_bus(dma_pdev->bus)) {
if (pci_acs_path_enabled(dma_pdev->bus->self,
 NULL, REQ_ACS_FLAGS))
@@ -4140,6 +4141,7 @@ static int intel_iommu_add_device(struct device *dev)
 
swap_pci_ref(_pdev, pci_dev_get(dma_pdev->bus->self));
}
+#endif
 
group = iommu_group_get(_pdev->dev);
pci_dev_put(dma_pdev);


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

Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Tejun Heo]

Hello,

On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
> I forgot to comment on that one, sorry.
> 
> If we put hash entries after struct hash_table we don't take the
> bits field size into account, or did I miss something?

So, if you do the following,

struct {
struct {
int i;
long ar[];
} B;
long __ar_storage[32];
} A;

It should always be safe to dereference A.B.ar[31].  I'm not sure
whether this is something guaranteed by C tho.  Maybe compilers are
allowed to put members in reverse order but I think we already depend
on the above.

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: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Tejun Heo]

Hello, Sasha.

On Fri, Aug 03, 2012 at 11:36:49PM +0200, Sasha Levin wrote:
> On 08/03/2012 11:30 PM, Tejun Heo wrote:
> The function definition itself is just a macro, for example:
> 
>   #define MM_SLOTS_HASH_CMP(mm_slot, obj) ((mm_slot)->mm == (obj))

It seems like it would make things more difficult to follow and
error-prone.  I'd definitely prefer just using functions.

> As an alternative, what do you think about simplifying that to be
> just a 'cond' instead of a function? Something like:
> 
>   hash_get(_slots_hash, mm, struct mm_slot, hash, mm);
> 
> In that case, the last param ("mm") will get unrolled to a condition like 
> this:
> 
>   if ((obj)->mm == key)
> 
> Which will be simple and easy for the user.

It seems a bit too magical(tm) to me. ;)

> The only reason I want to keep this interface is that most cases
> I've stumbled so far were easy short comparisons of a struct member
> with the key, and I don't want to make them more complex than they
> need to be. I probably will switch hash_get() to use
> hash_for_each_possible() as well, which will cut down on how
> hash_get() is a separate case.

I can understand that but I think the benefit we're talking about is a
bit too miniscule to matter and to have two different interfaces.
What do others think?

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: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Sasha Levin]

On 08/03/2012 11:30 PM, Tejun Heo wrote:
> Hello,
> 
> On Fri, Aug 03, 2012 at 11:19:57PM +0200, Sasha Levin wrote:
>>> Is this supposed to be embedded in struct definition?  If so, the name
>>> is rather misleading as DEFINE_* is supposed to define and initialize
>>> stand-alone constructs.  Also, for struct members, simply putting hash
>>> entries after struct hash_table should work.
>>
>> It would work, but I didn't want to just put them in the union since
>> I feel it's safer to keep them in a separate struct so they won't be
>> used by mistake,
> 
> Just use ugly enough pre/postfixes.  If the user still accesses that,
> it's the user's fault.

I forgot to comment on that one, sorry.

If we put hash entries after struct hash_table we don't take the bits field 
size into account, or did I miss something?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Tree for Aug 3 (drivers/i2c/busses/i2c-i801.c)

[Randy Dunlap]

On 08/03/2012 12:57 PM, Jean Delvare wrote:

> Hi Randy,
> 
> On Fri, 03 Aug 2012 10:24:34 -0700, Randy Dunlap wrote:
>> on x86_64:
>>
>> when CONFIG_GPIOLIB is not enabled:
>>
>> drivers/i2c/busses/i2c-i801.c: In function 'match_gpio_chip_by_label':
>> drivers/i2c/busses/i2c-i801.c:1011:21: error: dereferencing pointer to 
>> incomplete type
>> drivers/i2c/busses/i2c-i801.c: In function 'i801_add_mux':
>> drivers/i2c/busses/i2c-i801.c:1028:2: error: implicit declaration of 
>> function 'gpiochip_find'
>> drivers/i2c/busses/i2c-i801.c:1028:7: warning: assignment makes pointer from 
>> integer without a cast
>> drivers/i2c/busses/i2c-i801.c:1047:27: error: dereferencing pointer to 
>> incomplete type
>> drivers/i2c/busses/i2c-i801.c: In function 'match_gpio_chip_by_label':
>> drivers/i2c/busses/i2c-i801.c:1012:1: warning: control reaches end of 
>> non-void function
> 
> Good catch, thanks for reporting. I'll fold the following in the
> offending patch, that should fix it:

Ack, it does.
Thanks.

> --- linux-3.6-rc0.orig/drivers/i2c/busses/Kconfig 2012-08-03 
> 21:51:51.0 +0200
> +++ linux-3.6-rc0/drivers/i2c/busses/Kconfig  2012-08-03 21:52:18.090537018 
> +0200
> @@ -80,6 +80,7 @@ config I2C_I801
>   tristate "Intel 82801 (ICH/PCH)"
>   depends on PCI
>   select CHECK_SIGNATURE if X86 && DMI
> + select GPIOLIB if I2C_MUX
>   help
> If you say yes to this option, support will be included for the Intel
> 801 family of mainboard I2C interfaces.  Specifically, the following
> 
> 



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

Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Sasha Levin]

On 08/03/2012 11:30 PM, Tejun Heo wrote:
>> I think hash_for_for_each_possible() is useful if the comparison
>> > condition is more complex than a simple comparison of one of the
>> > object members with the key - there's no need to force it on all the
>> > users.
> I don't know.  What's the difference?  In terms of LOC, it might even
> not save any thanks to the extra function definition, right?  I don't
> think it's saving enough complexity to justify a separate rather
> unusual interface.

The function definition itself is just a macro, for example:

#define MM_SLOTS_HASH_CMP(mm_slot, obj) ((mm_slot)->mm == (obj))

As an alternative, what do you think about simplifying that to be just a 'cond' 
instead of a function? Something like:

hash_get(_slots_hash, mm, struct mm_slot, hash, mm);

In that case, the last param ("mm") will get unrolled to a condition like this:

if ((obj)->mm == key)

Which will be simple and easy for the user.


The only reason I want to keep this interface is that most cases I've stumbled 
so far were easy short comparisons of a struct member with the key, and I don't 
want to make them more complex than they need to be. I probably will switch 
hash_get() to use hash_for_each_possible() as well, which will cut down on how 
hash_get() is a separate case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Tejun Heo]

Hello,

On Fri, Aug 03, 2012 at 11:19:57PM +0200, Sasha Levin wrote:
> > Is this supposed to be embedded in struct definition?  If so, the name
> > is rather misleading as DEFINE_* is supposed to define and initialize
> > stand-alone constructs.  Also, for struct members, simply putting hash
> > entries after struct hash_table should work.
> 
> It would work, but I didn't want to just put them in the union since
> I feel it's safer to keep them in a separate struct so they won't be
> used by mistake,

Just use ugly enough pre/postfixes.  If the user still accesses that,
it's the user's fault.

> >> +static void hash_init(struct hash_table *ht, size_t bits)
> >> +{
> >> +  size_t i;
> > 
> > I would prefer int here but no biggie.
> 
> Just wondering, is there a particular reason behind it?

It isn't a size and using unsigned when signed suffices seems to cause
more headache than helps anything usually due to lack of values to use
for exceptional conditions (usually -errno or -1).

> > As opposed to using hash_for_each_possible(), how much difference does
> > this make?  Is it really worthwhile?
> 
> Most of the places I've switched to using this hashtable so far (4
> out of 6) are using hash_get(). I think that the code looks cleaner
> when you an just provide a comparison function instead of
> implementing the iteration itself.
>
> I think hash_for_for_each_possible() is useful if the comparison
> condition is more complex than a simple comparison of one of the
> object members with the key - there's no need to force it on all the
> users.

I don't know.  What's the difference?  In terms of LOC, it might even
not save any thanks to the extra function definition, right?  I don't
think it's saving enough complexity to justify a separate rather
unusual interface.

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 v3] printk: add option to print cpu id

[Pandita, Vikram]

Aaro

On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen  wrote:
> Hi,
>
> On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote:
>> > And really: Wasting 1/3 of the 80 character line is too much.
>>
>> You _WASTE_ 4 chars only if you are interested in this info by
>> enabling: CONFIG_PRINTK_CPUID
>
> I guess you waste 4 + 3 chars? You could optimize the length by checking
> CONFIG_NR_CPUS?

Good point.
Looks there is a variable 'nr_cpu_ids' that could be used as well.

If there is general consensus that the patch can help the arm
community, and others in general,
this optimization should be easy to implement - saving few chars space
in each line of console output.

For now i will stick to this v3 version of path, unless you think otherwise.

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

[Geert Uytterhoeven]

From: Mikael Pettersson 

commit c663600584a596b5e66258cc10716fb781a5c2c9 upstream.

Booting a 3.2, 3.3, or 3.4-rc4 kernel on an Atari using the
`nfeth' ethernet device triggers a WARN_ONCE() in generic irq
handling code on the first irq for that device:

WARNING: at kernel/irq/handle.c:146 handle_irq_event_percpu+0x134/0x142()
irq 3 handler nfeth_interrupt+0x0/0x194 enabled interrupts
Modules linked in:
Call Trace: [<000299b2>] warn_slowpath_common+0x48/0x6a
 [<000299c0>] warn_slowpath_common+0x56/0x6a
 [<00029a4c>] warn_slowpath_fmt+0x2a/0x32
 [<0005b34c>] handle_irq_event_percpu+0x134/0x142
 [<0005b34c>] handle_irq_event_percpu+0x134/0x142
 [] nfeth_interrupt+0x0/0x194
 [<001ba0a8>] schedule_preempt_disabled+0x0/0xc
 [<0005b37a>] handle_irq_event+0x20/0x2c
 [<0005add4>] generic_handle_irq+0x2c/0x3a
 [<2ab6>] do_IRQ+0x20/0x32
 [<289e>] auto_irqhandler_fixup+0x4/0x6
 [<3144>] cpu_idle+0x22/0x2e
 [<001b8a78>] printk+0x0/0x18
 [<0024d112>] start_kernel+0x37a/0x386
 [<0003021d>] __do_proc_dointvec+0xb1/0x366
 [<0003021d>] __do_proc_dointvec+0xb1/0x366
 [<0024c31e>] _sinittext+0x31e/0x9c0

After invoking the irq's handler the kernel sees !irqs_disabled()
and concludes that the handler erroneously enabled interrupts.

However, debugging shows that !irqs_disabled() is true even before
the handler is invoked, which indicates a problem in the platform
code rather than the specific driver.

The warning does not occur in 3.1 or older kernels.

It turns out that the ALLOWINT definition for Atari is incorrect.

The Atari definition of ALLOWINT is ~0x400, the stated purpose of
that is to avoid taking HSYNC interrupts.  irqs_disabled() returns
true if the 3-bit ipl & 4 is non-zero.  The nfeth interrupt runs at
ipl 3 (it's autovector 3), but 3 & 4 is zero so irqs_disabled() is
false, and the warning above is generated.

When interrupts are explicitly disabled, ipl is set to 7.  When they
are enabled, ipl is masked with ALLOWINT.  On Atari this will result
in ipl = 3, which blocks interrupts at ipl 3 and below.  So how come
nfeth interrupts at ipl 3 are received at all?  That's because ipl
is reset to 2 by Atari-specific code in default_idle(), again with
the stated purpose of blocking HSYNC interrupts.  This discrepancy
means that ipl 3 can remain blocked for longer than intended.

Both default_idle() and falcon_hblhandler() identify HSYNC with
ipl 2, and the "Atari ST/.../F030 Hardware Register Listing" agrees,
but ALLOWINT is defined as if HSYNC was ipl 3.

[As an experiment I modified default_idle() to reset ipl to 3, and
as expected that resulted in all nfeth interrupts being blocked.]

The fix is simple: define ALLOWINT as ~0x500 instead.  This makes
arch_local_irq_enable() consistent with default_idle(), and prevents
the !irqs_disabled() problems for ipl 3 interrupts.

Tested on Atari running in an Aranym VM.

Signed-off-by: Mikael Pettersson 
Tested-by: Michael Schmitz  (on Falcon/CT60)
Signed-off-by: Geert Uytterhoeven 
---
This version applies to v3.2..v3.4.
For v2.6.29..v3.1, it should be applied to arch/m68k/include/asm/entry_mm.h
instead

 arch/m68k/include/asm/entry.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/include/asm/entry.h b/arch/m68k/include/asm/entry.h
index c3c5a86..8798ebc 100644
--- a/arch/m68k/include/asm/entry.h
+++ b/arch/m68k/include/asm/entry.h
@@ -33,8 +33,8 @@
 
 /* the following macro is used when enabling interrupts */
 #if defined(MACH_ATARI_ONLY)
-   /* block out HSYNC on the atari */
-#define ALLOWINT   (~0x400)
+   /* block out HSYNC = ipl 2 on the atari */
+#define ALLOWINT   (~0x500)
 #defineMAX_NOINT_IPL   3
 #else
/* portable version */
-- 
1.7.0.4

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

Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable

[Sasha Levin]

On 08/03/2012 07:15 PM, Tejun Heo wrote:
> Hello, Sasha.
> 
> On Fri, Aug 03, 2012 at 04:23:02PM +0200, Sasha Levin wrote:
>> +#define DEFINE_STATIC_HASHTABLE(n, b)   
>> \
>> +static struct hash_table n = { .bits = (b), \
>> +.buckets = { [0 ... ((1 << (b)) - 1)] = HLIST_HEAD_INIT } }
> 
> What does this "static" mean?
> 
>> +#define DEFINE_HASHTABLE(n, b)  
>> \
>> +union { \
>> +struct hash_table n;\
>> +struct {\
>> +size_t bits;\
>> +struct hlist_head buckets[1 << (b)];\
>> +} __##n ;   \
>> +};
> 
> Is this supposed to be embedded in struct definition?  If so, the name
> is rather misleading as DEFINE_* is supposed to define and initialize
> stand-alone constructs.  Also, for struct members, simply putting hash
> entries after struct hash_table should work.

It would work, but I didn't want to just put them in the union since I feel 
it's safer to keep them in a separate struct so they won't be used by mistake,

> Wouldn't using DEFINE_HASHTABLE() for the first macro and
> DEFINE_HASHTABLE_MEMBER() for the latter be better?

Indeed that sounds better, will fix.

>> +#define HASH_BITS(name) ((name)->bits)
>> +#define HASH_SIZE(name) (1 << (HASH_BITS(name)))
>> +
>> +__attribute__ ((unused))
> 
> Are we using __attribute__((unused)) for functions defined in headers
> instead of static inline now?  If so, why? 
> 
>> +static void hash_init(struct hash_table *ht, size_t bits)
>> +{
>> +size_t i;
> 
> I would prefer int here but no biggie.

Just wondering, is there a particular reason behind it?

>> +ht->bits = bits;
>> +for (i = 0; i < (1 << bits); i++)
>> +INIT_HLIST_HEAD(>buckets[i]);
>> +}
>> +
>> +static void hash_add(struct hash_table *ht, struct hlist_node *node, long 
>> key)
>> +{
>> +hlist_add_head(node,
>> +>buckets[hash_long((unsigned long)key, HASH_BITS(ht))]);
>> +}
>> +
>> +
>> +#define hash_get(name, key, type, member, cmp_fn)   \
>> +({  \
>> +struct hlist_node *__node;  \
>> +typeof(key) __key = key;\
>> +type *__obj = NULL; \
>> +hlist_for_each_entry(__obj, __node, &(name)->buckets[   \
>> +hash_long((unsigned long) __key,\
>> +HASH_BITS(name))], member)  \
>> +if (cmp_fn(__obj, __key))   \
>> +break;  \
>> +__obj;  \
>> +})
> 
> As opposed to using hash_for_each_possible(), how much difference does
> this make?  Is it really worthwhile?

Most of the places I've switched to using this hashtable so far (4 out of 6) 
are using hash_get(). I think that the code looks cleaner when you an just 
provide a comparison function instead of implementing the iteration itself.

I think hash_for_for_each_possible() is useful if the comparison condition is 
more complex than a simple comparison of one of the object members with the key 
- there's no need to force it on all the users.

> 
> Thanks.
> 

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

Re: [RFC v2 7/7] net,9p: use new hashtable implementation

[Sasha Levin]

On 08/03/2012 08:00 PM, Eric Dumazet wrote:
> On Fri, 2012-08-03 at 16:23 +0200, Sasha Levin wrote:
>>  /* initialize hash table */
>> -for (bucket = 0; bucket < ERRHASHSZ; bucket++)
>> -INIT_HLIST_HEAD(_errmap[bucket]);
>> +hash_init(_errmap, ERRHASHSZ);
> 
> Why is hash_init() even needed ?
> 
> If hash is "DEFINE_STATIC_HASHTABLE(...)", its already ready for use !

Indeed it is.

I've removed it, and then decided to put it back since the definition of the 
hashtable isn't fully cooked yet, and I didn't want to miss this initialization 
point if it turn out we need to initialize that hashtable afterall.

I will remove it once the hashtable definitions are clear.

The rest of the review comments will be addressed.

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

[PATCH 2/2] Made core dump functionality optional

[Alex Kelly]

From: Alex 

Adds an expert Kconfig option, CONFIG_COREDUMP, which allows disabling of core 
dump.
This saves approximately 2.6k in the compiled kernel, and complements 
CONFIG_ELF_CORE,
which now depends on it.

CONFIG_COREDUMP also disables coredump-related sysctls, except for 
suid_dumpable and
related functions, which are necessary for ptrace.

Signed-off-by: Alex Kelly 
Reviewed-by: Josh Triplett 
---
 fs/Kconfig.binfmt   | 8 
 fs/Makefile | 3 ++-
 include/linux/binfmts.h | 4 
 init/Kconfig| 1 +
 kernel/sysctl.c | 6 +-
 5 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index 0225742..0efd152 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -164,3 +164,11 @@ config BINFMT_MISC
  You may say M here for module support and later load the module when
  you have use for it; the module is called binfmt_misc. If you
  don't know what to answer at this point, say Y.
+
+config COREDUMP
+   bool "Enable core dump support" if EXPERT
+   default y
+   help
+ This option enables support for performing core dumps. You almost
+ certainly want to say Y here. Not necessary on systems that never
+ need debugging or only ever run flawless code.
diff --git a/fs/Makefile b/fs/Makefile
index 8938f82..1d7af79 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -11,7 +11,7 @@ obj-y :=  open.o read_write.o file_table.o super.o \
attr.o bad_inode.o file.o filesystems.o namespace.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o drop_caches.o splice.o sync.o utimes.o \
-   stack.o fs_struct.o statfs.o coredump.o
+   stack.o fs_struct.o statfs.o
 
 ifeq ($(CONFIG_BLOCK),y)
 obj-y +=   buffer.o bio.o block_dev.o direct-io.o mpage.o ioprio.o
@@ -48,6 +48,7 @@ obj-$(CONFIG_FS_MBCACHE)  += mbcache.o
 obj-$(CONFIG_FS_POSIX_ACL) += posix_acl.o xattr_acl.o
 obj-$(CONFIG_NFS_COMMON)   += nfs_common/
 obj-$(CONFIG_GENERIC_ACL)  += generic_acl.o
+obj-$(CONFIG_COREDUMP) += coredump.o
 
 obj-$(CONFIG_FHANDLE)  += fhandle.o
 
diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
index 366422b..00e2e89 100644
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@ -132,7 +132,11 @@ extern int copy_strings_kernel(int argc, const char *const 
*argv,
   struct linux_binprm *bprm);
 extern int prepare_bprm_creds(struct linux_binprm *bprm);
 extern void install_exec_creds(struct linux_binprm *bprm);
+#ifdef CONFIG_COREDUMP
 extern void do_coredump(long signr, int exit_code, struct pt_regs *regs);
+#else
+static inline void do_coredump(long signr, int exit_code, struct pt_regs 
*regs) {}
+#endif
 extern void set_binfmt(struct linux_binfmt *new);
 extern void free_bprm(struct linux_binprm *);
 
diff --git a/init/Kconfig b/init/Kconfig
index af6c7f8..0e75056 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1230,6 +1230,7 @@ config BUG
   Just say Y.
 
 config ELF_CORE
+   depends on COREDUMP
default y
bool "Enable ELF core dumps" if EXPERT
help
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 87174ef..af57e84 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -97,10 +97,12 @@
 extern int sysctl_overcommit_memory;
 extern int sysctl_overcommit_ratio;
 extern int max_threads;
-extern int core_uses_pid;
 extern int suid_dumpable;
+#ifdef CONFIG_COREDUMP
+extern int core_uses_pid;
 extern char core_pattern[];
 extern unsigned int core_pipe_limit;
+#endif
 extern int pid_max;
 extern int min_free_kbytes;
 extern int pid_max_min, pid_max_max;
@@ -404,6 +406,7 @@ static struct ctl_table kern_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec,
},
+#ifdef CONFIG_COREDUMP
{
.procname   = "core_uses_pid",
.data   = _uses_pid,
@@ -425,6 +428,7 @@ static struct ctl_table kern_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec,
},
+#endif
 #ifdef CONFIG_PROC_SYSCTL
{
.procname   = "tainted",
-- 
1.7.11.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/2] Moved core dump functionality into its own file

[Alex Kelly]

From: Alex Kelly 

This was done in preparation for making core dump functionality optional.

The variable "suid_dumpable" and associated functions are left in fs/exec.c
because they're used elsewhere, such as in ptrace.

Signed-off-by: Alex Kelly 
Reviewed-by: Josh Triplett 
---
 fs/Makefile   |   2 +-
 fs/coredump.c | 689 ++
 fs/exec.c | 647 +--
 include/linux/sched.h |   1 +
 4 files changed, 692 insertions(+), 647 deletions(-)
 create mode 100644 fs/coredump.c

diff --git a/fs/Makefile b/fs/Makefile
index 2fb9779..8938f82 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -11,7 +11,7 @@ obj-y :=  open.o read_write.o file_table.o super.o \
attr.o bad_inode.o file.o filesystems.o namespace.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o drop_caches.o splice.o sync.o utimes.o \
-   stack.o fs_struct.o statfs.o
+   stack.o fs_struct.o statfs.o coredump.o
 
 ifeq ($(CONFIG_BLOCK),y)
 obj-y +=   buffer.o bio.o block_dev.o direct-io.o mpage.o ioprio.o
diff --git a/fs/coredump.c b/fs/coredump.c
new file mode 100644
index 000..34c9236
--- /dev/null
+++ b/fs/coredump.c
@@ -0,0 +1,689 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "internal.h"
+
+#include 
+
+int core_uses_pid;
+char core_pattern[CORENAME_MAX_SIZE] = "core";
+unsigned int core_pipe_limit;
+static atomic_t call_count = ATOMIC_INIT(1);
+
+/* The maximal length of core_pattern is also specified in sysctl.c */
+static int zap_process(struct task_struct *start, int exit_code)
+{
+   struct task_struct *t;
+   int nr = 0;
+
+   start->signal->flags = SIGNAL_GROUP_EXIT;
+   start->signal->group_exit_code = exit_code;
+   start->signal->group_stop_count = 0;
+
+   t = start;
+   do {
+   task_clear_jobctl_pending(t, JOBCTL_PENDING_MASK);
+   if (t != current && t->mm) {
+   sigaddset(>pending.signal, SIGKILL);
+   signal_wake_up(t, 1);
+   nr++;
+   }
+   } while_each_thread(start, t);
+
+   return nr;
+}
+
+
+/*
+ * Core dumping helper functions.  These are the only things you should
+ * do on a core-file: use only these functions to write out all the
+ * necessary info.
+ */
+int dump_write(struct file *file, const void *addr, int nr)
+{
+   return access_ok(VERIFY_READ, addr, nr) && file->f_op->write(file, 
addr, nr, >f_pos) == nr;
+}
+EXPORT_SYMBOL(dump_write);
+
+struct core_name {
+   char *corename;
+   int used, size;
+};
+
+static int expand_corename(struct core_name *cn)
+{
+   char *old_corename = cn->corename;
+
+   cn->size = CORENAME_MAX_SIZE * atomic_inc_return(_count);
+   cn->corename = krealloc(old_corename, cn->size, GFP_KERNEL);
+
+   if (!cn->corename) {
+   kfree(old_corename);
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
+static int cn_printf(struct core_name *cn, const char *fmt, ...)
+{
+   char *cur;
+   int need;
+   int ret;
+   va_list arg;
+
+   va_start(arg, fmt);
+   need = vsnprintf(NULL, 0, fmt, arg);
+   va_end(arg);
+
+   if (likely(need < cn->size - cn->used - 1))
+   goto out_printf;
+
+   ret = expand_corename(cn);
+   if (ret)
+   goto expand_fail;
+
+out_printf:
+   cur = cn->corename + cn->used;
+   va_start(arg, fmt);
+   vsnprintf(cur, need + 1, fmt, arg);
+   va_end(arg);
+   cn->used += need;
+   return 0;
+
+expand_fail:
+   return ret;
+}
+
+static void cn_escape(char *str)
+{
+   for (; *str; str++)
+   if (*str == '/')
+   *str = '!';
+}
+
+static int cn_print_exe_file(struct core_name *cn)
+{
+   struct file *exe_file;
+   char *pathbuf, *path;
+   int ret;
+
+   exe_file = get_mm_exe_file(current->mm);
+   if (!exe_file) {
+   char *commstart = cn->corename + cn->used;
+   ret = cn_printf(cn, "%s (path unknown)", current->comm);
+   cn_escape(commstart);
+   return ret;
+   }
+
+   pathbuf = kmalloc(PATH_MAX, GFP_TEMPORARY);
+   if (!pathbuf) {
+   ret = -ENOMEM;
+   goto put_exe_file;
+   }
+
+   path = d_path(_file->f_path, pathbuf, PATH_MAX);
+   if (IS_ERR(path)) {
+   ret = PTR_ERR(path);
+   goto free_buf;
+   }
+
+   cn_escape(path);
+
+   ret = 

Re: [PATCH 1/5] code_domain: New code domain tracking susbsystem

[Frederic Weisbecker]

On Fri, Aug 03, 2012 at 01:31:44PM -0700, Paul E. McKenney wrote:
> On Fri, Aug 03, 2012 at 04:09:39PM -0400, Steven Rostedt wrote:
> > On Fri, 2012-08-03 at 21:45 +0200, Ingo Molnar wrote:
> > > * Frederic Weisbecker  wrote:
> > > 
> > > > Create a new subsystem that handles the probing on kernel 
> > > > boundaries to keep track of the transitions between code 
> > > > domains with two basic initial domains: user or kernel.
> > > 
> > > To do a bit more bike shed painting, I'd call it "context 
> > > tracking" - user mode, kernel mode (guest mode, etc.).
> > > 
> > > The term 'code domain' would bring up blank stares from most 
> > > kernel developers, me thinks.
> > 
> > Heh, that would be a second new term I heard this week for context.
> > Earlier, I noticed that Paul McKenney called it 'levels'. So now there's
> > four names:
> > 
> > user/kernel context
> > user/kernel state
> > user/kernel level
> > user/kernel domain
> > 
> > And we could probably add a fifth:
> > 
> > user/kernel mode
> 
> Plus:
> 
> user/kernel space
> 
> > ;-)
> 
> Then there is "supervisor", "system", "privileged", and who knows what
> all else for "kernel".  And "application" and "problem" and probably
> others for "user".

Hehe.

Ok I agree that domain already has a biased meaning in the kernel.

So I'm going to respin with code_context_tracking.

If anybody oppose, please raise your hand.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: fix migration thread runtime bogosity

[Peter Zijlstra]

On Fri, 2012-08-03 at 15:42 +0200, Mike Galbraith wrote:
> Greetings,
> 
> I have two bug reports of absurd migration thread CPU usage, one of them
> with a link to a bisection..
> 
>  https://bugs.gentoo.org/show_bug.cgi?id=394487
> 
> ..fingering d670ec13 - posix-cpu-timers: Cure SMP wobbles
> 
> I reproduced with my -rt kernel and 3.4, but didn't manage to reproduce
> with the 3.0 NOPREEMPT kernel it was reported against.

Ah, I've seen similar reports, never managed to reproduce though.


> Signed-off-by: Mike Galbraith 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 82ad284..82a78a6 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -974,6 +974,13 @@ void sched_set_stop_task(int cpu, struct task_struct 
> *stop)
>   sched_setscheduler_nocheck(stop, SCHED_FIFO, );
>  
>   stop->sched_class = _sched_class;
> +
> + /* Zero stale values for our non-accountable thread. */
> + stop->se.exec_start = 0;
> + stop->se.sum_exec_runtime = 0;
> + stop->se.prev_sum_exec_runtime = 0;
> + stop->stime = stop->stimescaled = 0;
> + stop->nvcsw = stop->nivcsw = 0;
>   }
>  
>   cpu_rq(cpu)->stop = stop;


Now the question is, how did that stop thing get any time to begin with?
Are we hotplugging or somesuch sillyness?


Anyway, I think I like B best, could you re-submit as a proper patch so
I can press the magic button that queues stuff?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] char/tpm: Fix compile error if CONFIG_PM is not set in tpm_i2c_infineon

[Kent Yoder]

Hi Peter,

On Fri, Aug 03, 2012 at 04:51:16PM +0200, Peter Huewe wrote:
> If CONFIG_PM was not set the compiler aborted with the following message:
> tpm_i2c_infineon.c:740:12: error: lvalue required as unary '&' operand
> 
> This patch fixes this error by not defining tpm_tis_i2c_ops as NULL if
> CONFIG_PM is not set, but only setting the suspend and resume function
> pointer as NULL

  Lets try to sync up with the work Rafael Wysocki is doing for PM.
Please take a look at these commits:

035e2ce8eb7412dbcb8522c19676a1dd52f3c024
8324be05380be044df8b70cb4bfb0c0b50eec3e5

Thanks,
Kent

> Signed-off-by: Peter Huewe 
> ---
> Sorry for the inconvenience - now tested with and without CONFIG_PM. Sorry.
> 
>  drivers/char/tpm/tpm_i2c_infineon.c |9 -
>  1 files changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_i2c_infineon.c 
> b/drivers/char/tpm/tpm_i2c_infineon.c
> index 1794a09..114e1a1 100644
> --- a/drivers/char/tpm/tpm_i2c_infineon.c
> +++ b/drivers/char/tpm/tpm_i2c_infineon.c
> @@ -674,16 +674,15 @@ static int tpm_tis_i2c_resume(struct device *dev)
>  {
>   return tpm_pm_resume(dev);
>  }
> +#else
> +#define tpm_tis_i2c_suspend NULL
> +#define tpm_tis_i2c_resume NULL
> +#endif
> 
>  static const struct dev_pm_ops tpm_tis_i2c_ops = {
>   .suspend = tpm_tis_i2c_suspend,
>   .resume = tpm_tis_i2c_resume,
>  };
> -#else
> -#define tpm_tis_i2c_suspend NULL
> -#define tpm_tis_i2c_resume NULL
> -#define tpm_tis_i2c_ops NULL
> -#endif
> 
>  static int __devinit tpm_tis_i2c_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
> -- 
> 1.7.6.msysgit.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 1/5] code_domain: New code domain tracking susbsystem

[Paul E. McKenney]

On Fri, Aug 03, 2012 at 04:09:39PM -0400, Steven Rostedt wrote:
> On Fri, 2012-08-03 at 21:45 +0200, Ingo Molnar wrote:
> > * Frederic Weisbecker  wrote:
> > 
> > > Create a new subsystem that handles the probing on kernel 
> > > boundaries to keep track of the transitions between code 
> > > domains with two basic initial domains: user or kernel.
> > 
> > To do a bit more bike shed painting, I'd call it "context 
> > tracking" - user mode, kernel mode (guest mode, etc.).
> > 
> > The term 'code domain' would bring up blank stares from most 
> > kernel developers, me thinks.
> 
> Heh, that would be a second new term I heard this week for context.
> Earlier, I noticed that Paul McKenney called it 'levels'. So now there's
> four names:
> 
> user/kernel context
> user/kernel state
> user/kernel level
> user/kernel domain
> 
> And we could probably add a fifth:
> 
> user/kernel mode

Plus:

user/kernel space

> ;-)

Then there is "supervisor", "system", "privileged", and who knows what
all else for "kernel".  And "application" and "problem" and probably
others for "user".

Thanx, Paul

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

Re: Linux 3.6-rc1

[Linus Torvalds]

On Thu, Aug 2, 2012 at 11:47 PM, Artem Bityutskiy  wrote:
>
> We have had 11 of 13 pieces of the 'sync_supers()' removal patch-sets
> merged. The 12th piece removes dead code in exofs was supposed to go
> through the exofs tree and blocked the 13th piece which removes
> 'sync_supers()' and was supposed to go via the VFS tree.
>
> Both 12th and 13th pieces zap dead code. I man not sure delaying that to
> v3.7 would be very beneficial for the kernel (why having a useless
> thread waking up every 5 secs?). Would you let us merge this to -rc1?

Ok. I'm pulling the exofs changes, they're small and remove more lines
than they add. And if the last piece then just kills dead code, I
won't mind that either.

   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: oops in pci_acs_path_enabled

[Alex Williamson]

On Fri, 2012-08-03 at 11:39 -0600, David Ahern wrote:
> Hi Alex:
> 
> Hitting an oops with 3.6-rc1. Backtrace from console attached. git blame 
> for the top function points to ad805758.

Hey David,

Hmm, what's special about your system?  I've got an 82576 here and the
same path works fine.  Any way you can get the top of the oops message?
Thanks,

Alex

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

[Aaro Koskinen]

Hi,

On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote:
> > And really: Wasting 1/3 of the 80 character line is too much.
> 
> You _WASTE_ 4 chars only if you are interested in this info by
> enabling: CONFIG_PRINTK_CPUID

I guess you waste 4 + 3 chars? You could optimize the length by checking
CONFIG_NR_CPUS?

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

Re: [PATCH v2 01/10] KVM: iommu: fix releasing unmapped page

[Marcelo Tosatti]

On Fri, Aug 03, 2012 at 03:36:52PM +0800, Xiao Guangrong wrote:
> There are two bugs:
> - the 'error page' is forgot to be released
>   [ it is unneeded after commit a2766325cf9f9, for backport, we
> still do kvm_release_pfn_clean for the error pfn ]
> 
> - guest pages are always released regardless of the unmapped page
>   (e,g, caused by hwpoison)
> 
> Signed-off-by: Xiao Guangrong 

Looks good.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] code_domain: New code domain tracking susbsystem

[Steven Rostedt]

On Fri, 2012-08-03 at 21:45 +0200, Ingo Molnar wrote:
> * Frederic Weisbecker  wrote:
> 
> > Create a new subsystem that handles the probing on kernel 
> > boundaries to keep track of the transitions between code 
> > domains with two basic initial domains: user or kernel.
> 
> To do a bit more bike shed painting, I'd call it "context 
> tracking" - user mode, kernel mode (guest mode, etc.).
> 
> The term 'code domain' would bring up blank stares from most 
> kernel developers, me thinks.

Heh, that would be a second new term I heard this week for context.
Earlier, I noticed that Paul McKenney called it 'levels'. So now there's
four names:

user/kernel context
user/kernel state
user/kernel level
user/kernel domain

And we could probably add a fifth:

user/kernel mode

;-)

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Tree for Aug 3 (drivers/i2c/busses/i2c-i801.c)

[Jean Delvare]

Hi Randy,

On Fri, 03 Aug 2012 10:24:34 -0700, Randy Dunlap wrote:
> on x86_64:
> 
> when CONFIG_GPIOLIB is not enabled:
> 
> drivers/i2c/busses/i2c-i801.c: In function 'match_gpio_chip_by_label':
> drivers/i2c/busses/i2c-i801.c:1011:21: error: dereferencing pointer to 
> incomplete type
> drivers/i2c/busses/i2c-i801.c: In function 'i801_add_mux':
> drivers/i2c/busses/i2c-i801.c:1028:2: error: implicit declaration of function 
> 'gpiochip_find'
> drivers/i2c/busses/i2c-i801.c:1028:7: warning: assignment makes pointer from 
> integer without a cast
> drivers/i2c/busses/i2c-i801.c:1047:27: error: dereferencing pointer to 
> incomplete type
> drivers/i2c/busses/i2c-i801.c: In function 'match_gpio_chip_by_label':
> drivers/i2c/busses/i2c-i801.c:1012:1: warning: control reaches end of 
> non-void function

Good catch, thanks for reporting. I'll fold the following in the
offending patch, that should fix it:

--- linux-3.6-rc0.orig/drivers/i2c/busses/Kconfig   2012-08-03 
21:51:51.0 +0200
+++ linux-3.6-rc0/drivers/i2c/busses/Kconfig2012-08-03 21:52:18.090537018 
+0200
@@ -80,6 +80,7 @@ config I2C_I801
tristate "Intel 82801 (ICH/PCH)"
depends on PCI
select CHECK_SIGNATURE if X86 && DMI
+   select GPIOLIB if I2C_MUX
help
  If you say yes to this option, support will be included for the Intel
  801 family of mainboard I2C interfaces.  Specifically, the following


-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-Wire: Add support for the maxim ds1825 temperature sensor

[Raphael Assenat]

This patch adds support for maxim ds1825 based 1-wire temperature sensors.

diff --git a/Documentation/w1/slaves/w1_therm b/Documentation/w1/slaves/w1_therm
index 0403aaa..874a8ca 100644
--- a/Documentation/w1/slaves/w1_therm
+++ b/Documentation/w1/slaves/w1_therm
@@ -3,6 +3,7 @@ Kernel driver w1_therm
 
 Supported chips:
   * Maxim ds18*20 based temperature sensors.
+  * Maxim ds1825 based temperature sensors.
 
 Author: Evgeniy Polyakov 
 
@@ -15,6 +16,7 @@ supported family codes:
 W1_THERM_DS18S20   0x10
 W1_THERM_DS18220x22
 W1_THERM_DS18B20   0x28
+W1_THERM_DS18250x3B
 
 Support is provided through the sysfs w1_slave file.  Each open and
 read sequence will initiate a temperature conversion then provide two
diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index ff29ae7..b34bf1d 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -91,6 +91,11 @@ static struct w1_family w1_therm_family_DS28EA00 = {
.fops = _therm_fops,
 };
 
+static struct w1_family w1_therm_family_DS1825 = {
+   .fid = W1_THERM_DS1825,
+   .fops = _therm_fops,
+};
+
 struct w1_therm_family_converter
 {
u8  broken;
@@ -120,6 +125,10 @@ static struct w1_therm_family_converter 
w1_therm_families[] = {
.f  = _therm_family_DS28EA00,
.convert= w1_DS18B20_convert_temp
},
+   {
+   .f  = _therm_family_DS1825,
+   .convert= w1_DS18B20_convert_temp
+   }
 };
 
 static inline int w1_DS18B20_convert_temp(u8 rom[9])
diff --git a/drivers/w1/w1_family.h b/drivers/w1/w1_family.h
index 874aeb0..b998c30 100644
--- a/drivers/w1/w1_family.h
+++ b/drivers/w1/w1_family.h
@@ -38,6 +38,7 @@
 #define W1_EEPROM_DS2431   0x2D
 #define W1_FAMILY_DS2760   0x30
 #define W1_FAMILY_DS2780   0x32
+#define W1_THERM_DS18250x3B
 #define W1_FAMILY_DS2781   0x3D
 #define W1_THERM_DS28EA00  0x42
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/