Re: + zsmalloc-do-not-remap-dst-page-while-prepare-next-src-page.patch added to -mm tree
On (03/24/15 14:03), a...@linux-foundation.org wrote:
> The patch titled
> Subject: zsmalloc: do not remap dst page while prepare next src page
> has been added to the -mm tree. Its filename is
> zsmalloc-do-not-remap-dst-page-while-prepare-next-src-page.patch
>
> This patch should soon appear at
>
> http://ozlabs.org/~akpm/mmots/broken-out/zsmalloc-do-not-remap-dst-page-while-prepare-next-src-page.patch
> and later at
>
> http://ozlabs.org/~akpm/mmotm/broken-out/zsmalloc-do-not-remap-dst-page-while-prepare-next-src-page.patch
>
Hello Stephen,
Heesub Shin has reported that this patch causes BUG_ON on ARM
(with CONFIG_DEBUG_HIGHMEM enabled). Could you please revert
it in linux-next 20150325?
-ss
> --
> From: Sergey Senozhatsky
> Subject: zsmalloc: do not remap dst page while prepare next src page
>
> The object may belong to different pages. zs_object_copy() handles this
> case and maps a new source page (get_next_page() and kmap_atomic()) when
> object crosses boundaries of the current source page. But it also
> performs unnecessary kunmap/kmap_atomic of the destination page (it
> remains unchanged), which can be avoided.
>
> Signed-off-by: Sergey Senozhatsky
> Cc: Minchan Kim
> Cc: Nitin Gupta
> Signed-off-by: Andrew Morton
> ---
>
> mm/zsmalloc.c |2 --
> 1 file changed, 2 deletions(-)
>
> diff -puN
> mm/zsmalloc.c~zsmalloc-do-not-remap-dst-page-while-prepare-next-src-page
> mm/zsmalloc.c
> --- a/mm/zsmalloc.c~zsmalloc-do-not-remap-dst-page-while-prepare-next-src-page
> +++ a/mm/zsmalloc.c
> @@ -1538,12 +1538,10 @@ static void zs_object_copy(unsigned long
> break;
>
> if (s_off + size >= PAGE_SIZE) {
> - kunmap_atomic(d_addr);
> kunmap_atomic(s_addr);
> s_page = get_next_page(s_page);
> BUG_ON(!s_page);
> s_addr = kmap_atomic(s_page);
> - d_addr = kmap_atomic(d_page);
> s_size = class->size - written;
> s_off = 0;
> } else {
> _
>
> Patches currently in -mm which might be from sergey.senozhat...@gmail.com are
>
> zram-cosmetic-zram_attr_ro-code-formatting-tweak.patch
> zram-use-idr-instead-of-zram_devices-array.patch
> zram-factor-out-device-reset-from-reset_store.patch
> zram-reorganize-code-layout.patch
> zram-add-dynamic-device-add-remove-functionality.patch
> zram-add-dynamic-device-add-remove-functionality-fix.patch
> zram-remove-max_num_devices-limitation.patch
> zram-report-every-added-and-removed-device.patch
> zram-trivial-correct-flag-operations-comment.patch
> zram-return-zram-device_id-value-from-zram_add.patch
> zram-introduce-automatic-device_id-generation.patch
> zram-introduce-automatic-device_id-generation-fix.patch
> zram-do-not-let-user-enforce-new-device-dev_id.patch
> zsmalloc-decouple-handle-and-object.patch
> zsmalloc-factor-out-obj_.patch
> zsmalloc-support-compaction.patch
> zsmalloc-adjust-zs_almost_full.patch
> zram-support-compaction.patch
> zsmalloc-record-handle-in-page-private-for-huge-object.patch
> zsmalloc-add-fullness-into-stat.patch
> zsmalloc-zsmalloc-documentation.patch
> zram-remove-num_migrated-device-attr.patch
> zram-move-compact_store-to-sysfs-functions-area.patch
> zram-use-generic-start-end-io-accounting.patch
> zram-describe-device-attrs-in-documentation.patch
> zram-export-new-io_stat-sysfs-attrs.patch
> zram-export-new-mm_stat-sysfs-attrs.patch
> zram-deprecate-zram-attrs-sysfs-nodes.patch
> zsmalloc-remove-synchronize_rcu-from-zs_compact.patch
> zsmalloc-remove-extra-cond_resched-in-__zs_compact.patch
> zsmalloc-do-not-remap-dst-page-while-prepare-next-src-page.patch
> zsmalloc-micro-optimize-zs_object_copy.patch
> cpumask-dont-perform-while-loop-in-cpumask_next_and.patch
> lib-lz4-pull-out-constant-tables.patch
>
> --
> To unsubscribe from this list: send the line "unsubscribe mm-commits" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 03/10] pci: drop some duplicate code
On Tue, Mar 24, 2015 at 06:33:57PM -0500, Bjorn Helgaas wrote:
> On Tue, Mar 24, 2015 at 04:42:35PM +0100, Michael S. Tsirkin wrote:
> > pci_msi_init_pci_dev and pci_msi_off share a lot of code.
> > This used to be justified since pci_msi_init_pci_dev
> > wasn't compiled in when CONFIG_PCI_MSI is off.
> > Now that it is, let's reuse code.
> >
> > Signed-off-by: Michael S. Tsirkin
> > ---
> > drivers/pci/pci.c | 24 +---
> > drivers/pci/probe.c | 11 ---
> > 2 files changed, 9 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 81f06e8..d5f297a 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -3106,26 +3106,12 @@ EXPORT_SYMBOL_GPL(pci_check_and_unmask_intx);
> > */
> > void pci_msi_off(struct pci_dev *dev)
> > {
> > - int pos;
> > - u16 control;
> > + if (dev->msi_cap)
> > + pci_msi_set_enable(dev, 0);
> >
> > - /*
> > -* This looks like it could go in msi.c, but we need it even when
> > -* CONFIG_PCI_MSI=n. For the same reason, we can't use
> > -* dev->msi_cap or dev->msix_cap here.
> > -*/
> > - pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
> > - if (pos) {
> > - pci_read_config_word(dev, pos + PCI_MSI_FLAGS, );
> > - control &= ~PCI_MSI_FLAGS_ENABLE;
> > - pci_write_config_word(dev, pos + PCI_MSI_FLAGS, control);
> > - }
> > - pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
> > - if (pos) {
> > - pci_read_config_word(dev, pos + PCI_MSIX_FLAGS, );
> > - control &= ~PCI_MSIX_FLAGS_ENABLE;
> > - pci_write_config_word(dev, pos + PCI_MSIX_FLAGS, control);
> > - }
> > + dev->msix_cap = pci_find_capability(dev, PCI_CAP_ID_MSIX);
>
> I think the above line is superfluous, isn't it? You already do the same
> in pci_msi_init_pci_dev() (below).
Ugh. Yea. I'll fix that up, thanks!
> > + if (dev->msix_cap)
> > + pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
> > }
> > EXPORT_SYMBOL_GPL(pci_msi_off);
> >
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 45d6d5c..baf8ddd 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -1489,17 +1489,14 @@ static void pci_msi_init_pci_dev(struct pci_dev
> > *dev)
> > INIT_LIST_HEAD(>msi_list);
> > #endif
> >
> > + dev->msi_cap = pci_find_capability(dev, PCI_CAP_ID_MSI);
> > + dev->msix_cap = pci_find_capability(dev, PCI_CAP_ID_MSIX);
> > +
> > /* Disable the msi hardware to avoid screaming interrupts
> > * during boot. This is the power on reset default so
> > * usually this should be a noop.
> > */
> > - dev->msi_cap = pci_find_capability(dev, PCI_CAP_ID_MSI);
> > - if (dev->msi_cap)
> > - pci_msi_set_enable(dev, 0);
> > -
> > - dev->msix_cap = pci_find_capability(dev, PCI_CAP_ID_MSIX);
> > - if (dev->msix_cap)
> > - pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
> > + pci_msi_off(dev);
> > }
> >
> > static void pci_init_capabilities(struct pci_dev *dev)
> > --
> > MST
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] media: dmxdev: fix possible race condition
This patch fixes race condition between dvb_dmxdev_buffer_read and
dvb_demux_io_ioctl.
There are race conditions executing DMX_ADD_PID or DMX_REMOVE_PID in the
dvb_demux_ioctl when dvb_demux_read is waiting for the data by
wait_event_interruptible. So, this fixes to sleep with acquired mutex
and splits dvb_dmxdev_buffer_read into dvb_dvr_read.
Signed-off-by: Jaedon Shin
---
drivers/media/dvb-core/dmxdev.c | 94 -
1 file changed, 75 insertions(+), 19 deletions(-)
diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
index abff803ad69a..c2564b0e389b 100644
--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -57,10 +57,11 @@ static int dvb_dmxdev_buffer_write(struct dvb_ringbuffer
*buf,
return dvb_ringbuffer_write(buf, src, len);
}
-static ssize_t dvb_dmxdev_buffer_read(struct dvb_ringbuffer *src,
+static ssize_t dvb_dmxdev_buffer_read(struct dmxdev_filter *dmxdevfilter,
int non_blocking, char __user *buf,
size_t count, loff_t *ppos)
{
+ struct dvb_ringbuffer *src = >buffer;
size_t todo;
ssize_t avail;
ssize_t ret = 0;
@@ -75,16 +76,21 @@ static ssize_t dvb_dmxdev_buffer_read(struct dvb_ringbuffer
*src,
}
for (todo = count; todo > 0; todo -= ret) {
- if (non_blocking && dvb_ringbuffer_empty(src)) {
- ret = -EWOULDBLOCK;
- break;
- }
+ if (dvb_ringbuffer_empty(src)) {
+ mutex_unlock(>mutex);
- ret = wait_event_interruptible(src->queue,
- !dvb_ringbuffer_empty(src) ||
- (src->error != 0));
- if (ret < 0)
- break;
+ if (non_blocking)
+ return -EWOULDBLOCK;
+
+ ret = wait_event_interruptible(src->queue,
+ !dvb_ringbuffer_empty(src) ||
+ (src->error != 0));
+ if (ret < 0)
+ return ret;
+
+ if (mutex_lock_interruptible(>mutex))
+ return -ERESTARTSYS;
+ }
if (src->error) {
ret = src->error;
@@ -242,13 +248,63 @@ static ssize_t dvb_dvr_read(struct file *file, char
__user *buf, size_t count,
{
struct dvb_device *dvbdev = file->private_data;
struct dmxdev *dmxdev = dvbdev->priv;
+ struct dvb_ringbuffer *src = >dvr_buffer;
+ size_t todo;
+ ssize_t avail;
+ ssize_t ret = 0;
- if (dmxdev->exit)
+ if (mutex_lock_interruptible(>mutex))
+ return -ERESTARTSYS;
+
+ if (dmxdev->exit) {
+ mutex_unlock(>mutex);
return -ENODEV;
+ }
+
+ if (src->error) {
+ ret = src->error;
+ dvb_ringbuffer_flush(src);
+ mutex_unlock(>mutex);
+ return ret;
+ }
+
+ for (todo = count; todo > 0; todo -= ret) {
+ if (dvb_ringbuffer_empty(src)) {
+ mutex_unlock(>mutex);
- return dvb_dmxdev_buffer_read(>dvr_buffer,
- file->f_flags & O_NONBLOCK,
- buf, count, ppos);
+ if (file->f_flags & O_NONBLOCK)
+ return -EWOULDBLOCK;
+
+ ret = wait_event_interruptible(src->queue,
+ !dvb_ringbuffer_empty(src) ||
+ (src->error != 0));
+ if (ret < 0)
+ return ret;
+
+ if (mutex_lock_interruptible(>mutex))
+ return -ERESTARTSYS;
+ }
+
+ if (src->error) {
+ ret = src->error;
+ dvb_ringbuffer_flush(src);
+ break;
+ }
+
+ avail = dvb_ringbuffer_avail(src);
+ if (avail > todo)
+ avail = todo;
+
+ ret = dvb_ringbuffer_read_user(src, buf, avail);
+ if (ret < 0)
+ break;
+
+ buf += ret;
+ }
+
+ mutex_unlock(>mutex);
+
+ return (count - todo) ? (count - todo) : ret;
}
static int dvb_dvr_set_buffer_size(struct dmxdev *dmxdev,
@@ -283,7 +339,6 @@ static int dvb_dvr_set_buffer_size(struct dmxdev *dmxdev,
return 0;
}
-
static inline void dvb_dmxdev_filter_state_set(struct dmxdev_filter
*dmxdevfilter, int state)
{
@@ -904,7 +959,7 @@ static ssize_t
Re: [PATCH v3] Add virtio-input driver.
On Tue, Mar 24, 2015 at 10:28:05AM -0700, Dmitry Torokhov wrote: > > > > > + err = input_register_device(vi->idev); > > > > > + if (err) > > > > > + goto err_input_register; > > > > > + > > > > > + return 0; > > > > > + > > > > > +err_input_register: > > > > > > > > > + input_free_device(vi->idev); > > > > > > > > At this point you can already get interrupts > > > > since you called virtio_device_ready, and > > > > getting events from a freed device likely won't > > > > DTRT. > > > > > > Right. I guess you want to mark the virtio device ready only after > > > registering input device. > > > > No that's broken since you can get events after this > > point, and you won't be able to forward them. > > Who cares? virtio cares: guest will crash if you attempt to kick virtqueue before device ready call. > What makes these events needed compared to ones sent 1 ms > earlier before we had input device registered? > > But I guess if you can call virtio_device_ready/virtio_device_broken > several times then the best option is putting them into input_dev->open > and input_dev->close callbacks. > > Thanks. > -- > Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] Add virtio-input driver.
On Wed, Mar 25, 2015 at 01:51:43PM +1030, Rusty Russell wrote: > Gerd Hoffmann writes: > > virtio-input is basically evdev-events-over-virtio, so this driver isn't > > much more than reading configuration from config space and forwarding > > incoming events to the linux input layer. > > > > Signed-off-by: Gerd Hoffmann > > Is the input layer sane? I've never dealt with it, so I don't know. I'm rather biased having designed it, but I'd say it's reasonable. It certainly has limitations and design mistakes, but none are too bad. One testimony to that Android has based its own Input API around it. > What's it used for? For all human input devices, like keyboards, mice, touchscreens, etc. > Imagine a future virtio standard which incorporates this. And a Windows > or FreeBSD implementation of the device and or driver. How ugly would > they be? A windows translation layer is fairly easy, people porting software from Windows to Linux told me numerous times that adapting isn't hard. I also believe that at least one of the BSD's has a compatible implementation these days based on the fact that I was asked to allow copying the headers in the past. -- Vojtech Pavlik Director SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 32/35] clockevents: Fix cpu down race for hrtimer based broadcasting
Ping. On 03/16/2015 10:22 AM, Preeti U Murthy wrote: > Hi Peter, Ingo, Thomas, > > Can you please take a look at the conversation on this thread ? > This fix is urgent. > > Regards > Preeti U Murthy > > On 03/02/2015 08:26 PM, Peter Zijlstra wrote: >> On Fri, Feb 27, 2015 at 02:19:05PM +0530, Preeti U Murthy wrote: >>> The problem reported in the changelog of this patch is causing severe >>> regressions very frequently on our machines for certain usecases. It would >>> help to put in a fix in place first and then follow that up with these >>> cleanups. A fix on the below lines : >> >> Regression how? Neither Thomas' Changelog, nor yours mention its a >> regression. >> >> If its a (recent) Regression you need to have a Fixes tag at the very >> least. So when was this broken and by which patch? >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] MAINTAINERS: Pantelis Antoniou device tree overlay maintainer
On Tue, Mar 17, 2015 at 3:30 PM, Pantelis Antoniou wrote: > Add me as the device tree overlays maintainer. > > Signed-off-by: Pantelis Antoniou Applied. Thanks. Rob > --- > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 0e1abe8..24aa339 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7187,6 +7187,15 @@ F: Documentation/devicetree/ > F: arch/*/boot/dts/ > F: include/dt-bindings/ > > +OPEN FIRMWARE AND DEVICE TREE OVERLAYS > +M: Pantelis Antoniou > +L: devicet...@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/dynamic-resolution-notes.txt > +F: Documentation/devicetree/overlay-notes.txt > +F: drivers/of/overlay.c > +F: drivers/of/resolver.c > + > OPENRISC ARCHITECTURE > M: Jonas Bonn > W: http://openrisc.net > -- > 1.7.12 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] zsmalloc: do not remap dst page while prepare next src page
On (03/25/15 14:05), Heesub Shin wrote:
> No, it's not unnecessary. We should do kunmap_atomic() in the reverse
> order of kmap_atomic(), so unfortunately it's inevitable to
> kunmap_atomic() both on d_addr and s_addr.
>
Andrew, can you please drop this patch?
> >
> > Signed-off-by: Sergey Senozhatsky
> > ---
> > mm/zsmalloc.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index d920e8b..7af4456 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -1536,12 +1536,10 @@ static void zs_object_copy(unsigned long src,
> > unsigned long dst,
> > break;
> >
> > if (s_off + size >= PAGE_SIZE) {
> > - kunmap_atomic(d_addr);
> > kunmap_atomic(s_addr);
>
> Removing kunmap_atomic(d_addr) here may cause BUG_ON() at __kunmap_atomic().
>
> I tried yours to see it really happens:
> > kernel BUG at arch/arm/mm/highmem.c:113!
oh, arm. tested on x86_64 only. I see why it happens there. thanks for
reporting.
sorry, should have checked.
> > Internal error: Oops - BUG: 0 [#1] SMP ARM
> > Modules linked in:
> > CPU: 2 PID: 1774 Comm: bash Not tainted 4.0.0-rc2-mm1+ #105
> > Hardware name: ARM-Versatile Express
> > task: ee971300 ti: e8a26000 task.ti: e8a26000
> > PC is at __kunmap_atomic+0x144/0x14c
> > LR is at zs_object_copy+0x19c/0x2dc
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] of: overlay: Master enable switch
On Tue, Mar 17, 2015 at 3:30 PM, Pantelis Antoniou
wrote:
> Implement a throw once master enable switch to protect against any
> further overlay applications if the administrator desires so.
sysfs documentation?
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/of/overlay.c | 66
> +++-
> 1 file changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index f17f5ef..6688797 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> #include "of_private.h"
>
> @@ -55,6 +56,9 @@ struct of_overlay {
> struct kobject kobj;
> };
>
> +/* master enable switch; once set to 0 can't be re-enabled */
> +static atomic_t ov_enable = ATOMIC_INIT(1);
> +
> static int of_overlay_apply_one(struct of_overlay *ov,
> struct device_node *target, const struct device_node
> *overlay);
>
> @@ -345,6 +349,60 @@ static struct kobj_type of_overlay_ktype = {
>
> static struct kset *ov_kset;
>
> +static ssize_t enable_read(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t offset, size_t count)
> +{
> + char tbuf[3];
> +
> + if (offset < 0)
> + return -EINVAL;
> +
> + if (offset >= sizeof(tbuf))
> + return 0;
> +
> + if (count > sizeof(tbuf) - offset)
> + count = sizeof(tbuf) - offset;
> +
> + /* fill in temp */
> + tbuf[0] = '0' + atomic_read(_enable);
> + tbuf[1] = '\n';
> + tbuf[2] = '\0';
> +
> + /* copy to buffer */
> + memcpy(buf, tbuf + offset, count);
> +
> + return count;
> +}
> +
> +static ssize_t enable_write(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t off, size_t count)
> +{
> + int new_enable;
> +
> + if (off != 0 || (buf[0] != '0' && buf[1] != '1'))
Is buf[1] correct here?
> + return -EINVAL;
> +
> + new_enable = buf[0] - '0';
> + if (new_enable != 0 && new_enable != 1)
Make unsigned just "if (new_enable > 1)".
> + return -EINVAL;
> +
> + /* NOP for same value */
> + if (new_enable == atomic_read(_enable))
> + return count;
> +
> + /* if we've disabled it, no going back */
> + if (atomic_read(_enable) == 0)
> + return -EPERM;
> +
> + atomic_set(_enable, new_enable);
> + return count;
> +}
> +
> +/* just a single char + '\n' + '\0' */
> +static BIN_ATTR_RW(enable, 3);
> +
> /**
> * of_overlay_create() - Create and apply an overlay
> * @tree: Device node containing all the overlays
> @@ -360,6 +418,10 @@ int of_overlay_create(struct device_node *tree)
> struct of_overlay *ov;
> int err, id;
>
> + /* administratively disabled */
> + if (!atomic_read(_enable))
> + return -EPERM;
> +
> /* allocate the overlay structure */
> ov = kzalloc(sizeof(*ov), GFP_KERNEL);
> if (ov == NULL)
> @@ -596,5 +658,7 @@ int of_overlay_init(void)
> if (!ov_kset)
> return -ENOMEM;
>
> - return 0;
> + rc = sysfs_create_bin_file(_kset->kobj, _attr_enable);
> + WARN(rc, "%s: error adding enable attribute\n", __func__);
> + return rc;
> }
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: powerpc/perf: add missing put_cpu_var in power_pmu_event_init
On Tue, 2015-24-03 at 12:33:22 UTC, Jan Stancek wrote: > One path in power_pmu_event_init() calls get_cpu_var(), but is > missing matching call to put_cpu_var(), which causes preemption > imbalance and crash in user-space: > > Page fault in user mode with in_atomic() = 1 mm = c01fefa5a280 > NIP = 3fff9bf2cae0 MSR = 90014280f032 > Oops: Weird page fault, sig: 11 [#23] Thanks. But I don't see this. I guess you have CONFIG_PREEMPT enabled? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation:Chinese translation of Documentation/arm64/legacy_instructions.txt
2015-03-25 12:09 GMT+08:00 : > From: Fu Wei > > This is a Chinese translated version of > Documentation/arm64/legacy_instructions.txt > > It is based on the modifications of > Documentation/arm64/legacy_instructions.txt in submission: > "587064b6", "bd35a4ad", "2d888f48", "c852f320". > > Signed-off-by: Fu Wei Signed-off-by: Weiwei Jia Thanks, Weiwei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 2/2] dma: Add Xilinx AXI Central Direct Memory Access Engine driver support
This is the driver for the AXI Central Direct Memory Access (AXI
CDMA) core, which is a soft Xilinx IP core that provides high-bandwidth
Direct Memory Access (DMA) between a memory-mapped source address and a
memory-mapped destination address.
This module works on Zynq (ARM Based SoC) and Microblaze platforms.
Signed-off-by: Srikanth Thokala
Signed-off-by: Kedareswara rao Appana
---
This patch is rebased on top of dma: xilinx-dma: move header file
to common location.
Changes in v3:
- Check for CDMA idle condition before changing the configuration.
- Modified the xilinx_dma.h header file location to the
include/linux/dma/xilinx_dma.h
Changes in v2:
- Rebased on 3.16-rc7.
drivers/dma/Kconfig | 12 +
drivers/dma/xilinx/Makefile |1 +
drivers/dma/xilinx/xilinx_cdma.c | 1000 ++
include/linux/dma/xilinx_dma.h | 15 +-
4 files changed, 1027 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/xilinx/xilinx_cdma.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index a874b6e..1bc17c6 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -425,6 +425,18 @@ config IMG_MDC_DMA
help
Enable support for the IMG multi-threaded DMA controller (MDC).
+config XILINX_CDMA
+ tristate "Xilinx AXI CDMA Engine"
+ depends on (ARCH_ZYNQ || MICROBLAZE)
+ select DMA_ENGINE
+ help
+ Enable support for Xilinx AXI CDMA Soft IP.
+
+ The AXI CDMA is a soft IP which provides high-bandwidth
+ Direct Memory Access (DMA) between a memory-mapped source
+ address and a memory-mapped destination address using the
+ AXI4 protocol.
+
config DMA_ENGINE
bool
diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile
index 3c4e9f2..e1dee77 100644
--- a/drivers/dma/xilinx/Makefile
+++ b/drivers/dma/xilinx/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o
+obj-$(CONFIG_XILINX_CDMA) += xilinx_cdma.o
diff --git a/drivers/dma/xilinx/xilinx_cdma.c b/drivers/dma/xilinx/xilinx_cdma.c
new file mode 100644
index 000..ff82fab
--- /dev/null
+++ b/drivers/dma/xilinx/xilinx_cdma.c
@@ -0,0 +1,1000 @@
+/*
+ * DMA driver for Xilinx Central DMA Engine
+ *
+ * Copyright (C) 2010 - 2015 Xilinx, Inc. All rights reserved.
+ *
+ * Based on the Freescale DMA driver.
+ *
+ * Description:
+ * The AXI CDMA, is a soft IP, which provides high-bandwidth Direct Memory
+ * Access (DMA) between a memory-mapped source address and a memory-mapped
+ * destination address.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../dmaengine.h"
+
+/* Register Offsets */
+#define XILINX_CDMA_CONTROL_OFFSET 0x00
+#define XILINX_CDMA_STATUS_OFFSET 0x04
+#define XILINX_CDMA_CDESC_OFFSET 0x08
+#define XILINX_CDMA_TDESC_OFFSET 0x10
+#define XILINX_CDMA_SRCADDR_OFFSET 0x18
+#define XILINX_CDMA_DSTADDR_OFFSET 0x20
+#define XILINX_CDMA_BTT_OFFSET 0x28
+
+/* General register bits definitions */
+#define XILINX_CDMA_CR_RESET BIT(2)
+#define XILINX_CDMA_CR_SGMODE BIT(3)
+
+#define XILINX_CDMA_SR_IDLEBIT(1)
+
+#define XILINX_CDMA_XR_IRQ_IOC_MASKBIT(12)
+#define XILINX_CDMA_XR_IRQ_DELAY_MASK BIT(13)
+#define XILINX_CDMA_XR_IRQ_ERROR_MASK BIT(14)
+#define XILINX_CDMA_XR_IRQ_ALL_MASKGENMASK(14, 12)
+
+#define XILINX_CDMA_XR_DELAY_MASK GENMASK(31, 24)
+#define XILINX_CDMA_XR_COALESCE_MASK GENMASK(23, 16)
+
+#define XILINX_CDMA_DELAY_MAX GENMASK(7, 0)
+#define XILINX_CDMA_DELAY_SHIFT24
+
+#define XILINX_CDMA_COALESCE_MAX GENMASK(7, 0)
+#define XILINX_CDMA_COALESCE_SHIFT 16
+
+/* Delay loop counter to prevent hardware failure */
+#define XILINX_CDMA_RESET_LOOP 100
+
+/* Maximum transfer length */
+#define XILINX_CDMA_MAX_TRANS_LEN GENMASK(22, 0)
+
+/**
+ * struct xilinx_cdma_desc_hw - Hardware Descriptor
+ * @next_desc: Next Descriptor Pointer @0x00
+ * @pad1: Reserved @0x04
+ * @src_addr: Source address @0x08
+ * @pad2: Reserved @0x0C
+ * @dest_addr: Destination address @0x10
+ * @pad3: Reserved @0x14
+ * @control: Control field @0x18
+ * @status: Status field @0x1C
+ */
+struct xilinx_cdma_desc_hw {
+ u32 next_desc;
+ u32 pad1;
+ u32 src_addr;
+ u32 pad2;
+ u32 dest_addr;
+ u32 pad3;
+ u32 control;
+ u32 status;
+} __aligned(64);
+
+/**
+ * struct xilinx_cdma_tx_segment - Descriptor segment
+ * @hw: Hardware descriptor
+ * @node: Node in the descriptor segments list
+ * @phys: Physical address of segment
+ */
+struct xilinx_cdma_tx_segment {
+ struct
Re: [PATCH v2 2/2] staging: panel: fix lcd type in module parameters
On Wed, Mar 25, 2015 at 12:25:59AM +0100, Willy Tarreau wrote: > On Tue, Mar 24, 2015 at 02:56:33PM +0530, Sudip Mukherjee wrote: > > with reference to the previous patch of the series, fixed the > > lcd type in module parameters. > > Sudip, it's better to avoid fragmenting patches like you did, because > it will result in a kernel state where there is an inconsistency between > the parameters actually used by the kernel and those reported by modinfo. > This can happen for example if someone does a bisect and ends up on patch > 1/2 applied only. Obviously in this case there is very little harm, but > you get the idea : each patch should be a functional change, address one > thing and do it consistently. So if you change the #defines or enums or > whatever, all the locations where their old values were referenced must > be changed in the same patch, simply because in fact they are duplicate > entries. Another point is that someone who notices your patch v1 and > does not notice patch v2 could pick v1 for his kernel and end up with > something inconsistent. For this reason it would be better to merge your > patches into a single one here. explained very well. thanks. i was wondering why Dan asked me to merge them into one. regards sudip > > > might not apply properly to old versions, some reordering was done > > in commit <98e0e762e> > > Appreciated, thanks for checking this! > > Best 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 1/2] zsmalloc: do not remap dst page while prepare next src page
Hello,
On 03/25/2015 12:24 AM, Sergey Senozhatsky wrote:
> object may belong to different pages. zs_object_copy() handles
> this case and maps a new source page (get_next_page() and
> kmap_atomic()) when object crosses boundaries of the current
> source page. But it also performs unnecessary kunmap/kmap_atomic
> of the destination page (it remains unchanged), which can be
> avoided.
No, it's not unnecessary. We should do kunmap_atomic() in the reverse
order of kmap_atomic(), so unfortunately it's inevitable to
kunmap_atomic() both on d_addr and s_addr.
>
> Signed-off-by: Sergey Senozhatsky
> ---
> mm/zsmalloc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index d920e8b..7af4456 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -1536,12 +1536,10 @@ static void zs_object_copy(unsigned long src,
> unsigned long dst,
> break;
>
> if (s_off + size >= PAGE_SIZE) {
> - kunmap_atomic(d_addr);
> kunmap_atomic(s_addr);
Removing kunmap_atomic(d_addr) here may cause BUG_ON() at __kunmap_atomic().
I tried yours to see it really happens:
> kernel BUG at arch/arm/mm/highmem.c:113!
> Internal error: Oops - BUG: 0 [#1] SMP ARM
> Modules linked in:
> CPU: 2 PID: 1774 Comm: bash Not tainted 4.0.0-rc2-mm1+ #105
> Hardware name: ARM-Versatile Express
> task: ee971300 ti: e8a26000 task.ti: e8a26000
> PC is at __kunmap_atomic+0x144/0x14c
> LR is at zs_object_copy+0x19c/0x2dc
regards
heesub
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] of: unittest: overlay: Keep track of created overlays
On Tue, Mar 17, 2015 at 3:30 PM, Pantelis Antoniou
wrote:
> During the course of the overlay selftests some of them remain
> applied. While this does not pose a real problem, make sure you track
> them and destroy them at the end of the test.
This is going to need to be rebased on my tree as there has been some
selftest->unitest renaming.
Rob
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/of/unittest.c | 62
> +++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 4e60682..c711534 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +#include
> +
> #include "of_private.h"
>
> static struct selftest_results {
> @@ -1115,6 +1117,59 @@ static const char *overlay_path(int nr)
>
> static const char *bus_path = "/testcase-data/overlay-node/test-bus";
>
> +/* it is guaranteed that overlay ids are assigned in sequence */
> +#define MAX_SELFTEST_OVERLAYS 256
> +static unsigned long overlay_id_bits[BITS_TO_LONGS(MAX_SELFTEST_OVERLAYS)];
> +static int overlay_first_id = -1;
> +
> +static void of_selftest_track_overlay(int id)
> +{
> + if (overlay_first_id < 0)
> + overlay_first_id = id;
> + id -= overlay_first_id;
> +
> + /* we shouldn't need that many */
> + BUG_ON(id >= MAX_SELFTEST_OVERLAYS);
> + overlay_id_bits[BIT_WORD(id)] |= BIT_MASK(id);
> +}
> +
> +static void of_selftest_untrack_overlay(int id)
> +{
> + if (overlay_first_id < 0)
> + return;
> + id -= overlay_first_id;
> + BUG_ON(id >= MAX_SELFTEST_OVERLAYS);
> + overlay_id_bits[BIT_WORD(id)] &= ~BIT_MASK(id);
> +}
> +
> +static void of_selftest_destroy_tracked_overlays(void)
> +{
> + int id, ret, defers;
> +
> + if (overlay_first_id < 0)
> + return;
> +
> + /* try until no defers */
> + do {
> + defers = 0;
> + /* remove in reverse order */
> + for (id = MAX_SELFTEST_OVERLAYS - 1; id >= 0; id--) {
> + if (!(overlay_id_bits[BIT_WORD(id)] & BIT_MASK(id)))
> + continue;
> +
> + ret = of_overlay_destroy(id + overlay_first_id);
> + if (ret != 0) {
> + defers++;
> + pr_warn("%s: overlay destroy failed for
> #%d\n",
> + __func__, id + overlay_first_id);
> + continue;
> + }
> +
> + overlay_id_bits[BIT_WORD(id)] &= ~BIT_MASK(id);
> + }
> + } while (defers > 0);
> +}
> +
> static int of_selftest_apply_overlay(int selftest_nr, int overlay_nr,
> int *overlay_id)
> {
> @@ -1136,6 +1191,7 @@ static int of_selftest_apply_overlay(int selftest_nr,
> int overlay_nr,
> goto out;
> }
> id = ret;
> + of_selftest_track_overlay(id);
>
> ret = 0;
>
> @@ -1349,6 +1405,7 @@ static void of_selftest_overlay_6(void)
> return;
> }
> ov_id[i] = ret;
> + of_selftest_track_overlay(ov_id[i]);
> }
>
> for (i = 0; i < 2; i++) {
> @@ -1373,6 +1430,7 @@ static void of_selftest_overlay_6(void)
> PDEV_OVERLAY));
> return;
> }
> + of_selftest_untrack_overlay(ov_id[i]);
> }
>
> for (i = 0; i < 2; i++) {
> @@ -1417,6 +1475,7 @@ static void of_selftest_overlay_8(void)
> return;
> }
> ov_id[i] = ret;
> + of_selftest_track_overlay(ov_id[i]);
> }
>
> /* now try to remove first overlay (it should fail) */
> @@ -1439,6 +1498,7 @@ static void of_selftest_overlay_8(void)
> PDEV_OVERLAY));
> return;
> }
> + of_selftest_untrack_overlay(ov_id[i]);
> }
>
> selftest(1, "overlay test %d passed\n", 8);
> @@ -1861,6 +1921,8 @@ static void __init of_selftest_overlay(void)
> of_selftest_overlay_i2c_cleanup();
> #endif
>
> + of_selftest_destroy_tracked_overlays();
> +
> out:
> of_node_put(bus_np);
> }
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: Defer lookup of supply to regulator_get
On Tue, Mar 24, 2015 at 06:56:05PM -0700, Bjorn Andersson wrote: > Instead of resolving regulator supplies during registration move this to > the time of a consumer retrieving a handle. The benefit is that it's > possible for one driver to register regulators with internal > dependencies out of order. This looks basically sensible (as we discussed in person) - I'd like to poke at this on some systems I've got back home to make sure I'm happy with the debugging output and so on but I'm not expecting any problems. signature.asc Description: Digital signature
Re: [Patch] dt: OF_UNITTEST make dependency broken
On Fri, Mar 13, 2015 at 2:21 PM, Frank Rowand wrote: > From: Frank Rowand > > If CONFIG_OF_UNITTEST=y then a kernel image make will always cause .version to > be incremented, even if there are not source changes. This is caused by > a lack of dependency tracking and checking for > drivers/of/unittest-data/testcases.dtb.o. > > > Signed-off-by: Frank Rowand Applied. Thanks. Rob > > --- > > > drivers/of/Makefile |5 +++-- > drivers/of/unittest-data/.gitignore |2 ++ > drivers/of/unittest-data/Makefile |7 +++ > 3 files changed, 12 insertions(+), 2 deletions(-) > > Index: b/drivers/of/Makefile > === > --- a/drivers/of/Makefile > +++ b/drivers/of/Makefile > @@ -6,8 +6,7 @@ obj-$(CONFIG_OF_PROMTREE) += pdt.o > obj-$(CONFIG_OF_ADDRESS) += address.o > obj-$(CONFIG_OF_IRQ)+= irq.o > obj-$(CONFIG_OF_NET) += of_net.o > -obj-$(CONFIG_OF_UNITTEST) += of_unittest.o > -of_unittest-objs := unittest.o unittest-data/testcases.dtb.o > +obj-$(CONFIG_OF_UNITTEST) += unittest.o > obj-$(CONFIG_OF_MDIO) += of_mdio.o > obj-$(CONFIG_OF_PCI) += of_pci.o > obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o > @@ -16,5 +15,7 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_rese > obj-$(CONFIG_OF_RESOLVE) += resolver.o > obj-$(CONFIG_OF_OVERLAY) += overlay.o > > +obj-$(CONFIG_OF_UNITTEST) += unittest-data/ > + > CFLAGS_fdt.o = -I$(src)/../../scripts/dtc/libfdt > CFLAGS_fdt_address.o = -I$(src)/../../scripts/dtc/libfdt > Index: b/drivers/of/unittest-data/Makefile > === > --- /dev/null > +++ b/drivers/of/unittest-data/Makefile > @@ -0,0 +1,7 @@ > +obj-y += testcases.dtb.o > + > +targets += testcases.dtb testcases.dtb.S > + > +.SECONDARY: \ > + $(obj)/testcases.dtb.S \ > + $(obj)/testcases.dtb > Index: b/drivers/of/unittest-data/.gitignore > === > --- /dev/null > +++ b/drivers/of/unittest-data/.gitignore > @@ -0,0 +1,2 @@ > +testcases.dtb > +testcases.dtb.S -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] Update the OF unittest and some small fix
On Wed, Mar 11, 2015 at 3:36 AM, Wang Long wrote:
> This series patches do some small fixes in drivers/of/unittest.c,
> and update the Documenttion.
>
> At last, replace selftest with unittest in the c, dtsi
> and binding files.
>
> * v2 <- v1:
> - According to Gaurav's advice. make the rename
> file patch correctly.
>
> Wang Long (5):
> of/unittest: remove the duplicate of_changeset_init
> of/unittest: Fix the wrong expected value in
> of_selftest_property_string
> Documentation: update the of_selftest.txt
> Documentation: rename of_selftest.txt to of_unittest.txt
> of/unittest: replace 'selftest' with 'unittest'
I've applied the series. Thanks.
Rob
>
> Documentation/devicetree/bindings/unittest.txt | 44 +-
> .../{of_selftest.txt => of_unittest.txt} | 35 +-
> drivers/of/unittest-data/tests-overlay.dtsi| 108 ++--
> drivers/of/unittest.c | 703
> ++---
> 4 files changed, 445 insertions(+), 445 deletions(-)
> rename Documentation/devicetree/{of_selftest.txt => of_unittest.txt} (87%)
>
> --
> 1.8.3.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rculist: Fix another sparse warning
This fixes the following sparse warnings: make C=1 CF=-D__CHECK_ENDIAN__ net/tipc/name_table.o net/tipc/name_table.c:977:17: error: incompatible types in comparison expression (different address spaces) net/tipc/name_table.c:977:17: error: incompatible types in comparison expression (different address spaces) To silence these spare complaints, an RCU annotation should be added to "next" pointer of hlist_node structure through hlist_next_rcu() macro when iterating over a hlist with hlist_for_each_entry_from_rcu(). Signed-off-by: Ying Xue --- include/linux/rculist.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/rculist.h b/include/linux/rculist.h index a18b16f..18a3f15 100644 --- a/include/linux/rculist.h +++ b/include/linux/rculist.h @@ -549,8 +549,8 @@ static inline void hlist_add_behind_rcu(struct hlist_node *n, */ #define hlist_for_each_entry_from_rcu(pos, member) \ for (; pos; \ -pos = hlist_entry_safe(rcu_dereference((pos)->member.next),\ - typeof(*(pos)), member)) +pos = hlist_entry_safe(rcu_dereference_bh(hlist_next_rcu( \ + &(pos)->member)), typeof(*(pos)), member)) #endif /* __KERNEL__ */ #endif -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL v2] of: Add of-graph helpers to loop over endpoints and find ports by id
On Tue, Mar 24, 2015 at 4:15 AM, Russell King - ARM Linux wrote: > On Mon, Mar 23, 2015 at 05:29:02PM +0100, Heiko Stuebner wrote: >> Hi Rob, Philipp, >> >> Am Mittwoch, 11. März 2015, 09:51:21 schrieb Philipp Zabel: >> > Am Dienstag, den 10.03.2015, 14:05 -0500 schrieb Rob Herring: >> > > I've only been copied on this latest pull request and a version from >> > > March of last year which Grant nak'ed. This series did not go to >> > > devicetree list either. I'll take a look at the series. >> > >> > My bad, I should have copied you, too. Thanks for having a look now. >> >> any news on this? >> >> Because it looks like I'll need the of_graph_get_port_by_id functionality in >> the short term, it'll be nice to not having to opencode this :-) > > Oh hell, you mean this still hasn't been merged for the next merge window? > > What's going on, Grant? > > Andrew, can you please take this if we send you the individual patches? > If not, I'll merge it into my tree, and send it to Linus myself. If > Grant wakes up, we can address any comments he has at that time by > additional patches. (I'll give Grant an extra few days to reply to > this mail...) I've merged this for 4.1. It is in my for-next branch[1]. Rob [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] ARM: fix module-bound check in setting page attributes
It was introduced in commit f2ca09f381a59 (ARM: 8311/1: Don't use is_module_addr in setting page attributes) We have no need to check start twice, but see if end is also in range. Signed-off-by: Hillf Danton --- --- a/arch/arm/mm/pageattr.cWed Mar 25 11:55:13 2015 +++ b/arch/arm/mm/pageattr.cWed Mar 25 11:57:31 2015 @@ -52,7 +52,7 @@ static int change_memory_common(unsigned if (start < MODULES_VADDR || start >= MODULES_END) return -EINVAL; - if (end < MODULES_VADDR || start >= MODULES_END) + if (end < MODULES_VADDR || end >= MODULES_END) return -EINVAL; data.set_mask = set_mask; -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 v2] Documentation, split up rtc.txt into documentation and test file
On 03/23/2015 02:32 PM, Prarit Bhargava wrote: > This patch splits rtc.txt into two separate files, one for the > documentation itself, and the other for the rtctest.c file. The rtctest > file is moved into the kernel tools/testing/selftests/timers directory. > This will make automated testing easier. Note that the only difference in > the rtc.txt file is that the location of the rtctest.c file has changed. > > Signed-off-by: Prarit Bhargava > Cc: cor...@lwn.net > Cc: rtc-li...@googlegroups.com > Cc: linux-...@vger.kernel.org > Cc: a.zu...@towertech.it > Cc: pra...@redhat.com > Cc: john.stu...@linaro.org > Cc: shua...@osg.samsung.com > Applied this patch and 2/2 to linux-kselftest next for 4.1 thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/4] clk: st: New always-on clock domain
Hi Lee,
On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote:
> On Fri, 06 Mar 2015, Mike Turquette wrote:
>> Quoting Lee Jones (2015-03-04 04:00:03)
>> > Mike,
>> >
>> > Do you want me to resend this set with Robert's Reviewed-by applied,
>> > or are you happy to apply it yourself?
>>
>> No need for the resend. I am hoping for a final review from a DT human.
>>
>> This approach looks fine to me. In practice I think it is restricted to
>> hardware blocks that don't exist in DT yet (e.g. no driver, in the case
>> of your interconnect) and that restriction is probably for the best.
>
> Agreed.
I think this restriction should be documented in the DT binding more clearly,
as adding a "clk-always-on" node prohibits you from handling the clock
correctly in
the future.
Still, for simple devices where you don't have a driver, but have "predictable"
bindings (e.g. a bus like "simple-pm-bus"), I think it's better to add
a device node
for that simple device now, incl. a reference to the clock, and have a simple
driver that binds to the device, or platform code that looks for a
compatible node,
and enables the clock. That way you don't have to make any chances to the DTS
later, when you'll have a real driver.
>> > > v2 => v3:
>> > > - Ensure DT actually reflects h/w
>> > > - i.e. Nodes should not contain a mishmash of different IP
>> > > blocks, but should identify related h/w. In the current
>> > > example we use interconnects
>> > > - Change naming from clkdomain to clk-always-on
>> > > - Place "do not abuse" warning in documentation
>> > >
>> > > v1 => v2:
>> > > - Turned the ST specific driver into a generic one
>> > >
>> > > Hardware can have a bunch of clocks which must not be turned off.
>> > > If drivers a) fail to obtain a reference to any of these or b) give
>> > > up a previously obtained reference during suspend, the common clk
>> > > framework will attempt to turn them off and the hardware will
>> > > subsequently die. The only way to recover from this failure is to
>> > > restart.
>> > >
>> > > To avoid either of these two scenarios from catastrophically
>> > > disabling the running system we have implemented a clock domain
>> > > where clocks are consumed and references are taken, thus preventing
>> > > them from being shut down by the framework.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lguest: simplify lguest_iret
Denys Vlasenko writes:
> On 03/23/2015 04:30 AM, Rusty Russell wrote:
>> + * They may be about to iret, where they asked us never to
>> + * deliver interrupts. In this case, we can emulate that iret
>> + * then immediately deliver the interrupt. This is bascially
>> + * a noop: the iret would pop the interrupt frame and restore
>> + * eflags, and then we'd set it up again. So just restore the
>> + * eflags word and jump straight to the handler in this case.
>> */
>> +if (cpu->regs->eip >= cpu->lg->noirq_start &&
>> +(cpu->regs->eip < cpu->lg->noirq_end)) {
>> +restore_eflags(cpu);
>
> In truth, this is not _exactly_ true for irets to CPL3.
>
> If a new interrupt comes right after iret, then
> a new transition to CPL0 will happen.
>
> This means ss:esp will be loaded from tss.ss0:tss.sp0.
>
> Meaning, that the new iret frame may be in a different place
> than the one which was used by iret.
True. We could check the to-be-restored-CPL and reset the sp. Instead,
I've added this comment:
/*
* They may be about to iret, where they asked us never to
* deliver interrupts. In this case, we can emulate that iret
* then immediately deliver the interrupt. This is basically
* a noop: the iret would pop the interrupt frame and restore
* eflags, and then we'd set it up again. So just restore the
* eflags word and jump straight to the handler in this case.
*
* Denys Vlasenko points out that this isn't quite right: if
* the iret was returning to userspace, then that interrupt
* would reset the stack pointer (which the Guest told us
* about via LHCALL_SET_STACK). But unless the Guest is being
* *really* weird, that will be the same as the current stack
* anyway.
*/
> There is no good reason for CPL0 code to move iret frame around,
> but who knows. As an example, look what 32-bit Linux kernel does
> with NMI iret frames... it's mind bending.
Fortunately, lguest is allergic to NMIs :)
Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] Add virtio-input driver.
Gerd Hoffmann writes: > virtio-input is basically evdev-events-over-virtio, so this driver isn't > much more than reading configuration from config space and forwarding > incoming events to the linux input layer. > > Signed-off-by: Gerd Hoffmann Is the input layer sane? I've never dealt with it, so I don't know. What's it used for? Imagine a future virtio standard which incorporates this. And a Windows or FreeBSD implementation of the device and or driver. How ugly would they be? Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Documentation:Chinese translation of Documentation/arm64/legacy_instructions.txt
From: Fu Wei
This is a Chinese translated version of
Documentation/arm64/legacy_instructions.txt
It is based on the modifications of Documentation/arm64/legacy_instructions.txt
in submission:
"587064b6", "bd35a4ad", "2d888f48", "c852f320".
Signed-off-by: Fu Wei
---
Documentation/zh_CN/arm64/legacy_instructions.txt | 72 +++
1 file changed, 72 insertions(+)
diff --git a/Documentation/zh_CN/arm64/legacy_instructions.txt
b/Documentation/zh_CN/arm64/legacy_instructions.txt
new file mode 100644
index 000..75b11bf
--- /dev/null
+++ b/Documentation/zh_CN/arm64/legacy_instructions.txt
@@ -0,0 +1,72 @@
+Chinese translated version of Documentation/arm64/legacy_instructions.txt
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Punit Agrawal
+Suzuki K. Poulose
+Chinese maintainer: Fu Wei
+-
+Documentation/arm64/legacy_instructions.txt 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+
+本文翻译提交时的 Git 检出点为： bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
+
+英文版维护者： Punit Agrawal
+Suzuki K. Poulose
+中文版维护者： 傅炜 Fu Wei
+中文版翻译者： 傅炜 Fu Wei
+中文版校译者： 傅炜 Fu Wei
+
+以下为正文
+-
+Linux 内核在 arm64 上的移植提供了一个基础框架，以支持构架中正在被淘汰或已废弃指令的模拟执行。
+这个基础框架的代码使用未定义指令钩子（hooks）来支持模拟。如果指令存在，它也允许在硬件中启用该指令。
+
+模拟模式可通过写 sysctl 节点（/proc/sys/abi）来控制。
+不同的执行方式及 sysctl 节点的相应值，解释如下：
+
+* Undef（未定义）
+ 值： 0
+ 产生未定义指令终止异常。它是那些构架中已废弃的指令，如 SWP，的默认处理方式。
+
+* Emulate（模拟）
+ 值： 1
+ 使用软件模拟方式。为解决软件迁移问题，这种模拟指令模式的使用是被跟踪的，并会发出速率限制警告。
+ 它是那些构架中正在被淘汰的指令，如 CP15 barriers（隔离指令），的默认处理方式。
+
+* Hardware Execution（硬件执行）
+ 值： 2
+ 虽然标记为正在被淘汰，但一些实现可能提供硬件执行这些指令的使能/禁用操作。
+ 使用硬件执行一般会有更好的性能，但将无法收集运行时对正被淘汰指令的使用统计数据。
+
+默认执行模式依赖于指令在构架中状态。正在被淘汰的指令应该以模拟（Emulate）作为默认模式，
+而已废弃的指令必须默认使用未定义（Undef）模式
+
+注意：指令模拟可能无法应对所有情况。更多详情请参考单独的指令注释。
+
+受支持的遗留指令
+-
+* SWP{B}
+节点: /proc/sys/abi/swp
+状态: 已废弃
+默认执行方式: Undef (0)
+
+* CP15 Barriers
+节点: /proc/sys/abi/cp15_barrier
+状态: 正被淘汰，不推荐使用
+默认执行方式: Emulate (1)
+
+* SETEND
+节点: /proc/sys/abi/setend
+状态: 正被淘汰，不推荐使用
+默认执行方式: Emulate (1)*
+注：为了使能这个特性，所有系统中的 CPU 必须在 EL0 支持混合字节序。
+如果一个新的 CPU （不支持混合字节序） 在使能这个特性后被热插入系统，
+该应用则可能出现不可预期的结果。
--
1.8.3.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] mm/memory-failure.c: define page types for action_result() in one place
On Thu, 19 Mar 2015, Naoya Horiguchi wrote:
> This cleanup patch moves all strings passed to action_result() into a single
> array action_page_type so that a reader can easily find which kind of action
> results are possible. And this patch also fixes the odd lines to be printed
> out, like "unknown page state page" or "free buddy, 2nd try page".
>
> Signed-off-by: Naoya Horiguchi
> ---
> mm/memory-failure.c | 107
> +---
> 1 file changed, 76 insertions(+), 31 deletions(-)
>
> diff --git v3.19.orig/mm/memory-failure.c v3.19/mm/memory-failure.c
> index d487f8dc6d39..afb740e1c8b0 100644
> --- v3.19.orig/mm/memory-failure.c
> +++ v3.19/mm/memory-failure.c
> @@ -521,6 +521,52 @@ static const char *action_name[] = {
> [RECOVERED] = "Recovered",
> };
>
> +enum page_type {
> + KERNEL,
> + KERNEL_HIGH_ORDER,
> + SLAB,
> + DIFFERENT_COMPOUND,
> + POISONED_HUGE,
> + HUGE,
> + FREE_HUGE,
> + UNMAP_FAILED,
> + DIRTY_SWAPCACHE,
> + CLEAN_SWAPCACHE,
> + DIRTY_MLOCKED_LRU,
> + CLEAN_MLOCKED_LRU,
> + DIRTY_UNEVICTABLE_LRU,
> + CLEAN_UNEVICTABLE_LRU,
> + DIRTY_LRU,
> + CLEAN_LRU,
> + TRUNCATED_LRU,
> + BUDDY,
> + BUDDY_2ND,
> + UNKNOWN,
> +};
> +
I like the patch because of the consistency in output and think it's worth
the extra 1% .text size.
My only concern is the generic naming of the enum members.
memory-failure.c is already an offender with "enum outcome" and the naming
of its members.
Would you mind renaming these to be prefixed with "MSG_"?
These enums should be anonymous, too, nothing is referencing enum outcome
or your new enum page_type.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] dt-bindings: brcm: rationalize Broadcom documentation naming
On 03/20/2015 08:06 PM, Scott Branden wrote:
> This patchset attempts to standardize the naming of dt-bindings
> documents based on the Broadcom vendor prefix of brcm.
>
> Although there are no guidelines currently present for how to name
> the dt-bindings document the "vendor,binding.txt" style is in use by
> some of the other vendors.
>
> Acked-by: Lee Jones
> Acked-by: Florian Fainelli
> Acked-by: Gregory Fong
> Acked-by: Stephen Warren
> Signed-off-by: Scott Branden
Version history would be nice...
Who did you want to apply this? I can, but I'm worried about merge
conflicts here. Hopefully, you're not also doing lots of changes to
existing bindings.
Rob
> ---
> .../arm/bcm/{brcm,bcm11351-cpu-method => brcm,bcm11351-cpu-method.txt}| 0
> .../devicetree/bindings/arm/bcm/{bcm11351.txt => brcm,bcm11351.txt} | 0
> .../devicetree/bindings/arm/bcm/{bcm21664.txt => brcm,bcm21664.txt} | 0
> .../devicetree/bindings/arm/{bcm2835.txt => bcm/brcm,bcm2835.txt} | 0
> .../devicetree/bindings/arm/{bcm4708.txt => bcm/brcm,bcm4708.txt} | 0
> .../devicetree/bindings/arm/bcm/{bcm63138.txt => brcm,bcm63138.txt} | 0
> .../devicetree/bindings/arm/{brcm-brcmstb.txt => bcm/brcm,brcmstb.txt}| 0
> Documentation/devicetree/bindings/arm/bcm/{cygnus.txt => brcm,cygnus.txt} | 0
> Documentation/devicetree/bindings/bus/{bcma.txt => brcm,bus-axi.txt} | 0
> .../devicetree/bindings/clock/{bcm-kona-clock.txt => brcm,kona-ccu.txt} | 0
> .../devicetree/bindings/dma/{bcm2835-dma.txt => brcm,bcm2835-dma.txt} | 0
> .../devicetree/bindings/gpio/{gpio-bcm-kona.txt => brcm,kona-gpio.txt}| 0
> .../devicetree/bindings/i2c/{i2c-bcm-kona.txt => brcm,kona-i2c.txt} | 0
> Documentation/devicetree/bindings/mfd/{bcm590xx.txt => brcm,bcm59056.txt} | 0
> .../bindings/mips/brcm/{bcm3384-intc.txt => brcm,bcm3384-intc.txt}| 0
> Documentation/devicetree/bindings/mips/brcm/{bmips.txt => brcm,bmips.txt} | 0
> .../devicetree/bindings/mips/brcm/{cm-dsl.txt => brcm,cm-dsl.txt} | 0
> Documentation/devicetree/bindings/misc/{smc.txt => brcm,kona-smc.txt} | 0
> .../devicetree/bindings/mmc/{kona-sdhci.txt => brcm,kona-sdhci.txt} | 0
> .../bindings/net/{broadcom-sf2.txt => brcm,bcm7445-switch-v4.0.txt} | 0
> .../devicetree/bindings/net/{broadcom-bcmgenet.txt => brcm,bcmgenet.txt} | 0
> .../bindings/net/{broadcom-systemport.txt => brcm,systemport.txt} | 0
> .../bindings/net/{broadcom-mdio-unimac.txt => brcm,unimac-mdio.txt} | 0
> .../devicetree/bindings/phy/{bcm-phy.txt => brcm,kona-usb2-phy.txt} | 0
> .../devicetree/bindings/pwm/{bcm-kona-pwm.txt => brcm,kona-pwm.txt} | 0
> .../{arm/bcm/kona-resetmgr.txt => reset/brcm,bcm21664-resetmgr.txt} | 0
> .../bindings/serial/{bcm63xx-uart.txt => brcm,bcm6345-uart.txt} | 0
> .../devicetree/bindings/sound/{bcm2835-i2s.txt => brcm,bcm2835-i2s.txt} | 0
> .../bindings/{arm/bcm/kona-timer.txt => timer/brcm,kona-timer.txt}| 0
> .../devicetree/bindings/{mips/brcm/usb.txt => usb/brcm,bcm3384-usb.txt} | 0
> .../bindings/{arm/bcm/kona-wdt.txt => watchdog/brcm,kona-wdt.txt} | 0
> 31 files changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/arm/bcm/{brcm,bcm11351-cpu-method
> => brcm,bcm11351-cpu-method.txt} (100%)
> rename Documentation/devicetree/bindings/arm/bcm/{bcm11351.txt =>
> brcm,bcm11351.txt} (100%)
> rename Documentation/devicetree/bindings/arm/bcm/{bcm21664.txt =>
> brcm,bcm21664.txt} (100%)
> rename Documentation/devicetree/bindings/arm/{bcm2835.txt =>
> bcm/brcm,bcm2835.txt} (100%)
> rename Documentation/devicetree/bindings/arm/{bcm4708.txt =>
> bcm/brcm,bcm4708.txt} (100%)
> rename Documentation/devicetree/bindings/arm/bcm/{bcm63138.txt =>
> brcm,bcm63138.txt} (100%)
> rename Documentation/devicetree/bindings/arm/{brcm-brcmstb.txt =>
> bcm/brcm,brcmstb.txt} (100%)
> rename Documentation/devicetree/bindings/arm/bcm/{cygnus.txt =>
> brcm,cygnus.txt} (100%)
> rename Documentation/devicetree/bindings/bus/{bcma.txt => brcm,bus-axi.txt}
> (100%)
> rename Documentation/devicetree/bindings/clock/{bcm-kona-clock.txt =>
> brcm,kona-ccu.txt} (100%)
> rename Documentation/devicetree/bindings/dma/{bcm2835-dma.txt =>
> brcm,bcm2835-dma.txt} (100%)
> rename Documentation/devicetree/bindings/gpio/{gpio-bcm-kona.txt =>
> brcm,kona-gpio.txt} (100%)
> rename Documentation/devicetree/bindings/i2c/{i2c-bcm-kona.txt =>
> brcm,kona-i2c.txt} (100%)
> rename Documentation/devicetree/bindings/mfd/{bcm590xx.txt =>
> brcm,bcm59056.txt} (100%)
> rename Documentation/devicetree/bindings/mips/brcm/{bcm3384-intc.txt =>
> brcm,bcm3384-intc.txt} (100%)
> rename Documentation/devicetree/bindings/mips/brcm/{bmips.txt =>
> brcm,bmips.txt} (100%)
> rename Documentation/devicetree/bindings/mips/brcm/{cm-dsl.txt =>
> brcm,cm-dsl.txt} (100%)
> rename Documentation/devicetree/bindings/misc/{smc.txt =>
Re: [patch v11 00/23] Introduce ACPI for ARM64 based on ACPI 5.1
On Tue, Mar 24, 2015 at 10:02 PM, Hanjun Guo wrote: > Some fixes since last version: > > - Add a patch 19/23 for disabling ACPI for Xen on ARM64 for now to fix >compile errors on XEN ACPI, Stefano and Julien are ok with this >temporary solution. > - Add patch "ARM64 / ACPI: Don't unflatten device tree if acpi=force >is passed", which will fix the problem that the device tree will >be unflattened even if acpi=force passed, that will not obey the >policy. > - update patch "irqchip: Add GICv2 specific ACPI boot support", >which will cause compile error on i386 with both DT and ACPI >enabled: > >All error/warnings: > > In file included from include/linux/acpi_irq.h:4:0, > from drivers/irqchip/irqchip.c:11: > arch/x86/include/asm/irq.h:35:8: error: unknown type name 'bool' > extern bool handle_irq(unsigned irq, struct pt_regs *regs); > ^ > arch/x86/include/asm/irq.h:35:45: warning: 'struct pt_regs' declared > inside parameter list > extern bool handle_irq(unsigned irq, struct pt_regs *regs); > ^ > arch/x86/include/asm/irq.h:35:45: warning: its scope is only this > definition or declaration, which is probably not what you want > > >That's because of I include the in , >and will be put on the top of all head files, >so use instead of in acpi_irq.h (in >, it will include before include >), this is the only update for this patch. > > Lorenzo will send some cleanup patches on top of this one soon. > > Thanks > Hanjun > > Al Stone (4): > ARM64 / ACPI: Get RSDP and ACPI boot-time tables > ARM64 / ACPI: Introduce early_param "acpi=" to enable/disable ACPI > ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on > ARM64 > ARM64 / ACPI: additions of ACPI documentation for arm64 > > Graeme Gregory (6): > ACPI: add arm64 to the platforms that use ioremap > ACPI / sleep: Introduce CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT > ARM64 / ACPI: If we chose to boot from acpi then disable FDT > ARM64 / ACPI: Get PSCI flags in FADT for PSCI init > ARM64 / ACPI: Enable ARM64 in Kconfig > Documentation: ACPI for ARM64 > > Hanjun Guo (10): > ACPI / table: Use pr_debug() instead of pr_info() for MADT table > scanning > ARM64 / ACPI: Introduce PCI stub functions for ACPI > ACPI / table: Print GIC information when MADT is parsed > ARM64 / ACPI: Parse MADT for SMP initialization > ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID > ACPI / processor: Make it possible to get CPU hardware ID via GICC > ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi > clocksource / arch_timer: Parse GTDT to initialize arch timer > XEN / ACPI: Make XEN ACPI depend on X86 > ARM64 / ACPI: Don't unflatten device tree if acpi=force is passed > > Mark Salter (2): > ARM64: allow late use of early_ioremap > ACPI: fix acpi_os_ioremap for arm64 > > Tomasz Nowicki (1): > irqchip: Add GICv2 specific ACPI boot support On APM mustang and qemu-system-aarch64 with 'acpi=force', Tested-by: Ming Lei Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [git pull] drm fixes
On 03/25/2015 at 12:54 AM, Josh Boyer wrote: On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote: On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer wrote: On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote: On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer wrote: On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote: On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter wrote: On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote: On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer wrote: Xi Ruoyao (1): drm/i915: Ensure plane->state->fb stays in sync with plane->fb Turns out to be that commit. git bisect start 'drivers/gpu/drm/i915/' # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344 # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5 git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure plane->state->fb stays in sync with plane->fb git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure plane->state->fb stays in sync with plane->fb Doing a straight revert on top of 4.0-rc5 makes things work again, albeit with the WARN_ON(obj->frontbuffer_bits) splat still being there. Can you please test the tip of drm-fixes: commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1 Author: Daniel Vetter Date: Fri Feb 27 12:58:13 2015 +0100 drm: Fixup racy refcounting in plane_force_disable http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8218c3f4df3bb1c637c17552405039a6dd3c1ee1 Because fumble that patch didn't make it to drm-fixes a while ago and instead landed in drm-next. That seems to have helped with totally different issues a macbook I have was seeing. However, it still doesn't fix the issue with the Celeron based NUC machine. I built a kernel based on Linus' latest tree as of this morning, without reverting 319c1d4 and adding the commit you pointed to. The NUC still won't boot without HDMI connected. With HDMI connected I still see the trace below. If I do the blacklist and then insmod dance with HDMI unplugged it shows the same spew I reported yesterday which starts with the same backtrace. I'll try building a kernel with 319c1d4 reverted + your patch. I suspect things will work fine with that combination because the two issues are unrelated. Can you please boot with drm.debug=0xff for the below case and grab complete dmesg? There'll be a lot of crap in the logs, you might need to blow up the logbuf size massively. But that log should contain everything I need to figure out where that framebuffer we're blowing up on is going. I provided both with HDMI attached and without (via insmod). If you want them emailed directly let me know, but they were large. Boot with drm.debug=0xff and HDMI connected: https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt Boot with drm.debug=0xff without HDMI connected and i915 loaded via manual insmod after boot: https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt Here's one more from the macbook I mentioned. It's showing the same kref.h splat: https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt Ok there's at least one fixup for which we've failed to apply when porting the fb refcounting fix from -next. Can you please cherry-pick commit f55548b5af87ebfc586ca75748947f1c1b1a4a52 Author: Damien Lespiau Date: Thu Feb 5 18:30:20 2015 + drm/i915: Don't try to reference the fb in get_initial_plane_config() From linux-next? Yes, building now. Will let you know as soon as I test it on both machines. OK, with that commit applied I no longer get the kref.h splat and the NUC machine boots headless. I still see the backtrace below on both the NUC and the macbook. I have a copy of it with drm.debug=0xff from the NUC here: https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt Getting better at least :). Ok thanks for testing. I'll look at that one tomorrow, wasted too much time with trying to resurrect a few machines that should have matched the common parts of what goes wrong here. Jani, can you please cherry-pick the above commit to -fixes? Actually add Jani this time around ... -Daniel One more question: Is the frontbuffer_bits splat now also gone? That was the one I have no clue about, but since somewhere around 4.0-rc it started poppping up in a few places ... Thus far it was always the canary for some other bug though. As far as I can tell, it's gone. I don't see it on any of my i915 machines running the kernel with those two patches. I'll
Re: [PATCH v4 2/3] leds: ktd2692: add device tree bindings for ktd2692
On 03/25/2015 07:00 AM, Ingi Kim wrote:
This patch adds the device tree bindings for ktd2692 flash LEDs.
Add optional properties 'flash-timeout-us' to control flash timeout
and 'vin-supply' for flash-led regulator
Signed-off-by: Ingi Kim
---
.../devicetree/bindings/leds/leds-ktd2692.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
new file mode 100644
index 000..f78512f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
@@ -0,0 +1,33 @@
+* Kinetic Technologies - KTD2692 Flash LED Driver
+
+KTD2692 is the ideal power solution for high-power flash LEDs.
+It uses ExpressWire single-wire programming for maximum flexibility.
+
+The ExpressWire interface through CTRL pin can control LED on/off and
+enable/disable the IC, Movie(max 1/3 of Flash current) / Flash mode current,
+Flash timeout, LVP(low voltage protection).
+
+Also, When the AUX pin is pulled high while CTRL pin is high,
+LED current will be ramped up to the flash-mode current level.
+
+Required properties:
+ - compatible: "kinetic,ktd2692"
+ - ctrl-gpio, aux-gpio : gpio pins in order control ktd2692 flash led.
+ There is an internal 300kOhm pull-down resistor at each pin
+ - vin-supply : "vin" LED supply (2.7V to 5.5V)
+ See Documentation/devicetree/bindings/regulator/regulator.txt
+
Above bindings are not that readable to me. Remove the tab spaces before
properties.
+Optional property:
+ - flash-timeout-us : Maximum flash timeout in microseconds.
+ flash timeout ranges from 0 to 1835000us and
+ default is 1049000us.
+
+Example:
+
+flash-led {
+ compatible = "kinetic,ktd2692";
+ ctrl-gpio = < 1 0>;
+ aux-gpio = < 2 0>;
+ flash-timeout-us = <1835000>;
+ vin-supply = <>;
+};
--
Varka Bhadram
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] leds: Add ktd2692 flash LED driver
On 03/25/2015 07:00 AM, Ingi Kim wrote:
This patch adds a driver to support the ktd2692 flash LEDs.
ktd2692 can control flash current by ExpressWire interface.
Signed-off-by: Ingi Kim
---
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-ktd2692.c | 412
3 files changed, 422 insertions(+)
create mode 100644 drivers/leds/leds-ktd2692.c
(...)
+static int ktd2692_parse_dt(struct ktd2692_context *led, struct device *dev,
+ u32 *flash_timeout_us)
+{
+ struct device_node *np = dev->of_node;
+
Unnecessary one line space..
+ int ret;
+
+ led->ctrl_gpio = of_get_named_gpio(np, "ctrl-gpio", 0);
+ if (!gpio_is_valid(led->ctrl_gpio)) {
+ dev_err(dev, "no ctrl-gpio property found\n");
+ return -EINVAL;
+ }
+
+ led->aux_gpio = of_get_named_gpio(np, "aux-gpio", 0);
+ if (!gpio_is_valid(led->aux_gpio)) {
+ dev_err(dev, "no aux-gpio property found\n");
+ return -EINVAL;
+ }
+
+ ret = devm_gpio_request_one(dev, led->ctrl_gpio,
+ GPIOF_OPEN_SOURCE, "ctrl-gpio");
+ if (ret) {
+ dev_err(dev, "failed to request ctrl-gpio %d error %d\n",
+ led->ctrl_gpio, ret);
+ return ret;
+ }
+
+ ret = devm_gpio_request_one(dev, led->aux_gpio,
+ GPIOF_OPEN_SOURCE, "aux-gpio");
+ if (ret) {
+ dev_err(dev, "failed to request aux-gpio %d error %d\n",
+ led->aux_gpio, ret);
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "flash-timeout-us", flash_timeout_us);
+ /* default setting */
+ if (ret)
+ *flash_timeout_us = KTD2692_FLASH_MODE_TIMEOUT_DEFAULT_US;
+
+ return 0;
+}
+
+static const struct led_flash_ops flash_ops = {
+ .strobe_set = ktd2692_led_flash_strobe_set,
+ .timeout_set = ktd2692_led_flash_timeout_set,
+};
+
+static int ktd2692_probe(struct platform_device *pdev)
+{
+ struct ktd2692_context *led;
+ struct led_classdev *led_cdev;
+ struct led_classdev_flash *fled_cdev;
+ struct led_flash_setting flash_timeout;
+ u32 flash_timeout_us;
+ int ret;
+
+ led = devm_kzalloc(>dev, sizeof(*led), GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ if (!pdev->dev.of_node)
+ return -ENXIO;
+
Above operation dt related. So if you do that in ktd2692_parse_dt(), it will be
good
+ fled_cdev = >fled_cdev;
+ led_cdev = _cdev->led_cdev;
+
+ ret = ktd2692_parse_dt(led, >dev, _timeout_us);
+ if (ret)
+ return ret;
+
+ led->regulator = devm_regulator_get(>dev, "vin");
+ if (IS_ERR(led->regulator)) {
+ dev_err(>dev, "regulator get failed\n");
+ return PTR_ERR(led->regulator);
+ }
+
+ ktd2692_init_flash_timeout(flash_timeout_us, _timeout);
+
+ fled_cdev->timeout = flash_timeout;
+ fled_cdev->ops = _ops;
+
+ led_cdev->name = KTD2692_DEFAULT_NAME;
+ led_cdev->brightness_set = ktd2692_led_brightness_set;
+ led_cdev->brightness_set_sync = ktd2692_led_brightness_set_sync;
+ led_cdev->flags |= LED_CORE_SUSPENDRESUME;
+ led_cdev->flags |= LED_DEV_CAP_FLASH;
+
+ mutex_init(>lock);
+ INIT_WORK(>work_brightness_set, ktd2692_brightness_set_work);
+
+ platform_set_drvdata(pdev, led);
+
+ ret = led_classdev_flash_register(>dev, fled_cdev);
+ if (ret) {
+ dev_err(>dev, "can't register LED %s\n", led_cdev->name);
+ cancel_work_sync(>work_brightness_set);
Is the above API is correct to use in this place.?
cancel_work_sync — cancel a work and wait for it to finish...
Work is not yet scheduled..?
What about mutex destroy..?
+ return ret;
+ }
+
+ ktd2692_setup(led);
+ ktd2692_led_regulator_enable(led);
+
+ return 0;
+}
+
+static int ktd2692_remove(struct platform_device *pdev)
+{
+ struct ktd2692_context *led = platform_get_drvdata(pdev);
+
+ ktd2692_led_regulator_disable(led);
+ led_classdev_flash_unregister(>fled_cdev);
+ cancel_work_sync(>work_brightness_set);
+
+ mutex_destroy(>lock);
+
+ return 0;
+}
+
+static const struct of_device_id ktd2692_match[] = {
+ { .compatible = "kinetic,ktd2692", },
+ { /* sentinel */ },
+};
+
+static struct platform_driver ktd2692_driver = {
+ .driver = {
+ .name = "leds-ktd2692",
+ .of_match_table = ktd2692_match,
+ },
+ .probe = ktd2692_probe,
+ .remove = ktd2692_remove,
+};
+
+module_platform_driver(ktd2692_driver);
+
+MODULE_AUTHOR("Ingi Kim ");
+MODULE_DESCRIPTION("Kinetic KTD2692 LED driver");
+MODULE_LICENSE("GPL
Re: [PATCH v11 21/21] brd: Rename XIP to DAX
On Tue, Mar 24, 2015 at 11:50:47AM -0700, Matt Mullins wrote: > On Thu, Sep 25, 2014 at 04:33:38PM -0400, Matthew Wilcox wrote: > > --- a/drivers/block/brd.c > > +++ b/drivers/block/brd.c > > @@ -97,13 +97,13 @@ static struct page *brd_insert_page(struct brd_device > > *brd, sector_t sector) > > * Must use NOIO because we don't want to recurse back into the > > * block or filesystem layers from page reclaim. > > * > > -* Cannot support XIP and highmem, because our ->direct_access > > -* routine for XIP must return memory that is always addressable. > > -* If XIP was reworked to use pfns and kmap throughout, this > > +* Cannot support DAX and highmem, because our ->direct_access > > +* routine for DAX must return memory that is always addressable. > > +* If DAX was reworked to use pfns and kmap throughout, this > > * restriction might be able to be lifted. > > */ > > gfp_flags = GFP_NOIO | __GFP_ZERO; > > -#ifndef CONFIG_BLK_DEV_XIP > > +#ifndef CONFIG_BLK_DEV_RAM_DAX > > gfp_flags |= __GFP_HIGHMEM; > > #endif > > page = alloc_page(gfp_flags); > > We're also developing a user of direct_access, and we ended up with some > questions about the sleeping guarantees of the direct_access API. > > Since brd is currently the only (x86) implementation of DAX in Linus's tree, > I've been testing against that. We noticed that the brd implementation of DAX > can call into alloc_page() with __GFP_WAIT if we call direct_access() on a > page > that has not yet been allocated. This is compounded by the fact that brd does > not support size > PAGE_SIZE (and thus I call bdev_direct_access() on each > use), > though the limitation makes sense -- I shouldn't expect the brd driver to be > able to allocate a gigabyte of contiguous memory. > > The potential sleeping behavior was somewhat surprising to me, as I would > expect > the NV-DIMM device implementation to simply offset the pfn at which the device > is located rather than perform a memory allocation. What are the guaranteed > and/or expected contexts from which direct_access() can be safely called? I'll defer to whatever Willy and others say, but I my understanding is that .direct_access has the same semantics as submitting an IO. i.e. the intent of .direct_access is to set up direct access to the memory and then return a pfn you can use to access it and hence what operations are performed are backing device dependent. Hence for some devices it might simply be an offset->pfn calculation and immediately return, others might have to play mapping games (maybe talk to an iommu?) and others, like brd, may have to allocate backing store from some separate storage pool before access can be granted. Expect that .direct_access can sleep, and you'll be fine. > While I can easily punt this usage to a work queue (that's what we already do > for devices where we need to submit a bio), part of our desire to use > direct_access is to avoid additional latency. brd is intended for testing purposes only because it isn't persistent. However, we need something we can develop against and imost of us don't have real hardware - that's what brd+dax is for. If you want brd+dax to act like NVDIMM based persistent memory, populate all the backing pages in the ram disk before running your tests by writing zeros to the entire block device. Then the backing store will be fully allocated, and .direct_access will never do allocation until you flush the backing store... 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/
Re: [PATCH 1/2] Support PCU power metrics in turbostat
On Tue, Mar 24, 2015 at 05:20:13PM -0400, Len Brown wrote: > > > On Thu, Nov 13, 2014 at 6:19 PM, Andi Kleen wrote: > > From: Andi Kleen > > > > Add support for reading PCU power metrics on Sandy Bridge / Ivy Bridge EP > > and Haswell Server in turbostat. This is done using the perf ABI, > > using the perf uncore driver. This requires the kernel to > > have uncore perf driver support. > > What happens if kernel doesn't include that support? The data is not displayed. > > The user has to specify the event group using a new -x option. All > > more sensible option characters were already taken. When -x is > > not specified no behavior changes. > > I'm concerned that turbostat cmdline is getting too complicated, > and this makes that more the case. Modern computers are complicated. No way around it. > > However this currently runs into a problem with the uncore > > driver that only makes us able to monitor a single band. > > Disabled until this is fixed. BTW this is fixed. Will update. > > Custom user metrics would be also possible. > > > > The event resolution code is derived from the jevents library > > (parts of pmu-tools, http://github.com/andikleen/pmu-tools) > > and is BSD licensed. > > can we put BSD licensed code into utilities that are in the linux > kernel git tree? I think so. There are already some. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: performance changes on d4b4c2cd: 37.6% fsmark.files_per_sec, -15.9% fsmark.files_per_sec, and few more
On Wed, 18 Mar 2015 13:03:19 +0800 Yuanahn Liu wrote: > Hi, > > FYI, we noticed performance changes on `fsmark.files_per_sec' by > d4b4c2cdffab86f5c7594c44635286a6d277d5c6: > > > commit d4b4c2cdffab86f5c7594c44635286a6d277d5c6 > > Author: s...@kernel.org > > AuthorDate: Mon Dec 15 12:57:03 2014 +1100 > > Commit: NeilBrown > > CommitDate: Wed Mar 4 13:40:17 2015 +1100 > > > > RAID5: batch adjacent full stripe write Thanks a lot for this one too! Generally positive, with the only regressions on NoSync tests. Maybe the same cause? Again, > 7 ± 5% +37.6% 10 ± 6% > fsmark.time.percent_of_cpu_this_job_got and > 9 ± 0% -14.8% 7 ± 6% > fsmark.time.percent_of_cpu_this_job_got are a bit confusing - really less than 10% of a CPU ?? Thanks, NeilBrown > > c1dfe87e41d9c2926fe92f803f02c733ddbccf0b > d4b4c2cdffab86f5c7594c44635286a6d277d5c6 > > > run time(m) metric_value ±stddev run time(m) metric_value > ±stddev change testbox/benchmark/sub-testcase > --- -- --- -- > -- > 4 15.3 33.525 ±3.0% 6 11.1 46.133 > ±5.0% 37.6% ivb44/fsmark/1x-1t-3HDD-RAID5-xfs-4M-120G-NoSync > 3 0.5 262.800 ±1.5% 3 0.4 307.367 > ±1.2% 17.0% ivb44/fsmark/1x-1t-4BRD_12G-RAID5-f2fs-4M-30G-NoSync > 3 0.5 289.900 ±0.3% 3 0.4 323.367 > ±2.4% 11.5% ivb44/fsmark/1x-64t-4BRD_12G-RAID5-f2fs-4M-30G-NoSync > 3 0.5 325.667 ±2.2% 3 0.5 358.800 > ±1.8% 10.2% ivb44/fsmark/1x-64t-4BRD_12G-RAID5-ext4-4M-30G-NoSync > 3 0.6 216.100 ±0.4% 3 0.6 230.100 > ±0.4% 6.5% > ivb44/fsmark/1x-64t-4BRD_12G-RAID5-f2fs-4M-30G-fsyncBeforeClose > 3 0.5 309.900 ±0.3% 3 0.5 328.500 > ±1.1% 6.0% ivb44/fsmark/1x-64t-4BRD_12G-RAID5-xfs-4M-30G-NoSync > > 3 13.8 37.000 ±0.2% 3 16.5 31.100 > ±0.3% -15.9% ivb44/fsmark/1x-1t-3HDD-RAID5-f2fs-4M-120G-NoSync > > NOTE: here are some more info about those test parameters for you to > understand the testcase better: > > 1x : where 'x' means iterations or loop, corresponding to the 'L' > option of fsmark > 64t: where 't' means thread > 4M : means the single file size, corresponding to the '-s' option of > fsmark > 120G, 30G: means the total test size > > 4BRD_12G: BRD is the ramdisk, where '4' means 4 ramdisk, and where > '12G' means > the size of one ramdisk. So, it would be 48G in total. And we > made a > raid on those ramdisk. > > > And FYI, here I listed more detailed changes for the maximal postive and > negtive changes. > > > more detailed changes about ivb44/fsmark/1x-1t-3HDD-RAID5-xfs-4M-120G-NoSync > - > > c1dfe87e41d9c292 d4b4c2cdffab86f5c7594c4463 > -- > %stddev %change %stddev > \ |\ > 33.53 ± 3% +37.6% 46.13 ± 4% fsmark.files_per_sec >916 ± 3% -27.2%667 ± 5% fsmark.time.elapsed_time.max >916 ± 3% -27.2%667 ± 5% fsmark.time.elapsed_time > 7 ± 5% +37.6% 10 ± 6% > fsmark.time.percent_of_cpu_this_job_got > 92097 ± 2% -23.1% 70865 ± 4% > fsmark.time.voluntary_context_switches > 0.04 ± 42%+681.0% 0.27 ± 22% turbostat.Pkg%pc3 > 716062 ± 3% -82.7% 124210 ± 21% cpuidle.C1-IVT.usage > 6.883e+08 ± 2% -86.8% 91146705 ± 34% cpuidle.C1-IVT.time > 0.04 ± 30%+145.8% 0.10 ± 25% turbostat.CPU%c3 >404 ± 16% -58.4%168 ± 14% cpuidle.POLL.usage >159 ± 47%+179.5%444 ± 23% > proc-vmstat.kswapd_low_wmark_hit_quickly > 11133 ± 23%+100.3% 22298 ± 30% cpuidle.C3-IVT.usage > 10286681 ± 27% +95.6% 20116924 ± 27% cpuidle.C3-IVT.time > 7.92 ± 16% +77.4% 14.05 ± 6% turbostat.Pkg%pc6 > 4.93 ± 3% -38.6% 3.03 ± 2% turbostat.CPU%c1 >916 ± 3% -27.2%667 ± 5% time.elapsed_time.max >916 ± 3% -27.2%667 ± 5% time.elapsed_time >2137390 ± 3% -26.7%1566752 ± 5% proc-vmstat.pgfault > 7 ± 5% +37.6% 10 ± 6% time.percent_of_cpu_this_job_got > 4.309e+10 ± 3% -26.3% 3.176e+10 ± 5% cpuidle.C6-IVT.time > 49038 ± 2% -23.9% 37334 ± 4% uptime.idle > 1047 ± 2% -23.8%797 ± 4% uptime.boot > 92097
Re: performance changes on 4400755e: 200.0% fsmark.files_per_sec, -18.1% fsmark.files_per_sec, and few more
On Wed, 18 Mar 2015 13:00:30 +0800 Yuanahn Liu wrote: > Hi, > > FYI, we noticed performance changes on `fsmark.files_per_sec' by > 4400755e356f9a2b0b7ceaa02f57b1c7546c3765: > > > commit 4400755e356f9a2b0b7ceaa02f57b1c7546c3765 > > Author: NeilBrown > > AuthorDate: Thu Feb 26 12:47:56 2015 +1100 > > Commit: NeilBrown > > CommitDate: Wed Mar 4 13:40:19 2015 +1100 > > > > md/raid5: allow the stripe_cache to grow and shrink. Thanks a lot for this testing!!! I was wondering how I could do some proper testing of this patch, and you've done it for me :-) The large number of improvements is very encouraging - that is what I was hoping for of course. The few regressions could be a concern. I note that are all NoSync. That seems to suggest that they could just be writing more data. i.e. the data is written a bit earlier (certainly possible) so it happen to introduce more delay I guess I'm not really sure how to interpret NoSync results, and suspect that poor NoSync result don't really reflect much on the underlying block device. Could that be right? Also, I'm a little confused by the fsmark.time.involuntary_context_switches statistic: > 1235 ± 2% -47.5%649 ± 3% > fsmark.time.percent_of_cpu_this_job_got >399 ± 4% -20.0%319 ± 3% > fsmark.time.percent_of_cpu_this_job_got Does that means that the ext4 test changed from 12.4 cpus to 6.4, and that the btrfs test chnages from 4 cpus to 3.2 ??? Or does it just not mean anything? Thanks, NeilBrown > > 26089f4902595a2f64c512066af07af6e82eb096 > 4400755e356f9a2b0b7ceaa02f57b1c7546c3765 > > > run time(m) metric_value ±stddev run time(m) metric_value > ±stddev change testbox/benchmark/sub-testcase > --- -- --- -- > -- > 3 18.6 6.400 ±0.0% 5 9.2 19.200 > ±0.0% 200.0% > ivb44/fsmark/1x-64t-3HDD-RAID5-ext4-4M-40G-fsyncBeforeClose > 3 24.7 6.400 ±0.0% 3 13.7 12.800 > ±0.0% 100.0% > ivb44/fsmark/1x-64t-3HDD-RAID5-f2fs-4M-40G-fsyncBeforeClose > 3 17.5 28.267 ±9.6% 3 12.3 42.833 > ±6.5% 51.5% ivb44/fsmark/1x-64t-3HDD-RAID5-f2fs-4M-120G-NoSync > 3 16.7 30.700 ±1.5% 3 12.6 40.733 > ±2.4% 32.7% ivb44/fsmark/1x-1t-3HDD-RAID5-f2fs-4M-120G-NoSync > 3 29.0 5.867 ±0.8% 5 23.6 7.240 > ±0.7% 23.4% > ivb44/fsmark/1x-1t-3HDD-RAID5-btrfs-4M-40G-fsyncBeforeClose > 3 28.5 6.000 ±0.0% 3 23.2 7.367 > ±0.6% 22.8% > ivb44/fsmark/1x-1t-3HDD-RAID5-f2fs-4M-40G-fsyncBeforeClose > 5 11.7 14.600 ±0.0% 5 9.7 17.500 > ±0.4% 19.9% ivb44/fsmark/1x-1t-3HDD-RAID5-xfs-4M-40G-fsyncBeforeClose > 3 22.4 25.600 ±0.0% 5 17.9 30.120 > ±4.1% 17.7% ivb44/fsmark/1x-64t-3HDD-RAID5-xfs-4M-120G-NoSync > 5 10.8 47.320 ±0.6% 5 9.3 54.820 > ±0.2% 15.8% ivb44/fsmark/1x-1t-3HDD-RAID5-xfs-4M-120G-NoSync > 1 0.5 252.400 ±0.0% 1 0.5 263.300 > ±0.0% 4.3% ivb44/fsmark/1x-1t-4BRD_12G-RAID5-ext4-4M-30G-NoSync > > 3 0.5 273.100 ±4.3% 3 0.6 223.567 > ±6.5% -18.1% ivb44/fsmark/1x-64t-4BRD_12G-RAID5-btrfs-4M-30G-NoSync > 3 8.1 63.133 ±0.5% 3 9.2 55.633 > ±0.2% -11.9% ivb44/fsmark/1x-1t-3HDD-RAID5-btrfs-4M-120G-NoSync > 3 8.2 64.000 ±0.0% 3 9.2 57.600 > ±0.0% -10.0% ivb44/fsmark/1x-64t-3HDD-RAID5-btrfs-4M-120G-NoSync > > > NOTE: here are some more info about those test parameters for you to > understand the testcase better: > > 1x: where 'x' means iterations or loop, corresponding to the 'L' option > of fsmark > 1t, 64t: where 't' means thread > 4M: means the single file size, corresponding to the '-s' option of > fsmark > 40G, 30G, 120G: means the total test size > > 4BRD_12G: BRD is the ramdisk, where '4' means 4 ramdisk, and where > '12G' means > the size of one ramdisk. So, it would be 48G in total. And we > made a > raid on those ramdisk. > > > As you can see from above data, interestingly, all performance > regressions come from btrfs testing. That's why Chris is also > in the cc list, with which just FYI. > > > FYI, here I listed more detailed changes for the maximal postive and negtive > changes. > > more
Re: [PATCH 3.14 00/79] 3.14.37-stable review
On 03/24/2015 08:45 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.14.37 release.
There are 79 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu Mar 26 15:43:19 UTC 2015.
Anything received after that time might be too late.
Build results:
total: 123 pass: 120 fail: 3
Failed builds:
arm:imx_v6_v7_defconfig
arm:multi_v7_defconfig
arm:imx_v4_v5_defconfig
Qemu test results:
total: 30 pass: 30 fail: 0
--
Build error log:
ERROR (phandle_references): Reference to non-existent node or label "swbst_reg"
ERROR (phandle_references): Reference to non-existent node or label "swbst_reg"
ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [arch/arm/boot/dts/imx6dl-sabresd.dtb] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [dtbs] Error 2
Caused by 'ARM: imx6qdl-sabresd: set swbst_reg as vbus's parent reg'
and 'ARM: imx6sl-evk: set swbst_reg as vbus's parent reg'.
swbst_reg was only introduced with commit 4b444bb82fa8 ("ARM: dts:
imx6qdl-sabresd: Add PFUZE100 support"). Unfortunately, that patch
does not apply cleanly.
--
Details are available at http://server.roeck-us.net:8010/builders.
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 3/6] direct-io: add support for write stream IDs
On Tue, Mar 24, 2015 at 09:27:00AM -0600, Jens Axboe wrote:
> Get the streamid from the file, if any, and set it on the bio.
>
> Signed-off-by: Jens Axboe
> ---
> fs/direct-io.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/direct-io.c b/fs/direct-io.c
> index e181b6b2e297..5d2750346451 100644
> --- a/fs/direct-io.c
> +++ b/fs/direct-io.c
> @@ -77,6 +77,7 @@ struct dio_submit {
> int reap_counter; /* rate limit reaping */
> sector_t final_block_in_request;/* doesn't change */
> int boundary; /* prev block is at a boundary */
> + int streamid; /* Write stream ID */
> get_block_t *get_block; /* block mapping function */
> dio_submit_t *submit_io;/* IO submition function */
>
> @@ -372,6 +373,8 @@ dio_bio_alloc(struct dio *dio, struct dio_submit *sdio,
>
> sdio->bio = bio;
> sdio->logical_offset_in_bio = sdio->cur_page_fs_offset;
> +
> + bio_set_streamid(bio, sdio->streamid);
> }
>
> /*
> @@ -1205,6 +1208,7 @@ do_blockdev_direct_IO(int rw, struct kiocb *iocb,
> struct inode *inode,
> sdio.blkbits = blkbits;
> sdio.blkfactor = i_blkbits - blkbits;
> sdio.block_in_file = offset >> blkbits;
> + sdio.streamid = iocb->ki_filp->f_streamid;
If iocb->ki_filp->f_streamid is not set, then it should fall back to
whatever is set on the inode->i_streamid.
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/
[LKP] [rhashtable] ccd57b1bd32: WARNING: CPU: 0 PID: 1 at lib/rhashtable.c:410 rhashtable_insert_rehash+0x101/0x201()
FYI, we noticed the below changes on
git://flatbed.openfabrics.org/~amirv/linux.git for-upstream
commit ccd57b1bd32460d27bbb9c599e795628a3c66983 ("rhashtable: Add immediate
rehash during insertion")
+-+++
| | b9ecfdaa10 |
ccd57b1bd3 |
+-+++
| boot_successes | 20 | 0
|
| early-boot-hang | 1 |
|
| boot_failures | 0 | 10
|
| WARNING:at_lib/rhashtable.c:#rhashtable_insert_rehash() | 0 | 10
|
| backtrace:test_rhashtable | 0 | 10
|
| backtrace:test_rht_init | 0 | 10
|
| backtrace:kernel_init_freeable | 0 | 10
|
+-+++
[3.857520] Running resizable hashtable tests...
[3.857883] Adding 2048 keys
[3.862557] [ cut here ]
[3.863095] WARNING: CPU: 0 PID: 1 at lib/rhashtable.c:410
rhashtable_insert_rehash+0x101/0x201()
[3.863856] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.0.0-rc5-01065-gd5c1d8c #1427
[3.864460] 80273e90 81ac8366 80273eac 8109d724
019a
[3.865164] 8165a792 95da9700 0001 0010 80273ebc 8109d88a 0009
[3.866109] 80273edc 8165a792 95da9780 82d746c0 fff5 95da9700
95dac540
[3.866794] Call Trace:
[3.867000] [<81ac8366>] dump_stack+0x105/0x1d2
[3.867356] [<8109d724>] warn_slowpath_common+0xe1/0x122
[3.867770] [<8165a792>] ? rhashtable_insert_rehash+0x101/0x201
[3.868253] [<8109d88a>] warn_slowpath_null+0x2b/0x3d
[3.868662] [<8165a792>] rhashtable_insert_rehash+0x101/0x201
[3.869280] [<822b5fd0>] test_rhashtable+0x245/0xa62
[3.869832] [<822b67ed>] ? test_rhashtable+0xa62/0xa62
[3.870314] [<822b686b>] test_rht_init+0x7e/0xad
[3.870710] [<8225aace>] do_one_initcall+0x1ed/0x367
[3.871137] [<8225aee3>] kernel_init_freeable+0x29b/0x409
[3.871801] [<81ab8658>] kernel_init+0x16/0x1d4
[3.872265] [<81ade541>] ret_from_kernel_thread+0x21/0x30
[3.872685] [<81ab8642>] ? rest_init+0x1c7/0x1c7
[3.873139] ---[ end trace ff89956aa4e2a9cf ]---
[3.873837] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.0.0-rc4 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
Re: [PATCH 6/6] xfs: add support for buffered writeback stream ID
On Tue, Mar 24, 2015 at 09:27:03AM -0600, Jens Axboe wrote: > Signed-off-by: Jens Axboe > --- > fs/xfs/xfs_aops.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c > index 3a9b7a1b8704..2b00a57732e3 100644 > --- a/fs/xfs/xfs_aops.c > +++ b/fs/xfs/xfs_aops.c > @@ -377,6 +377,7 @@ xfs_submit_ioend_bio( > atomic_inc(>io_remaining); > bio->bi_private = ioend; > bio->bi_end_io = xfs_end_bio; > + bio_set_streamid(bio, wbc->streamid); > submit_bio(wbc->sync_mode == WB_SYNC_ALL ? WRITE_SYNC : WRITE, bio); Like I said, this is wrong. + bio_set_streamid(bio, ioend->io_inode->i_streamid); is actually what it should be. 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/
Re: [PATCH 4/6] Add stream ID support for buffered writeback
On Tue, Mar 24, 2015 at 09:27:01AM -0600, Jens Axboe wrote:
> Add a streamid field to the writeback_control structure, and use
> it for the various parts of buffered writeback.
>
> Signed-off-by: Jens Axboe
> ---
> fs/buffer.c | 4 ++--
> fs/fs-writeback.c | 1 +
> fs/mpage.c| 1 +
> include/linux/writeback.h | 2 ++
> mm/filemap.c | 1 +
> mm/migrate.c | 1 +
> mm/page-writeback.c | 1 +
> mm/vmscan.c | 1 +
> 8 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 20805db2c987..1ae99868f6fb 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1774,7 +1774,7 @@ static int __block_write_full_page(struct inode *inode,
> struct page *page,
> do {
> struct buffer_head *next = bh->b_this_page;
> if (buffer_async_write(bh)) {
> - submit_bh(write_op, bh);
> + _submit_bh(write_op, bh,
> streamid_to_flags(wbc->streamid));
Urk, the is the second patchset in a couple of days to add some
random parameter to submit_bh like this (control group thottling
patch from Tejun was the other).
This doesn't scale
> diff --git a/include/linux/writeback.h b/include/linux/writeback.h
> index 00048339c23e..3ac2ce545dac 100644
> --- a/include/linux/writeback.h
> +++ b/include/linux/writeback.h
> @@ -78,6 +78,8 @@ struct writeback_control {
>
> enum writeback_sync_modes sync_mode;
>
> + unsigned int streamid;
> +
> unsigned for_kupdate:1; /* A kupdate writeback */
> unsigned for_background:1; /* A background writeback */
> unsigned tagged_writepages:1; /* tag-and-write to avoid livelock */
> diff --git a/mm/filemap.c b/mm/filemap.c
> index ad7242043bdb..85aa2cc77d67 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -276,6 +276,7 @@ int __filemap_fdatawrite_range(struct address_space
> *mapping, loff_t start,
> struct writeback_control wbc = {
> .sync_mode = sync_mode,
> .nr_to_write = LONG_MAX,
> + .streamid = inode_streamid(mapping->host),
> .range_start = start,
> .range_end = end,
> };
I don't think this is the right layer to be specifying the stream
id. When we do buffered writeback, the filesystem's .writepage
implementation gets called and it has access to the inode and hence
can grab the stream id there. the struct wbc is used for writeback
across more than one inode, and hence there's going to be nothing
but confusion when this gets set and we iterate writeback across
multiple inodes.
i.e. the stream id should be set by the code the packs the pages
into the bio/bh that is being submitted where there is a direct
relationship between the inode and the IO being built, rather than
at a high layer where the stream id has ambiguous meaning
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/
[RFCv2] mm: page allocation for less fragmentation
My driver allocates more than 40MB pages via alloc_page() at a time and
maps them at virtual address. Totally it uses 300~400MB pages.
If I run a heavy load test for a few days in 1GB memory system, I cannot
allocate even order=3 pages
because-of the external fragmentation.
I thought I needed a anti-fragmentation solution for my driver.
But there is no allocation function that considers fragmentation.
The compaction is not helpful because it is only for movable pages, not
unmovable pages.
This patch proposes a allocation function allocates only pages in the same
pageblock.
I tested this patch like following:
1. When the driver allocates about 400MB and do "cat /proc/pagetypeinfo;cat
/proc/buddyinfo"
Free pages count per migrate type at order 0 1 2 3 4
5 6 7 8 9 10
Node0, zone Normal, typeUnmovable 3864728394216129
47 18 9 1 0 0
Node0, zone Normal, type Reclaimable902 96 68 17 3
0 1 0 0 0 0
Node0, zone Normal, type Movable 5146663178 91 43
16 4 0 0 0 0
Node0, zone Normal, type Reserve 1 4 6 6 2
1 1 1 0 1 1
Node0, zone Normal, type CMA 0 0 0 0 0
0 0 0 0 0 0
Node0, zone Normal, type Isolate 0 0 0 0 0
0 0 0 0 0 0
Number of blocks type Unmovable Reclaimable Movable Reserve
CMA Isolate
Node 0, zone Normal 1353 1242
00
Node 0, zone Normal 9880 1489647332177 64 24 10
1 1 1
2. The driver frees all pages and allocates pages again with
alloc_pages_compact.
This is a kind of compaction of the driver.
Following is the result of "cat /proc/pagetypeinfo;cat /proc/buddyinfo"
Free pages count per migrate type at order 0 1 2 3 4
5 6 7 8 9 10
Node0, zone Normal, typeUnmovable 8 5 1432272
91 37 11 1 0 0
Node0, zone Normal, type Reclaimable901 96 68 17 3
0 1 0 0 0 0
Node0, zone Normal, type Movable 4790776192 91 43
16 4 0 0 0 0
Node0, zone Normal, type Reserve 1 4 6 6 2
1 1 1 0 1 1
Node0, zone Normal, type CMA 0 0 0 0 0
0 0 0 0 0 0
Node0, zone Normal, type Isolate 0 0 0 0 0
0 0 0 0 0 0
Number of blocks type Unmovable Reclaimable Movable Reserve
CMA Isolate
Node 0, zone Normal 1353 1242
00
Node 0, zone Normal 5693877266544320108 43 12
1 1 1
I found that fragmentation is decreased.
This patch is based on 3.16. It is not change any code so that it can apply to
any version.
Changelog since v1:
- change argument of page order into page count
Signed-off-by: Gioh Kim
---
mm/page_alloc.c | 167 +++
1 file changed, 167 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 86c9a72..e269030 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6646,3 +6646,170 @@ void dump_page(struct page *page, const char *reason)
dump_page_badflags(page, reason, 0);
}
EXPORT_SYMBOL(dump_page);
+
+static unsigned long alloc_freepages_block(unsigned long start_pfn,
+ unsigned long end_pfn,
+ int count,
+ struct list_head *freelist)
+{
+ int total_alloc = 0;
+ struct page *cursor, *valid_page = NULL;
+
+ cursor = pfn_to_page(start_pfn);
+
+ /* Isolate free pages. */
+ for (; start_pfn < end_pfn; start_pfn++, cursor++) {
+ int alloc, i;
+ struct page *page = cursor;
+
+ if (!pfn_valid_within(start_pfn))
+ continue;
+
+ if (!valid_page)
+ valid_page = page;
+ if (!PageBuddy(page))
+ continue;
+
+ if (!PageBuddy(page))
+ continue;
+
+ /* allocate only low-order pages */
+ if (page_order(page) >= 3) {
+ start_pfn += (1 << page_order(page)) - 1;
+ cursor += (1 << page_order(page)) - 1;
+ continue;
+
Re: [PATCH RT 2/4] Revert "timers: do not raise softirq unconditionally"
On Tue, 2015-03-24 at 19:15 +0100, Sebastian Andrzej Siewior wrote: > * Mike Galbraith | 2015-03-21 19:02:23 [+0100]: > > >> Steve, I'm still working on the fix we discussed using dummy irq_task. > >> I should be able to submit some time next week, if still interested. > >> > >> Either that, or I think we should remove the function > >> spin_do_trylock_in_interrupt() to prevent any possibility of running > >> into similar problems in the future. > > > >Why can't we just Let swapper be the owner when in irq with no dummy? > > so you abuse the owner to be swapper and mask it out everywhere. It does > not look like a final solution. I'm more inclined to take you other > patch. In the end I hope we get a timer re-work and do not need any > hackary around it… Yeah, it was just _a_ way to dodge the bullet. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.19 000/123] 3.19.3-stable review
On 03/24/2015 08:45 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.19.3 release. There are 123 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Mar 26 15:43:14 UTC 2015. Anything received after that time might be too late. Build results: total: 121 pass: 121 fail: 0 Qemu test results: total: 30 pass: 30 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. 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 3.10 00/55] 3.10.73-stable review
On 03/24/2015 08:42 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.73 release. There are 55 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Mar 26 15:41:27 UTC 2015. Anything received after that time might be too late. Build results: total: 123 pass: 123 fail: 0 Qemu test results: total: 27 pass: 27 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. 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 RT 2/4] Revert "timers: do not raise softirq unconditionally"
On Tue, 2015-03-24 at 19:10 +0100, Sebastian Andrzej Siewior wrote: > * Steven Rostedt | 2015-03-19 12:26:11 [-0400]: > > >On Thu, 19 Mar 2015 09:17:09 +0100 > >Mike Galbraith wrote: > > > > > >> (aw crap, let's go shopping)... so why is the one in timer.c ok? > > > >It's not. Sebastian, you said there were no other cases of rt_mutexes > >being taken in hard irq context. Looks like timer.c has one. > > If you refer to switch_timer_base() then this one is not taken in > hard-irq context. The callchain is: > > lock_timer_base() (with spin_lock_irqsave(>lock, *flags) which >makes it a sleeping lock or lockdep would scream) > -> switch_timer_base() > -> spin_trylock() (not in hardirq conteyt) Nah, I was referring to get_next_timer_interrupt() because I saw that rt_spin_unlock_after_trylock_in_irq(>lock) sitting there. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] block: add support for carrying a stream ID in a bio
On Tue, Mar 24, 2015 at 09:26:58AM -0600, Jens Axboe wrote:
> The top bits of bio->bi_flags are reserved for keeping the
> allocation pool, set aside the next four bits for carrying
> a stream ID. That leaves us with support for 15 streams,
> 0 is reserved as a "stream not set" value.
>
> Add helpers for setting/getting stream ID of a bio.
> +/*
> + * after the pool bits, next 4 bits are for the stream id
> + */
> +#define BIO_STREAM_BITS (4)
> +#define BIO_STREAM_OFFSET(BITS_PER_LONG - 8)
> +#define BIO_STREAM_MASK ((1 << BIO_STREAM_BITS) - 1)
> +
> +static inline unsigned long streamid_to_flags(unsigned int id)
> +{
> + return (unsigned long) (id & BIO_STREAM_MASK) << BIO_STREAM_OFFSET;
> +}
> +
> +static inline void bio_set_streamid(struct bio *bio, unsigned int id)
> +{
> + bio->bi_flags |= streamid_to_flags(id);
> +}
> +
> +static inline unsigned int bio_get_streamid(struct bio *bio)
> +{
> + return (bio->bi_flags >> BIO_STREAM_OFFSET) & BIO_STREAM_MASK;
> +}
> +
> +static inline bool bio_streamid_valid(struct bio *bio)
> +{
> + return bio_get_streamid(bio) != 0;
> +}
Need to reserve at least one stream for filesystem private use (e.g.
metadata writeback). Potentially 2 streams - one for the journal
which is frequently overwritten, the other for all other long lived
persistent metadata.
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/
Re: [PATCH 1/1] cifs: potential missing check for posix_lock_file_wait
On Tue, Mar 24, 2015 at 7:18 PM, Chengyu Song wrote: > posix_lock_file_wait may fail under certain circumstances, and its result is > usually checked/returned. But given the complexity of cifs, I'm not sure if > the result is intentially left unchecked and always expected to succeed. > > Signed-off-by: Chengyu Song > --- > fs/cifs/file.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/cifs/file.c b/fs/cifs/file.c > index a94b3e6..beef67b 100644 > --- a/fs/cifs/file.c > +++ b/fs/cifs/file.c > @@ -1553,8 +1553,8 @@ cifs_setlk(struct file *file, struct file_lock *flock, > __u32 type, > rc = server->ops->mand_unlock_range(cfile, flock, xid); > > out: > - if (flock->fl_flags & FL_POSIX) > - posix_lock_file_wait(file, flock); > + if (flock->fl_flags & FL_POSIX && !rc) > + rc = posix_lock_file_wait(file, flock); > return rc; > } > This is interesting. Useful comparisons include For network file systems you could - enforce byte range locks only at the server - enforce locks only on the client, and don't send to the server - do both Since cifs byte range locks are often emulated (except when Unix Extensions are enabled, e.g. on mounts to Samba), we do the latter by default, as does fs/9p (although they do it in a different order, trying to grab the local byte range lock first). But another interesting comparison point is nfs, where the code for v3 vs. v4 looks different. Take a look at nfsv3 (see fs/nfs/file.c) where the choice is made to either do the posix_lock_file_wait (if 'local' locking only) or if sending locks to the server then don't call to set the local lock. Alternatively nfs4proc.c handles it differently. There may not be a perfect answer on this one but was wondering if you have experimented with what happens when you mount with "nobrl" (which is the cifs mount option which causes locks not to be sent to the server, and thus only evaulted locally). My suspicion is that you can demonstrate a failure if you mount with nobrl (without your patch). -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] drm/msm/mdp4: Support NV12MT format in mdp4
Hello, On 2015년 03월 25일 03:32, Rob Clark wrote: > On Mon, Mar 16, 2015 at 4:05 AM, Daniel Vetter wrote: >> On Fri, Mar 13, 2015 at 03:12:10PM -0400, Stephane Viau wrote: >>> From: Beeresh Gopal >>> >>> Using fb modifier flag, support NV12MT format in MDP4. >>> >>> v2: >>> - rework the modifier's description [Daniel Vetter's comment] >>> - drop .set_mode_config() callback [Rob Clark's comment] >>> >>> Signed-off-by: Beeresh Gopal >>> Signed-off-by: Stephane Viau >>> --- >>> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 ++ >>> drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++ >>> include/uapi/drm/drm_fourcc.h | 5 + >>> 3 files changed, 29 insertions(+) >>> >>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h >>> index 188e61f..2ff79cb 100644 >>> --- a/include/uapi/drm/drm_fourcc.h >>> +++ b/include/uapi/drm/drm_fourcc.h >>> @@ -161,4 +161,9 @@ >>> * authoritative source for all of these. >>> */ >>> >>> +/* Samsung framebuffer modifiers */ >>> + >>> +/* Tiled: 64x32 pixel macroblocks */ >> >> Since this seems shared by a lot of vendors (I still don't believe Samsung >> invented this really ...) can you please describe this thing a bit in more >> detail? Somewhat important how macroblocks are laid out and pixels within. >> Also with a planar format like NV12 "pixel" is a bit unclear, e.g. what >> happens if you throw 10bit plane formats at this? So maybe also add a note >> that for now this is only used together with NV12T. > > + a couple folks from Samsung, since I expect they want this for > exynos as well (and might be able to help with the description) Yes, I have a plan to apply fb_modifier for exynos with kms interface of hdmi. > > vl4 also has this format, but last I looked was rather light on the details. I am not sure msm mdp uses exactly same format with exynos, but anyway v4l2 NV12MT format was introduced for exynos hw video codec. macro blocks for the format is laid z-order and each pixel data in each macro block is just normal NV12 style. I think Marek and Sylwester can help understanding the format. > > http://linuxtv.org/downloads/v4l-dvb-apis/re31.html > > I know up in userspace, GStreamer seems to have some support for this format: > > http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=f8d3b9b4fcc5e08b771314fa95e9ed8f750b54e6 > >> Then there's the question of validating the input - stride should probably >> be a full multiple of the macroblock size. Since this is a shared format >> imo this kind of checking should be done in drm core. > > afaiu, stride (and maybe even width?) should be a multiple of the > block size (but height does not) > > BR, > -R > > >> -Daniel >> >> >>> +#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1) >>> + >>> #endif /* DRM_FOURCC_H */ >>> -- >>> Qualcomm Innovation Center, Inc. >>> >>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, >>> a Linux Foundation Collaborative Project >>> >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- Seung-Woo Kim Samsung Software R Center -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got conflicts in
net/ipv4/tcp_ipv4.c and net/ipv6/tcp_ipv6.c between commit d0c294c53a77
("tcp: prevent fetching dst twice in early demux code") from the tree
and commit f7e4eb03f9d9 ("inet: ip early demux should avoid request
sockets") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/ipv4/tcp_ipv4.c
index f1756ee02207,4e90217003e8..
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@@ -1517,8 -1521,8 +1521,8 @@@ void tcp_v4_early_demux(struct sk_buff
if (sk) {
skb->sk = sk;
skb->destructor = sock_edemux;
- if (sk->sk_state != TCP_TIME_WAIT) {
+ if (sk_fullsock(sk)) {
- struct dst_entry *dst = sk->sk_rx_dst;
+ struct dst_entry *dst = READ_ONCE(sk->sk_rx_dst);
if (dst)
dst = dst_check(dst, 0);
diff --cc net/ipv6/tcp_ipv6.c
index b283a498f7a4,4a4e6d30c448..
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@@ -1584,8 -1544,8 +1544,8 @@@ static void tcp_v6_early_demux(struct s
if (sk) {
skb->sk = sk;
skb->destructor = sock_edemux;
- if (sk->sk_state != TCP_TIME_WAIT) {
+ if (sk_fullsock(sk)) {
- struct dst_entry *dst = sk->sk_rx_dst;
+ struct dst_entry *dst = READ_ONCE(sk->sk_rx_dst);
if (dst)
dst = dst_check(dst,
inet6_sk(sk)->rx_dst_cookie);
pgpMp5PDjEiKC.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 1/2] powerpc32: put csum_tcpudp_magic inline
On Tue, 2015-02-03 at 12:39 +0100, Christophe Leroy wrote: > csum_tcpudp_magic() is only a few instructions, and does not modifies any > other > register than the returned result. So it is not worth having it as a separate > function and suffer function branching and saving of volatile registers. > This patch makes it inline by use of the already existing csum_tcpudp_nofold() > function. > > Signed-off-by: Christophe Leroy > > --- > v2: no change > > arch/powerpc/include/asm/checksum.h | 15 +++ > arch/powerpc/lib/checksum_32.S | 16 > 2 files changed, 15 insertions(+), 16 deletions(-) The 64-bit version is pretty similar to the 32-bit -- why only use csum_tcpudp_nofold() on 32-bit? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/3] block, drbd: fix drbd_req_new() initialization
On 03/24/2015 05:22 PM, David Rientjes wrote: mempool_alloc() does not support __GFP_ZERO since elements may come from memory that has already been released by mempool_free(). Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly initialize it to 0. This (and the other drbd patch) queued up in for-4.1/drivers, thanks. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/3] block: allocate request memory local to request queue
On 03/24/2015 05:21 PM, David Rientjes wrote: blk_init_rl() allocates a mempool using mempool_create_node() with node local memory. This only allocates the mempool and element list locally to the requeue queue node. What we really want to do is allocate the request itself local to the queue. To do this, we need our own alloc and free functions that will allocate from request_cachep and pass the request queue node in to prefer node local memory. Applied to for-4.1/core, thanks. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: powerpc: Fix trivial typo in comment
On Fri, 2015-27-02 at 22:22:54 UTC, Yannick Guerrini wrote: > Change 'Kenrel' to 'Kernel' > > Signed-off-by: Yannick Guerrini > --- > arch/powerpc/include/asm/smu.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) If you're going to send spelling fix patches, please at least fix all the spelling mistakes in the file at once. I can see several others in this file. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 braces to GNU style
From: Carlos Roberto Silveira Junior
---
kernel/sched/fair.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7ce18f3..834aa55 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -296,13 +296,12 @@ static inline void list_add_leaf_cfs_rq(struct cfs_rq
*cfs_rq)
* reduces this to two cases.
*/
if (cfs_rq->tg->parent &&
- cfs_rq->tg->parent->cfs_rq[cpu_of(rq_of(cfs_rq))]->on_list)
{
+ cfs_rq->tg->parent->cfs_rq[cpu_of(rq_of(cfs_rq))]->on_list)
list_add_rcu(_rq->leaf_cfs_rq_list,
_of(cfs_rq)->leaf_cfs_rq_list);
- } else {
+ else
list_add_tail_rcu(_rq->leaf_cfs_rq_list,
_of(cfs_rq)->leaf_cfs_rq_list);
- }
cfs_rq->on_list = 1;
/* We should have no load, but we need to update last_decay. */
@@ -505,9 +504,9 @@ static void __enqueue_entity(struct cfs_rq *cfs_rq, struct
sched_entity *se)
* We dont care about collisions. Nodes with
* the same key stay together.
*/
- if (entity_before(se, entry)) {
+ if (entity_before(se, entry))
link = >rb_left;
- } else {
+ else {
link = >rb_right;
leftmost = 0;
}
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix platform_no_drv_owner.cocci warnings
On Tue, Mar 24, 2015 at 11:43:41AM +0100, Thierry Reding wrote: > On Wed, Mar 18, 2015 at 02:38:18AM +0100, Linus Walleij wrote: > > On Wed, Mar 11, 2015 at 12:05 PM, Thierry Reding > > wrote: > > > On Fri, Jan 16, 2015 at 09:06:14AM +0800, kbuild test robot wrote: > > >> drivers/pwm/pwm-stmpe.c:99:3-8: No need to set .owner here. The core > > >> will do it. > > >> > > >> Remove .owner field if calls are used which set it automatically > > >> > > >> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci > > >> > > >> Signed-off-by: Fengguang Wu > > >> --- > > >> > > >> pwm-stmpe.c |1 - > > >> 1 file changed, 1 deletion(-) > > > > > > Erm... this driver doesn't exist in my tree. What's going on? > > > > What's going on is that the 0day build robot builds everything it > > finds, including experimental branches. > > > > I dunno why it's mailing you though, probably I already added your > > CC on the patch... stupid me. A bit much to think of. > > I guess the robot generates this patch and then runs get_maintainers.pl > on it, so it's doing the right thing. Anyway, I'll know to ignore these > in the future if drivers aren't in my tree yet. Sorry I've added some heuristics to avoid adding CC from get_maintainers.pl for the likely private branches. It should reduce such confusions and noises considerably in future. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: Defer lookup of supply to regulator_get
Instead of resolving regulator supplies during registration move this to
the time of a consumer retrieving a handle. The benefit is that it's
possible for one driver to register regulators with internal
dependencies out of order.
Signed-off-by: Bjorn Andersson
---
drivers/regulator/core.c | 92
include/linux/regulator/driver.h | 1 +
2 files changed, 57 insertions(+), 36 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index f245214..52ddb73 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1325,6 +1325,54 @@ static struct regulator_dev *regulator_dev_lookup(struct
device *dev,
return NULL;
}
+static int regulator_resolve_supply(struct regulator_dev *rdev)
+{
+ struct regulator_dev *r;
+ struct device *dev = rdev->dev.parent;
+ int ret;
+
+ /* No supply to resovle? */
+ if (!rdev->supply_name)
+ return 0;
+
+ /* Supply already resolved? */
+ if (rdev->supply)
+ return 0;
+
+ r = regulator_dev_lookup(dev, rdev->supply_name, );
+ if (ret == -ENODEV) {
+ /*
+* No supply was specified for this regulator and
+* there will never be one.
+*/
+ return 0;
+ }
+
+ if (!r) {
+ dev_err(dev, "Failed to resolve %s-supply for %s\n",
+ rdev->supply_name, rdev->desc->name);
+ return -EPROBE_DEFER;
+ }
+
+ /* Recursively resolve the supply of the supply */
+ ret = regulator_resolve_supply(r);
+ if (ret < 0)
+ return ret;
+
+ ret = set_supply(rdev, r);
+ if (ret < 0)
+ return ret;
+
+ /* Cascade always-on state to supply */
+ if (_regulator_is_enabled(rdev)) {
+ ret = regulator_enable(rdev->supply);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
/* Internal regulator request function */
static struct regulator *_regulator_get(struct device *dev, const char *id,
bool exclusive, bool allow_dummy)
@@ -1394,6 +1442,12 @@ found:
goto out;
}
+ ret = regulator_resolve_supply(rdev);
+ if (ret < 0) {
+ regulator = ERR_PTR(ret);
+ goto out;
+ }
+
if (!try_module_get(rdev->owner))
goto out;
@@ -3545,7 +3599,6 @@ regulator_register(const struct regulator_desc
*regulator_desc,
struct regulator_dev *rdev;
struct device *dev;
int ret, i;
- const char *supply = NULL;
if (regulator_desc == NULL || cfg == NULL)
return ERR_PTR(-EINVAL);
@@ -3659,41 +3712,10 @@ regulator_register(const struct regulator_desc
*regulator_desc,
goto scrub;
if (init_data && init_data->supply_regulator)
- supply = init_data->supply_regulator;
+ rdev->supply_name = init_data->supply_regulator;
else if (regulator_desc->supply_name)
- supply = regulator_desc->supply_name;
-
- if (supply) {
- struct regulator_dev *r;
-
- r = regulator_dev_lookup(dev, supply, );
+ rdev->supply_name = regulator_desc->supply_name;
- if (ret == -ENODEV) {
- /*
-* No supply was specified for this regulator and
-* there will never be one.
-*/
- ret = 0;
- goto add_dev;
- } else if (!r) {
- dev_err(dev, "Failed to find supply %s\n", supply);
- ret = -EPROBE_DEFER;
- goto scrub;
- }
-
- ret = set_supply(rdev, r);
- if (ret < 0)
- goto scrub;
-
- /* Enable supply if rail is enabled */
- if (_regulator_is_enabled(rdev)) {
- ret = regulator_enable(rdev->supply);
- if (ret < 0)
- goto scrub;
- }
- }
-
-add_dev:
/* add consumers devices */
if (init_data) {
for (i = 0; i < init_data->num_consumer_supplies; i++) {
@@ -3720,8 +3742,6 @@ unset_supplies:
unset_regulator_supplies(rdev);
scrub:
- if (rdev->supply)
- _regulator_put(rdev->supply);
regulator_ena_gpio_free(rdev);
kfree(rdev->constraints);
wash:
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 0f86a182..a15c59d 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -371,6 +371,7 @@ struct regulator_dev {
struct device dev;
struct regulation_constraints *constraints;
struct
Re: [PATCH] PM / Hiberante : optimize swsusp_free()
>From 6cb5fffc41911a29212be52d4ce7e481f5077ccf Mon Sep 17 00:00:00 2001
From: "Tom(JeHyeon) Yeon"
Date: Thu, 19 Mar 2015 17:10:45 +0900
Subject: [PATCH] PM / Hiberante : optimize swsusp_free()
Our team developed the snapshot booting.
Fisrt of all, make a snapshot image, compress it and finally save it
in the storage(like mmc).
When the system is booting next time, bootloader read it from mmc,
decompress it and jump to the kernel.
In this circumstance, mili seconds is very important.
So, I prepared this patch, but not applied because I missed the time
to apply it.
And, I came across to find commit fdd64ed.
It's very similar to the patch I prepared.
I think do { ... } while (fb_pfn != fr_pfn) operation is very similar
to my patch. but, it takes a little more time to iterate.
So suggest to iterate one of two maps and check whether the other map
has the same pfn, finally free the page.
Signed-off-by: Tom(JeHyeon) Yeon
---
kernel/power/snapshot.c | 43 ++-
1 file changed, 10 insertions(+), 33 deletions(-)
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index c24d5a2..a1ad801 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -726,14 +726,6 @@ static void memory_bm_clear_bit(struct memory_bitmap *bm,
unsigned long pfn)
clear_bit(bit, addr);
}
-static void memory_bm_clear_current(struct memory_bitmap *bm)
-{
- int bit;
-
- bit = max(bm->cur.node_bit - 1, 0);
- clear_bit(bit, bm->cur.node->data);
-}
-
static int memory_bm_test_bit(struct memory_bitmap *bm, unsigned long pfn)
{
void *addr;
@@ -1342,36 +1334,21 @@ static struct memory_bitmap copy_bm;
void swsusp_free(void)
{
- unsigned long fb_pfn, fr_pfn;
+ unsigned long pfn;
if (!forbidden_pages_map || !free_pages_map)
goto out;
memory_bm_position_reset(forbidden_pages_map);
- memory_bm_position_reset(free_pages_map);
-
-loop:
- fr_pfn = memory_bm_next_pfn(free_pages_map);
- fb_pfn = memory_bm_next_pfn(forbidden_pages_map);
-
- /*
-* Find the next bit set in both bitmaps. This is guaranteed to
-* terminate when fb_pfn == fr_pfn == BM_END_OF_MAP.
-*/
- do {
- if (fb_pfn < fr_pfn)
- fb_pfn = memory_bm_next_pfn(forbidden_pages_map);
- if (fr_pfn < fb_pfn)
- fr_pfn = memory_bm_next_pfn(free_pages_map);
- } while (fb_pfn != fr_pfn);
-
- if (fr_pfn != BM_END_OF_MAP && pfn_valid(fr_pfn)) {
- struct page *page = pfn_to_page(fr_pfn);
-
- memory_bm_clear_current(forbidden_pages_map);
- memory_bm_clear_current(free_pages_map);
- __free_page(page);
- goto loop;
+ for ( ; ; ) {
+ pfn = memory_bm_next_pfn(forbidden_pages_map);
+ if (BM_END_OF_MAP == pfn)
+ break;
+ if (memory_bm_test_bit(free_pages_map, pfn)) {
+ memory_bm_clear_bit(forbidden_pages_map, pfn);
+ memory_bm_clear_bit(free_pages_map, pfn);
+ __free_page(pfn_to_page(pfn));
+ }
}
out:
--
1.7.9.5
describe it in details.
As pavel said, 5ms is not important in the normal booting system.
but mili seconds is important in the hibernation or snapshot system.
Just suggestion.
Thank you.
--
On Thursday, March 19, 2015 05:28:58 PM Tom Yeon wrote:
> From: "Tom(JeHyeon) Yeon"
>
> I tested the performance of swsusp_free operation.
> The free time took about 58768us before commit fdd64ed, and
> the free time took about 40535us after the commit fdd64ed.
>
> But, I optimized the function before I saw commit fdd64ed.
> So, I applied the patch in my system.(ARM Coretex A9, Dual Core 1GHz)
> The free time took about 35164us.
> I think that the finding routine for the same pfn is redundant
This changelog in total pants, sorry.
Please write what the patch is doing and why instead of describing
your testing experience. The numbers are useful too, but only to
show what the gain is, and you need to explain what is changing and
why.
> Signed-off-by: Tom(JeHyeon) Yeon
> ---
> kernel/power/snapshot.c | 43 ++-
> 1 file changed, 10 insertions(+), 33 deletions(-)
>
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index c24d5a2..a1ad801 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -726,14 +726,6 @@ static void memory_bm_clear_bit(struct memory_bitmap
> *bm, unsigned long pfn)
> clear_bit(bit, addr);
> }
>
> -static void memory_bm_clear_current(struct memory_bitmap *bm)
> -{
> - int bit;
> -
> - bit = max(bm->cur.node_bit - 1, 0);
> - clear_bit(bit, bm->cur.node->data);
> -}
> -
> static int memory_bm_test_bit(struct memory_bitmap *bm, unsigned long pfn)
> {
> void
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi, On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote: > So you propose that the parent->child relationship is “control”? I.e. some > channel which allows to address some bus client (through ) and > control that devices. > > Makes sense. This is how i2c and spi clients are specified. > > > > > In the case of our GPS, it receives control over the serial connection from > > the UART, > > Ahem - does it? > > AFAIK the chip simply starts to emit NMEA records if powered on. > There is no command going over the serial interface to address it > or control it. Right, since GPS basically doesn't need any configuration/control. That's not true for other UART attached devices, though. > > also receives control via a GPIO to the on/off pin, and also needs > > a regulator to power the antenna. > > > > So should the parent be the uart, the on/off GPIO, or the regulator? > > > > I would much rather there wasn't a parent, and that each of these were > > listed > > as ad-hoc attribute assignments. But device-tree says there must be a > > parent > > (where possible), and the parent is the thing that is “primarily" in > > control. > > Well, IMHO the “parent” could also be the root. Representing the > whole board. > > Nevertheless, I doubt your rule that “ability to control” defines > the parent>child relation (see below). > > > > > I think the GPS is “primarily" a uart-attached device. > > But not in the same way as an I2C device. > > Especially the serial interface is not a bus and not used for > signalling and power control. It is payload data (only). Actually many I2C devices are also powered on/off via a GPIO and even use additional GPIOs for sending interrupts. Nevertheless they are normally identified as an I2C device. Also for non-GPS device the serial connection is used for controlling and configuring the device. > > So I propose a device-node which describes the GPS, which is a child of the > > UART, and explicitly identifies the GPIO it uses to power on/off, the > > regulator it uses to power the antenna, and how it receives "on or off" > > status indications from the GPS. > > The more I think about that, you have given good arguments *not* > to use the parent->child relationship for the UART interface of > the GPS. > > Let me give another example. The 3G Modem has 3 (or 4) interfaces: > 1. an USB-Interface for AT signalling and payload > 2. some GPIOs for power control. > 3. a PCM interface for digital voice. > 4. it might also have a serial interface as alternate AT command and (GPRS > low speed) payload. > > So which one is the most prominent or most important to make it a child of? > > If you use “control” you must make it a child of the USB phy and the serial > interface > which requires multiple inheritance… > > So I am not sure at all. None is IMHO prominent and unique enough to make it > a parent>child relation. > > Threrefore, I would be happy to see it as multiple children of /. For example > a > MFD with subnodes. This scenario has already been seen before and can happen for non-UART based devices (e.g. SPI + I2C). So far the decision was to postpone the discussion about this kind of devices until one of them appears. > > It is arguable that the "antenna" should be treated as a separate device - a > > child of the GPS - which controls the regulator and also provides a 'extcon' > > which reports whether an external GPS antenna is attached, or whether the > > internal on is in use. I haven't made the time to properly explore that > > issue yet. > > If you assume that parent>child relationship is about control (only). But if > it > is about data flow, there is a different concept in DT. For example the > CSI/DSI > (OMAP DSS) use the “port” concept. Yes, this is about data not going to the cpu / system memory. > This means that indeed parent>child is used for control, e.g. I2C > or SPI to tell the panel controller to switch on. well parent > child is not about power control, but about "primary" control. Some I2C/SPI devices have additional gpios for power control. > For example we have the GTA04 panel as a subnode of SPI (because SPI is a > bus and the panel is controlled through SPI). Other panels need no control > interface and are simply a child of /. Yes, some devices do not have an interface worth of being called "primary control" :) > The video stream and its connections are arranged through such ports. > For the video out management we have added our OPA362 video amplifier into > that video pipeline which starts at the VENC (Video encode) in the SoC, > goes through the OPA362 and ends in the connector (which has its own > node). All this is connected by references. The opa362 node itself is a child > of /: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98 > > So to summarize I now see exactly two cases where parent>child is used: > a) for
Re: [PATCH 1/6] block: add support for carrying a stream ID in a bio
On 03/24/2015 04:07 PM, Ming Lin-SSI wrote: -Original Message- From: Jens Axboe [mailto:ax...@kernel.dk] Sent: Tuesday, March 24, 2015 10:27 AM To: Matias Bjørling; Jens Axboe; linux-kernel@vger.kernel.org; linux- fsde...@vger.kernel.org Cc: Ming Lin-SSI Subject: Re: [PATCH 1/6] block: add support for carrying a stream ID in a bio On 03/24/2015 11:11 AM, Matias Bjørling wrote: On 03/24/2015 04:26 PM, Jens Axboe wrote: The top bits of bio->bi_flags are reserved for keeping the allocation pool, set aside the next four bits for carrying a stream ID. That leaves us with support for 15 streams, 0 is reserved as a "stream not set" value. 15 streams seem very limited. Can this be extended? e.g. 16 bits. 15 streams is enough for 1-4 applications. More, and applications starts to fight over the same stream id's, leading them to place different age data in same flash blocks and push us back to square one. I understand that Samsung multi-stream SSD supports a limited amount of streams, more advance implementations should provide higher limits. Pushing it higher is not a big deal as far as the implementation goes, though 16 bits might be stealing a bit too much space for this. On 32-bit archs, we have 18 bits currently free that we can abuse. The Samsung device supports 16 streams. That's honestly a lot more than I would expect most devices to support in hardware, 16 is a lot of open erase blocks and write append points. Obviously the open channel effort would make that more feasible, though. Can we use 8 bits at least? I'll test performance with 16 streams. We could, but I still question whether that's really useful. I'd rather start smaller and go bigger if there's a real use case for it. It wont change the user space ABI if we later make it larger. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mmc: mmci: Cascade EPROBE_DEFER from regulators.
Signed-off-by: Bjorn Andersson --- drivers/mmc/host/mmci.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c index 7fe1619..fb26674 100644 --- a/drivers/mmc/host/mmci.c +++ b/drivers/mmc/host/mmci.c @@ -1613,7 +1613,10 @@ static int mmci_probe(struct amba_device *dev, dev_dbg(mmc_dev(mmc), "clocking block at %u Hz\n", mmc->f_max); /* Get regulators and the supported OCR mask */ - mmc_regulator_get_supply(mmc); + ret = mmc_regulator_get_supply(mmc); + if (ret == -EPROBE_DEFER) + goto clk_disable; + if (!mmc->ocr_avail) mmc->ocr_avail = plat->ocr_mask; else if (plat->ocr_mask) -- 1.8.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [23/32] powerpc: copy_thread(): rename 'arg' argument to 'kthread_arg'
On Tue, 2015-03-24 at 21:49 +0200, Alex Dowad wrote: > On 20/03/15 01:54, Michael Ellerman wrote: > > On Thu, 2015-03-19 at 09:22 +0200, Alex Dowad wrote: > >> On 19/03/15 08:45, Michael Ellerman wrote: > >>> On Fri, 2015-13-03 at 18:14:46 UTC, Alex Dowad wrote: > The 'arg' argument to copy_thread() is only ever used when forking a new > kernel thread. Hence, rename it to 'kthread_arg' for clarity (and > consistency > with do_fork() and other arch-specific implementations of copy_thread()). > >>> > >>> I don't understand the bit about consistency with do_fork() ? > >>> > >> This series of patches includes one patch which renames the arg for > >> do_fork(), and others which rename the same arg for each arch-specific > >> implementation of copy_thread(). So if all of them are accepted and > >> merged, then all will be consistent. If only some of the patches are > >> accepted, I will rewrite the commit message so it doesn't mention > >> "consistency". > > Ah OK, I only got patch 23, so I missed the context of the whole series. > > > > I'll apply this one to the powerpc tree. > > Dear M. Ellerman, sorry for not replying promptly. If you would like to > apply this directly to the powerpc tree, that is fine, but can I edit > the commit message to remove the mention of 'consistency'? I doubt that > all 30+ archs will ever merge this change. Thanks, Alex I merged it last week: https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/commit/?h=next=6eca8933d3ff17bff39d5f10a2a22366d8622fa6 And I edited the commit message more or less as you describe. And feel free to call me Michael or mpe :) cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ufs: missing check for block_truncate_page
block_truncate_page may fail under certain circumstances, so its result
should be checked.
Signed-off-by: Chengyu Song
---
fs/ufs/truncate.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/ufs/truncate.c b/fs/ufs/truncate.c
index f04f89f..8b41f07 100644
--- a/fs/ufs/truncate.c
+++ b/fs/ufs/truncate.c
@@ -464,7 +464,12 @@ int ufs_truncate(struct inode *inode, loff_t old_i_size)
goto out;
}
- block_truncate_page(inode->i_mapping, inode->i_size, ufs_getfrag_block);
+ err = block_truncate_page(inode->i_mapping, inode->i_size,
ufs_getfrag_block);
+
+ if (err) {
+ i_size_write(inode, old_i_size);
+ goto out;
+ }
while (1) {
retry = ufs_trunc_direct(inode);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/3] of: Add vendor prefix for Kinetic technologies
This patch adds vendor prefix for Kinetic technologies Signed-off-by: Ingi Kim Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..de9e126 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -98,6 +98,7 @@ isee ISEE 2007 S.L. isil Intersil karo Ka-Ro electronics GmbH keymileKeymile GmbH +kinetic Kinetic Technologies lacie LaCie lantiq Lantiq Semiconductor lenovo Lenovo Group Ltd. -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/3] leds: ktd2692: add device tree bindings for ktd2692
This patch adds the device tree bindings for ktd2692 flash LEDs.
Add optional properties 'flash-timeout-us' to control flash timeout
and 'vin-supply' for flash-led regulator
Signed-off-by: Ingi Kim
---
.../devicetree/bindings/leds/leds-ktd2692.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
new file mode 100644
index 000..f78512f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
@@ -0,0 +1,33 @@
+* Kinetic Technologies - KTD2692 Flash LED Driver
+
+KTD2692 is the ideal power solution for high-power flash LEDs.
+It uses ExpressWire single-wire programming for maximum flexibility.
+
+The ExpressWire interface through CTRL pin can control LED on/off and
+enable/disable the IC, Movie(max 1/3 of Flash current) / Flash mode current,
+Flash timeout, LVP(low voltage protection).
+
+Also, When the AUX pin is pulled high while CTRL pin is high,
+LED current will be ramped up to the flash-mode current level.
+
+Required properties:
+ - compatible: "kinetic,ktd2692"
+ - ctrl-gpio, aux-gpio : gpio pins in order control ktd2692 flash led.
+ There is an internal 300kOhm pull-down resistor at each pin
+ - vin-supply : "vin" LED supply (2.7V to 5.5V)
+ See Documentation/devicetree/bindings/regulator/regulator.txt
+
+Optional property:
+ - flash-timeout-us : Maximum flash timeout in microseconds.
+ flash timeout ranges from 0 to 1835000us and
+ default is 1049000us.
+
+Example:
+
+flash-led {
+ compatible = "kinetic,ktd2692";
+ ctrl-gpio = < 1 0>;
+ aux-gpio = < 2 0>;
+ flash-timeout-us = <1835000>;
+ vin-supply = <>;
+};
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/3] Add ktd2692 Flash LED driver using LED Flash class
This patch adds ktd2692 Flash LED driver with LED Flash class Change in v4: - Clean up the code - Modify binding documentation of ktd2692 Change in v3: - Clean up the code - Add aux gpio pin to control Flash LED Change in v2: - Introduction of LED Flash class as Jacek's comment - Supplement of binding documentation - Rename gpio control pin and remove unused pin - Add regulator for the Flash LED Ingi Kim (3): of: Add vendor prefix for Kinetic technologies leds: ktd2692: add device tree bindings for ktd2692 leds: Add ktd2692 flash LED driver .../devicetree/bindings/leds/leds-ktd2692.txt | 33 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/leds/Kconfig | 9 + drivers/leds/Makefile | 1 + drivers/leds/leds-ktd2692.c| 412 + 5 files changed, 456 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt create mode 100644 drivers/leds/leds-ktd2692.c -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] prctl: avoid using mmap_sem for exe_file serialization
Oleg cleverly suggested using xchg() to set the new
mm->exe_file instead of calling set_mm_exe_file()
which requires some form of serialization -- mmap_sem
in this case. For archs that do not have atomic rmw
instructions we still fallback to a spinlock alternative,
so this should always be safe. As such, we only need the
mmap_sem for looking up the backing vm_file, which can be
done sharing the lock. Naturally, this means we need to
manually deal with both the new and old file reference
counting, and we need not worry about the MMF_EXE_FILE_CHANGED
bits, which can probably be deleted in the future anyway.
Suggested-by: Oleg Nesterov
Cc: Konstantin Khlebnikov
Signed-off-by: Davidlohr Bueso
---
Changes from v1:
- use rcu_dereference_raw()
- comment lockless use in flush_old_exec()
fs/exec.c | 6 ++
kernel/fork.c | 19 +--
kernel/sys.c | 43 ++-
3 files changed, 45 insertions(+), 23 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 314e8d8..02bfd98 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1082,7 +1082,13 @@ int flush_old_exec(struct linux_binprm * bprm)
if (retval)
goto out;
+ /*
+* Must be called _before_ exec_mmap() as bprm->mm is
+* not visible until then. This also enables the update
+* to be lockless.
+*/
set_mm_exe_file(bprm->mm, bprm->file);
+
/*
* Release all of the old mmap stuff
*/
diff --git a/kernel/fork.c b/kernel/fork.c
index 3847f34..347f69c 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -688,15 +688,22 @@ EXPORT_SYMBOL_GPL(mmput);
*
* This changes mm's executale file (shown as symlink /proc/[pid]/exe).
*
- * Main users are mmput(), sys_execve() and sys_prctl(PR_SET_MM_MAP/EXE_FILE).
- * Callers prevent concurrent invocations: in mmput() nobody alive left,
- * in execve task is single-threaded, prctl holds mmap_sem exclusively.
+ * Main users are mmput() and sys_execve(). Callers prevent concurrent
+ * invocations: in mmput() nobody alive left, in execve task is single
+ * threaded. sys_prctl(PR_SET_MM_MAP/EXE_FILE) also needs to set the
+ * mm->exe_file, but does so without using set_mm_exe_file() in order
+ * to do avoid the need for any locks.
*/
void set_mm_exe_file(struct mm_struct *mm, struct file *new_exe_file)
{
- struct file *old_exe_file = rcu_dereference_protected(mm->exe_file,
- !atomic_read(>mm_users) || current->in_execve ||
- lockdep_is_held(>mmap_sem));
+ struct file *old_exe_file;
+
+ /*
+* It is safe to dereference the exe_file without RCU as
+* this function is only called if nobody else can access
+* this mm -- see comment above for justification.
+*/
+ old_exe_file = rcu_dereference_raw(mm->exe_file);
if (new_exe_file)
get_file(new_exe_file);
diff --git a/kernel/sys.c b/kernel/sys.c
index 3be3449..1da6b17 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1649,14 +1649,13 @@ SYSCALL_DEFINE1(umask, int, mask)
return mask;
}
-static int prctl_set_mm_exe_file_locked(struct mm_struct *mm, unsigned int fd)
+static int prctl_set_mm_exe_file(struct mm_struct *mm, unsigned int fd)
{
struct fd exe;
+ struct file *old_exe, *exe_file;
struct inode *inode;
int err;
- VM_BUG_ON_MM(!rwsem_is_locked(>mmap_sem), mm);
-
exe = fdget(fd);
if (!exe.file)
return -EBADF;
@@ -1680,15 +1679,22 @@ static int prctl_set_mm_exe_file_locked(struct
mm_struct *mm, unsigned int fd)
/*
* Forbid mm->exe_file change if old file still mapped.
*/
+ exe_file = get_mm_exe_file(mm);
err = -EBUSY;
if (mm->exe_file) {
struct vm_area_struct *vma;
- for (vma = mm->mmap; vma; vma = vma->vm_next)
- if (vma->vm_file &&
- path_equal(>vm_file->f_path,
+ down_read(>mmap_sem);
+ for (vma = mm->mmap; vma; vma = vma->vm_next) {
+ if (!vma->vm_file)
+ continue;
+ if (path_equal(>vm_file->f_path,
>exe_file->f_path))
- goto exit;
+ goto exit_err;
+ }
+
+ up_read(>mmap_sem);
+ fput(exe_file);
}
/*
@@ -1702,10 +1708,18 @@ static int prctl_set_mm_exe_file_locked(struct
mm_struct *mm, unsigned int fd)
goto exit;
err = 0;
- set_mm_exe_file(mm, exe.file); /* this grabs a reference to exe.file */
+ /* set the new file, lockless */
+ get_file(exe.file);
+ old_exe = xchg(>exe_file, exe.file);
+ if (old_exe)
+ fput(old_exe);
exit:
fdput(exe);
return err;
[PATCH v4 3/3] leds: Add ktd2692 flash LED driver
This patch adds a driver to support the ktd2692 flash LEDs.
ktd2692 can control flash current by ExpressWire interface.
Signed-off-by: Ingi Kim
---
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-ktd2692.c | 412
3 files changed, 422 insertions(+)
create mode 100644 drivers/leds/leds-ktd2692.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 25b320d..9311cfc4 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -498,6 +498,15 @@ config LEDS_MENF21BMC
This driver can also be built as a module. If so the module
will be called leds-menf21bmc.
+config LEDS_KTD2692
+ tristate "Flash LED support for the KTD2692 Driver"
+ depends on LEDS_CLASS_FLASH && GPIOLIB
+ help
+ This option enables support for the KTD2692 connected through
+ ExpressWire Interface. Say Y to enabled these.
+ It depends on LEDS_CLASS_FLASH for using flash led (strobe) and
+ GPIOLIB for using gpio pin to control Expresswire interface
+
comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
(HID_THINGM)"
config LEDS_BLINKM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index cbba921..289513b 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
+obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-ktd2692.c b/drivers/leds/leds-ktd2692.c
new file mode 100644
index 000..c31ec9d
--- /dev/null
+++ b/drivers/leds/leds-ktd2692.c
@@ -0,0 +1,412 @@
+/*
+ * LED driver : leds-ktd2692.c
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * Ingi Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GET_BIT(bit, val) (((val) >> (bit)) & 0x01)
+
+/* Value related the flash mode */
+#define KTD2692_FLASH_MODE_TIMEOUT_LEVELS 8
+#define KTD2692_FLASH_MODE_TIMEOUT_DISABLE 0
+#define KTD2692_FLASH_MODE_TIMEOUT_DEFAULT_US 1049000
+#define KTD2692_FLASH_MODE_TIMEOUT_MAX_US 1835000
+#define KTD2692_FLASH_MODE_CURR_PERCENT(x) (((x) * 16) / 100)
+
+/* Macro for getting offset of flash timeout */
+#define GET_TIMEOUT_OFFSET(timeout, step) ((timeout) / (step))
+
+/* Adjust a multiple of brightness */
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_16(x) (((x) >> 4) & 0x0F)
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_8(x) (((x) >> 5) & 0x0F)
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_4(x) (((x) >> 6) & 0x0F)
+
+/* Base register address */
+#define KTD2692_REG_LVP_BASE 0x00
+#define KTD2692_REG_FLASH_TIMEOUT_BASE 0x20
+#define KTD2692_REG_MIN_CURRENT_SET_BASE 0x40
+#define KTD2692_REG_MOVIE_CURRENT_BASE 0x60
+#define KTD2692_REG_FLASH_CURRENT_BASE 0x80
+#define KTD2692_REG_MODE_BASE 0xA0
+
+/* Set bit coding time for expresswire interface */
+#define KTD2692_TIME_RESET_US 700
+#define KTD2692_TIME_DATA_START_TIME_US10
+#define KTD2692_TIME_HIGH_END_OF_DATA_US 350
+#define KTD2692_TIME_LOW_END_OF_DATA_US10
+#define KTD2692_TIME_SHORT_BITSET_US 4
+#define KTD2692_TIME_LONG_BITSET_US12
+
+/* KTD2692 default length of name */
+#define KTD2692_NAME_LENGTH20
+
+/* KTD2692 default name */
+#define KTD2692_DEFAULT_NAME "ktd2692"
+
+enum ktd2692_bitset {
+ KTD2692_LOW = 0,
+ KTD2692_HIGH,
+};
+
+/* Movie / Flash Mode Control */
+enum ktd2692_led_mode {
+ KTD2692_MODE_DISABLE = 0, /* default */
+ KTD2692_MODE_MOVIE,
+ KTD2692_MODE_FLASH,
+};
+
+struct ktd2692_context {
+ /* Related LED Flash class device */
+ struct led_classdev_flash fled_cdev;
+
+ struct mutex lock;
+ struct regulator *regulator;
+ struct work_struct work_brightness_set;
+
+ int aux_gpio;
+ int ctrl_gpio;
+
+ enum ktd2692_led_mode mode;
+ enum led_brightness torch_brightness;
+};
+
+static struct ktd2692_context *fled_cdev_to_led(
+ struct led_classdev_flash *fled_cdev)
+{
+ return container_of(fled_cdev, struct ktd2692_context, fled_cdev);
+}
+
+static void ktd2692_led_regulator_enable(struct ktd2692_context *led)
+{
+ struct led_classdev_flash *fled_cdev = >fled_cdev;
+ struct led_classdev *led_cdev =
Re: [v2,2/2] powerpc32: add support for csum_add()
On Tue, Feb 03, 2015 at 12:39:27PM +0100, LEROY Christophe wrote: > The C version of csum_add() as defined in include/net/checksum.h gives the > following assembly: >0: 7c 04 1a 14 add r0,r4,r3 >4: 7c 64 00 10 subfc r3,r4,r0 >8: 7c 63 19 10 subfe r3,r3,r3 >c: 7c 63 00 50 subfr3,r3,r0 > > include/net/checksum.h also offers the possibility to define an arch specific > function. > This patch provides a ppc32 specific csum_add() inline function. What makes it 32-bit specific? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: powerpc32: rearrange instructions order in ip_fast_csum()
On Tue, Feb 03, 2015 at 12:39:27PM +0100, LEROY Christophe wrote: > On PPC_8xx, lwz has a 2 cycles latency, and branching also takes 2 cycles. > As the size of the header is minimum 5 words, we can unroll the loop for the > first words to reduce number of branching, and we can re-order the > instructions > to limit loading latency. Please wrap commit messages at around 70 characters. > Signed-off-by: Christophe Leroy > --- > arch/powerpc/lib/checksum_32.S | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S > index 6d67e05..5500704 100644 > --- a/arch/powerpc/lib/checksum_32.S > +++ b/arch/powerpc/lib/checksum_32.S > @@ -26,13 +26,17 @@ > _GLOBAL(ip_fast_csum) > lwz r0,0(r3) > lwzur5,4(r3) > - addic. r4,r4,-2 > + addic. r4,r4,-4 > addcr0,r0,r5 > mtctr r4 > blelr- > -1: lwzur4,4(r3) > - adder0,r0,r4 > + lwzur5,4(r3) > + lwzur4,4(r3) The blelr is pointless since len is guaranteed to be >= 5 (assuming that comment is accurate), but now it's both pointless and in the wrong place, since you haven't yet finished the four words that you subtracted from r4. How about keeping the blelr, without the -, moving it after the initial words, and changing the number of inital words to 5? Also maybe do all the loads up front, since many PPC chips have a three cycle load latency rather than two. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v8 24/30] PCI/tegra: Remove redundant tegra_pcie_scan_bus()
On 2015/3/24 20:31, Thierry Reding wrote: > On Tue, Mar 24, 2015 at 11:34:18AM +0800, Yijing Wang wrote: >> Now pci_scan_root_bus() is almost similar to >> pci_create_root_bus() + pci_scan_child_bus(). >> So we could use common pci_scan_root_bus() in >> pci_common_init_dev() to scan pci busses. >> tegra_pcie_scan_bus() is redundant, remove it. >> >> Signed-off-by: Yijing Wang >> CC: Thierry Reding >> CC: linux-te...@vger.kernel.org >> --- >> drivers/pci/host/pci-tegra.c | 16 >> 1 files changed, 0 insertions(+), 16 deletions(-) > > Jetson TK1 still boots over NFS root via the onboard PCIe network card > with this series applied, so: > > Tested-by: Thierry Reding > Acked-by: Thierry Reding Thanks! > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] input: synaptics: min_max quirk for Thinkpad E440
Sets min_max_quirk values for LEN2006 touchpad found in Lenovo Thinkpad E440
(board_id=2691).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=89641
Signed-off-by: Filip Ayazi
---
drivers/input/mouse/synaptics.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index dda6058..63942d4 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -154,6 +154,11 @@ static const struct min_max_quirk min_max_pnpid_table[] = {
},
{
(const char * const []){"LEN2006", NULL},
+ {2691, 2691},
+ 1024, 5045, 2457, 4832
+ },
+ {
+ (const char * const []){"LEN2006", NULL},
{ANY_BOARD_ID, ANY_BOARD_ID},
1264, 5675, 1171, 4688
},
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] irq: Remove unnecessary warning with affinity_hint
Hi, If you turn off a PCI device whose driver has set affinity_hint, you will get warning message which does _not_ explain the reason why it is appeared from the users' point of view. # echo 0 > /sys/bus/pci/slots/65/power Apr 28 20:29:39 localhost kernel: [ cut here ] Apr 28 20:29:39 localhost kernel: WARNING: at kernel/irq/manage.c:1002 __free_irq+0x22d/0x250() (Tainted: P --- ) (snip) Users will misunderstand some problem has happened even though he or she succeeded to turn off the device. I suppose this warning was originally for a debug purpose for driver developers and has incidentally been left. Just remove the warning is good and enough. Signed-off-by: Seiichi Ikarashi --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1335,7 +1335,7 @@ static struct irqaction *__free_irq(unsi #ifdef CONFIG_SMP /* make sure affinity_hint is cleaned up */ - if (WARN_ON_ONCE(desc->affinity_hint)) + if (desc->affinity_hint) desc->affinity_hint = NULL; #endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kdbus: Fix CONFIG_KDBUS help text
Hi On Tue, Mar 24, 2015 at 7:51 PM, Daniel Mack wrote: > Drop a left-over from the times when documentation lived in a > simple text file, which is no longer the case. Mention the > auto-generated man-pages and HTML files instead. > > Reported-by: Jiri Slaby > Signed-off-by: Daniel Mack > --- > > Thanks for reporting this, Jiri! Reviewed-by: David Herrmann Thanks David > > init/Kconfig | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/init/Kconfig b/init/Kconfig > index a7b462e..6bda631 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -268,10 +268,11 @@ config KDBUS > D-Bus is a system for low-latency, low-overhead, easy to use > interprocess communication (IPC). > > - See Documentation/kdbus.txt > + See the man-pages and HTML files in Documentation/kdbus/ > + that are generated by 'make mandocs' and 'make htmldocs'. > > - To compile this driver as a module, choose M here: the > - module will be called kdbus. > + If you have an ordinary machine, select M here. The module > + will be called kdbus. > > config CROSS_MEMORY_ATTACH > bool "Enable process_vm_readv/writev syscalls" > -- > 2.3.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 1/3] mm/vmalloc: fix possible exhaustion of vmalloc space caused by vm_map_ram allocator
> > In current patch I simply put newly allocated block to the tail of a free > list, > thus reduce fragmentation, giving a chance to resolve allocation request using > older blocks with possible holes left. It's great. I think this might be helpful for fragmentation by mix of long-time, short-time mappings. I do thank you for your work. > > Signed-off-by: Roman Pen > Cc: Andrew Morton > Cc: Eric Dumazet > Acked-by: Joonsoo Kim > Cc: David Rientjes > Cc: WANG Chao > Cc: Fabian Frederick > Cc: Christoph Lameter > Cc: Gioh Kim > Cc: Rob Jones > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > Cc: sta...@vger.kernel.org > --- > mm/vmalloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 39c3388..db6bffb 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -837,7 +837,7 @@ static struct vmap_block *new_vmap_block(gfp_t gfp_mask) > > vbq = _cpu_var(vmap_block_queue); > spin_lock(>lock); > - list_add_rcu(>free_list, >free); > + list_add_tail_rcu(>free_list, >free); > spin_unlock(>lock); > put_cpu_var(vmap_block_queue); > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/17] x86, fpu: wrap get_xsave_addr() to make it safer
On 03/24/2015 08:18 PM, Andy Lutomirski wrote: > On Tue, Mar 24, 2015 at 5:12 PM, Dave Hansen wrote: >> I won't completely claim to understand what's going on with the FPU >> code, but I think your analysis is a bit off. >> >> unlazy_fpu() does __save_init_fpu() which (among other things) calls >> xsave to dump the CPU registers to memory. That doesn't make any sense >> to do if "The in-memory copy and the CPU regs match." >> >> IOW, unlazy_fpu() is called when the in-memory copy is garbage and takes >> us to a state where we can look at the in-memory copy. > > I think that __save_init_fpu (called by unlazy_fpu) does that, but > __thread_fpu_end calls __thread_clear_has_fpu, which, in turn, zaps > fpu_owner_task, which will force an unnecessary xrstor. Or maybe not > if we have further bugs. Indeed, __save_init_fpu (yeah, terrible name) will save the in-register state to memory for you, so you can inspect it. Is there any reason not to rename __save_init_fpu to save_fpu_state, or just save_fpu? -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: vdso32/syscall.S: do not load __USER32_DS to %ss
On Tue, Mar 24, 2015 at 4:17 PM, Denys Vlasenko wrote: > On 03/24/2015 05:55 PM, Brian Gerst wrote: Might be nice to place a more generic description there, which registers are expected to be saved by user-space calling in here, etc. >>> >>> __kernel_vsyscall entry point has the same ABI in any 32-bit vDSO, >>> the good old int 0x80 calling convention: >>> >>> syscall# in eax, >>> params in ebx/ecx/edx/esi/edi/ebp, >>> all registers are preserved by the syscall. >>> >>> (I think we don't guarantee that all flags are preserved: >>> I have a testcase where DF gets cleared). >> >> DF should always be clear on any function call per the C ABI. But, >> eflags should be preserved, at least the non-privileged bits. I'd >> like to see that testcase. > > The testcase is a simplistic example of how to find and use > 32-bit vDSO to perform system calls. > > It also sets flags.DF before syscall, and checks whether registers > are preserved, including flags.DF. > > On 32-bit kernel (on Intel CPU, where vDSO uses SYSENTER), I see this: > > $ ./test32_syscall_vdso > Result:1 > > whereas on 64-bit it is > > ./test32_syscall_vdso > Result:0 > > "Result:1" means that DF was cleared. > > See attached source. > It looks like 32-bit native does not restore eflags before sysexit, while 64-bit compat does. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] led/led-class: Handle LEDs with the same name
Hi Ricardo,
(Cc Jacek.)
I had similar thoughts when reviewing Jacek's V4L2 flash API patches. See
below.
On Sat, Mar 14, 2015 at 12:05:39AM +0100, Ricardo Ribalda Delgado wrote:
> The current code expected that every LED had an unique name. This is a
> legit expectation when the device tree can no be modified or extended.
> But with device tree overlays this requirement can be easily broken.
>
> This patch finds out if the name is already in use and adds the suffix
> _1, _2... if not.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> v3: Suggested by Bryan Wu
>
> -Do not allocate dynamically the name
> drivers/leds/led-class.c | 31 +--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 768d33a..4ca37b8 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -212,6 +212,26 @@ static const struct dev_pm_ops leds_class_dev_pm_ops = {
> .resume = led_resume,
> };
>
> +static int match_name(struct device *dev, const void *data)
> +{
> + if (!dev_name(dev))
> + return 0;
> + return !strcmp(dev_name(dev), (char *)data);
> +}
> +
> +static int led_classdev_next_name(const char *init_name, char *name,
> + size_t len)
> +{
> + int i = 0;
> +
> + strncpy(name, init_name, len);
> +
> + while (class_find_device(leds_class, NULL, name, match_name))
> + snprintf(name, len, "%s_%d", init_name, ++i);
> +
> + return i;
> +}
> +
> /**
> * led_classdev_register - register a new object of led_classdev class.
> * @parent: The device to register.
> @@ -219,12 +239,19 @@ static const struct dev_pm_ops leds_class_dev_pm_ops = {
> */
> int led_classdev_register(struct device *parent, struct led_classdev
> *led_cdev)
> {
> + char name[64];
> + int ret;
> +
> + ret = led_classdev_next_name(led_cdev->name, name, sizeof(name));
> led_cdev->dev = device_create_with_groups(leds_class, parent, 0,
> - led_cdev, led_cdev->groups,
> - "%s", led_cdev->name);
> + led_cdev, led_cdev->groups, name);
> if (IS_ERR(led_cdev->dev))
> return PTR_ERR(led_cdev->dev);
>
> + if (ret)
> + dev_info(parent, "Led %s renamed to %s due to name collision",
> + led_cdev->name, dev_name(led_cdev->dev));
I'd use dev_warn() or even WARN_ON(ret). This is a rather serious issue as
now the probe order defines the name of the device. There might be something
better such as the I2C bus/address.
If the registration order for some reason changes, that'd revert the device
names. In Media controller this is part of the user space API.
I suggested Jacek adding the uniqueness requirement to documentation as
well, ePAPR by itself does not require it for label properties.
> +
> #ifdef CONFIG_LEDS_TRIGGERS
> init_rwsem(_cdev->trigger_lock);
> #endif
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/11] x86/xip: resolve alternative instructions at build
On Mon, Mar 23, 2015 at 09:33:02AM +0100, Borislav Petkov wrote: > On Mon, Mar 23, 2015 at 12:46:39AM -0700, Jim Kukunas wrote: > > Since the .text section can't be updated at run-time, remove the > > .alternatives sections and update the .text at build time. To pick the > > proper instructions, Kconfig options are exposed for each X86_FEATURE > > that needed to be resolved. Each X86_FEATURE gets a corresponding > > CONFIG_XIP_ENABLE_X86_FEATURE_ option. Based on whether this option > > is set, a resolver macro is setup to either generate that instruction, > > or the fallback. The resolver needs to be defined for each FEATURE, and > > the proper one is chosen via preprocessor string pasting. > > > > This approach is horrific and ugly. > > You said it. > > And with XIP enabled - whatever that means, your announce message could > explain a lot more and more verbosely what this whole patchset is all > about - this kernel is not going to be generic anymore but it will be > destined only for the machine it is being built for, correct? Please see my response to Ingo for more information about the patchset. Yes, regardless of how it's implemented, selecting alternatives at build time will produce a non-generic kernel (unless all alternative instructions are disabled and just the fallbacks are used). > If that is so, how are distros supposed to ship one kernel with XIP or > is this some obscure feature distros won't have to enable anyway? XIP isn't a general feature that distros are going to be enabling. It's designed for a very specific usage where people are building very custom kernels. > Concerning this particular patch, I'd suggest a switch which simply > disables alternatives patching at run time so that you don't add this > ifdeffery to alternative.c I'll look into this. > Btw, why do you even have to disable the alternatives? I see this in > your patch 1/11: > > + location in RAM. As a result, when the kernel is located in storage > + that is addressable by the CPU, the kernel text and read-only data > + segments are never loaded into memory, thereby using less RAM. > > is this it? To save some memory? Probably embedded, maybe some light > bulb running linux... Yuck. Alternatives are disabled because the kernel text will be read-only. For example, consider the kernel image being stored in and executing from ROM. Cutting the kernel text and read-only data out of RAM really helps Linux scale down to smaller systems. So yes, it's for embedded. Linux has a lot to offer in that area. Thanks. -- Jim Kukunas Intel Open Source Technology Center pgpnw8LNDbWIa.pgp Description: PGP signature
[PATCH 1/1] hfsplus: incorrect return value
In case of memory allocation error, the return should be -ENOMEM,
instead of -ENOSPC.
Signed-off-by: Chengyu Song
---
fs/hfsplus/dir.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/hfsplus/dir.c b/fs/hfsplus/dir.c
index f0235c1..3074609 100644
--- a/fs/hfsplus/dir.c
+++ b/fs/hfsplus/dir.c
@@ -434,7 +434,7 @@ static int hfsplus_symlink(struct inode *dir, struct dentry
*dentry,
{
struct hfsplus_sb_info *sbi = HFSPLUS_SB(dir->i_sb);
struct inode *inode;
- int res = -ENOSPC;
+ int res = -ENOMEM;
mutex_lock(>vh_mutex);
inode = hfsplus_new_inode(dir->i_sb, S_IFLNK | S_IRWXUGO);
@@ -476,7 +476,7 @@ static int hfsplus_mknod(struct inode *dir, struct dentry
*dentry,
{
struct hfsplus_sb_info *sbi = HFSPLUS_SB(dir->i_sb);
struct inode *inode;
- int res = -ENOSPC;
+ int res = -ENOMEM;
mutex_lock(>vh_mutex);
inode = hfsplus_new_inode(dir->i_sb, mode);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: lz4: fix system halted at boot kernel x86_64 compressed lz4
On Tue, Mar 24, 2015 at 12:27:25PM +0100, Krzysztof Kolasa wrote: > lz4: fix system halted at boot kernel x86_64 compressed lz4 > > Decompression process ends with an error when loading kernel: > > Decoding failed > -- System halted Serious regression detected ... > > This condition is probably not needed ( from the last commit d5e7caf) : The offending patch is on the way to stable trees, so it would be best to postpone it for now. > if( ... || > (op + COPYLENGTH) > oend) > goto _output_error > > macro LZ4_SECURE_COPY() tests op and does not copy any data > when op exceeds the value, decompression process is continued. > > added by analogy security for the ref: > > if ((ref + COPYLENGTH) > oend... > > to lz4_uncompress_unknownoutputsize(...) I did only a quick check, your analysis seems correct. Reviewing the lz4 patches is tedious as the kernel implementations do not match the upstream one line-by-line besides that I've missed the side effects of the macro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 11/24] huge tmpfs: shrinker to migrate and free underused holes
On Tue, 24 Mar 2015, Kirill A. Shutemov wrote:
> On Sun, Mar 22, 2015 at 09:40:02PM -0700, Hugh Dickins wrote:
> > (I think Kirill has a problem of that kind in his page_remove_rmap scan).
(And this one I mentioned to you at the conference :)
> >
> > It will be interesting to see what Kirill does to maintain the stats
> > for huge pagecache: but he will have no difficulty in finding fields
> > to store counts, because he's got lots of spare fields in those 511
> > tail pages - that's a useful benefit of the compound page, but does
> > prevent the tails from being used in ordinary ways. (I did try using
> > team_head[1].team_usage for more, but atomicity needs prevented it.)
>
> The patch below should address the race you pointed, if I've got all
> right. Not hugely happy with the change though.
Yes, without thinking too hard about it, something like what you have
below should do it. Not very pretty; maybe a neater idea will come up.
Hugh
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 435c90f59227..a3e6b35520f8 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -423,8 +423,17 @@ static inline void page_mapcount_reset(struct page *page)
>
> static inline int page_mapcount(struct page *page)
> {
> + int ret;
> VM_BUG_ON_PAGE(PageSlab(page), page);
> - return atomic_read(>_mapcount) + compound_mapcount(page) + 1;
> + ret = atomic_read(>_mapcount) + 1;
> + if (compound_mapcount(page)) {
> + /*
> + * positive compound_mapcount() offsets ->_mapcount by one --
> + * substract here.
> + */
> +ret += compound_mapcount(page) - 1;
> + }
> + return ret;
> }
>
> static inline int page_count(struct page *page)
> diff --git a/mm/rmap.c b/mm/rmap.c
> index fc6eee4ed476..f4ab976276e7 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1066,9 +1066,17 @@ void do_page_add_anon_rmap(struct page *page,
>* disabled.
>*/
> if (compound) {
> + int i;
> VM_BUG_ON_PAGE(!PageTransHuge(page), page);
> __inc_zone_page_state(page,
> NR_ANON_TRANSPARENT_HUGEPAGES);
> + /*
> + * While compound_mapcount() is positive we keep *one*
> + * mapcount reference in all subpages. It's required
> + * for atomic removal from rmap.
> + */
> + for (i = 0; i < nr; i++)
> + atomic_set([i]._mapcount, 0);
> }
> __mod_zone_page_state(page_zone(page), NR_ANON_PAGES, nr);
> }
> @@ -1103,10 +,19 @@ void page_add_new_anon_rmap(struct page *page,
> VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
> SetPageSwapBacked(page);
> if (compound) {
> + int i;
> +
> VM_BUG_ON_PAGE(!PageTransHuge(page), page);
> /* increment count (starts at -1) */
> atomic_set(compound_mapcount_ptr(page), 0);
> __inc_zone_page_state(page, NR_ANON_TRANSPARENT_HUGEPAGES);
> + /*
> + * While compound_mapcount() is positive we keep *one* mapcount
> + * reference in all subpages. It's required for atomic removal
> + * from rmap.
> + */
> + for (i = 0; i < nr; i++)
> + atomic_set([i]._mapcount, 0);
> } else {
> /* Anon THP always mapped first with PMD */
> VM_BUG_ON_PAGE(PageTransCompound(page), page);
> @@ -1174,9 +1191,6 @@ out:
> */
> void page_remove_rmap(struct page *page, bool compound)
> {
> - int nr = compound ? hpage_nr_pages(page) : 1;
> - bool partial_thp_unmap;
> -
> if (!PageAnon(page)) {
> VM_BUG_ON_PAGE(compound && !PageHuge(page), page);
> page_remove_file_rmap(page);
> @@ -1184,10 +1198,20 @@ void page_remove_rmap(struct page *page, bool
> compound)
> }
>
> /* page still mapped by someone else? */
> - if (!atomic_add_negative(-1, compound ?
> -compound_mapcount_ptr(page) :
> ->_mapcount))
> + if (compound) {
> + int i;
> +
> + VM_BUG_ON_PAGE(!PageTransHuge(page), page);
> + if (!atomic_add_negative(-1, compound_mapcount_ptr(page)))
> + return;
> + __dec_zone_page_state(page, NR_ANON_TRANSPARENT_HUGEPAGES);
> + for (i = 0; i < hpage_nr_pages(page); i++)
> + page_remove_rmap(page + i, false);
> return;
> + } else {
> + if (!atomic_add_negative(-1, >_mapcount))
> + return;
> + }
>
> /* Hugepages are not counted in NR_ANON_PAGES for now. */
> if (unlikely(PageHuge(page)))
> @@
Re: bpf+tracing next steps. Was: [PATCH v9 tip 3/9] tracing: attach BPF programs to kprobes
On 3/23/15 2:27 AM, Masami Hiramatsu wrote:
> (2015/03/23 13:57), Alexei Starovoitov wrote:
>> On 3/22/15 7:17 PM, Masami Hiramatsu wrote:
>>> (2015/03/23 3:03), Alexei Starovoitov wrote:
>>>
User space tools that will compile ktap/dtrace scripts into bpf might
use build-id for their own purpose, but that's a different discussion.
>>>
>>> Agreed.
>>> I'd like to discuss it since kprobe event interface may also have same
>>> issue.
>>
>> I'm not sure what 'issue' you're seeing. My understanding is that
>> build-ids are used by perf to associate binaries with their debug info
>> and by systemtap to make sure that probes actually match the kernel
>> they were compiled for. In bpf case it probably will be perf way only.
>
> Ah, I see. So perftools can check the build-id if needed, right?
yes. of course.
>> Are you interested in doing something with bpf ? ;)
>
> Of course :)
Great :)
>> I know that Jovi is working on clang-based front-end, He Kuang is doing
>> something fancy and I'm going to focus on 'tcp instrumentation' once
>> bpf+kprobes is in. I think these efforts will help us make it
>> concrete and will establish a path towards bpf+tracepoints
>> (debug tracepoints or trace markers) and eventual integration with perf.
>> Here is the wish-list (for kernel and userspace) inspired by Brendan:
>> - access to pid, uid, tid, comm, etc
>> - access to kernel stack trace
>> - access to user-level stack trace
>> - kernel debuginfo for walking kernel structs, and accessing kprobe
>> entry args as variables
>
> perf probe can provide this to bpf.
I was thinking about deeper integration with perf actually.
perf has all the right infra to find debug info in kernel and user
binaries, to extract and understand all the dwarf stuff.
The future tracing language can use more of it.
The programs should be able refer to names of in-kernel variables
and arguments natively.
When I'm writing a program that attaches to blk_update_request()
I would like to write:
bpf_printk("req %p bytes %d\n", req->q, nr_bytes);
and perf with debug info should be able to figure out that 'req'
is the first function argument, then find out offset of '->q'
within the struct and that 'nr_bytes' is the 3rd argument in
appropriate register. Then generate llvm ir on the fly,
compile it, load into kernel and attach to kprobe event at
this blk_update_request() function. All seamlessly.
>> - tracing of uprobes
>> - tracing of user markers
>
> I'm working on the perf-cache which will also support SDT (based on Hemant
> Kumar's work).
yep. waiting for SDT stuff to finalize. Would be nice to
have 'follow' button for interesting patches :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] hfs: incorrect return values
In case of memory allocation error, the return should be -ENOMEM,
instead of -ENOSPC.
Signed-off-by: Chengyu Song
---
fs/hfs/dir.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c
index 1455668..36d1a6a 100644
--- a/fs/hfs/dir.c
+++ b/fs/hfs/dir.c
@@ -197,7 +197,7 @@ static int hfs_create(struct inode *dir, struct dentry
*dentry, umode_t mode,
inode = hfs_new_inode(dir, >d_name, mode);
if (!inode)
- return -ENOSPC;
+ return -ENOMEM;
res = hfs_cat_create(inode->i_ino, dir, >d_name, inode);
if (res) {
@@ -226,7 +226,7 @@ static int hfs_mkdir(struct inode *dir, struct dentry
*dentry, umode_t mode)
inode = hfs_new_inode(dir, >d_name, S_IFDIR | mode);
if (!inode)
- return -ENOSPC;
+ return -ENOMEM;
res = hfs_cat_create(inode->i_ino, dir, >d_name, inode);
if (res) {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/5] power: max77843_charger: Add Max77843 charger device driver
On 03/24/2015 05:38 PM, Krzysztof Kozlowski wrote: > 2015-03-24 9:01 GMT+01:00 Beomho Seo : >> On 03/10/2015 10:44 PM, Beomho Seo wrote: >>> On 03/09/2015 09:13 PM, Krzysztof Kozlowski wrote: On pon, 2015-03-09 at 20:46 +0900, Beomho Seo wrote: > On 03/09/2015 08:02 PM, Krzysztof Kozlowski wrote: >> 2015-03-09 1:35 GMT+01:00 Beomho Seo : >>> On 03/08/2015 05:13 AM, Sebastian Reichel wrote: On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote: > From: Beomho Seo > > This patch adds device driver of max77843 charger. This driver provide > initialize each charging mode(e.g. fast charge, top-off mode and > constant > charging mode so on.). Additionally, control charging paramters to use > i2c interface. > > Cc: Sebastian Reichel > Signed-off-by: Beomho Seo Reviewed-By: Sebastian Reichel I can't take it as is, since it depends on the private header file of PATCHv1. -- Sebastian >>> >>> This patch reviewed by Sebastian. >>> Could you Please merge that your git tree ? >> >> Hi, >> >> ... and again we are adding a new driver for very similar chipset to >> already supported. I looked at spec and the charger's registers are >> almost the same as for max77693. Their layout and addresses are the >> same. I see some minor differences, probably the most important would >> be different values current (fast-charge, top-off). But still 90% of >> registers are the same... Do we really have to add new driver? >> >> Best regards, >> Krzysztof >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-input" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > Hi, > > Thank you for your comment. As you say, both chip set are similar. > But new driver need for support max77843. It is support different below > - Provide Battery presence information. Another set of power supply properties could be added for that chip. This way the get_property() function would be the same but actually the POWER_SUPPLY_PROP_PRESENT won't be called for max77693. > - Can OTG FET control. Where the OTG FET feature is it enabled in your driver? I couldn't find it. >>> >>> Sorry. This driver don't control OTG FET feature. >>> > - Bigger Fast charge current, Top Off current Threshold selection. > - Various and bigger OTG current limitation. > - Bigger primary charger termination voltage setting. > - Different maximum input current limit selection(Different step). Yes, I mentioned some of these differences (the Fast/top-off differences). These are differences in values so it does not require new driver. There is need to develop new driver just to support different current (3.0 A instead of 2.1 A) or voltage threshold. >>> >>> They are different charging current, OTG current limitation, top off >>> current, >>> charging limitation value. In case OTG current limitation different not >>> limitation value but using register bit(max77843 use[7:6] max77693 use[7] >>> bit only). Even if this driver not support all feature, some register >>> different with max77693(support value, use register bit). >>> >>> If this driver will combined with max77693 may even be beneficial for >>> new Maxim driver. But the present, this driver is related with >>> max77843 core driver and max77843-regulator. So I hope this driver >>> merge first. And then will extend two driver(max77843 charger and max77693 >>> charger). > > I still prefer merging common drivers into one instead of creating > some more of them. > However I understand your point and I am not entirely opposed against. > Especially that you invested quite a bit of time for developing this > and my feedback was quite late. To summarize I am fine with your > approach. > > Best regards, > Krzysztof > Then, Can I request merge this patch ? Best regards, Beomho -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, entry: Check for syscall exit work with IRQs disabled
On Tue, Mar 24, 2015 at 1:08 PM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> We currently have a race: if we're preempted during syscall exit, we
>> can fail to process syscall return work that is queued up while
>> we're preempted in ret_from_sys_call after checking ti.flags.
>>
>> Fix it by disabling interrupts before checking ti.flags.
>>
>> Fixes: 96b6352c1271 x86_64, entry: Remove the syscall exit audit and
>> schedule optimizations
>> Reported-by: Stefan Seyfried
>> Reported-by: Takashi Iwai
>> Signed-off-by: Andy Lutomirski
>> ---
>>
>> Ingo, I don't understand the LOCKDEP_SYS_EXIT stuff. Can you take a quick
>> look to confirm that it's okay to call it more than once?
>
> So the essence is that it wants to print this warning if we are
> holding a lock after a syscall:
>
> printk("[ BUG: lock held when returning to user space! ]\n");
>
> it manipulates no state and is not sensitive to whether it's called
> before or after return-work processing.
>
>> arch/x86/kernel/entry_64.S | 18 ++
>> 1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
>> index 1d74d161687c..2babb393915e 100644
>> --- a/arch/x86/kernel/entry_64.S
>> +++ b/arch/x86/kernel/entry_64.S
>> @@ -364,12 +364,21 @@ system_call_fastpath:
>> * Has incomplete stack frame and undefined top of stack.
>> */
>> ret_from_sys_call:
>> - testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
>> - jnz int_ret_from_sys_call_fixup /* Go the the slow path */
>> -
>> LOCKDEP_SYS_EXIT
>> DISABLE_INTERRUPTS(CLBR_NONE)
>> TRACE_IRQS_OFF
>> +
>> + /*
>> + * We must check ti flags with interrupts (or at least preemption)
>> + * off because we must *never* return to userspace without
>> + * processing exit work that is enqueued if we're preempted here.
>> + * In particular, returning to userspace with any of the one-shot
>> + * flags (TIF_NOTIFY_RESUME, TIF_USER_RETURN_NOTIFY, etc) set is
>> + * very bad.
>> + */
>> + testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
>> + jnz int_ret_from_sys_call_fixup /* Go the the slow path */
>
> Should be safe to call it once again after user-work processing has
> been finished.
>
> I've picked up your fix for tip:x86/urgent.
FWIW, the tentative merge here:
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=tmp.tmp=a77dd1607ad88a601259a74ba4d646fa68b7cd9a
looks funny. Why aren't you jumping to int_ret_from_sys_call_irqs_off?
--Andy
>
> Thanks,
>
> Ingo
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] dmaengine: Introduce scheduled DMA framework
On Tue, Mar 24, 2015 at 09:50:43PM +0530, Vinod Koul wrote:
> On Mon, Mar 23, 2015 at 02:51:40PM -0700, Maxime Ripard wrote:
> > > > + if (vd) {
> > > > + lli = desc->v_lli;
> > > > + while (true) {
> > > > + bytes += sdma->ops->lli_size(lli);
> > > > +
> > > > + if (!sdma->ops->lli_has_next(lli))
> > > > + break;
> > > > +
> > > > + lli = sdma->ops->lli_next(lli);
> > >
> > > wouldn't it be nicer to just use a link list here which is embedded
> > > in a generic struct which in turn can be embedded in a driver
> > > specific one, so we actually don't care what driver specific
> > > implementation is...
> >
> > I'm not sure to get what you mean here. We will always have to care
> > about the driver specific implementation.
>
> by providing a callback driver can do whatever it wants whereas the framework
> does generic stuff
It's kind of the whole point. LLI can be either actual list, maps,
tables, or even not supported by hardware at all and should be
emulated.
On this, letting the driver do whatever is needed seems like a good
thing.
> > > that way we cna get rid of lli_size and lli_has_next and lli_next
> > > ones. Further that will allow drivers/framework to break a txn into
> > > multiple smaller txns internally.
> >
> > I chose this accessors/iterators pattern because it actually make this
> > very easy to add new features on the LLI (like debugging, we just have
> > to add a new lli_dump) and that works.
> >
> > We can also manage more easily the LLI, by allocating ourself the LLI
> > items, and freeing it afterwards, which is something that also is
> > often wrong, or at least addressed in different ways from one driver
> > to another (for example, the Atmel drivers have their own descriptor
> > allocation logic, while the others mostly rely on the dma_pools. Which
> > one is right, I don't know, but the right one should be shared by
> > everyone).
> >
> > That would also be much easier to add software-emulated LLI, since you
> > just have to set the lli management functions to some common library
> > functions, and we're done.
> >
> > I feel like it would be much more flexible, and would remove logic
> > from the driver itself, which is the point of this whole
> > "sub-framework".
>
> Yes the intent is right, I was thinking that using a kernel link frees us
> from managing the list, lesser chances of bugs that way
A generic structure embedded in a driver specific structure wouldn't
even cover all cases. For example, in tx_status, we do want to access
the hardware descriptor size, and possibly iterate over the LLI
itself, so we would still have to have some accessors and iterators.
Given that, I'm not sure that duplicating this info in several places
is a good idea.
> > > typically driver would do calculations for descriptor setting up the
> > > registers values which cna be programmed, so a driver callback would be
> > > nice
> > > here. That way lesser work in start function and which is good as I am
> > > assuming start should be done from irq context
> >
> > I'm not really sure that would make sense. You don't have the
> > guarantee that the dma_chan pointer you are passing to it is actually
> > mapped to a physical channel at this time.
> >
> > And I thought that the prep functions could be called from irq context
> > too?
>
> Yes that is true but if you have descriptor prepared and only need to
> program the hw that it is the fastest way. Plus the HW is idle so faster we
> can submit a new transaction the better it is.
You don't really know at this point whether the hardware is idle, or
on which channel it's actually going to be scheduled to.
If it's just to prepare and store some registers value, I guess it
might make sense. I don't really know to what should we attach this
kind of precomputed values, to the request? the descriptor? the LLI
itself?
> Btw the recommendation is that new txn should be submitted in ISR
> and not wait till tasklet, most driver do latter with few doing
> former.
Yes, that's one of the things that my driver took into account, since
most drivers get this wrong (including the one I wrote).
sdma_report is expected to be called from an interrupt context, and
will try to find a new descriptor to run on the channel which just got
reported as free. If such a descriptor is available, it will return it
to the driver, that is expected to run it on that channel.
Otherwise, we just put the channel back in the available list for
future use.
> The computation part of registers to be programmed should be anyway
> independent of channel, while actual programming and starting of channel we
> need to ensure right channel and thereby offsets are used :)
Yep, that part is hopefully covered :)
> > > Also this needs to take into account the dma_slave_config, which is
> > > allowed
> > > to me modified for subsequent txns
> >
> > memcpy
Re: [PATCH] staging: rtl8723au: Update RT_TRACE macro and uses
On Tue, 2015-03-24 at 20:28 -0400, Jes Sorensen wrote: > Joe Perches writes: > > Create an rt_trace function using %pV to reduce overall code size. > > Update the macro uses to remove unnecessary and now harmful parentheses. [] > This could be further improved by fixing up all the places where the > function name is hard coded into the print statement, instead of using > __func__. In particular as a lot of it is carried over from old code > and has been renamed since. There's a cocci script for that. http://cocci.systeme.lip6.narkive.com/nKXf6Bmy/finding-embedded-function-names I expect someone will run it one day on staging. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: iproc: fix PCIE_IPROC in Kconfig
On Tue, Mar 24, 2015 at 12:33 AM, Ray Jui wrote: > Make PCIE_IPROC depending on both OF and ARM and default to be disabled, > so it cannot be accidentally enabled by other platforms > > PCIE_IPROC is meant to be enabled by a front-end bus driver. Curenntly > it's enabled by PCIE_IPROC_PLTFM driver > > Signed-off-by: Ray Jui > --- > drivers/pci/host/Kconfig |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig > index feccd0d..963b507 100644 > --- a/drivers/pci/host/Kconfig > +++ b/drivers/pci/host/Kconfig > @@ -108,6 +108,8 @@ config PCI_VERSATILE > > config PCIE_IPROC > tristate "Broadcom iProc PCIe controller" > + depends on OF && ARM > + default n > help > This enables the iProc PCIe core controller support for Broadcom's > iProc family of SoCs. An appropriate bus interface driver also needs What pattern are you following? There must be other drivers with similar front-end bus driver schemes, and I'd rather copy their Kconfig descriptions than invent something new. With CONFIG_PCIE_IPROC_PLTFM, can we spell out "PLATFORM"? Doesn't seem like there's anything to gain by abbreviating it. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8723au: Update RT_TRACE macro and uses
Joe Perches writes: > Create an rt_trace function using %pV to reduce overall code size. > Update the macro uses to remove unnecessary and now harmful parentheses. > > Miscellanea around these changes: > > o Coalesce formats > o Realign arguments > o Remove commented-out RT_TRACE uses > o Spelling fixes in formats > o Add missing newlines to formats > o Remove multiple newlines from formats > o Neaten formats where noticed > o Use %pM in one instance > > Reduces code size ~20KB > > Signed-off-by: Joe Perches > --- > Mostly done by various scripts > Compiled, untested, no hardware, This could be further improved by fixing up all the places where the function name is hard coded into the print statement, instead of using __func__. In particular as a lot of it is carried over from old code and has been renamed since. It's OK with me to do this in a follow-on patch though. Jes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 8/9] eeprom: qfprom: Add bindings for qfprom
On Tue, Mar 24, 2015 at 11:31 PM, Srinivas Kandagatla
wrote:
> This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
> is based on simple eeprom framework.
>
> Signed-off-by: Srinivas Kandagatla
> ---
> .../devicetree/bindings/eeprom/qfprom.txt | 23
> ++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/eeprom/qfprom.txt
>
> diff --git a/Documentation/devicetree/bindings/eeprom/qfprom.txt
> b/Documentation/devicetree/bindings/eeprom/qfprom.txt
> new file mode 100644
> index 000..d5baed6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/eeprom/qfprom.txt
> @@ -0,0 +1,23 @@
> += Qualcomm QFPROM device tree bindings =
> +
> +This binding is intended to represent QFPROM which is found in most QCOM
> SOCs.
> +
> +Required properties:
> +- compatible: should be "qcom,qfprom"
> +- reg: Should contain registers location and length
> +
> += Data cells =
> +Are child nodes of qfprom, bindings of which as described in
> +bindings/eeprom/eeprom.txt
> +
> +Example:
> +
> + qfprom: qfprom@0070 {
> + compatible = "qcom,qfprom";
> + reg = <0x0070 0x1000>;
The qfprom block starts at 0x70 and is 0x8000 long.
The registers at the beginning of this block are raw R/W fuse bits and
should not be read directly. Instead there is an ecc corrected shadow
copy of these registers at 0x4000.
> + ...
> + /* Data cells */
> + tsens_calibration: calib@404 {
> + reg = <0x404 0x10>;
> + };
> + };
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cifs: potential missing check for posix_lock_file_wait
posix_lock_file_wait may fail under certain circumstances, and its result is usually checked/returned. But given the complexity of cifs, I'm not sure if the result is intentially left unchecked and always expected to succeed. Signed-off-by: Chengyu Song --- fs/cifs/file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/cifs/file.c b/fs/cifs/file.c index a94b3e6..beef67b 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -1553,8 +1553,8 @@ cifs_setlk(struct file *file, struct file_lock *flock, __u32 type, rc = server->ops->mand_unlock_range(cfile, flock, xid); out: - if (flock->fl_flags & FL_POSIX) - posix_lock_file_wait(file, flock); + if (flock->fl_flags & FL_POSIX && !rc) + rc = posix_lock_file_wait(file, flock); return rc; } -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/17] x86, fpu: wrap get_xsave_addr() to make it safer
[add Borislav] I swear it would actually be an improvement if we just randomized the function names. fpu_817, fpu_717, etc. At least no one would think they understand them... On Tue, Mar 24, 2015 at 5:18 PM, Andy Lutomirski wrote: > On Tue, Mar 24, 2015 at 5:12 PM, Dave Hansen wrote: >> On 03/24/2015 04:52 PM, Andy Lutomirski wrote: >>> On Tue, Mar 24, 2015 at 4:42 PM, Dave Hansen wrote: On 03/24/2015 03:28 PM, Andy Lutomirski wrote: > Your function appears to be getting it for write (I assume that's what > the unlazy_fpu is for), so I'd rather have it called > tsk_get_xsave_field_for_write or something like that. It should be entirely read-only. For MPX (the only user of get_xsave_addr() iirc), we are only worried about getting the status codes (and addresses) out of the bndstatus register and making sure that the kernel-recorded bounds directory address matches the bndcfgu (configuration) register. We don't ever write to the registers. >>> >>> So why are you unlazying it? >> >> Oleg actually suggested it. >> >>> IIUC, the xstae for current can be in one of three logical states: >>> >>> 1. Live in CPU regs. The in-memory copy is garbage and the state is >>> in CPU regs. >>> 2. Lazy. The in-memory copy and the CPU regs match. Writing to >>> either copy is illegal. >>> 3. In memory only. Writing to the in-memory copy is safe. >>> >>> IIUC, you want to read the xstate, do you're okay with #2 or #3. This >>> would be tsk_get_xsave_field_for_read in my terminology. >>> >>> If you want to write the xstate, you'd need to be in state #3, which >>> would be tsk_get_xsave_field_for_write. >>> >>> IIUC, unlazy_fpu just moves from from state 2 to 3. >> >> I won't completely claim to understand what's going on with the FPU >> code, but I think your analysis is a bit off. >> >> unlazy_fpu() does __save_init_fpu() which (among other things) calls >> xsave to dump the CPU registers to memory. That doesn't make any sense >> to do if "The in-memory copy and the CPU regs match." >> >> IOW, unlazy_fpu() is called when the in-memory copy is garbage and takes >> us to a state where we can look at the in-memory copy. > > I think that __save_init_fpu (called by unlazy_fpu) does that, but > __thread_fpu_end calls __thread_clear_has_fpu, which, in turn, zaps > fpu_owner_task, which will force an unnecessary xrstor. Or maybe not > if we have further bugs. > > Holy crap these functions are poorly named. Also, what, if anything, > guarantees that fpu_owner_task is set on entry to userspace? Do we > even need it to be set? Oleg, help? > > --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/
[PATCH 1/3] Documentation: bindings: add BCM6328-style soft reset binding
Add a binding document for the BCM6328-style software reset block found
in MIPS and ARM based Broadcom BCM63xx DSL SoCs.
Signed-off-by: Florian Fainelli
---
Documentation/devicetree/bindings/arm/bcm/bcm63138.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm63138.txt
b/Documentation/devicetree/bindings/arm/bcm/bcm63138.txt
index bd49987a8812..bddf76d8dda4 100644
--- a/Documentation/devicetree/bindings/arm/bcm/bcm63138.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm63138.txt
@@ -7,3 +7,19 @@ following properties:
Required root node property:
compatible: should be "brcm,bcm63138"
+
+
+reboot node
+---
+
+Required properties
+
+- compatible: sould be "brcm,bcm6328-soft-reset"
+- reg: should be the base register addresse and length
+
+Example:
+
+reboot@b0 {
+ compatible = "brcm,bcm6328-soft-reset";
+ reg = <0xb0 0x4>;
+};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: dts: BCM63xx: add soft-reset node
Add the software reset Device Tree node allowing us to software reset a
BCM63138 device using bcm6328-soft-reset.
Signed-off-by: Florian Fainelli
---
arch/arm/boot/dts/bcm63138.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm63138.dtsi b/arch/arm/boot/dts/bcm63138.dtsi
index f46329c8ad75..cfd7f67fed02 100644
--- a/arch/arm/boot/dts/bcm63138.dtsi
+++ b/arch/arm/boot/dts/bcm63138.dtsi
@@ -114,6 +114,11 @@
#size-cells = <1>;
ranges = <0 0xfffe8000 0x8100>;
+ reset: soft-reset@b4 {
+ compatible = "brcm,bcm6328-soft-reset";
+ reg = <0xb4 0x4>;
+ };
+
serial0: serial@600 {
compatible = "brcm,bcm6345-uart";
reg = <0x600 0x1b>;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] power: reset: BCM63xx reboot support
Hi all, This patch series adds support for the BCM6328-style software reset hardware block commonly found on Broadcom BCM63xx DSL SoCs. Thanks! Florian Fainelli (3): Documentation: bindings: add BCM6328-style soft reset binding power: reset: add Broadcom BCM63xx software reset driver ARM: dts: BCM63xx: add soft-reset node .../devicetree/bindings/arm/bcm/bcm63138.txt | 16 + arch/arm/boot/dts/bcm63138.dtsi| 5 ++ drivers/power/reset/Kconfig| 7 ++ drivers/power/reset/Makefile | 1 + drivers/power/reset/bcm63xx-reboot.c | 80 ++ 5 files changed, 109 insertions(+) create mode 100644 drivers/power/reset/bcm63xx-reboot.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/17] x86, fpu: wrap get_xsave_addr() to make it safer
On Tue, Mar 24, 2015 at 5:12 PM, Dave Hansen wrote: > On 03/24/2015 04:52 PM, Andy Lutomirski wrote: >> On Tue, Mar 24, 2015 at 4:42 PM, Dave Hansen wrote: >>> On 03/24/2015 03:28 PM, Andy Lutomirski wrote: Your function appears to be getting it for write (I assume that's what the unlazy_fpu is for), so I'd rather have it called tsk_get_xsave_field_for_write or something like that. >>> >>> It should be entirely read-only. >>> >>> For MPX (the only user of get_xsave_addr() iirc), we are only worried >>> about getting the status codes (and addresses) out of the bndstatus >>> register and making sure that the kernel-recorded bounds directory >>> address matches the bndcfgu (configuration) register. >>> >>> We don't ever write to the registers. >> >> So why are you unlazying it? > > Oleg actually suggested it. > >> IIUC, the xstae for current can be in one of three logical states: >> >> 1. Live in CPU regs. The in-memory copy is garbage and the state is >> in CPU regs. >> 2. Lazy. The in-memory copy and the CPU regs match. Writing to >> either copy is illegal. >> 3. In memory only. Writing to the in-memory copy is safe. >> >> IIUC, you want to read the xstate, do you're okay with #2 or #3. This >> would be tsk_get_xsave_field_for_read in my terminology. >> >> If you want to write the xstate, you'd need to be in state #3, which >> would be tsk_get_xsave_field_for_write. >> >> IIUC, unlazy_fpu just moves from from state 2 to 3. > > I won't completely claim to understand what's going on with the FPU > code, but I think your analysis is a bit off. > > unlazy_fpu() does __save_init_fpu() which (among other things) calls > xsave to dump the CPU registers to memory. That doesn't make any sense > to do if "The in-memory copy and the CPU regs match." > > IOW, unlazy_fpu() is called when the in-memory copy is garbage and takes > us to a state where we can look at the in-memory copy. I think that __save_init_fpu (called by unlazy_fpu) does that, but __thread_fpu_end calls __thread_clear_has_fpu, which, in turn, zaps fpu_owner_task, which will force an unnecessary xrstor. Or maybe not if we have further bugs. Holy crap these functions are poorly named. Also, what, if anything, guarantees that fpu_owner_task is set on entry to userspace? Do we even need it to be set? Oleg, help? --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] power: reset: add Broadcom BCM63xx software reset driver
Add a sofware reset driver for the Broadcom BCM63xx DSL SoCs, starting
with 6328 all the way through newer chips such as 63138.
Signed-off-by: Florian Fainelli
---
drivers/power/reset/Kconfig | 7
drivers/power/reset/Makefile | 1 +
drivers/power/reset/bcm63xx-reboot.c | 80
3 files changed, 88 insertions(+)
create mode 100644 drivers/power/reset/bcm63xx-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 27f6646731b0..c20c76870f42 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -38,6 +38,13 @@ config POWER_RESET_AXXIA
Say Y if you have an Axxia family SoC.
+config POWER_RESET_BCM63XX
+ bool "Broadcom BCM63xx reset driver"
+ depends on ARM || MIPS || COMPILE_TEST
+ default ARCH_BCM_63XX
+ help
+ This driver provides restart support for the Broadcom DSL SoCs.
+
config POWER_RESET_BRCMSTB
bool "Broadcom STB reset driver"
depends on ARM || MIPS || COMPILE_TEST
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 11de15bae52e..7d28eaff4cd1 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_POWER_RESET_AS3722) += as3722-poweroff.o
obj-$(CONFIG_POWER_RESET_AT91_POWEROFF) += at91-poweroff.o
obj-$(CONFIG_POWER_RESET_AT91_RESET) += at91-reset.o
obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
+obj-$(CONFIG_POWER_RESET_BCM63XX) += bcm63xx-reboot.o
obj-$(CONFIG_POWER_RESET_BRCMSTB) += brcmstb-reboot.o
obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
diff --git a/drivers/power/reset/bcm63xx-reboot.c
b/drivers/power/reset/bcm63xx-reboot.c
new file mode 100644
index ..1e3a93c38784
--- /dev/null
+++ b/drivers/power/reset/bcm63xx-reboot.c
@@ -0,0 +1,80 @@
+/*
+ * Broadcom BCM63xx DSL SoCs reboot handler
+ *
+ * Copyright (C) 2015, 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
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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
+
+static void __iomem *rst_base;
+
+#define SOFT_RESET BIT(0)
+
+static int bcm63xx_restart_handler(struct notifier_block *this,
+ unsigned long mdoe, void *cmd)
+{
+ u32 reg;
+
+ reg = __raw_readl(rst_base);
+ reg |= SOFT_RESET;
+ __raw_writel(reg, rst_base);
+
+ while (1)
+ ;
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block bcm63xx_restart_nb = {
+ .notifier_call = bcm63xx_restart_handler,
+ .priority = 128,
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id bcm63xx_reboot_of_match[] = {
+ { .compatible = "brcm,bcm6328-soft-reset", },
+ { /* sentinel */ },
+};
+#endif
+
+static int bcm63xx_reboot_probe(struct platform_device *pdev)
+{
+ struct resource *r;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ rst_base = devm_ioremap_resource(>dev, r);
+ if (IS_ERR(rst_base)) {
+ dev_err(>dev, "failed to remap registers\n");
+ return PTR_ERR(rst_base);
+ }
+
+ return register_restart_handler(_restart_nb);
+}
+
+static struct platform_driver bcm63xx_reboot_driver = {
+ .probe = bcm63xx_reboot_probe,
+ .driver = {
+ .name = "bcm63xx-soft-reset",
+ .of_match_table = of_match_ptr(bcm63xx_reboot_of_match),
+ },
+};
+
+static int __init bcm63xx_reboot_init(void)
+{
+ return platform_driver_probe(_reboot_driver,
+bcm63xx_reboot_probe);
+}
+subsys_initcall(bcm63xx_reboot_init);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] x86 XIP
On Mon, Mar 23, 2015 at 09:07:14AM +0100, Ingo Molnar wrote: > * Jim Kukunas wrote: > > > > > Hi Folks, > > > > This patchset introduces eXecute-In-Place (XIP) support for x86. > > [...] > > So we'd need a lot better high level description than this: In future patch revisions, I'll update my coverletter to include the information below. > - a bit of background description: what are the advantages of having >the kernel image in non-RAM (flash), etc. Currently for tiny memory-constrained embedded systems, the kernel configuration is usually stripped down in order to reduce the kernel's RAM footprint, freeing up more precious memory for user space and allowing the kernel to fit into smaller systems. With XIP, the kernel's text and read-only data sections are never loaded into RAM, thereby reducing the kernel's memory usage. Also, since a significant portion of the kernel is never loaded into RAM, a larger kernel configuration can be used without bloating memory usage. I haven't done any performance analysis yet, but it's probably safe to say that executing from storage will negatively affect performance. > - on what hardware/bootloaders is or will be XIP supported? With regards to supported hardware, these patches aren't targeting any specific platform. As mentioned in the coverletter, there are current limits on the supported configurations (32-bit only, no SMP, no PAE), but these are not technical limits ... I just need to implement support for them. With regards to supported bootloaders, I've been testing with a small bootloader that I wrote specifically for XIP. Which other bootloaders I add support to will depend on the feedback/requests that I get. > Also, there should probably be some fail-safe mechanism included: such > as to check whether caching attributes (MTRRs, PAT) are properly set > for the XIP area (at minimum to not be uncacheable). Good idea. I'll add that into the next revision. Thanks. -- Jim Kukunas Intel Open Source Technology Center pgp9Hs_FSZajB.pgp Description: PGP signature
Re: [PATCH 01/17] x86, fpu: wrap get_xsave_addr() to make it safer
On 03/24/2015 04:52 PM, Andy Lutomirski wrote: > On Tue, Mar 24, 2015 at 4:42 PM, Dave Hansen wrote: >> On 03/24/2015 03:28 PM, Andy Lutomirski wrote: >>> Your function appears to be getting it for write (I assume that's what >>> the unlazy_fpu is for), so I'd rather have it called >>> tsk_get_xsave_field_for_write or something like that. >> >> It should be entirely read-only. >> >> For MPX (the only user of get_xsave_addr() iirc), we are only worried >> about getting the status codes (and addresses) out of the bndstatus >> register and making sure that the kernel-recorded bounds directory >> address matches the bndcfgu (configuration) register. >> >> We don't ever write to the registers. > > So why are you unlazying it? Oleg actually suggested it. > IIUC, the xstae for current can be in one of three logical states: > > 1. Live in CPU regs. The in-memory copy is garbage and the state is > in CPU regs. > 2. Lazy. The in-memory copy and the CPU regs match. Writing to > either copy is illegal. > 3. In memory only. Writing to the in-memory copy is safe. > > IIUC, you want to read the xstate, do you're okay with #2 or #3. This > would be tsk_get_xsave_field_for_read in my terminology. > > If you want to write the xstate, you'd need to be in state #3, which > would be tsk_get_xsave_field_for_write. > > IIUC, unlazy_fpu just moves from from state 2 to 3. I won't completely claim to understand what's going on with the FPU code, but I think your analysis is a bit off. unlazy_fpu() does __save_init_fpu() which (among other things) calls xsave to dump the CPU registers to memory. That doesn't make any sense to do if "The in-memory copy and the CPU regs match." IOW, unlazy_fpu() is called when the in-memory copy is garbage and takes us to a state where we can look at the in-memory copy. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
