Hello,
syzbot found the following crash on:
HEAD commit:7c1b097f27bf Add linux-next specific files for 20180912
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=152fcd4940
kernel config: https://syzkaller.appspot.com/x/.config?x=5980033172920ec0
On 13.09.2018 06:01, zhong jiang wrote:
> remove_extent_mapping use the variable "ret" for return value,
> but it is not modified after initialzation. Further, I find that
> any of the callers do not handle the return value, so it is safe
> to drop the unneeded "ret" and make it to be void
Hello,
syzbot found the following crash on:
HEAD commit:7c1b097f27bf Add linux-next specific files for 20180912
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=152fcd4940
kernel config: https://syzkaller.appspot.com/x/.config?x=5980033172920ec0
On 13.09.2018 06:01, zhong jiang wrote:
> remove_extent_mapping use the variable "ret" for return value,
> but it is not modified after initialzation. Further, I find that
> any of the callers do not handle the return value, so it is safe
> to drop the unneeded "ret" and make it to be void
Le 12/09/2018 à 11:49, Sudeep Holla a écrit :
>
>> Yes. Without this change, we hit the lscpu error in the commit message,
>> and get zero output about the system. We don't even get information
>> about the caches which are architecturally specified or how many cpus
>> are present. With this
Le 12/09/2018 à 11:49, Sudeep Holla a écrit :
>
>> Yes. Without this change, we hit the lscpu error in the commit message,
>> and get zero output about the system. We don't even get information
>> about the caches which are architecturally specified or how many cpus
>> are present. With this
Hi Florian,
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the git repository at:
git://github.com/anholt/linux tags/bcm2835-defconfig-next-2018-09-09
for you to fetch changes up to
Hi Florian,
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the git repository at:
git://github.com/anholt/linux tags/bcm2835-dt-64-next-2018-09-09
for you to fetch changes up to
Hi Florian,
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the git repository at:
git://github.com/anholt/linux tags/bcm2835-defconfig-next-2018-09-09
for you to fetch changes up to
Hi Florian,
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the git repository at:
git://github.com/anholt/linux tags/bcm2835-dt-64-next-2018-09-09
for you to fetch changes up to
Hi Florian,
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the git repository at:
git://github.com/anholt/linux tags/bcm2835-dt-next-2018-09-09
for you to fetch changes up to
Hi Florian,
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the git repository at:
git://github.com/anholt/linux tags/bcm2835-dt-next-2018-09-09
for you to fetch changes up to
On Wed, Sep 12, 2018 at 10:09:28PM -0700, Dan Williams wrote:
> The UIO file mask in MAINTAINERS was incorrectly directing UACCESS
> (include/linux/uio.h) patches to Greg.
>
> Tag Al as the UACCESS maintainer as Ingo and others have explicitly
> required his ack before taking architecture patches
On Wed, Sep 12, 2018 at 10:09:28PM -0700, Dan Williams wrote:
> The UIO file mask in MAINTAINERS was incorrectly directing UACCESS
> (include/linux/uio.h) patches to Greg.
>
> Tag Al as the UACCESS maintainer as Ingo and others have explicitly
> required his ack before taking architecture patches
On Wed, Sep 12, 2018 at 04:27:44PM -0700, Cong Wang wrote:
> There is a race condition between ucma_close() and ucma_resolve_ip():
>
> CPU0 CPU1
> ucma_resolve_ip():ucma_close():
>
> ctx = ucma_get_ctx(file, cmd.id);
>
> list_for_each_entry_safe(ctx,
On Wed, Sep 12, 2018 at 04:27:44PM -0700, Cong Wang wrote:
> There is a race condition between ucma_close() and ucma_resolve_ip():
>
> CPU0 CPU1
> ucma_resolve_ip():ucma_close():
>
> ctx = ucma_get_ctx(file, cmd.id);
>
> list_for_each_entry_safe(ctx,
Signed-off-by: Gerd Hoffmann
---
samples/vfio-mdev/mbochs.c | 54 --
1 file changed, 52 insertions(+), 2 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index 2535c3677c..6331871ff5 100644
---
Signed-off-by: Gerd Hoffmann
---
samples/vfio-mdev/mbochs.c | 54 --
1 file changed, 52 insertions(+), 2 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index 2535c3677c..6331871ff5 100644
---
Signed-off-by: Gerd Hoffmann
---
include/uapi/linux/vfio.h | 38 ++
1 file changed, 38 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 1aa7b82e81..38b591e909 100644
--- a/include/uapi/linux/vfio.h
+++
Signed-off-by: Gerd Hoffmann
---
include/uapi/linux/vfio.h | 38 ++
1 file changed, 38 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 1aa7b82e81..38b591e909 100644
--- a/include/uapi/linux/vfio.h
+++
On 09/13/2018, 04:38 AM, chen.l...@zte.com.cn wrote:
> Before wq 's->workqueue' be initialized in function 'max3100_startup',
>
> 'cat /proc/tty/driver/ttyMAX' will cause oops.
>
>
> Oops: Kernel access of bad area, sig: 11 [#1]
>
> ...
>
> NIP [c0049070] __queue_work+0x24/0x268
>
> LR
On 09/13/2018, 04:38 AM, chen.l...@zte.com.cn wrote:
> Before wq 's->workqueue' be initialized in function 'max3100_startup',
>
> 'cat /proc/tty/driver/ttyMAX' will cause oops.
>
>
> Oops: Kernel access of bad area, sig: 11 [#1]
>
> ...
>
> NIP [c0049070] __queue_work+0x24/0x268
>
> LR
Hi all,
News: there will be no linux-next releases on Friday or Monday.
Changes since 20180912:
Dropped trees: xarray, ida (temporarily)
I still disabled building some samples in the vfs tree.
I added a supplied patch to the akpm-current tree.
The akpm tree lost a patch for a bug
Hi all,
News: there will be no linux-next releases on Friday or Monday.
Changes since 20180912:
Dropped trees: xarray, ida (temporarily)
I still disabled building some samples in the vfs tree.
I added a supplied patch to the akpm-current tree.
The akpm tree lost a patch for a bug
The UIO file mask in MAINTAINERS was incorrectly directing UACCESS
(include/linux/uio.h) patches to Greg.
Tag Al as the UACCESS maintainer as Ingo and others have explicitly
required his ack before taking architecture patches that touch
lib/iov_iter.c.
Cc: Al Viro
Reported-by: Greg
The UIO file mask in MAINTAINERS was incorrectly directing UACCESS
(include/linux/uio.h) patches to Greg.
Tag Al as the UACCESS maintainer as Ingo and others have explicitly
required his ack before taking architecture patches that touch
lib/iov_iter.c.
Cc: Al Viro
Reported-by: Greg
Neil Armstrong writes:
> Add missing chosen and memory nodes.
>
> Signed-off-by: Neil Armstrong
Applied to v4.20/dt64 with Martin's ack.
Thanks,
Kevin
Neil Armstrong writes:
> Add missing chosen and memory nodes.
>
> Signed-off-by: Neil Armstrong
Applied to v4.20/dt64 with Martin's ack.
Thanks,
Kevin
Neil Armstrong writes:
> Use the correct compatible for the AXG ethernet mac node.
>
> Signed-off-by: Neil Armstrong
Applied to v4.20/dt64 with Martin's ack,
Thanks,
Kevin
Neil Armstrong writes:
> Use the correct compatible for the AXG ethernet mac node.
>
> Signed-off-by: Neil Armstrong
Applied to v4.20/dt64 with Martin's ack,
Thanks,
Kevin
Jerome Brunet writes:
> This patchset adds pdm support for amlogic AXG SoC.
> It applies on top of the DT clean-up [0] I sent earlier
Applied to v4.20/dt64.
> The related ASoC PDM patches can be found here [1]. While the ASoC patches
> [2] are obviously needed to for the PDM to work, this
Jerome Brunet writes:
> This patchset adds pdm support for amlogic AXG SoC.
> It applies on top of the DT clean-up [0] I sent earlier
Applied to v4.20/dt64.
> The related ASoC PDM patches can be found here [1]. While the ASoC patches
> [2] are obviously needed to for the PDM to work, this
Jerome Brunet writes:
> Compile the necessary drivers as modules, including codecs, for the
> s400 sound card.
>
> Signed-off-by: Jerome Brunet
Applied to v4.20/defconfig.
Thanks,
Kevin
Jerome Brunet writes:
> Compile the necessary drivers as modules, including codecs, for the
> s400 sound card.
>
> Signed-off-by: Jerome Brunet
Applied to v4.20/defconfig.
Thanks,
Kevin
Maxime Jourdan writes:
> Amlogic SoCs have a repository of 256 canvas which they use to
> describe pixel buffers.
>
> They contain metadata like width, height, block mode, endianness [..]
>
> Many IPs within those SoCs like vdec/vpu rely on those canvas to read/write
> pixels.
>
> Reviewed-by:
Maxime Jourdan writes:
> Amlogic SoCs have a repository of 256 canvas which they use to
> describe pixel buffers.
>
> They contain metadata like width, height, block mode, endianness [..]
>
> Many IPs within those SoCs like vdec/vpu rely on those canvas to read/write
> pixels.
>
> Reviewed-by:
Maxime Jourdan writes:
> DMC is a small memory region with various registers,
> including the ones needed for the canvas module.
>
> Reviewed-by: Jerome Brunet
> Signed-off-by: Maxime Jourdan
Applied to v4.20/dt64 with s/ARM64/arm64/ as requested.
Thanks,
Kevin
Maxime Jourdan writes:
> DMC is a small memory region with various registers,
> including the ones needed for the canvas module.
>
> Reviewed-by: Jerome Brunet
> Signed-off-by: Maxime Jourdan
Applied to v4.20/dt64 with s/ARM64/arm64/ as requested.
Thanks,
Kevin
On Wed, Sep 12, 2018 at 8:28 PM Mark Brown wrote:
>
> On Wed, Sep 12, 2018 at 08:19:54PM +0800, Cheng-Yi Chiang wrote:
> > max98927 codec driver will support reset-gpio binding so it can toggle
> > reset line in its probe function.
>
> All GPIO properties are supposed to end -gpios even if there
On Wed, Sep 12, 2018 at 8:28 PM Mark Brown wrote:
>
> On Wed, Sep 12, 2018 at 08:19:54PM +0800, Cheng-Yi Chiang wrote:
> > max98927 codec driver will support reset-gpio binding so it can toggle
> > reset line in its probe function.
>
> All GPIO properties are supposed to end -gpios even if there
On Wed, Sep 12, 2018 at 6:21 PM, Yang, Bin wrote:
> On Wed, 2018-09-12 at 10:44 -0700, Kees Cook wrote:
>> On Tue, Sep 11, 2018 at 8:36 PM, Bin Yang wrote:
>> > persistent_ram_vmap() returns the page start vaddr.
>> > persistent_ram_iomap() supports non-page-aligned mapping.
>>
>> Oh, yes, good
On Wed, Sep 12, 2018 at 6:21 PM, Yang, Bin wrote:
> On Wed, 2018-09-12 at 10:44 -0700, Kees Cook wrote:
>> On Tue, Sep 11, 2018 at 8:36 PM, Bin Yang wrote:
>> > persistent_ram_vmap() returns the page start vaddr.
>> > persistent_ram_iomap() supports non-page-aligned mapping.
>>
>> Oh, yes, good
On Wed, Sep 12, 2018 at 8:59 PM Kevin Hilman wrote:
>
> Neil Armstrong writes:
>
> > The order between "syscon" and "simple-mfd" is important because in these
> > particular cases, the node needs to be first a "simple-mfd" to expose
> > it's sub-nodes, and later on a "syscon" to permit other
On Wed, Sep 12, 2018 at 8:59 PM Kevin Hilman wrote:
>
> Neil Armstrong writes:
>
> > The order between "syscon" and "simple-mfd" is important because in these
> > particular cases, the node needs to be first a "simple-mfd" to expose
> > it's sub-nodes, and later on a "syscon" to permit other
Jerome Brunet writes:
> Sort DT nodes by address when possible, by node node name otherwise.
>
> Signed-off-by: Jerome Brunet
> ---
>
> Hi Kevin,
>
> This patch is same kind of clean-up we already did on gxbb and gxl some
> time ago. In the same fashion, it ends up being and ugly and almost
Jerome Brunet writes:
> Sort DT nodes by address when possible, by node node name otherwise.
>
> Signed-off-by: Jerome Brunet
> ---
>
> Hi Kevin,
>
> This patch is same kind of clean-up we already did on gxbb and gxl some
> time ago. In the same fashion, it ends up being and ugly and almost
Jerome Brunet writes:
> There is actually several different libretech board with the CC suffix
> so the model name is not appropriate here. Update to something more
> specific
>
> Reported-by: Da Xue
> Signed-off-by: Jerome Brunet
Applied to v4.20/dt64
Kevin
Jerome Brunet writes:
> There is actually several different libretech board with the CC suffix
> so the model name is not appropriate here. Update to something more
> specific
>
> Reported-by: Da Xue
> Signed-off-by: Jerome Brunet
Applied to v4.20/dt64
Kevin
On Thu, Jul 26, 2018 at 10:51 PM Neil Armstrong wrote:
>
> Hi,
>
> On 26/07/2018 16:41, Yixun Lan wrote:
> > HI Neil
> >
> > On 07/26/2018 10:13 PM, Neil Armstrong wrote:
> >> The order between "syscon" and "simple-mfd" is important because in these
> >> particular cases, the node needs to be
On Thu, Jul 26, 2018 at 10:51 PM Neil Armstrong wrote:
>
> Hi,
>
> On 26/07/2018 16:41, Yixun Lan wrote:
> > HI Neil
> >
> > On 07/26/2018 10:13 PM, Neil Armstrong wrote:
> >> The order between "syscon" and "simple-mfd" is important because in these
> >> particular cases, the node needs to be
Fix the following compile warning:
drivers/hid/hid-logitech-hidpp.c: In function hi_res_scroll_enable:
drivers/hid/hid-logitech-hidpp.c:2714:54: warning: multiplier may be used
uninitialized in this function [-Wmaybe-uninitialized]
hidpp->vertical_wheel_counter.resolution_multiplier =
Fix the following compile warning:
drivers/hid/hid-logitech-hidpp.c: In function hi_res_scroll_enable:
drivers/hid/hid-logitech-hidpp.c:2714:54: warning: multiplier may be used
uninitialized in this function [-Wmaybe-uninitialized]
hidpp->vertical_wheel_counter.resolution_multiplier =
Hi again,
On Wed, Sep 12, 2018 at 6:19 AM, Miguel Ojeda
wrote:
>
> I will do a bigger one tomorrow or so and see if there are any
> important differences. Regardless of what we do, I will send the
> __naked patches separately as well (requested by Nick on GitHub).
So I did a comparison with a
Hi again,
On Wed, Sep 12, 2018 at 6:19 AM, Miguel Ojeda
wrote:
>
> I will do a bigger one tomorrow or so and see if there are any
> important differences. Regardless of what we do, I will send the
> __naked patches separately as well (requested by Nick on GitHub).
So I did a comparison with a
Christian Hewitt writes:
> Devices using the new V4L2 mem2mem vdec require a larger CMA pool. As
> nearly all GX* devices are video/media focused and will use it, set a
> larger (256MB) default value.
>
> Signed-off-by: Christian Hewitt
Applied to v4.20/dt64,
Kevin
Christian Hewitt writes:
> Devices using the new V4L2 mem2mem vdec require a larger CMA pool. As
> nearly all GX* devices are video/media focused and will use it, set a
> larger (256MB) default value.
>
> Signed-off-by: Christian Hewitt
Applied to v4.20/dt64,
Kevin
Neil Armstrong writes:
> The order between "syscon" and "simple-mfd" is important because in these
> particular cases, the node needs to be first a "simple-mfd" to expose
> it's sub-nodes, and later on a "syscon" to permit other nodes to access
> this register space through the "syscon"
Neil Armstrong writes:
> The order between "syscon" and "simple-mfd" is important because in these
> particular cases, the node needs to be first a "simple-mfd" to expose
> it's sub-nodes, and later on a "syscon" to permit other nodes to access
> this register space through the "syscon"
Neil Armstrong writes:
> The Amlogic Meson SoC Secure Monitor implements a call to retrieve an unique
> SoC ID starting from the GX Family and all new families.
>
> The serial number is simply exposed as a sysfs entry under the firmware
> sysfs directory.
>
> Signed-off-by: Neil Armstrong
Neil Armstrong writes:
> The Amlogic Meson SoC Secure Monitor implements a call to retrieve an unique
> SoC ID starting from the GX Family and all new families.
>
> The serial number is simply exposed as a sysfs entry under the firmware
> sysfs directory.
>
> Signed-off-by: Neil Armstrong
This driver tries to access a block of data on a i2c bus and it tries
to manually make a device command frame and a consecutively read frame,
then uses i2c_transfer() to read data. But this has already been
implemented in i2c_smbus_read_i2c_block_data().
Sorry for not having this device by my
This driver tries to access a block of data on a i2c bus and it tries
to manually make a device command frame and a consecutively read frame,
then uses i2c_transfer() to read data. But this has already been
implemented in i2c_smbus_read_i2c_block_data().
Sorry for not having this device by my
On Wed, Sep 12, 2018 at 10:17 PM Atish Patra wrote:
>
> On 9/12/18 7:38 AM, Anup Patel wrote:
> > Currently, /proc/cpuinfo show logical CPU ID as Hart ID which
> > is in-correct. This patch shows CPU ID and Hart ID separately
> > in /proc/cpuinfo using cpuid_to_hardid_map().
> >
> > With this
On Wed, Sep 12, 2018 at 10:17 PM Atish Patra wrote:
>
> On 9/12/18 7:38 AM, Anup Patel wrote:
> > Currently, /proc/cpuinfo show logical CPU ID as Hart ID which
> > is in-correct. This patch shows CPU ID and Hart ID separately
> > in /proc/cpuinfo using cpuid_to_hardid_map().
> >
> > With this
hid_alloc_report_buf() has to be called with GFP_ATOMIC in
__hid_request(), because there are the following callchains
leading to __hid_request() being an atomic context:
picolcd_send_and_wait (acquire a spinlock)
hid_hw_request
__hid_request
hid_alloc_report_buf(GFP_KERNEL)
hid_alloc_report_buf() has to be called with GFP_ATOMIC in
__hid_request(), because there are the following callchains
leading to __hid_request() being an atomic context:
picolcd_send_and_wait (acquire a spinlock)
hid_hw_request
__hid_request
hid_alloc_report_buf(GFP_KERNEL)
PCI fixes:
- Add Tyrel Datwyler as maintainer for PPC64 RPA hotplug (Tyrel Datwyler)
- Add Gustavo Pimentel as DesignWare PCI maintainer (Joao Pinto)
- Fix a Switchtec Spectre v1 vulnerability (Gustavo A. R. Silva)
- Revert an unnecessary Intel 300 ACS quirk (Mika Westerberg)
- Fix
PCI fixes:
- Add Tyrel Datwyler as maintainer for PPC64 RPA hotplug (Tyrel Datwyler)
- Add Gustavo Pimentel as DesignWare PCI maintainer (Joao Pinto)
- Fix a Switchtec Spectre v1 vulnerability (Gustavo A. R. Silva)
- Revert an unnecessary Intel 300 ACS quirk (Mika Westerberg)
- Fix
Hi Johannes,
On Wed, 12 Sep 2018 21:42:22 -0400 Johannes Weiner wrote:
>
> Thanks for the report.
>
> On Wed, Sep 12, 2018 at 05:45:08PM -0700, Randy Dunlap wrote:
> > Multiple build errors when CONFIG_SMP is not set: (this is on i386 fwiw)
> >
> > in the psi (pressure) patches, I guess:
> >
Hi Russell,
Russell King - ARM Linux writes:
> On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
>> I reproduced the same Oops on Clearfog Base without any taint:
>>
>> [1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> ...
>> [1.855954] Code: e2844004
Hi Johannes,
On Wed, 12 Sep 2018 21:42:22 -0400 Johannes Weiner wrote:
>
> Thanks for the report.
>
> On Wed, Sep 12, 2018 at 05:45:08PM -0700, Randy Dunlap wrote:
> > Multiple build errors when CONFIG_SMP is not set: (this is on i386 fwiw)
> >
> > in the psi (pressure) patches, I guess:
> >
Hi Russell,
Russell King - ARM Linux writes:
> On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
>> I reproduced the same Oops on Clearfog Base without any taint:
>>
>> [1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> ...
>> [1.855954] Code: e2844004
Thanks for the reply :)
On 2018/9/11 1:41, Mark Brown wrote:
On Thu, Aug 30, 2018 at 10:34:20AM +0800, Jia-Ju Bai wrote:
My static tool DSAC reports many sleep-in-atomic-context bugs involving
regmap_lock_mutex(), so I wonder whether this function is possible to be
executed in atomic context.
Thanks for the reply :)
On 2018/9/11 1:41, Mark Brown wrote:
On Thu, Aug 30, 2018 at 10:34:20AM +0800, Jia-Ju Bai wrote:
My static tool DSAC reports many sleep-in-atomic-context bugs involving
regmap_lock_mutex(), so I wonder whether this function is possible to be
executed in atomic context.
From: Dou Liyang
As Kashyap and Sumit reported, in MSI/-x subsystem, the pre/post vectors
may be used to some extra reply queues for performance. the best way to
map the pre/post vectors is map them to the local numa node.
But, current Linux can't do that, because
The pre and post vectors
From: Dou Liyang
As Kashyap and Sumit reported, in MSI/-x subsystem, the pre/post vectors
may be used to some extra reply queues for performance. the best way to
map the pre/post vectors is map them to the local numa node.
But, current Linux can't do that, because
The pre and post vectors
On 13.09.2018 [01:18:14 +0200], Jan H. Schönherr wrote:
> On 09/12/2018 09:34 PM, Jan H. Schönherr wrote:
> > That said, I see a hang, too. It seems to happen, when there is a
> > cpu.scheduled!=0 group that is not a direct child of the root task group.
> > You seem to have
On 13.09.2018 [01:18:14 +0200], Jan H. Schönherr wrote:
> On 09/12/2018 09:34 PM, Jan H. Schönherr wrote:
> > That said, I see a hang, too. It seems to happen, when there is a
> > cpu.scheduled!=0 group that is not a direct child of the root task group.
> > You seem to have
Fix the following compile warning:
rch/x86/kernel/cpu/common.c: In function 'syscall_init':
arch/x86/kernel/cpu/common.c:1534:6: warning: unused variable 'cpu'
[-Wunused-variable]
int cpu = smp_processor_id();
Signed-off-by: zhong jiang
---
arch/x86/kernel/cpu/common.c | 5 ++---
1 file
Fix the following compile warning:
rch/x86/kernel/cpu/common.c: In function 'syscall_init':
arch/x86/kernel/cpu/common.c:1534:6: warning: unused variable 'cpu'
[-Wunused-variable]
int cpu = smp_processor_id();
Signed-off-by: zhong jiang
---
arch/x86/kernel/cpu/common.c | 5 ++---
1 file
From: Al Viro
Signed-off-by: Al Viro
---
drivers/tty/ipwireless/tty.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/tty/ipwireless/tty.c b/drivers/tty/ipwireless/tty.c
index 1ef751c27ac6..fad3401e604d 100644
---
From: Al Viro
Signed-off-by: Al Viro
---
drivers/tty/ipwireless/tty.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/tty/ipwireless/tty.c b/drivers/tty/ipwireless/tty.c
index 1ef751c27ac6..fad3401e604d 100644
---
From: Al Viro
Signed-off-by: Al Viro
---
arch/ia64/hp/sim/simserial.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/hp/sim/simserial.c b/arch/ia64/hp/sim/simserial.c
index 663388a73d4e..de5e69162ad5 100644
--- a/arch/ia64/hp/sim/simserial.c
From: Al Viro
These ioctls never reach driver's ->ioctl() - tty_ioctl() handles
them on its own. ->tiocm[gs]et() is what actually gets called,
and mos7720 provides those, with results equivalent to what the
unreachable code would be doing when called.
Signed-off-by: Al Viro
---
From: Al Viro
Signed-off-by: Al Viro
---
drivers/tty/cyclades.c | 77 --
1 file changed, 37 insertions(+), 40 deletions(-)
diff --git a/drivers/tty/cyclades.c b/drivers/tty/cyclades.c
index 6d3c58051ce3..4562c8060d09 100644
---
From: Al Viro
Signed-off-by: Al Viro
---
arch/ia64/hp/sim/simserial.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/hp/sim/simserial.c b/arch/ia64/hp/sim/simserial.c
index 663388a73d4e..de5e69162ad5 100644
--- a/arch/ia64/hp/sim/simserial.c
From: Al Viro
These ioctls never reach driver's ->ioctl() - tty_ioctl() handles
them on its own. ->tiocm[gs]et() is what actually gets called,
and mos7720 provides those, with results equivalent to what the
unreachable code would be doing when called.
Signed-off-by: Al Viro
---
From: Al Viro
Signed-off-by: Al Viro
---
drivers/tty/cyclades.c | 77 --
1 file changed, 37 insertions(+), 40 deletions(-)
diff --git a/drivers/tty/cyclades.c b/drivers/tty/cyclades.c
index 6d3c58051ce3..4562c8060d09 100644
---
From: Al Viro
Signed-off-by: Al Viro
---
fs/compat_ioctl.c | 4
1 file changed, 4 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index a9b00942e87d..53bc3659dcef 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -749,12 +749,8 @@ COMPATIBLE_IOCTL(TIOCOUTQ)
From: Al Viro
Signed-off-by: Al Viro
---
fs/compat_ioctl.c | 4
1 file changed, 4 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index a9b00942e87d..53bc3659dcef 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -749,12 +749,8 @@ COMPATIBLE_IOCTL(TIOCOUTQ)
From: Al Viro
ioctls that are
* callable only via tty_ioctl()
* not driver-specific
* not demand data structure conversions
* either always need passing arg as is or always demand compat_ptr()
get intercepted in tty_compat_ioctl() from the very beginning and
From: Al Viro
Signed-off-by: Al Viro
---
drivers/tty/amiserial.c | 83 ++---
1 file changed, 38 insertions(+), 45 deletions(-)
diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
index 34dead614149..17fc8bb6c6b8 100644
---
From: Al Viro
Signed-off-by: Al Viro
---
drivers/staging/fwserial/fwserial.c | 66 -
1 file changed, 28 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwserial.c
index fa0dd425b454..173f451b86b7
From: Al Viro
ioctls that are
* callable only via tty_ioctl()
* not driver-specific
* not demand data structure conversions
* either always need passing arg as is or always demand compat_ptr()
get intercepted in tty_compat_ioctl() from the very beginning and
From: Al Viro
Signed-off-by: Al Viro
---
drivers/tty/amiserial.c | 83 ++---
1 file changed, 38 insertions(+), 45 deletions(-)
diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
index 34dead614149..17fc8bb6c6b8 100644
---
From: Al Viro
Signed-off-by: Al Viro
---
drivers/staging/fwserial/fwserial.c | 66 -
1 file changed, 28 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwserial.c
index fa0dd425b454..173f451b86b7
From: Al Viro
That code had been live for 11 weeks back in 1992, but it had been 26 years
since sys_ioctl() began handling FIONBIO on its own. Time to to bury the body,
already...
Signed-off-by: Al Viro
---
drivers/tty/tty_io.c | 30 --
1 file changed, 30
From: Al Viro
Signed-off-by: Al Viro
---
drivers/staging/greybus/uart.c | 47 --
1 file changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
index 8a006323c3c1..3313cb0b60af 100644
---
From: Al Viro
Signed-off-by: Al Viro
---
drivers/usb/serial/io_ti.c | 47 ++
1 file changed, 14 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index 6d1d6efa3055..c327d4cf7928 100644
---
From: Al Viro
Signed-off-by: Al Viro
---
drivers/tty/isicom.c | 72 ++--
1 file changed, 25 insertions(+), 47 deletions(-)
diff --git a/drivers/tty/isicom.c b/drivers/tty/isicom.c
index 8d96e86966f1..e04a43e89f6b 100644
---
1 - 100 of 1468 matches
Mail list logo
