aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/call-graph-from-sql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2018-10-13remove fallback to drivers for TIOCGICOUNTAl Viro1-5/+1
none of them handles it anyway. Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13dgnc: break-related ioctls won't reach ->ioctl()Al Viro1-75/+0
kill the dead code, especially since ->break_ctl() will do the right thing anyway. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13kill the rest of tty COMPAT_IOCTL() entriesAl Viro1-13/+0
TIOCLINUX is handled by ->compat_ioctl() in the only place that has native ->ioctl() recognizing it, TIOC{START,STOP} are simply useless these days - unrecognized compat ioctl won't spew into syslog anymore. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13dgnc: TIOCM... won't reach ->ioctl()Al Viro1-114/+0
bury the dead code (and ->tiocmget()/->tiocmset() are there, so I really wonder why have they kept the stuff that became unreachable with the introduction of those...) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13isdn_tty: TCSBRK{,P} won't reach ->ioctl()Al Viro1-19/+0
kill the long-dead code - it's been unreachable since 2008. Redundant, as well - generic will do exact same thing, since ->break_ctl is NULL here... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13kill capinc_tty_ioctl()Al Viro1-7/+0
NULL ->ioctl() in tty_operations is treated as "returns -ENOIOCTLCMD"... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()Al Viro2-67/+81
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13synclink: reduce pointless checks in ->ioctl()Al Viro4-8/+4
it's never getting called with TIOC[SG]SERIAL anymore (nor has it ever supported those, while we are at it) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13complete ->[sg]et_serial() switchoverAl Viro2-12/+6
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13usb_wwan: switch to ->[sg]et_serial()Al Viro3-49/+23
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13whiteheat: switch to ->get_serial()Al Viro1-27/+15
... and fix the return value - on success it used to have ioctl(2) fill the user-supplied struct serial_struct and return -ENOTTY. Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13ti_usb_3410_5052: switch to ->[sg]et_serial()Al Viro1-50/+24
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13ssu100: switch to ->get_serial()Al Viro1-31/+11
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13quatech2: switch to ->get_serial()Al Viro1-31/+11
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13pl2303: switch to ->get_serial()Al Viro1-21/+8
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13opticon: switch to ->get_serial()Al Viro1-31/+12
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13mos7840: switch to ->get_serial()Al Viro1-26/+13
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13mos7720: switch to ->get_serial()Al Viro1-21/+13
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13io_ti: switch to ->get_serial()Al Viro1-33/+14
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13io_edgeport: switch to ->get_serial()Al Viro1-21/+16
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13fdti_sio: switch to ->[sg]et_serial()Al Viro1-27/+21
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13f81534: switch to ->get_serial()Al Viro1-30/+8
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13f81232: switch to ->get_serial()Al Viro1-28/+8
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13ark3116: switch to ->get_serial()Al Viro1-30/+8
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13cdc-acm: switch to ->[sg]et_serial()Al Viro1-27/+14
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13usb-serial: begin switching to ->[sg]et_serial()Al Viro2-0/+22
add such methods for usb_serial_driver, provide tty_operations ->[sg]et_serial() calling those. For now the lack of methods in driver means ENOIOCTLCMD from usb-serial ->[sg]et_serial(), making tty_ioctl() fall back to calling ->ioctl(). Once all drivers are converted, we'll be returning -ENOTTY instead, completing the switchover. Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13rfcomm: get rid of mentioning TIOC[SG]SERIALAl Viro1-8/+0
no support there Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13serial_core: switch to ->[sg]et_serial()Al Viro1-26/+12
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13mxser: switch to ->[sg]et_serial()Al Viro1-46/+51
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13moxa: switch to ->[sg]et_serial()Al Viro1-39/+40
Pointless dead assignments in moxa_set_serial_info() killed off; they would've been a bug, if not for the fact that user-settable flags had never been used in that driver. Bogus from day 1, though... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13isicom: switch to ->[sg]et_serial()Al Viro1-47/+25
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13ipwireless: switch to ->[sg]et_serial()Al Viro1-18/+18
Acked-by: David Sterba <dsterba@suse.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13cyclades: switch to ->[sg]et_serial()Al Viro1-40/+37
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13amiserial: switch to ->[sg]et_serial()Al Viro1-45/+33
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-09-14greybus/uart: switch to ->[sg]et_serial()Al Viro1-29/+18
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-09-14fwserial: switch to ->[sg]et_serial()Al Viro1-38/+28
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-09-14simserial: switch to ->[sg]et_serial()Al Viro1-4/+13
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-09-14tty_ioctl(): start taking TIOC[SG]SERIAL into separate methodsAl Viro2-5/+33
->set_serial() and ->get_serial() resp., both taking tty and a kernel pointer to serial_struct. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-09-14mos7720: bury dead TIOCM... in ->ioctl()Al Viro1-52/+0
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 <viro@zeniv.linux.org.uk>
2018-09-14tty_ioctl(): drop FIONBIO handlingAl Viro1-30/+0
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 <viro@zeniv.linux.org.uk>
2018-09-14move compat handling of tty ioctls to tty_compat_ioctl()Al Viro4-71/+76
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 redirecter to tty_ioctl(). As the result, their entries in fs/compat_ioctl.c (some of those had been missing, BTW) got removed, as well as n_tty_compat_ioctl_helper() (now it's never called with any cmd it would accept). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-09-11presence of RS485 ioctls has been unconditional since 2014Al Viro1-4/+0
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-08-26Linux 4.19-rc1Linus Torvalds1-2/+2
2018-08-25mm/cow: don't bother write protecting already write-protected pagesLinus Torvalds1-1/+1
This is not normally noticeable, but repeated forks are unnecessarily expensive because they repeatedly dirty the parent page tables during the page table copy operation. It's trivial to just avoid write protecting the page table entry if it was already not writable. This patch was inspired by https://bugzilla.kernel.org/show_bug.cgi?id=200447 which points to an ancient "waste time re-doing fork" issue in the presence of lots of signals. That bug was fixed by Eric Biederman's signal handling series culminating in commit c3ad2c3b02e9 ("signal: Don't restart fork when signals come in"), but the unnecessary work for repeated forks is still work just fixing, particularly since the fix is trivial. Cc: Eric Biederman <ebiederm@xmission.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-25hpfs: remove unnecessary checks on the value of r when assigning error codeColin Ian King1-1/+1
At the point where r is being checked for different values, r is always going to be equal to 2 as the previous if statements jump to end or end1 if r is not 2. Hence the assignment to err can be simplified to just err an assignment without any checks on the value or r. Detected by CoverityScan, CID#1226737 ("Logically dead code") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-25libata: maintainership updateJens Axboe1-3/+3
Tejun Heo wrote: > > I asked Jens whether he could take care of the libata tree and he > thankfully agreed, so, from now on, Jens will be the libata > maintainer. > > Thanks a lot! Thanks for your work in this area. I still remember the first linux storage summit we did in Vancouver 2001, Tejun was invited to talk about his libata error handling work. Before that, it was basically a crap shoot if we recovered properly or not... A lot of water has flown under the bridge since then! Here's an "official" patch. Linus, can you apply it? Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-24iommu/rockchip: Move irq request past pm_runtime_enableMarc Zyngier1-11/+13
Enabling the interrupt early, before power has been applied to the device, can result in an interrupt being delivered too early if: - the IOMMU shares an interrupt with a VOP - the VOP has a pending interrupt (after a kexec, for example) In these conditions, we end-up taking the interrupt without the IOMMU being ready to handle the interrupt (not powered on). Moving the interrupt request past the pm_runtime_enable() call makes sure we can at least access the IOMMU registers. Note that this is only a partial fix, and that the VOP interrupt will still be screaming until the VOP driver kicks in, which advocates for a more synchronized interrupt enabling/disabling approach. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2018-08-24iommu/rockchip: Handle errors returned from PM frameworkMarc Zyngier1-6/+15
pm_runtime_get_if_in_use can fail: either PM has been disabled altogether (-EINVAL), or the device hasn't been enabled yet (0). Sadly, the Rockchip IOMMU driver tends to conflate the two things by considering a non-zero return value as successful. This has the consequence of hiding other bugs, so let's handle this case throughout the driver, with a WARN_ON_ONCE so that we can try and work out what happened. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2018-08-24arm64: rockchip: Force CONFIG_PM on Rockchip systemsMarc Zyngier1-0/+1
A number of the Rockchip-specific drivers (IOMMU, display controllers) are now assuming that CONFIG_PM is set, and may completely misbehave if that's not the case. Since there is hardly any reason for this configuration option not to be selected anyway, let's require it (in the same way Tegra already does). Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2018-08-24ARM: rockchip: Force CONFIG_PM on Rockchip systemsMarc Zyngier1-0/+1
A number of the Rockchip-specific drivers (IOMMU, display controllers) are now assuming that CONFIG_PM is set, and may completely misbehave if that's not the case. Since there is hardly any reason for this configuration option not to be selected anyway, let's require it (in the same way Tegra already does). Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.