Re: f_op->read seems to be always NULL since Linux 4.1
Am 28.06.2015 um 08:36 schrieb Andreas Hartmann: > On Sat, Jun 27, 2015 at 8:10 PM, Richard Weinberger wrote: >> On Sat, Jun 27, 2015 at 7:32 PM, Andreas Hartmann >> wrote: > [...] >> See __vfs_read(). >> Your module most not rely on such internals. > > Thanks for your hint to the function which exists since 3.19. > > Is there a site out there which lists all relevant changes done for each > kernel version and the recommendations how to correctly handle them? There is no such site. The only way do deal with the ever changing in-kernel ABI is bringing your code mainline. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [!GIT PULL] kdbus for 4.2
On Fri, Jun 26, 2015 at 9:36 PM, Tom Gundersen wrote: > On Fri, Jun 26, 2015 at 9:33 PM, Andy Lutomirski wrote: >> What's a good distro on which to poke at a full running system? > > Fedora Rawhide is probably currently your best bet. > >> Fedora Rawhide seems to still build systemd with --disable-kdbus, >> although I suppose that means that I could boot it with kdbus=1? > > Correct. Does Fedora offer a RPM with systemd from git? I wonder how to install a bleeding edge systemd in a sane way. ./configure && make && make install it a bit archaic. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: f_op->read seems to be always NULL since Linux 4.1
On Sun, Jun 28, 2015 at 08:36:18AM +0200, Andreas Hartmann wrote:
> On Sat, Jun 27, 2015 at 8:10 PM, Richard Weinberger wrote:
> >On Sat, Jun 27, 2015 at 7:32 PM, Andreas Hartmann
> > wrote:
> [...]
> >See __vfs_read().
> >Your module most not rely on such internals.
>
> Thanks for your hint to the function which exists since 3.19.
>
> Is there a site out there which lists all relevant changes done for
> each kernel version and the recommendations how to correctly handle
> them?
localhost. It's in Documentation/filesystems/porting in the kernel
source. To quote the relevant entry (not far from the end - they
are in chronological order):
[mandatory]
never call ->read() and ->write() directly; use __vfs_{read,write} or
wrappers; instead of checking for ->write or ->read being NULL, look for
FMODE_CAN_{WRITE,READ} in file->f_mode.
Sometimes TFM to R _is_ in the natural place...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drm/amdgpu: Delete an unnecessary check before the function call "kfree"
From: Markus Elfring Date: Sun, 28 Jun 2015 10:27:35 +0200 The kfree() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index fec487d..a85cd08 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -1575,8 +1575,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev) amdgpu_fence_driver_fini(adev); amdgpu_fbdev_fini(adev); r = amdgpu_fini(adev); - if (adev->ip_block_enabled) - kfree(adev->ip_block_enabled); + kfree(adev->ip_block_enabled); adev->ip_block_enabled = NULL; adev->accel_working = false; /* free i2c buses */ -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 14/46] d_walk() might skip too much
On 6/27/15, Greg Kroah-Hartman wrote: > That's insane, and not how my tools work :( I asked you to do that apply-patch-two-more-times thing because I assumed that you trust Al Viro's Signed-off-by more than you trust my Signed-off-by. > Can you provide the needed backport? If it was in an earlier email in > this series, sorry, it's long gone from my mailbox, can you resend it? Willy Tarreau re-posted that patch to you yesterday. No need for me to repeat that here. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] nvdimm: Fix return value of nvdimm_bus_init() if class_create() fails
Return proper error if class_create() fails.
Signed-off-by: Axel Lin
---
drivers/nvdimm/bus.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index ca80270..f6f6a91 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -644,8 +644,10 @@ int __init nvdimm_bus_init(void)
nvdimm_major = rc;
nd_class = class_create(THIS_MODULE, "nd");
- if (IS_ERR(nd_class))
+ if (IS_ERR(nd_class)) {
+ rc = PTR_ERR(nd_class);
goto err_class;
+ }
return 0;
--
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] ALSA: hda: Delete an unnecessary check before the function call "snd_info_free_entry"
From: Markus Elfring
Date: Sun, 28 Jun 2015 11:15:28 +0200
The snd_info_free_entry() function tests whether its argument is NULL and
then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
sound/pci/hda/patch_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index f852734..2f24338 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -591,7 +591,7 @@ static int eld_proc_new(struct hdmi_spec_per_pin *per_pin,
int index)
static void eld_proc_free(struct hdmi_spec_per_pin *per_pin)
{
- if (!per_pin->codec->bus->shutdown && per_pin->proc_entry) {
+ if (!per_pin->codec->bus->shutdown) {
snd_info_free_entry(per_pin->proc_entry);
per_pin->proc_entry = NULL;
}
--
2.4.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/
atomic64 on 32-bit vs 64-bit (was: Re: Add virtio gpu driver.)
On Fri, Jun 26, 2015 at 10:52 PM, Linux Kernel Mailing List
wrote:
> Gitweb:
> http://git.kernel.org/linus/;a=commit;h=dc5698e80cf724770283e10414054662bdf6ccfa
> Commit: dc5698e80cf724770283e10414054662bdf6ccfa
> Parent: 16e3247da7f71f8c31f4330f739f6192a00c8b51
> Refname:refs/heads/master
> Author: Dave Airlie
> AuthorDate: Mon Sep 9 10:02:56 2013 +1000
> Committer: Gerd Hoffmann
> CommitDate: Wed Jun 3 14:17:38 2015 +0200
>
> Add virtio gpu driver.
>
> This patch adds a kms driver for the virtio gpu. The xorg modesetting
> driver can handle the device just fine, the framebuffer for fbcon is
> there too.
>
> Qemu patches for the host side are under review currently.
>
> The pci version of the device comes in two variants: with and without
> vga compatibility. The former has a extra memory bar for the vga
> framebuffer, the later is a pure virtio device. The only concern for
> this driver is that in the virtio-vga case we have to kick out the
> firmware framebuffer.
>
> Initial revision has only 2d support, 3d (virgl) support requires
> some more work on the qemu side and will be added later.
>
> Signed-off-by: Dave Airlie
> Signed-off-by: Gerd Hoffmann
> Acked-by: Michael S. Tsirkin
> --- /dev/null
> +++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
> +static int
> +virtio_gpu_debugfs_irq_info(struct seq_file *m, void *data)
> +{
> + struct drm_info_node *node = (struct drm_info_node *) m->private;
> + struct virtio_gpu_device *vgdev = node->minor->dev->dev_private;
> +
> + seq_printf(m, "fence %ld %lld\n",
> + atomic64_read(&vgdev->fence_drv.last_seq),
> + vgdev->fence_drv.sync_seq);
On m68k (32-bit):
drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function
‘virtio_gpu_debugfs_irq_info’:
drivers/gpu/drm/virtio/virtgpu_debugfs.c:39: warning: format ‘%ld’
expects type ‘long int’, but argument 3 has type ‘long long int’
> --- /dev/null
> +++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
> +static bool virtio_signaled(struct fence *f)
> +{
> + struct virtio_gpu_fence *fence = to_virtio_fence(f);
> +
> + if (atomic64_read(&fence->drv->last_seq) >= fence->seq)
> + return true;
drivers/gpu/drm/virtio/virtgpu_fence.c: In function ‘virtio_timeline_value_str’:
drivers/gpu/drm/virtio/virtgpu_fence.c:64: warning: format ‘%lu’
expects type ‘long unsigned int’, but argument 4 has type ‘long long
int’
interestingly, this was reported almost one year ago:
https://lists.01.org/pipermail/kbuild-all/2014-September/006409.html
Instead of sprinkling casts, is there any good reason why atomic64_read()
and atomic64_t aren't "long long" everywhere, cfr. u64?
Thanks!
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] SCSI-OSD: Delete an unnecessary check before the function call "put_disk"
On 06/24/2015 05:16 PM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 24 Jun 2015 16:06:21 +0200
>
> The put_disk() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
ACK-by: Boaz Harrosh
> ---
> drivers/scsi/osd/osd_uld.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/osd/osd_uld.c b/drivers/scsi/osd/osd_uld.c
> index 243eab3..e2075522 100644
> --- a/drivers/scsi/osd/osd_uld.c
> +++ b/drivers/scsi/osd/osd_uld.c
> @@ -407,9 +407,7 @@ static void __remove(struct device *dev)
>
> OSD_INFO("osd_remove %s\n",
>oud->disk ? oud->disk->disk_name : NULL);
> -
> - if (oud->disk)
> - put_disk(oud->disk);
> + put_disk(oud->disk);
> ida_remove(&osd_minor_ida, oud->minor);
>
> kfree(oud);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: stm32: Fix out-by-one error path in the index lookup
If stm32f4_rcc_lookup() is called with primary == 0 and secondary == 192 then it will read beyond the end of the table array due to an out-by-one error in the range check. In addition to the fixing the inequality we also modify the r.h.s. to make it even more explicit that we are comparing against the size of table in bits. Reported-by: Dan Carpenter Signed-off-by: Daniel Thompson --- drivers/clk/clk-stm32f4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c index c825bbd..148c151 100644 --- a/drivers/clk/clk-stm32f4.c +++ b/drivers/clk/clk-stm32f4.c @@ -268,7 +268,7 @@ static int stm32f4_rcc_lookup_clk_idx(u8 primary, u8 secondary) memcpy(table, stm32f42xx_gate_map, sizeof(table)); /* only bits set in table can be used as indices */ - if (WARN_ON(secondary > 8 * sizeof(table) || + if (WARN_ON(secondary >= BITS_PER_BYTE * sizeof(table) || 0 == (table[BIT_ULL_WORD(secondary)] & BIT_ULL_MASK(secondary return -EINVAL; -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PM-wakeup: Delete unnecessary checks before two function calls
From: Markus Elfring
Date: Sun, 28 Jun 2015 12:14:43 +0200
The functions dev_pm_disarm_wake_irq() and wakeup_source_unregister() test
whether their argument is NULL and then return immediately.
Thus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/base/power/wakeup.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index 40f7160..3741bc2 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -341,8 +341,7 @@ void device_wakeup_arm_wake_irqs(void)
rcu_read_lock();
list_for_each_entry_rcu(ws, &wakeup_sources, entry) {
- if (ws->wakeirq)
- dev_pm_arm_wake_irq(ws->wakeirq);
+ dev_pm_arm_wake_irq(ws->wakeirq);
}
rcu_read_unlock();
}
@@ -358,8 +357,7 @@ void device_wakeup_disarm_wake_irqs(void)
rcu_read_lock();
list_for_each_entry_rcu(ws, &wakeup_sources, entry) {
- if (ws->wakeirq)
- dev_pm_disarm_wake_irq(ws->wakeirq);
+ dev_pm_disarm_wake_irq(ws->wakeirq);
}
rcu_read_unlock();
}
@@ -396,9 +394,7 @@ int device_wakeup_disable(struct device *dev)
return -EINVAL;
ws = device_wakeup_detach(dev);
- if (ws)
- wakeup_source_unregister(ws);
-
+ wakeup_source_unregister(ws);
return 0;
}
EXPORT_SYMBOL_GPL(device_wakeup_disable);
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drbd: Deletion of an unnecessary check before the function call "lc_destroy"
> From: Markus Elfring
> Date: Wed, 19 Nov 2014 13:33:32 +0100
>
> The lc_destroy() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/block/drbd/drbd_nl.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
> index 1cd47df..0bcb3e0 100644
> --- a/drivers/block/drbd/drbd_nl.c
> +++ b/drivers/block/drbd/drbd_nl.c
> @@ -1115,8 +1115,7 @@ static int drbd_check_al_size(struct drbd_device
> *device, struct disk_conf *dc)
> lc_destroy(n);
> return -EBUSY;
> } else {
> - if (t)
> - lc_destroy(t);
> + lc_destroy(t);
> }
> drbd_md_mark_dirty(device); /* we changed device->act_log->nr_elemens */
> return 0;
>
Would you like to integrate this update suggestion
into another source code repository?
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] block-rsxx: Deletion of an unnecessary check before the function call "vfree"
> From: Markus Elfring > Date: Mon, 1 Dec 2014 19:19:25 +0100 > > The vfree() function performs also input parameter validation. > Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/block/rsxx/dma.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/block/rsxx/dma.c b/drivers/block/rsxx/dma.c > index cf8cd29..0181387 100644 > --- a/drivers/block/rsxx/dma.c > +++ b/drivers/block/rsxx/dma.c > @@ -960,8 +960,7 @@ failed_dma_setup: > ctrl->done_wq = NULL; > } > > - if (ctrl->trackers) > - vfree(ctrl->trackers); > + vfree(ctrl->trackers); > > if (ctrl->status.buf) > pci_free_consistent(card->dev, STATUS_BUFFER_SIZE8, > Would you like to integrate this update suggestion into another source code repository? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] block-skd: Deletion of an unnecessary check before the function call "kfree"
> From: Markus Elfring > Date: Mon, 1 Dec 2014 18:15:46 +0100 > > The kfree() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/block/skd_main.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c > index 1e46eb2..c4b0259 100644 > --- a/drivers/block/skd_main.c > +++ b/drivers/block/skd_main.c > @@ -3998,8 +3998,7 @@ static int skd_acquire_msix(struct skd_device *skdev) > return 0; > > msix_out: > - if (entries) > - kfree(entries); > + kfree(entries); > skd_release_msix(skdev); > return rc; > } > Would anybody like to integrate this update suggestion into another source code repository? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] SCSI: dtc: Fixed a brace issue on return 0
From: rudhresh
Return is not a function so parenthesis is not required
Signed-off-by: Rudhresh
---
drivers/scsi/dtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
index 4c74c7b..c793ecf 100644
--- a/drivers/scsi/dtc.c
+++ b/drivers/scsi/dtc.c
@@ -363,7 +363,7 @@ static inline int NCR5380_pread(struct Scsi_Host *instance,
unsigned char *dst,
NCR5380_read(RESET_PARITY_INTERRUPT_REG);
if (i > hostdata->spin_max_r)
hostdata->spin_max_r = i;
- return (0);
+ return 0;
}
/
@@ -417,7 +417,7 @@ static inline int NCR5380_pwrite(struct Scsi_Host
*instance, unsigned char *src,
rtrc(0);
if (i > hostdata->spin_max_w)
hostdata->spin_max_w = i;
- return (0);
+ return 0;
}
MODULE_LICENSE("GPL");
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID-picoLCD: Deletion of unnecessary checks before three function calls
> From: Markus Elfring > Date: Wed, 19 Nov 2014 18:30:22 +0100 > > The functions backlight_device_unregister(), lcd_device_unregister() and > rc_unregister_device() test whether their argument is NULL and then > return immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/hid/hid-picolcd_backlight.c | 3 +-- > drivers/hid/hid-picolcd_cir.c | 3 +-- > drivers/hid/hid-picolcd_lcd.c | 3 +-- > 3 files changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/hid/hid-picolcd_backlight.c > b/drivers/hid/hid-picolcd_backlight.c > index a32c5f8..808807a 100644 > --- a/drivers/hid/hid-picolcd_backlight.c > +++ b/drivers/hid/hid-picolcd_backlight.c > @@ -94,8 +94,7 @@ void picolcd_exit_backlight(struct picolcd_data *data) > struct backlight_device *bdev = data->backlight; > > data->backlight = NULL; > - if (bdev) > - backlight_device_unregister(bdev); > + backlight_device_unregister(bdev); > } > > int picolcd_resume_backlight(struct picolcd_data *data) > diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c > index 045f8eb..9628651 100644 > --- a/drivers/hid/hid-picolcd_cir.c > +++ b/drivers/hid/hid-picolcd_cir.c > @@ -145,7 +145,6 @@ void picolcd_exit_cir(struct picolcd_data *data) > struct rc_dev *rdev = data->rc_dev; > > data->rc_dev = NULL; > - if (rdev) > - rc_unregister_device(rdev); > + rc_unregister_device(rdev); > } > > diff --git a/drivers/hid/hid-picolcd_lcd.c b/drivers/hid/hid-picolcd_lcd.c > index 89821c2..22dcbe1 100644 > --- a/drivers/hid/hid-picolcd_lcd.c > +++ b/drivers/hid/hid-picolcd_lcd.c > @@ -92,8 +92,7 @@ void picolcd_exit_lcd(struct picolcd_data *data) > struct lcd_device *ldev = data->lcd; > > data->lcd = NULL; > - if (ldev) > - lcd_device_unregister(ldev); > + lcd_device_unregister(ldev); > } > > int picolcd_resume_lcd(struct picolcd_data *data) > Would you like to integrate this update suggestion into another source code repository? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] backlight: lp8788: Deletion of a check before backlight_device_unregister()
> From: Markus Elfring
>
> The backlight_device_unregister() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/video/backlight/lp8788_bl.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/lp8788_bl.c
> b/drivers/video/backlight/lp8788_bl.c
> index d6c4f6a..24a055c 100644
> --- a/drivers/video/backlight/lp8788_bl.c
> +++ b/drivers/video/backlight/lp8788_bl.c
> @@ -221,8 +221,7 @@ static void lp8788_backlight_unregister(struct lp8788_bl
> *bl)
> {
> struct backlight_device *bl_dev = bl->bl_dev;
>
> - if (bl_dev)
> - backlight_device_unregister(bl_dev);
> + backlight_device_unregister(bl_dev);
> }
>
> static ssize_t lp8788_get_bl_ctl_mode(struct device *dev,
>
Would you like to integrate this update suggestion
into another source code repository?
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] video: fbdev: omap2: displays-new: Delete a check before backlight_device_unregister()
From: Markus Elfring Date: Sun, 28 Jun 2015 14:30:17 +0200 The backlight_device_unregister() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c b/drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c index 3414c26..d2caa41 100644 --- a/drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c +++ b/drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c @@ -1323,8 +1323,7 @@ static int dsicm_probe(struct platform_device *pdev) return 0; err_sysfs_create: - if (bldev != NULL) - backlight_device_unregister(bldev); + backlight_device_unregister(bldev); err_bl: destroy_workqueue(ddata->workqueue); err_reg: -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: fsl_ssi: fix AC'97 mode
W dniu 28.06.2015 06:27, Timur Tabi pisze:
> Maciej S. Szmigiero wrote:
>> +if (newbinding && fsl_ssi_is_ac97(ssi_private)) {
>
> Is the "newbinding" necessary? I thought only the original PowerPC device
> trees were the only one that have the old binding, and they never supported
> AC97.
If there isn't going to be new platforms added with old bindings then this
won't be needed - I'll remove it.
Best regards,
Maciej Szmigiero
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USB-mxuport: Delete an unnecessary check before the function call "release_firmware"
From: Markus Elfring Date: Sun, 28 Jun 2015 14:59:04 +0200 The release_firmware() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/usb/serial/mxuport.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c index 460a406..92f7aee 100644 --- a/drivers/usb/serial/mxuport.c +++ b/drivers/usb/serial/mxuport.c @@ -1101,8 +1101,7 @@ static int mxuport_probe(struct usb_serial *serial, */ usb_set_serial_data(serial, (void *)id->driver_info); out: - if (fw_p) - release_firmware(fw_p); + release_firmware(fw_p); return err; } -- 2.4.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] hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead
From: Joe Perches
Date: Thu, 26 Mar 2015 20:47:10 -0700
Removing unnecessary static buffers is good.
Use the vsprintf %pV extension instead.
Signed-off-by: Joe Perches
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org # v2.6.36+
---
fs/hpfs/super.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
Index: linux-4.1/fs/hpfs/super.c
===
--- linux-4.1.orig/fs/hpfs/super.c 2015-06-22 21:28:15.0 +0200
+++ linux-4.1/fs/hpfs/super.c 2015-06-22 21:28:25.0 +0200
@@ -53,17 +53,20 @@ static void unmark_dirty(struct super_bl
}
/* Filesystem error... */
-static char err_buf[1024];
-
void hpfs_error(struct super_block *s, const char *fmt, ...)
{
+ struct va_format vaf;
va_list args;
va_start(args, fmt);
- vsnprintf(err_buf, sizeof(err_buf), fmt, args);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ pr_err("filesystem error: %pV", &vaf);
+
va_end(args);
- pr_err("filesystem error: %s", err_buf);
if (!hpfs_sb(s)->sb_was_error) {
if (hpfs_sb(s)->sb_err == 2) {
pr_cont("; crashing the system because you wanted
it\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hpfs: kstrdup() out of memory handling
From: Sanidhya Kashyap Date: Sat, 21 Mar 2015 12:57:50 -0400 There is a possibility of nothing being allocated to the new_opts in case of memory pressure, therefore return ENOMEM for such case. Signed-off-by: Sanidhya Kashyap Signed-off-by: Mikulas Patocka Cc: sta...@vger.kernel.org --- fs/hpfs/super.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) Index: linux-2.6/fs/hpfs/super.c === --- linux-2.6.orig/fs/hpfs/super.c 2015-06-28 14:43:48.0 +0200 +++ linux-2.6/fs/hpfs/super.c 2015-06-28 14:45:11.0 +0200 @@ -459,11 +459,14 @@ static int hpfs_remount_fs(struct super_ int o; struct hpfs_sb_info *sbi = hpfs_sb(s); char *new_opts = kstrdup(data, GFP_KERNEL); - + + if (!new_opts) + return -ENOMEM; + sync_filesystem(s); *flags |= MS_NOATIME; - + hpfs_lock(s); uid = sbi->sb_uid; gid = sbi->sb_gid; umask = 0777 & ~sbi->sb_mode; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] hpfs: add fstrim support
This patch adds support for fstrim to the HPFS filesystem.
Signed-off-by: Mikulas Patocka
---
fs/hpfs/alloc.c | 95 ++
fs/hpfs/dir.c |4 ++
fs/hpfs/file.c|4 ++
fs/hpfs/hpfs_fn.h |7 +++
fs/hpfs/super.c | 35 +++
5 files changed, 145 insertions(+)
Index: linux-4.1-rc1/fs/hpfs/dir.c
===
--- linux-4.1-rc1.orig/fs/hpfs/dir.c2014-07-01 18:49:25.0 +0200
+++ linux-4.1-rc1/fs/hpfs/dir.c 2015-05-01 15:52:29.0 +0200
@@ -327,4 +327,8 @@ const struct file_operations hpfs_dir_op
.iterate= hpfs_readdir,
.release= hpfs_dir_release,
.fsync = hpfs_file_fsync,
+ .unlocked_ioctl = hpfs_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = hpfs_compat_ioctl,
+#endif
};
Index: linux-4.1-rc1/fs/hpfs/file.c
===
--- linux-4.1-rc1.orig/fs/hpfs/file.c 2015-05-01 12:31:01.0 +0200
+++ linux-4.1-rc1/fs/hpfs/file.c2015-05-01 15:52:29.0 +0200
@@ -203,6 +203,10 @@ const struct file_operations hpfs_file_o
.release= hpfs_file_release,
.fsync = hpfs_file_fsync,
.splice_read= generic_file_splice_read,
+ .unlocked_ioctl = hpfs_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = hpfs_compat_ioctl,
+#endif
};
const struct inode_operations hpfs_file_iops =
Index: linux-4.1-rc1/fs/hpfs/alloc.c
===
--- linux-4.1-rc1.orig/fs/hpfs/alloc.c 2014-07-01 18:49:25.0 +0200
+++ linux-4.1-rc1/fs/hpfs/alloc.c 2015-05-01 15:52:29.0 +0200
@@ -484,3 +484,98 @@ struct anode *hpfs_alloc_anode(struct su
a->btree.first_free = cpu_to_le16(8);
return a;
}
+
+static unsigned find_run(__le32 *bmp, unsigned *idx)
+{
+ unsigned len;
+ while (tstbits(bmp, *idx, 1)) {
+ (*idx)++;
+ if (unlikely(*idx >= 0x4000))
+ return 0;
+ }
+ len = 1;
+ while (!tstbits(bmp, *idx + len, 1))
+ len++;
+ return len;
+}
+
+static int do_trim(struct super_block *s, secno start, unsigned len, secno
limit_start, secno limit_end, unsigned minlen, unsigned *result)
+{
+ int err;
+ secno end;
+ if (fatal_signal_pending(current))
+ return -EINTR;
+ end = start + len;
+ if (start < limit_start)
+ start = limit_start;
+ if (end > limit_end)
+ end = limit_end;
+ if (start >= end)
+ return 0;
+ if (end - start < minlen)
+ return 0;
+ err = sb_issue_discard(s, start, end - start, GFP_NOFS, 0);
+ if (err)
+ return err;
+ *result += end - start;
+ return 0;
+}
+
+int hpfs_trim_fs(struct super_block *s, u64 start, u64 end, u64 minlen,
unsigned *result)
+{
+ int err = 0;
+ struct hpfs_sb_info *sbi = hpfs_sb(s);
+ unsigned idx, len, start_bmp, end_bmp;
+ __le32 *bmp;
+ struct quad_buffer_head qbh;
+
+ *result = 0;
+ if (!end || end > sbi->sb_fs_size)
+ end = sbi->sb_fs_size;
+ if (start >= sbi->sb_fs_size)
+ return 0;
+ if (minlen > 0x4000)
+ return 0;
+ if (start < sbi->sb_dirband_start + sbi->sb_dirband_size && end >
sbi->sb_dirband_start) {
+ hpfs_lock(s);
+ if (s->s_flags & MS_RDONLY) {
+ err = -EROFS;
+ goto unlock_1;
+ }
+ if (!(bmp = hpfs_map_dnode_bitmap(s, &qbh))) {
+ err = -EIO;
+ goto unlock_1;
+ }
+ idx = 0;
+ while ((len = find_run(bmp, &idx)) && !err) {
+ err = do_trim(s, sbi->sb_dirband_start + idx * 4, len *
4, start, end, minlen, result);
+ idx += len;
+ }
+ hpfs_brelse4(&qbh);
+unlock_1:
+ hpfs_unlock(s);
+ }
+ start_bmp = start >> 14;
+ end_bmp = (end + 0x3fff) >> 14;
+ while (start_bmp < end_bmp && !err) {
+ hpfs_lock(s);
+ if (s->s_flags & MS_RDONLY) {
+ err = -EROFS;
+ goto unlock_2;
+ }
+ if (!(bmp = hpfs_map_bitmap(s, start_bmp, &qbh, "trim"))) {
+ err = -EIO;
+ goto unlock_2;
+ }
+ idx = 0;
+ while ((len = find_run(bmp, &idx)) && !err) {
+ err = do_trim(s, (start_bmp << 14) + idx, len, start,
end, minlen, result);
+ idx += len;
+ }
+ hpfs_brelse4(&qbh);
+unlock_2:
+ hpfs_unlock(s);
+
[PATCH RFC 4/5] kdbus: handle WARN_ON cases properly when decrementing quota
If we spotted inconsistency, fix it by setting values to zero. Signed-off-by: Sergei Zviagintsev --- ipc/kdbus/connection.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/ipc/kdbus/connection.c b/ipc/kdbus/connection.c index 1d44e280eff0..12e32de310f5 100644 --- a/ipc/kdbus/connection.c +++ b/ipc/kdbus/connection.c @@ -742,9 +742,15 @@ void kdbus_conn_quota_dec(struct kdbus_conn *c, struct kdbus_user *u, if (!WARN_ON(quota->msgs == 0)) --quota->msgs; - if (!WARN_ON(quota->memory < memory)) + + if (WARN_ON(quota->memory < memory)) + quota->memory = 0; + else quota->memory -= memory; - if (!WARN_ON(quota->fds < fds)) + + if (WARN_ON(quota->fds < fds)) + quota->fds = 0; + else quota->fds -= fds; } -- 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/
[PATCH] hpfs: Remove unessary cast
From: Firo Yang
Date: Thu, 23 Apr 2015 17:28:45 +0800
Avoid a pointless kmem_cache_alloc() return value cast in
fs/hpfs/super.c::hpfs_alloc_inode()
Signed-off-by: Firo Yang
Signed-off-by: Mikulas Patocka
---
fs/hpfs/super.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-4.1/fs/hpfs/super.c
===
--- linux-4.1.orig/fs/hpfs/super.c 2015-06-22 20:17:54.0 +0200
+++ linux-4.1/fs/hpfs/super.c 2015-06-22 21:27:59.0 +0200
@@ -238,7 +238,7 @@ static struct kmem_cache * hpfs_inode_ca
static struct inode *hpfs_alloc_inode(struct super_block *sb)
{
struct hpfs_inode_info *ei;
- ei = (struct hpfs_inode_info *)kmem_cache_alloc(hpfs_inode_cachep,
GFP_NOFS);
+ ei = kmem_cache_alloc(hpfs_inode_cachep, GFP_NOFS);
if (!ei)
return NULL;
ei->vfs_inode.i_version = 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 RFC 2/5] kdbus: use standard kernel types in struct kdbus_quota
uint{8,16,32}_t -> u{8,16,32}
Signed-off-by: Sergei Zviagintsev
---
ipc/kdbus/connection.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ipc/kdbus/connection.c b/ipc/kdbus/connection.c
index df072487e23c..af044f93c14f 100644
--- a/ipc/kdbus/connection.c
+++ b/ipc/kdbus/connection.c
@@ -606,9 +606,9 @@ bool kdbus_conn_has_name(struct kdbus_conn *conn, const
char *name)
}
struct kdbus_quota {
- uint32_t memory;
- uint16_t msgs;
- uint8_t fds;
+ u32 memory;
+ u16 msgs;
+ u8 fds;
};
/**
--
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/
[PATCH RFC 3/5] kdbus: do explicit overflow check in kdbus_conn_quota_inc()
Replace the use of max() with explicit and obvious overflow check.
Signed-off-by: Sergei Zviagintsev
---
ipc/kdbus/connection.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/ipc/kdbus/connection.c b/ipc/kdbus/connection.c
index af044f93c14f..1d44e280eff0 100644
--- a/ipc/kdbus/connection.c
+++ b/ipc/kdbus/connection.c
@@ -668,9 +668,11 @@ int kdbus_conn_quota_inc(struct kdbus_conn *c, struct
kdbus_user *u,
id = u ? u->id : KDBUS_USER_KERNEL_ID;
if (id >= c->n_quota) {
- unsigned int users;
+ unsigned int users = KDBUS_ALIGN8(id) + 8;
+
+ if (users < id) /* overflow */
+ users = id;
- users = max(KDBUS_ALIGN8(id) + 8, id);
quota = krealloc(c->quota, users * sizeof(*quota),
GFP_KERNEL | __GFP_ZERO);
if (!quota)
--
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/
[PATCH RFC 1/5] kdbus: fix typos in kdbus_conn_quota_inc()
Signed-off-by: Sergei Zviagintsev --- ipc/kdbus/connection.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ipc/kdbus/connection.c b/ipc/kdbus/connection.c index 9993753d11de..df072487e23c 100644 --- a/ipc/kdbus/connection.c +++ b/ipc/kdbus/connection.c @@ -646,7 +646,7 @@ int kdbus_conn_quota_inc(struct kdbus_conn *c, struct kdbus_user *u, * allocation schemes. Furthermore, resource utilization should be * maximized, so only minimal resources stay reserved. However, we need * to adapt to a dynamic number of users, as we cannot know how many -* users will talk to a connection. Therefore, the current allocations +* users will talk to a connection. Therefore, the current allocation * works like this: * We limit the number of bytes in a destination's pool per sending * user. The space available for a user is 33% of the unused pool space @@ -688,7 +688,7 @@ int kdbus_conn_quota_inc(struct kdbus_conn *c, struct kdbus_user *u, /* * Pool owner slices are un-accounted slices; they can claim more -* than 50% of the queue. However, the slice we're dealing with here +* than 50% of the queue. However, the slices we're dealing with here * belong to the incoming queue, hence they are 'accounted' slices * to which the 50%-limit applies. */ -- 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/
[PATCH RFC 0/5] kdbus: minor quota code improvements
Hi, Main points here are to use conventional types, rewrite tests in obvious way, add couple of new WARN_ONs and do a bit more work in the others. Keeping in mind the number of mistakes I made while preparing this patchset, I decided to mark it as RFC :) I'd appreciate any feedback on these. Sergei Zviagintsev (5): kdbus: fix typos in kdbus_conn_quota_inc() kdbus: use standard kernel types in struct kdbus_quota kdbus: do explicit overflow check in kdbus_conn_quota_inc() kdbus: handle WARN_ON cases properly when decrementing quota kdbus: improve tests on incrementing quota ipc/kdbus/connection.c | 44 ++-- 1 file changed, 30 insertions(+), 14 deletions(-) -- 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/
[PATCH RFC 5/5] kdbus: improve tests on incrementing quota
1) Rewrite quota->memory + memory > U32_MAX as U32_MAX - quota->memory < memory and provide the comment on why we need that check. We have no overflow issue in the original expression when size_t is 32-bit because the previous one (available - quota->memory < memory) guarantees that quota->memory + memory doesn't exceed `available' which is <= U32_MAX in that case. But lets stay explicit rather than implicit, it would save us from describing HOW the code works. 2) Add WARN_ON when quota->msgs > KDBUS_CONN_MAX_MSGS This is somewhat inconsistent, so we need to properly report it. 3) Replace quota->fds + fds < quota->fds || quota->fds + fds > KDBUS_CONN_MAX_FDS_PER_USER with KDBUS_CONN_MAX_FDS_PER_USER - quota->fds < fds and add explicit WARN_ON in the case quota->fds > KDBUS_CONN_MAX_FDS_PER_USER. Reading the code one can assume that the first expression is there to ensure that we won't have an overflow in quota->fds after quota->fds += fds, but what it really does is testing for size_t overflow in `quota->fds + fds' to be safe in the second expression (as fds is size_t, quota->fds is converted to bigger type). Rewrite it in more obvious way. KDBUS_CONN_MAX_FDS_PER_USER is checked at compile time to fill in quota->fds type (there is BUILD_BUG_ON), so no further checks for quota->fds overflow are needed. Signed-off-by: Sergei Zviagintsev --- ipc/kdbus/connection.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/ipc/kdbus/connection.c b/ipc/kdbus/connection.c index 12e32de310f5..6556a0f9d44c 100644 --- a/ipc/kdbus/connection.c +++ b/ipc/kdbus/connection.c @@ -701,13 +701,21 @@ int kdbus_conn_quota_inc(struct kdbus_conn *c, struct kdbus_user *u, available = (available - accounted + quota->memory) / 3; if (available < quota->memory || - available - quota->memory < memory || - quota->memory + memory > U32_MAX) + available - quota->memory < memory) return -ENOBUFS; - if (quota->msgs >= KDBUS_CONN_MAX_MSGS) + + /* +* available is size_t and thus it could be greater than U32_MAX. +* Ensure that quota->memory won't overflow. +*/ + if (U32_MAX - quota->memory < memory) + return -ENOBUFS; + + if (WARN_ON(quota->msgs > KDBUS_CONN_MAX_MSGS) || + quota->msgs == KDBUS_CONN_MAX_MSGS) return -ENOBUFS; - if (quota->fds + fds < quota->fds || - quota->fds + fds > KDBUS_CONN_MAX_FDS_PER_USER) + if (WARN_ON(quota->fds > KDBUS_CONN_MAX_FDS_PER_USER) || + KDBUS_CONN_MAX_FDS_PER_USER - quota->fds < fds) return -EMFILE; quota->memory += memory; -- 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/
[GIT PULL] UML updates for 4.2
Linus, the following changes since commit ba155e2d21f6bf05de86a78dbe5bfd8757604a65: Linux 4.1-rc5 (2015-05-24 18:22:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.2-rc1 for you to fetch changes up to da028d5e5463dabb6ede2f5e3f6cced1283988cc: um: Don't pollute kernel namespace with uapi (2015-06-25 22:44:11 +0200) This pull request includes the following UML changes: * removal of hppfs * initial support for musl libc * uaccess cleanup * random cleanups and bug fixes all over the place Chen Gang (1): um: kernel: ksyms: Export symbol syscall() for fixing modpost issue Hans-Werner Hilse (3): um: Do not use __ptr_t type for stack_t's .ss pointer um: Do not use stdin and stdout identifiers for struct members um: Include sys/types.h for makedev(), major(), minor() Nicolas Iooss (3): um: Create asm/sections.h um: Use char[] for linker script address declarations um/os-Linux: Use char[] for syscall_stub declarations Richard Weinberger (14): um: Move syscall() declaration into os.h um: Remove hppfs um: Cleanup mem_32/64.c headers um: Add asm/elf.h to vma.c um: Add uaccess.h to syscalls_64.c um: Add uaccess.h to ldt.c um: Rework uaccess code um: Fix warning in setup_signal_stack_si() um: Catch unprotected user memory access um: Stop abusing __KERNEL__ um: Remove copy&paste code from init.h um: Handle tracehook_report_syscall_entry() result um: Fix mconsole dependency um: Don't pollute kernel namespace with uapi arch/um/Kconfig.um | 16 +- arch/um/Makefile | 7 +- arch/um/drivers/harddog_user.c | 18 +- arch/um/drivers/mconsole.h | 2 +- arch/um/drivers/net_user.c | 6 +- arch/um/drivers/slip_user.c| 14 +- arch/um/drivers/slirp_user.c | 16 +- arch/um/include/asm/Kbuild | 1 - arch/um/include/asm/ptrace-generic.h | 3 +- arch/um/include/asm/sections.h | 9 + arch/um/include/asm/thread_info.h | 2 +- arch/um/include/asm/uaccess.h | 176 ++-- arch/um/include/shared/init.h | 24 +- arch/um/include/shared/os.h| 2 + arch/um/include/shared/user.h | 2 +- arch/um/kernel/ksyms.c | 2 + arch/um/kernel/physmem.c | 7 +- arch/um/kernel/ptrace.c| 7 +- arch/um/kernel/skas/mmu.c | 7 +- arch/um/kernel/skas/syscall.c | 6 +- arch/um/kernel/skas/uaccess.c | 47 +- arch/um/kernel/trap.c | 5 + arch/um/kernel/um_arch.c | 4 +- arch/um/os-Linux/drivers/tuntap_user.c | 6 +- arch/um/os-Linux/file.c| 1 + arch/um/os-Linux/signal.c | 8 +- arch/um/os-Linux/skas/mem.c| 6 +- arch/um/os-Linux/skas/process.c| 8 +- arch/x86/um/asm/checksum.h | 1 + arch/x86/um/asm/elf.h | 2 - arch/x86/um/asm/processor.h| 2 + arch/x86/um/asm/segment.h | 8 + arch/x86/um/ldt.c | 1 + arch/x86/um/mem_32.c | 3 +- arch/x86/um/mem_64.c | 3 +- arch/x86/um/ptrace_32.c| 1 + arch/x86/um/ptrace_64.c| 1 + arch/x86/um/shared/sysdep/tls.h| 6 +- arch/x86/um/signal.c | 3 +- arch/x86/um/syscalls_64.c | 1 + arch/x86/um/tls_32.c | 1 + arch/x86/um/tls_64.c | 1 + arch/x86/um/vdso/vma.c | 1 + fs/Makefile| 1 - fs/hppfs/Makefile | 6 - fs/hppfs/hppfs.c | 766 - 46 files changed, 155 insertions(+), 1065 deletions(-) create mode 100644 arch/um/include/asm/sections.h delete mode 100644 fs/hppfs/Makefile delete mode 100644 fs/hppfs/hppfs.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: fsl_ssi: fix AC'97 mode
Maciej S. Szmigiero wrote: If there isn't going to be new platforms added with old bindings then this won't be needed - I'll remove it. I would love it if someone would port those original device trees to the new binding, so that we can get rid of the old one. But we should definitely not allow new device trees with the old binding. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] ASoC: fsl_ssi: enable IPG clock during AC'97 reg access
IPG clock have to be enabled during AC'97 CODEC register
access in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index c7647e0..9c46c7d 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1127,10 +1127,17 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97,
unsigned short reg,
struct regmap *regs = fsl_ac97_data->regs;
unsigned int lreg;
unsigned int lval;
+ int ret;
if (reg > 0x7f)
return;
+ ret = clk_prepare_enable(fsl_ac97_data->clk);
+ if (ret) {
+ pr_err("ac97 write clk_prepare_enable failed: %d\n",
+ ret);
+ return;
+ }
lreg = reg << 12;
regmap_write(regs, CCSR_SSI_SACADD, lreg);
@@ -1141,6 +1148,8 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97,
unsigned short reg,
regmap_update_bits(regs, CCSR_SSI_SACNT, CCSR_SSI_SACNT_RDWR_MASK,
CCSR_SSI_SACNT_WR);
udelay(100);
+
+ clk_disable_unprepare(fsl_ac97_data->clk);
}
static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
@@ -1151,6 +1160,14 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97
*ac97,
unsigned short val = -1;
u32 reg_val;
unsigned int lreg;
+ int ret;
+
+ ret = clk_prepare_enable(fsl_ac97_data->clk);
+ if (ret) {
+ pr_err("ac97 read clk_prepare_enable failed: %d\n",
+ ret);
+ return -1;
+ }
lreg = (reg & 0x7f) << 12;
regmap_write(regs, CCSR_SSI_SACADD, lreg);
@@ -1162,6 +1179,8 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97
*ac97,
regmap_read(regs, CCSR_SSI_SACDAT, ®_val);
val = (reg_val >> 4) & 0x;
+ clk_disable_unprepare(fsl_ac97_data->clk);
+
return val;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] ASoC: fsl_ssi: AC'97 DAI driver needs probe method too
AC'97 DAI driver struct need the same probe method as
I2S one to setup DMA params in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 9c46c7d..2ce9e1d 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1101,6 +1101,7 @@ static const struct snd_soc_component_driver
fsl_ssi_component = {
static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
.bus_control = true,
+ .probe = fsl_ssi_dai_probe,
.playback = {
.stream_name = "AC97 Playback",
.channels_min = 2,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
AC'97 bus can support asymmetric playback/capture rates
so enable them in this case in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 2ce9e1d..f3034b9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1377,7 +1377,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
/* Are the RX and the TX clocks locked? */
if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
- ssi_private->cpu_dai_drv.symmetric_rates = 1;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ ssi_private->cpu_dai_drv.symmetric_rates = 1;
+
ssi_private->cpu_dai_drv.symmetric_channels = 1;
ssi_private->cpu_dai_drv.symmetric_samplebits = 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 4/6] ASoC: fsl_ssi: add AC'97 ops setting check and cleanup
Check whether setting AC'97 ops succeeded and clean them
on removal so the fsl_ssi driver can be reloaded.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index f3034b9..0b4fcd9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1340,7 +1340,11 @@ static int fsl_ssi_probe(struct platform_device *pdev)
fsl_ac97_data = ssi_private;
- snd_soc_set_ac97_ops_of_reset(&fsl_ssi_ac97_ops, pdev);
+ ret = snd_soc_set_ac97_ops_of_reset(&fsl_ssi_ac97_ops, pdev);
+ if (ret) {
+ dev_err(&pdev->dev, "could not set AC'97 ops\n");
+ return ret;
+ }
} else {
/* Initialize this copy of the CPU DAI driver structure */
memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
@@ -1480,6 +1484,9 @@ static int fsl_ssi_remove(struct platform_device *pdev)
if (ssi_private->soc->imx)
fsl_ssi_imx_clean(pdev, ssi_private);
+ if (fsl_ssi_is_ac97(ssi_private))
+ snd_soc_set_ac97_ops(NULL);
+
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] ASoC: fsl_ssi: instantiate AC'97 CODEC
Instantiate AC'97 CODEC in fsl_ssi driver AC'97 mode.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 0b4fcd9..e79dc16 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1460,6 +1460,27 @@ done:
_fsl_ssi_set_dai_fmt(&pdev->dev, ssi_private,
ssi_private->dai_fmt);
+ if (fsl_ssi_is_ac97(ssi_private)) {
+ u32 ssi_idx;
+
+ ret = of_property_read_u32(np, "cell-index", &ssi_idx);
+ if (ret) {
+ dev_err(&pdev->dev, "cannot get SSI index property\n");
+ goto error_sound_card;
+ }
+
+ ssi_private->pdev =
+ platform_device_register_data(NULL,
+ "ac97-codec", ssi_idx, NULL, 0);
+ if (IS_ERR(ssi_private->pdev)) {
+ ret = PTR_ERR(ssi_private->pdev);
+ dev_err(&pdev->dev,
+ "failed to register AC97 codec platform: %d\n",
+ ret);
+ goto error_sound_card;
+ }
+ }
+
return 0;
error_sound_card:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] ASoC: fsl_ssi: adjust set DAI format in AC'97 mode
Adjust set DAI format function in fsl_ssi driver so it
doesn't fail and clears RXDIR in AC'97 mode.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index e79dc16..d043c7c 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -900,14 +900,16 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
scr &= ~CCSR_SSI_SCR_SYS_CLK_EN;
break;
default:
- return -EINVAL;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ return -EINVAL;
}
stcr |= strcr;
srcr |= strcr;
- if (ssi_private->cpu_dai_drv.symmetric_rates) {
- /* Need to clear RXDIR when using SYNC mode */
+ if (ssi_private->cpu_dai_drv.symmetric_rates
+ || fsl_ssi_is_ac97(ssi_private)) {
+ /* Need to clear RXDIR when using SYNC or AC97 mode */
srcr &= ~CCSR_SSI_SRCR_RXDIR;
scr |= CCSR_SSI_SCR_SYN;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ASoC: fsl_ssi: enable AC'97 asymmetric rates
Maciej S. Szmigiero wrote:
/* Are the RX and the TX clocks locked? */
if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
- ssi_private->cpu_dai_drv.symmetric_rates = 1;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ ssi_private->cpu_dai_drv.symmetric_rates = 1;
+
Is this necessary? Why not just add fsl,ssi-asynchronous to the AC97
device tree node?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iommu/arm-smmu: Delete an unnecessary check before the function call "free_io_pgtable_ops"
From: Markus Elfring
Date: Sun, 28 Jun 2015 15:55:11 +0200
The free_io_pgtable_ops() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/iommu/arm-smmu-v3.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index f141301..8e9ec81 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1389,8 +1389,7 @@ static void arm_smmu_domain_free(struct iommu_domain
*domain)
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_device *smmu = smmu_domain->smmu;
- if (smmu_domain->pgtbl_ops)
- free_io_pgtable_ops(smmu_domain->pgtbl_ops);
+ free_io_pgtable_ops(smmu_domain->pgtbl_ops);
/* Free the CD and ASID, if we allocated them */
if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr
On 06/27/2015 11:52 AM, Andy Lutomirski wrote:
> On Sat, Jun 27, 2015 at 1:39 AM, Ingo Molnar wrote:
>>
>> * Ingo Molnar wrote:
>>
>>> So what's wrong with exposing them as a simplified PMU driver?
>>>
>>> That way we only expose the ones we want to - plus tooling can use all the
>>> rich
>>> perf features that can be used around this. (sampling, counting, call
>>> chains,
>>> etc.)
>>
>> See below code from Andy that exposes a single MSR via perf. At the core of
>> the
>> PMU driver is a single rdmsrl():
>>
>> +static void aperfmperf_event_start(struct perf_event *event, int flags)
>> +{
>> + u64 now;
>> +
>> + rdmsrl(event->hw.event_base, now);
>> + local64_set(&event->hw.prev_count, now);
>> +}
>>
I just sat down to do something similar to what Andy had proposed here :).
>> Now I think what we really want is to expose not a single MSR but multiple
>> MSRs in
>> a single driver, i.e. don't have one PMU driver per MSR, but have a driver
>> that
>> allows the exposure of select MSRs as counters.
>
> I'm way ahead of you: this driver can expose *two* MSRs as counters :)
>
> Seriously, though, it would be straightforward to make it handle a
> more general list, complete with non-architectural stuff (such as the
> upcoming PPERF in Skylake).
Is it easier to blacklist MSRs we don't want generally exposed, or only expose
the ones that we think are safe? That's sort of a devil's advocate sort of
question ;) and I'm wondering what the shorter list is.
>
> This driver only knows how to handle counters, though. I'm not sure
> whether all of the MSRs that turbostat needs are counters.
I knew that turbostat only did MSR reads and that's why turbostat's code was
changed in this patch. TBH I'm more concerned for software that monitors system
power consumption, performance, and load.
I'll take what Andy has proposed and expand on it.
P.
>
> --Andy
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7] dma: Add Xilinx AXI Direct Memory Access Engine driver support
On Sat, Jun 27, 2015 at 05:44:38PM +0300, Nicolae Rosia wrote: > On Sat, Jun 27, 2015 at 5:40 PM, Vinod Koul wrote: > [...] > >> Please let me know if you are not clear. > > No sorry am not... > > > > I asked how the device address in configured. For both MM2S S2MM you are > > using sg for memory address, where are you getting device adress, are you > > assuming/hardcoding or getting somehow, if so how? > As the name says, one end is memory (MM) and the other end is an AXI4 > Stream Bus (S) which has no concept of memory address. > So yes, it is hardcoded at design time. So where does the data go at the end of stream bus, who configures that? Shouldnt all this be at least documented... -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI-iproc: Delete unnecessary checks before two function calls
From: Markus Elfring Date: Sun, 28 Jun 2015 16:42:04 +0200 The functions phy_exit() and phy_power_off() test whether their argument is NULL and then return immediately. Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/pci/host/pcie-iproc.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c index d77481e..f875821 100644 --- a/drivers/pci/host/pcie-iproc.c +++ b/drivers/pci/host/pcie-iproc.c @@ -239,12 +239,9 @@ err_rm_root_bus: pci_remove_root_bus(bus); err_power_off_phy: - if (pcie->phy) - phy_power_off(pcie->phy); + phy_power_off(pcie->phy); err_exit_phy: - if (pcie->phy) - phy_exit(pcie->phy); - + phy_exit(pcie->phy); return ret; } EXPORT_SYMBOL(iproc_pcie_setup); -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [all better] Re: regression: massive trouble with fpu rework
On Sun, 28 Jun 2015, Mike Galbraith wrote: > > > > > BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily. > > > > Well, it is supposed to disable CPUID levels >= 0x04. This thing should > > *NEVER* be enabled, the last operating system that required it to be enabled > > was Windows 98. > > > > Can/do we override that crap during cpu init? If we cannot/don't, maybe > > instead of limping along with CPUID crippled, it would be better to either > > output a very nasty warning, or outright stop booting [with an appropriate > > error message] ? > > Why get all upset? We didn't even notice before, nor did/does that > other OS. A casual "BTW, your BIOS sucks.." should suffice, no? Oh, I am not upset, although I suppose my reply did look like it. Sorry about that. It is just that this kind of breakage should not be subtle if we can help it, because people will use a crippled system for years without noticing... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7] dma: Add Xilinx AXI Direct Memory Access Engine driver support
HI, On Sun, Jun 28, 2015 at 5:45 PM, Vinod Koul wrote: [...] >> > I asked how the device address in configured. For both MM2S S2MM you are >> > using sg for memory address, where are you getting device adress, are you >> > assuming/hardcoding or getting somehow, if so how? >> As the name says, one end is memory (MM) and the other end is an AXI4 >> Stream Bus (S) which has no concept of memory address. >> So yes, it is hardcoded at design time. > So where does the data go at the end of stream bus, who configures that? > Shouldnt all this be at least documented... You make the connection at design time. In Zynq7000 case, there's a dual core Cortex A9 coupled with an FPGA. While designing the FPGA part, you instantiate an Xilinx AXI DMA, on one side you connect it to an AXI4 Lite bus (which is memory mapped) and on the other side you connect your custom peripheral using an AXI4 Stream bus which has no concept of addresses. Here's a picture which depicts all of this [0]. Does this clear things up? [0] http://www.fpgadeveloper.com/wp-content/uploads/2014/08/fpga_developer_20140806_130447.png -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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, msr: Allow read access to /dev/cpu/X/msr
On Sun, 28 Jun 2015, Prarit Bhargava wrote: > Is it easier to blacklist MSRs we don't want generally exposed, or only expose > the ones that we think are safe? That's sort of a devil's advocate sort of > question ;) and I'm wondering what the shorter list is. The only way to make MSR access safe is to allow it only by whitelisting. The x86 platform restricts all MSR access to ring 0 for a damn good reason. Also, such a whitelist would most likely need to be vendor and model-aware, and to differentiate "allow reads" from "allow writes"... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr
On Fri, 26 Jun 2015, Prarit Bhargava wrote: > > The proper way to do this is to write a driver to only expose the MSRs > > that the user tools need, and nothing else. > > Will do -- At least I got everyone's attention with this :). IMHO we need both a new driver that exposes semanthic functionality instead of raw MSRs, and also to lock down the current MSR driver using processor vendor, family and model-aware whitelists. We have absolutely no idea of the real security impact of the CONFIG_X86_MSR /dev/cpu/cpu#/msr driver, as that driver allows CAP_SYS_RAWIO userspace to have complete access to all documented *and undocumented* MSRs. Maybe we could build on the ideas and data already colleced by the msr-safe LLNS code? https://github.com/scalability-llnl/msr-safe http://www.vi-hps.org/upload/program/espt-sc14/vi-hps-ESPT14-Shoga.pdf At the very least, their work on building a list of safe MSRs should help... Their code seems to be licensed under the GPLv3, which is a rather strange choice of license for a kernel module. A quick look using Debian's codesearch found these users of /dev/cpu/cpu#/msr: * cpufrequtils * flashrom * i7z * intel-gpu-tools * inteltool * mcelog * msrtool, msr-tools * PAPI (can use msr_safe) * powertop * qemu * slurm-llnl (maybe this can also use msr_safe?) * stressapptest * turbostat * wmlongrun, longrun * x86info * xserver-xorg-video-geode As well as the other stuff that ships from the Linux kernel tree. Looking at what they need the MSR access for (well, except for msrtools, which is just a way for shell scripts to easily talk to the MSR driver) might help define the problem space better. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] tty: add missing rcu_read_lock for task_pgrp
On 06/27/2015 08:51 PM, Patrick Donnelly wrote:
> task_pgrp requires an rcu or tasklist lock to be obtained if the returned pid
> is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the
> duration of use.
kill_pgrp() obtains tasklist_lock, so I don't see an unsafe deref.
> Signed-off-by: Patrick Donnelly
> ---
> drivers/tty/tty_io.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 57fc6ee..fbb55db 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -388,33 +388,39 @@ EXPORT_SYMBOL_GPL(tty_find_polling_driver);
> int tty_check_change(struct tty_struct *tty)
> {
> unsigned long flags;
> + struct pid *pgrp;
> int ret = 0;
>
> if (current->signal->tty != tty)
> return 0;
>
> - spin_lock_irqsave(&tty->ctrl_lock, flags);
> + rcu_read_lock();
> + pgrp = task_pgrp(current);
>
> + spin_lock_irqsave(&tty->ctrl_lock, flags);
> if (!tty->pgrp) {
> printk(KERN_WARNING "tty_check_change: tty->pgrp == NULL!\n");
> - goto out_unlock;
> + goto out_irqunlock;
> }
> - if (task_pgrp(current) == tty->pgrp)
> - goto out_unlock;
> + if (pgrp == tty->pgrp)
> + goto out_irqunlock;
> spin_unlock_irqrestore(&tty->ctrl_lock, flags);
> +
> if (is_ignored(SIGTTOU))
> - goto out;
> + goto out_rcuunlock;
> if (is_current_pgrp_orphaned()) {
> ret = -EIO;
> - goto out;
> + goto out_rcuunlock;
> }
> - kill_pgrp(task_pgrp(current), SIGTTOU, 1);
> + kill_pgrp(pgrp, SIGTTOU, 1);
> + rcu_read_unlock();
> set_thread_flag(TIF_SIGPENDING);
> ret = -ERESTARTSYS;
> -out:
> return ret;
> -out_unlock:
> +out_irqunlock:
> spin_unlock_irqrestore(&tty->ctrl_lock, flags);
> +out_rcuunlock:
> + rcu_read_unlock();
> return ret;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [4.1.0-07254-gc13c810] Regression: Bluetooth not working.
2015-06-26 16:28 GMT+02:00 Jörg Otte : > 2015-06-26 12:03 GMT+02:00 Jörg Otte : >> 2015-06-26 11:37 GMT+02:00 Marcel Holtmann : >>> Hi Joerg, >>> Bluetooth is inoperable in current Linus tree and the first bad commit is: 835a6a2f8603237a3e6cded5a6765090ecb06ea5 is the first bad commit commit 835a6a2f8603237a3e6cded5a6765090ecb06ea5 Author: Alexey Dobriyan Date: Wed Jun 10 20:28:33 2015 +0300 Bluetooth: Stop sabotaging list poisoning list_del() poisons pointers with special values, no need to overwrite them. Signed-off-by: Alexey Dobriyan Signed-off-by: Marcel Holtmann My BT adapter is an intel 8087:07da I reverted that commit and this fixed the problem for me. >>> >>> today we had a patch from Tedd fixing the list initialization in the HIDP >>> code. >>> >>> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c >>> index 9070dfd6b4ad..f1a117f8cad2 100644 >>> --- a/net/bluetooth/hidp/core.c >>> +++ b/net/bluetooth/hidp/core.c >>> @@ -915,6 +915,7 @@ static int hidp_session_new(struct hidp_session **out, >>> const bdaddr_t *bdaddr, >>> session->conn = l2cap_conn_get(conn); >>> session->user.probe = hidp_session_probe; >>> session->user.remove = hidp_session_remove; >>> + INIT_LIST_HEAD(&session->user.list); >>> session->ctrl_sock = ctrl_sock; >>> session->intr_sock = intr_sock; >>> skb_queue_head_init(&session->ctrl_transmit); >>> >>> Could this be fixing it for you as well? >>> >> I will check this when I am at home in the >> afternoon. >> > > The patch works for me too. > Ok, this was a little bit hasty! I now see the following additional problems: - System freeze on resume (occures always). - System freeze on shutdown (occures sometimes) - System freeze when BT-mouse is connecting (occures sometimes). Then I can't do anything except power off. This happens only if Bluetooth AND BT-mouse is activated. Thanks, Jörg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [all better] Re: regression: massive trouble with fpu rework
On Sun, 2015-06-28 at 12:06 -0300, Henrique de Moraes Holschuh wrote: > On Sun, 28 Jun 2015, Mike Galbraith wrote: > > > > > > BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily. > > > > > > Well, it is supposed to disable CPUID levels >= 0x04. This thing should > > > *NEVER* be enabled, the last operating system that required it to be > > > enabled > > > was Windows 98. > > > > > > Can/do we override that crap during cpu init? If we cannot/don't, maybe > > > instead of limping along with CPUID crippled, it would be better to either > > > output a very nasty warning, or outright stop booting [with an appropriate > > > error message] ? > > > > Why get all upset? We didn't even notice before, nor did/does that > > other OS. A casual "BTW, your BIOS sucks.." should suffice, no? > > Oh, I am not upset, although I suppose my reply did look like it. Sorry > about that. I didn't mean you personally of course, I meant the kernel ;-) > It is just that this kind of breakage should not be subtle if we can help > it, because people will use a crippled system for years without noticing... If you can use it without noticing for years, it ain't crippled, or? My point being that severity seems more akin to the box having a zit behind its left ear, in which case lobotomizing it seems a tad extreme. -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 v2 2/2] tty: check tcsetpgrp p is a process group
On 06/27/2015 08:51 PM, Patrick Donnelly wrote: > This fixes a bug where a process can set the foreground process group to its > pid even if its pid is not a valid pgrp. > > Signed-off-by: Patrick Donnelly > --- > drivers/tty/tty_io.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c > index fbb55db..01b4769 100644 > --- a/drivers/tty/tty_io.c > +++ b/drivers/tty/tty_io.c > @@ -2579,6 +2579,9 @@ static int tiocspgrp(struct tty_struct *tty, struct > tty_struct *real_tty, pid_t > retval = -ESRCH; > if (!pgrp) > goto out_unlock; > + retval = -EINVAL; > + if (!pid_task(pgrp, PIDTYPE_PGID)) > + goto out_unlock; This change implies that the sequence in session_of_pgrp() that specifically checks for pid_task(pgrp, PIDTYPE_PGID) == NULL is not doing anything useful. However, that hypothesis is directly contradicted by the comment above session_of_pgrp() "* This checks not only the pgrp, but falls back on the pid if no * satisfactory pgrp is found. I dunno - gdb doesn't work correctly * without this..." Regards, Peter Hurley > retval = -EPERM; > if (session_of_pgrp(pgrp) != task_session(current)) > goto out_unlock; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4.1.0-07254-gc13c810] Regression: Bluetooth not working.
On Sun, Jun 28, 2015 at 05:36:04PM +0200, Jörg Otte wrote: > 2015-06-26 16:28 GMT+02:00 Jörg Otte : > > 2015-06-26 12:03 GMT+02:00 Jörg Otte : > >> 2015-06-26 11:37 GMT+02:00 Marcel Holtmann : > >>> Hi Joerg, > >>> > Bluetooth is inoperable in current Linus tree and the > first bad commit is: > > 835a6a2f8603237a3e6cded5a6765090ecb06ea5 is the first bad commit > commit 835a6a2f8603237a3e6cded5a6765090ecb06ea5 > Author: Alexey Dobriyan > Date: Wed Jun 10 20:28:33 2015 +0300 > > Bluetooth: Stop sabotaging list poisoning > > list_del() poisons pointers with special values, no need to overwrite > them. > > Signed-off-by: Alexey Dobriyan > Signed-off-by: Marcel Holtmann > > My BT adapter is an intel 8087:07da > I reverted that commit and this fixed the problem for me. > >>> > >>> today we had a patch from Tedd fixing the list initialization in the HIDP > >>> code. > >>> > >>> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c > >>> index 9070dfd6b4ad..f1a117f8cad2 100644 > >>> --- a/net/bluetooth/hidp/core.c > >>> +++ b/net/bluetooth/hidp/core.c > >>> @@ -915,6 +915,7 @@ static int hidp_session_new(struct hidp_session > >>> **out, const bdaddr_t *bdaddr, > >>> session->conn = l2cap_conn_get(conn); > >>> session->user.probe = hidp_session_probe; > >>> session->user.remove = hidp_session_remove; > >>> + INIT_LIST_HEAD(&session->user.list); > >>> session->ctrl_sock = ctrl_sock; > >>> session->intr_sock = intr_sock; > >>> skb_queue_head_init(&session->ctrl_transmit); > >>> > >>> Could this be fixing it for you as well? > >>> > >> I will check this when I am at home in the > >> afternoon. > >> > > > > The patch works for me too. > > > Ok, this was a little bit hasty! > I now see the following additional problems: > > - System freeze on resume (occures always). > - System freeze on shutdown (occures sometimes) > - System freeze when BT-mouse is connecting (occures sometimes). > > Then I can't do anything except power off. > > This happens only if Bluetooth AND BT-mouse is activated. OK, what happens if you just revert only list_del 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: [RFC PATCH 0/3] restartable sequences: fast user-space percpu critical sections
- On Jun 27, 2015, at 12:25 PM, Andy Lutomirski l...@amacapital.net wrote: > Let me try to summarize some of the approaches with their pros and cons: > I can try summarizing a desiderata that I gather from this thread so far: - *very fast* accesses for per-cpu push/pop, per-cpu lock acquisition, and per-cpu counters, - guaranteed progress (don't loop forever when single-stepped), - critical section implementation flexibility: - can be written only in assembly or also in C, - provide a single building-block (e.g. cmpxchg) or allow applications/libraries to do arbitrary critical sections, - portability to non-x86 architectures, - low-intrusiveness for injection into applications (no signal handler, no segment selector used by pre-existing applications). - can be used by either a single or many shared objects per process, - don't disturb real-time scheduling, - minimal slowdown of kernel scheduling execution. More comments on each approach below: > --- percpu segment --- > > This is probably the simplest and might make sense regardless. > cmpxchg can be used to do an atomic push onto a linked list. I think > that unlocked cmpxchg16b can be used to get an atomic pop. (You'd > have the list head pointer next to an auxiliary pointer to the second > element in the list, perhaps.) Based on http://www.agner.org/optimize/instruction_tables.pdf On Intel Haswell: instruction latency (cycles) cmpxchg: 8 lock cmpxchg: 19 cmpxchg16b: 15 cmpxchg16b does not appear to be particularly fast (twice the latency of cmpxchg). > > You can also use this for limited forms of speculative locking. > Aborting cleanly if your lock is stolen might require the kernel's > help, though (you're now on the wrong cpu, so you can't atomically > poke the lock variable any more). > > The ABI is straightforward, and the only limitation on multiple users > in the same process is that they need to coordinate their offsets into > the percpu segment. One more downside about this approach: some applications already use the gs segment (AFAIK the wine emulator uses it), so can be prohibitive to use it from tracing code injected into pre-existing applications. Another downside is that it is x86-specific. > > --- vdso-provided atomic ops --- > > This could be quite flexible. The upside is that the ABI would be > straightforward (call a function with clearly-specified behavior). Following same ref as above, the call/ret pair alone would cost about 5 cycles. > The downside is that implementing it well might require percpu > segments and a certain amount of coordination, and it requires a > function call. Same downside as above about gs segment being already used by some applications. > > One nice thing about doing it in the vdso is that we can change the > implementation down the road. Yes, this is clearly an advantage over letting applications inline their cmpxchg on gs:. Same downside as above about being x86-specific. > > --- kernel preemption hooks --- > > I'm defining a preemption hook as an action taken by the kernel when a > user task is preempted during a critical section. > > As an upside, we get extremely efficient, almost arbitrary percpu > operations. We don't need to worry about memory ordering at all, > because the whole sequence aborts if anything else might run on the > same cpu. Push and pop are both easy. > > One con is that actually defining where the critical section is might > be nasty. If there's a single IP range, then two libraries could > fight over it. We could have a variable somewhere that you write to > arm the critical section, but that's a bit slower. My current understanding is that we have two means to tell the kernel "we are in a critical section": either through register content or through a per-thread memory area. Paul's implementation uses the instruction pointer, but it could perhaps use another reserved register state, which might help us do the critical functions in C code rather than assembly. It might be tricky to find a register that is guaranteed not to be used though, hence the per-thread memory area. The per-thread memory area has the advantage of allowing the critical sections to be implemented in C code rather than assembly, but, as you say, its downside is that we need at the very least to set/clear a TLS flag (or have a nesting counter) surrounding the critical section. This approach is quite similar to preempt_disable()/preempt_enable() in the Linux kernel. Another advantage of preempt migration hooks over migration hooks is that the critical section can assume it has mutually exclusive access, which is not the case for migration hooks, because it can be preempted and continue execution afterward. This means what can be achieved with e.g. "load+test+store" with preempt hook needs to be performed with "cmpxchg" with migration hooks. This might not be a huge issue for x86, but can become more expensive on other architectures. >
[PATCH 0/2] vfio: powerpc/spapr: Deletion of an unnecessary check
From: Markus Elfring Another update suggestion was taken into account after a patch was applied from static source code analysis. Markus Elfring (2): Delete an unnecessary check before the function call "kfree" One function call less in tce_iommu_attach_group() after kzalloc() failure drivers/vfio/vfio_iommu_spapr_tce.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.4.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 1/2] vfio: powerpc/spapr: Delete an unnecessary check before the function call "kfree"
From: Markus Elfring Date: Sun, 28 Jun 2015 17:43:48 +0200 The kfree() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/vfio/vfio_iommu_spapr_tce.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c index 0582b72..50ddfac 100644 --- a/drivers/vfio/vfio_iommu_spapr_tce.c +++ b/drivers/vfio/vfio_iommu_spapr_tce.c @@ -1215,7 +1215,7 @@ static int tce_iommu_attach_group(void *iommu_data, } unlock_exit: - if (ret && tcegrp) + if (ret) kfree(tcegrp); mutex_unlock(&container->lock); -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] vfio: powerpc/spapr: One function call less in tce_iommu_attach_group() after kzalloc() failure
From: Markus Elfring
Date: Sun, 28 Jun 2015 17:58:42 +0200
The kfree() function was called even if a previous memory allocation
try failed.
This implementation detail could be improved by the introduction
of another jump label.
Signed-off-by: Markus Elfring
---
drivers/vfio/vfio_iommu_spapr_tce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 50ddfac..2523075 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -1200,7 +1200,7 @@ static int tce_iommu_attach_group(void *iommu_data,
tcegrp = kzalloc(sizeof(*tcegrp), GFP_KERNEL);
if (!tcegrp) {
ret = -ENOMEM;
- goto unlock_exit;
+ goto unlock_container;
}
if (!table_group->ops || !table_group->ops->take_ownership ||
@@ -1217,7 +1217,7 @@ static int tce_iommu_attach_group(void *iommu_data,
unlock_exit:
if (ret)
kfree(tcegrp);
-
+unlock_container:
mutex_unlock(&container->lock);
return ret;
--
2.4.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] un-improve strrchr()
Commit 8da53d4595a53fb9a3380dd4d1c9bc24c7c9aab8
("lib/string.c: improve strrchr()") changed strrchr() implementation
from "rewind to the end and search backwards" to "search forward"
optimizing for characher not found case. However, common case is exactly
the opposite: string is absolute pathname, c is '/' always to be found.
Previous code did 1 branch per character + 1 branch for every character
in the last path component. Current code does 2 branches per characher
regardless.
Patch reverts to previous implementation (sans fixed coding style).
Signed-off-by: Alexey Dobriyan
---
Cc linux-kernel
lib/string.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/lib/string.c
+++ b/lib/string.c
@@ -313,12 +313,13 @@ EXPORT_SYMBOL(strchrnul);
*/
char *strrchr(const char *s, int c)
{
- const char *last = NULL;
+ const char *p = s + strlen(s);
+
do {
- if (*s == (char)c)
- last = s;
- } while (*s++);
- return (char *)last;
+ if (*p == (char)c)
+ return (char *)p;
+ } while (--p >= s);
+ return NULL;
}
EXPORT_SYMBOL(strrchr);
#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/
[PATCH]drivers:staging:visorbus:Fix checkpatch warnings
This patch fixes checkpatch warnings
Signed-off-by: Ravi Teja Darbha
---
drivers/staging/unisys/visorbus/visorchipset.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
b/drivers/staging/unisys/visorbus/visorchipset.c
index bb8087e..62f7f68 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1410,8 +1410,8 @@ visorchipset_chipset_ready(void)
static int
visorchipset_chipset_selftest(void)
{
-char env_selftest[20];
-char *envp[] = { env_selftest, NULL };
+static char env_selftest[20];
+static const char * const envp[] = { env_selftest, NULL };
sprintf(env_selftest, "SPARSP_SELFTEST=%d", 1);
kobject_uevent_env(&visorchipset_platform_device.dev.kobj, KOBJ_CHANGE,
@@ -1559,9 +1559,9 @@ static void
parahotplug_request_kickoff(struct parahotplug_request *req)
{
struct controlvm_message_packet *cmd = &req->msg.cmd;
-char env_cmd[40], env_id[40], env_state[40], env_bus[40], env_dev[40],
-env_func[40];
-char *envp[] = {
+static char env_cmd[40], env_id[40], env_state[40], env_bus[40],
+env_dev[40], env_func[40];
+static const char * const envp[] = {
env_cmd, env_id, env_state, env_bus, env_dev, env_func, NULL
};
--
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/
Re: [PATCH v2 1/2] tty: add missing rcu_read_lock for task_pgrp
On Sun, Jun 28, 2015 at 11:23 AM, Peter Hurley wrote: > On 06/27/2015 08:51 PM, Patrick Donnelly wrote: >> task_pgrp requires an rcu or tasklist lock to be obtained if the returned pid >> is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the >> duration of use. > > kill_pgrp() obtains tasklist_lock, so I don't see an unsafe deref. I see a race between looking up the pgrp via task_pgrp and passing it to kill_pgrp. The pgrp struct pid may be freed via setpgid/setsid, as mentioned in the comment for task_pgrp: * Without tasklist or rcu lock it is not safe to dereference * the result of task_pgrp/task_session even if task == current, * we can race with another thread doing sys_setsid/sys_setpgid. Getting the lock after the lookup is getting the lock too late. I could be wrong though as I'm no expert on locking in Linux. -- Patrick Donnelly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE
-- I am Mrs. Gloria C. Mackenzie, the power-ball lottery winner and I have donated $2,000,000.00 USD to you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/10] Drivers: hv: vmbus: Enable kexec and other misc cleanup
In addition to enabling kexec, this patch-set has a bunch of miscellaneous fixes. I have been having mail issues and hence resending the series. Alex Ng (1): Drivers: hv: balloon: Enable dynamic memory protocol negotiation with Windows 10 hosts K. Y. Srinivasan (1): Drivers: hv: vmbus: Permit sending of packets without payload Vitaly Kuznetsov (8): Drivers: hv: vmbus: remove hv_synic_free_cpu() call from hv_synic_cleanup() kexec: define kexec_in_progress in !CONFIG_KEXEC case Drivers: hv: vmbus: add special kexec handler Drivers: hv: don't do hypercalls when hypercall_page is NULL Drivers: hv: vmbus: add special crash handler Drivers: hv: vmbus: prefer 'die' notification chain to 'panic' Drivers: hv: kvp: check kzalloc return value Drivers: hv: fcopy: dynamically allocate smsg_out in fcopy_send_data() arch/x86/include/asm/mshyperv.h |4 ++ arch/x86/kernel/cpu/mshyperv.c | 46 ++ drivers/hv/channel.c|4 ++- drivers/hv/hv.c | 15 drivers/hv/hv_balloon.c | 26 +++--- drivers/hv/hv_fcopy.c | 21 +++ drivers/hv/hv_kvp.c |3 ++ drivers/hv/vmbus_drv.c | 69 -- include/linux/kexec.h |1 + 9 files changed, 163 insertions(+), 26 deletions(-) -- 1.7.4.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 RESEND 09/10] Drivers: hv: balloon: Enable dynamic memory protocol negotiation with Windows 10 hosts
From: Alex Ng
Support Win10 protocol for Dynamic Memory. Thia patch allows guests on Win10
hosts
to hot-add memory even when dynamic memory is not enabled on the guest.
Signed-off-by: Alex Ng
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_balloon.c | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 8a725cd..b853b4b 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -62,11 +62,13 @@
enum {
DYNMEM_PROTOCOL_VERSION_1 = DYNMEM_MAKE_VERSION(0, 3),
DYNMEM_PROTOCOL_VERSION_2 = DYNMEM_MAKE_VERSION(1, 0),
+ DYNMEM_PROTOCOL_VERSION_3 = DYNMEM_MAKE_VERSION(2, 0),
DYNMEM_PROTOCOL_VERSION_WIN7 = DYNMEM_PROTOCOL_VERSION_1,
DYNMEM_PROTOCOL_VERSION_WIN8 = DYNMEM_PROTOCOL_VERSION_2,
+ DYNMEM_PROTOCOL_VERSION_WIN10 = DYNMEM_PROTOCOL_VERSION_3,
- DYNMEM_PROTOCOL_VERSION_CURRENT = DYNMEM_PROTOCOL_VERSION_WIN8
+ DYNMEM_PROTOCOL_VERSION_CURRENT = DYNMEM_PROTOCOL_VERSION_WIN10
};
@@ -1296,13 +1298,25 @@ static void version_resp(struct hv_dynmem_device *dm,
if (dm->next_version == 0)
goto version_error;
- dm->next_version = 0;
memset(&version_req, 0, sizeof(struct dm_version_request));
version_req.hdr.type = DM_VERSION_REQUEST;
version_req.hdr.size = sizeof(struct dm_version_request);
version_req.hdr.trans_id = atomic_inc_return(&trans_id);
- version_req.version.version = DYNMEM_PROTOCOL_VERSION_WIN7;
- version_req.is_last_attempt = 1;
+ version_req.version.version = dm->next_version;
+
+ /*
+* Set the next version to try in case current version fails.
+* Win7 protocol ought to be the last one to try.
+*/
+ switch (version_req.version.version) {
+ case DYNMEM_PROTOCOL_VERSION_WIN8:
+ dm->next_version = DYNMEM_PROTOCOL_VERSION_WIN7;
+ version_req.is_last_attempt = 0;
+ break;
+ default:
+ dm->next_version = 0;
+ version_req.is_last_attempt = 1;
+ }
ret = vmbus_sendpacket(dm->dev->channel, &version_req,
sizeof(struct dm_version_request),
@@ -1442,7 +1456,7 @@ static int balloon_probe(struct hv_device *dev,
dm_device.dev = dev;
dm_device.state = DM_INITIALIZING;
- dm_device.next_version = DYNMEM_PROTOCOL_VERSION_WIN7;
+ dm_device.next_version = DYNMEM_PROTOCOL_VERSION_WIN8;
init_completion(&dm_device.host_event);
init_completion(&dm_device.config_event);
INIT_LIST_HEAD(&dm_device.ha_region_list);
@@ -1474,7 +1488,7 @@ static int balloon_probe(struct hv_device *dev,
version_req.hdr.type = DM_VERSION_REQUEST;
version_req.hdr.size = sizeof(struct dm_version_request);
version_req.hdr.trans_id = atomic_inc_return(&trans_id);
- version_req.version.version = DYNMEM_PROTOCOL_VERSION_WIN8;
+ version_req.version.version = DYNMEM_PROTOCOL_VERSION_WIN10;
version_req.is_last_attempt = 0;
ret = vmbus_sendpacket(dev->channel, &version_req,
--
1.7.4.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 RESEND 10/10] Drivers: hv: vmbus: Permit sending of packets without payload
The guest may have to send a completion packet back to the host. To support this usage, permit sending a packet without a payload - we would be only sending the descriptor in this case. Signed-off-by: K. Y. Srinivasan --- drivers/hv/channel.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index 603ce97..c4dcab0 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -601,6 +601,7 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, u64 aligned_data = 0; int ret; bool signal = false; + int num_vecs = ((bufferlen != 0) ? 3 : 1); /* Setup the descriptor */ @@ -618,7 +619,8 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, bufferlist[2].iov_base = &aligned_data; bufferlist[2].iov_len = (packetlen_aligned - packetlen); - ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, &signal); + ret = hv_ringbuffer_write(&channel->outbound, bufferlist, num_vecs, + &signal); /* * Signalling the host is conditional on many factors: -- 1.7.4.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 RESEND 05/10] Drivers: hv: vmbus: add special crash handler
From: Vitaly Kuznetsov
Full kernel hang is observed when kdump kernel starts after a crash. This
hang happens in vmbus_negotiate_version() function on
wait_for_completion() as Hyper-V host (Win2012R2 in my testing) never
responds to CHANNELMSG_INITIATE_CONTACT as it thinks the connection is
already established. We need to perform some mandatory minimalistic
cleanup before we start new kernel.
Reported-by: K. Y. Srinivasan
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
arch/x86/include/asm/mshyperv.h |2 ++
arch/x86/kernel/cpu/mshyperv.c | 22 ++
drivers/hv/vmbus_drv.c | 14 ++
3 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index d3db910..d02f9c9 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -22,4 +22,6 @@ void hv_remove_vmbus_irq(void);
void hv_setup_kexec_handler(void (*handler)(void));
void hv_remove_kexec_handler(void);
+void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
+void hv_remove_crash_handler(void);
#endif
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 09911aa..1a6e742 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -35,6 +35,7 @@ struct ms_hyperv_info ms_hyperv;
EXPORT_SYMBOL_GPL(ms_hyperv);
static void (*hv_kexec_handler)(void);
+static void (*hv_crash_handler)(struct pt_regs *regs);
#if IS_ENABLED(CONFIG_HYPERV)
static void (*vmbus_handler)(void);
@@ -85,6 +86,18 @@ void hv_remove_kexec_handler(void)
hv_kexec_handler = NULL;
}
EXPORT_SYMBOL_GPL(hv_remove_kexec_handler);
+
+void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs))
+{
+ hv_crash_handler = handler;
+}
+EXPORT_SYMBOL_GPL(hv_setup_crash_handler);
+
+void hv_remove_crash_handler(void)
+{
+ hv_crash_handler = NULL;
+}
+EXPORT_SYMBOL_GPL(hv_remove_crash_handler);
#endif
static void hv_machine_shutdown(void)
@@ -94,6 +107,14 @@ static void hv_machine_shutdown(void)
native_machine_shutdown();
}
+static void hv_machine_crash_shutdown(struct pt_regs *regs)
+{
+ if (hv_crash_handler)
+ hv_crash_handler(regs);
+ native_machine_crash_shutdown(regs);
+}
+
+
static uint32_t __init ms_hyperv_platform(void)
{
u32 eax;
@@ -167,6 +188,7 @@ static void __init ms_hyperv_init_platform(void)
#endif
machine_ops.shutdown = hv_machine_shutdown;
+ machine_ops.crash_shutdown = hv_machine_crash_shutdown;
}
const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 31748a2..1ed9b32 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1071,6 +1071,18 @@ static void hv_kexec_handler(void)
hv_cleanup();
};
+static void hv_crash_handler(struct pt_regs *regs)
+{
+ vmbus_initiate_unload();
+ /*
+* In crash handler we can't schedule synic cleanup for all CPUs,
+* doing the cleanup for current CPU only. This should be sufficient
+* for kdump.
+*/
+ hv_synic_cleanup(NULL);
+ hv_cleanup();
+};
+
static int __init hv_acpi_init(void)
{
int ret, t;
@@ -1104,6 +1116,7 @@ static int __init hv_acpi_init(void)
goto cleanup;
hv_setup_kexec_handler(hv_kexec_handler);
+ hv_setup_crash_handler(hv_crash_handler);
return 0;
@@ -1118,6 +1131,7 @@ static void __exit vmbus_exit(void)
int cpu;
hv_remove_kexec_handler();
+ hv_remove_crash_handler();
vmbus_connection.conn_state = DISCONNECTED;
hv_synic_clockevents_cleanup();
vmbus_disconnect();
--
1.7.4.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 RESEND 01/10] Drivers: hv: vmbus: remove hv_synic_free_cpu() call from hv_synic_cleanup()
From: Vitaly Kuznetsov We already have hv_synic_free() which frees all per-cpu pages for all CPUs, let's remove the hv_synic_free_cpu() call from hv_synic_cleanup() so it will be possible to do separate cleanup (writing to MSRs) and final freeing. This is going to be used to assist kexec. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan --- drivers/hv/hv.c|2 -- drivers/hv/vmbus_drv.c |1 + 2 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c index d3943bc..5b87042 100644 --- a/drivers/hv/hv.c +++ b/drivers/hv/hv.c @@ -530,6 +530,4 @@ void hv_synic_cleanup(void *arg) rdmsrl(HV_X64_MSR_SCONTROL, sctrl.as_uint64); sctrl.enable = 0; wrmsrl(HV_X64_MSR_SCONTROL, sctrl.as_uint64); - - hv_synic_free_cpu(cpu); } diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index cf20400..00d5158 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -1120,6 +1120,7 @@ static void __exit vmbus_exit(void) tasklet_kill(hv_context.event_dpc[cpu]); smp_call_function_single(cpu, hv_synic_cleanup, NULL, 1); } + hv_synic_free(); acpi_bus_unregister_driver(&vmbus_acpi_driver); hv_cpu_hotplug_quirk(false); } -- 1.7.4.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 RESEND 04/10] Drivers: hv: don't do hypercalls when hypercall_page is NULL
From: Vitaly Kuznetsov
At the very late stage of kexec a driver (which are not being unloaded) can
try to post a message or signal an event. This will crash the kernel as we
already did hv_cleanup() and the hypercall page is NULL.
Move all common (between 32 and 64 bit code) declarations to the beginning
of the do_hypercall() function. Unfortunately we have to write the
!hypercall_page check twice to not mix declarations and code.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 5b87042..41d8072 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -93,11 +93,14 @@ static int query_hypervisor_info(void)
*/
static u64 do_hypercall(u64 control, void *input, void *output)
{
-#ifdef CONFIG_X86_64
- u64 hv_status = 0;
u64 input_address = (input) ? virt_to_phys(input) : 0;
u64 output_address = (output) ? virt_to_phys(output) : 0;
void *hypercall_page = hv_context.hypercall_page;
+#ifdef CONFIG_X86_64
+ u64 hv_status = 0;
+
+ if (!hypercall_page)
+ return (u64)ULLONG_MAX;
__asm__ __volatile__("mov %0, %%r8" : : "r" (output_address) : "r8");
__asm__ __volatile__("call *%3" : "=a" (hv_status) :
@@ -112,13 +115,13 @@ static u64 do_hypercall(u64 control, void *input, void
*output)
u32 control_lo = control & 0x;
u32 hv_status_hi = 1;
u32 hv_status_lo = 1;
- u64 input_address = (input) ? virt_to_phys(input) : 0;
u32 input_address_hi = input_address >> 32;
u32 input_address_lo = input_address & 0x;
- u64 output_address = (output) ? virt_to_phys(output) : 0;
u32 output_address_hi = output_address >> 32;
u32 output_address_lo = output_address & 0x;
- void *hypercall_page = hv_context.hypercall_page;
+
+ if (!hypercall_page)
+ return (u64)ULLONG_MAX;
__asm__ __volatile__ ("call *%8" : "=d"(hv_status_hi),
"=a"(hv_status_lo) : "d" (control_hi),
--
1.7.4.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 RESEND 03/10] Drivers: hv: vmbus: add special kexec handler
From: Vitaly Kuznetsov
When general-purpose kexec (not kdump) is being performed in Hyper-V guest
the newly booted kernel fails with an MCE error coming from the host. It
is the same error which was fixed in the "Drivers: hv: vmbus: Implement
the protocol for tearing down vmbus state" commit - monitor pages remain
special and when they're being written to (as the new kernel doesn't know
these pages are special) bad things happen. We need to perform some
minimalistic cleanup before booting a new kernel on kexec. To do so we
need to register a special machine_ops.shutdown handler to be executed
before the native_machine_shutdown(). Registering a shutdown notification
handler via the register_reboot_notifier() call is not sufficient as it
happens to early for our purposes. machine_ops is not being exported to
modules (and I don't think we want to export it) so let's do this in
mshyperv.c
The minimalistic cleanup consists of cleaning up clockevents, synic MSRs,
guest os id MSR, and hypercall MSR.
Kdump doesn't require all this stuff as it lives in a separate memory
space.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
arch/x86/include/asm/mshyperv.h |2 ++
arch/x86/kernel/cpu/mshyperv.c | 24
drivers/hv/vmbus_drv.c | 14 ++
3 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index c163215..d3db910 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -20,4 +20,6 @@ void hyperv_vector_handler(struct pt_regs *regs);
void hv_setup_vmbus_irq(void (*handler)(void));
void hv_remove_vmbus_irq(void);
+void hv_setup_kexec_handler(void (*handler)(void));
+void hv_remove_kexec_handler(void);
#endif
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 939155f..09911aa 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -28,10 +29,13 @@
#include
#include
#include
+#include
struct ms_hyperv_info ms_hyperv;
EXPORT_SYMBOL_GPL(ms_hyperv);
+static void (*hv_kexec_handler)(void);
+
#if IS_ENABLED(CONFIG_HYPERV)
static void (*vmbus_handler)(void);
@@ -69,8 +73,27 @@ void hv_remove_vmbus_irq(void)
}
EXPORT_SYMBOL_GPL(hv_setup_vmbus_irq);
EXPORT_SYMBOL_GPL(hv_remove_vmbus_irq);
+
+void hv_setup_kexec_handler(void (*handler)(void))
+{
+ hv_kexec_handler = handler;
+}
+EXPORT_SYMBOL_GPL(hv_setup_kexec_handler);
+
+void hv_remove_kexec_handler(void)
+{
+ hv_kexec_handler = NULL;
+}
+EXPORT_SYMBOL_GPL(hv_remove_kexec_handler);
#endif
+static void hv_machine_shutdown(void)
+{
+ if (kexec_in_progress && hv_kexec_handler)
+ hv_kexec_handler();
+ native_machine_shutdown();
+}
+
static uint32_t __init ms_hyperv_platform(void)
{
u32 eax;
@@ -143,6 +166,7 @@ static void __init ms_hyperv_init_platform(void)
no_timer_check = 1;
#endif
+ machine_ops.shutdown = hv_machine_shutdown;
}
const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 00d5158..31748a2 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1060,6 +1060,17 @@ static struct acpi_driver vmbus_acpi_driver = {
},
};
+static void hv_kexec_handler(void)
+{
+ int cpu;
+
+ hv_synic_clockevents_cleanup();
+ vmbus_initiate_unload();
+ for_each_online_cpu(cpu)
+ smp_call_function_single(cpu, hv_synic_cleanup, NULL, 1);
+ hv_cleanup();
+};
+
static int __init hv_acpi_init(void)
{
int ret, t;
@@ -1092,6 +1103,8 @@ static int __init hv_acpi_init(void)
if (ret)
goto cleanup;
+ hv_setup_kexec_handler(hv_kexec_handler);
+
return 0;
cleanup:
@@ -1104,6 +1117,7 @@ static void __exit vmbus_exit(void)
{
int cpu;
+ hv_remove_kexec_handler();
vmbus_connection.conn_state = DISCONNECTED;
hv_synic_clockevents_cleanup();
vmbus_disconnect();
--
1.7.4.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 RESEND 02/10] kexec: define kexec_in_progress in !CONFIG_KEXEC case
From: Vitaly Kuznetsov
If some piece of code wants to check kexec_in_progress it has to be put
in #ifdef CONFIG_KEXEC block to not break the build in !CONFIG_KEXEC
case. Overcome this limitation by defining kexec_in_progress to false.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
include/linux/kexec.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e804306..b63218f 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -323,6 +323,7 @@ struct pt_regs;
struct task_struct;
static inline void crash_kexec(struct pt_regs *regs) { }
static inline int kexec_should_crash(struct task_struct *p) { return 0; }
+#define kexec_in_progress false
#endif /* CONFIG_KEXEC */
#endif /* !defined(__ASSEBMLY__) */
--
1.7.4.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 RESEND 07/10] Drivers: hv: kvp: check kzalloc return value
From: Vitaly Kuznetsov kzalloc() return value check was accidentally lost in 11bc3a5fa91f: "Drivers: hv: kvp: convert to hv_utils_transport" commit. We don't need to reset kvp_transaction.state here as we have the kvp_timeout_func() timeout function and in case we're in OOM situation it is preferable to wait. Reported-by: Dan Carpenter Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan --- drivers/hv/hv_kvp.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c index d85798d..74c38a9 100644 --- a/drivers/hv/hv_kvp.c +++ b/drivers/hv/hv_kvp.c @@ -353,6 +353,9 @@ kvp_send_key(struct work_struct *dummy) return; message = kzalloc(sizeof(*message), GFP_KERNEL); + if (!message) + return; + message->kvp_hdr.operation = operation; message->kvp_hdr.pool = pool; in_msg = kvp_transaction.kvp_msg; -- 1.7.4.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 REESEND 06/10] Drivers: hv: vmbus: prefer 'die' notification chain to 'panic'
From: Vitaly Kuznetsov
current_pt_regs() sometimes returns regs of the userspace process and in
case of a kernel crash this is not what we need to report. E.g. when we
trigger crash with sysrq we see the following:
...
RIP: 0010:[] []
sysrq_handle_crash+0x16/0x20
RSP: 0018:8800db0a7d88 EFLAGS: 00010246
RAX: 000f RBX: 820a0660 RCX:
...
at the same time current_pt_regs() give us:
ip=7f899ea7e9e0, ax=ffda, bx=26c81a0, cx=7f899ea7e9e0, ...
These registers come from the userspace process triggered the crash. As we
don't even know which process it was this information is rather useless.
When kernel crash happens through 'die' proper regs are being passed to
all receivers on the die_chain (and panic_notifier_list is being notified
with the string passed to panic() only). If panic() is called manually
(e.g. on BUG()) we won't get 'die' notification so keep the 'panic'
notification reporter as well but guard against double reporting.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/vmbus_drv.c | 40
1 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 1ed9b32..b6114cc 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "hyperv_vmbus.h"
static struct acpi_device *hv_acpi_dev;
@@ -48,12 +49,18 @@ static struct completion probe_event;
static int irq;
-static int hyperv_panic_event(struct notifier_block *nb,
- unsigned long event, void *ptr)
+static void hyperv_report_panic(struct pt_regs *regs)
{
- struct pt_regs *regs;
+ static bool panic_reported;
- regs = current_pt_regs();
+ /*
+* We prefer to report panic on 'die' chain as we have proper
+* registers to report, but if we miss it (e.g. on BUG()) we need
+* to report it on 'panic'.
+*/
+ if (panic_reported)
+ return;
+ panic_reported = true;
wrmsrl(HV_X64_MSR_CRASH_P0, regs->ip);
wrmsrl(HV_X64_MSR_CRASH_P1, regs->ax);
@@ -65,9 +72,32 @@ static int hyperv_panic_event(struct notifier_block *nb,
* Let Hyper-V know there is crash data available
*/
wrmsrl(HV_X64_MSR_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY);
+}
+
+static int hyperv_panic_event(struct notifier_block *nb, unsigned long val,
+ void *args)
+{
+ struct pt_regs *regs;
+
+ regs = current_pt_regs();
+
+ hyperv_report_panic(regs);
return NOTIFY_DONE;
}
+static int hyperv_die_event(struct notifier_block *nb, unsigned long val,
+ void *args)
+{
+ struct die_args *die = (struct die_args *)args;
+ struct pt_regs *regs = die->regs;
+
+ hyperv_report_panic(regs);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block hyperv_die_block = {
+ .notifier_call = hyperv_die_event,
+};
static struct notifier_block hyperv_panic_block = {
.notifier_call = hyperv_panic_event,
};
@@ -842,6 +872,7 @@ static int vmbus_bus_init(int irq)
* Only register if the crash MSRs are available
*/
if (ms_hyperv.features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+ register_die_notifier(&hyperv_die_block);
atomic_notifier_chain_register(&panic_notifier_list,
&hyperv_panic_block);
}
@@ -1139,6 +1170,7 @@ static void __exit vmbus_exit(void)
tasklet_kill(&msg_dpc);
vmbus_free_channels();
if (ms_hyperv.features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+ unregister_die_notifier(&hyperv_die_block);
atomic_notifier_chain_unregister(&panic_notifier_list,
&hyperv_panic_block);
}
--
1.7.4.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 RESEND 08/10] Drivers: hv: fcopy: dynamically allocate smsg_out in fcopy_send_data()
From: Vitaly Kuznetsov
struct hv_start_fcopy is too big to be on stack on i386, the following
warning is reported:
>> drivers/hv/hv_fcopy.c:159:1: warning: the frame size of 1088 bytes is larger
>> than 1024 bytes [-Wframe-larger-than=]
Reported-by: kbuild test robot
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_fcopy.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index b50dd33..db4b887 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -116,7 +116,7 @@ static int fcopy_handle_handshake(u32 version)
static void fcopy_send_data(struct work_struct *dummy)
{
- struct hv_start_fcopy smsg_out;
+ struct hv_start_fcopy *smsg_out = NULL;
int operation = fcopy_transaction.fcopy_msg->operation;
struct hv_start_fcopy *smsg_in;
void *out_src;
@@ -136,21 +136,24 @@ static void fcopy_send_data(struct work_struct *dummy)
switch (operation) {
case START_FILE_COPY:
out_len = sizeof(struct hv_start_fcopy);
- memset(&smsg_out, 0, out_len);
- smsg_out.hdr.operation = operation;
+ smsg_out = kzalloc(sizeof(*smsg_out), GFP_KERNEL);
+ if (!smsg_out)
+ return;
+
+ smsg_out->hdr.operation = operation;
smsg_in = (struct hv_start_fcopy *)fcopy_transaction.fcopy_msg;
utf16s_to_utf8s((wchar_t *)smsg_in->file_name, W_MAX_PATH,
UTF16_LITTLE_ENDIAN,
- (__u8 *)&smsg_out.file_name, W_MAX_PATH - 1);
+ (__u8 *)&smsg_out->file_name, W_MAX_PATH - 1);
utf16s_to_utf8s((wchar_t *)smsg_in->path_name, W_MAX_PATH,
UTF16_LITTLE_ENDIAN,
- (__u8 *)&smsg_out.path_name, W_MAX_PATH - 1);
+ (__u8 *)&smsg_out->path_name, W_MAX_PATH - 1);
- smsg_out.copy_flags = smsg_in->copy_flags;
- smsg_out.file_size = smsg_in->file_size;
- out_src = &smsg_out;
+ smsg_out->copy_flags = smsg_in->copy_flags;
+ smsg_out->file_size = smsg_in->file_size;
+ out_src = smsg_out;
break;
default:
@@ -168,6 +171,8 @@ static void fcopy_send_data(struct work_struct *dummy)
fcopy_transaction.state = HVUTIL_READY;
}
}
+ kfree(smsg_out);
+
return;
}
--
1.7.4.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] un-improve strrchr()
On Sun, 2015-06-28 at 19:44 +0300, Alexey Dobriyan wrote:
> Commit 8da53d4595a53fb9a3380dd4d1c9bc24c7c9aab8
> ("lib/string.c: improve strrchr()") changed strrchr() implementation
> from "rewind to the end and search backwards" to "search forward"
> optimizing for characher not found case. However, common case is exactly
> the opposite: string is absolute pathname, c is '/' always to be found.
>
> Previous code did 1 branch per character + 1 branch for every character
> in the last path component. Current code does 2 branches per characher
> regardless.
Are you comparing total cycles of all of the branches
in the called functions too?
As written the current version removes the strlen call.
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -313,12 +313,13 @@ EXPORT_SYMBOL(strchrnul);
> */
> char *strrchr(const char *s, int c)
> {
> - const char *last = NULL;
> + const char *p = s + strlen(s);
> +
> do {
> - if (*s == (char)c)
> - last = s;
> - } while (*s++);
> - return (char *)last;
> + if (*p == (char)c)
> + return (char *)p;
> + } while (--p >= s);
> + return NULL;
> }
> EXPORT_SYMBOL(strrchr);
> #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: [tip:irq/urgent] avr32/at32ap: Fix race in installing chained IRQ handler
Around Fri 26 Jun 2015 12:47:18 -0700 or thereabout, tip-bot for Thomas
Gleixner wrote:
> avr32/at32ap: Fix race in installing chained IRQ handler
>
> Reported-by: Russell King
> Signed-off-by: Thomas Gleixner
> Cc: Julia Lawall
> Cc: Haavard Skinnemoen
> Cc: Hans-Christian Egtvedt
> ---
> arch/avr32/mach-at32ap/extint.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/avr32/mach-at32ap/extint.c b/arch/avr32/mach-at32ap/extint.c
> index cfb298d..2d48b6a 100644
> --- a/arch/avr32/mach-at32ap/extint.c
> +++ b/arch/avr32/mach-at32ap/extint.c
> @@ -231,8 +231,7 @@ static int __init eic_probe(struct platform_device *pdev)
> irq_set_chip_data(eic->first_irq + i, eic);
> }
>
> - irq_set_chained_handler(int_irq, demux_eic_irq);
> - irq_set_handler_data(int_irq, eic);
> + irq_set_chained_handler_and_data(int_irq, demux_eic_irq, eic);
>
> if (pdev->id == 0) {
> nmi_eic = eic;
Good fix, wil you pass it through your git tree, or would you prefer I add it
to the AVR32 tree? I have nothing in the pipe, hence feel free to add it to a
series if you are preparing fixes.
Acked-by: Hans-Christian Egtvedt
--
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] SCSI: DTC: Removed 0 initialization for statics
Removed unneccessary initialization of zero to a static variable
Signed-off-by: Rudhresh Kumar J
---
drivers/scsi/dtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
index 4c74c7b..99164d6 100644
--- a/drivers/scsi/dtc.c
+++ b/drivers/scsi/dtc.c
@@ -150,7 +150,7 @@ static const struct signature {
static int __init dtc_setup(char *str)
{
- static int commandline_current = 0;
+ static int commandline_current;
int i;
int ints[10];
@@ -188,7 +188,7 @@ __setup("dtc=", dtc_setup);
static int __init dtc_detect(struct scsi_host_template * tpnt)
{
- static int current_override = 0, current_base = 0;
+ static int current_override, current_base;
struct Scsi_Host *instance;
unsigned int addr;
void __iomem *base;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
W dniu 28.06.2015 16:01, Timur Tabi pisze:
> Maciej S. Szmigiero wrote:
>> /* Are the RX and the TX clocks locked? */
>> if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
>> -ssi_private->cpu_dai_drv.symmetric_rates = 1;
>> +if (!fsl_ssi_is_ac97(ssi_private))
>> +ssi_private->cpu_dai_drv.symmetric_rates = 1;
>> +
>
> Is this necessary? Why not just add fsl,ssi-asynchronous to the AC97 device
> tree node?
Because in the AC'97 mode the driver supports only one channel config and one
sample format
anyway the remaining settings controlled by this property don't do anything.
Since it should be safe to enable asymmetric rates with any AC'97 CODEC I think
it is good
to do it in driver than to add "fsl,ssi-asynchronous" to every AC'97 DT node.
Also the description of this property in fsl,ssi.txt looks like that it only
makes sense in
non-AC'97 mode.
Best regards,
Maciej Szmigiero
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 4/6] slim: qcom: Add Qualcomm Slimbus controller driver
On 6/17/2015 7:53 AM, Mark Brown wrote:
On Tue, Jun 16, 2015 at 07:46:02PM -0600, Sagar Dharia wrote:
+ - dmaengine, and pipes used to communicate between controller and memory if
+ sps-BAM HW is used
This needs more detail.
+*/
+ mb();
+ if (notify_rx)
+ complete(&dev->rx_msgq_notify);
+ }
+ return IRQ_HANDLED;
This interrupt handler unconditionally returns IRQ_HANDLED regardless of
if that's true or not.
Some interrupt handling is done in ISR itself. RX-msgq thread
notifier/workQ is only used for items that can sleep/operations that can
take longer. (e.g. assignment of logical address based on report_present
message)
That's the reason IRQ_HANDLED is always true here.
+static void msm_slim_wait_retry(struct msm_slim_ctrl *dev)
+{
+ int msec_per_frm = 0;
+ int sfr_per_sec;
+
+ /* Wait for 1 superframe, or default time and then retry */
+ sfr_per_sec = dev->framer.superfreq /
+ (1 << (SLIM_MAX_CLK_GEAR - dev->ctrl.clkgear));
+ if (sfr_per_sec)
+ msec_per_frm = MSEC_PER_SEC / sfr_per_sec;
+ if (msec_per_frm < DEF_RETRY_MS)
+ msec_per_frm = DEF_RETRY_MS;
+ msleep(msec_per_frm);
+}
Is this device specific?
This is seen on most of the Qualcomm-controllers I've worked with, where
retries in early initialization were needed to avoid issues due to noise.
+static void msm_slim_cb(void *ctx, int err)
+{
+ if (err)
+ pr_err("MSM-slim completion reported err:%d\n", err);
dev_err()?
+ else if (ctx)
+ complete(ctx);
+}
That's weird, if we get an error we don't signal whatever's waiting -
won't it just time out at best then? Also, what happens if we get
neither an error nor context?
+ if (txn->msg->wbuf)
+ memcpy(puc, txn->msg->wbuf, txn->msg->num_bytes);
+ msm_slim_queue_tx(dev, pbuf, txn->rl, MGR_TX_MSG);
+ timeout = wait_for_completion_timeout(&done,
+ msecs_to_jiffies(txn->rl + 100));
+
+ if (!timeout)
+ dev_err(dev->dev, "TX timed out:MC:0x%x,mt:0x%x\n", txn->mc,
+ txn->mt);
+
+ mutex_unlock(&dev->txn_lock);
+ return timeout ? 0 : -ETIMEDOUT;
+}
Shouldn't we provide a route for error reports here (and might some of
this timeout stuff go into the core)?
Sure, good point. If I move it to core, all controllers will be expected
to have 'write-done' notification. If that's a fair assumption, I will
move it to core.
That will also mean the above callback/completion will move to framework.
+
+ if ((msm_slim_put_rx(dev, (u8 *)buf)) != -ENODATA) {
+ len = buf[0] & 0x1F;
+ mt = (buf[0] >> 5) & 0x7;
+ mc = buf[1];
+ if (mt == SLIM_MSG_MT_CORE &&
+ mc == SLIM_MSG_MC_REPORT_PRESENT) {
Looks like a switch statement.
+static int msm_slim_rx_msgq_thread(void *data)
+{
+ struct msm_slim_ctrl *dev = (struct msm_slim_ctrl *)data;
+ struct completion *notify = &dev->rx_msgq_notify;
+ int ret;
+
+ while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ ret = wait_for_completion_interruptible(notify);
+
+ if (ret)
+ dev_err(dev->dev, "rx thread wait error:%d\n", ret);
+ else
+ msm_slim_rxwq(dev);
+ }
+
+ return 0;
+}
It's not entirely clear to me why this is a kthread rather than a
workqueue or something. I'm also unclear what happens if more than one
piece of work is queued prior to msm_slim_rxwq() running, it looks like
it only handles a single operation.
Sure, I will change this to workqueue. That should not be a problem.
+ /* SLEW RATE register for this slimbus */
+ dev->slew_mem = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "slimbus_slew_reg");
+ if (!dev->slew_mem) {
+ dev_err(&pdev->dev, "no slimbus slew resource\n");
+ return;
+ }
Warning not an error isn't it?
+ hclk = clk_get(&pdev->dev, "iface_clk");
+ if (IS_ERR(hclk))
+ return PTR_ERR(hclk);
devm_clk_get()
+ ret = clk_set_rate(rclk, SLIM_ROOT_FREQ);
You're ignoring this error in spite of assigning to ret.
+ slim_mem = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "slimbus_physical");
+ if (!slim_mem) {
+ dev_err(&pdev->dev, "no slimbus physical memory resource\n");
+ ret = ENODEV;
+ goto err_get_mem_failed;
+ }
+ slim_io = request_mem_region(slim_mem->start, resource_size(slim_mem),
+ pdev->name);
+ if (!slim_io) {
+ dev_err(&pdev->d
Re: [PATCH v2 1/2] tty: add missing rcu_read_lock for task_pgrp
On 06/28/2015 01:20 PM, Patrick Donnelly wrote: > On Sun, Jun 28, 2015 at 11:23 AM, Peter Hurley > wrote: >> On 06/27/2015 08:51 PM, Patrick Donnelly wrote: >>> task_pgrp requires an rcu or tasklist lock to be obtained if the returned >>> pid >>> is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the >>> duration of use. >> >> kill_pgrp() obtains tasklist_lock, so I don't see an unsafe deref. > > I see a race between looking up the pgrp via task_pgrp and passing it > to kill_pgrp. The pgrp struct pid may be freed via setpgid/setsid, as > mentioned in the comment for task_pgrp: > > * Without tasklist or rcu lock it is not safe to dereference > * the result of task_pgrp/task_session even if task == current, > * we can race with another thread doing sys_setsid/sys_setpgid. > > Getting the lock after the lookup is getting the lock too late. I > could be wrong though as I'm no expert on locking in Linux. I suppose it can't hurt; please add similar logic to job_control() in drivers/tty/n_tty.c which handles the corresponding SIGTTIN signal conditions. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] tty: add missing rcu_read_lock for task_pgrp
Hi Patrick,
On 06/27/2015 08:51 PM, Patrick Donnelly wrote:
> task_pgrp requires an rcu or tasklist lock to be obtained if the returned pid
> is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the
> duration of use.
>
> Signed-off-by: Patrick Donnelly
> ---
> drivers/tty/tty_io.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 57fc6ee..fbb55db 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -388,33 +388,39 @@ EXPORT_SYMBOL_GPL(tty_find_polling_driver);
> int tty_check_change(struct tty_struct *tty)
> {
> unsigned long flags;
> + struct pid *pgrp;
> int ret = 0;
>
> if (current->signal->tty != tty)
> return 0;
>
> - spin_lock_irqsave(&tty->ctrl_lock, flags);
> + rcu_read_lock();
> + pgrp = task_pgrp(current);
>
> + spin_lock_irqsave(&tty->ctrl_lock, flags);
> if (!tty->pgrp) {
> printk(KERN_WARNING "tty_check_change: tty->pgrp == NULL!\n");
> - goto out_unlock;
> + goto out_irqunlock;
The label name changing is not really necessary and would reduce diff count.
It would be nice to get the printk() out from the locks as well (in a follow-on
patch?)
Regards,
Peter Hurley
> }
> - if (task_pgrp(current) == tty->pgrp)
> - goto out_unlock;
> + if (pgrp == tty->pgrp)
> + goto out_irqunlock;
> spin_unlock_irqrestore(&tty->ctrl_lock, flags);
> +
> if (is_ignored(SIGTTOU))
> - goto out;
> + goto out_rcuunlock;
> if (is_current_pgrp_orphaned()) {
> ret = -EIO;
> - goto out;
> + goto out_rcuunlock;
> }
> - kill_pgrp(task_pgrp(current), SIGTTOU, 1);
> + kill_pgrp(pgrp, SIGTTOU, 1);
> + rcu_read_unlock();
> set_thread_flag(TIF_SIGPENDING);
> ret = -ERESTARTSYS;
> -out:
> return ret;
> -out_unlock:
> +out_irqunlock:
> spin_unlock_irqrestore(&tty->ctrl_lock, flags);
> +out_rcuunlock:
> + rcu_read_unlock();
> return ret;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpu: host1x: Fix MLOCK's debug info
MLOCK's debug info, spewed on CDMA timeout, contains meaningless MLOCK
owner channel ID because HOST1X_SYNC_MLOCK_OWNER_CHID_F() returns shifted
value, while unshifted should be used. Fix it by changing '_F' to '_V'.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/hw/debug_hw.c | 2 +-
drivers/gpu/host1x/hw/hw_host1x01_sync.h | 8
drivers/gpu/host1x/hw/hw_host1x02_sync.h | 8
drivers/gpu/host1x/hw/hw_host1x04_sync.h | 8
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c
index 791de93..cc3f182 100644
--- a/drivers/gpu/host1x/hw/debug_hw.c
+++ b/drivers/gpu/host1x/hw/debug_hw.c
@@ -298,7 +298,7 @@ static void host1x_debug_show_mlocks(struct host1x *host,
struct output *o)
host1x_sync_readl(host, HOST1X_SYNC_MLOCK_OWNER(i));
if (HOST1X_SYNC_MLOCK_OWNER_CH_OWNS_V(owner))
host1x_debug_output(o, "%d: locked by channel %d\n",
- i, HOST1X_SYNC_MLOCK_OWNER_CHID_F(owner));
+ i, HOST1X_SYNC_MLOCK_OWNER_CHID_V(owner));
else if (HOST1X_SYNC_MLOCK_OWNER_CPU_OWNS_V(owner))
host1x_debug_output(o, "%d: locked by cpu\n", i);
else
diff --git a/drivers/gpu/host1x/hw/hw_host1x01_sync.h
b/drivers/gpu/host1x/hw/hw_host1x01_sync.h
index ac704e5..31238c2 100644
--- a/drivers/gpu/host1x/hw/hw_host1x01_sync.h
+++ b/drivers/gpu/host1x/hw/hw_host1x01_sync.h
@@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned int
id)
}
#define HOST1X_SYNC_MLOCK_OWNER(id) \
host1x_sync_mlock_owner_r(id)
-static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
+static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
{
- return (v & 0xf) << 8;
+ return (v >> 8) & 0xf;
}
-#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
- host1x_sync_mlock_owner_chid_f(v)
+#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
+ host1x_sync_mlock_owner_chid_v(v)
static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
{
return (r >> 1) & 0x1;
diff --git a/drivers/gpu/host1x/hw/hw_host1x02_sync.h
b/drivers/gpu/host1x/hw/hw_host1x02_sync.h
index 4495401..540c7b6 100644
--- a/drivers/gpu/host1x/hw/hw_host1x02_sync.h
+++ b/drivers/gpu/host1x/hw/hw_host1x02_sync.h
@@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned int
id)
}
#define HOST1X_SYNC_MLOCK_OWNER(id) \
host1x_sync_mlock_owner_r(id)
-static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
+static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
{
- return (v & 0xf) << 8;
+ return (v >> 8) & 0xf;
}
-#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
- host1x_sync_mlock_owner_chid_f(v)
+#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
+ host1x_sync_mlock_owner_chid_v(v)
static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
{
return (r >> 1) & 0x1;
diff --git a/drivers/gpu/host1x/hw/hw_host1x04_sync.h
b/drivers/gpu/host1x/hw/hw_host1x04_sync.h
index ef2275b..3d6c8ec 100644
--- a/drivers/gpu/host1x/hw/hw_host1x04_sync.h
+++ b/drivers/gpu/host1x/hw/hw_host1x04_sync.h
@@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned int
id)
}
#define HOST1X_SYNC_MLOCK_OWNER(id) \
host1x_sync_mlock_owner_r(id)
-static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
+static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
{
- return (v & 0xf) << 8;
+ return (v >> 8) & 0xf;
}
-#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
- host1x_sync_mlock_owner_chid_f(v)
+#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
+ host1x_sync_mlock_owner_chid_v(v)
static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
{
return (r >> 1) & 0x1;
--
2.4.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] ARM: tegra: paz00: set gpiod_lookup table conn_id's
Commit 72daceb9a10a ("net: rfkill: gpio: Add default GPIO driver mappings
for ACPI") removed possibility to request GPIO by table index for non-ACPI
platforms without changing it users. As result "shutdown" GPIO request
will fail if request for "reset" GPIO succeeded or "reset" will be
requested instead of "shutdown" if "reset" wasn't defined. Fix it by
setting conn_id's in gpiod_lookup_table.
Signed-off-by: Dmitry Osipenko
Fixes: 72daceb (net: rfkill: gpio: Add default GPIO driver mappings for ACPI)
Cc: # v3.19+
---
arch/arm/mach-tegra/board-paz00.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/board-paz00.c
b/arch/arm/mach-tegra/board-paz00.c
index fbe74c6..67024f3 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -39,8 +39,8 @@ static struct platform_device wifi_rfkill_device = {
static struct gpiod_lookup_table wifi_gpio_lookup = {
.dev_id = "rfkill_gpio",
.table = {
- GPIO_LOOKUP_IDX("tegra-gpio", 25, NULL, 0, 0),
- GPIO_LOOKUP_IDX("tegra-gpio", 85, NULL, 1, 0),
+ GPIO_LOOKUP_IDX("tegra-gpio", 25, "reset", 0, 0),
+ GPIO_LOOKUP_IDX("tegra-gpio", 85, "shutdown", 1, 0),
{ },
},
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] un-improve strrchr()
Joe Perches wrote:
> On Sun, 2015-06-28 at 19:44 +0300, Alexey Dobriyan wrote:
> > Commit 8da53d4595a53fb9a3380dd4d1c9bc24c7c9aab8
> > ("lib/string.c: improve strrchr()") changed strrchr() implementation
> > from "rewind to the end and search backwards" to "search forward"
> > optimizing for characher not found case. However, common case is exactly
> > the opposite: string is absolute pathname, c is '/' always to be found.
> >
> > Previous code did 1 branch per character + 1 branch for every character
> > in the last path component. Current code does 2 branches per characher
> > regardless.
>
> Are you comparing total cycles of all of the branches
> in the called functions too?
I'm comparing branches to branches. For strrchr() you don't need 2xN branches
even in theory. strlen() might even be optimized (gcc does have the impudence
to inline it's own CMPB version though).
> As written the current version removes the strlen call.
It does.
> > --- a/lib/string.c
> > +++ b/lib/string.c
> > @@ -313,12 +313,13 @@ EXPORT_SYMBOL(strchrnul);
> > */
> > char *strrchr(const char *s, int c)
> > {
> > - const char *last = NULL;
> > + const char *p = s + strlen(s);
> > +
> > do {
> > - if (*s == (char)c)
> > - last = s;
> > - } while (*s++);
> > - return (char *)last;
> > + if (*p == (char)c)
> > + return (char *)p;
> > + } while (--p >= s);
> > + return NULL;
> > }
> > EXPORT_SYMBOL(strrchr);
> > #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/
[PATCH RFC v2 0/3] UART slave device support
Post RFC V2 (test on 4.1) as it seems that V1 wasn't sent properly.
Hi all,
this patch series is our proposal to add hooks so that the driver for a device
connected to an UART can
monitor modem control lines and data activity of the connected chip.
It contains an example for such a device driver which needs such sophisticated
power control: wi2wi,w2sg0004
A remote device connected to a RS232 interface is usually power controlled by
the DTR line.
The DTR line is managed automatically by the UART driver for open() and close()
syscalls
and on demand by tcsetattr().
With embedded devices, the serial peripheral might be directly and always
connected to the UART
and there might be no physical DTR line involved. Power control (on/off) has to
be done by some
chip specific device driver (which we call "UART slave") through some
mechanisms (I2C, GPIOs etc.)
not related to the serial interface. Some devices do not tell their power state
except by sending
or not sending data to the UART. In such a case the device driver must be able
to monitor data
activity. The role of the device driver is to encapsulate such power control in
a single place.
This patch series allows to support such UART slave drivers by providing:
* a mechanism that a slave driver can identify the UART instance it is
connected to
* a mechanism that UART slave drivers can register to be notified
* notfications for DTR (and other modem control) state changes
* notifications that the device has sent some data to the UART
A slave device tree entry simply adds a phandle reference to the UART it is
connected to, e.g.
gps {
compatible = "wi2wi,w2sg0004";
uart = <&uart1>;
};
The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart
driver.
devm_serial_get_uart_by_phandle() follows the concept of
devm_usb_get_phy_by_phandle().
A slave device driver registers itself with serial_register_slave() to receive
notifications.
Notification handlers can be registered by serial_register_mctrl_notification()
and
serial_register_rx_notification(). If an UART has a NULL slave or a NULL
handler registered,
no notifications are sent.
RX notification handlers can define a ktermios setup and modify or decide to
throw away the
character that is passed upwards.
This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want
to add an optional
GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself
as a "virtual
GPIO". The idea of a "virtual GPIO" is not compatible with the concept that DT
must
describe hardware (and not virtual hardware). So in this new solution DT only
describes that
the w2sg0004 is connected to some UART and how the power state signalling works
is left
to the driver implementations.
The rx data notification also removes the concept of having two different
pinmux states
and make the w2sg0004 driver intercept rx activities by switching the rx line
to a GPIO
interrupt. This was very OMAP3 specific. The new solution is generic and might
even be
extensible that the chip driver could filter or consume the rx data before it
is passed
to the tty layer.
This patch works on linux-next as intended except one major weakness: we have
to call
uart_change_speed() each time we open the tty. This is the opposite of what we
would like
to have: that the slave initializes the uart speed through some termios and the
tty level just uses
this setting. We have not yet completely understood how to make this work and
are happy
about help in this area.
And of course we would like to see general comments about the whole
implementation
approach.
H. Nikolaus Schaller (3):
tty: serial core: provide method to search uart by phandle
tty: serial_core: Add hooks for uart slave drivers
misc: Add w2g0004 gps receiver driver
.../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 18 +
Documentation/serial/slaves.txt| 36 ++
drivers/misc/Kconfig | 18 +
drivers/misc/Makefile | 1 +
drivers/misc/w2sg0004.c| 436 +
drivers/tty/serial/serial_core.c | 205 +-
include/linux/serial_core.h| 21 +-
include/linux/w2sg0004.h | 28 ++
8 files changed, 757 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
create mode 100644 Documentation/serial/slaves.txt
create mode 100644 drivers/misc/w2sg0004.c
create mode 100644 include/linux/w2sg0004.h
--
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 RFC v2 1/3] tty: serial core: provide method to search uart by phandle
From: "H. Nikolaus Schaller"
1. add registered uart_ports to a search list
2. provide a function to search an uart_port by phandle. This copies the
mechanism how devm_usb_get_phy_by_phandle() works
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: Marek Belisko
---
Documentation/serial/slaves.txt | 36 ++
drivers/tty/serial/serial_core.c | 103 +++
include/linux/serial_core.h | 10
3 files changed, 149 insertions(+)
create mode 100644 Documentation/serial/slaves.txt
diff --git a/Documentation/serial/slaves.txt b/Documentation/serial/slaves.txt
new file mode 100644
index 000..6f8d44d
--- /dev/null
+++ b/Documentation/serial/slaves.txt
@@ -0,0 +1,36 @@
+UART slave device support
+
+A remote device connected to a RS232 interface is usually power controlled by
the DTR line.
+The DTR line is managed automatically by the UART driver for open() and
close() syscalls
+and on demand by tcsetattr().
+
+With embedded devices, the serial peripheral might be directly and always
connected to the UART
+and there might be no physical DTR line involved. Power control (on/off) has
to be done by some
+chip specific device driver (which we call "UART slave") through some
mechanisms (I2C, GPIOs etc.)
+not related to the serial interface. Some devices do not explicitly tell their
power state except
+by sending or not sending data to the UART. In such a case the device driver
must be able to monitor
+data activity. The role of the device driver is to encapsulate such power
control in a single place.
+
+This patch series allows to support such drivers by providing:
+* a mechanism that a slave driver can identify the UART instance it is
connected to
+* a mechanism that UART slave drivers can register to be notified
+* notfications for DTR (and other modem control) state changes
+* notifications that the UART has received some data from the UART
+
+A slave device simply adds a phandle reference to the UART it is connected to,
e.g.
+
+ gps {
+ compatible = "wi2wi,w2sg0004";
+ uart = <&uart1>;
+ };
+
+The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart
driver.
+This API follows the concept of devm_usb_get_phy_by_phandle().
+
+A slave device driver registers itself with serial_register_slave() to receive
notifications.
+Notification handler callbacks can be registered by
serial_register_mctrl_notification() and
+serial_register_rx_notification(). If an UART has registered a NULL slave or a
NULL handler,
+no notifications are sent.
+
+RX notification handlers can define a ktermios during setup and the handler
function can modify
+or decide to throw away each character that is passed upwards.
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index eec067d..ad61441 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -38,6 +38,33 @@
#include
#include
+static LIST_HEAD(uart_list);
+static DEFINE_SPINLOCK(uart_lock);
+
+/* same concept as __of_usb_find_phy */
+static struct uart_port *__of_serial_find_uart(struct device_node *node)
+{
+ struct uart_port *uart;
+
+ if (!of_device_is_available(node))
+ return ERR_PTR(-ENODEV);
+
+ list_for_each_entry(uart, &uart_list, head) {
+ if (node != uart->dev->of_node)
+ continue;
+
+ return uart;
+ }
+
+ return ERR_PTR(-EPROBE_DEFER);
+}
+
+static void devm_serial_uart_release(struct device *dev, void *res)
+{
+ struct uart_port *uart = *(struct uart_port **)res;
+ /* FIXME: serial_put_uart(uart); */
+}
+
/*
* This is used to lock changes in serial line configuration.
*/
@@ -64,6 +91,78 @@ static int uart_dcd_enabled(struct uart_port *uport)
return !!(uport->status & UPSTAT_DCD_ENABLE);
}
+/**
+ * devm_serial_get_uart_by_phandle - find the uart by phandle
+ * @dev - device that requests this uart
+ * @phandle - name of the property holding the uart phandle value
+ * @index - the index of the uart
+ *
+ * Returns the uart_port associated with the given phandle value,
+ * after getting a refcount to it, -ENODEV if there is no such uart or
+ * -EPROBE_DEFER if there is a phandle to the uart, but the device is
+ * not yet loaded. While at that, it also associates the device with
+ * the uart using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ *
+ * For use by tty host and peripheral drivers.
+ */
+
+/* same concept as devm_usb_get_phy_by_phandle() */
+
+struct uart_port *devm_serial_get_uart_by_phandle(struct device *dev,
+ const char *phandle, u8 index)
+{
+ struct uart_port *uart = ERR_PTR(-ENOMEM), **ptr;
+ unsigned long flags;
+ struct device_node *node;
+
+ if (!dev->of_node) {
+ dev_err(dev, "device does not have a device node entry\
[PATCH RFC v2 2/3] tty: serial_core: Add hooks for uart slave drivers
From: "H. Nikolaus Schaller"
1. allow drivers to get notified in mctrl changes
2. allow drivers to get notified on rx data (indicating to the driver that
the connected chip is active)
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: Marek Belisko
---
drivers/tty/serial/serial_core.c | 102 +--
include/linux/serial_core.h | 11 -
2 files changed, 107 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index ad61441..c8910c4 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -163,6 +163,84 @@ err0:
}
EXPORT_SYMBOL_GPL(devm_serial_get_uart_by_phandle);
+void uart_register_slave(struct uart_port *uport, void *slave)
+{
+ if (!slave) {
+ uart_register_mctrl_notification(uport, NULL);
+ uart_register_rx_notification(uport, NULL, NULL);
+ }
+ uport->slave = slave;
+}
+
+void uart_register_mctrl_notification(struct uart_port *uport, int
(*function)(void *slave, int state))
+{
+ uport->mctrl_notification = function;
+}
+
+static int uart_port_startup(struct tty_struct *tty, struct uart_state *state,
+ int init_hw);
+
+static void uart_port_shutdown(struct tty_port *port);
+
+void uart_register_rx_notification(struct uart_port *uport, int
(*function)(void *slave, unsigned int *c), struct ktermios *termios)
+{
+ struct uart_state *state = uport->state;
+ struct tty_port *tty_port = &state->port;
+
+ if (!uport->slave)
+ return; /* slave must be registered first */
+
+ uport->rx_notification = function;
+
+ if (tty_port->count == 0) {
+ if (function) {
+ int retval = 0;
+
+ uart_change_pm(state, UART_PM_STATE_ON);
+ retval = uport->ops->startup(uport);
+ if (retval == 0 && termios) {
+ int hw_stopped;
+ /*
+* Initialise the hardware port settings.
+*/
+ uport->ops->set_termios(uport, termios, NULL);
+
+ /*
+* Set modem status enables based on termios
cflag
+*/
+ spin_lock_irq(&uport->lock);
+ if (termios->c_cflag & CRTSCTS)
+ uport->status |= UPSTAT_CTS_ENABLE;
+ else
+ uport->status &= ~UPSTAT_CTS_ENABLE;
+
+ if (termios->c_cflag & CLOCAL)
+ uport->status &= ~UPSTAT_DCD_ENABLE;
+ else
+ uport->status |= UPSTAT_DCD_ENABLE;
+
+ /* reset sw-assisted CTS flow control based on
(possibly) new mode */
+ hw_stopped = uport->hw_stopped;
+ uport->hw_stopped = uart_softcts_mode(uport) &&
+ !(uport->ops->get_mctrl(uport) &
TIOCM_CTS);
+ if (uport->hw_stopped) {
+ if (!hw_stopped)
+ uport->ops->stop_tx(uport);
+ } else {
+ if (hw_stopped)
+ uport->ops->start_tx(uport);
+ }
+ spin_unlock_irq(&uport->lock);
+ }
+ } else
+ uart_port_shutdown(tty_port);
+ }
+}
+
+EXPORT_SYMBOL_GPL(uart_register_slave);
+EXPORT_SYMBOL_GPL(uart_register_mctrl_notification);
+EXPORT_SYMBOL_GPL(uart_register_rx_notification);
+
/*
* This routine is used by the interrupt handler to schedule processing in
* the software interrupt portion of the driver.
@@ -220,6 +298,10 @@ uart_update_mctrl(struct uart_port *port, unsigned int
set, unsigned int clear)
port->mctrl = (old & ~clear) | set;
if (old != port->mctrl)
port->ops->set_mctrl(port, port->mctrl);
+
+ if (port->mctrl_notification)
+ (*port->mctrl_notification)(port->slave, port->mctrl);
+
spin_unlock_irqrestore(&port->lock, flags);
}
@@ -259,7 +341,8 @@ static int uart_port_startup(struct tty_struct *tty, struct
uart_state *state,
uart_circ_clear(&state->xmit);
}
- retval = uport->ops->startup(uport);
+ if (!state->uart_port->rx_notification)
+ retval = uport->ops->startup(uport);
if (retval == 0) {
if (uart_console(uport) && uport->cons->cflag) {
tty->termio
[PATCH RFC v2 3/3] misc: Add w2g0004 gps receiver driver
From: "H. Nikolaus Schaller"
Add driver for Wi2Wi w2g004 GPS module connected through uart. Use uart
slave + notification hooks to glue with tty.
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: Marek Belisko
---
.../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 18 +
drivers/misc/Kconfig | 18 +
drivers/misc/Makefile | 1 +
drivers/misc/w2sg0004.c| 436 +
include/linux/w2sg0004.h | 28 ++
5 files changed, 501 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
create mode 100644 drivers/misc/w2sg0004.c
create mode 100644 include/linux/w2sg0004.h
diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
new file mode 100644
index 000..ef0d6d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
@@ -0,0 +1,18 @@
+Wi2Wi GPS module connected through UART
+
+Required properties:
+- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
+- on-off-gpio: the GPIO that controls the module's on-off toggle input
+- uart: the uart we are connected to (provides DTR for power control)
+
+Optional properties:
+- lna-suppy: an (optional) LNA regulator that is enabled together with the GPS
receiver
+
+example:
+
+gps_receiver: w2sg0004 {
+compatible = "wi2wi,w2sg0004";
+lna-supply = <&vsim>; /* LNA regulator */
+on-off-gpio = <&gpio5 17 0>; /* GPIO_145: trigger for
turning on/off w2sg0004 */
+uart = <&uart1>; /* we are a slave of uart1 */
+}
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 42c3852..952add4 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -527,4 +527,22 @@ source "drivers/misc/mic/Kconfig"
source "drivers/misc/genwqe/Kconfig"
source "drivers/misc/echo/Kconfig"
source "drivers/misc/cxl/Kconfig"
+
+menu "GTA04 misc hardware support"
+
+config W2SG0004
+ tristate "W2SG0004 on/off control"
+ depends on GPIOLIB
+ help
+ Enable on/off control of W2SG0004 GPS using a tty slave to
+ to allow powering up if the /dev/tty$n is opened.
+ It also provides a rfkill gps node to control the LNA power.
+
+config W2SG0004_DEBUG
+ bool "W2SG0004 on/off debugging"
+ depends on W2SG0004
+ help
+ Enable driver debugging mode of W2SG0004 GPS.
+
+endmenu
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d056fb7..3bc67c7 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,5 +53,6 @@ obj-$(CONFIG_SRAM)+= sram.o
obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_W2SG0004) += w2sg0004.o
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
new file mode 100644
index 000..c5f0f7b
--- /dev/null
+++ b/drivers/misc/w2sg0004.c
@@ -0,0 +1,436 @@
+/*
+ * w2sg0004.c
+ * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
+ *
+ * This receiver has an ON/OFF pin which must be toggled to
+ * turn the device 'on' of 'off'. A high->low->high toggle
+ * will switch the device on if it is off, and off if it is on.
+ *
+ * To enable receiving on/off requests we register with the
+ * UART power management notifications.
+ *
+ * It is not possible to directly detect the state of the device.
+ * However when it is on it will send characters on a UART line
+ * regularly.
+ *
+ * To detect that the power state is out of sync (e.g. if GPS
+ * was enabled before a reboot), we register for UART data received
+ * notifications.
+ *
+ * In addition we register as a rfkill client so that we can
+ * control the LNA power.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_W2SG0004_DEBUG
+#undef pr_debug
+#define pr_debug printk
+#endif
+
+/*
+ * There seems to be restrictions on how quickly we can toggle the
+ * on/off line. data sheets says "two rtc ticks", whatever that means.
+ * If we do it too soon it doesn't work.
+ * So we have a state machine which uses the common work queue to ensure
+ * clean transitions.
+ * When a change is requested we record that request and only act on it
+ * once the previous change has completed.
+ * A change involves a 10ms low pulse, and a 990ms raised level, so only
+ * one change per second.
+ */
+
+enum w2sg_state {
+ W2SG_IDLE, /* is not changing state */
+ W2SG_PULSE, /* activate on/off impulse */
+ W2SG_NOPULSE/* deactivate on/off impulse */
+};
+
+struct w2sg_data {
+ struct rfkill *rf_kill;
+ st
Re: [PATCH] hpfs: add fstrim support
On Sun, Jun 28, 2015 at 6:16 AM, Mikulas Patocka wrote:
> This patch adds support for fstrim to the HPFS filesystem.
...
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = hpfs_compat_ioctl,
> +#endif
...
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = hpfs_compat_ioctl,
> +#endif
...
> +#ifdef CONFIG_COMPAT
> +long hpfs_compat_ioctl(struct file *file, unsigned cmd, unsigned long arg)
> +{
> + return hpfs_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
> +}
> +#endif
Hmm. You've clearly copied this pattern from other filesystems, and so
I can't really blame you, but this thing annoys me a lot.
Why isn't FITRIM just marked as a COMPATIBLE_IOCTL(), at which point
the generic ioctl layer will do exactly the above translation for us?
Am I missing something?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3] arm DMA: Fix allocation from CMA for coherent DMA
On Fri, Jun 26, 2015 at 6:25 PM, Catalin Marinas
wrote:
> On Thu, Jun 18, 2015 at 11:44:22PM +0200, Lorenzo Nava wrote:
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index 7e7583d..8e7f402 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -645,15 +645,29 @@ static void *__dma_alloc(struct device *dev, size_t
>> size, dma_addr_t *handle,
>> size = PAGE_ALIGN(size);
>> want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs);
>>
>> - if (is_coherent || nommu())
>> + if (nommu()) {
>> addr = __alloc_simple_buffer(dev, size, gfp, &page);
>> - else if (!(gfp & __GFP_WAIT))
>> + goto dma_alloc_done;
>> + }
>> +
>> + if (dev_get_cma_area(dev) && (gfp & __GFP_WAIT)) {
>> + addr = __alloc_from_contiguous(dev, size, prot, &page,
>> +caller, want_vaddr);
>> + goto dma_alloc_done;
>> + }
>> +
>> + if (is_coherent) {
>> + addr = __alloc_simple_buffer(dev, size, gfp, &page);
>> + goto dma_alloc_done;
>> + }
>> +
>> + if (!(gfp & __GFP_WAIT))
>> addr = __alloc_from_pool(size, &page);
>> - else if (!dev_get_cma_area(dev))
>> - addr = __alloc_remap_buffer(dev, size, gfp, prot, &page,
>> caller, want_vaddr);
>> else
>> - addr = __alloc_from_contiguous(dev, size, prot, &page, caller,
>> want_vaddr);
>> + addr = __alloc_remap_buffer(dev, size, gfp, prot, &page,
>> + caller, want_vaddr);
>>
>> +dma_alloc_done:
>> if (page)
>> *handle = pfn_to_dma(dev, page_to_pfn(page));
>
> The logic here looks alright but I would have preferred the original
> more concise "if ... else if" constructs than the gotos (just personal
> preference).
>
Ok, I can switch back to "if..else": I thought it was becoming too
difficult to read, but in the end the code looks good also with the
original style.
>> @@ -680,9 +694,14 @@ void *arm_dma_alloc(struct device *dev, size_t size,
>> dma_addr_t *handle,
>> static void *arm_coherent_dma_alloc(struct device *dev, size_t size,
>> dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs)
>> {
>> - pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL);
>> + pgprot_t prot;
>> void *memory;
>>
>> + if (attrs == NULL)
>> + prot = PAGE_KERNEL;
>> + else
>> + prot = __get_dma_pgprot(attrs, PAGE_KERNEL);
>> +
>> if (dma_alloc_from_coherent(dev, size, handle, &memory))
>> return memory;
>
> I still think this is the wrong way to fix. It doesn't address the
> coherent dma mmap operation. I already replied on the previous version
> that we should rather have an extra argument "coherent" to
> __get_dma_pgprot().
>
I avoided touching the __get_dma_pgprot() function because it affects
a lot of different functions.
If you think that the implementation you suggested in previous reply
was ok and doesn't introduce problems on the other functions using the
__get_dma_pgprot(), for me it's of course ok as well. Do you see any
code that maybe need a double check: I'm thinking, for example, at the
function arm_iommu_alloc_attrs() and arm_iommu_mmap_attrs()? I agree
with you that the extra argument in the __get_dma_pgprot() function is
definitely the best solution, but I have to be sure that this doesn't
affect any other functions with unexpected behaviour.
For the dma mmap there is still the patch "[PATCH v3]
arm/mm/dma-mapping.c: Add arm_coherent_dma_mmap" which corrects the
behaviour of mapped attributes and makes this version of patch ok.
>> @@ -735,12 +754,12 @@ static void __arm_dma_free(struct device *dev, size_t
>> size, void *cpu_addr,
>>
>> size = PAGE_ALIGN(size);
>>
>> - if (is_coherent || nommu()) {
>> + if (nommu()) {
>> __dma_free_buffer(page, size);
>> } else if (__free_from_pool(cpu_addr, size)) {
>> return;
>
> You have an unnecessary __free_from_pool() call here in the is_coherent
> case.
Ok, I'll fix it. Do you think that short-circuit evaluation can be
used here or it is better to use another solution?
>
>> } else if (!dev_get_cma_area(dev)) {
>> - if (want_vaddr)
>> + if (want_vaddr && !is_coherent)
>> __dma_free_remap(cpu_addr, size);
>> __dma_free_buffer(page, size);
>> } else {
>
> --
> Catalin
Thanks.
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv4 PATCH 00/34] sched: Energy cost model for energy-aware scheduling
Hi,
So I tried to play around a little bit with this patchset. I did a
checkout from:
git://linux-arm.org/linux-power.git energy_model_rfc_v4
and then, when I tried to enable the ENERGY_AWARE from sysfs inside
qemu (x86_64) and I got this:
[69452.750245] BUG: unable to handle kernel paging request at 88009d3fb958
[69452.750245] IP: [] try_to_wake_up+0x125/0x310
[69452.750245] PGD 2155067 PUD 0
[69452.750245] Oops: [#1] SMP
[69452.750245] Modules linked in:
[69452.750245] CPU: 0 PID: 1007 Comm: sh Not tainted 4.1.0-rc2+ #8
[69452.750245] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[69452.750245] task: 88007c9e5aa0 ti: 88007be0c000 task.ti:
88007be0c000
[69452.750245] RIP: 0010:[] []
try_to_wake_up+0x125/0x310
[69452.750245] RSP: :88007fc03d78 EFLAGS: 0092
[69452.750245] RAX: RBX: RCX: 00015a40
[69452.750245] RDX: 0001 RSI: RDI: 88007d005000
[69452.750245] RBP: 88007fc03dc8 R08: 0400 R09:
[69452.750245] R10: R11: R12: 00015a40
[69452.750245] R13: 88007d3fbdaa R14: R15: 88007d3fb660
[69452.750245] FS: 7f8a3c9f0700() GS:88007fc0()
knlGS:
[69452.750245] CS: 0010 DS: ES: CR0: 80050033
[69452.750245] CR2: 88009d3fb958 CR3: 7c32c000 CR4: 06f0
[69452.750245] DR0: DR1: DR2:
[69452.750245] DR3: DR6: DR7:
[69452.750245] Stack:
[69452.750245] 88007fc15aa8 88007c9e5b08 88007fc15aa8
0046
[69452.750245] 88007fc03e08 88007c83fe60 81e3c8a8
81e3c890
[69452.750245] 0003 88007fc03dd8
8107bb8d
[69452.750245] Call Trace:
[69452.750245]
[69452.750245] [] default_wake_function+0xd/0x10
[69452.750245] [] autoremove_wake_function+0x11/0x40
[69452.750245] [] __wake_up_common+0x55/0x90
[69452.750245] [] __wake_up+0x38/0x60
[69452.750245] [] rcu_gp_kthread_wake+0x42/0x50
[69452.750245] [] rcu_process_callbacks+0x2ef/0x5e0
[69452.750245] [] __do_softirq+0x9f/0x280
[69452.750245] [] irq_exit+0xa5/0xb0
[69452.750245] [] smp_apic_timer_interrupt+0x41/0x50
[69452.750245] [] apic_timer_interrupt+0x6b/0x70
[69452.750245]
[69452.750245] Code: 4c 89 ff ff d0 41 83 bf f8 02 00 00 01 41 8b 5f
48 7e 16 49 8b 47 60 89 de 44 89 f1 ba 10 00 00 00 4c 89 ff ff 50 40
89 c3 89 d8 <49> 0f a3 87 00 03 00 00 19 d2 85 d2 0f 84 59 01 00 00 48
8b 15
[69452.750245] RIP [] try_to_wake_up+0x125/0x310
[69452.750245] RSP
[69452.750245] CR2: 88009d3fb958
[69452.750245] ---[ end trace 9b4570a93c243e98 ]---
[69452.750245] Kernel panic - not syncing: Fatal exception in interrupt
[69452.750245] Kernel Offset: disabled
[69452.750245] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
and then I did a disassable from kgdb and I got this:
0x8107b8ae <+286>: callq *0x40(%rax)
0x8107b8b1 <+289>: mov%eax,%ebx
0x8107b8b3 <+291>: mov%ebx,%eax
0x8107b8b5 <+293>: bt %rax,0x300(%r15)
0x8107b8bd <+301>: sbb%edx,%edx
and then I did a objdump and got this:
static inline
int select_task_rq(struct task_struct *p, int cpu, int sd_flags, int wake_flags)
{
if (p->nr_cpus_allowed > 1)
7dcb: 7e 16 jle7de3
cpu = p->sched_class->select_task_rq(p, cpu, sd_flags,
wake_flags);
7dcd: 49 8b 47 60 mov0x60(%r15),%rax
7dd1: 89 de mov%ebx,%esi
7dd3: 44 89 f1mov%r14d,%ecx
7dd6: ba 10 00 00 00 mov$0x10,%edx
7ddb: 4c 89 ffmov%r15,%rdi
7dde: ff 50 40callq *0x40(%rax)
7de1: 89 c3 mov%eax,%ebx
7de3: 89 d8 mov%ebx,%eax
7de5: 49 0f a3 87 00 03 00bt %rax,0x300(%r15)
7dec: 00
7ded: 19 d2 sbb%edx,%edx
* Since this is common to all placement strategies, this lives here.
*
* [ this allows ->select_task() to simply return task_cpu(p) and
* not worry about this generic constraint ]
*/
if (unlikely(!cpumask_test_cpu(cpu, tsk_cpus_allowed(p)) ||
7def: 85 d2 test %edx,%edx
I wasn't able to determine the cause from the line:
7de5: 49 0f a3 87 00 03 00bt %rax,0x300(%r15)
Finally, the question I have is: Could this happen because I'm running
it from qemu?
I hope all this info helps.
Thanks,
Abel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH] tty/vt: Fix the memory leak in visual_init
On 06/10/2015 03:21 AM, Dongxing Zhang wrote: > If vc->vc_uni_pagedir_loc is not NULL, its refcount needs to be > decreased before vc_uni_pagedir_loc is re-assigned. Reviewed-by: Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 v6 1/2] serial_core: add pci uart early console support
On 06/08/2015 02:17 PM, Bin Gao wrote: > On some Intel Atom SoCs, the legacy IO port UART(0x3F8) is not available. > Instead, a 8250 compatible PCI uart can be used as early console. > This patch adds pci support to the 8250 early console driver uart8250. > For example, to enable pci uart(00:21.3) as early console on these > platforms, append the following line to the kernel command line > (assume baud rate is 115200): > earlyprintk=uart8250,pci32,0:24.2,115200n8 Reviewed-by: Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 100491] New: Oops under bitmap_start_sync [md_mod] at boot
On Thu, Jun 25, 2015 at 09:02:45PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=100491 > > Bug ID: 100491 >Summary: Oops under bitmap_start_sync [md_mod] at boot [...] > Reading all physical valumes. This may take a while... > Found volume group "rootvg" using metadata type lvm2 > device-mapper: raid: Device 0 specified for rebuild: Clearing superblock > md/raid1:mdX: active with 1 out of 2 mirrors > mdX: invalid bitmap file superblock: bad magic > md-cluster module not found. > mdX: Could not setup cluster service (256) > BUG: unable to handle kernel NULL pointer dereference at 0100 > IP: [] _raw_spin_lock_irq+0x29/0x70 > PGD 0 > Oops: 0002 [#1] PREEMPT SMP [...] I'm marking this as a regression in bugzilla, since this seems to prevent booting on 4.1.0 at least in certain circumstances (namely those which I have; I wonder if any raid1 recovery works?) while 4.0.6 boots correctly. I bisected this down to one of four commits. Well, assuming that the problem was caused by changes in drivers/md; a fair assumption, I think. The commits are: $ git bisect view --oneline f9209a3 bitmap_create returns bitmap pointer 96ae923 Gather on-going resync information of other nodes 54519c5 Lock bitmap while joining the cluster b97e9257 Use separate bitmaps for each nodes in the cluster The crash happens whether or not CONFIG_MD_CLUSTER is enabled. Here's the versions I tested: git bisect start '--' 'drivers/md' # bad: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 # good: [39a8804455fb23f09157341d3ba7db6d7ae6ee76] Linux 4.0 # bad: [9ffc8f7cb9647b13dfe4d1ad0d5e1427bb8b46d6] md/raid5: don't do chunk aligned read on degraded array. # bad: [6dc69c9c460b0cf05b5b3f323a8b944a2e52e76d] md: recover_bitmaps() can be static # bad: [4b26a08af92c0d9c0bce07612b56ff326112321a] Perform resync for cluster node failure # good: [cf921cc19cf7c1e99f730a2faa02d80817d684a2] Add node recovery callbacks # skip: [96ae923ab659e37dd5fc1e05ecbf654e2f94bcbe] Gather on-going resync information of other nodes # bad: [f9209a323547f054c7439a3bf67c45e64a054bdd] bitmap_create returns bitmap pointer # skip: [54519c5f4b398bcfe599f652b4ef4004d5fa63ff] Lock bitmap while joining the cluster Sami -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] hpfs: add fstrim support
On Sun, Jun 28, 2015 at 12:52:11PM -0700, Linus Torvalds wrote:
> On Sun, Jun 28, 2015 at 6:16 AM, Mikulas Patocka
> wrote:
> > This patch adds support for fstrim to the HPFS filesystem.
> ...
> > +#ifdef CONFIG_COMPAT
> > + .compat_ioctl = hpfs_compat_ioctl,
> > +#endif
> ...
> > +#ifdef CONFIG_COMPAT
> > + .compat_ioctl = hpfs_compat_ioctl,
> > +#endif
> ...
> > +#ifdef CONFIG_COMPAT
> > +long hpfs_compat_ioctl(struct file *file, unsigned cmd, unsigned long arg)
> > +{
> > + return hpfs_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
> > +}
> > +#endif
>
> Hmm. You've clearly copied this pattern from other filesystems, and so
> I can't really blame you, but this thing annoys me a lot.
>
> Why isn't FITRIM just marked as a COMPATIBLE_IOCTL(), at which point
> the generic ioctl layer will do exactly the above translation for us?
>
> Am I missing something?
More to the point, why bother with ->ioctl() at all? Why not make
->fitrim() a super_block method and let do_vfs_ioctl() handle all
marshalling? As in
(int *)fitrim(struct super_block *, struct fstrim_range *);
guaranteed to be called only on a filesystem kept active by caller...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] um: Fix out-of-tree build
Commit 30b11ee9a (um: Remove copy&paste code from init.h) uncovered an issue wrt. out-of-tree builds. For out-of-tree builds, we must not rely on relative paths. Before 30b11ee9a it worked by chance as no host code included generated header files. Signed-off-by: Richard Weinberger --- arch/um/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/um/Makefile b/arch/um/Makefile index 098ab33..e3abe6f 100644 --- a/arch/um/Makefile +++ b/arch/um/Makefile @@ -70,8 +70,8 @@ KBUILD_AFLAGS += $(ARCH_INCLUDE) USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -I%,,$(KBUILD_CFLAGS))) \ $(ARCH_INCLUDE) $(MODE_INCLUDE) $(filter -I%,$(CFLAGS)) \ - -D_FILE_OFFSET_BITS=64 -idirafter include \ - -D__KERNEL__ -D__UM_HOST__ + -D_FILE_OFFSET_BITS=64 -idirafter $(srctree)/include \ + -idirafter $(obj)/include -D__KERNEL__ -D__UM_HOST__ #This will adjust *FLAGS accordingly to the platform. include $(ARCH_DIR)/Makefile-os-$(OS) -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 1/3] tty: serial core: provide method to search uart by phandle
Hi,
Some comments below.
On Sun, Jun 28, 2015 at 09:46:24PM +0200, Marek Belisko wrote:
> From: "H. Nikolaus Schaller"
>
> 1. add registered uart_ports to a search list
> 2. provide a function to search an uart_port by phandle. This copies the
>mechanism how devm_usb_get_phy_by_phandle() works
>
> Signed-off-by: H. Nikolaus Schaller
> Signed-off-by: Marek Belisko
> ---
> Documentation/serial/slaves.txt | 36 ++
> drivers/tty/serial/serial_core.c | 103
> +++
> include/linux/serial_core.h | 10
> 3 files changed, 149 insertions(+)
> create mode 100644 Documentation/serial/slaves.txt
>
> diff --git a/Documentation/serial/slaves.txt b/Documentation/serial/slaves.txt
> new file mode 100644
> index 000..6f8d44d
> --- /dev/null
> +++ b/Documentation/serial/slaves.txt
> @@ -0,0 +1,36 @@
> +UART slave device support
> +
> +A remote device connected to a RS232 interface is usually power controlled
> by the DTR line.
> +The DTR line is managed automatically by the UART driver for open() and
> close() syscalls
> +and on demand by tcsetattr().
> +
> +With embedded devices, the serial peripheral might be directly and always
> connected to the UART
> +and there might be no physical DTR line involved. Power control (on/off) has
> to be done by some
> +chip specific device driver (which we call "UART slave") through some
> mechanisms (I2C, GPIOs etc.)
> +not related to the serial interface. Some devices do not explicitly tell
> their power state except
> +by sending or not sending data to the UART. In such a case the device driver
> must be able to monitor
> +data activity. The role of the device driver is to encapsulate such power
> control in a single place.
> +
> +This patch series allows to support such drivers by providing:
> +* a mechanism that a slave driver can identify the UART instance it is
> connected to
> +* a mechanism that UART slave drivers can register to be notified
> +* notfications for DTR (and other modem control) state changes
> +* notifications that the UART has received some data from the UART
> +
> +A slave device simply adds a phandle reference to the UART it is connected
> to, e.g.
> +
> + gps {
> + compatible = "wi2wi,w2sg0004";
> + uart = <&uart1>;
> + };
> +
> +The slave driver calls devm_serial_get_uart_by_phandle() to identify the
> uart driver.
> +This API follows the concept of devm_usb_get_phy_by_phandle().
> +
> +A slave device driver registers itself with serial_register_slave() to
> receive notifications.
> +Notification handler callbacks can be registered by
> serial_register_mctrl_notification() and
> +serial_register_rx_notification(). If an UART has registered a NULL slave or
> a NULL handler,
> +no notifications are sent.
> +
> +RX notification handlers can define a ktermios during setup and the handler
> function can modify
> +or decide to throw away each character that is passed upwards.
> diff --git a/drivers/tty/serial/serial_core.c
> b/drivers/tty/serial/serial_core.c
> index eec067d..ad61441 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -38,6 +38,33 @@
> #include
> #include
>
> +static LIST_HEAD(uart_list);
> +static DEFINE_SPINLOCK(uart_lock);
> +
> +/* same concept as __of_usb_find_phy */
> +static struct uart_port *__of_serial_find_uart(struct device_node *node)
> +{
> + struct uart_port *uart;
> +
> + if (!of_device_is_available(node))
> + return ERR_PTR(-ENODEV);
> +
> + list_for_each_entry(uart, &uart_list, head) {
> + if (node != uart->dev->of_node)
> + continue;
> +
> + return uart;
We can easily save three lines here :)
> + }
> +
> + return ERR_PTR(-EPROBE_DEFER);
> +}
> +
> +static void devm_serial_uart_release(struct device *dev, void *res)
> +{
> + struct uart_port *uart = *(struct uart_port **)res;
> + /* FIXME: serial_put_uart(uart); */
> +}
Looks unfinished...
> +
> /*
> * This is used to lock changes in serial line configuration.
> */
> @@ -64,6 +91,78 @@ static int uart_dcd_enabled(struct uart_port *uport)
> return !!(uport->status & UPSTAT_DCD_ENABLE);
> }
>
> +/**
> + * devm_serial_get_uart_by_phandle - find the uart by phandle
> + * @dev - device that requests this uart
> + * @phandle - name of the property holding the uart phandle value
> + * @index - the index of the uart
> + *
> + * Returns the uart_port associated with the given phandle value,
> + * after getting a refcount to it, -ENODEV if there is no such uart or
> + * -EPROBE_DEFER if there is a phandle to the uart, but the device is
> + * not yet loaded. While at that, it also associates the device with
> + * the uart using devres. On driver detach, release function is invoked
> + * on the devres data, then, devres data is freed.
Add -ENOMEM and -EINVAL, remove -EPROBE_DEFER?
> + *
> + * For use by tty host
Re: [PATCH] hpfs: add fstrim support
On Sun, Jun 28, 2015 at 1:59 PM, Al Viro wrote: > > More to the point, why bother with ->ioctl() at all? Why not make > ->fitrim() a super_block method and let do_vfs_ioctl() handle all > marshalling? As in > (int *)fitrim(struct super_block *, struct fstrim_range *); > guaranteed to be called only on a filesystem kept active by caller... I'd be ok with that, but that's a bigger issue and I think would be a separate second step from removing the whole compat mess anyway. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] Bluetooth: btusb: Modify entry to support misc devices with BT interface
In the USB device table in btusb driver, the code specify a generic Bluetooth
device by matching Device Descriptor. However, some devices with BT interface
are classified as "Miscellaneous Device" and have different Device Descriptor,
such as Realtek RTL8723AU. Then btusb wouldn't probe them.
To resolve this, specify generic Bluetooth device in the USB device table by
matching Interface Descriptor, to probe all devices with Bluetooth interface
including these "Miscellaneous" ones.
Signed-off-by: Xi Ruoyao
---
The Bluetooth USB driver changed a lot since 4.1 released. However this problem
still exists now, so I think I should resend this patch.
After apply this patch, my RTL8723AU works well. This is the info of the
RTL8723AU
USB device:
T: Bus=03 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=1724 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c01
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index b4cf8d9..950afda 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -63,7 +63,7 @@ static struct usb_driver btusb_driver;
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
- { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ { USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },
/* Generic Bluetooth AMP device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x04), .driver_info = BTUSB_AMP },
--
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/
Re: [PATCH RFC v2 2/3] tty: serial_core: Add hooks for uart slave drivers
Hi,
Some minor comments below.
On Sun, Jun 28, 2015 at 09:46:25PM +0200, Marek Belisko wrote:
> From: "H. Nikolaus Schaller"
>
> 1. allow drivers to get notified in mctrl changes
> 2. allow drivers to get notified on rx data (indicating to the driver that
>the connected chip is active)
>
> Signed-off-by: H. Nikolaus Schaller
> Signed-off-by: Marek Belisko
> ---
> drivers/tty/serial/serial_core.c | 102
> +--
> include/linux/serial_core.h | 11 -
> 2 files changed, 107 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/tty/serial/serial_core.c
> b/drivers/tty/serial/serial_core.c
> index ad61441..c8910c4 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -163,6 +163,84 @@ err0:
> }
> EXPORT_SYMBOL_GPL(devm_serial_get_uart_by_phandle);
>
> +void uart_register_slave(struct uart_port *uport, void *slave)
> +{
> + if (!slave) {
> + uart_register_mctrl_notification(uport, NULL);
> + uart_register_rx_notification(uport, NULL, NULL);
> + }
> + uport->slave = slave;
> +}
> +
> +void uart_register_mctrl_notification(struct uart_port *uport, int
> (*function)(void *slave, int state))
> +{
> + uport->mctrl_notification = function;
> +}
> +
> +static int uart_port_startup(struct tty_struct *tty, struct uart_state
> *state,
> + int init_hw);
> +
> +static void uart_port_shutdown(struct tty_port *port);
> +
> +void uart_register_rx_notification(struct uart_port *uport, int
> (*function)(void *slave, unsigned int *c), struct ktermios *termios)
> +{
> + struct uart_state *state = uport->state;
> + struct tty_port *tty_port = &state->port;
> +
> + if (!uport->slave)
> + return; /* slave must be registered first */
> +
> + uport->rx_notification = function;
> +
> + if (tty_port->count == 0) {
if (tty_port->count)
return;
> + if (function) {
> + int retval = 0;
Useless initialization.
> +
> + uart_change_pm(state, UART_PM_STATE_ON);
> + retval = uport->ops->startup(uport);
> + if (retval == 0 && termios) {
Indentation is evil in this rather simple function :)
> + int hw_stopped;
> + /*
> + * Initialise the hardware port settings.
> + */
> + uport->ops->set_termios(uport, termios, NULL);
> +
> + /*
> + * Set modem status enables based on termios
> cflag
> + */
> + spin_lock_irq(&uport->lock);
> + if (termios->c_cflag & CRTSCTS)
> + uport->status |= UPSTAT_CTS_ENABLE;
> + else
> + uport->status &= ~UPSTAT_CTS_ENABLE;
> +
> + if (termios->c_cflag & CLOCAL)
> + uport->status &= ~UPSTAT_DCD_ENABLE;
> + else
> + uport->status |= UPSTAT_DCD_ENABLE;
> +
> + /* reset sw-assisted CTS flow control based on
> (possibly) new mode */
checkpatch.pl will complain about long line :)
> + hw_stopped = uport->hw_stopped;
> + uport->hw_stopped = uart_softcts_mode(uport) &&
> + !(uport->ops->get_mctrl(uport) &
> TIOCM_CTS);
> + if (uport->hw_stopped) {
> + if (!hw_stopped)
> + uport->ops->stop_tx(uport);
> + } else {
> + if (hw_stopped)
> + uport->ops->start_tx(uport);
> + }
> + spin_unlock_irq(&uport->lock);
> + }
> + } else
Usage of braces is against CodingStyle.
> + uart_port_shutdown(tty_port);
> + }
> +}
> +
> +EXPORT_SYMBOL_GPL(uart_register_slave);
> +EXPORT_SYMBOL_GPL(uart_register_mctrl_notification);
> +EXPORT_SYMBOL_GPL(uart_register_rx_notification);
> +
> /*
> * This routine is used by the interrupt handler to schedule processing in
> * the software interrupt portion of the driver.
> @@ -220,6 +298,10 @@ uart_update_mctrl(struct uart_port *port, unsigned int
> set, unsigned int clear)
> port->mctrl = (old & ~clear) | set;
> if (old != port->mctrl)
> port->ops->set_mctrl(port, port->mctrl);
> +
> + if (port->mctrl_notification)
> + (*port->mctrl_notification)(port->slave, port->mctrl);
> +
> spin_unlock_irqrestore(&port->lock, flags);
Re: LIBCFS_ALLOC
Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have even a tiny sliver of RAM isn't going to work. It's easier to use libcfs_kvzalloc() everywhere, but it's probably the wrong thing. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control
[Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control] On 26/06/2015 (Fri 20:47) Ville Syrjälä wrote: > On Fri, Jun 26, 2015 at 06:31:37PM +0200, Daniel Vetter wrote: > > On Fri, Jun 26, 2015 at 02:32:03PM +0530, Shobhit Kumar wrote: > > > Hi, > > > Next update of the series reviewed at > > > https://lkml.org/lkml/2015/6/22/155 > > > > > > Major changes are few review comments from Varka and Ville being > > > addressed. Also except > > > for intel-gfx patches, all patches reviesion history is moved out of > > > commit message. > > > > > > Hope this series finally finds its mark. > > > > > > Regards > > > Shobhit > > > > > > Shobhit Kumar (7): > > > gpiolib: Add support for removing registered consumer lookup table > > > mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO > > > signal > > > mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC > > > mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM > > > pwm: crc: Add Crystalcove (CRC) PWM driver > > > drm/i915: Use the CRC gpio for panel enable/disable > > > drm/i915: Backlight control using CRC PMIC based PWM driver > > > > I think we have r-b/acks on all the patches now. Ok if I pull this in > > through drm-intel.git for 4.3? Or should I make a topic branch with tag > > and then send out pull requests to everyone? Or will each maintainer merge > > on their own since it's all only coupled at runtime anyway? Any of these > > would suit me. > > I forgot to mention that I had a build failure due to > builtin_platform_driver() when I tried this (just changed it to > module_platform_driver() to get past it). So I'm not sure if this > now depends on some tree which isn't included in -nightly... builtin_platform_register does not yet exist in mainline; as Paul (the other one) said earlier. So you can either open-code what it does for now, or use module_platform_register. If you do the latter, then ensure you (temorarily) also include module.h or you risk additional breakage in the future. Paul. -- > > -- > Ville Syrjälä > Intel OTC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] Bluetooth: btusb: Modify entry to support misc devices with BT interface
On 06/28/2015 04:49 PM, Xi Ruoyao wrote:
In the USB device table in btusb driver, the code specify a generic Bluetooth
device by matching Device Descriptor. However, some devices with BT interface
are classified as "Miscellaneous Device" and have different Device Descriptor,
such as Realtek RTL8723AU. Then btusb wouldn't probe them.
To resolve this, specify generic Bluetooth device in the USB device table by
matching Interface Descriptor, to probe all devices with Bluetooth interface
including these "Miscellaneous" ones.
Signed-off-by: Xi Ruoyao
---
The Bluetooth USB driver changed a lot since 4.1 released. However this problem
still exists now, so I think I should resend this patch.
I have now been able to get this patch tested through the repo at GitHub.com. My
testers concur that this allows the BT part of the RTL8723AU to load.
Acked-by: Larry Finger
Thanks,
Larry
After apply this patch, my RTL8723AU works well. This is the info of the
RTL8723AU
USB device:
T: Bus=03 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=1724 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c01
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index b4cf8d9..950afda 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -63,7 +63,7 @@ static struct usb_driver btusb_driver;
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
- { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ { USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },
/* Generic Bluetooth AMP device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x04), .driver_info = BTUSB_AMP },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
