Re: [PATCH 1/1] ext3: Add __init macro to init_inodecache
On Sat 01-02-14 19:13:00, Fabian Frederick wrote:
> init_inodecache is only called by __init init_ext3_fs.
Thanks. Added to my tree.
Honza
>
> Signed-off-by: Fabian Frederick
> ---
> fs/ext3/super.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ext3/super.c b/fs/ext3/super.c
> index 37fd31e..94608d4 100644
> --- a/fs/ext3/super.c
> +++ b/fs/ext3/super.c
> @@ -527,7 +527,7 @@ static void init_once(void *foo)
> inode_init_once(>vfs_inode);
> }
>
> -static int init_inodecache(void)
> +static int __init init_inodecache(void)
> {
> ext3_inode_cachep = kmem_cache_create("ext3_inode_cache",
>sizeof(struct ext3_inode_info),
> --
> 1.8.1.4
>
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] udf: Add __init macro to init_inodecache
On Sat 01-02-14 15:45:18, Fabian Frederick wrote:
> init_inodecache is only called by __init init_udf_fs.
Thanks. Added to my tree.
Honza
>
> Signed-off-by: Fabian Frederick
> ---
> fs/udf/super.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index 3306b9f..6a14649 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -175,7 +175,7 @@ static void init_once(void *foo)
> inode_init_once(>vfs_inode);
> }
>
> -static int init_inodecache(void)
> +static int __init init_inodecache(void)
> {
> udf_inode_cachep = kmem_cache_create("udf_inode_cache",
>sizeof(struct udf_inode_info),
> --
> 1.8.1.4
>
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ext2: Add __init macro to init_inodecache
On Sat 01-02-14 16:02:02, Fabian Frederick wrote:
> init_inodecache is only called by __init init_ext2_fs.
Thanks added to my tree.
Honza
>
> Signed-off-by: Fabian Frederick
> ---
> fs/ext2/super.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ext2/super.c b/fs/ext2/super.c
> index 20d6697..73d80da 100644
> --- a/fs/ext2/super.c
> +++ b/fs/ext2/super.c
> @@ -192,7 +192,7 @@ static void init_once(void *foo)
> inode_init_once(>vfs_inode);
> }
>
> -static int init_inodecache(void)
> +static int __init init_inodecache(void)
> {
> ext2_inode_cachep = kmem_cache_create("ext2_inode_cache",
>sizeof(struct ext2_inode_info),
> --
> 1.8.1.4
>
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/3] Deferrable timers support for timerfd API
On 02/02/2014 10:54 PM, Alexey Perevalov wrote: > Dear John, hello > > could we figure out without Thomas advice? > Maybe it worth to propose timerfd and posix timer flag unification patch? That would likely get his attention (and possibly wrath)... so not a bad idea! ;) 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/
[PATCH 2/2] ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled
From: Stephen Warren
(This is upstream 75fae117a5db "ALSA: hda/hdmi - allow PIN_OUT to be
dynamically enabled", backported to stable 3.10 through 3.12. 3.13 and
later can take the original patch.)
Commit 384a48d71520 "ALSA: hda: HDMI: Support codecs with fewer cvts
than pins" dynamically enabled each pin widget's PIN_OUT only when the
pin was actively in use. This was required on certain NVIDIA CODECs for
correct operation. Specifically, if multiple pin widgets each had their
mux input select the same audio converter widget and each pin widget had
PIN_OUT enabled, then only one of the pin widgets would actually receive
the audio, and often not the one the user wanted!
However, this apparently broke some Intel systems, and commit
6169b673618b "ALSA: hda - Always turn on pins for HDMI/DP" reverted the
dynamic setting of PIN_OUT. This in turn broke the afore-mentioned NVIDIA
CODECs.
This change supports either dynamic or static handling of PIN_OUT,
selected by a flag set up during CODEC initialization. This flag is
enabled for all recent NVIDIA GPUs.
Reported-by: Uosis
Signed-off-by: Stephen Warren
---
sound/pci/hda/patch_hdmi.c | 40
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index aad73a1fc2cd..417e0fc2d119 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -88,6 +88,9 @@ struct hdmi_spec {
unsigned int channels_max; /* max over all cvts */
struct hdmi_eld temp_eld;
+
+ bool dyn_pin_out;
+
/*
* Non-generic ATI/NVIDIA specific
*/
@@ -452,15 +455,25 @@ static void hdmi_write_dip_byte(struct hda_codec *codec,
hda_nid_t pin_nid,
static void hdmi_init_pin(struct hda_codec *codec, hda_nid_t pin_nid)
{
+ struct hdmi_spec *spec = codec->spec;
+ int pin_out;
+
/* Unmute */
if (get_wcaps(codec, pin_nid) & AC_WCAP_OUT_AMP)
snd_hda_codec_write(codec, pin_nid, 0,
AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE);
- /* Enable pin out: some machines with GM965 gets broken output when
-* the pin is disabled or changed while using with HDMI
-*/
+
+ if (spec->dyn_pin_out)
+ /* Disable pin out until stream is active */
+ pin_out = 0;
+ else
+ /* Enable pin out: some machines with GM965 gets broken output
+* when the pin is disabled or changed while using with HDMI
+*/
+ pin_out = PIN_OUT;
+
snd_hda_codec_write(codec, pin_nid, 0,
- AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT);
+ AC_VERB_SET_PIN_WIDGET_CONTROL, pin_out);
}
static int hdmi_get_channel_count(struct hda_codec *codec, hda_nid_t cvt_nid)
@@ -1535,6 +1548,7 @@ static int generic_hdmi_playback_pcm_prepare(struct
hda_pcm_stream *hinfo,
struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx);
hda_nid_t pin_nid = per_pin->pin_nid;
bool non_pcm;
+ int pinctl;
non_pcm = check_non_pcm_per_cvt(codec, cvt_nid);
per_pin->channels = substream->runtime->channels;
@@ -1544,6 +1558,14 @@ static int generic_hdmi_playback_pcm_prepare(struct
hda_pcm_stream *hinfo,
hdmi_setup_audio_infoframe(codec, per_pin, non_pcm);
+ if (spec->dyn_pin_out) {
+ pinctl = snd_hda_codec_read(codec, pin_nid, 0,
+ AC_VERB_GET_PIN_WIDGET_CONTROL, 0);
+ snd_hda_codec_write(codec, pin_nid, 0,
+ AC_VERB_SET_PIN_WIDGET_CONTROL,
+ pinctl | PIN_OUT);
+ }
+
return hdmi_setup_stream(codec, cvt_nid, pin_nid, stream_tag, format);
}
@@ -1563,6 +1585,7 @@ static int hdmi_pcm_close(struct hda_pcm_stream *hinfo,
int cvt_idx, pin_idx;
struct hdmi_spec_per_cvt *per_cvt;
struct hdmi_spec_per_pin *per_pin;
+ int pinctl;
if (hinfo->nid) {
cvt_idx = cvt_nid_to_cvt_index(spec, hinfo->nid);
@@ -1579,6 +1602,14 @@ static int hdmi_pcm_close(struct hda_pcm_stream *hinfo,
return -EINVAL;
per_pin = get_pin(spec, pin_idx);
+ if (spec->dyn_pin_out) {
+ pinctl = snd_hda_codec_read(codec, per_pin->pin_nid, 0,
+ AC_VERB_GET_PIN_WIDGET_CONTROL, 0);
+ snd_hda_codec_write(codec, per_pin->pin_nid, 0,
+ AC_VERB_SET_PIN_WIDGET_CONTROL,
+ pinctl & ~PIN_OUT);
+ }
+
snd_hda_spdif_ctls_unassign(codec, pin_idx);
per_pin->chmap_set = false;
memset(per_pin->chmap, 0, sizeof(per_pin->chmap));
@@ -2570,6 +2601,7 @@ static int patch_nvhdmi(struct
Re: [PATCH] Fix lockdep false positive in add_full()
On Mon, Feb 03, 2014 at 03:31:40PM -0800, David Rientjes wrote: > On Mon, 3 Feb 2014, Paul E. McKenney wrote: > > > Hello! > > > > The add_full() function currently has a lockdep_assert_held() requiring > > that the kmem_cache_node structure's ->list_lock be held. However, > > this lock is not acquired by add_full()'s caller deactivate_slab() > > in the full-node case unless debugging is enabled. Because full nodes > > are accessed only by debugging code, this state of affairs results in > > lockdep false-positive splats like the following: > > > > [ 43.942868] WARNING: CPU: 0 PID: 698 at > > /home/paulmck/public_git/linux-rcu/mm/slub.c:1007 > > deactivate_slab+0x509/0x720() > > [ 43.943016] Modules linked in: > > [ 43.943016] CPU: 0 PID: 698 Comm: torture_onoff Not tainted 3.14.0-rc1+ > > #1 > > [ 43.943016] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 > > [ 43.943016] 03ef 88001e3f5ba8 818952ec > > 0046 > > [ 43.943016] 88001e3f5be8 81049517 > > ea784e00 > > [ 43.943016] ea7a9000 0002 > > > > [ 43.943016] Call Trace: > > [ 43.943016] [] dump_stack+0x46/0x58 > > [ 43.943016] [] warn_slowpath_common+0x87/0xb0 > > [ 43.943016] [] warn_slowpath_null+0x15/0x20 > > [ 43.943016] [] deactivate_slab+0x509/0x720 > > [ 43.943016] [] ? slab_cpuup_callback+0x3b/0x100 > > [ 43.943016] [] ? slab_cpuup_callback+0xd2/0x100 > > [ 43.943016] [] slab_cpuup_callback+0xa4/0x100 > > [ 43.943016] [] notifier_call_chain+0x54/0x110 > > [ 43.943016] [] __raw_notifier_call_chain+0x9/0x10 > > [ 43.943016] [] __cpu_notify+0x1b/0x30 > > [ 43.943016] [] cpu_notify_nofail+0x10/0x20 > > [ 43.943016] [] _cpu_down+0x10d/0x2e0 > > [ 43.943016] [] cpu_down+0x30/0x50 > > [ 43.943016] [] torture_onoff+0xd3/0x3c0 > > [ 43.943016] [] ? torture_onoff_stats+0x90/0x90 > > [ 43.943016] [] kthread+0xdf/0x100 > > [ 43.943016] [] ? _raw_spin_unlock_irq+0x2b/0x40 > > [ 43.943016] [] ? flush_kthread_worker+0x130/0x130 > > [ 43.943016] [] ret_from_fork+0x7c/0xb0 > > [ 43.943016] [] ? flush_kthread_worker+0x130/0x130 > > > > This commit therefore does the lockdep check only if debuggging is > > enabled, thus avoiding the false positives. > > > > Signed-off-by: Paul E. McKenney > > This was discussed in http://marc.info/?t=13914579132, what do you > think about the patch in that thread instead? Looks fine to me! I also tried it out and it avoided the splats, as noted in my mail in the other thread, so please feel free to add my Tested-by. 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/
[patch for-3.14] mm, slub: list_lock may not be held in some circumstances
Commit c65c1877bd68 ("slub: use lockdep_assert_held") incorrectly required
that add_full() and remove_full() hold n->list_lock. The lock is only
taken when kmem_cache_debug(s), since that's the only time it actually
does anything.
Require that the lock only be taken under such a condition.
Reported-by: Larry Finger
Tested-by: Larry Finger
Tested-by: Paul E. McKenney
Acked-by: Christoph Lameter
Signed-off-by: David Rientjes
---
mm/slub.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1004,21 +1004,19 @@ static inline void slab_free_hook(struct kmem_cache *s,
void *x)
static void add_full(struct kmem_cache *s,
struct kmem_cache_node *n, struct page *page)
{
- lockdep_assert_held(>list_lock);
-
if (!(s->flags & SLAB_STORE_USER))
return;
+ lockdep_assert_held(>list_lock);
list_add(>lru, >full);
}
static void remove_full(struct kmem_cache *s, struct kmem_cache_node *n,
struct page *page)
{
- lockdep_assert_held(>list_lock);
-
if (!(s->flags & SLAB_STORE_USER))
return;
+ lockdep_assert_held(>list_lock);
list_del(>lru);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel WARNING splat in 3.14-rc1
On Mon, Feb 03, 2014 at 05:08:11PM -0600, Larry Finger wrote:
> On 02/03/2014 02:39 PM, David Rientjes wrote:
> >Commit c65c1877bd68 ("slub: use lockdep_assert_held") incorrectly required
> >that add_full() and remove_full() hold n->list_lock. The lock is only
> >taken when kmem_cache_debug(s), since that's the only time it actually
> >does anything.
> >
> >Require that the lock only be taken under such a condition.
> >
> >Reported-by: Larry Finger
> >Signed-off-by: David Rientjes
>
> You may add a "Tested-by: Larry Finger ".
> The patch cleans up the splat on my system. Thanks for the quick
> response.
Please feel free to add mine as well:
Tested-by: Paul E. McKenney
And also feel free to ignore my patch as well. ;-)
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: + arch-x86-mm-numa_32c-fix-the-initialization-of-physnode_map.patch added to -mm tree
On Mon, 3 Feb 2014, a...@linux-foundation.org wrote:
> From: Petr Tesarik
> Subject: arch/x86/mm/numa_32.c: fix the initialization of physnode_map
>
> With DISCONTIGMEM, the mapping between a pfn and its owning node is
> initialized using data provided by the BIOS. However, the initialization
> may fail if the extents are not aligned to section boundary (64M).
>
> The symptom of this bug is an early boot failure in pfn_to_page(), as it
> tries to access NODE_DATA(__nid) using index from an unitialized element
> of the physnode_map[] array.
>
> While the bug is always present, it is more likely to be hit in kdump
> kernels on large machines, because:
>
> 1. The memory map for a kdump kernel is specified as exactmap, and
>exactmap is more likely to be unaligned.
>
> 2. Large reservations are more likely to span across a 64M boundary.
>
> Signed-off-by: Petr Tesarik
> Signed-off-by: Andrew Morton
> ---
>
> arch/x86/mm/numa_32.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff -puN
> arch/x86/mm/numa_32.c~arch-x86-mm-numa_32c-fix-the-initialization-of-physnode_map
> arch/x86/mm/numa_32.c
> ---
> a/arch/x86/mm/numa_32.c~arch-x86-mm-numa_32c-fix-the-initialization-of-physnode_map
> +++ a/arch/x86/mm/numa_32.c
> @@ -52,6 +52,8 @@ void memory_present(int nid, unsigned lo
> nid, start, end);
> printk(KERN_DEBUG " Setting physnode_map array to node %d for
> pfns:\n", nid);
> printk(KERN_DEBUG " ");
> + pfn = round_down(pfn, PAGES_PER_SECTION);
> + end = round_up(end, PAGES_PER_SECTION);
> for (pfn = start; pfn < end; pfn += PAGES_PER_SECTION) {
> physnode_map[pfn / PAGES_PER_SECTION] = nid;
> printk(KERN_CONT "%lx ", pfn);
This is the buggy version of the patch which erroneously rounds down the
uninitialized "pfn" rather than "start". hpa has already merged the
corrected patch into x86/urgent.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 21/24][Resend] ACPI / hotplug / PCI: Rework the handling of eject requests
From: Rafael J. Wysocki
To avoid the need to install a hotplug notify handler for each ACPI
namespace node representing a device and having a matching scan
handler, move the check whether or not the ejection of the given
device is enabled through its scan handler from acpi_hotplug_notify_cb()
to acpi_generic_hotplug_event(). Also, move the execution of
ACPI_OST_SC_EJECT_IN_PROGRESS _OST to acpi_generic_hotplug_event(),
because in acpi_hotplug_notify_cb() or in acpi_eject_store() we really
don't know whether or not the eject is going to be in progress (for
example, acpi_hotplug_execute() may still fail without queuing up the
work item).
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/acpi/scan.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -459,6 +459,12 @@ static int acpi_generic_hotplug_event(st
return acpi_scan_device_check(adev);
case ACPI_NOTIFY_EJECT_REQUEST:
case ACPI_OST_EC_OSPM_EJECT:
+ if (adev->handler && !adev->handler->hotplug.enabled) {
+ dev_info(>dev, "Eject disabled\n");
+ return -EPERM;
+ }
+ acpi_evaluate_hotplug_ost(adev->handle,
ACPI_NOTIFY_EJECT_REQUEST,
+ ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
return acpi_scan_hot_remove(adev);
}
return -EINVAL;
@@ -483,6 +489,10 @@ static void acpi_device_hotplug(void *da
if (adev->handler) {
error = acpi_generic_hotplug_event(adev, src);
+ if (error == -EPERM) {
+ ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
+ goto err_out;
+ }
} else {
int (*event)(struct acpi_device *, u32);
@@ -512,7 +522,6 @@ static void acpi_device_hotplug(void *da
static void acpi_hotplug_notify_cb(acpi_handle handle, u32 type, void *data)
{
- struct acpi_scan_handler *handler = data;
u32 ost_code = ACPI_OST_SC_SUCCESS;
struct acpi_device *adev;
acpi_status status;
@@ -528,13 +537,6 @@ static void acpi_hotplug_notify_cb(acpi_
case ACPI_NOTIFY_EJECT_REQUEST:
acpi_handle_debug(handle, "ACPI_NOTIFY_EJECT_REQUEST event\n");
- if (handler && !handler->hotplug.enabled) {
- acpi_handle_err(handle, "Eject disabled\n");
- ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
- goto out;
- }
- acpi_evaluate_hotplug_ost(handle, ACPI_NOTIFY_EJECT_REQUEST,
- ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
break;
case ACPI_NOTIFY_DEVICE_WAKE:
@@ -632,8 +634,6 @@ acpi_eject_store(struct device *d, struc
if (ACPI_FAILURE(status) || !acpi_device->flags.ejectable)
return -ENODEV;
- acpi_evaluate_hotplug_ost(acpi_device->handle, ACPI_OST_EC_OSPM_EJECT,
- ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
get_device(_device->dev);
status = acpi_hotplug_execute(acpi_device_hotplug, acpi_device,
ACPI_OST_EC_OSPM_EJECT);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 23/24][Update] ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify()
From: Rafael J. Wysocki
Since acpi_bus_notify() is executed on all notifications for all
devices anyway, make it execute acpi_device_hotplug() for all
hotplug events instead of installing notify handlers pointing to
the same function for all hotplug devices.
This change reduces both the size and complexity of ACPI-based device
hotplug code. Moreover, since acpi_device_hotplug() only does
significant things for devices that have either an ACPI scan handler,
or a hotplug context with .eject() defined, and those devices
had notify handlers pointing to acpi_hotplug_notify_cb() installed
before anyway, this modification shouldn't change functionality.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/bus.c | 61 +-
drivers/acpi/internal.h|1
drivers/acpi/scan.c| 101 -
drivers/pci/hotplug/acpiphp.h |1
drivers/pci/hotplug/acpiphp_glue.c | 24
include/acpi/acpi_bus.h|2
6 files changed, 53 insertions(+), 137 deletions(-)
Index: linux-pm/drivers/acpi/bus.c
===
--- linux-pm.orig/drivers/acpi/bus.c
+++ linux-pm/drivers/acpi/bus.c
@@ -340,62 +340,77 @@ static void acpi_bus_osc_support(void)
*/
static void acpi_bus_notify(acpi_handle handle, u32 type, void *data)
{
- struct acpi_device *device;
+ struct acpi_device *adev;
struct acpi_driver *driver;
-
- ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Notification %#02x to handle %p\n",
- type, handle));
+ acpi_status status;
+ u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
switch (type) {
-
case ACPI_NOTIFY_BUS_CHECK:
- /* TBD */
+ acpi_handle_debug(handle, "ACPI_NOTIFY_BUS_CHECK event\n");
break;
case ACPI_NOTIFY_DEVICE_CHECK:
- /* TBD */
+ acpi_handle_debug(handle, "ACPI_NOTIFY_DEVICE_CHECK event\n");
break;
case ACPI_NOTIFY_DEVICE_WAKE:
- /* TBD */
+ acpi_handle_debug(handle, "ACPI_NOTIFY_DEVICE_WAKE event\n");
break;
case ACPI_NOTIFY_EJECT_REQUEST:
- /* TBD */
+ acpi_handle_debug(handle, "ACPI_NOTIFY_EJECT_REQUEST event\n");
break;
case ACPI_NOTIFY_DEVICE_CHECK_LIGHT:
+ acpi_handle_debug(handle, "ACPI_NOTIFY_DEVICE_CHECK_LIGHT
event\n");
/* TBD: Exactly what does 'light' mean? */
break;
case ACPI_NOTIFY_FREQUENCY_MISMATCH:
- /* TBD */
+ acpi_handle_err(handle, "Device cannot be configured due "
+ "to a frequency mismatch\n");
break;
case ACPI_NOTIFY_BUS_MODE_MISMATCH:
- /* TBD */
+ acpi_handle_err(handle, "Device cannot be configured due "
+ "to a bus mode mismatch\n");
break;
case ACPI_NOTIFY_POWER_FAULT:
- /* TBD */
+ acpi_handle_err(handle, "Device has suffered a power fault\n");
break;
default:
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "Received unknown/unsupported notification
[%08x]\n",
- type));
- break;
+ acpi_handle_warn(handle, "Unsupported event type 0x%x\n", type);
+ ost_code = ACPI_OST_SC_UNRECOGNIZED_NOTIFY;
+ goto err;
}
- device = acpi_bus_get_acpi_device(handle);
- if (device) {
- driver = device->driver;
- if (driver && driver->ops.notify &&
- (driver->flags & ACPI_DRIVER_ALL_NOTIFY_EVENTS))
- driver->ops.notify(device, type);
+ adev = acpi_bus_get_acpi_device(handle);
+ if (!adev)
+ goto err;
+
+ driver = adev->driver;
+ if (driver && driver->ops.notify &&
+ (driver->flags & ACPI_DRIVER_ALL_NOTIFY_EVENTS))
+ driver->ops.notify(adev, type);
- acpi_bus_put_acpi_device(device);
+ switch (type) {
+ case ACPI_NOTIFY_BUS_CHECK:
+ case ACPI_NOTIFY_DEVICE_CHECK:
+ case ACPI_NOTIFY_EJECT_REQUEST:
+ status = acpi_hotplug_execute(acpi_device_hotplug, adev, type);
+ if (ACPI_SUCCESS(status))
+ return;
+ default:
+ break;
}
+ acpi_bus_put_acpi_device(adev);
+ return;
+
+ err:
+ acpi_evaluate_hotplug_ost(handle, type, ost_code, NULL);
}
/* --
Index: linux-pm/drivers/acpi/internal.h
===
--- linux-pm.orig/drivers/acpi/internal.h
+++
[PATCH 20/24][Update] ACPI / hotplug / PCI: Consolidate ACPIPHP with ACPI core hotplug
From: Rafael J. Wysocki
The ACPI-based PCI hotplug (ACPIPHP) code currently attaches its
hotplug context objects directly to ACPI namespace nodes representing
hotplug devices. However, after recent changes causing struct
acpi_device to be created for every namespace node representing a
device (regardless of its status), that is not necessary any more.
Moreover, it's vulnerable to a theoretical issue that the ACPI
handle passed in the context between handle_hotplug_event() and
hotplug_event_work() may become invalid in the meantime (as a
result of a concurrent table unload).
In principle, this issue might be addressed by adding a non-empty
release handler for ACPIPHP hotplug context objects analogous to
acpi_scan_drop_device(), but that would duplicate the code in that
function and in acpi_device_del_work_fn(). For this reason, it's
better to modify ACPIPHP to attach its device hotplug contexts to
struct device objects representing hotplug devices and make it
use acpi_hotplug_notify_cb() as its notify handler. At the same
time, acpi_device_hotplug() can be modified to dispatch the new
.hp.event() callback pointing to acpiphp_hotplug_event() from ACPI
device objects associated with PCI devices and use the generic
ACPI device hotplug code for device objects with scan handlers
attached to them.
This allows the existing code duplication between ACPIPHP and the
ACPI core to be reduced too and makes further ACPI-based device
hotplug consolidation possible.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c| 106 +--
drivers/pci/hotplug/acpiphp.h |9 +-
drivers/pci/hotplug/acpiphp_glue.c | 164 +++--
include/acpi/acpi_bus.h| 22
4 files changed, 142 insertions(+), 159 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -450,43 +450,61 @@ static int acpi_scan_bus_check(struct ac
return 0;
}
+static int acpi_generic_hotplug_event(struct acpi_device *adev, u32 type)
+{
+ switch (type) {
+ case ACPI_NOTIFY_BUS_CHECK:
+ return acpi_scan_bus_check(adev);
+ case ACPI_NOTIFY_DEVICE_CHECK:
+ return acpi_scan_device_check(adev);
+ case ACPI_NOTIFY_EJECT_REQUEST:
+ case ACPI_OST_EC_OSPM_EJECT:
+ return acpi_scan_hot_remove(adev);
+ }
+ return -EINVAL;
+}
+
static void acpi_device_hotplug(void *data, u32 src)
{
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
struct acpi_device *adev = data;
- int error;
+ int error = -ENODEV;
lock_device_hotplug();
mutex_lock(_scan_lock);
/*
* The device object's ACPI handle cannot become invalid as long as we
-* are holding acpi_scan_lock, but it may have become invalid before
+* are holding acpi_scan_lock, but it might have become invalid before
* that lock was acquired.
*/
if (adev->handle == INVALID_ACPI_HANDLE)
- goto out;
+ goto err_out;
- switch (src) {
- case ACPI_NOTIFY_BUS_CHECK:
- error = acpi_scan_bus_check(adev);
- break;
- case ACPI_NOTIFY_DEVICE_CHECK:
- error = acpi_scan_device_check(adev);
- break;
- case ACPI_NOTIFY_EJECT_REQUEST:
- case ACPI_OST_EC_OSPM_EJECT:
- error = acpi_scan_hot_remove(adev);
- break;
- default:
- error = -EINVAL;
- break;
+ if (adev->handler) {
+ error = acpi_generic_hotplug_event(adev, src);
+ } else {
+ int (*event)(struct acpi_device *, u32);
+
+ acpi_lock_hp_context();
+ event = adev->hp ? adev->hp->event : NULL;
+ acpi_unlock_hp_context();
+ /*
+* There may be additional notify handlers for device objects
+* without the .event() callback, so ignore them here.
+*/
+ if (event)
+ error = event(adev, src);
+ else
+ goto out;
}
if (!error)
ost_code = ACPI_OST_SC_SUCCESS;
- out:
+ err_out:
acpi_evaluate_hotplug_ost(adev->handle, src, ost_code, NULL);
+
+ out:
acpi_bus_put_acpi_device(adev);
mutex_unlock(_scan_lock);
unlock_device_hotplug();
@@ -494,8 +512,8 @@ static void acpi_device_hotplug(void *da
static void acpi_hotplug_notify_cb(acpi_handle handle, u32 type, void *data)
{
- u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
struct acpi_scan_handler *handler = data;
+ u32 ost_code = ACPI_OST_SC_SUCCESS;
struct acpi_device *adev;
acpi_status status;
@@ -503,26 +521,49 @@ static void
[PATCH 18/24][Update] ACPI / hotplug: Fix potential race in acpi_bus_notify()
From: Rafael J. Wysocki
There is a slight possibility for the ACPI device object pointed to
by adev in acpi_hotplug_notify_cb() to become invalid between the
acpi_bus_get_device() that it comes from and the subsequent dereference
of that pointer under get_device(). Namely, if acpi_scan_drop_device()
runs in parallel with acpi_hotplug_notify_cb(), acpi_device_del_work_fn()
queued up by it may delete the device object in question right after
a successful execution of acpi_bus_get_device() in acpi_bus_notify().
An analogous problem is present in acpi_bus_notify() where the device
pointer coming from acpi_bus_get_device() may become invalid before
it subsequent dereference in the "if" block.
To prevent that from happening, introduce a new function,
acpi_bus_get_acpi_device(), working analogously to acpi_bus_get_device()
except that it will grab a reference to the ACPI device object returned
by it and it will do that under the ACPICA's namespace mutex. Then,
make both acpi_hotplug_notify_cb() and acpi_bus_notify() use
acpi_bus_get_acpi_device() instead of acpi_bus_get_device() so as to
ensure that the pointers used by them will not become stale at one
point.
In addition to that, introduce acpi_bus_put_acpi_device() as a wrapper
around put_device() to be used along with acpi_bus_get_acpi_device()
and make the (new) users of the latter use acpi_bus_put_acpi_device()
too.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/bus.c |6 --
drivers/acpi/scan.c | 42 ++
include/acpi/acpi_bus.h |2 ++
3 files changed, 40 insertions(+), 10 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -476,7 +476,7 @@ static void acpi_device_hotplug(void *da
out:
acpi_evaluate_hotplug_ost(adev->handle, src, ost_code, NULL);
- put_device(>dev);
+ acpi_bus_put_acpi_device(adev);
mutex_unlock(_scan_lock);
unlock_device_hotplug();
}
@@ -488,9 +488,6 @@ static void acpi_hotplug_notify_cb(acpi_
struct acpi_device *adev;
acpi_status status;
- if (acpi_bus_get_device(handle, ))
- goto err_out;
-
switch (type) {
case ACPI_NOTIFY_BUS_CHECK:
acpi_handle_debug(handle, "ACPI_NOTIFY_BUS_CHECK event\n");
@@ -512,12 +509,15 @@ static void acpi_hotplug_notify_cb(acpi_
/* non-hotplug event; possibly handled by other handler */
return;
}
- get_device(>dev);
+ adev = acpi_bus_get_acpi_device(handle);
+ if (!adev)
+ goto err_out;
+
status = acpi_hotplug_execute(acpi_device_hotplug, adev, type);
if (ACPI_SUCCESS(status))
return;
- put_device(>dev);
+ acpi_bus_put_acpi_device(adev);
err_out:
acpi_evaluate_hotplug_ost(handle, type, ost_code, NULL);
@@ -1112,14 +1112,16 @@ static void acpi_scan_drop_device(acpi_h
mutex_unlock(_device_del_lock);
}
-int acpi_bus_get_device(acpi_handle handle, struct acpi_device **device)
+static int acpi_get_device_data(acpi_handle handle, struct acpi_device
**device,
+ void (*callback)(void *))
{
acpi_status status;
if (!device)
return -EINVAL;
- status = acpi_get_data(handle, acpi_scan_drop_device, (void **)device);
+ status = acpi_get_data_full(handle, acpi_scan_drop_device,
+ (void **)device, callback);
if (ACPI_FAILURE(status) || !*device) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No context for object [%p]\n",
handle));
@@ -1127,8 +1129,32 @@ int acpi_bus_get_device(acpi_handle hand
}
return 0;
}
+
+int acpi_bus_get_device(acpi_handle handle, struct acpi_device **device)
+{
+ return acpi_get_device_data(handle, device, NULL);
+}
EXPORT_SYMBOL(acpi_bus_get_device);
+static void get_acpi_device(void *dev)
+{
+ if (dev)
+ get_device(&((struct acpi_device *)dev)->dev);
+}
+
+struct acpi_device *acpi_bus_get_acpi_device(acpi_handle handle)
+{
+ struct acpi_device *adev = NULL;
+
+ acpi_get_device_data(handle, , get_acpi_device);
+ return adev;
+}
+
+void acpi_bus_put_acpi_device(struct acpi_device *adev)
+{
+ put_device(>dev);
+}
+
int acpi_device_add(struct acpi_device *device,
void (*release)(struct device *))
{
Index: linux-pm/drivers/acpi/bus.c
===
--- linux-pm.orig/drivers/acpi/bus.c
+++ linux-pm/drivers/acpi/bus.c
@@ -340,7 +340,7 @@ static void acpi_bus_osc_support(void)
*/
static void acpi_bus_notify(acpi_handle handle, u32 type, void *data)
{
- struct acpi_device *device = NULL;
+ struct acpi_device *device;
struct
[PATCH 16/24][New] ACPI / hotplug / PCI: Do not pass ACPI handle to hotplug_event()
From: Rafael J. Wysocki
Since hotplug_event() can get the ACPI handle needed for debug
printouts from its context argument, there's no need to pass the
handle to it. Moreover, the second argument's type may be changed
to (struct acpiphp_context *), because that's what is always passed
to hotplug_event() as the second argument anyway.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -63,7 +63,7 @@ static DEFINE_MUTEX(acpiphp_context_lock
static void handle_hotplug_event(acpi_handle handle, u32 type, void *data);
static void acpiphp_sanitize_bus(struct pci_bus *bus);
static void acpiphp_set_hpp_values(struct pci_bus *bus);
-static void hotplug_event(acpi_handle handle, u32 type, void *data);
+static void hotplug_event(u32 type, struct acpiphp_context *context);
static void free_bridge(struct kref *kref);
static void acpiphp_context_handler(acpi_handle handle, void *context)
@@ -225,7 +225,7 @@ static void dock_event(acpi_handle handl
acpiphp_put_context(context);
mutex_unlock(_context_lock);
- hotplug_event(handle, type, data);
+ hotplug_event(type, context);
put_bridge(context->func.parent);
}
@@ -813,9 +813,9 @@ void acpiphp_check_host_bridge(acpi_hand
static int acpiphp_disable_and_eject_slot(struct acpiphp_slot *slot);
-static void hotplug_event(acpi_handle handle, u32 type, void *data)
+static void hotplug_event(u32 type, struct acpiphp_context *context)
{
- struct acpiphp_context *context = data;
+ acpi_handle handle = context->adev->handle;
struct acpiphp_func *func = >func;
struct acpiphp_slot *slot = func->slot;
struct acpiphp_bridge *bridge;
@@ -870,14 +870,14 @@ static void hotplug_event(acpi_handle ha
static void hotplug_event_work(void *data, u32 type)
{
struct acpiphp_context *context = data;
- acpi_handle handle = context->adev->handle;
acpi_scan_lock_acquire();
- hotplug_event(handle, type, context);
+ hotplug_event(type, context);
acpi_scan_lock_release();
- acpi_evaluate_hotplug_ost(handle, type, ACPI_OST_SC_SUCCESS, NULL);
+ acpi_evaluate_hotplug_ost(context->adev->handle, type,
+ ACPI_OST_SC_SUCCESS, NULL);
put_bridge(context->func.parent);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 24/24][New] ACPI / hotplug / PCI: Rework acpiphp_check_host_bridge()
From: Rafael J. Wysocki
Since the only existing caller of acpiphp_check_host_bridge(),
which is acpi_pci_root_scan_dependent(), already has a struct
acpi_device pointer needed to obtain the ACPIPHP context, it
doesn't make sense to execute acpi_bus_get_device() on its
handle in acpiphp_handle_to_bridge() just in order to get that
pointer back.
For this reason, modify acpiphp_check_host_bridge() to take
a struct acpi_device pointer as its argument and rearrange the
code accordingly.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/pci_root.c|2 +-
drivers/pci/hotplug/acpiphp_glue.c | 11 +++
include/linux/pci-acpi.h |4 ++--
3 files changed, 6 insertions(+), 11 deletions(-)
Index: linux-pm/include/linux/pci-acpi.h
===
--- linux-pm.orig/include/linux/pci-acpi.h
+++ linux-pm/include/linux/pci-acpi.h
@@ -59,12 +59,12 @@ static inline void acpi_pci_slot_remove(
void acpiphp_init(void);
void acpiphp_enumerate_slots(struct pci_bus *bus);
void acpiphp_remove_slots(struct pci_bus *bus);
-void acpiphp_check_host_bridge(acpi_handle handle);
+void acpiphp_check_host_bridge(struct acpi_device *adev);
#else
static inline void acpiphp_init(void) { }
static inline void acpiphp_enumerate_slots(struct pci_bus *bus) { }
static inline void acpiphp_remove_slots(struct pci_bus *bus) { }
-static inline void acpiphp_check_host_bridge(acpi_handle handle) { }
+static inline void acpiphp_check_host_bridge(struct acpi_device *adev) { }
#endif
#else /* CONFIG_ACPI */
Index: linux-pm/drivers/acpi/pci_root.c
===
--- linux-pm.orig/drivers/acpi/pci_root.c
+++ linux-pm/drivers/acpi/pci_root.c
@@ -51,7 +51,7 @@ static void acpi_pci_root_remove(struct
static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
{
- acpiphp_check_host_bridge(adev->handle);
+ acpiphp_check_host_bridge(adev);
return 0;
}
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -378,15 +378,11 @@ static acpi_status register_slot(acpi_ha
return AE_OK;
}
-static struct acpiphp_bridge *acpiphp_handle_to_bridge(acpi_handle handle)
+static struct acpiphp_bridge *acpiphp_dev_to_bridge(struct acpi_device *adev)
{
- struct acpi_device *adev = acpi_bus_get_acpi_device(handle);
struct acpiphp_context *context;
struct acpiphp_bridge *bridge = NULL;
- if (!adev)
- return NULL;
-
acpi_lock_hp_context();
context = acpiphp_get_context(adev);
if (context) {
@@ -397,7 +393,6 @@ static struct acpiphp_bridge *acpiphp_ha
acpiphp_put_context(context);
}
acpi_unlock_hp_context();
- acpi_bus_put_acpi_device(adev);
return bridge;
}
@@ -764,11 +759,11 @@ static void acpiphp_sanitize_bus(struct
* ACPI event handlers
*/
-void acpiphp_check_host_bridge(acpi_handle handle)
+void acpiphp_check_host_bridge(struct acpi_device *adev)
{
struct acpiphp_bridge *bridge;
- bridge = acpiphp_handle_to_bridge(handle);
+ bridge = acpiphp_dev_to_bridge(adev);
if (bridge) {
pci_lock_rescan_remove();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] mm/swap: prevent concurrent swapon on the same S_ISBLK blockdev
On Mon, 27 Jan 2014 18:03:04 +0800 Weijie Yang wrote: > When swapon the same S_ISBLK blockdev concurrent, the allocated two > swap_info could hold the same block_device, because claim_swapfile() > allow the same holder(here, it is sys_swapon function). > > To prevent this situation, This patch adds swap_lock protect to ensure > we can find this situation and return -EBUSY for one swapon call. > > As for S_ISREG swapfile, claim_swapfile() already prevent this scenario > by holding inode->i_mutex. > > This patch is just for a rare scenario, aim to correct of code. > hm, OK. Would it be saner to pass a unique `holder' to claim_swapfile()? Say, `p'? Truly, I am fed up with silly swapon/swapoff races. How often does anyone call these things? Let's slap a huge lock around the whole thing and be done with it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] clk: mvebu: fix clk init order
On 02/04/2014 12:16 AM, Willy Tarreau wrote: On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote: On 01/30/14 11:24, Gregory CLEMENT wrote: On 25/01/2014 19:19, Sebastian Hesselbarth wrote: This patch set fixes clk init order that went upside-down with v3.14. I haven't really investigated what caused this, but I assume it is related with DT node reordering by addresses. Can you explain what kind of issue do you observe? Sure. When probing CLK_OF_DECLAREed clock drivers, clock-gating driver gets registered before core-clocks. It therefore cannot resolve it's parent clock name for tclk and all clock gates will have no parent clock. Usually, you'll see in some drivers (e.g. v643xx_eth) div_by_zero errors poping up, when they calculate a frequency division factors based on clock gate frequency, which should have been tclk but is 0 now. Well, to be honnest, I have no idea whether your patch is the right way to fix the problem or not, but what I can say is that it fixes such oopses that appear in 3.14-rc1 when booting on mirabox : Division by zero in kernel. Willy, you have hit exactly the reason for this patch. [...] By the way, seeing how often a trick related to the DT is nedeed to solve an oops or a panic, I'm really scared that this whole DT mess is just becoming the exact copy of the ACPI mess (but 15 years later) and we'll experience the same horrible things :-( Sometimes I'm wondering whether there are not too many structural things put in there... To be precise, it is not a DT-related trick at all. You would have the same issues, if you'd register those "low-level" (i.e. early) drivers without DT. It is more about missing init ordering, here. There could be different ways to work this out, even elevating clock devices to "normal" probed devices could be possible. I am sure, in the long run, it will work out, but now this is a fix for v3.14-rc1. @Jason, Andrew, Gregory, Thomas: Now that v3.14 is out, anything against taking this in as fixes for rc1? Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 15/24][Resend] ACPI / hotplug / PCI: Use acpi_handle_debug() in hotplug_event()
From: Rafael J. Wysocki
Make hotplug_event() use acpi_handle_debug() instead of an open-coded
debug message printing and clean up the messages printed by it.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/pci/hotplug/acpiphp_glue.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -819,9 +819,6 @@ static void hotplug_event(acpi_handle ha
struct acpiphp_func *func = >func;
struct acpiphp_slot *slot = func->slot;
struct acpiphp_bridge *bridge;
- char objname[64];
- struct acpi_buffer buffer = { .length = sizeof(objname),
- .pointer = objname };
mutex_lock(_context_lock);
bridge = context->bridge;
@@ -831,14 +828,11 @@ static void hotplug_event(acpi_handle ha
mutex_unlock(_context_lock);
pci_lock_rescan_remove();
- acpi_get_name(handle, ACPI_FULL_PATHNAME, );
switch (type) {
case ACPI_NOTIFY_BUS_CHECK:
/* bus re-enumerate */
- pr_debug("%s: Bus check notify on %s\n", __func__, objname);
- pr_debug("%s: re-enumerating slots under %s\n",
-__func__, objname);
+ acpi_handle_debug(handle, "Bus check in %s()\n", __func__);
if (bridge)
acpiphp_check_bridge(bridge);
else if (!(slot->flags & SLOT_IS_GOING_AWAY))
@@ -848,7 +842,7 @@ static void hotplug_event(acpi_handle ha
case ACPI_NOTIFY_DEVICE_CHECK:
/* device check */
- pr_debug("%s: Device check notify on %s\n", __func__, objname);
+ acpi_handle_debug(handle, "Device check in %s()\n", __func__);
if (bridge) {
acpiphp_check_bridge(bridge);
} else if (!(slot->flags & SLOT_IS_GOING_AWAY)) {
@@ -863,7 +857,7 @@ static void hotplug_event(acpi_handle ha
case ACPI_NOTIFY_EJECT_REQUEST:
/* request device eject */
- pr_debug("%s: Device eject notify on %s\n", __func__, objname);
+ acpi_handle_debug(handle, "Eject request in %s()\n", __func__);
acpiphp_disable_and_eject_slot(slot);
break;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 17/24][Resend] ACPICA: Introduce acpi_get_data_full() and rework acpi_get_data()
From: Rafael J. Wysocki
Introduce a new function, acpi_get_data_full(), working in analogy
with acpi_get_data() except that it can execute a callback provided
as its 4th argument right after acpi_ns_get_attached_data() has
returned a success.
That will allow Linux to reference count the object pointed to by
*data before the namespace mutex is released so as to ensure that it
will not be freed going forward until the reference to it acquired
by acpi_get_data_full() is dropped.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/acpi/acpica/nsxfeval.c | 33 ++---
include/acpi/acpixf.h |4
2 files changed, 34 insertions(+), 3 deletions(-)
Index: linux-pm/drivers/acpi/acpica/nsxfeval.c
===
--- linux-pm.orig/drivers/acpi/acpica/nsxfeval.c
+++ linux-pm/drivers/acpi/acpica/nsxfeval.c
@@ -923,19 +923,22 @@ ACPI_EXPORT_SYMBOL(acpi_detach_data)
/***
*
- * FUNCTION:acpi_get_data
+ * FUNCTION:acpi_get_data_full
*
* PARAMETERS: obj_handle - Namespace node
* handler - Handler used in call to attach_data
* data- Where the data is returned
+ * callback- function to execute before returning
*
* RETURN: Status
*
- * DESCRIPTION: Retrieve data that was previously attached to a namespace node.
+ * DESCRIPTION: Retrieve data that was previously attached to a namespace node
+ * and execute a callback before returning.
*
**/
acpi_status
-acpi_get_data(acpi_handle obj_handle, acpi_object_handler handler, void **data)
+acpi_get_data_full(acpi_handle obj_handle, acpi_object_handler handler,
+ void **data, void (*callback)(void *))
{
struct acpi_namespace_node *node;
acpi_status status;
@@ -960,10 +963,34 @@ acpi_get_data(acpi_handle obj_handle, ac
}
status = acpi_ns_get_attached_data(node, handler, data);
+ if (ACPI_SUCCESS(status) && callback) {
+ callback(*data);
+ }
unlock_and_exit:
(void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
return (status);
}
+ACPI_EXPORT_SYMBOL(acpi_get_data_full)
+
+/***
+ *
+ * FUNCTION:acpi_get_data
+ *
+ * PARAMETERS: obj_handle - Namespace node
+ * handler - Handler used in call to attach_data
+ * data- Where the data is returned
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Retrieve data that was previously attached to a namespace node.
+ *
+
**/
+acpi_status
+acpi_get_data(acpi_handle obj_handle, acpi_object_handler handler, void **data)
+{
+ return acpi_get_data_full(obj_handle, handler, data, NULL);
+}
+
ACPI_EXPORT_SYMBOL(acpi_get_data)
Index: linux-pm/include/acpi/acpixf.h
===
--- linux-pm.orig/include/acpi/acpixf.h
+++ linux-pm/include/acpi/acpixf.h
@@ -230,6 +230,10 @@ acpi_attach_data(acpi_handle object, acp
acpi_status acpi_detach_data(acpi_handle object, acpi_object_handler handler);
acpi_status
+acpi_get_data_full(acpi_handle object, acpi_object_handler handler, void
**data,
+ void (*callback)(void *));
+
+acpi_status
acpi_get_data(acpi_handle object, acpi_object_handler handler, void **data);
acpi_status
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 22/24][Resend] ACPI / hotplug / PCI: Simplify acpi_install_hotplug_notify_handler()
From: Rafael J. Wysocki
Since acpi_hotplug_notify_cb() does not use its data argument any
more, the second argument of acpi_install_hotplug_notify_handler()
can be dropped, so do that and update its callers accordingly.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/acpi/scan.c|6 +++---
drivers/pci/hotplug/acpiphp_glue.c |2 +-
include/acpi/acpi_bus.h|2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -577,10 +577,10 @@ static void acpi_hotplug_notify_cb(acpi_
acpi_evaluate_hotplug_ost(handle, type, ost_code, NULL);
}
-void acpi_install_hotplug_notify_handler(acpi_handle handle, void *data)
+void acpi_install_hotplug_notify_handler(acpi_handle handle)
{
acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
- acpi_hotplug_notify_cb, data);
+ acpi_hotplug_notify_cb, NULL);
}
void acpi_remove_hotplug_notify_handler(acpi_handle handle)
@@ -2048,7 +2048,7 @@ static void acpi_scan_init_hotplug(acpi_
list_for_each_entry(hwid, , list) {
handler = acpi_scan_match_handler(hwid->id, NULL);
if (handler) {
- acpi_install_hotplug_notify_handler(handle, handler);
+ acpi_install_hotplug_notify_handler(handle);
break;
}
}
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -372,7 +372,7 @@ static acpi_status register_slot(acpi_ha
/* install notify handler */
if (!(newfunc->flags & FUNC_HAS_DCK))
- acpi_install_hotplug_notify_handler(handle, NULL);
+ acpi_install_hotplug_notify_handler(handle);
return AE_OK;
}
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -445,7 +445,7 @@ static inline bool acpi_device_enumerate
typedef void (*acpi_hp_callback)(void *data, u32 src);
acpi_status acpi_hotplug_execute(acpi_hp_callback func, void *data, u32 src);
-void acpi_install_hotplug_notify_handler(acpi_handle handle, void *data);
+void acpi_install_hotplug_notify_handler(acpi_handle handle);
void acpi_remove_hotplug_notify_handler(acpi_handle handle);
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, 3 Feb 2014, Andrew Morton wrote: > > > How do you define "huge bloat" if the size of vmlinux doesn't increase? > > > > Don't be silly. The size of all the object files increase *hugely*. > > yup, I disable this in my allmodconfig testing, to great effect. > > That being said, I do think the text should make clear that the bloat > is a compile-time impact and not a runtime one. Something like > > --- > a/lib/Kconfig.debug~lib-kconfigdebug-clarify-config_debug_infos-bloaty-nature-fix > +++ a/lib/Kconfig.debug > @@ -128,9 +128,9 @@ config DEBUG_INFO > tools like crash, kgdb, LKCD, gdb, etc on the kernel. > > If you only want to have resolved symbols in kernel traces and > - are not going to need support for those tools above, you don't need > - to enable this as it is a huge bloat and build slowdown; > - enable CONFIG_KALLSYMS instead. > + are not going to need support for the above tools, you don't need > + to enable this. It hugely bloat object files' on-disk sizes and slows > + the build. Enable CONFIG_KALLSYMS instead. > > If unsure, say N. > Um, I still don't think this is right since CONFIG_DEBUG_INFO_REDUCED requires you to say yes here and that config option actually specifies the tools for which it is effective. Are you suggesting that we decouple CONFIG_DEBUG_INFO from CONFIG_DEBUG_INFO_REDUCED and make CONFIG_DEBUG_INFO select the reduced variant? Or... what? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 14/24][Update] ACPI / hotplug / PCI: Simplify hotplug_event()
From: Rafael J. Wysocki
A few lines of code can be cut from hotplug_event() by defining
and initializing the slot variable at the top of the function,
so do that.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -817,6 +817,7 @@ static void hotplug_event(acpi_handle ha
{
struct acpiphp_context *context = data;
struct acpiphp_func *func = >func;
+ struct acpiphp_slot *slot = func->slot;
struct acpiphp_bridge *bridge;
char objname[64];
struct acpi_buffer buffer = { .length = sizeof(objname),
@@ -838,14 +839,11 @@ static void hotplug_event(acpi_handle ha
pr_debug("%s: Bus check notify on %s\n", __func__, objname);
pr_debug("%s: re-enumerating slots under %s\n",
__func__, objname);
- if (bridge) {
+ if (bridge)
acpiphp_check_bridge(bridge);
- } else {
- struct acpiphp_slot *slot = func->slot;
+ else if (!(slot->flags & SLOT_IS_GOING_AWAY))
+ enable_slot(slot);
- if (!(slot->flags & SLOT_IS_GOING_AWAY))
- enable_slot(slot);
- }
break;
case ACPI_NOTIFY_DEVICE_CHECK:
@@ -853,12 +851,7 @@ static void hotplug_event(acpi_handle ha
pr_debug("%s: Device check notify on %s\n", __func__, objname);
if (bridge) {
acpiphp_check_bridge(bridge);
- } else {
- struct acpiphp_slot *slot = func->slot;
-
- if (slot->flags & SLOT_IS_GOING_AWAY)
- break;
-
+ } else if (!(slot->flags & SLOT_IS_GOING_AWAY)) {
/*
* Check if anything has changed in the slot and rescan
* from the parent if that's the case.
@@ -871,7 +864,7 @@ static void hotplug_event(acpi_handle ha
case ACPI_NOTIFY_EJECT_REQUEST:
/* request device eject */
pr_debug("%s: Device eject notify on %s\n", __func__, objname);
- acpiphp_disable_and_eject_slot(func->slot);
+ acpiphp_disable_and_eject_slot(slot);
break;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 13/24][Resend] ACPI / hotplug / PCI: Drop crit_sect locking
From: Rafael J. Wysocki
After recent PCI core changes related to the rescan/remove locking,
the code sections under crit_sect mutexes from ACPIPHP slot objects
are always executed under the general PCI rescan/remove lock.
For this reason, the crit_sect mutexes are simply redundant, so drop
them.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/pci/hotplug/acpiphp.h |1 -
drivers/pci/hotplug/acpiphp_glue.c | 23 +++
2 files changed, 3 insertions(+), 21 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -347,7 +347,6 @@ static acpi_status register_slot(acpi_ha
slot->bus = bridge->pci_bus;
slot->device = device;
INIT_LIST_HEAD(>funcs);
- mutex_init(>crit_sect);
list_add_tail(>node, >slots);
@@ -744,7 +743,6 @@ static void acpiphp_check_bridge(struct
struct pci_bus *bus = slot->bus;
struct pci_dev *dev, *tmp;
- mutex_lock(>crit_sect);
if (slot_no_hotplug(slot)) {
; /* do nothing */
} else if (get_slot_status(slot) == ACPI_STA_ALL) {
@@ -759,7 +757,6 @@ static void acpiphp_check_bridge(struct
} else {
disable_slot(slot);
}
- mutex_unlock(>crit_sect);
}
}
@@ -846,12 +843,8 @@ static void hotplug_event(acpi_handle ha
} else {
struct acpiphp_slot *slot = func->slot;
- if (slot->flags & SLOT_IS_GOING_AWAY)
- break;
-
- mutex_lock(>crit_sect);
- enable_slot(slot);
- mutex_unlock(>crit_sect);
+ if (!(slot->flags & SLOT_IS_GOING_AWAY))
+ enable_slot(slot);
}
break;
@@ -862,7 +855,6 @@ static void hotplug_event(acpi_handle ha
acpiphp_check_bridge(bridge);
} else {
struct acpiphp_slot *slot = func->slot;
- int ret;
if (slot->flags & SLOT_IS_GOING_AWAY)
break;
@@ -871,10 +863,7 @@ static void hotplug_event(acpi_handle ha
* Check if anything has changed in the slot and rescan
* from the parent if that's the case.
*/
- mutex_lock(>crit_sect);
- ret = acpiphp_rescan_slot(slot);
- mutex_unlock(>crit_sect);
- if (ret)
+ if (acpiphp_rescan_slot(slot))
acpiphp_check_bridge(func->parent);
}
break;
@@ -1088,13 +1077,10 @@ int acpiphp_enable_slot(struct acpiphp_s
if (slot->flags & SLOT_IS_GOING_AWAY)
return -ENODEV;
- mutex_lock(>crit_sect);
/* configure all functions */
if (!(slot->flags & SLOT_ENABLED))
enable_slot(slot);
- mutex_unlock(>crit_sect);
-
pci_unlock_rescan_remove();
return 0;
}
@@ -1110,8 +1096,6 @@ static int acpiphp_disable_and_eject_slo
if (slot->flags & SLOT_IS_GOING_AWAY)
return -ENODEV;
- mutex_lock(>crit_sect);
-
/* unconfigure all functions */
disable_slot(slot);
@@ -1125,7 +1109,6 @@ static int acpiphp_disable_and_eject_slo
break;
}
- mutex_unlock(>crit_sect);
return 0;
}
Index: linux-pm/drivers/pci/hotplug/acpiphp.h
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
+++ linux-pm/drivers/pci/hotplug/acpiphp.h
@@ -93,7 +93,6 @@ struct acpiphp_slot {
struct list_head funcs; /* one slot may have different
objects (i.e. for each function) */
struct slot *slot;
- struct mutex crit_sect;
u8 device; /* pci device# */
u32 flags; /* see below */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/24][Resend] ACPI / hotplug / PCI: Drop acpiphp_bus_add()
From: Rafael J. Wysocki
acpiphp_bus_add() is only called from one place, so move the code out
of it into that place and drop it. Also make that code use
func_to_acpi_device() to get the struct acpi_device pointer it needs
instead of calling acpi_bus_get_device() which may be costly.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/pci/hotplug/acpiphp_glue.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -491,20 +491,6 @@ static unsigned char acpiphp_max_busnr(s
return max;
}
-/**
- * acpiphp_bus_add - Scan ACPI namespace subtree.
- * @handle: ACPI object handle to start the scan from.
- */
-static void acpiphp_bus_add(acpi_handle handle)
-{
- struct acpi_device *adev = NULL;
-
- acpi_bus_scan(handle);
- acpi_bus_get_device(handle, );
- if (acpi_device_enumerated(adev))
- acpi_device_set_power(adev, ACPI_STATE_D0);
-}
-
static void acpiphp_set_acpi_region(struct acpiphp_slot *slot)
{
struct acpiphp_func *func;
@@ -544,9 +530,13 @@ static int acpiphp_rescan_slot(struct ac
{
struct acpiphp_func *func;
- list_for_each_entry(func, >funcs, sibling)
- acpiphp_bus_add(func_to_handle(func));
+ list_for_each_entry(func, >funcs, sibling) {
+ struct acpi_device *adev = func_to_acpi_device(func);
+ acpi_bus_scan(adev->handle);
+ if (acpi_device_enumerated(adev))
+ acpi_device_set_power(adev, ACPI_STATE_D0);
+ }
return pci_scan_slot(slot->bus, PCI_DEVFN(slot->device, 0));
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/24][Update] ACPI / hotplug / PCI: Store acpi_device pointer in acpiphp_context
From: Rafael J. Wysocki
After recent modifications of the ACPI core making it create a struct
acpi_device object for every namespace node representing a device
regardless of the current status of that device the ACPIPHP code
can store a struct acpi_device pointer instead of an ACPI handle
in struct acpiphp_context. This immediately makes it possible to
avoid making potentially costly calls to acpi_bus_get_device() in
two places and allows some more simplifications to be made going
forward.
The reason why that is correct is because ACPIPHP only installs
hotify handlers for namespace nodes that exist when
acpiphp_enumerate_slots() is called for their parent bridge.
That only happens if the parent bridge has an ACPI companion
associated with it, which means that the ACPI namespace scope
in question has been scanned already at that point. That, in
turn, means that struct acpi_device objects have been created
for all namespace nodes in that scope and pointers to those
objects can be stored directly instead of their ACPI handles.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |9 +--
drivers/pci/hotplug/acpiphp_glue.c | 46 +
2 files changed, 29 insertions(+), 26 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp.h
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
+++ linux-pm/drivers/pci/hotplug/acpiphp.h
@@ -117,8 +117,8 @@ struct acpiphp_func {
};
struct acpiphp_context {
- acpi_handle handle;
struct acpiphp_func func;
+ struct acpi_device *adev;
struct acpiphp_bridge *bridge;
unsigned int refcount;
};
@@ -128,9 +128,14 @@ static inline struct acpiphp_context *fu
return container_of(func, struct acpiphp_context, func);
}
+static inline struct acpi_device *func_to_acpi_device(struct acpiphp_func
*func)
+{
+ return func_to_context(func)->adev;
+}
+
static inline acpi_handle func_to_handle(struct acpiphp_func *func)
{
- return func_to_context(func)->handle;
+ return func_to_acpi_device(func)->handle;
}
/*
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -73,11 +73,11 @@ static void acpiphp_context_handler(acpi
/**
* acpiphp_init_context - Create hotplug context and grab a reference to it.
- * @handle: ACPI object handle to create the context for.
+ * @adev: ACPI device object to create the context for.
*
* Call under acpiphp_context_lock.
*/
-static struct acpiphp_context *acpiphp_init_context(acpi_handle handle)
+static struct acpiphp_context *acpiphp_init_context(struct acpi_device *adev)
{
struct acpiphp_context *context;
acpi_status status;
@@ -86,9 +86,9 @@ static struct acpiphp_context *acpiphp_i
if (!context)
return NULL;
- context->handle = handle;
+ context->adev = adev;
context->refcount = 1;
- status = acpi_attach_data(handle, acpiphp_context_handler, context);
+ status = acpi_attach_data(adev->handle, acpiphp_context_handler,
context);
if (ACPI_FAILURE(status)) {
kfree(context);
return NULL;
@@ -118,7 +118,7 @@ static struct acpiphp_context *acpiphp_g
/**
* acpiphp_put_context - Drop a reference to ACPI hotplug context.
- * @handle: ACPI object handle to put the context for.
+ * @context: ACPI hotplug context to drop a reference to.
*
* The context object is removed if there are no more references to it.
*
@@ -130,7 +130,7 @@ static void acpiphp_put_context(struct a
return;
WARN_ON(context->bridge);
- acpi_detach_data(context->handle, acpiphp_context_handler);
+ acpi_detach_data(context->adev->handle, acpiphp_context_handler);
kfree(context);
}
@@ -216,7 +216,7 @@ static void dock_event(acpi_handle handl
mutex_lock(_context_lock);
context = acpiphp_get_context(handle);
- if (!context || WARN_ON(context->handle != handle)
+ if (!context || WARN_ON(context->adev->handle != handle)
|| context->func.parent->is_going_away) {
mutex_unlock(_context_lock);
return;
@@ -284,6 +284,7 @@ static acpi_status register_slot(acpi_ha
{
struct acpiphp_bridge *bridge = data;
struct acpiphp_context *context;
+ struct acpi_device *adev;
struct acpiphp_slot *slot;
struct acpiphp_func *newfunc;
acpi_status status = AE_OK;
@@ -303,12 +304,14 @@ static acpi_status register_slot(acpi_ha
"can't evaluate _ADR (%#x)\n", status);
return AE_OK;
}
+ if (acpi_bus_get_device(handle, ))
+ return AE_OK;
device = (adr >> 16) & 0x;
function =
Re: [PATCH] Fix lockdep false positive in add_full()
On Mon, 3 Feb 2014, Paul E. McKenney wrote: > Hello! > > The add_full() function currently has a lockdep_assert_held() requiring > that the kmem_cache_node structure's ->list_lock be held. However, > this lock is not acquired by add_full()'s caller deactivate_slab() > in the full-node case unless debugging is enabled. Because full nodes > are accessed only by debugging code, this state of affairs results in > lockdep false-positive splats like the following: > > [ 43.942868] WARNING: CPU: 0 PID: 698 at > /home/paulmck/public_git/linux-rcu/mm/slub.c:1007 > deactivate_slab+0x509/0x720() > [ 43.943016] Modules linked in: > [ 43.943016] CPU: 0 PID: 698 Comm: torture_onoff Not tainted 3.14.0-rc1+ #1 > [ 43.943016] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 > [ 43.943016] 03ef 88001e3f5ba8 818952ec > 0046 > [ 43.943016] 88001e3f5be8 81049517 > ea784e00 > [ 43.943016] ea7a9000 0002 > > [ 43.943016] Call Trace: > [ 43.943016] [] dump_stack+0x46/0x58 > [ 43.943016] [] warn_slowpath_common+0x87/0xb0 > [ 43.943016] [] warn_slowpath_null+0x15/0x20 > [ 43.943016] [] deactivate_slab+0x509/0x720 > [ 43.943016] [] ? slab_cpuup_callback+0x3b/0x100 > [ 43.943016] [] ? slab_cpuup_callback+0xd2/0x100 > [ 43.943016] [] slab_cpuup_callback+0xa4/0x100 > [ 43.943016] [] notifier_call_chain+0x54/0x110 > [ 43.943016] [] __raw_notifier_call_chain+0x9/0x10 > [ 43.943016] [] __cpu_notify+0x1b/0x30 > [ 43.943016] [] cpu_notify_nofail+0x10/0x20 > [ 43.943016] [] _cpu_down+0x10d/0x2e0 > [ 43.943016] [] cpu_down+0x30/0x50 > [ 43.943016] [] torture_onoff+0xd3/0x3c0 > [ 43.943016] [] ? torture_onoff_stats+0x90/0x90 > [ 43.943016] [] kthread+0xdf/0x100 > [ 43.943016] [] ? _raw_spin_unlock_irq+0x2b/0x40 > [ 43.943016] [] ? flush_kthread_worker+0x130/0x130 > [ 43.943016] [] ret_from_fork+0x7c/0xb0 > [ 43.943016] [] ? flush_kthread_worker+0x130/0x130 > > This commit therefore does the lockdep check only if debuggging is > enabled, thus avoiding the false positives. > > Signed-off-by: Paul E. McKenney This was discussed in http://marc.info/?t=13914579132, what do you think about the patch in that thread instead? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/24][Resend] ACPI / hotplug / PCI: Drop acpiphp_bus_trim()
From: Rafael J. Wysocki
If trim_stale_devices() calls acpi_bus_trim() directly, we can
save a potentially costly acpi_bus_get_device() invocation. After
making that change acpiphp_bus_trim() would only be called from one
place, so move the code from it to that place and drop it.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/pci/hotplug/acpiphp_glue.c | 30 +++---
1 file changed, 11 insertions(+), 19 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -489,19 +489,6 @@ static unsigned char acpiphp_max_busnr(s
}
/**
- * acpiphp_bus_trim - Trim device objects in an ACPI namespace subtree.
- * @handle: ACPI device object handle to start from.
- */
-static void acpiphp_bus_trim(acpi_handle handle)
-{
- struct acpi_device *adev = NULL;
-
- acpi_bus_get_device(handle, );
- if (adev)
- acpi_bus_trim(adev);
-}
-
-/**
* acpiphp_bus_add - Scan ACPI namespace subtree.
* @handle: ACPI object handle to start the scan from.
*/
@@ -641,8 +628,12 @@ static void disable_slot(struct acpiphp_
if (PCI_SLOT(dev->devfn) == slot->device)
pci_stop_and_remove_bus_device(dev);
- list_for_each_entry(func, >funcs, sibling)
- acpiphp_bus_trim(func_to_handle(func));
+ list_for_each_entry(func, >funcs, sibling) {
+ struct acpi_device *adev;
+
+ if (!acpi_bus_get_device(func_to_handle(func), ))
+ acpi_bus_trim(adev);
+ }
slot->flags &= (~SLOT_ENABLED);
}
@@ -714,11 +705,12 @@ static unsigned int get_slot_status(stru
*/
static void trim_stale_devices(struct pci_dev *dev)
{
- acpi_handle handle = ACPI_HANDLE(>dev);
+ struct acpi_device *adev = ACPI_COMPANION(>dev);
struct pci_bus *bus = dev->subordinate;
bool alive = false;
- if (handle) {
+ if (adev) {
+ acpi_handle handle = adev->handle;
acpi_status status;
unsigned long long sta;
@@ -734,8 +726,8 @@ static void trim_stale_devices(struct pc
}
if (!alive) {
pci_stop_and_remove_bus_device(dev);
- if (handle)
- acpiphp_bus_trim(handle);
+ if (adev)
+ acpi_bus_trim(adev);
} else if (bus) {
struct pci_dev *child, *tmp;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/24][Resend] ACPI / hotplug / PCI: Rework acpiphp_no_hotplug()
From: Rafael J. Wysocki
If a struct acpi_device pointer is passed to acpiphp_no_hotplug()
instead of an ACPI handle, the function won't need to call
acpi_bus_get_device(), which may be costly, any more. Then,
trim_stale_devices() can call acpiphp_no_hotplug() passing
the struct acpi_device object it already has directly to that
function.
Make those changes and update slot_no_hotplug() accordingly.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/pci/hotplug/acpiphp_glue.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -638,11 +638,8 @@ static void disable_slot(struct acpiphp_
slot->flags &= (~SLOT_ENABLED);
}
-static bool acpiphp_no_hotplug(acpi_handle handle)
+static bool acpiphp_no_hotplug(struct acpi_device *adev)
{
- struct acpi_device *adev = NULL;
-
- acpi_bus_get_device(handle, );
return adev && adev->flags.no_hotplug;
}
@@ -650,10 +647,13 @@ static bool slot_no_hotplug(struct acpip
{
struct acpiphp_func *func;
- list_for_each_entry(func, >funcs, sibling)
- if (acpiphp_no_hotplug(func_to_handle(func)))
- return true;
+ list_for_each_entry(func, >funcs, sibling) {
+ struct acpi_device *adev = NULL;
+ acpi_bus_get_device(func_to_handle(func), );
+ if (acpiphp_no_hotplug(adev))
+ return true;
+ }
return false;
}
@@ -710,13 +710,12 @@ static void trim_stale_devices(struct pc
bool alive = false;
if (adev) {
- acpi_handle handle = adev->handle;
acpi_status status;
unsigned long long sta;
- status = acpi_evaluate_integer(handle, "_STA", NULL, );
+ status = acpi_evaluate_integer(adev->handle, "_STA", NULL,
);
alive = (ACPI_SUCCESS(status) && sta == ACPI_STA_ALL)
- || acpiphp_no_hotplug(handle);
+ || acpiphp_no_hotplug(adev);
}
if (!alive) {
u32 v;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] arm64: Add architecture support for PCI
On Mon, Feb 03, 2014 at 05:07:48PM -0600, Rob Herring wrote: > > An interesting question however is what the transition plan is to > > have the code shared between arm32 and arm64: We will certainly need > > to share at least the dw-pcie and the generic SBSA compliant pci > > implementation. > > You might want to re-read the SBSA. Unless ARM provides an IP block or > there is some other standard such as EHCI or AHCI, there is no generic > implementation. You only have to go look at the Linux EHCI or AHCI > drivers and see how meaningless and inadequate "use EHCI" is. For PCI, > the text is so brief in the SBSA there will be no way PCI is going to > just work given all the variations of root complexes, bridges, address > windows, etc. we typically see on ARM platforms. I could be wrong and > some AML magic will solve all the problems. :) The biggest hinderance I've seen while looking at ARM PCI drivers is quite simply - they don't follow the PCI-E spec. There is a spec, and it is not followed. This fixup in the X-Gene is a solid example, the purpose of the BAR in a PCI-PCI bridge is very clear: using it to specify the system DRAM aperature is completely wrong. Not having working aperture windows in the root complex's bridges is completely wrong. Lacking any ability to generate 8 and 16 bit config write TLP's is wrong. Starting with an end-port PCI-E core and re-tasking it to be a root port bridge and ignoring all the requirements with the bridge's config space is utterly and completely WRONG. Specifying 'use EHCI, AHCI, etc' - which are all PCI based standards without clearly specifying exactly how PCI is suppose to work is completely bonkers. What is needed is a spec that says: 1) Here is how you generate config TLPs. A MMIO region that conforms to the already specified x86 ECAM would be perfect 2) Here is a dword by dword break down of the entire config space in a SOC. Here is where a on-board AHCI controller must show up in config space. Here is how an external PCI-E port must show up. Etc. Most of this is already specified, but it clearly needs to be layed out explicitly for ARM SOCs to actually follow it. 3) Here is how you specify the aperture(s) associated with PCI BAR's and bridge windows in config space. And yes: The CONFIG SPACE BARS MUST WORK. 4) Here is how MSI works, these are the values you put in the address/data and here is how you collect the interrupt. 5) Here is how Legacy INTx must be mapped into the GIC. This is what x86 does, and they have been doing it well for 10 years. If you want to play in the server game you have to properly implement PCI. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/24][Resend] ACPI / hotplug / PCI: Proper kerneldoc comments for enumeration/removal
From: Rafael J. Wysocki
Add proper kerneldoc comments describing acpiphp_enumerate_slots()
and acpiphp_remove_slots().
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/pci/hotplug/acpiphp_glue.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -1001,9 +1001,12 @@ static void handle_hotplug_event(acpi_ha
acpi_evaluate_hotplug_ost(handle, type, ost_code, NULL);
}
-/*
- * Create hotplug slots for the PCI bus.
- * It should always return 0 to avoid skipping following notifiers.
+/**
+ * acpiphp_enumerate_slots - Enumerate PCI slots for a given bus.
+ * @bus: PCI bus to enumerate the slots for.
+ *
+ * A "slot" is an object associated with a PCI device number. All functions
+ * (PCI devices) with the same bus and device number belong to the same slot.
*/
void acpiphp_enumerate_slots(struct pci_bus *bus)
{
@@ -1076,7 +1079,10 @@ void acpiphp_enumerate_slots(struct pci_
}
}
-/* Destroy hotplug slots associated with the PCI bus */
+/**
+ * acpiphp_remove_slots - Remove slot objects associated with a given bus.
+ * @bus: PCI bus to remove the slot objects for.
+ */
void acpiphp_remove_slots(struct pci_bus *bus)
{
struct acpiphp_bridge *bridge;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/24][New] ACPI / hotplug / PCI: Fix bridge removal race vs dock events
From: Rafael J. Wysocki
If a PCI bridge with an ACPIPHP context attached is removed via
sysfs, the code path executed as a result is the following:
pci_stop_and_remove_bus_device_locked
pci_remove_bus
pcibios_remove_bus
acpi_pci_remove_bus
acpiphp_remove_slots
cleanup_bridge
unregister_hotplug_dock_device (drops dock references to the bridge)
put_bridge
free_bridge
acpiphp_put_context (for each child, under context lock)
kfree (context)
Now, if a dock event affecting one of the bridge's child devices
occurs (roughly at the same time), it will lead to the following code
path:
acpi_dock_deferred_cb
dock_notify
handle_eject_request
hot_remove_dock_devices
dock_hotplug_event
hotplug_event (dereferences context)
That may lead to a kernel crash in hotplug_event() if it is executed
after the last kfree() in the bridge removal code path.
To prevent that from happening, add a wrapper around hotplug_event()
called dock_event() and point the .handler pointer in acpiphp_dock_ops
to it. Make that wrapper retrieve the device's ACPIPHP context using
acpiphp_get_context() (instead of taking it from the data argument)
under acpiphp_context_lock and check if the parent bridge's
is_going_away flag is set. If that flag is set, it will return
immediately and if it is not set it will grab a reference to the
device's parent bridge before executing hotplug_event().
Then, in the above scenario, the reference to the parent bridge
held by dock_event() will prevent free_bridge() from being executed
for it until hotplug_event() returns.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -210,10 +210,29 @@ static void post_dock_fixups(acpi_handle
}
}
+static void dock_event(acpi_handle handle, u32 type, void *data)
+{
+ struct acpiphp_context *context;
+
+ mutex_lock(_context_lock);
+ context = acpiphp_get_context(handle);
+ if (!context || WARN_ON(context->handle != handle)
+ || context->func.parent->is_going_away) {
+ mutex_unlock(_context_lock);
+ return;
+ }
+ get_bridge(context->func.parent);
+ acpiphp_put_context(context);
+ mutex_unlock(_context_lock);
+
+ hotplug_event(handle, type, data);
+
+ put_bridge(context->func.parent);
+}
static const struct acpi_dock_ops acpiphp_dock_ops = {
.fixup = post_dock_fixups,
- .handler = hotplug_event,
+ .handler = dock_event,
};
/* Check whether the PCI device is managed by native PCIe hotplug driver */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/24][Resend] ACPI / hotplug / PCI: Simplify register_slot()
From: Rafael J. Wysocki
The err label in register_slot() is only jumped to from one place,
so move the code under the label to that place and drop the label.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/pci/hotplug/acpiphp_glue.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -335,8 +335,10 @@ static acpi_status register_slot(acpi_ha
slot = kzalloc(sizeof(struct acpiphp_slot), GFP_KERNEL);
if (!slot) {
- status = AE_NO_MEMORY;
- goto err;
+ mutex_lock(_context_lock);
+ acpiphp_put_context(context);
+ mutex_unlock(_context_lock);
+ return AE_NO_MEMORY;
}
slot->bus = bridge->pci_bus;
@@ -404,12 +406,6 @@ static acpi_status register_slot(acpi_ha
}
return AE_OK;
-
- err:
- mutex_lock(_context_lock);
- acpiphp_put_context(context);
- mutex_unlock(_context_lock);
- return status;
}
static struct acpiphp_bridge *acpiphp_handle_to_bridge(acpi_handle handle)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/24][Resend] ACPI / hotplug / PCI: Simplify disable_slot()
From: Rafael J. Wysocki
After recent PCI core changes related to the rescan/remove locking,
the ACPIPHP's disable_slot() function is only called under the
general PCI rescan/remove lock, so it doesn't have to use
dev_in_slot() any more to avoid race conditions. Make it simply
walk the devices on the bus and drop the ones in the slot being
disabled and drop dev_in_slot() which has no more users.
Moreover, to avoid problems described in the changelog of commit
29ed1f29b68a (PCI: pciehp: Fix null pointer deref when hot-removing
SR-IOV device), make disable_slot() carry out the list walk in
reverse order.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/pci/hotplug/acpiphp_glue.c | 28 +---
1 file changed, 5 insertions(+), 23 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -625,32 +625,15 @@ static void __ref enable_slot(struct acp
}
}
-/* return first device in slot, acquiring a reference on it */
-static struct pci_dev *dev_in_slot(struct acpiphp_slot *slot)
-{
- struct pci_bus *bus = slot->bus;
- struct pci_dev *dev;
- struct pci_dev *ret = NULL;
-
- down_read(_bus_sem);
- list_for_each_entry(dev, >devices, bus_list)
- if (PCI_SLOT(dev->devfn) == slot->device) {
- ret = pci_dev_get(dev);
- break;
- }
- up_read(_bus_sem);
-
- return ret;
-}
-
/**
* disable_slot - disable a slot
* @slot: ACPI PHP slot
*/
static void disable_slot(struct acpiphp_slot *slot)
{
+ struct pci_bus *bus = slot->bus;
+ struct pci_dev *dev, *prev;
struct acpiphp_func *func;
- struct pci_dev *pdev;
/*
* enable_slot() enumerates all functions in this device via
@@ -658,10 +641,9 @@ static void disable_slot(struct acpiphp_
* methods (_EJ0, etc.) or not. Therefore, we remove all functions
* here.
*/
- while ((pdev = dev_in_slot(slot))) {
- pci_stop_and_remove_bus_device(pdev);
- pci_dev_put(pdev);
- }
+ list_for_each_entry_safe_reverse(dev, prev, >devices, bus_list)
+ if (PCI_SLOT(dev->devfn) == slot->device)
+ pci_stop_and_remove_bus_device(dev);
list_for_each_entry(func, >funcs, sibling)
acpiphp_bus_trim(func_to_handle(func));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/24][Resend] ACPI / hotplug / PCI: Scan root bus under the PCI rescan-remove lock
From: Rafael J. Wysocki
Since acpiphp_check_bridge() called by acpiphp_check_host_bridge()
does things that require PCI rescan-remove locking around it,
make acpiphp_check_host_bridge() use that locking.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c |4
1 file changed, 4 insertions(+)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -829,7 +829,11 @@ void acpiphp_check_host_bridge(acpi_hand
bridge = acpiphp_handle_to_bridge(handle);
if (bridge) {
+ pci_lock_rescan_remove();
+
acpiphp_check_bridge(bridge);
+
+ pci_unlock_rescan_remove();
put_bridge(bridge);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] mm/swap: fix race on swap_info reuse between swapoff and swapon
On Mon, 3 Feb 2014 15:23:40 -0800 Andrew Morton wrote: > On Mon, 27 Jan 2014 18:03:04 +0800 Weijie Yang > wrote: > > > swapoff clear swap_info's SWP_USED flag prematurely and free its resources > > after that. A concurrent swapon will reuse this swap_info while its previous > > resources are not cleared completely. > > > > These late freed resources are: > > - p->percpu_cluster > > - swap_cgroup_ctrl[type] > > - block_device setting > > - inode->i_flags &= ~S_SWAPFILE > > > > This patch clear SWP_USED flag after all its resources freed, so that swapon > > can reuse this swap_info by alloc_swap_info() safely. > > > > This patch is just for a rare scenario, aim to correct of code. > > I believe that > http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-fix-race-on-swap_info-reuse-between-swapoff-and-swapon.patch > makes this patch redundant? > oop, hang on. This patch *is* a stealth-updated version of http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-fix-race-on-swap_info-reuse-between-swapoff-and-swapon.patch. Undocumented removals of si->swap_map have been added. What's going on there? I think I'll stick with the original patch for now. If you see additional optimisations or changes, let's address that separately? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/24][Resend] ACPI / hotplug / PCI: Move PCI rescan-remove locking to hotplug_event()
From: Rafael J. Wysocki
Commit 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove
locking) modified ACPIPHP to protect its PCI device removal and addition
code paths from races against sysfs-driven rescan and remove operations
with the help of PCI rescan-remove locking. However, it overlooked the
fact that hotplug_event_work() is not the only caller of hotplug_event()
which may also be called by dock_hotplug_event() and that code path
is missing the PCI rescan-remove locking. This means that, although
the PCI rescan-remove lock is held as appropriate during the handling
of events originating from handle_hotplug_event(), the ACPIPHP's
operations resulting from dock events may still suffer the race
conditions that commit 9217a984671e was supposed to eliminate.
To address that problem, move the PCI rescan-remove locking from
hotplug_event_work() to hotplug_event() so that it is used regardless
of the way that function is invoked.
Revamps: 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove
locking)
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/pci/hotplug/acpiphp_glue.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -852,6 +852,7 @@ static void hotplug_event(acpi_handle ha
mutex_unlock(_context_lock);
+ pci_lock_rescan_remove();
acpi_get_name(handle, ACPI_FULL_PATHNAME, );
switch (type) {
@@ -905,6 +906,7 @@ static void hotplug_event(acpi_handle ha
break;
}
+ pci_unlock_rescan_remove();
if (bridge)
put_bridge(bridge);
}
@@ -915,11 +917,9 @@ static void hotplug_event_work(void *dat
acpi_handle handle = context->handle;
acpi_scan_lock_acquire();
- pci_lock_rescan_remove();
hotplug_event(handle, type, context);
- pci_unlock_rescan_remove();
acpi_scan_lock_release();
acpi_evaluate_hotplug_ost(handle, type, ACPI_OST_SC_SUCCESS, NULL);
put_bridge(context->func.parent);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/24][New] ACPI / hotplug / PCI: Fix bridge removal race in handle_hotplug_event()
From: Rafael J. Wysocki
If a PCI bridge with an ACPIPHP context attached is removed via
sysfs, the code path executed as a result is the following:
pci_stop_and_remove_bus_device_locked
pci_remove_bus
pcibios_remove_bus
acpi_pci_remove_bus
acpiphp_remove_slots
cleanup_bridge
put_bridge
free_bridge
acpiphp_put_context (for each child, under context lock)
kfree (child context)
Now, if a hotplug notify is dispatched for one of the bridge's
children and the timing is such that handle_hotplug_event() for
that notify is executed while free_bridge() above is running,
the get_bridge(context->func.parent) in handle_hotplug_event()
will not really help, because it is too late to prevent the bridge
from going away and the child's context may be freed before
hotplug_event_work() scheduled from handle_hotplug_event()
dereferences the pointer to it passed via the data argument.
That will cause a kernel crash to happpen in hotplug_event_work().
To prevent that from happening, make handle_hotplug_event()
check the is_going_away flag of the function's parent bridge
(under acpiphp_context_lock) and bail out if it's set. Also,
make cleanup_bridge() set the bridge's is_going_away flag under
acpiphp_context_lock so that it cannot be changed between the
check and the subsequent get_bridge(context->func.parent) in
handle_hotplug_event().
Then, in the above scenario, handle_hotplug_event() will notice
that context->func.parent->is_going_away is already set and it
will exit immediately preventing the crash from happening.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -441,7 +441,9 @@ static void cleanup_bridge(struct acpiph
list_del(>list);
mutex_unlock(_mutex);
+ mutex_lock(_context_lock);
bridge->is_going_away = true;
+ mutex_unlock(_context_lock);
}
/**
@@ -941,6 +943,7 @@ static void handle_hotplug_event(acpi_ha
{
struct acpiphp_context *context;
u32 ost_code = ACPI_OST_SC_SUCCESS;
+ acpi_status status;
switch (type) {
case ACPI_NOTIFY_BUS_CHECK:
@@ -976,13 +979,20 @@ static void handle_hotplug_event(acpi_ha
mutex_lock(_context_lock);
context = acpiphp_get_context(handle);
- if (context && !WARN_ON(context->handle != handle)) {
- get_bridge(context->func.parent);
- acpiphp_put_context(context);
- acpi_hotplug_execute(hotplug_event_work, context, type);
+ if (!context || WARN_ON(context->handle != handle)
+ || context->func.parent->is_going_away)
+ goto err_out;
+
+ get_bridge(context->func.parent);
+ acpiphp_put_context(context);
+ status = acpi_hotplug_execute(hotplug_event_work, context, type);
+ if (ACPI_SUCCESS(status)) {
mutex_unlock(_context_lock);
return;
}
+ put_bridge(context->func.parent);
+
+ err_out:
mutex_unlock(_context_lock);
ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/24][Resend] ACPI / hotplug / PCI: Remove entries from bus->devices in reverse order
From: Rafael J. Wysocki
According to the changelog of commit 29ed1f29b68a (PCI: pciehp: Fix null
pointer deref when hot-removing SR-IOV device) it is unsafe to walk the
bus->devices list of a PCI bus and remove devices from it in direct order,
because that may lead to NULL pointer dereferences related to virtual
functions.
For this reason, change all of the bus->devices list walks in
acpiphp_glue.c during which devices may be removed to be carried out in
reverse order.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/pci/hotplug/acpiphp_glue.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -742,7 +742,7 @@ static void trim_stale_devices(struct pc
/* The device is a bridge. so check the bus below it. */
pm_runtime_get_sync(>dev);
- list_for_each_entry_safe(child, tmp, >devices, bus_list)
+ list_for_each_entry_safe_reverse(child, tmp, >devices,
bus_list)
trim_stale_devices(child);
pm_runtime_put(>dev);
@@ -773,8 +773,8 @@ static void acpiphp_check_bridge(struct
; /* do nothing */
} else if (get_slot_status(slot) == ACPI_STA_ALL) {
/* remove stale devices if any */
- list_for_each_entry_safe(dev, tmp, >devices,
-bus_list)
+ list_for_each_entry_safe_reverse(dev, tmp,
+>devices,
bus_list)
if (PCI_SLOT(dev->devfn) == slot->device)
trim_stale_devices(dev);
@@ -805,7 +805,7 @@ static void acpiphp_sanitize_bus(struct
int i;
unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM;
- list_for_each_entry_safe(dev, tmp, >devices, bus_list) {
+ list_for_each_entry_safe_reverse(dev, tmp, >devices, bus_list) {
for (i=0; iresource[i];
if ((res->flags & type_mask) && !res->start &&
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/24] ACPI / hotplug / PCI: ACPIPHP updates and consolidation with ACPI core
On Monday, February 03, 2014 12:44:08 PM Mika Westerberg wrote: > On Sun, Feb 02, 2014 at 01:19:33AM +0100, Rafael J. Wysocki wrote: > > On Monday, January 27, 2014 01:37:17 AM Rafael J. Wysocki wrote: > > > Hi All, > > > > > > ACPIPHP can be simplified a bit on top of some PCI and ACPI changes merged > > > recently and the following series of patches implements those > > > simplifications: > > > > > > [1/11] Fix up two kerneldoc comments in acpiphp_glue.c. > > > [2/11] Get rid of an unnecessary label in register_slot(). > > > [3/11] Drop acpiphp_bus_trim() and use acpi_bus_trim() instead of it > > > directly. > > > [4/11] Move the acpi_bus_get_device() call out of acpiphp_no_hotplug(). > > > [5/11] Store struct acpi_device pointers instead of ACPI handles in > > > struct acpiphp_context. > > > [6/11] Drop acpiphp_bus_add() (which has only one user). > > > [7/11] Drop crit_sect mutexes (that are redundant). > > > [8/11] Clean up the usage of the slot variable in hotplug_event(). > > > [9/11] Drop dev_in_slot() and rework disable_slot() to walk bus->devices > > > directly. > > > [10/11] Use acpi_handle_debug() in hotplug_event() instead of open-coded > > > stuff. > > > [11/11] Drop handle argument from the member functions of struct > > > acpi_dock_ops. > > > > > > All of that is relateively straightforward, but I have some more > > > intrusive changes > > > on top of it in the works. They will be posted separately later this > > > week. > > > > I've learned a couple of things since I sent this patchset. First, all > > bus->devices list walks that may remove PCI devices should be done in > > reverse > > order or they can crash if virtual functions are involved. Second, > > hotplug_event() > > (in acpiphp_glue.c) has to acquire pci_rescan_remove_lock by itself, > > because it > > may be called from multiple places and all of them need that lock to be > > held. > > That is done by patches [1-2/13] which I'm planning to push as fixes for > > 3.14-rc2. > > > > The rest is pretty much the same as last time except that the old patch > > [9/11] > > became [3/13] in this series and it has been changed so that the list is > > walked in > > reverse order. > > On Intel NUC and DZ77RE-75K, > > Tested-by: Mika Westerberg Thanks! As I said previously, I have found two concurrency-related bugs more in ACPIPHP and I needed to put fixes for those bugs at the top of the series (after previous [1-2/13] and the patch at https://patchwork.kernel.org/patch/3567701/). For this reason, I also had to rebase the ACPI/PCI hotplug consolidation patchset (https://lkml.org/lkml/2014/2/2/87) which got a few additional cosmetic changes too. The following is a combination of the two series with one patch dropped (it would conflict with [4-5/24]) and a few patches added. It is on top of 3.14-rc1. Patches [1-5/24], that are regarded as 3.14-rc2 material, are on the bleeding-edge branch of linux-pm.git. The remaining patches will show up in bleeding-edge shortly. [1/24] Remove entries from bus->devices in reverse order (in ACPIPHP). [2/24] Move PCI rescan-remove locking to hotplug_event(). [3/24] Scan root bus under the PCI rescan-remove lock [4/24] Fix race in handle_hotplug_event() related to concurrent bridge removal. [5/24] Fix race in hotplug_event() related to dock events and concurrent bridge removal. [6/24] Drop dev_in_slot() and rework disable_slot() to walk bus->devices directly. [7/24] Fix up two kerneldoc comments in acpiphp_glue.c. [8/24] Get rid of an unnecessary label in register_slot(). [9/24] Drop acpiphp_bus_trim() and use acpi_bus_trim() instead of it directly. [10/24] Move the acpi_bus_get_device() call out of acpiphp_no_hotplug(). [11/24] Store struct acpi_device pointers instead of ACPI handles in struct acpiphp_context. [12/24] Drop acpiphp_bus_add() (which has only one user). [13/24] Drop crit_sect mutexes (that are redundant). [14/24] Clean up the usage of the slot variable in hotplug_event(). [15/24] Use acpi_handle_debug() in hotplug_event() instead of open-coded stuff. [16/24] Do not pass ACPI handle to hotplug_event(). [17/24] Add a new function to ACPICA allowing a callback to be executed under the namespace mutex after calling acpi_ns_get_attached_data(). [18/24] Use the new ACPICA's function to fix a couple of potential races related to ACPI notifies. [19/24] Move the hotplug context lock definition to the ACPI core (from ACPIPHP). [20/24] Consolidate ACPI hotplug signaling for PCI and ACPI core. [21/24] Rework the handling of eject requests in the ACPI core. [22/24] Simplify a routine for installing hotplug notify handlers. [23/24] Dispatch ACPI hotplug notifications for "core" devices and PCI from acpi_bus_notify(). [24/24] Pass struct acpi_device pointer to acpiphp_check_host_bridge(). Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe
[PATCH 19/24][Update] ACPI / hotplug / PCI: Define hotplug context lock in the core
From: Rafael J. Wysocki
Subsequent changes will require the ACPI core to acquire the lock
protecting the ACPIPHP hotplug contexts, so move the definition of
the lock to the core and change its name to be more generic.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c| 11 +++
drivers/pci/hotplug/acpiphp_glue.c | 51 ++---
include/acpi/acpi_bus.h|2 +
3 files changed, 38 insertions(+), 26 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -41,6 +41,7 @@ static DEFINE_MUTEX(acpi_scan_lock);
static LIST_HEAD(acpi_scan_handlers_list);
DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
+static DEFINE_MUTEX(acpi_hp_context_lock);
struct acpi_device_bus_id{
char bus_id[15];
@@ -60,6 +61,16 @@ void acpi_scan_lock_release(void)
}
EXPORT_SYMBOL_GPL(acpi_scan_lock_release);
+void acpi_lock_hp_context(void)
+{
+ mutex_lock(_hp_context_lock);
+}
+
+void acpi_unlock_hp_context(void)
+{
+ mutex_unlock(_hp_context_lock);
+}
+
int acpi_scan_add_handler(struct acpi_scan_handler *handler)
{
if (!handler || !handler->attach)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -58,7 +58,6 @@
static LIST_HEAD(bridge_list);
static DEFINE_MUTEX(bridge_mutex);
-static DEFINE_MUTEX(acpiphp_context_lock);
static void handle_hotplug_event(acpi_handle handle, u32 type, void *data);
static void acpiphp_sanitize_bus(struct pci_bus *bus);
@@ -75,7 +74,7 @@ static void acpiphp_context_handler(acpi
* acpiphp_init_context - Create hotplug context and grab a reference to it.
* @adev: ACPI device object to create the context for.
*
- * Call under acpiphp_context_lock.
+ * Call under acpi_hp_context_lock.
*/
static struct acpiphp_context *acpiphp_init_context(struct acpi_device *adev)
{
@@ -100,7 +99,7 @@ static struct acpiphp_context *acpiphp_i
* acpiphp_get_context - Get hotplug context and grab a reference to it.
* @handle: ACPI object handle to get the context for.
*
- * Call under acpiphp_context_lock.
+ * Call under acpi_hp_context_lock.
*/
static struct acpiphp_context *acpiphp_get_context(acpi_handle handle)
{
@@ -122,7 +121,7 @@ static struct acpiphp_context *acpiphp_g
*
* The context object is removed if there are no more references to it.
*
- * Call under acpiphp_context_lock.
+ * Call under acpi_hp_context_lock.
*/
static void acpiphp_put_context(struct acpiphp_context *context)
{
@@ -151,7 +150,7 @@ static void free_bridge(struct kref *kre
struct acpiphp_slot *slot, *next;
struct acpiphp_func *func, *tmp;
- mutex_lock(_context_lock);
+ acpi_lock_hp_context();
bridge = container_of(kref, struct acpiphp_bridge, ref);
@@ -175,7 +174,7 @@ static void free_bridge(struct kref *kre
pci_dev_put(bridge->pci_dev);
kfree(bridge);
- mutex_unlock(_context_lock);
+ acpi_unlock_hp_context();
}
/*
@@ -214,16 +213,16 @@ static void dock_event(acpi_handle handl
{
struct acpiphp_context *context;
- mutex_lock(_context_lock);
+ acpi_lock_hp_context();
context = acpiphp_get_context(handle);
if (!context || WARN_ON(context->adev->handle != handle)
|| context->func.parent->is_going_away) {
- mutex_unlock(_context_lock);
+ acpi_unlock_hp_context();
return;
}
get_bridge(context->func.parent);
acpiphp_put_context(context);
- mutex_unlock(_context_lock);
+ acpi_unlock_hp_context();
hotplug_event(type, context);
@@ -310,17 +309,17 @@ static acpi_status register_slot(acpi_ha
device = (adr >> 16) & 0x;
function = adr & 0x;
- mutex_lock(_context_lock);
+ acpi_lock_hp_context();
context = acpiphp_init_context(adev);
if (!context) {
- mutex_unlock(_context_lock);
+ acpi_unlock_hp_context();
acpi_handle_err(handle, "No hotplug context\n");
return AE_NOT_EXIST;
}
newfunc = >func;
newfunc->function = function;
newfunc->parent = bridge;
- mutex_unlock(_context_lock);
+ acpi_unlock_hp_context();
if (acpi_has_method(handle, "_EJ0"))
newfunc->flags = FUNC_HAS_EJ0;
@@ -338,9 +337,9 @@ static acpi_status register_slot(acpi_ha
slot = kzalloc(sizeof(struct acpiphp_slot), GFP_KERNEL);
if (!slot) {
- mutex_lock(_context_lock);
+ acpi_lock_hp_context();
acpiphp_put_context(context);
- mutex_unlock(_context_lock);
+
Re: [PATCH 2/8] mm/swap: fix race on swap_info reuse between swapoff and swapon
On Mon, 27 Jan 2014 18:03:04 +0800 Weijie Yang wrote: > swapoff clear swap_info's SWP_USED flag prematurely and free its resources > after that. A concurrent swapon will reuse this swap_info while its previous > resources are not cleared completely. > > These late freed resources are: > - p->percpu_cluster > - swap_cgroup_ctrl[type] > - block_device setting > - inode->i_flags &= ~S_SWAPFILE > > This patch clear SWP_USED flag after all its resources freed, so that swapon > can reuse this swap_info by alloc_swap_info() safely. > > This patch is just for a rare scenario, aim to correct of code. I believe that http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-fix-race-on-swap_info-reuse-between-swapoff-and-swapon.patch makes this patch redundant? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 5/10] xfstest: shared/001: Standard collapse range tests
On Sun, Feb 02, 2014 at 02:45:58PM +0900, Namjae Jeon wrote: > From: Namjae Jeon > > This testcase(001) tries to test various corner cases > for fcollapse range functionality over different type of extents. > > Signed-off-by: Namjae Jeon > Signed-off-by: Ashish Sangwan Couple of things: > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ] && die_now > _md5_checksum $testfile > @@ -415,10 +425,10 @@ _test_generic_punch() > if [ "$remove_testfile" ]; then > rm -f $testfile > fi > - $XFS_IO_PROG -f -c "truncate 20k" \ > - -c "$alloc_cmd 0 8k" \ > - -c "pwrite 8k 8k" $sync_cmd \ > - -c "$zero_cmd 4k 8k" \ > + $XFS_IO_PROG -f -c "truncate $(($multiple * 20))k" \ > + -c "$alloc_cmd 0 $(($multiple * 8))k" \ > + -c "pwrite $(($multiple * 8))k $(($multiple * 8))k" > $sync_cmd \ > + -c "$zero_cmd $(($multiple * 4))k $(($multiple * 8))k" \ > -c "$map_cmd -v" $testfile | $filter_cmd This is unreadable, and therefore I'd consider that these changes render _test_generic_punch unmaintainable. Either it needs tobe factored to be more readable, or we need a more readable way of representing the offsets and sizes if we want them to be variable. For example: _4k="$((multiple * 4))k" _8k="$((multiple * 8))k" _20k="$((multiple * 20))k" leads to: $XFS_IO_PROG -f -c "truncate $_20k" \ -c "$alloc_cmd 0 $_8k" \ -c "pwrite $_8k $_8k" $sync_cmd \ -c "$zero_cmd $_4k $_8k" \ -c "$map_cmd -v" $testfile | $filter_cmd which is still readable and allows us to arbitrarily scale the parameters. It even allows us to handle different filesystem block sizes if we really want to > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ] && die_now > _md5_checksum $testfile > > + # If zero_cmd is fcollpase, don't check unaligned offsets > + if [ "$zero_cmd" == "fcollapse" ]; then > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + rm -f $testfile.2 > + fi > + return > + fi No need to remove the test files here - we remove them at test startup to ensure we have a known initial state > +0: [0..63]: extent > +bb7df04e1b0a2570657527a7e108ae23 > + 13. data -> unwritten -> data > +0: [0..63]: extent > +0f0151cbed83e4bf6e5bde26e82ab115 > + 14. data -> hole @ EOF > +fallocate: Invalid argument > +0: [0..159]: extent This error appears in all the golden outputs. If it's correct, then perhaps it should be filtered out or commented somewhere to explain why it is expected. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] of: restructure for_each macros to fix compile warnings
From: Rob Herring
Commit 00b2c76a6a "include/linux/of.h: make for_each_child_of_node()
reference its args when CONFIG_OF=n" fixed warnings for unused
variables, but introduced variable "used uninitialized" warnings.
Simply initializing the variables would result in "set but not used"
warnings with W=1.
Fix both types of warnings by making all the for_each macros
unconditional and rely on the dummy static inline functions to
initialize and reference any variables.
Reported-by: Geert Uytterhoeven
Cc: David Howells
Signed-off-by: Rob Herring
---
include/linux/of.h | 153 +
1 file changed, 84 insertions(+), 69 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 70c64ba..435cb99 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -169,35 +169,15 @@ static inline const char *of_node_full_name(const struct
device_node *np)
extern struct device_node *of_find_node_by_name(struct device_node *from,
const char *name);
-#define for_each_node_by_name(dn, name) \
- for (dn = of_find_node_by_name(NULL, name); dn; \
-dn = of_find_node_by_name(dn, name))
extern struct device_node *of_find_node_by_type(struct device_node *from,
const char *type);
-#define for_each_node_by_type(dn, type) \
- for (dn = of_find_node_by_type(NULL, type); dn; \
-dn = of_find_node_by_type(dn, type))
extern struct device_node *of_find_compatible_node(struct device_node *from,
const char *type, const char *compat);
-#define for_each_compatible_node(dn, type, compatible) \
- for (dn = of_find_compatible_node(NULL, type, compatible); dn; \
-dn = of_find_compatible_node(dn, type, compatible))
extern struct device_node *of_find_matching_node_and_match(
struct device_node *from,
const struct of_device_id *matches,
const struct of_device_id **match);
-static inline struct device_node *of_find_matching_node(
- struct device_node *from,
- const struct of_device_id *matches)
-{
- return of_find_matching_node_and_match(from, matches, NULL);
-}
-#define for_each_matching_node(dn, matches) \
- for (dn = of_find_matching_node(NULL, matches); dn; \
-dn = of_find_matching_node(dn, matches))
-#define for_each_matching_node_and_match(dn, matches, match) \
- for (dn = of_find_matching_node_and_match(NULL, matches, match); \
-dn; dn = of_find_matching_node_and_match(dn, matches, match))
+
extern struct device_node *of_find_node_by_path(const char *path);
extern struct device_node *of_find_node_by_phandle(phandle handle);
extern struct device_node *of_get_parent(const struct device_node *node);
@@ -209,43 +189,11 @@ extern struct device_node *of_get_next_available_child(
extern struct device_node *of_get_child_by_name(const struct device_node *node,
const char *name);
-#define for_each_child_of_node(parent, child) \
- for (child = of_get_next_child(parent, NULL); child != NULL; \
-child = of_get_next_child(parent, child))
-
-#define for_each_available_child_of_node(parent, child) \
- for (child = of_get_next_available_child(parent, NULL); child != NULL; \
-child = of_get_next_available_child(parent, child))
-
-static inline int of_get_child_count(const struct device_node *np)
-{
- struct device_node *child;
- int num = 0;
-
- for_each_child_of_node(np, child)
- num++;
-
- return num;
-}
-
-static inline int of_get_available_child_count(const struct device_node *np)
-{
- struct device_node *child;
- int num = 0;
-
- for_each_available_child_of_node(np, child)
- num++;
-
- return num;
-}
/* cache lookup */
extern struct device_node *of_find_next_cache_node(const struct device_node *);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
-#define for_each_node_with_property(dn, prop_name) \
- for (dn = of_find_node_with_property(NULL, prop_name); dn; \
-dn = of_find_node_with_property(dn, prop_name))
extern struct property *of_find_property(const struct device_node *np,
const char *name,
@@ -367,42 +315,53 @@ static inline struct device_node
*of_find_node_by_name(struct device_node *from,
return NULL;
}
-static inline struct device_node *of_get_parent(const struct device_node *node)
+static inline struct device_node *of_find_node_by_type(struct device_node
*from,
+ const char *type)
{
return NULL;
}
-static inline bool of_have_populated_dt(void)
+static inline struct device_node *of_find_matching_node_and_match(
+ struct device_node *from,
+ const struct of_device_id *matches,
+ const struct of_device_id **match)
{
- return false;
+ return NULL;
}
-/* Kill an unused variable
Re: [PATCH 0/4] clk: mvebu: fix clk init order
Hi Sebastian, On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote: > On 01/30/14 11:24, Gregory CLEMENT wrote: > >On 25/01/2014 19:19, Sebastian Hesselbarth wrote: > >>This patch set fixes clk init order that went upside-down with > >>v3.14. I haven't really investigated what caused this, but I assume > >>it is related with DT node reordering by addresses. > > > >Can you explain what kind of issue do you observe? > > Sure. When probing CLK_OF_DECLAREed clock drivers, clock-gating driver > gets registered before core-clocks. It therefore cannot resolve it's > parent clock name for tclk and all clock gates will have no parent > clock. > > Usually, you'll see in some drivers (e.g. v643xx_eth) div_by_zero errors > poping up, when they calculate a frequency division factors based on > clock gate frequency, which should have been tclk but is 0 now. Well, to be honnest, I have no idea whether your patch is the right way to fix the problem or not, but what I can say is that it fixes such oopses that appear in 3.14-rc1 when booting on mirabox : Division by zero in kernel. CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.13.0-bck-mbx #6 Workqueue: kmmcd mmc_rescan [] (unwind_backtrace+0x1/0x98) from [] (show_stack+0xb/0xc) [] (show_stack+0xb/0xc) from [] (Ldiv0+0x9/0x12) [] (Ldiv0+0x9/0x12) from [] (mvsd_set_ios+0xcb/0x160) [] (mvsd_set_ios+0xcb/0x160) from [] (__mmc_set_clock+0x2d/0 x40) [] (__mmc_set_clock+0x2d/0x40) from [] (mmc_sdio_init_card+0 x391/0x808) [] (mmc_sdio_init_card+0x391/0x808) from [] (mmc_attach_sdio +0x5b/0x218) [] (mmc_attach_sdio+0x5b/0x218) from [] (mmc_rescan+0x159/0x 1b4) [] (mmc_rescan+0x159/0x1b4) from [] (process_one_work+0xa9/0 x21c) [] (process_one_work+0xa9/0x21c) from [] (worker_thread+0xb5 /0x248) [] (worker_thread+0xb5/0x248) from [] (kthread+0x7b/0x94) +0xa7/0x138) [] (kernel_init_freeable+0xa7/0x138) from [] (kernel_init+0x 7/0xb8) [] (kernel_init+0x7/0xb8) from [] (ret_from_fork+0x11/0x34) mvsdio d00d4000.mvsdio: lacking card detect (fall back to polling) By the way, seeing how often a trick related to the DT is nedeed to solve an oops or a panic, I'm really scared that this whole DT mess is just becoming the exact copy of the ACPI mess (but 15 years later) and we'll experience the same horrible things :-( Sometimes I'm wondering whether there are not too many structural things put in there... Regards, Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 5/6] fat: permit to return phy block number by fibmap in fallocated region
2014-02-03, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> From: Namjae Jeon
>>
>> Make the fibmap call the return the proper physical block number for any
>> offset request in the fallocated range.
>>
>> Signed-off-by: Namjae Jeon
>> Signed-off-by: Amit Sahrawat
>> ---
>> fs/fat/cache.c | 13 ++---
>> fs/fat/fat.h |3 +++
>> fs/fat/inode.c |3 +++
>> 3 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/fat/cache.c b/fs/fat/cache.c
>> index a132666..d22c1a2 100644
>> --- a/fs/fat/cache.c
>> +++ b/fs/fat/cache.c
>> @@ -325,19 +325,26 @@ int fat_bmap(struct inode *inode, sector_t sector,
>> sector_t *phys,
>>
>> last_block = (i_size_read(inode) + (blocksize - 1)) >> blocksize_bits;
>> if (sector >= last_block) {
>> -if (!create)
>> -return 0;
>> -
>> /*
>> * Both ->mmu_private and ->i_disksize can access
>> * on only allocation path. (caller must hold ->i_mutex)
>> */
>> last_block = (MSDOS_I(inode)->i_disksize + (blocksize - 1))
>> >> blocksize_bits;
>> +if (!create) {
>> +/* Map a block in fallocated region */
>> +if (atomic_read(_I(inode)->beyond_isize))
>> +if (sector < last_block)
>> +goto out_map_cluster;
>> +
>> +return 0;
>> +}
>> +
>> if (sector >= last_block)
>> return 0;
>> }
>>
>> +out_map_cluster:
>> cluster = sector >> (sbi->cluster_bits - sb->s_blocksize_bits);
>> offset = sector & (sbi->sec_per_clus - 1);
>> cluster = fat_bmap_cluster(inode, cluster);
>> diff --git a/fs/fat/fat.h b/fs/fat/fat.h
>> index 7b5851f..b884276 100644
>> --- a/fs/fat/fat.h
>> +++ b/fs/fat/fat.h
>> @@ -129,6 +129,9 @@ struct msdos_inode_info {
>> struct hlist_node i_dir_hash; /* hash by i_logstart */
>> struct rw_semaphore truncate_lock; /* protect bmap against truncate */
>> struct inode vfs_inode;
>> +
>> +/* for getting block number beyond file size in case of fallocate */
>> +atomic_t beyond_isize;
>> };
>>
>> struct fat_slot_info {
>> diff --git a/fs/fat/inode.c b/fs/fat/inode.c
>> index 3636617..1c3192b 100644
>> --- a/fs/fat/inode.c
>> +++ b/fs/fat/inode.c
>> @@ -256,7 +256,10 @@ static sector_t _fat_bmap(struct address_space
>> *mapping, sector_t block)
>>
>> /* fat_get_cluster() assumes the requested blocknr isn't truncated. */
>> down_read(_I(mapping->host)->truncate_lock);
>> +/* To get block number beyond file size in fallocated region */
>> +atomic_set(_I(mapping->host)->beyond_isize, 1);
>> blocknr = generic_block_bmap(mapping, block, fat_get_block);
>> +atomic_set(_I(mapping->host)->beyond_isize, 0);
>> up_read(_I(mapping->host)->truncate_lock);
>
> This is racy. While user is using bmap, kernel can allocate new blocks.
> We should use another function for this.
I understand that fat can map fallocated blocks in read case while
user is using bmap.
But I can not find the case allocate new blocks.
If I am missing something, Could you please elaborate more ?
Is it a case of _bmap request returning the block number for block
allocated in parallel write path ?
Thanks.
>
> For example, something like
>
> fat_get_block_bmap()
> {
> [...]
> fat_get_block2(inode, iblock, _blocks, bh_result, create, bmap);
> [...]
> }
>
> blocknr = generic_block_bmap(mapping, block, fat_get_block_bmap);
> --
> OGAWA Hirofumi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 1/6] spmi: Linux driver framework for SPMI
From: Kenneth Heitke
System Power Management Interface (SPMI) is a specification
developed by the MIPI (Mobile Industry Process Interface) Alliance
optimized for the real time control of Power Management ICs (PMIC).
SPMI is a two-wire serial interface that supports up to 4 master
devices and up to 16 logical slaves.
The framework supports message APIs, multiple busses (1 controller
per bus) and multiple clients/slave devices per controller.
Signed-off-by: Kenneth Heitke
Signed-off-by: Michael Bohan
Signed-off-by: Josh Cartwright
---
drivers/Kconfig | 2 +
drivers/Makefile| 1 +
drivers/spmi/Kconfig| 9 +
drivers/spmi/Makefile | 4 +
drivers/spmi/spmi.c | 609
include/dt-bindings/spmi/spmi.h | 18 ++
include/linux/mod_devicetable.h | 8 +
include/linux/spmi.h| 191 +
8 files changed, 842 insertions(+)
create mode 100644 drivers/spmi/Kconfig
create mode 100644 drivers/spmi/Makefile
create mode 100644 drivers/spmi/spmi.c
create mode 100644 include/dt-bindings/spmi/spmi.h
create mode 100644 include/linux/spmi.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index b3138fb..e0a4ae6 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -52,6 +52,8 @@ source "drivers/i2c/Kconfig"
source "drivers/spi/Kconfig"
+source "drivers/spmi/Kconfig"
+
source "drivers/hsi/Kconfig"
source "drivers/pps/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 8e3b8b0..3d6de8b 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_ATA) += ata/
obj-$(CONFIG_TARGET_CORE) += target/
obj-$(CONFIG_MTD) += mtd/
obj-$(CONFIG_SPI) += spi/
+obj-$(CONFIG_SPMI) += spmi/
obj-y += hsi/
obj-y += net/
obj-$(CONFIG_ATM) += atm/
diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
new file mode 100644
index 000..1dbfee0
--- /dev/null
+++ b/drivers/spmi/Kconfig
@@ -0,0 +1,9 @@
+#
+# SPMI driver configuration
+#
+menuconfig SPMI
+ tristate "SPMI support"
+ help
+ SPMI (System Power Management Interface) is a two-wire
+ serial interface between baseband and application processors
+ and Power Management Integrated Circuits (PMIC).
diff --git a/drivers/spmi/Makefile b/drivers/spmi/Makefile
new file mode 100644
index 000..1de1acd
--- /dev/null
+++ b/drivers/spmi/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for kernel SPMI framework.
+#
+obj-$(CONFIG_SPMI) += spmi.o
diff --git a/drivers/spmi/spmi.c b/drivers/spmi/spmi.c
new file mode 100644
index 000..6122c8f
--- /dev/null
+++ b/drivers/spmi/spmi.c
@@ -0,0 +1,609 @@
+/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static DEFINE_IDA(ctrl_ida);
+
+static void spmi_dev_release(struct device *dev)
+{
+ struct spmi_device *sdev = to_spmi_device(dev);
+ kfree(sdev);
+}
+
+static const struct device_type spmi_dev_type = {
+ .release= spmi_dev_release,
+};
+
+static void spmi_ctrl_release(struct device *dev)
+{
+ struct spmi_controller *ctrl = to_spmi_controller(dev);
+ ida_simple_remove(_ida, ctrl->nr);
+ kfree(ctrl);
+}
+
+static const struct device_type spmi_ctrl_type = {
+ .release= spmi_ctrl_release,
+};
+
+#ifdef CONFIG_PM_RUNTIME
+static int spmi_runtime_suspend(struct device *dev)
+{
+ struct spmi_device *sdev = to_spmi_device(dev);
+ int err;
+
+ err = pm_generic_runtime_suspend(dev);
+ if (err)
+ return err;
+
+ return spmi_command_sleep(sdev);
+}
+
+static int spmi_runtime_resume(struct device *dev)
+{
+ struct spmi_device *sdev = to_spmi_device(dev);
+ int err;
+
+ err = spmi_command_wakeup(sdev);
+ if (err)
+ return err;
+
+ return pm_generic_runtime_resume(dev);
+}
+#endif
+
+static const struct dev_pm_ops spmi_pm_ops = {
+ SET_RUNTIME_PM_OPS(
+ spmi_runtime_suspend,
+ spmi_runtime_resume,
+ NULL
+ )
+};
+
+static int spmi_device_match(struct device *dev, struct device_driver *drv)
+{
+ if (of_driver_match_device(dev, drv))
+ return 1;
+
+ if (drv->name)
+ return
[PATCH v5 2/6] spmi: add generic SPMI controller binding documentation
Signed-off-by: Josh Cartwright
---
Documentation/devicetree/bindings/spmi/spmi.txt | 41 +
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spmi/spmi.txt
diff --git a/Documentation/devicetree/bindings/spmi/spmi.txt
b/Documentation/devicetree/bindings/spmi/spmi.txt
new file mode 100644
index 000..462a42f
--- /dev/null
+++ b/Documentation/devicetree/bindings/spmi/spmi.txt
@@ -0,0 +1,41 @@
+System Power Management Interface (SPMI) Controller
+
+This document defines a generic set of bindings for use by SPMI controllers. A
+controller is modelled in device tree as a node with zero or more child nodes,
+each representing a unique slave on the bus.
+
+Required properties:
+- #address-cells : must be set to 2
+- #size-cells : must be set to 0
+
+Child nodes:
+
+An SPMI controller node can contain zero or more child nodes representing slave
+devices on the bus. Child 'reg' properties are specified as an address, type
+pair. The address must be in the range 0-15 (4 bits). The type must be one of
+SPMI_USID (0) or SPMI_GSID (1) for Unique Slave ID or Group Slave ID
respectively.
+These are the identifiers "statically assigned by the system integrator", as
+per the SPMI spec.
+
+Each child node must have one and only one 'reg' entry of type SPMI_USID.
+
+#include
+
+ spmi@.. {
+ compatible = "...";
+ reg = <...>;
+
+ #address-cells = <2>;
+ #size-cells <0>;
+
+ child@0 {
+ compatible = "...";
+ reg = <0 SPMI_USID>;
+ };
+
+ child@7 {
+ compatible = "...";
+ reg = <7 SPMI_USID
+ 3 SPMI_GSID>;
+ };
+ };
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 4/6] spmi: pmic_arb: add support for interrupt handling
The Qualcomm PMIC Arbiter, in addition to being a basic SPMI controller,
also implements interrupt handling for slave devices. Note, this is
outside the scope of SPMI, as SPMI leaves interrupt handling completely
unspecified.
Extend the driver to provide a irq_chip implementation and chained irq
handling which allows for these interrupts to be used.
Cc: Thomas Gleixner
Signed-off-by: Josh Cartwright
---
drivers/spmi/Kconfig | 1 +
drivers/spmi/spmi-pmic-arb.c | 377 ++-
2 files changed, 376 insertions(+), 2 deletions(-)
diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
index 80b7901..075bd79 100644
--- a/drivers/spmi/Kconfig
+++ b/drivers/spmi/Kconfig
@@ -13,6 +13,7 @@ if SPMI
config SPMI_MSM_PMIC_ARB
tristate "Qualcomm MSM SPMI Controller (PMIC Arbiter)"
depends on ARM
+ depends on IRQ_DOMAIN
depends on ARCH_MSM || COMPILE_TEST
default ARCH_MSM
help
diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
index b7f753f..e4b6854 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -13,6 +13,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -103,6 +106,14 @@ enum pmic_arb_cmd_op_code {
* @cnfg: address of the PMIC Arbiter configuration registers.
* @lock: lock to synchronize accesses.
* @channel: which channel to use for accesses.
+ * @irq: PMIC ARB interrupt.
+ * @ee:the current Execution Environment
+ * @min_apid: minimum APID (used for bounding IRQ search)
+ * @max_apid: maximum APID
+ * @mapping_table: in-memory copy of PPID -> APID mapping table.
+ * @domain:irq domain object for PMIC IRQ domain
+ * @spmic: SPMI controller object
+ * @apid_to_ppid: cached mapping from APID to PPID
*/
struct spmi_pmic_arb_dev {
void __iomem*base;
@@ -110,6 +121,14 @@ struct spmi_pmic_arb_dev {
void __iomem*cnfg;
spinlock_t lock;
u8 channel;
+ int irq;
+ u8 ee;
+ u8 min_apid;
+ u8 max_apid;
+ u32 mapping_table[SPMI_MAPPING_TABLE_LEN];
+ struct irq_domain *domain;
+ struct spmi_controller *spmic;
+ u16 apid_to_ppid[256];
};
static inline u32 pmic_arb_base_read(struct spmi_pmic_arb_dev *dev, u32 offset)
@@ -306,12 +325,316 @@ static int pmic_arb_write_cmd(struct spmi_controller
*ctrl, u8 opc, u8 sid,
return rc;
}
+enum qpnpint_regs {
+ QPNPINT_REG_RT_STS = 0x10,
+ QPNPINT_REG_SET_TYPE= 0x11,
+ QPNPINT_REG_POLARITY_HIGH = 0x12,
+ QPNPINT_REG_POLARITY_LOW= 0x13,
+ QPNPINT_REG_LATCHED_CLR = 0x14,
+ QPNPINT_REG_EN_SET = 0x15,
+ QPNPINT_REG_EN_CLR = 0x16,
+ QPNPINT_REG_LATCHED_STS = 0x18,
+};
+
+struct spmi_pmic_arb_qpnpint_type {
+ u8 type; /* 1 -> edge */
+ u8 polarity_high;
+ u8 polarity_low;
+} __packed;
+
+/* Simplified accessor functions for irqchip callbacks */
+static void qpnpint_spmi_write(struct irq_data *d, u8 reg, void *buf,
+ size_t len)
+{
+ struct spmi_pmic_arb_dev *pa = irq_data_get_irq_chip_data(d);
+ u8 sid = d->hwirq >> 24;
+ u8 per = d->hwirq >> 16;
+
+ if (pmic_arb_write_cmd(pa->spmic, SPMI_CMD_EXT_WRITEL, sid,
+ (per << 8) + reg, buf, len))
+ dev_err_ratelimited(>spmic->dev,
+ "failed irqchip transaction on %x\n",
+ d->irq);
+}
+
+static void qpnpint_spmi_read(struct irq_data *d, u8 reg, void *buf, size_t
len)
+{
+ struct spmi_pmic_arb_dev *pa = irq_data_get_irq_chip_data(d);
+ u8 sid = d->hwirq >> 24;
+ u8 per = d->hwirq >> 16;
+
+ if (pmic_arb_read_cmd(pa->spmic, SPMI_CMD_EXT_READL, sid,
+ (per << 8) + reg, buf, len))
+ dev_err_ratelimited(>spmic->dev,
+ "failed irqchip transaction on %x\n",
+ d->irq);
+}
+
+static void periph_interrupt(struct spmi_pmic_arb_dev *pa, u8 apid)
+{
+ unsigned int irq;
+ u32 status;
+ int id;
+
+ status = readl_relaxed(pa->intr + SPMI_PIC_IRQ_STATUS(apid));
+ while (status) {
+ id = ffs(status) - 1;
+ status &= ~(1 << id);
+ irq = irq_find_mapping(pa->domain,
+ pa->apid_to_ppid[apid] << 16
+| id << 8
+| apid);
+ generic_handle_irq(irq);
[PATCH v5 5/6] spmi: document the PMIC arbiter SPMI bindings
Signed-off-by: Josh Cartwright
---
.../bindings/spmi/qcom,spmi-pmic-arb.txt | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
new file mode 100644
index 000..a0a5759
--- /dev/null
+++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
@@ -0,0 +1,60 @@
+Qualcomm SPMI Controller (PMIC Arbiter)
+
+The SPMI PMIC Arbiter is found on the Snapdragon 800 Series. It is an SPMI
+controller with wrapping arbitration logic to allow for multiple on-chip
+devices to control a single SPMI master.
+
+The PMIC Arbiter can also act as an interrupt controller, providing interrupts
+to slave devices.
+
+See spmi.txt for the generic SPMI controller binding requirements for child
+nodes.
+
+See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
+generic interrupt controller binding documentation.
+
+Required properties:
+- compatible : should be "qcom,spmi-pmic-arb".
+- reg-names : should be "core", "intr", "cnfg"
+- reg : register specifiers, must contain:
+ "core" - core registers
+ "intr" - interrupt controller registers
+ "cnfg" - configuration registers
+- #address-cells : must be set to 2
+- #size-cells : must be set to 0
+- qcom,ee : indicates the active Execution Environment identifier (0-5)
+- qcom,channel : which of the PMIC Arb provided channels to use for accesses
(0-5)
+- interrupts : interrupt list for the PMIC Arb controller, must contain a
+ single interrupt entry for the peripheral interrupt
+- interrupt-names : corresponding interrupt names for the interrupts
+listed in the 'interrupts' property, must contain:
+ "periph_irq" - summary interrupt for PMIC peripherals
+- interrupt-controller : boolean indicator that the PMIC arbiter is an
interrupt controller
+- #interrupt-cells : must be set to 4. Interrupts are specified as a 4-tuple:
+cell 1: slave ID for the requested interrupt (0-15)
+cell 2: peripheral ID for requested interrupt (0-255)
+cell 3: the requested peripheral interrupt (0-7)
+cell 4: interrupt flags indicating level-sense information, as defined in
+dt-bindings/interrupt-controller/irq.h
+
+Example:
+
+ spmi {
+ compatible = "qcom,spmi-pmic-arb";
+ reg-names = "core", "intr", "cnfg";
+ reg = <0xfc4cf000 0x1000>,
+ <0xfc4cb000 0x1000>,
+ <0xfc4ca000 0x1000>;
+
+ interrupt-names = "periph_irq";
+ interrupts = <0 190 0>;
+
+ qcom,ee = <0>;
+ qcom,channel = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ interrupt-controller;
+ #interrupt-cells = <4>;
+ };
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 6/6] regmap: spmi: support base and extended register spaces
SPMI states that a slave may contain two register spaces, the Base
register space is a 5-bit byte-addressable space accessed via the
Register Read/Write and Register Zero Write command sequences, and the
Extended register space: a 16-bit byte-addressable space accessed via
the Extended Read/Write and Extended Read/Write Long command sequences.
Provide support for accessing both of these spaces, taking advantage of
the more bandwidth-efficient commands ('Register 0 Write' vs 'Register
Write', and 'Extended Register Read/Write' vs 'Extended Register
Read/Write Long') when possible.
Signed-off-by: Josh Cartwright
Acked-by: Mark Brown
---
drivers/base/regmap/regmap-spmi.c | 228 --
include/linux/regmap.h| 12 +-
2 files changed, 205 insertions(+), 35 deletions(-)
diff --git a/drivers/base/regmap/regmap-spmi.c
b/drivers/base/regmap/regmap-spmi.c
index ac23910..d7026dc 100644
--- a/drivers/base/regmap/regmap-spmi.c
+++ b/drivers/base/regmap/regmap-spmi.c
@@ -22,69 +22,235 @@
#include
#include
-static int regmap_spmi_read(void *context,
- const void *reg, size_t reg_size,
- void *val, size_t val_size)
+static int regmap_spmi_base_read(void *context,
+const void *reg, size_t reg_size,
+void *val, size_t val_size)
{
+ u8 addr = *(u8 *)reg;
+ int err = 0;
+
+ BUG_ON(reg_size != 1);
+
+ while (val_size-- && !err)
+ err = spmi_register_read(context, addr++, val++);
+
+ return err;
+}
+
+static int regmap_spmi_base_gather_write(void *context,
+const void *reg, size_t reg_size,
+const void *val, size_t val_size)
+{
+ const u8 *data = val;
+ u8 addr = *(u8 *)reg;
+ int err = 0;
+
+ BUG_ON(reg_size != 1);
+
+ /*
+* SPMI defines a more bandwidth-efficient 'Register 0 Write' sequence,
+* use it when possible.
+*/
+ if (addr == 0 && val_size) {
+ err = spmi_register_zero_write(context, *data);
+ if (err)
+ goto err_out;
+
+ data++;
+ addr++;
+ val_size--;
+ }
+
+ while (val_size) {
+ err = spmi_register_write(context, addr, *data);
+ if (err)
+ goto err_out;
+
+ data++;
+ addr++;
+ val_size--;
+ }
+
+err_out:
+ return err;
+}
+
+static int regmap_spmi_base_write(void *context, const void *data,
+ size_t count)
+{
+ BUG_ON(count < 1);
+ return regmap_spmi_base_gather_write(context, data, 1, data + 1,
+count - 1);
+}
+
+static struct regmap_bus regmap_spmi_base = {
+ .read = regmap_spmi_base_read,
+ .write = regmap_spmi_base_write,
+ .gather_write = regmap_spmi_base_gather_write,
+ .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
+ .val_format_endian_default = REGMAP_ENDIAN_NATIVE,
+};
+
+/**
+ * regmap_init_spmi_base(): Create regmap for the Base register space
+ * @sdev: SPMI device that will be interacted with
+ * @config:Configuration for register map
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer to
+ * a struct regmap.
+ */
+struct regmap *regmap_init_spmi_base(struct spmi_device *sdev,
+const struct regmap_config *config)
+{
+ return regmap_init(>dev, _spmi_base, sdev, config);
+}
+EXPORT_SYMBOL_GPL(regmap_init_spmi_base);
+
+/**
+ * devm_regmap_init_spmi_base(): Create managed regmap for Base register space
+ * @sdev: SPMI device that will be interacted with
+ * @config:Configuration for register map
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a struct regmap. The regmap will be automatically freed by the
+ * device management code.
+ */
+struct regmap *devm_regmap_init_spmi_base(struct spmi_device *sdev,
+ const struct regmap_config *config)
+{
+ return devm_regmap_init(>dev, _spmi_base, sdev, config);
+}
+EXPORT_SYMBOL_GPL(devm_regmap_init_spmi_base);
+
+static int regmap_spmi_ext_read(void *context,
+ const void *reg, size_t reg_size,
+ void *val, size_t val_size)
+{
+ int err = 0;
+ size_t len;
+ u16 addr;
+
BUG_ON(reg_size != 2);
- return spmi_ext_register_readl(context, *(u16 *)reg,
- val, val_size);
+
+ addr = *(u16 *)reg;
+
+ /*
+* Split accesses into two to take advantage of the more
+* bandwidth-efficient 'Extended Register Read'
[PATCH v5 3/6] spmi: Add MSM PMIC Arbiter SPMI controller
From: Kenneth Heitke
Qualcomm's PMIC Arbiter SPMI controller functions as a bus master and
is used to communication with one or more PMIC (slave) devices on the
SPMI bus. The PMIC Arbiter is actually a hardware wrapper around the
SPMI controller that provides concurrent and autonomous PMIC access
to various entities that need to communicate with the PMIC.
The SPMI controller hardware handles all of the SPMI bus activity (bus
arbitration, sequence start condition, transmission of frames, etc).
This software driver uses the PMIC Arbiter register interface to
initiate command sequences on the SPMI bus. The status register is
read to determine when the command sequence has completed and whether
or not it completed successfully.
Signed-off-by: Kenneth Heitke
Signed-off-by: Josh Cartwright
---
drivers/spmi/Kconfig | 17 ++
drivers/spmi/Makefile| 2 +
drivers/spmi/spmi-pmic-arb.c | 405 +++
3 files changed, 424 insertions(+)
create mode 100644 drivers/spmi/spmi-pmic-arb.c
diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
index 1dbfee0..80b7901 100644
--- a/drivers/spmi/Kconfig
+++ b/drivers/spmi/Kconfig
@@ -7,3 +7,20 @@ menuconfig SPMI
SPMI (System Power Management Interface) is a two-wire
serial interface between baseband and application processors
and Power Management Integrated Circuits (PMIC).
+
+if SPMI
+
+config SPMI_MSM_PMIC_ARB
+ tristate "Qualcomm MSM SPMI Controller (PMIC Arbiter)"
+ depends on ARM
+ depends on ARCH_MSM || COMPILE_TEST
+ default ARCH_MSM
+ help
+ If you say yes to this option, support will be included for the
+ built-in SPMI PMIC Arbiter interface on Qualcomm MSM family
+ processors.
+
+ This is required for communicating with Qualcomm PMICs and
+ other devices that have the SPMI interface.
+
+endif
diff --git a/drivers/spmi/Makefile b/drivers/spmi/Makefile
index 1de1acd..fc75104 100644
--- a/drivers/spmi/Makefile
+++ b/drivers/spmi/Makefile
@@ -2,3 +2,5 @@
# Makefile for kernel SPMI framework.
#
obj-$(CONFIG_SPMI) += spmi.o
+
+obj-$(CONFIG_SPMI_MSM_PMIC_ARB)+= spmi-pmic-arb.o
diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
new file mode 100644
index 000..b7f753f
--- /dev/null
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -0,0 +1,405 @@
+/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PMIC Arbiter configuration registers */
+#define PMIC_ARB_VERSION 0x
+#define PMIC_ARB_INT_EN0x0004
+
+/* PMIC Arbiter channel registers */
+#define PMIC_ARB_CMD(N)(0x0800 + (0x80 * (N)))
+#define PMIC_ARB_CONFIG(N) (0x0804 + (0x80 * (N)))
+#define PMIC_ARB_STATUS(N) (0x0808 + (0x80 * (N)))
+#define PMIC_ARB_WDATA0(N) (0x0810 + (0x80 * (N)))
+#define PMIC_ARB_WDATA1(N) (0x0814 + (0x80 * (N)))
+#define PMIC_ARB_RDATA0(N) (0x0818 + (0x80 * (N)))
+#define PMIC_ARB_RDATA1(N) (0x081C + (0x80 * (N)))
+
+/* Interrupt Controller */
+#define SPMI_PIC_OWNER_ACC_STATUS(M, N)(0x + ((32 * (M)) + (4 *
(N
+#define SPMI_PIC_ACC_ENABLE(N) (0x0200 + (4 * (N)))
+#define SPMI_PIC_IRQ_STATUS(N) (0x0600 + (4 * (N)))
+#define SPMI_PIC_IRQ_CLEAR(N) (0x0A00 + (4 * (N)))
+
+/* Mapping Table */
+#define SPMI_MAPPING_TABLE_REG(N) (0x0B00 + (4 * (N)))
+#define SPMI_MAPPING_BIT_INDEX(X) (((X) >> 18) & 0xF)
+#define SPMI_MAPPING_BIT_IS_0_FLAG(X) (((X) >> 17) & 0x1)
+#define SPMI_MAPPING_BIT_IS_0_RESULT(X)(((X) >> 9) & 0xFF)
+#define SPMI_MAPPING_BIT_IS_1_FLAG(X) (((X) >> 8) & 0x1)
+#define SPMI_MAPPING_BIT_IS_1_RESULT(X)(((X) >> 0) & 0xFF)
+
+#define SPMI_MAPPING_TABLE_LEN 255
+#define SPMI_MAPPING_TABLE_TREE_DEPTH 16 /* Maximum of 16-bits */
+
+/* Ownership Table */
+#define SPMI_OWNERSHIP_TABLE_REG(N)(0x0700 + (4 * (N)))
+#define SPMI_OWNERSHIP_PERIPH2OWNER(X) ((X) & 0x7)
+
+/* Channel Status fields */
+enum pmic_arb_chnl_status {
+ PMIC_ARB_STATUS_DONE= (1 << 0),
+ PMIC_ARB_STATUS_FAILURE = (1 << 1),
+ PMIC_ARB_STATUS_DENIED = (1 << 2),
+ PMIC_ARB_STATUS_DROPPED = (1 << 3),
+};
+
+/* Command register fields */
+#define PMIC_ARB_CMD_MAX_BYTE_COUNT8
+
+/* Command Opcodes
[PATCH v5 0/6] Add support for the System Power Management Interface (SPMI)
The System Power Management Interface (SPMI) is a high-speed,
low-latency, bi-directional, two-wire serial bus suitable for real-time
control of voltage and frequency scaled multi-core application
processors and its power management of auxiliary components. SPMI
obsoletes a number of legacy, custom point-to-point interfaces and
provides a low pin count, high-speed control bus for up to 4 Master and
16 Slave devices.
SPMI is specified by the MIPI (Mobile Industry Process Interface)
Alliance [1].
This patchset is intended both to provide a core implementation of SPMI and
also to provide a controller driver implementation.
- Patches 1-2 implement the SPMI core functionality and provide basic
DT binding documentation
- Patches 3-5 provide an implementation of an SPMI controller, the
Qualcomm SPMI PMIC Arbiter, currently used on the 8x74 SoCs.
- Patch 6 rounds out regmap support for SPMI
Changes from v4[2]:
- Fixed a few minor error-handling bugs found with further testing
- Addressed Courtney Cavin's feedback regarding device tree bindings
- Reworked Kconfig options a bit (allow for building PMIC arb when
COMPILE_TEST=y)
Changes from v3[3]:
- Dropped the pm8x41 PMIC driver and pm8xxx-rtc changes as part of this
patchset.
(will be sent out separately)
- Rebased on v3.13-rc2
- Move to simple_ida_* for controller ID allocation
- Addressed documentation fixes and nits
- Provide pm_runtime implementation, which leverages SPMI's SLEEP and WAKEUP
commands
- Address spmi_controller object lifetime issues
Changes from v2[4]:
- Dropped RFC.
- Add basic regmap support at Mark Brown's suggestion
- Drop debugfs interface. Debugging SPMI accesses can happen via the regmap
debugfs interface if necessary.
- Add second address-cell in SPMI generic device tree binding, encoding the
address type (suggestion by Stephen Warren)
- Implement interrupt handling functionality within the PMIC Arbiter driver
- Provide basic MFD driver for the PMIC8x41 PMICs, demonstrating SPMI regmap
client use
- Adapt existing pm8xxx-rtc driver to work as a child of the PM8x41 mfd device
Changes from v1[5]:
- Adopted patch (1/5) to #define for_each_available_node() shim
in the !CONFIG_OF case
- Moved device tree logic out of drivers/of and into spmi.c core (this
mirrors what SPI is doing, and what i2c will soon be doing)
- Move of_spmi_add_devices() call into spmi_device_add(), so drivers don't
have to call it explicitly
- Unconditionally build in debugfs code (rely on the underlying
CONFIG_DEBUG_FS switch to throw unused code away)
- Change pr_* print functions to their dev_* equivalents
- Fix copy_{to,from}_user error handling
- Renamed "board_lock" to "ctrl_idr_lock" to better describe it's purpose
- Rework device object lifetime management
- Rename PMIC arb binding document, add description of PMIC arb
- Add generic SPMI device tree bindings
[1]: http://www.mipi.org/specifications/system-power-management-interface
[2]: http://lkml.kernel.org/r/cover.1389738151.git.jo...@codeaurora.org
[3]: http://lkml.kernel.org/r/cover.1382985169.git.jo...@codeaurora.org
[4]: http://lkml.kernel.org/r/cover.1377202730.git.jo...@codeaurora.org
[5]: http://lkml.kernel.org/r/cover.1376596224.git.jo...@codeaurora.org
Josh Cartwright (4):
spmi: add generic SPMI controller binding documentation
spmi: pmic_arb: add support for interrupt handling
spmi: document the PMIC arbiter SPMI bindings
regmap: spmi: support base and extended register spaces
Kenneth Heitke (2):
spmi: Linux driver framework for SPMI
spmi: Add MSM PMIC Arbiter SPMI controller
.../bindings/spmi/qcom,spmi-pmic-arb.txt | 60 ++
Documentation/devicetree/bindings/spmi/spmi.txt| 41 ++
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/base/regmap/regmap-spmi.c | 228 +-
drivers/spmi/Kconfig | 24 +
drivers/spmi/Makefile | 6 +
drivers/spmi/spmi-pmic-arb.c | 778 +
drivers/spmi/spmi.c| 609
include/dt-bindings/spmi/spmi.h| 18 +
include/linux/mod_devicetable.h| 8 +
include/linux/regmap.h | 12 +-
include/linux/spmi.h | 191 +
13 files changed, 1943 insertions(+), 35 deletions(-)
create mode 100644
Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
create mode 100644 Documentation/devicetree/bindings/spmi/spmi.txt
create mode 100644 drivers/spmi/Kconfig
create mode 100644 drivers/spmi/Makefile
create mode 100644 drivers/spmi/spmi-pmic-arb.c
create mode 100644 drivers/spmi/spmi.c
create mode 100644 include/dt-bindings/spmi/spmi.h
create mode 100644 include/linux/spmi.h
--
Qualcomm Innovation
Re: [BUGREPORT] Linux USB 3.0
Hi Sarah, On Mon, Jan 20, 2014 at 8:35 PM, Sarah Sharp wrote: > Hi Markus, > > I'm the xHCI driver maintainer, and it helps to Cc me on USB 3.0 bug > reports. > > On Sat, Dec 28, 2013 at 07:24:20AM +0100, Markus Rechberger wrote: >> just received following log snippset: > > Please state which kernel version you (or your customer) is running. > You've reported issues with several different kernel versions, so which > kernel are you running for this particular snippet? > >> Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR >> Transfer event TRB DMA ptr > > These messages might be harmless. The 3.0 kernel contains a fix for > Intel Panther Point xHCI hosts that suppresses those messages, commit > ad808333d8201d53075a11bc8dd83b81f3d68f0b "Intel xhci: Ignore spurious > successful event." > > A later commit extends that to all xHCI 1.0 hosts, commit > 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 "usb: host: xhci: Enable > XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0" That was > queued for 3.11 and marked to be backported into stable kernels as old > as 3.0. > >> the previous bug report of that user: >> https://bugzilla.kernel.org/show_bug.cgi?id=65021 xhci: complete USB freeze > > Hmm, Greg didn't assign that bug to me, so I missed it, sorry. > >> On Fri, Dec 27, 2013 at 8:59 PM, Markus Rechberger >> wrote: >> > Seems like DH87RL was working with 3.2.0-55-generic-pae unfortunately >> > we don't have such a board for testing and customer patience is >> > limited to bisect the kernel. >> > >> > Does anyone have a clue what modification could have killed USB 3.0 >> > support within those releases? >> > It does not seem to be SG support. > > 3.2 was the kernel where the Intel EHCI to xHCI port switchover code > went in. Without that code, all ports will remain under the EHCI host, > and USB 3.0 devices will work at USB 2.0 speeds. I suspect the USB > device triggers an issue with the xHCI driver, and 3.2 only works > because the device is on an EHCI port without the switchover code. > >> > On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger >> > wrote: >> >> I just got another USB 3.0 bugreport, the entire system crashed. That >> >> particular customer already filed a bugreport in November 2013 that >> >> his system is in a bad state when using some USB 2.0 media devices >> >> which even have opensource drivers built into the kernel. >> >> >> >> USB 3.0 support with Linux seems to be a disaster with Linux 3.6.12. >> >> The affected board is an Intel DH87RL board. > > Why are they running 3.6.12 in particular? That's not a supported > stable kernel. > our customers are using any kind of linux kernel. The drivers are using USBFS (devio.c) for interfacing with USB. It seems like you are in contact with one customer who is using the DH87RL board. Just today we got another one in our forum using 3.12.9-2-ARCH. Also Synology NAS users seem to be affected by the USB 2.0 through USB 3.0 issue. >> >> On Wed, Dec 25, 2013 at 8:18 AM, Markus Rechberger >> >> wrote: >> >>> A customer using a device with USBDEVFS is reporting following >> >>> backtrace (it seems to be a rather generic issue related to linux usb >> >>> 3.0 in general): >> >>> According to him this problem is reproducible as soon as he starts the >> >>> data transfer, is there anything known about that? >> >>> >> >>> He is using 3.12.0-031200-generic > > So at this point you've reported three separate bugs, all with the same > symptom, but different kernel versions? Are these all from the same bug > reporter, or a different bug reporter? > > You've got me seriously confused right now. Please keep one bug report > to one mail thread, and get the original bug reporter to start that > thread. If this is from one bug reporter, please state the current > kernel they are running, and send dmesg showing the issue with > CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on (you may > also need to turn on CONFIG_DYNAMIC_DEBUG in later kernels). Please > attach the dmesg as a file, since your mail client line-wraps. > >> >>> Dec 24 14:22:39 homenas kernel: [ 1469.818460] xhci_hcd :0f:00.0: >> >>> ERROR Transfer event TRB DMA ptr not part of current TD >> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >> >>> ERROR Transfer event TRB DMA ptr not part of current TD >> >>> Dec 24 14:30:39 homenas kernel: last message repeated 16 times >> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >> >>> WARN Successful completion on short TX >> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >> >>> WARN Successful completion on short TX >> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >> >>> URB transfer length is wrong, xHC issue? req. len = 46080, act. len = >> >>> 1382400 >> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] BUG: unable to handle >> >>> kernel NULL pointer dereference at 0004 >> >>>
Re: [PATCH v2] mm/zswap: add writethrough option
On Mon, 27 Jan 2014 09:01:19 -0500 Dan Streetman wrote: > Currently, zswap is writeback cache; stored pages are not sent > to swap disk, and when zswap wants to evict old pages it must > first write them back to swap cache/disk manually. This avoids > swap out disk I/O up front, but only moves that disk I/O to > the writeback case (for pages that are evicted), and adds the > overhead of having to uncompress the evicted pages and the > need for an additional free page (to store the uncompressed page). > > This optionally changes zswap to writethrough cache by enabling > frontswap_writethrough() before registering, so that any > successful page store will also be written to swap disk. The > default remains writeback. To enable writethrough, the param > zswap.writethrough=1 must be used at boot. > > Whether writeback or writethrough will provide better performance > depends on many factors including disk I/O speed/throughput, > CPU speed(s), system load, etc. In most cases it is likely > that writeback has better performance than writethrough before > zswap is full, but after zswap fills up writethrough has > better performance than writeback. > > The reason to add this option now is, first to allow any zswap > user to be able to test using writethrough to determine if they > get better performance than using writeback, and second to allow > future updates to zswap, such as the possibility of dynamically > switching between writeback and writethrough. > > ... > > Based on specjbb testing on my laptop, the results for both writeback > and writethrough are better than not using zswap at all, but writeback > does seem to be better than writethrough while zswap isn't full. Once > it fills up, performance for writethrough is essentially close to not > using zswap, while writeback seems to be worse than not using zswap. > However, I think more testing on a wider span of systems and conditions > is needed. Additionally, I'm not sure that specjbb is measuring true > performance under fully loaded cpu conditions, so additional cpu load > might need to be added or specjbb parameters modified (I took the > values from the 4 "warehouses" test run). > > In any case though, I think having writethrough as an option is still > useful. More changes could be made, such as changing from writeback > to writethrough based on the zswap % full. And the patch doesn't > change default behavior - writethrough must be specifically enabled. > > The %-ized numbers I got from specjbb on average, using the default > 20% max_pool_percent and varying the amount of heap used as shown: > > ram | no zswap | writeback | writethrough > 75 93.08 100 96.90 > 87 96.58 95.58 96.72 > 10092.29 89.73 86.75 > 11263.80 38.66 19.66 > 1254.79 29.90 15.75 > 1374.99 4.504.75 > 1504.28 4.625.01 > 1625.20 2.944.66 > 1755.71 2.114.84 Changelog is very useful, thanks for taking the time. It does sound like the feature is of marginal benefit. Is "zswap filled up" an interesting or useful case to optimize? otoh the addition is pretty simple and we can later withdraw the whole thing without breaking anyone's systems. What do people think? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel WARNING splat in 3.14-rc1
On 02/03/2014 02:39 PM, David Rientjes wrote:
Commit c65c1877bd68 ("slub: use lockdep_assert_held") incorrectly required
that add_full() and remove_full() hold n->list_lock. The lock is only
taken when kmem_cache_debug(s), since that's the only time it actually
does anything.
Require that the lock only be taken under such a condition.
Reported-by: Larry Finger
Signed-off-by: David Rientjes
You may add a "Tested-by: Larry Finger ". The patch
cleans up the splat on my system. Thanks for the quick response.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] arm64: Add architecture support for PCI
On Mon, Feb 3, 2014 at 2:05 PM, Arnd Bergmann wrote: > On Monday 03 February 2014 19:18:38 Liviu Dudau wrote: >> On Mon, Feb 03, 2014 at 06:58:56PM +, Arnd Bergmann wrote: >> > On Monday 03 February 2014 18:43:48 Liviu Dudau wrote: [snip] >> Agree. This is the RFC version. I didn't dare to post a patch with fixes >> for all architectures. :) > > No need to change the other architectures. You can make it opt-in for > now and just put the code into a common location. > > An interesting question however is what the transition plan is to > have the code shared between arm32 and arm64: We will certainly need > to share at least the dw-pcie and the generic SBSA compliant pci > implementation. You might want to re-read the SBSA. Unless ARM provides an IP block or there is some other standard such as EHCI or AHCI, there is no generic implementation. You only have to go look at the Linux EHCI or AHCI drivers and see how meaningless and inadequate "use EHCI" is. For PCI, the text is so brief in the SBSA there will be no way PCI is going to just work given all the variations of root complexes, bridges, address windows, etc. we typically see on ARM platforms. I could be wrong and some AML magic will solve all the problems. :) Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 0/2] Add Qualcomm BAM dmaengine driver
This patch set introduces the dmaengine driver for the Qualcomm Bus Access Manager (BAM) DMA controller present on MSM 8x74 devices. A number of the on-chip devices have their own BAM DMA controller and use it to move data between system memory and peripherals or between two peripherals. The initial version of this driver will only support slave DMA operations between system memory and peripherals. Changes from v3: - Remove unused bam_channel_dir. - Remove incorrect write to BAM_IRQ_SRCS_EE (read only). - Remove dma direction from DT binding and revise driver to use direction from prep_slave_sg. - Remove unnecessary channel reset from channel_init. This could affect channels controlled from other execution environments. - Change terminate_all to also take care of the current active descriptor. - Rework .remove function to correctly mask interrupts and clean up resources and tasklets. Changes from v2: - Corrected Kconfig dependencies - Moved execution environment ID to controller DT binding. The EE is a global setting across all of the channels on the controller. - Combined header into source file. - Corrected copyright date. - Moved channel hardware initialization to occur when channel is used for the first time. - Converted dma_alloc_coherent to dma_alloc_writecombine - Removed unecessary reset of channel from the dma terminate_all - Corrected usage of EE in irq handler and channel configuration functions. - Changed resource functions inside probe to use correct APIs. - Removed dma filter function and modified dma_xlate to use dma_get_slave_channel API - Fixed various nit comments Changes from v1: - Converted driver to use virt-dma - Reworked probe function per review comments - tx_status function now computes and returns residuals - Removed proprietary slave config. Removed associated include file. - Renamed files to reflect vendor name instead of specific device - Converted to use (readl|writel)_relaxed w/ appropriate barriers - Removed unions in favor of standard types. Andy Gross (2): dmaengine: add Qualcomm BAM dma driver dmaengine: qcom_bam_dma: Add device tree binding .../devicetree/bindings/dma/qcom_bam_dma.txt | 48 + drivers/dma/Kconfig|9 + drivers/dma/Makefile |1 + drivers/dma/qcom_bam_dma.c | 1059 4 files changed, 1117 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt create mode 100644 drivers/dma/qcom_bam_dma.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 1/2] dmaengine: add Qualcomm BAM dma driver
Add the DMA engine driver for the QCOM Bus Access Manager (BAM) DMA controller
found in the MSM 8x74 platforms.
Each BAM DMA device is associated with a specific on-chip peripheral. Each
channel provides a uni-directional data transfer engine that is capable of
transferring data between the peripheral and system memory (System mode), or
between two peripherals (BAM2BAM).
The initial release of this driver only supports slave transfers between
peripherals and system memory.
Signed-off-by: Andy Gross
---
drivers/dma/Kconfig|9 +
drivers/dma/Makefile |1 +
drivers/dma/qcom_bam_dma.c | 1059
3 files changed, 1069 insertions(+)
create mode 100644 drivers/dma/qcom_bam_dma.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index c10eb89..1b2f6cf 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -386,4 +386,13 @@ config DMATEST
config DMA_ENGINE_RAID
bool
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_MSM_DT || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
+
endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 0ce2da9..7ef950a 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -42,3 +42,4 @@ obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
obj-$(CONFIG_TI_CPPI41) += cppi41.o
obj-$(CONFIG_K3_DMA) += k3dma.o
+obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
new file mode 100644
index 000..a4ac0db
--- /dev/null
+++ b/drivers/dma/qcom_bam_dma.c
@@ -0,0 +1,1059 @@
+/*
+ * QCOM BAM DMA engine driver
+ *
+ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ * QCOM BAM DMA blocks are distributed amongst a number of the on-chip
+ * peripherals on the MSM 8x74. The configuration of the channels are
dependent
+ * on the way they are hard wired to that specific peripheral. The peripheral
+ * device tree entries specify the configuration of each channel.
+ *
+ * The DMA controller requires the use of external memory for storage of the
+ * hardware descriptors for each channel. The descriptor FIFO is accessed as a
+ * circular buffer and operations are managed according to the offset within
the
+ * FIFO. After pipe/channel reset, all of the pipe registers and internal
state
+ * are back to defaults.
+ *
+ * During DMA operations, we write descriptors to the FIFO, being careful to
+ * handle wrapping and then write the last FIFO offset to that channel's
+ * P_EVNT_REG register to kick off the transaction. The P_SW_OFSTS register
+ * indicates the current FIFO offset that is being processed, so there is some
+ * indication of where the hardware is currently working.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+struct bam_desc_hw {
+ u32 addr; /* Buffer physical address */
+ u16 size; /* Buffer size in bytes */
+ u16 flags;
+};
+
+#define DESC_FLAG_INT BIT(15)
+#define DESC_FLAG_EOT BIT(14)
+#define DESC_FLAG_EOB BIT(13)
+
+struct bam_async_desc {
+ struct virt_dma_desc vd;
+
+ u32 num_desc;
+ u32 xfer_len;
+ struct bam_desc_hw *curr_desc;
+
+ enum dma_transfer_direction dir;
+ size_t length;
+ struct bam_desc_hw desc[0];
+};
+
+#define BAM_CTRL 0x
+#define BAM_REVISION 0x0004
+#define BAM_SW_REVISION0x0080
+#define BAM_NUM_PIPES 0x003C
+#define BAM_TIMER 0x0040
+#define BAM_TIMER_CTRL 0x0044
+#define BAM_DESC_CNT_TRSHLD0x0008
+#define BAM_IRQ_SRCS 0x000C
+#define BAM_IRQ_SRCS_MSK 0x0010
+#define BAM_IRQ_SRCS_UNMASKED 0x0030
+#define BAM_IRQ_STTS 0x0014
+#define BAM_IRQ_CLR0x0018
+#define BAM_IRQ_EN 0x001C
+#define BAM_CNFG_BITS 0x007C
+#define BAM_IRQ_SRCS_EE(pipe) (0x0800 + ((pipe) * 0x80))
+#define BAM_IRQ_SRCS_MSK_EE(pipe)
[Patch v4 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Add device tree binding support for the QCOM BAM DMA driver.
Signed-off-by: Andy Gross
---
.../devicetree/bindings/dma/qcom_bam_dma.txt | 48
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
new file mode 100644
index 000..86344f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
@@ -0,0 +1,48 @@
+QCOM BAM DMA controller
+
+Required properties:
+- compatible: Must be "qcom,bam-v1.4.0" for MSM8974 V1
+ Must be "qcom,bam-v1.4.1" for MSM8974 V2
+- reg: Address range for DMA registers
+- interrupts: single interrupt for this controller
+- #dma-cells: must be <1>
+- clocks: required clock
+- clock-names: name of clock
+- qcom,ee : indicates the active Execution Environment identifier (0-7)
+
+Example:
+
+ uart-bam: dma@f9984000 = {
+ compatible = "qcom,bam-v1.4.1";
+ reg = <0xf9984000 0x15000>;
+ interrupts = <0 94 0>;
+ clocks = < GCC_BAM_DMA_AHB_CLK>;
+ clock-names = "bam_clk";
+ #dma-cells = <1>;
+ qcom,ee = <0>;
+ };
+
+Client:
+Required properties:
+- dmas: List of dma channel requests
+- dma-names: Names of aforementioned requested channels
+
+Clients must use the format described in the dma.txt file, using a two cell
+specifier for each channel.
+
+The three cells in order are:
+ 1. A phandle pointing to the DMA controller
+ 2. The channel number
+
+Example:
+ serial@f991e000 {
+ compatible = "qcom,msm-uart";
+ reg = <0xf991e000 0x1000>
+ <0xf9944000 0x19000>;
+ interrupts = <0 108 0>;
+ clocks = < GCC_BLSP1_UART2_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+
+ dmas = < 0>, < 1>;
+ dma-names = "rx", "tx";
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 2/6] fat: add fat_fallocate operation
2014-02-03, OGAWA Hirofumi :
>
> Sorry for long delay.
>
> Namjae Jeon writes:
>
>> +if (mode & FALLOC_FL_KEEP_SIZE) {
>> +/* First compute the number of clusters to be allocated */
>> +mm_bytes = offset + len - round_up(MSDOS_I(inode)->mmu_private,
>> +sbi->cluster_size);
>
Hi OGAWA.
> This should use ->i_disksize?
Right, I will fix it.
>
> [...]
>
>> +/* Release unwritten fallocated blocks on inode eviction. */
>> +if (MSDOS_I(inode)->mmu_private < MSDOS_I(inode)->i_disksize) {
>> +int err;
>> +fat_truncate_blocks(inode, MSDOS_I(inode)->mmu_private);
>> +/* Fallocate results in updating the i_start/iogstart
>> + * for the zero byte file. So, make it return to
>> + * original state during evict and commit it
>> + * synchrnously to avoid any corruption on the next
>> + * access to the cluster chain for the file.
>> + */
>> +err = fat_sync_inode(inode);
>
> Ah, good catch. We have to update i_size. I was forgetting about this.
> Well, sync inode unconditionally would not be good. Maybe, we better to
> use __fat_write_inode() with inode_needs_sync() or such.
Okay, I will change it.
Thanks.
> --
> OGAWA Hirofumi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] vmcore: prevent PT_NOTE p_memsz overflow during header update
On 02/03/2014 02:38 PM, Vivek Goyal wrote:
> On Mon, Feb 03, 2014 at 01:18:38PM -0700, Greg Pearson wrote:
>
> [..]
>> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
>> index 2ca7ba0..051c803 100644
>> --- a/fs/proc/vmcore.c
>> +++ b/fs/proc/vmcore.c
>> @@ -468,12 +468,14 @@ static int __init update_note_header_size_elf64(const
>> Elf64_Ehdr *ehdr_ptr)
>> return rc;
>> }
>> nhdr_ptr = notes_section;
>> -while (real_sz < max_sz) {
>> -if (nhdr_ptr->n_namesz == 0)
>> -break;
>> +while (nhdr_ptr->n_namesz != 0) {
>> sz = sizeof(Elf64_Nhdr) +
>> ((nhdr_ptr->n_namesz + 3) & ~3) +
>> ((nhdr_ptr->n_descsz + 3) & ~3);
>> +if ((real_sz + sz) > max_sz) {
>> +pr_warn("Warning: dropping PT_NOTE entry\n");
>> +break;
>> +}
> Hi Greg,
>
> Couple of minor nits.
>
> I think it is a good idea to give more data in warning which tells why
> are we dropping a note entry. May be something like.
>
> "Warning: Total note entry size exceeded PT_NOTE memsz. Dropping PT_NOTE
> entry, n_namesz=<> n_descsz=<>".
Sounds good I'll add more information to the pr_warn().
>
> Secondly, if there is only on note entry in a PT_NOTE header and we drop
> it, then that PT_NOTE header is empty and needs to be cleaned up.
>
> I think you will have to modify get_note_number_and_size_elf64() and
> other relevant functions which are not expecting ->p_memsz=0.
What about treating this as an error condition and adding a check to the
update_note_header_size_elf32()/update_note_header_size_elf64() routines
that would return a failure, something like the following at the end of
the routine:
if (real_sz == 0)
return -EINVAL
I could also add a pr_warn() with a message indicating no PT_NOTE
entries were found.
This seems like a lower risk change to handle the case I'm currently
seeing as opposed to changing the code to handle a p_memsz==0.
Thoughts?
--
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, 3 Feb 2014 14:47:15 -0800 Linus Torvalds wrote: > On Mon, Feb 3, 2014 at 2:00 PM, David Rientjes wrote: > > > > How do you define "huge bloat" if the size of vmlinux doesn't increase? > > Don't be silly. The size of all the object files increase *hugely*. yup, I disable this in my allmodconfig testing, to great effect. That being said, I do think the text should make clear that the bloat is a compile-time impact and not a runtime one. Something like --- a/lib/Kconfig.debug~lib-kconfigdebug-clarify-config_debug_infos-bloaty-nature-fix +++ a/lib/Kconfig.debug @@ -128,9 +128,9 @@ config DEBUG_INFO tools like crash, kgdb, LKCD, gdb, etc on the kernel. If you only want to have resolved symbols in kernel traces and - are not going to need support for those tools above, you don't need - to enable this as it is a huge bloat and build slowdown; - enable CONFIG_KALLSYMS instead. + are not going to need support for the above tools, you don't need + to enable this. It hugely bloat object files' on-disk sizes and slows + the build. Enable CONFIG_KALLSYMS instead. If unsure, say N. _ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Fix lockdep false positive in add_full()
Hello!
The add_full() function currently has a lockdep_assert_held() requiring
that the kmem_cache_node structure's ->list_lock be held. However,
this lock is not acquired by add_full()'s caller deactivate_slab()
in the full-node case unless debugging is enabled. Because full nodes
are accessed only by debugging code, this state of affairs results in
lockdep false-positive splats like the following:
[ 43.942868] WARNING: CPU: 0 PID: 698 at
/home/paulmck/public_git/linux-rcu/mm/slub.c:1007 deactivate_slab+0x509/0x720()
[ 43.943016] Modules linked in:
[ 43.943016] CPU: 0 PID: 698 Comm: torture_onoff Not tainted 3.14.0-rc1+ #1
[ 43.943016] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 43.943016] 03ef 88001e3f5ba8 818952ec
0046
[ 43.943016] 88001e3f5be8 81049517
ea784e00
[ 43.943016] ea7a9000 0002
[ 43.943016] Call Trace:
[ 43.943016] [] dump_stack+0x46/0x58
[ 43.943016] [] warn_slowpath_common+0x87/0xb0
[ 43.943016] [] warn_slowpath_null+0x15/0x20
[ 43.943016] [] deactivate_slab+0x509/0x720
[ 43.943016] [] ? slab_cpuup_callback+0x3b/0x100
[ 43.943016] [] ? slab_cpuup_callback+0xd2/0x100
[ 43.943016] [] slab_cpuup_callback+0xa4/0x100
[ 43.943016] [] notifier_call_chain+0x54/0x110
[ 43.943016] [] __raw_notifier_call_chain+0x9/0x10
[ 43.943016] [] __cpu_notify+0x1b/0x30
[ 43.943016] [] cpu_notify_nofail+0x10/0x20
[ 43.943016] [] _cpu_down+0x10d/0x2e0
[ 43.943016] [] cpu_down+0x30/0x50
[ 43.943016] [] torture_onoff+0xd3/0x3c0
[ 43.943016] [] ? torture_onoff_stats+0x90/0x90
[ 43.943016] [] kthread+0xdf/0x100
[ 43.943016] [] ? _raw_spin_unlock_irq+0x2b/0x40
[ 43.943016] [] ? flush_kthread_worker+0x130/0x130
[ 43.943016] [] ret_from_fork+0x7c/0xb0
[ 43.943016] [] ? flush_kthread_worker+0x130/0x130
This commit therefore does the lockdep check only if debuggging is
enabled, thus avoiding the false positives.
Signed-off-by: Paul E. McKenney
Cc: linux...@kvack.org
Cc: c...@linux-foundation.org
Cc: penb...@kernel.org
Cc: m...@selenic.com
diff --git a/mm/slub.c b/mm/slub.c
index 7e3e0458bce4..6fff4d980b7c 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1004,7 +1004,8 @@ static inline void slab_free_hook(struct kmem_cache *s,
void *x)
static void add_full(struct kmem_cache *s,
struct kmem_cache_node *n, struct page *page)
{
- lockdep_assert_held(>list_lock);
+ if (kmem_cache_debug(s))
+ lockdep_assert_held(>list_lock);
if (!(s->flags & SLAB_STORE_USER))
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ceph: fix posix ACL hooks
On Mon, Feb 3, 2014 at 2:40 PM, Al Viro wrote: > > Umm... Point, but that actually means that we get an extra pitfall for > filesystem writers here. foo_permission() passes dentry (now that it > has one) to foo_wank_a_lot(), with the latter using dentry->d_inode at > some point... I agree. The good news, though, is that in the RCU lookup case, we have that MAY_NOT_BLOCK thing, and most filesystems will have errored out for any complex operations. RCU lookup is special, and complicated, and sadly, the permissions checking is very much part of that. But for the really complex cases, at least we can punt. >> Look at gfs2_lookupi() in particular, and check how it is called. > > Yeowch... gfs2_ok_to_move() is particulary nasty... WTF do we need > it for and why is it not racy as hell? I don't know. And I suspect that for things like the journal index file lookup (which is actually worse - see gfs2_jindex_hold()) we don't really about the permissions, since this is just done at init_journal() time. So I think all of this is quite solvable for gfs2, it just wasn't the obvious kind of "we already have the dentry" case that every single other case I looked at was. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH char-misc-linus] misc: mic: fix possible signed underflow (undefined behavior) in userspace API
iovcnt is declared as a signed integer in both the userspace API and
as a local variable in mic_virtio.c. The while() loop in mic_virtio.c
iterates until the local variable iovcnt reaches the value 0. If
userspace passes e.g. INT_MIN as iovcnt field, this loop then appears
to depend on an undefined behavior (signed underflow) to complete.
The fix is to use unsigned integers in both the userspace API and
the local variable.
This issue was reported @ https://lkml.org/lkml/2014/1/10/10
Reported-by: Mathieu Desnoyers
Reviewed-by: Ashutosh Dixit
Signed-off-by: Sudeep Dutt
---
drivers/misc/mic/host/mic_virtio.c | 3 ++-
include/uapi/linux/mic_ioctl.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/mic/host/mic_virtio.c
b/drivers/misc/mic/host/mic_virtio.c
index 752ff87..7e1ef0e 100644
--- a/drivers/misc/mic/host/mic_virtio.c
+++ b/drivers/misc/mic/host/mic_virtio.c
@@ -156,7 +156,8 @@ static int mic_vringh_copy(struct mic_vdev *mvdev, struct
vringh_kiov *iov,
static int _mic_virtio_copy(struct mic_vdev *mvdev,
struct mic_copy_desc *copy)
{
- int ret = 0, iovcnt = copy->iovcnt;
+ int ret = 0;
+ u32 iovcnt = copy->iovcnt;
struct iovec iov;
struct iovec __user *u_iov = copy->iov;
void __user *ubuf = NULL;
diff --git a/include/uapi/linux/mic_ioctl.h b/include/uapi/linux/mic_ioctl.h
index 7fabba5..feb0b4c 100644
--- a/include/uapi/linux/mic_ioctl.h
+++ b/include/uapi/linux/mic_ioctl.h
@@ -39,7 +39,7 @@ struct mic_copy_desc {
#else
struct iovec *iov;
#endif
- int iovcnt;
+ __u32 iovcnt;
__u8 vr_idx;
__u8 update_used;
__u32 out_len;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, Feb 3, 2014 at 2:00 PM, David Rientjes wrote: > > How do you define "huge bloat" if the size of vmlinux doesn't increase? Don't be silly. The size of all the object files increase *hugely*. This is my fs/builtin.o in my normal config: -rw-rw-r--. 1 torvalds torvalds 2838613 Feb 3 14:32 fs/built-in.o and with the *reduced* debug info, ie .config diff as follows: +CONFIG_DEBUG_INFO=y +CONFIG_DEBUG_INFO_REDUCED=y I get this: -rw-rw-r--. 1 torvalds torvalds 11793317 Feb 3 14:33 fs/built-in.o iow, that "reduced" debug info is still more than 4x bigger than a non-debug-info kernel. David, if you don't think that debug-info bloats the build, you're in huge *huge* denial. CONFIG_DEBUG_INFO (even with the "reduced" thing) is ABSOLUTELY HORRIBLE CRAP. > Would some people consider that to be acceptable but now mysteriously > confused because we don't know what "huge bloat" you're referring to? That >4x size increase doesn't match your idea of "huge bloat"? The object files being much bigger really does screw you especially on laptops that often have less memory and less capable IO subsystems. The final links in particular tend to be much bigger and use much more memory. I suspect a lot of people are in denial about just how *horrible* the overhead of debug builds are. And yeah, if you have oodles of memory to cache things, it's not too bad. But you really want to have *lots* of memory, because otherwise you won't be caching all those object files in RAM, and your build easily becomes IO bound at link time. A factor of four size difference will not be helping your poor slow laptop disk.. 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,RFC] random: collect cpu randomness
On Mon, Feb 03, 2014 at 09:54:22PM +, Maciej W. Rozycki wrote: > > Can we be sure we don't leak information this way? Just being > paranoid... The register information will be mixed pretty thoroughly by the time it gets to the entropy pool, and then we don't ever expose the entropy pool to userspace. So no, I don't think we need to worry about leaking information. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel WARNING splat in 3.14-rc1
On Mon, 3 Feb 2014, David Rientjes wrote:
> Commit c65c1877bd68 ("slub: use lockdep_assert_held") incorrectly required
> that add_full() and remove_full() hold n->list_lock. The lock is only
> taken when kmem_cache_debug(s), since that's the only time it actually
> does anything.
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ceph: fix posix ACL hooks
On Mon, Feb 03, 2014 at 02:12:00PM -0800, Linus Torvalds wrote:
> >> -int afs_permission(struct inode *inode, int mask)
> >> +int afs_permission(struct dentry *dentry, struct inode *inode, int mask)
> >
> > Oh, _lovely_. So not only do we pass dentry, the arguments are redundant
> > as well.
>
> Note that *not* passing in inode would make the patch much bigger,
> because now every filesystem would have to add the
>
>struct inode *inode = dentry->d_inode;
>
> at the top.
>
> Also, I'm not actually convinced it is redundant at all. Remember the
> RCU lookup case? dentry->d_inode is not safe.
Umm... Point, but that actually means that we get an extra pitfall for
filesystem writers here. foo_permission() passes dentry (now that it
has one) to foo_wank_a_lot(), with the latter using dentry->d_inode at
some point...
> >> +static int gfs2_vfs_permission(struct dentry *dentry, struct inode
> >> *inode, int mask)
> >> +{
> >> + return gfs2_permission(inode, mask);
> >> +}
> >
> > Er... You do realize that callers of gfs2_permission() tend to have
> > the dentry in question, either directly or as ->d_parent of something
> > they have?
>
> Not true. Look closer.
>
> Look at gfs2_lookupi() in particular, and check how it is called.
Yeowch... gfs2_ok_to_move() is particulary nasty... WTF do we need
it for and why is it not racy as hell?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] arm64: Add architecture support for PCI
On 3 February 2014 18:43, Liviu Dudau wrote:
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 4cc813e..ce5bad2 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void
> __iomem *addr)
> /*
> * I/O port access primitives.
> */
> +#define arch_has_dev_port()(0)
> #define IO_SPACE_LIMIT 0x
> #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))
>
> +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> +#define ioport_unmap(addr)
I'm not sure that this will work. The in[bwl], out[bwl] macros in
arch/arm64/include/asm/io.h already add the PCI_IOBASE offset.
Instead of these two #defines, why not just enforce that
GENERIC_PCI_IOMAP is enabled? Or at least wrap these defines with 'if
(!config_enabled(CONFIG_GENERIC_PCI_IOMAP))' or similar.
> +
> static inline u8 inb(unsigned long addr)
> {
> return readb(addr + PCI_IOBASE);
Andrew Murray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/7] time: clockevents: Adjust timer interval when frequency changes
To adjust the timer's interval in periodic mode, the clockevent device
is put into periodic mode during clockevents_update_freq() in case the
timer is in periodic mode.
Cc: Thomas Gleixner
Signed-off-by: Soren Brinkmann
---
It is assumed that simply calling the timer's 'set_mode()' API takes care of
programming an appropriate interval based on the current timer frequency.
If that doesn't work for all timers, I guess it might require a new API
call.
---
kernel/time/clockevents.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 641d91003a45..f85e5fda9c66 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -443,10 +443,13 @@ int __clockevents_update_freq(struct clock_event_device
*dev, u32 freq)
{
clockevents_config(dev, freq);
- if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
- return 0;
+ if (dev->mode == CLOCK_EVT_MODE_ONESHOT)
+ return clockevents_program_event(dev, dev->next_event, false);
+
+ if (dev->mode == CLOCK_EVT_MODE_PERIODIC)
+ dev->set_mode(CLOCK_EVT_MODE_PERIODIC, dev);
- return clockevents_program_event(dev, dev->next_event, false);
+ return 0;
}
/**
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/7] ARM: zynq: cpufreq support
Hi, the merge window is over and ARM is also booting again. So, time to restart the discussion on this series. I rebased the series on 3.14-rc1 which removed some of the patches of the original submission due to them already having been merged. Other than that, I didn't do many changes compared to the patches that have been sent out in early December. Changelogs are included with the patches. Thanks, Sören Soren Brinkmann (7): time: Serialize calls to 'clockevents_update_freq' in the timing core time: clockevents: Adjust timer interval when frequency changes clocksource/cadence_ttc: Call clockevents_update_freq() with IRQs enabled clocksource/cadence_ttc: Overhaul clocksource frequency adjustment clocksource/cadence_ttc: Use only one counter arm: zynq: Don't use arm_global_timer with cpufreq arm: zynq: Add support for cpufreq arch/arm/boot/dts/zynq-7000.dtsi| 6 + arch/arm/mach-zynq/Kconfig | 4 +- arch/arm/mach-zynq/common.c | 3 + drivers/clocksource/cadence_ttc_timer.c | 213 ++-- kernel/time/clockevents.c | 32 +++-- kernel/time/tick-broadcast.c| 25 +++- kernel/time/tick-internal.h | 4 + 7 files changed, 177 insertions(+), 110 deletions(-) -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/7] time: Serialize calls to 'clockevents_update_freq' in the timing core
From: Thomas Gleixner
We can identify the broadcast device in the core and serialize all
callers including interrupts on a different CPU against the update.
Also, disabling interrupts is moved into the core allowing callers to
leave interrutps enabled when calling clockevents_update_freq().
Cc: Thomas Gleixner
Signed-off-by: Soren Brinkmann
---
kernel/time/clockevents.c| 29 ++---
kernel/time/tick-broadcast.c | 25 +++--
kernel/time/tick-internal.h | 4
3 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 086ad6043bcb..641d91003a45 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -439,6 +439,16 @@ void clockevents_config_and_register(struct
clock_event_device *dev,
}
EXPORT_SYMBOL_GPL(clockevents_config_and_register);
+int __clockevents_update_freq(struct clock_event_device *dev, u32 freq)
+{
+ clockevents_config(dev, freq);
+
+ if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
+ return 0;
+
+ return clockevents_program_event(dev, dev->next_event, false);
+}
+
/**
* clockevents_update_freq - Update frequency and reprogram a clock event
device.
* @dev: device to modify
@@ -446,17 +456,22 @@ EXPORT_SYMBOL_GPL(clockevents_config_and_register);
*
* Reconfigure and reprogram a clock event device in oneshot
* mode. Must be called on the cpu for which the device delivers per
- * cpu timer events with interrupts disabled! Returns 0 on success,
- * -ETIME when the event is in the past.
+ * cpu timer events. If called for the broadcast device the core takes
+ * care of serialization.
+ *
+ * Returns 0 on success, -ETIME when the event is in the past.
*/
int clockevents_update_freq(struct clock_event_device *dev, u32 freq)
{
- clockevents_config(dev, freq);
-
- if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
- return 0;
+ unsigned long flags;
+ int ret;
- return clockevents_program_event(dev, dev->next_event, false);
+ local_irq_save(flags);
+ ret = tick_broadcast_update_freq(dev, freq);
+ if (ret == -ENODEV)
+ ret = __clockevents_update_freq(dev, freq);
+ local_irq_restore(flags);
+ return ret;
}
/*
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 43780ab5e279..003e6c3663b1 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -120,6 +120,19 @@ int tick_is_broadcast_device(struct clock_event_device
*dev)
return (dev && tick_broadcast_device.evtdev == dev);
}
+int tick_broadcast_update_freq(struct clock_event_device *dev, u32 freq)
+{
+ int ret = -ENODEV;
+
+ if (tick_is_broadcast_device(dev)) {
+ raw_spin_lock(_broadcast_lock);
+ ret = __clockevents_update_freq(dev, freq);
+ raw_spin_unlock(_broadcast_lock);
+ }
+ return ret;
+}
+
+
static void err_broadcast(const struct cpumask *mask)
{
pr_crit_once("Failed to broadcast timer tick. Some CPUs may be
unresponsive.\n");
@@ -272,12 +285,8 @@ static void tick_do_broadcast(struct cpumask *mask)
*/
static void tick_do_periodic_broadcast(void)
{
- raw_spin_lock(_broadcast_lock);
-
cpumask_and(tmpmask, cpu_online_mask, tick_broadcast_mask);
tick_do_broadcast(tmpmask);
-
- raw_spin_unlock(_broadcast_lock);
}
/*
@@ -287,13 +296,15 @@ static void tick_handle_periodic_broadcast(struct
clock_event_device *dev)
{
ktime_t next;
+ raw_spin_lock(_broadcast_lock);
+
tick_do_periodic_broadcast();
/*
* The device is in periodic mode. No reprogramming necessary:
*/
if (dev->mode == CLOCK_EVT_MODE_PERIODIC)
- return;
+ goto unlock;
/*
* Setup the next period for devices, which do not have
@@ -306,9 +317,11 @@ static void tick_handle_periodic_broadcast(struct
clock_event_device *dev)
next = ktime_add(next, tick_period);
if (!clockevents_program_event(dev, next, false))
- return;
+ goto unlock;
tick_do_periodic_broadcast();
}
+unlock:
+ raw_spin_unlock(_broadcast_lock);
}
/*
diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index 8329669b51ec..26f1c0ba9d81 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -111,6 +111,7 @@ extern int tick_resume_broadcast(void);
extern void tick_broadcast_init(void);
extern void
tick_set_periodic_handler(struct clock_event_device *dev, int broadcast);
+int tick_broadcast_update_freq(struct clock_event_device *dev, u32 freq);
#else /* !BROADCAST */
@@ -133,6 +134,8 @@ static inline void tick_shutdown_broadcast(unsigned int
*cpup) { }
static inline void tick_suspend_broadcast(void) { }
static inline int
[PATCH v3 3/7] clocksource/cadence_ttc: Call clockevents_update_freq() with IRQs enabled
The timer core takes care of serialization and IRQs. Hence the driver is
no longer required to disable interrupts when calling
clockevents_update_freq().
Signed-off-by: Soren Brinkmann
---
drivers/clocksource/cadence_ttc_timer.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/clocksource/cadence_ttc_timer.c
b/drivers/clocksource/cadence_ttc_timer.c
index 63f176de0d02..f05b9fdc7425 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -321,25 +321,12 @@ static int ttc_rate_change_clockevent_cb(struct
notifier_block *nb,
switch (event) {
case POST_RATE_CHANGE:
- {
- unsigned long flags;
-
- /*
-* clockevents_update_freq should be called with IRQ disabled on
-* the CPU the timer provides events for. The timer we use is
-* common to both CPUs, not sure if we need to run on both
-* cores.
-*/
- local_irq_save(flags);
- clockevents_update_freq(>ce,
- ndata->new_rate / PRESCALE);
- local_irq_restore(flags);
-
/* update cached frequency */
ttc->freq = ndata->new_rate;
+ clockevents_update_freq(>ce, ndata->new_rate / PRESCALE);
+
/* fall through */
- }
case PRE_RATE_CHANGE:
case ABORT_RATE_CHANGE:
default:
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/7] clocksource/cadence_ttc: Overhaul clocksource frequency adjustment
The currently used method adjusting the clocksource to a changing input
frequency does not work on kernels from 3.11 on.
The new approach is to keep the timer frequency as constant as possible.
I.e.
- due to the TTC's prescaler limitations, allow frequency changes
only if the frequency scales by a power of 2
- adjust the counter's divider on the fly when a frequency change
occurs
This limits cpufreq to scale by certain factors only.
But we may keep the time base somewhat constant, so that sleep() & co
keep working as expected, while supporting cpufreq.
Signed-off-by: Soren Brinkmann
---
v3:
- Clock notifier data does not behave as documented. Adjust code
accordingly (https://lkml.org/lkml/2014/1/22/412)
v2:
- remove PM notifier and associated code
Signed-off-by: Soren Brinkmann
---
drivers/clocksource/cadence_ttc_timer.c | 104 ++--
1 file changed, 84 insertions(+), 20 deletions(-)
diff --git a/drivers/clocksource/cadence_ttc_timer.c
b/drivers/clocksource/cadence_ttc_timer.c
index f05b9fdc7425..49fbe2847c84 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -16,6 +16,7 @@
*/
#include
+#include
#include
#include
#include
@@ -52,6 +53,8 @@
#define TTC_CNT_CNTRL_DISABLE_MASK 0x1
#define TTC_CLK_CNTRL_CSRC_MASK(1 << 5)/* clock source
*/
+#define TTC_CLK_CNTRL_PSV_MASK 0x1e
+#define TTC_CLK_CNTRL_PSV_SHIFT1
/*
* Setup the timers to use pre-scaling, using a fixed value for now that will
@@ -63,6 +66,8 @@
#define CLK_CNTRL_PRESCALE_EN 1
#define CNT_CNTRL_RESET(1 << 4)
+#define MAX_F_ERR 50
+
/**
* struct ttc_timer - This definition defines local timer structure
*
@@ -82,6 +87,8 @@ struct ttc_timer {
container_of(x, struct ttc_timer, clk_rate_change_nb)
struct ttc_timer_clocksource {
+ u32 scale_clk_ctrl_reg_old;
+ u32 scale_clk_ctrl_reg_new;
struct ttc_timerttc;
struct clocksource cs;
};
@@ -229,32 +236,89 @@ static int ttc_rate_change_clocksource_cb(struct
notifier_block *nb,
struct ttc_timer_clocksource, ttc);
switch (event) {
- case POST_RATE_CHANGE:
+ case PRE_RATE_CHANGE:
+ {
+ u32 psv;
+ unsigned long factor, rate_low, rate_high;
+
+ if (ndata->new_rate > ndata->old_rate) {
+ factor = DIV_ROUND_CLOSEST(ndata->new_rate,
+ ndata->old_rate);
+ rate_low = ndata->old_rate;
+ rate_high = ndata->new_rate;
+ } else {
+ factor = DIV_ROUND_CLOSEST(ndata->old_rate,
+ ndata->new_rate);
+ rate_low = ndata->new_rate;
+ rate_high = ndata->old_rate;
+ }
+
+ if (!is_power_of_2(factor))
+ return NOTIFY_BAD;
+
+ if (abs(rate_high - (factor * rate_low)) > MAX_F_ERR)
+ return NOTIFY_BAD;
+
+ factor = __ilog2_u32(factor);
+
/*
-* Do whatever is necessary to maintain a proper time base
-*
-* I cannot find a way to adjust the currently used clocksource
-* to the new frequency. __clocksource_updatefreq_hz() sounds
-* good, but does not work. Not sure what's that missing.
-*
-* This approach works, but triggers two clocksource switches.
-* The first after unregister to clocksource jiffies. And
-* another one after the register to the newly registered timer.
-*
-* Alternatively we could 'waste' another HW timer to ping pong
-* between clock sources. That would also use one register and
-* one unregister call, but only trigger one clocksource switch
-* for the cost of another HW timer used by the OS.
+* store timer clock ctrl register so we can restore it in case
+* of an abort.
*/
- clocksource_unregister(>cs);
- clocksource_register_hz(>cs,
- ndata->new_rate / PRESCALE);
- /* fall through */
- case PRE_RATE_CHANGE:
+ ttccs->scale_clk_ctrl_reg_old =
+ __raw_readl(ttccs->ttc.base_addr +
+ TTC_CLK_CNTRL_OFFSET);
+
+ psv = (ttccs->scale_clk_ctrl_reg_old &
+ TTC_CLK_CNTRL_PSV_MASK) >>
+ TTC_CLK_CNTRL_PSV_SHIFT;
+ if (ndata->new_rate < ndata->old_rate)
+ psv -= factor;
+
[PATCH v3 6/7] arm: zynq: Don't use arm_global_timer with cpufreq
The timer frequency of the arm_global_timer depends on the CPU frequency. With cpufreq altering that frequency the arm_global_timer does not maintain a stable time base. Therefore don't enable that timer in case cpufreq is enabled. Cc: Russell King Signed-off-by: Soren Brinkmann --- arch/arm/mach-zynq/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig index 6b04260aa142..f84fab14f0b7 100644 --- a/arch/arm/mach-zynq/Kconfig +++ b/arch/arm/mach-zynq/Kconfig @@ -13,6 +13,6 @@ config ARCH_ZYNQ select HAVE_SMP select SPARSE_IRQ select CADENCE_TTC_TIMER - select ARM_GLOBAL_TIMER + select ARM_GLOBAL_TIMER if !CPU_FREQ help Support for Xilinx Zynq ARM Cortex A9 Platform -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 7/7] arm: zynq: Add support for cpufreq
The generic cpufreq-cpu0 driver can scale the CPU frequency on Zynq
SOCs. Add the required platform device to the BSP and appropriate
OPPs to the dts.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: devicet...@vger.kernel.org
Signed-off-by: Soren Brinkmann
---
v3:
- change lowest frequency to 23 (F_max / 3)
---
arch/arm/boot/dts/zynq-7000.dtsi | 6 ++
arch/arm/mach-zynq/Kconfig | 2 ++
arch/arm/mach-zynq/common.c | 3 +++
3 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 8b67b19392ec..789d0bacc110 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -24,6 +24,12 @@
device_type = "cpu";
reg = <0>;
clocks = < 3>;
+ operating-points = <
+ /* kHzuV */
+ 67 100
+ 34 100
+ 23 100
+ >;
};
cpu@1 {
diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
index f84fab14f0b7..f03e75bd0b2b 100644
--- a/arch/arm/mach-zynq/Kconfig
+++ b/arch/arm/mach-zynq/Kconfig
@@ -2,6 +2,8 @@ config ARCH_ZYNQ
bool "Xilinx Zynq ARM Cortex A9 Platform" if ARCH_MULTI_V7
select ARM_AMBA
select ARM_GIC
+ select ARCH_HAS_CPUFREQ
+ select ARCH_HAS_OPP
select COMMON_CLK
select CPU_V7
select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 1db2a5ca9ab8..644468151c04 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -51,6 +51,8 @@ static struct platform_device zynq_cpuidle_device = {
*/
static void __init zynq_init_machine(void)
{
+ struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
+
/*
* 64KB way size, 8-way associativity, parity disabled
*/
@@ -59,6 +61,7 @@ static void __init zynq_init_machine(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
platform_device_register(_cpuidle_device);
+ platform_device_register_full();
}
static void __init zynq_timer_init(void)
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/7] clocksource/cadence_ttc: Use only one counter
Currently the driver uses two of the three counters the TTC provides to
implement a clocksource and a clockevent device. By using the TTC's
match feature we can implement both use cases using a single counter
only.
The old approach is to use timer over-/underflow to generate an
interrupt. Using the match register allows to generate an interrupt on
arbitrary counter values. This way a dedicated clockevent counter can be
avoided.
Signed-off-by: Soren Brinkmann
---
drivers/clocksource/cadence_ttc_timer.c | 92 +++--
1 file changed, 31 insertions(+), 61 deletions(-)
diff --git a/drivers/clocksource/cadence_ttc_timer.c
b/drivers/clocksource/cadence_ttc_timer.c
index 49fbe2847c84..d922e982af95 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -47,6 +47,7 @@
#define TTC_CNT_CNTRL_OFFSET 0x0C /* Counter Control Reg, RW */
#define TTC_COUNT_VAL_OFFSET 0x18 /* Counter Value Reg, RO */
#define TTC_INTR_VAL_OFFSET0x24 /* Interval Count Reg, RW */
+#define TTC_MATCH1_OFFSET 0x30 /* Match reg, RW */
#define TTC_ISR_OFFSET 0x54 /* Interrupt Status Reg, RO */
#define TTC_IER_OFFSET 0x60 /* Interrupt Enable Reg, RW */
@@ -64,7 +65,10 @@
#define PRESCALE 2048/* The exponent must match this */
#define CLK_CNTRL_PRESCALE ((PRESCALE_EXPONENT - 1) << 1)
#define CLK_CNTRL_PRESCALE_EN 1
-#define CNT_CNTRL_RESET(1 << 4)
+#define CNT_CNTRL_RESETBIT(4)
+#define CNT_CNTRL_MATCHBIT(3)
+
+#define TTC_INTERRUPT_MATCH1 BIT(1)
#define MAX_F_ERR 50
@@ -99,6 +103,7 @@ struct ttc_timer_clocksource {
struct ttc_timer_clockevent {
struct ttc_timerttc;
struct clock_event_device ce;
+ unsigned long interval;
};
#define to_ttc_timer_clkevent(x) \
@@ -112,25 +117,20 @@ static void __iomem *ttc_sched_clock_val_reg;
* @timer: Pointer to the timer instance
* @cycles:Timer interval ticks
**/
-static void ttc_set_interval(struct ttc_timer *timer,
- unsigned long cycles)
+static void ttc_set_interval(struct ttc_timer *timer, unsigned long cycles)
{
- u32 ctrl_reg;
+ struct ttc_timer_clockevent *ttcce = container_of(timer,
+ struct ttc_timer_clockevent, ttc);
- /* Disable the counter, set the counter value and re-enable counter */
- ctrl_reg = __raw_readl(timer->base_addr + TTC_CNT_CNTRL_OFFSET);
- ctrl_reg |= TTC_CNT_CNTRL_DISABLE_MASK;
- __raw_writel(ctrl_reg, timer->base_addr + TTC_CNT_CNTRL_OFFSET);
+ /* set interval */
+ u32 reg = __raw_readl(timer->base_addr + TTC_COUNT_VAL_OFFSET);
+ reg += cycles;
+ __raw_writel(reg, timer->base_addr + TTC_MATCH1_OFFSET);
- __raw_writel(cycles, timer->base_addr + TTC_INTR_VAL_OFFSET);
+ /* enable match interrupt */
+ __raw_writel(TTC_INTERRUPT_MATCH1, timer->base_addr + TTC_IER_OFFSET);
- /*
-* Reset the counter (0x10) so that it starts from 0, one-shot
-* mode makes this needed for timing to be right.
-*/
- ctrl_reg |= CNT_CNTRL_RESET;
- ctrl_reg &= ~TTC_CNT_CNTRL_DISABLE_MASK;
- __raw_writel(ctrl_reg, timer->base_addr + TTC_CNT_CNTRL_OFFSET);
+ ttcce->interval = cycles;
}
/**
@@ -148,6 +148,8 @@ static irqreturn_t ttc_clock_event_interrupt(int irq, void
*dev_id)
/* Acknowledge the interrupt and call event handler */
__raw_readl(timer->base_addr + TTC_ISR_OFFSET);
+ if (ttce->ce.mode == CLOCK_EVT_MODE_PERIODIC)
+ ttc_set_interval(timer, ttce->interval);
ttce->ce.event_handler(>ce);
@@ -201,7 +203,6 @@ static void ttc_set_mode(enum clock_event_mode mode,
{
struct ttc_timer_clockevent *ttce = to_ttc_timer_clkevent(evt);
struct ttc_timer *timer = >ttc;
- u32 ctrl_reg;
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
@@ -211,18 +212,9 @@ static void ttc_set_mode(enum clock_event_mode mode,
case CLOCK_EVT_MODE_ONESHOT:
case CLOCK_EVT_MODE_UNUSED:
case CLOCK_EVT_MODE_SHUTDOWN:
- ctrl_reg = __raw_readl(timer->base_addr +
- TTC_CNT_CNTRL_OFFSET);
- ctrl_reg |= TTC_CNT_CNTRL_DISABLE_MASK;
- __raw_writel(ctrl_reg,
- timer->base_addr + TTC_CNT_CNTRL_OFFSET);
+ __raw_writel(0, timer->base_addr + TTC_IER_OFFSET);
break;
case CLOCK_EVT_MODE_RESUME:
- ctrl_reg = __raw_readl(timer->base_addr +
- TTC_CNT_CNTRL_OFFSET);
- ctrl_reg &= ~TTC_CNT_CNTRL_DISABLE_MASK;
- __raw_writel(ctrl_reg,
- timer->base_addr + TTC_CNT_CNTRL_OFFSET);
break;
}
Re: [PATCH v2] ceph: fix posix ACL hooks
On Mon, Feb 03, 2014 at 01:44:22PM -0800, Linus Torvalds wrote: > On Mon, Feb 3, 2014 at 1:39 PM, Al Viro wrote: > > > > If we really have hardlinks, the result of permission check would better > > be a function of inode itself - as in, "if it gives different results > > for two pathnames reachable for the same user, we have a bug". ^ > No. You're wrong. > > EVEN ON A UNIX FILESYSTEM THE PATH IS MEANINGFUL. > > Do this: create a hardlink in two different directories. Make the > *directory* permissions for one of the directories be something you > cannot traverse. Now try to check the permissions of the *same* inode > through those two paths. Notice how you get *different* results. > > Really. Yes. In one case we won't get to looking at the permissions of that thing at all. > Now, imagine that you are doing the same thing over a network. On the > server, there may be a single inode for the file, but when the client > gives the server a pathname, the two pathnames to that single inode > ARE NOT EQUIVALENT. Why do we pretend that those are links, in the first place? > And the fact is, filesystems with hardlinks and path-name-based > operations do exist. cifs with the unix extensions is one of them. Pox on Tridge... I really, really hate that change; I can buy "->getxattr() has inconvenient interface because of lousy protocol design", but spreading the same to ->permission(), with everything that will fall out of that... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Would devm_regulator_enable be useful ?
On Mon, Feb 03, 2014 at 06:21:52PM +, Mark Brown wrote: > On Sat, Feb 01, 2014 at 04:23:59PM -0800, Guenter Roeck wrote: > > As previously mentioned please fix your mailer to word wrap at a > sensible limit. > I thought I did ;-). I'll try to make sure I only send e-mail to you using mutt in the future ... but I notice that your line length is less than the one I configured, so maybe that is the problem here. > > Seems to me it would be useful to have it, but then devm_clk_enable() > > doesn't exist either, so I wonder if there is a reason for not having > > it. > > In both cases enabling and then leaving the resource enabled throughout > the runtime of the device isn't normally the best practice for using > them. You usually want to enable and disable at runtime with mechanisms > like runtime PM when the device is idle rather than burning power all > the time and once you start doing that managed resources don't fit so > well. Ok, I accept that. I thought that was what devm_xxx_[disable,remove] etc was for, though. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: Add support for creating a generic host_bridge from device tree
On Mon, Feb 03, 2014 at 07:31:31PM +, Arnd Bergmann wrote:
> On Monday 03 February 2014 19:06:49 Liviu Dudau wrote:
> > On Mon, Feb 03, 2014 at 06:46:10PM +, Arnd Bergmann wrote:
> > > On Monday 03 February 2014 18:33:48 Liviu Dudau wrote:
> > > > +/**
> > > > + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources
> > > > from DT
> > > > + * @dev: device node of the host bridge having the range property
> > > > + * @resources: list where the range of resources will be added after
> > > > DT parsing
> > > > + *
> > > > + * This function will parse the "ranges" property of a PCI host bridge
> > > > device
> > > > + * node and setup the resource mapping based on its content. It is
> > > > expected
> > > > + * that the property conforms with the Power ePAPR document.
> > > > + *
> > > > + * Each architecture will then apply their filtering based on the
> > > > limitations
> > > > + * of each platform. One general restriction seems to be the number of
> > > > IO space
> > > > + * ranges, the PCI framework makes intensive use of struct resource
> > > > management,
> > > > + * and for IORESOURCE_IO types they can only be requested if they are
> > > > contained
> > > > + * within the global ioport_resource, so that should be limited to one
> > > > IO space
> > > > + * range.
> > >
> > > Actually we have quite a different set of restrictions around I/O space
> > > on ARM32
> > > at the moment: Each host bridge can have its own 64KB range in an
> > > arbitrary
> > > location on MMIO space, and the total must not exceed 2MB of I/O space.
> >
> > And that is why the filtering is not (yet) imposed in the generic code. But
> > once
> > you use pci_request_region, that will call request_region which will check
> > against ioport_resource as parent for the requested resource. That should
> > fail
> > if is is not in the correct range, so I don't know how arm arch code manages
> > multiple IO ranges.
>
> Let's try to come up with nomenclature so we can talk about this better
>
> The ioport_resource is in "logical I/O space", which is a Linux fiction,
> it goes from 0 to IO_SPACE_LIMIT (2MB on ARM) and is mapped into "virtual
> I/O space", which start at (void __iomem *)PCI_IO_VIRT_BASE.
>
> Each PCI domain can have its own "bus I/O aperture", which is typically
> between 0x1000 and 0x and reflects the address that is used in PCI
> transactions and in BARs.
Actually, the bus I/O aperture can start from 0x if you are talking about
PCI bus addresses.
> The aperture here reflects the subset of the
> 4GB bus I/O space that is actually mapped into a CPU visible "physical
> I/O aperture" using an inbound mapping of the host bridge. The physical
> I/O aperture in turn gets mapped to the virtual I/O space using
> pci_ioremap_io.
Agree.
> The difference between a bus I/O address and a logical
> I/O address is stored in the io_offset.
Not exactly. If that would be true that means that for an I/O range that
start at bus I/O address zero but physical I/O apperture starts at
0x4000 the io_offset is zero. For me, the io_offset should be 0x4000.
Let me see if I can summarise this correctly, using only CPU addresses:
0x - IO_SPACE_LIMIT <- logical I/O address
0x - 0x+IO_SIZE <- physical address for PCI I/O space
0x - 0x+IO_SPACE_LIMIT <- virtual address for I/O
The io_offset then is 0x - logical I/O address. At least that is
the intent of the io_offset variable that I introduced in pci_host_bridge.
The bus I/O address is generated by the host bridge, I think we can ignore
it here as it tends to confuse the message.
>
> So much for basic definitions. When a device driver calls pci_request_region,
> the port number it sees is the bus I/O port number adjusted using the
> io_offset to turn it into a logical I/O port number, which should
> always be within the host bridge window, which in turn is a subset
> of the ioport_resource.
My understanding is that device drivers all user port numbers that are logical
I/O numbers, so no io_offset needs to be applied here. It is only when one
wants to access the port, that the translation happens. First, inb or outb
will add the PCI_IO_VIRT_BASE to generate the virtual address, the MMU will
then convert that address to physical address and the host bridge will
then translate the physical address into bus address.
>
> > > > +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
> > > > + struct list_head *resources)
> > > > +{
> > > > + struct resource *res;
> > > > + struct of_pci_range range;
> > > > + struct of_pci_range_parser parser;
> > > > + int err;
> > > > +
> > > > + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
> > > > +
> > > > + /* Check for ranges property */
> > > > + err = of_pci_range_parser_init(, dev);
> > > > + if (err)
> > > > + return err;
> > > > +
> > > > +
Re: [RFC PATCH V3 1/4] pci: APM X-Gene PCIe controller driver
On Mon, Feb 03, 2014 at 09:12:32PM +0100, Arnd Bergmann wrote: > Are you sure that is true for the root bridge as well? I don't > remember the details, but I though that for the host bridge, > we don't actually look at the BARs at all. That is right, but this isn't a host bridge device, it is a PCI-PCI bridge with root complex registers. The root complex bridge is not the same as the host bridge. Unfortunately the implementation is non-conforming. :( Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] ceph: fix posix ACL hooks
On Mon, Feb 3, 2014 at 1:59 PM, Al Viro wrote:
> On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
>
>> - err = vfs_mkdir(path.dentry->d_inode, dentry, mode);
>> + err = vfs_mkdir(path.dentry, dentry, mode);
>
> Pointless - path.dentry == dentry->d_parent anyway.
Heh. It's no less redundant than it used to be.
But if you want to clean up the vfs_xyzzy() ones further, I'm
perfectly fine with that.
>> - err = ll_vfs_rename(dir->d_inode, dchild_old, mnt,
>> - dir->d_inode, dchild_new, mnt, NULL);
>> + err = ll_vfs_rename(dir, dchild_old, mnt,
>> + dir, dchild_new, mnt, NULL);
>
>
> ... and again, that's completely pointless.
Minimal patch.. I really didn't want to check what the heck lustre
does with the insane ll_vfs thing.
>> -int afs_permission(struct inode *inode, int mask)
>> +int afs_permission(struct dentry *dentry, struct inode *inode, int mask)
>
> Oh, _lovely_. So not only do we pass dentry, the arguments are redundant
> as well.
Note that *not* passing in inode would make the patch much bigger,
because now every filesystem would have to add the
struct inode *inode = dentry->d_inode;
at the top.
Also, I'm not actually convinced it is redundant at all. Remember the
RCU lookup case? dentry->d_inode is not safe.
The RCU case actually does
inode_permission(nd->path.dentry, nd->inode, ..)
and here the difference between nd->inode and dentry->d_inode are
relevant, I think.
>> +static int gfs2_vfs_permission(struct dentry *dentry, struct inode *inode,
>> int mask)
>> +{
>> + return gfs2_permission(inode, mask);
>> +}
>
> Er... You do realize that callers of gfs2_permission() tend to have
> the dentry in question, either directly or as ->d_parent of something
> they have?
Not true. Look closer.
Look at gfs2_lookupi() in particular, and check how it is called.
I did hate that part of the patch, and I did mention the kinds of
problems this will cause if the next phase passes in dentry to
"generic_permission()".
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] audit: Only use the syscall slowpath when syscall audit rules exist
On Mon, Feb 3, 2014 at 12:23 PM, Steve Grubb wrote: > On Monday, February 03, 2014 09:53:23 AM Andy Lutomirski wrote: >> This toggles TIF_SYSCALL_AUDIT as needed when rules change instead of >> leaving it set whenever rules might be set in the future. This reduces >> syscall latency from >60ns to closer to 40ns on my laptop. > > Does this mean that we have processes that don't have the TIF_SYSCALL_AUDIT > flag set? When rules get loaded, how do we get the flag put back into all > processes? By looping over all processes and setting the flag, which is what my patch does. > > The theory of ops is supposed to be that for anyone not needing audit, there > is only the cost of "if (tif & TIF_SYSCALL_AUDIT)". On current kernels *all* processes have TIF_SYSCALL_AUDIT, even if they don't need auditing because there's nothing to audit. So everything pays the full cost. > That should be it. If you > have audit enabled or had it enabled (which means it might be loaded with new > rules), we want to inspect the syscall. > My point is that there's nothing to inspect -- there are no rules. Unless the audit code needs to do something just in case a non-syscall audit event gets written, in which case the audit code should IMO be fixed. (This is what Eric is talking about, I think.) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/7] memcg, slab: cleanup memcg cache name creation
On Mon, 3 Feb 2014 19:54:37 +0400 Vladimir Davydov
wrote:
> The way memcg_create_kmem_cache() creates the name for a memcg cache
> looks rather strange: it first formats the name in the static buffer
> tmp_name protected by a mutex, then passes the pointer to the buffer to
> kmem_cache_create_memcg(), which finally duplicates it to the cache
> name.
>
> Let's clean this up by moving memcg cache name creation to a separate
> function to be called by kmem_cache_create_memcg(), and estimating the
> length of the name string before copying anything to it so that we won't
> need a temporary buffer.
>
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3193,6 +3193,37 @@ int memcg_update_cache_size(struct kmem_cache *s, int
> num_groups)
> return 0;
> }
>
> +static int memcg_print_cache_name(char *buf, size_t size,
> + struct mem_cgroup *memcg, struct kmem_cache *root_cache)
> +{
> + int ret;
> +
> + rcu_read_lock();
> + ret = snprintf(buf, size, "%s(%d:%s)", root_cache->name,
> +memcg_cache_id(memcg), cgroup_name(memcg->css.cgroup));
> + rcu_read_unlock();
> + return ret;
> +}
> +
> +char *memcg_create_cache_name(struct mem_cgroup *memcg,
> + struct kmem_cache *root_cache)
> +{
> + int len;
> + char *name;
> +
> + /*
> + * We cannot use kasprintf() here, because cgroup_name() must be called
> + * under RCU protection.
> + */
> + len = memcg_print_cache_name(NULL, 0, memcg, root_cache);
> +
> + name = kmalloc(len + 1, GFP_KERNEL);
> + if (name)
> + memcg_print_cache_name(name, len + 1, memcg, root_cache);
but but but this assumes that cgroup_name(memcg->css.cgroup) did not
change between the two calls to memcg_print_cache_name(). If that is
the case then the locking was unneeded anyway.
> + return name;
> +}
> +
> int memcg_alloc_cache_params(struct mem_cgroup *memcg, struct kmem_cache *s,
>struct kmem_cache *root_cache)
> {
> @@ -3397,44 +3428,6 @@ void mem_cgroup_destroy_cache(struct kmem_cache
> *cachep)
> schedule_work(>memcg_params->destroy);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/3] epoll: read(),write(),ioctl() interface
On Mon, Feb 3, 2014 at 1:51 PM, Eric Wong wrote: > Andy Lutomirski wrote: >> >> On 02/02/2014 06:17 PM, Nathaniel Yazdani wrote: >> > So are you saying that those features you mentioned are specifically sought >> > after for the kernel? If so I'd like to take a crack at some of them, >> > may as well >> > get some use out of my new knowledge of epoll internals :) >> >> If by "sought after", you mean "is there at least one epoll user who >> wants them", then yes :) >> >> I think that EPOLLET and EPOLLONESHOT are giant hacks, and that what >> everyone really wants is the ability to very efficiently toggle events >> on and off. The ability to do it simultaneously and inexpensively >> with epoll_wait would make it happen. > > Everybody using single-threaded epoll, you mean? I suppose there's > quite a few of those. > > I've pondered an epoll_xchg syscall which would behave like *BSD kevent > to satisfy single-threaded users, but never got around to it. All my > epoll uses are multithreaded w/ oneshot nowadays, so xchg would only > save one syscall per thread. Even for multithreaded, the ability to rearm EPOLLONESHOT entries without extra syscalls would probably be useful. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 7/8] Add 32 bit VDSO time support for 32 bit kernel
On Mon, Feb 3, 2014 at 2:01 PM, Stefani Seibold wrote:
> Am Montag, den 03.02.2014, 08:36 -0800 schrieb Andy Lutomirski:
>> On Sun, Feb 2, 2014 at 11:44 PM, Stefani Seibold wrote:
>> > Am Sonntag, den 02.02.2014, 16:12 -0800 schrieb Andy Lutomirski:
>> >> On Sun, Feb 2, 2014 at 1:39 PM, Stefani Seibold
>> >> wrote:
>> >> > Am Sonntag, den 02.02.2014, 08:46 -0800 schrieb Andy Lutomirski:
>> >> >> On Sun, Feb 2, 2014 at 3:27 AM, wrote:
>> >> >> > From: Stefani Seibold
>> >> >> >
>> >> >> > This patch add the time support for 32 bit a VDSO to a 32 bit kernel.
>> >> >>
>> >> >> [...]
>> >> >>
>> >> >> Can you address the review comments from last time around? For
>> >> >> example, this still seems to have redundant vvar and hpet mappings, it
>> >> >> doesn't use the VVAR macro, it moves the 32-bit compat vDSO, etc.
>> >> >>
>> >> >
>> >> > I will address the compat VDSO issue.
>> >> >
>> >> > But the VVAR macro will be not a part of this patch set. If you depend
>> >> > on this, feel free to create one. From my point of view this is not
>> >> > feasible without a macro hacking, because the address accessing the vvar
>> >> > area differs in kernel and VDSO user mode.
>> >>
>> >> Sorry, but "I will make the code messier for no apparent reason and I
>> >> will not offer to fix it in the same series" gets my NAK.
>> >>
>> >> Hint: I'm talking about two or three lines of code in vvar.h.
>> >>
>> >
>> > A hint back: if you threat me with a NAK for a requested code sequence
>> > which currently no user, this is far away from professional. I am not
>> > your trainee.
>> >
>> > BTW: If it is so easy, send me the two or three lines and i will merge
>> > it ;-)
>>
>> Something to the effect of:
>>
>> #elif defined(BUILD_VDSO32)
>> #define VVAR(name) (*vvar_ ## name)
>> #endif
>>
>> Should do the trick.
>
> You are wrong...
>
> #ifdef BUILD_VDSO32
>
> #define DECLARE_VVAR(offset, type, name) \
> extern type vvar_ ## name __attribute__((visibility("hidden")));
>
> #define VVAR(name) (vvar_ ## name)
>
> #else
>
> /* Base address of vvars. This is not ABI. */
> #ifdef CONFIG_X86_64
> #define VVAR_ADDRESS (-10*1024*1024 - 4096)
> #else
> extern char __vvar_page;
>
> #define VVAR_ADDRESS (&__vvar_page)
> #endif
>
> This would do the trick!
>
> But for 64 bit to 32 bit conversation layer in vclock_gettime.c there is
> still a
>
> struct arch_vsyscall_gtod_data arch_vvar_vsyscall_gtod_data
> __attribute__((visibility("hidden")));
> #define gtod (_vvar_vsyscall_gtod_data)
>
> needed, because vvar_vsyscall_gtod_data is the 32 bit version, which
> would result in incorrect access of the struct members. So my code can't
> use this VVAR macro.
For 32-on-64, I must have read your code wrong. Are you sticking two
copies of the same struct with different layout into the vvar page?
If so, wouldn't it be better to only have the variant with a common
layout and use it for all versions of the vdso?
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH,RFC] random: collect cpu randomness
On Mon, 3 Feb 2014, Theodore Ts'o wrote: > > How about taking the saved registers from the interrupted CPU, xor'ing > > them all and calling the result random_get_entropy() on systems > > lacking a good cycles-counter? > > So we could take the struct pt_regs which we get from get_irq_regs(), > XOR them together and use them to feed into input[2] amd input[3] in > add_interrupt_randomness(). Or some other way of distributing the > values of all of the irq registers into the __u32 input[4] array. Can we be sure we don't leak information this way? Just being paranoid... Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/3] epoll: read(),write(),ioctl() interface
Andy Lutomirski wrote: > >> On 02/02/2014 06:17 PM, Nathaniel Yazdani wrote: > > So are you saying that those features you mentioned are specifically sought > > after for the kernel? If so I'd like to take a crack at some of them, > > may as well > > get some use out of my new knowledge of epoll internals :) > > If by "sought after", you mean "is there at least one epoll user who > wants them", then yes :) > > I think that EPOLLET and EPOLLONESHOT are giant hacks, and that what > everyone really wants is the ability to very efficiently toggle events > on and off. The ability to do it simultaneously and inexpensively > with epoll_wait would make it happen. Everybody using single-threaded epoll, you mean? I suppose there's quite a few of those. I've pondered an epoll_xchg syscall which would behave like *BSD kevent to satisfy single-threaded users, but never got around to it. All my epoll uses are multithreaded w/ oneshot nowadays, so xchg would only save one syscall per thread. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 7/8] Add 32 bit VDSO time support for 32 bit kernel
Am Montag, den 03.02.2014, 08:36 -0800 schrieb Andy Lutomirski:
> On Sun, Feb 2, 2014 at 11:44 PM, Stefani Seibold wrote:
> > Am Sonntag, den 02.02.2014, 16:12 -0800 schrieb Andy Lutomirski:
> >> On Sun, Feb 2, 2014 at 1:39 PM, Stefani Seibold
> >> wrote:
> >> > Am Sonntag, den 02.02.2014, 08:46 -0800 schrieb Andy Lutomirski:
> >> >> On Sun, Feb 2, 2014 at 3:27 AM, wrote:
> >> >> > From: Stefani Seibold
> >> >> >
> >> >> > This patch add the time support for 32 bit a VDSO to a 32 bit kernel.
> >> >>
> >> >> [...]
> >> >>
> >> >> Can you address the review comments from last time around? For
> >> >> example, this still seems to have redundant vvar and hpet mappings, it
> >> >> doesn't use the VVAR macro, it moves the 32-bit compat vDSO, etc.
> >> >>
> >> >
> >> > I will address the compat VDSO issue.
> >> >
> >> > But the VVAR macro will be not a part of this patch set. If you depend
> >> > on this, feel free to create one. From my point of view this is not
> >> > feasible without a macro hacking, because the address accessing the vvar
> >> > area differs in kernel and VDSO user mode.
> >>
> >> Sorry, but "I will make the code messier for no apparent reason and I
> >> will not offer to fix it in the same series" gets my NAK.
> >>
> >> Hint: I'm talking about two or three lines of code in vvar.h.
> >>
> >
> > A hint back: if you threat me with a NAK for a requested code sequence
> > which currently no user, this is far away from professional. I am not
> > your trainee.
> >
> > BTW: If it is so easy, send me the two or three lines and i will merge
> > it ;-)
>
> Something to the effect of:
>
> #elif defined(BUILD_VDSO32)
> #define VVAR(name) (*vvar_ ## name)
> #endif
>
> Should do the trick.
You are wrong...
#ifdef BUILD_VDSO32
#define DECLARE_VVAR(offset, type, name) \
extern type vvar_ ## name __attribute__((visibility("hidden")));
#define VVAR(name) (vvar_ ## name)
#else
/* Base address of vvars. This is not ABI. */
#ifdef CONFIG_X86_64
#define VVAR_ADDRESS (-10*1024*1024 - 4096)
#else
extern char __vvar_page;
#define VVAR_ADDRESS (&__vvar_page)
#endif
This would do the trick!
But for 64 bit to 32 bit conversation layer in vclock_gettime.c there is
still a
struct arch_vsyscall_gtod_data arch_vvar_vsyscall_gtod_data
__attribute__((visibility("hidden")));
#define gtod (_vvar_vsyscall_gtod_data)
needed, because vvar_vsyscall_gtod_data is the 32 bit version, which
would result in incorrect access of the struct members. So my code can't
use this VVAR macro.
>
> >
> >> >
> >> > I also see no redundant mapping. There are two modes, one is the map of
> >> > the kernel area the other maps the VDSO into the user space area. This
> >> > is exactly the behaviour of the origin VDSO implementation.
> >>
> >> No.
> >>
> >> In your series there are *three* mappings. There are:
> >>
> >> - The linear mapping that the kernel loader sets up (the writable
> >> mapping used in the kernel). This is implicit and, of course, fine.
> >> - There's the fixmap page, which aliases the normal kernel mapping at
> >> a fixed address with the user, ro, and nx attributes. The 64-bit vDSO
> >> uses that mapping. See vdso.h -- it's all arranged pretty clearly.
> >> Your code, for no discernible reason, sets up a fixmap entry on
> >> *32-bit* kernels.
> >> - The vma that you're setting up adjacent to the actual vdso text.
> >> This is what you are using.
> >>
> >> Please choose *one* user-readable mapping for the 32-bit vdso and
> >> stick with it. If the 64-bit vdso can use it to and userspace doesn't
> >> break, even better. But a pointless set of extra fixmap entries is
> >> not okay.
> >>
> >
> > Again: I wrote that there are two modes for a 32 bit kernel and
> > therefore there are two mappings at the same time. Since there are both
> > ways available in a 32 bit kernel via the vdso32= kernel parameter, both
> > must be supported.
> >
> > Due the lack of a real fixmap for a 32 bit kernel (FIXADDR_TOP is a
> > variable), the HPET and VVAR Page can only relative addressed. So this
> > pages must located before or after the VDSO.
> >
> > This is why i need to setup this pages into the fixmap area, this is the
> > compat mode "vdso32=2".
> >
> > For "vdso32=1" i need to map the VDSO Page together with the HPET and
> > VVAR into the user space.
> >
> > For compability reasons both mappings are required.
>
> Not at the same time, and I don't think you've guarded the
> map_vsyscall call with a check for compat mode.
>
I see no benefit to check the compat mode in map_vsyscall. The best way
is always map the VVAR page, because it is less error prone. In your
case tt would be also necessary not map the HPET page in non compat mode
too. So why bloat the code?
- Stefani
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature
On Mon, 3 Feb 2014, Borislav Petkov wrote: > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index dbf94a7d25a8..9095c2078095 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -126,7 +126,11 @@ config DEBUG_INFO > This adds debug symbols to the kernel and modules (gcc -g), and > is needed if you intend to use kernel crashdump or binary object > tools like crash, kgdb, LKCD, gdb, etc on the kernel. > - Say Y here only if you plan to debug the kernel. > + > + If you only want to have resolved symbols in kernel traces and > + are not going to need support for those tools above, you don't need > + to enable this as it is a huge bloat and build slowdown; How do you define "huge bloat" if the size of vmlinux doesn't increase? Would some people consider that to be acceptable but now mysteriously confused because we don't know what "huge bloat" you're referring to? It also begs the question about the meaning of DEBUG_INFO_REDUCED and this comment doesn't even allow us to see that it's an option. So this doesn't look good. > + enable CONFIG_KALLSYMS instead. > > If unsure, say N. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] ceph: fix posix ACL hooks
On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
> - err = vfs_mkdir(path.dentry->d_inode, dentry, mode);
> + err = vfs_mkdir(path.dentry, dentry, mode);
Pointless - path.dentry == dentry->d_parent anyway.
> - err = vfs_mknod(path.dentry->d_inode, dentry, mode, dev->devt);
> + err = vfs_mknod(path.dentry, dentry, mode, dev->devt);
Ditto.
> @@ -237,7 +237,7 @@ static int dev_rmdir(const char *name)
> return PTR_ERR(dentry);
> if (dentry->d_inode) {
> if (dentry->d_inode->i_private == )
> - err = vfs_rmdir(parent.dentry->d_inode, dentry);
> + err = vfs_rmdir(parent.dentry, dentry);
Ditto, with s/path/parent/
> @@ -324,7 +324,7 @@ static int handle_remove(const char *nodename, struct
> device *dev)
> mutex_lock(>d_inode->i_mutex);
> notify_change(dentry, , NULL);
> mutex_unlock(>d_inode->i_mutex);
> - err = vfs_unlink(parent.dentry->d_inode, dentry, NULL);
> + err = vfs_unlink(parent.dentry, dentry, NULL);
> if (!err || err == -ENOENT)
> deleted = 1;
> }
And here as well.
> +++ b/drivers/staging/lustre/lustre/lvfs/lvfs_linux.c
> @@ -222,8 +222,8 @@ int lustre_rename(struct dentry *dir, struct vfsmount
> *mnt,
> if (IS_ERR(dchild_new))
> GOTO(put_old, err = PTR_ERR(dchild_new));
>
> - err = ll_vfs_rename(dir->d_inode, dchild_old, mnt,
> - dir->d_inode, dchild_new, mnt, NULL);
> + err = ll_vfs_rename(dir, dchild_old, mnt,
> + dir, dchild_new, mnt, NULL);
... and again, that's completely pointless.
> -int afs_permission(struct inode *inode, int mask)
> +int afs_permission(struct dentry *dentry, struct inode *inode, int mask)
Oh, _lovely_. So not only do we pass dentry, the arguments are redundant
as well.
> -static inline int btrfs_may_create(struct inode *dir, struct dentry *child)
> +static inline int btrfs_may_create(struct dentry *parent, struct dentry
> *child)
I'm fairly sure that it's also pointless, because parent is going to be, well,
the parent. Of child.
> +static int gfs2_vfs_permission(struct dentry *dentry, struct inode *inode,
> int mask)
> +{
> + return gfs2_permission(inode, mask);
> +}
Er... You do realize that callers of gfs2_permission() tend to have
the dentry in question, either directly or as ->d_parent of something
they have?
I really hate the whole thing... ;-/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2 5/5] mutex: Give spinners a chance to spin_on_owner if need_resched() triggered while queued
On Mon, 2014-02-03 at 22:06 +0100, Peter Zijlstra wrote: > On Mon, Feb 03, 2014 at 12:55:34PM -0800, Jason Low wrote: > > On Mon, 2014-02-03 at 20:25 +0100, Peter Zijlstra wrote: > > > XXX: anybody got a better name than m_spinlock? > > > > So I was thinking something along the lines of > > mcs_spin_lock_cancelable() as that's essentially what this function > > does. > > sure, but what do we call the data structure that goes with it? Can't > have two struct mcs_spinlock :/ If this structure is only going to be used for cancelable mcs locking, what do you think of "struct cancelable_mcs_spinlock"? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] spi: rspi: fix build error when CONFIG_OF is not set
On Mon, Feb 3, 2014 at 2:47 AM, Geert Uytterhoeven wrote:
> Hi Shimoda-san,
>
> On Mon, 3 Feb 2014, Shimoda, Yoshihiro wrote:
>> This patch fixes an issue that the following build error happens when
>> the CONFIG_OF is not set:
>>
>> drivers/spi/spi-rspi.c: In function 'rspi_probe':
>> drivers/spi/spi-rspi.c:1203:26: error: 'rspi_of_match' undeclared (first use
>> in this function)
>>
>> Signed-off-by: Yoshihiro Shimoda
>> ---
>> This patch is based on the latest origin/topic/rspi branch in the spi.git.
>>
>> drivers/spi/spi-rspi.c |1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c
>> index 34ad4bc..e5cfc3d 100644
>> --- a/drivers/spi/spi-rspi.c
>> +++ b/drivers/spi/spi-rspi.c
>> @@ -1164,6 +1164,7 @@ static int rspi_parse_dt(struct device *dev, struct
>> spi_master *master)
>> return 0;
>> }
>> #else
>> +#define rspi_of_matchNULL
>> static inline int rspi_parse_dt(struct device *dev, struct spi_master
>> *master)
>> {
>> return -EINVAL;
>> --
>> 1.7.1
>
> Thanks, obviously I missed that of_match_device() still uses the ID table
> parameter if CONFIG_OF=n :-(
>
> Below I have two alternative solutions:
> 1. Uses rspi_of_match() to nullify the ID table pointer, like is done in
> the platform_driver structure,
> 2. Fixes it at the OF subsystem level, by nullifying the ID table pointer
> inside of_match_device().
>
> If 2 is accepted, drivers don't have to care about this anymore.
>
> What do you think?
I'll apply the 2nd one.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ceph: fix posix ACL hooks
On Mon, Feb 3, 2014 at 1:39 PM, Al Viro wrote: > > If we really have hardlinks, the result of permission check would better > be a function of inode itself - as in, "if it gives different results > for two pathnames reachable for the same user, we have a bug". No. You're wrong. EVEN ON A UNIX FILESYSTEM THE PATH IS MEANINGFUL. Do this: create a hardlink in two different directories. Make the *directory* permissions for one of the directories be something you cannot traverse. Now try to check the permissions of the *same* inode through those two paths. Notice how you get *different* results. Really. Now, imagine that you are doing the same thing over a network. On the server, there may be a single inode for the file, but when the client gives the server a pathname, the two pathnames to that single inode ARE NOT EQUIVALENT. And the fact is, filesystems with hardlinks and path-name-based operations do exist. cifs with the unix extensions is one of them. Al, face it, you're wrong this time. 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 v2] ceph: fix posix ACL hooks
On Mon, Feb 03, 2014 at 01:37:03PM -0800, Linus Torvalds wrote: > On Mon, Feb 3, 2014 at 1:31 PM, Al Viro wrote: > > > > Yes, and...? CIFS also doesn't have hardlinks, so _there_ d_find_alias() > > is just fine. > > Hmm? I'm pretty sure cifs can actually have hardlinks. *UGH* How the hell does it... Oh, right - samba on Unix server. I really wonder how well do Windows clients deal with those... Crap... I reall hate that prototype change ;-/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ceph: fix posix ACL hooks
On Mon, Feb 03, 2014 at 09:39:26PM +, Al Viro wrote: > Which fs are you talking about? For 9P it *is* a function of inode alone. > For CIFS there's no wrong dentry to pick - it doesn't have links to start > with. Except that apparently it does ;-/ Bugger... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v6 8/8] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
Add a sample DTS which will allow bootup of a board populated
with the BCM7445 chip.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
arch/arm/boot/dts/bcm7445.dts | 111 +
1 files changed, 111 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm7445.dts
diff --git a/arch/arm/boot/dts/bcm7445.dts b/arch/arm/boot/dts/bcm7445.dts
new file mode 100644
index 000..ffa3305
--- /dev/null
+++ b/arch/arm/boot/dts/bcm7445.dts
@@ -0,0 +1,111 @@
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "Broadcom STB (bcm7445)";
+ compatible = "brcm,bcm7445", "brcm,brcmstb";
+ interrupt-parent = <>;
+
+ chosen {};
+
+ memory {
+ device_type = "memory";
+ reg = <0x00 0x 0x00 0x4000>,
+ <0x00 0x4000 0x00 0x4000>,
+ <0x00 0x8000 0x00 0x4000>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "brcm,brahma-b15";
+ device_type = "cpu";
+ reg = <0>;
+ };
+
+ cpu@1 {
+ compatible = "brcm,brahma-b15";
+ device_type = "cpu";
+ reg = <1>;
+ };
+
+ cpu@2 {
+ compatible = "brcm,brahma-b15";
+ device_type = "cpu";
+ reg = <2>;
+ };
+
+ cpu@3 {
+ compatible = "brcm,brahma-b15";
+ device_type = "cpu";
+ reg = <3>;
+ };
+ };
+
+ gic: interrupt-controller@ffd0 {
+ compatible = "brcm,brahma-b15-gic", "arm,cortex-a15-gic";
+ reg = <0x00 0xffd01000 0x00 0x1000>,
+ <0x00 0xffd02000 0x00 0x2000>,
+ <0x00 0xffd04000 0x00 0x2000>,
+ <0x00 0xffd06000 0x00 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <1 13 0xf08>,
+<1 14 0xf08>,
+<1 11 0xf08>,
+<1 10 0xf08>;
+ };
+
+ rdb {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x00 0xf000 0x100>;
+
+ serial@406b00 {
+ compatible = "ns16550a";
+ reg = <0x406b00 0x20>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <0 75 0x4>;
+ clock-frequency = <0x4d3f640>;
+ };
+
+ sun_top_ctrl: syscon@404000 {
+ compatible = "brcm,bcm7445-sun-top-ctrl",
+"syscon";
+ reg = <0x404000 0x51c>;
+ };
+
+ hif_cpubiuctrl: syscon@3e2400 {
+ compatible = "brcm,bcm7445-hif-cpubiuctrl",
+"syscon";
+ reg = <0x3e2400 0x5b4>;
+ };
+
+ hif_continuation: syscon@452000 {
+ compatible = "brcm,bcm7445-hif-continuation",
+"syscon";
+ reg = <0x452000 0x100>;
+ };
+ };
+
+ smpboot {
+ compatible = "brcm,brcmstb-smpboot";
+ syscon-cpu = <_cpubiuctrl 0x88 0x178>;
+ syscon-cont = <_continuation>;
+ };
+
+ reboot {
+ compatible = "brcm,brcmstb-reboot";
+ syscon = <_top_ctrl 0x304 0x308>;
+ };
+};
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] (xen) stable/for-3.14-rc1-tag
Hey Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git stable/for-linus-3.14-rc1-tag which has a revert of a fix that caused build regression on ARM (with Xen enabled), and a tiny litte fix for Xen PVH where we did not set the CR4 flags properly. Please pull! arch/x86/include/asm/xen/page.h | 5 +-- arch/x86/xen/enlighten.c| 12 + arch/x86/xen/p2m.c | 17 ++- drivers/block/xen-blkback/blkback.c | 15 --- drivers/xen/gntdev.c| 13 +++--- drivers/xen/grant-table.c | 89 ++--- include/xen/grant_table.h | 8 +--- 7 files changed, 58 insertions(+), 101 deletions(-) Konrad Rzeszutek Wilk (1): Revert "xen/grant-table: Avoid m2p_override during mapping" Mukesh Rathor (1): xen/pvh: set CR4 flags for APs pgpl6ABChdowo.pgp Description: PGP signature
[PATCH] gpio: bcm281xx: Update MODULE_AUTHOR
Add Broadcom's upstreaming mailing list address to MODULE_AUTHOR.
Signed-off-by: Markus Mayer
---
drivers/gpio/gpio-bcm-kona.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index 233d088..f32357e 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012-2013 Broadcom Corporation
+ * Copyright (C) 2012-2014 Broadcom Corporation
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -657,6 +657,6 @@ static struct platform_driver bcm_kona_gpio_driver = {
module_platform_driver(bcm_kona_gpio_driver);
-MODULE_AUTHOR("Broadcom");
+MODULE_AUTHOR("Broadcom Corporation ");
MODULE_DESCRIPTION("Broadcom Kona GPIO Driver");
MODULE_LICENSE("GPL v2");
--
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/
