Most SCSI drivers want to enable "clustering", that is merging of
segments so that they might span more than a single page. Remove the
ENABLE_CLUSTERING define, and require drivers to explicitly set
DISABLE_CLUSTERING to disable this feature.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Clean up kernel-doc warnings in <drivers/firewire/core-transaction.c>
so that it can be added to a Firewire/IEEE 1394 driver-api chapter
without adding lots of noisy warnings to the documentation build.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: linux-doc@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Clean up kernel-doc warnings in <drivers/firewire/core-iso.c> so that
it can be added to a Firewire/IEEE 1394 driver-api chapter
without adding lots of noisy warnings to the documentation build.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: linux-doc@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
32-bit CLOCK_REALTIME timestamps overflow in year 2038, so all such
interfaces are deprecated now. For the FW_CDEV_IOC_GET_CYCLE_TIMER2
ioctl, we already support 64-bit timestamps, but the implementation
still uses timespec.
This changes the code to use timespec64 instead with the appropriate
accessor functions.
Link: http://lkml.kernel.org/r/20180711124456.1023039-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
This patch makes the changes for kmalloc()-family (and kvmalloc()-family)
uses. It was done via automatic conversion with manual review for the
"CHECKME" non-standard cases noted below, using the following Coccinelle
script:
// pkey_cache = kmalloc(sizeof *pkey_cache + tprops->pkey_tbl_len *
// sizeof *pkey_cache->table, GFP_KERNEL);
@@
identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
expression GFP;
identifier VAR, ELEMENT;
expression COUNT;
@@
- alloc(sizeof(*VAR) + COUNT * sizeof(*VAR->ELEMENT), GFP)
+ alloc(struct_size(VAR, ELEMENT, COUNT), GFP)
// mr = kzalloc(sizeof(*mr) + m * sizeof(mr->map[0]), GFP_KERNEL);
@@
identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
expression GFP;
identifier VAR, ELEMENT;
expression COUNT;
@@
- alloc(sizeof(*VAR) + COUNT * sizeof(VAR->ELEMENT[0]), GFP)
+ alloc(struct_size(VAR, ELEMENT, COUNT), GFP)
// Same pattern, but can't trivially locate the trailing element name,
// or variable name.
@@
identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
expression GFP;
expression SOMETHING, COUNT, ELEMENT;
@@
- alloc(sizeof(SOMETHING) + COUNT * sizeof(ELEMENT), GFP)
+ alloc(CHECKME_struct_size(&SOMETHING, ELEMENT, COUNT), GFP)
Signed-off-by: Kees Cook <keescook@chromium.org>
This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:
for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
done
with de-mangling cleanups yet to come.
NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do. But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.
The next patch from Al will sort out the final differences, and we
should be all done.
Scripted-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
- make JMicron JMB38x controllers work with IOMMU-equipped systems
- IP-over-1394: allow user-configured MTU of up to 4096 bytes
-----BEGIN PGP SIGNATURE-----
iQJOBAABCAA4FiEElVwAmOXEbvmhUkgUefNvslRdedAFAlp0aGYaHHN0ZWZhbnJA
czVyNi5pbi1iZXJsaW4uZGUACgkQefNvslRdedDOHg/+NBs+6uv7SDZ2HXfQ6EQs
ytoAaPMjrSWztHWrz3JM/Q1CECgwYJhq3pWqTCIho2CXE/PFJF0YvqSgg45buzW1
sBOsJ6Sn5yIFTcHw9IDcTjI73lNLjEyBuft7KzHswCYbNbftOaebVE+19D24wOCb
MspCcrqqQehmlHLrmhJmkv9n4kUEx7v/ZT5lXy4gXxO3/NvQ02Vq7AblbNX1/mcy
Lf7ONqWi4cjY5sp49KuR0tZJZmclYodUnqkCSSRsLGtJSj/oacMufqk9/LU80Oc4
0J9Xzf4kRGWxmdO7TqLRu4632oZeXjX/q57IsKJOcjIqPX/FDAWOdBadaEEVOSLy
AOwpXQ3GOl9SC8HmSptTSzMedRoxszwZ7NdbLvkuydoPa2mpTyxHYhOf1gy6639g
fa0iQ8LdzDIjI1R8bka9SWVmUlxaOFKbYMqhuWk+ugoG4QtZKpCdXs4MFOmSyWGX
kAtanLXKijA1iVrr1Kn2Cf2MJlvjuYfG00X4dzKIsIEvZHgwXs2mYua5wNHy4eLe
KrKC3WBGDkW81Zokk9FFvdsECvCc1W4z/bLIOWrGsMa3OLvA0jiZTVydQXMdZyHd
GL2LtpwfCbuRUZkt/ScJ3ELyXDULviaBu/mlX4Ppc2c15JW/RSmwr3S/W/n0HL6j
pe9TTDYRTnPpScJ2eI7NlYY=
=FQUh
-----END PGP SIGNATURE-----
Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire updates from Stefan Richter
- make JMicron JMB38x controllers work with IOMMU-equipped systems
- IP-over-1394: allow user-configured MTU of up to 4096 bytes
* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire-ohci: work around oversized DMA reads on JMicron controllers
firewire: net: max MTU off by one
At least some JMicron controllers issue buggy oversized DMA reads when
fetching context descriptors, always fetching 0x20 bytes at once for
descriptors which are only 0x10 bytes long. This is often harmless, but
can cause page faults on modern systems with IOMMUs:
DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set
firewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_read
This works around the problem by always leaving 0x10 padding bytes at
the end of descriptor buffer pages, which should be harmless to do
unconditionally for controllers in case others have the same behavior.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The latest max_mtu patch missed that datagram_size is actually one less
than the datagram's Total Length.
Fixes: 357f4aae85 ("firewire: net: really fix maximum possible MTU")
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Pull timer updates from Thomas Gleixner:
"Yet another big pile of changes:
- More year 2038 work from Arnd slowly reaching the point where we
need to think about the syscalls themself.
- A new timer function which allows to conditionally (re)arm a timer
only when it's either not running or the new expiry time is sooner
than the armed expiry time. This allows to use a single timer for
multiple timeout requirements w/o caring about the first expiry
time at the call site.
- A new NMI safe accessor to clock real time for the printk timestamp
work. Can be used by tracing, perf as well if required.
- A large number of timer setup conversions from Kees which got
collected here because either maintainers requested so or they
simply got ignored. As Kees pointed out already there are a few
trivial merge conflicts and some redundant commits which was
unavoidable due to the size of this conversion effort.
- Avoid a redundant iteration in the timer wheel softirq processing.
- Provide a mechanism to treat RTC implementations depending on their
hardware properties, i.e. don't inflict the write at the 0.5
seconds boundary which originates from the PC CMOS RTC to all RTCs.
No functional change as drivers need to be updated separately.
- The usual small updates to core code clocksource drivers. Nothing
really exciting"
* 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (111 commits)
timers: Add a function to start/reduce a timer
pstore: Use ktime_get_real_fast_ns() instead of __getnstimeofday()
timer: Prepare to change all DEFINE_TIMER() callbacks
netfilter: ipvs: Convert timers to use timer_setup()
scsi: qla2xxx: Convert timers to use timer_setup()
block/aoe: discover_timer: Convert timers to use timer_setup()
ide: Convert timers to use timer_setup()
drbd: Convert timers to use timer_setup()
mailbox: Convert timers to use timer_setup()
crypto: Convert timers to use timer_setup()
drivers/pcmcia: omap1: Fix error in automated timer conversion
ARM: footbridge: Fix typo in timer conversion
drivers/sgi-xp: Convert timers to use timer_setup()
drivers/pcmcia: Convert timers to use timer_setup()
drivers/memstick: Convert timers to use timer_setup()
drivers/macintosh: Convert timers to use timer_setup()
hwrng/xgene-rng: Convert timers to use timer_setup()
auxdisplay: Convert timers to use timer_setup()
sparc/led: Convert timers to use timer_setup()
mips: ip22/32: Convert timers to use timer_setup()
...
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Remove uses of init_timer_on_stack() with open-coded function and data
assignments that could be expressed using timer_setup_on_stack(). Several
were removed from the stack entirely since there was a one-to-one mapping
of parent structure to timer, those are switched to using timer_setup()
instead. All related callbacks were adjusted to use from_timer().
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mips@linux-mips.org
Cc: Petr Mladek <pmladek@suse.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: linux1394-devel@lists.sourceforge.net
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: linux-s390@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
Cc: linux-scsi@vger.kernel.org
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ursula Braun <ubraun@linux.vnet.ibm.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Harish Patil <harish.patil@cavium.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Michael Reed <mdr@sgi.com>
Cc: Manish Chopra <manish.chopra@cavium.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-pm@vger.kernel.org
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Mark Gross <mark.gross@intel.com>
Cc: linux-watchdog@vger.kernel.org
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: netdev@vger.kernel.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Link: https://lkml.kernel.org/r/1507159627-127660-4-git-send-email-keescook@chromium.org
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions return void * and remove all the casts across
the tree, adding a (u8 *) cast only where the unsigned char pointer
was used directly, all done with the following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
@@
expression SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- fn(SKB, LEN)[0]
+ *(u8 *)fn(SKB, LEN)
Note that the last part there converts from push(...)[0] to the
more idiomatic *(u8 *)push(...).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.
An spatch similar to the one for skb_put_zero() converts many
of the places using it:
@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)
@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)
@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);
(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Windsor <dwindsor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull IDR rewrite from Matthew Wilcox:
"The most significant part of the following is the patch to rewrite the
IDR & IDA to be clients of the radix tree. But there's much more,
including an enhancement of the IDA to be significantly more space
efficient, an IDR & IDA test suite, some improvements to the IDR API
(and driver changes to take advantage of those improvements), several
improvements to the radix tree test suite and RCU annotations.
The IDR & IDA rewrite had a good spin in linux-next and Andrew's tree
for most of the last cycle. Coupled with the IDR test suite, I feel
pretty confident that any remaining bugs are quite hard to hit. 0-day
did a great job of watching my git tree and pointing out problems; as
it hit them, I added new test-cases to be sure not to be caught the
same way twice"
Willy goes on to expand a bit on the IDR rewrite rationale:
"The radix tree and the IDR use very similar data structures.
Merging the two codebases lets us share the memory allocation pools,
and results in a net deletion of 500 lines of code. It also opens up
the possibility of exposing more of the features of the radix tree to
users of the IDR (and I have some interesting patches along those
lines waiting for 4.12)
It also shrinks the size of the 'struct idr' from 40 bytes to 24 which
will shrink a fair few data structures that embed an IDR"
* 'idr-4.11' of git://git.infradead.org/users/willy/linux-dax: (32 commits)
radix tree test suite: Add config option for map shift
idr: Add missing __rcu annotations
radix-tree: Fix __rcu annotations
radix-tree: Add rcu_dereference and rcu_assign_pointer calls
radix tree test suite: Run iteration tests for longer
radix tree test suite: Fix split/join memory leaks
radix tree test suite: Fix leaks in regression2.c
radix tree test suite: Fix leaky tests
radix tree test suite: Enable address sanitizer
radix_tree_iter_resume: Fix out of bounds error
radix-tree: Store a pointer to the root in each node
radix-tree: Chain preallocated nodes through ->parent
radix tree test suite: Dial down verbosity with -v
radix tree test suite: Introduce kmalloc_verbose
idr: Return the deleted entry from idr_remove
radix tree test suite: Build separate binaries for some tests
ida: Use exceptional entries for small IDAs
ida: Move ida_bitmap to a percpu variable
Reimplement IDR and IDA using the radix tree
radix-tree: Add radix_tree_iter_delete
...
Fix typos and add the following to the scripts/spelling.txt:
intialization||initialization
The "inintialization" in drivers/acpi/spcr.c is a different pattern but
I fixed it as well in this commit.
Link: http://lkml.kernel.org/r/1481573103-11329-16-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It is a relatively common idiom (8 instances) to first look up an IDR
entry, and then remove it from the tree if it is found, possibly doing
further operations upon the entry afterwards. If we change idr_remove()
to return the removed object, all of these users can save themselves a
walk of the IDR tree.
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:
datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).
Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:
ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;
ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;
Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.
Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.
So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The IP-over-1394 driver firewire-net lacked input validation when
handling incoming fragmented datagrams. A maliciously formed fragment
with a respectively large datagram_offset would cause a memcpy past the
datagram buffer.
So, drop any packets carrying a fragment with offset + length larger
than datagram_size.
In addition, ensure that
- GASP header, unfragmented encapsulation header, or fragment
encapsulation header actually exists before we access it,
- the encapsulated datagram or fragment is of nonzero size.
Reported-by: Eyal Itkin <eyal.itkin@gmail.com>
Reviewed-by: Eyal Itkin <eyal.itkin@gmail.com>
Fixes: CVE 2016-8633
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Mostly simple overlapping changes.
For example, David Ahern's adjacency list revamp in 'net-next'
conflicted with an adjacency list traversal bug fix in 'net'.
Signed-off-by: David S. Miller <davem@davemloft.net>
The maximum unicast datagram size /without/ link fragmentation is
4096 - 4 = 4092 (max IEEE 1394 async payload size at >= S800 bus speed,
minus unfragmented encapssulation header). Max broadcast datagram size
without fragmentation is 8 bytes less than that (due to GASP header).
The maximum datagram size /with/ link fragmentation is 0xfff = 4095
for unicast and broadcast. This is because the RFC 2734 fragment
encapsulation header field for datagram size is only 12 bits wide.
Fixes: 5d48f00d836a('firewire: net: fix maximum possible MTU')
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
firewire-net, like the older eth1394 driver, reduced the initial MTU to
less than 1500 octets if the local link layer controller's asynchronous
packet reception limit was lower.
This is bogus, since this reception limit does not have anything to do
with the transmission limit. Neither did this reduction affect the TX
path positively, nor could it prevent link fragmentation at the RX path.
Many FireWire CardBus cards have a max_rec of 9, causing an initial MTU
of 1024 - 16 = 1008. RFC 2734 and RFC 3146 allow a minimum max_rec = 8,
which would result in an initial MTU of 512 - 16 = 496. On such cards,
IPv6 could only be employed if the MTU was manually increased to 1280 or
more, i.e. IPv6 would not work without intervention from userland.
We now always initialize the MTU to 1500, which is the default according
to RFC 2734 and RFC 3146.
On a VIA VT6316 based CardBus card which was affected by this, changing
the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
RX remains unaffected.
CC: netdev@vger.kernel.org
CC: linux1394-devel@lists.sourceforge.net
CC: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit b3e3893e12 ("net: use core MTU range checking in misc drivers")
mistakenly introduced an upper limit for firewire-net's MTU based on the
local link layer controller's reception capability. Revert this. Neither
RFC 2734 nor our implementation impose any particular upper limit.
Actually, to be on the safe side and to make the code explicit, set
ETH_MAX_MTU = 65535 as upper limit now.
(I replaced sizeof(struct rfc2734_header) by the equivalent
RFC2374_FRAG_HDR_SIZE in order to avoid distracting long/int conversions.)
Fixes: b3e3893e1253('net: use core MTU range checking in misc drivers')
CC: netdev@vger.kernel.org
CC: linux1394-devel@lists.sourceforge.net
CC: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
firewire-net:
- set min/max_mtu
- remove fwnet_change_mtu
nes:
- set max_mtu
- clean up nes_netdev_change_mtu
xpnet:
- set min/max_mtu
- remove xpnet_dev_change_mtu
hippi:
- set min/max_mtu
- remove hippi_change_mtu
batman-adv:
- set max_mtu
- remove batadv_interface_change_mtu
- initialization is a little async, not 100% certain that max_mtu is set
in the optimal place, don't have hardware to test with
rionet:
- set min/max_mtu
- remove rionet_change_mtu
slip:
- set min/max_mtu
- streamline sl_change_mtu
um/net_kern:
- remove pointless ndo_change_mtu
hsi/clients/ssi_protocol:
- use core MTU range checking
- remove now redundant ssip_pn_set_mtu
ipoib:
- set a default max MTU value
- Note: ipoib's actual max MTU can vary, depending on if the device is in
connected mode or not, so we'll just set the max_mtu value to the max
possible, and let the ndo_change_mtu function continue to validate any new
MTU change requests with checks for CM or not. Note that ipoib has no
min_mtu set, and thus, the network core's mtu > 0 check is the only lower
bounds here.
mptlan:
- use net core MTU range checking
- remove now redundant mpt_lan_change_mtu
fddi:
- min_mtu = 21, max_mtu = 4470
- remove now redundant fddi_change_mtu (including export)
fjes:
- min_mtu = 8192, max_mtu = 65536
- The max_mtu value is actually one over IP_MAX_MTU here, but the idea is to
get past the core net MTU range checks so fjes_change_mtu can validate a
new MTU against what it supports (see fjes_support_mtu in fjes_hw.c)
hsr:
- min_mtu = 0 (calls ether_setup, max_mtu is 1500)
f_phonet:
- min_mtu = 6, max_mtu = 65541
u_ether:
- min_mtu = 14, max_mtu = 15412
phonet/pep-gprs:
- min_mtu = 576, max_mtu = 65530
- remove redundant gprs_set_mtu
CC: netdev@vger.kernel.org
CC: linux-rdma@vger.kernel.org
CC: Stefan Richter <stefanr@s5r6.in-berlin.de>
CC: Faisal Latif <faisal.latif@intel.com>
CC: linux-rdma@vger.kernel.org
CC: Cliff Whickman <cpw@sgi.com>
CC: Robin Holt <robinmholt@gmail.com>
CC: Jes Sorensen <jes@trained-monkey.org>
CC: Marek Lindner <mareklindner@neomailbox.ch>
CC: Simon Wunderlich <sw@simonwunderlich.de>
CC: Antonio Quartulli <a@unstable.cc>
CC: Sathya Prakash <sathya.prakash@broadcom.com>
CC: Chaitra P B <chaitra.basappa@broadcom.com>
CC: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
CC: MPT-FusionLinux.pdl@broadcom.com
CC: Sebastian Reichel <sre@kernel.org>
CC: Felipe Balbi <balbi@kernel.org>
CC: Arvid Brodin <arvid.brodin@alten.se>
CC: Remi Denis-Courmont <courmisch@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is no check if ioremap_nocache() returns a valid pointer.
Potentially it can lead to null pointer dereference.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (renamed goto labels)
- Occurrences of timeval were supposed to be eliminated last round,
now remove a last forgotten one.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJW9PnoAAoJEHnzb7JUXXnQlBAQAOZELI61TS2XAk+94EvxODgY
FrTOzZFGDUlXlkdyI7Smlla1D6LwV47FCRpZYTuf4z1xD5+nT9RcvxjiaAGUZxmJ
swhdei74LPRIW7OfVtODz7kLsNLBJM1Le6+kVfugxDPxaOMFn7oqn7TsLakg005l
gyzhP7NnZm15IuUnGpjjZgx1utNvVeMZ+0GdhUfTzVHPyHzYh0iquYC8yCnW2AfT
Z9PN5j5XKdE/sJDTtWwq2hvSaDfUr6cybNkk+jYGIn9qxtTdUebg+ZddoU0aLo6L
DsJPUdAQ2mo9rrjJchR5v+jbbZ2AYDFFUz8GfJceUvc2dcllm7WQsYQO4AsRM0A7
YllY8xzkK11Mid7ZxoHpj6F8c6ZJztPZ2qT/H58KgGngkn4frkPCGMkverTRF2Yp
D/bxQ/sRifK3kLWxTjHEcomifXasvHtj4Cwfklcu1RqCJuKgMawhrtjktjqTZKFC
vfG9OoRb6xV2RJtAnDVz+QuaGklPLP/NekQzFGryHYWHCEjI62sH8+WUhVkOs+m5
1/23N4mqJ/sOurp3Gj0a19lKiAbAAYHMp2v8vLWC7dfQ7VhJC/K0vEQm0HL0Bvwf
FqIUg6QqfVYjckdL9Fh/0XCMKrOF9Qb59JWOWXPnFjuc7KD2/s/vpfgby6cP+14/
D1NrNVkp2bEiLZ9avdSL
=S0zD
-----END PGP SIGNATURE-----
Merge tag 'firewire-update2' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire leftover from Stefan Richter:
"Occurrences of timeval were supposed to be eliminated last round, now
remove a last forgotten one"
* tag 'firewire-update2' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: nosy: Replace timeval with timespec64
Firewire was using is_compat_task to check whether it was in a compat
ioctl or a non-compat ioctl. Use is_compat_syscall instead so it works
properly on all architectures.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
'struct timeval' uses a 32 bit field for its 'seconds' value which
will overflow in year 2038 and beyond. This patch replaces the use
of timeval in nosy.c with timespec64 which doesn't suffer from y2038
issue. The code is correct as is - since it is only using the
microseconds portion of timeval. However, this patch does the
replacement as part of a larger effort to remove all instances of
'struct timeval' from the kernel (that would help identify cases
where the code is actually broken).
Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
- Work around JMicron initialization quirk.
Affected isochronous transmission, e.g. audio via FFADO or ALSA.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWQ4HdAAoJEHnzb7JUXXnQeYgQAIBTEKytcjRSFnfB4XgBRAXS
0MU6702PdM1qZW8m9oEu42UJgh/WrMO2F+CSM3XWbRwtMdhz6KpLYp2PIKpbeDWz
q50lhNweeISxz03+Bf12fYxxcfLfdBrS2SmA7Xkn3L/sESDtz6eSfgztc9DA5j0e
mLm7fsFsZiFB6t0zq5YPpEh78J7RjLilStxo+N7zz2/xFz2vWoyH7YovZNwXogVb
BoMSr0IWeOUIT/QxXFA16McsdCFQqE7/m8ndACnpnSn+at91t652/CP7RnrWrmKD
ewQ3qw1uzVSZ4FaE6fUe5+NvyvV9i0s2h0iIXtSZyXMly8P2ghQ6WOWjZ1yrK8Iw
wJSN8XeDNCvXpSlYDGbYZ8ErxOo9UYwAz9lrioQxjDOsyuW+3d2XRV97zK/ur5O5
LPNMYmD6xA6AhX7oj/pU66RV7fLleJd8WBfP3lBdyaHC4M9AXkHyNr+wsHAvzh5j
oOswe1usVC9Wqxis68rvTwWROw8LhD0QyGf/QfQ16xZ9UU7TyJgBNGV8BW1PZ4lX
GW78mPqCrO5rp21R7ZsnlcEFEes54V57wDGjEMGA9iPXfCYwRo87YMmfZK6XgIa1
GBAiLKve686VLDvN+ioN9jXjOKaSgzYa5xUYrLH/WMwnCCbexS/0TlUJI3EWk09A
/4vAE3zkW+IjTJ8tzi8h
=ivX9
-----END PGP SIGNATURE-----
Merge tag 'firewire-update' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire fix from Stefan Richter:
"Work around JMicron initialization quirk, which ffected isochronous
transmission, e.g. audio via FFADO or ALSA"
* tag 'firewire-update' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: fix JMicron JMB38x IT context discovery
__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts. They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve". __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".
Over time, callers had a requirement to not block when fallback options
were available. Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.
This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative. High priority users continue to use
__GFP_HIGH. __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim. __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim. __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.
This patch then converts a number of sites
o __GFP_ATOMIC is used by callers that are high priority and have memory
pools for those requests. GFP_ATOMIC uses this flag.
o Callers that have a limited mempool to guarantee forward progress clear
__GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
into this category where kswapd will still be woken but atomic reserves
are not used as there is a one-entry mempool to guarantee progress.
o Callers that are checking if they are non-blocking should use the
helper gfpflags_allow_blocking() where possible. This is because
checking for __GFP_WAIT as was done historically now can trigger false
positives. Some exceptions like dm-crypt.c exist where the code intent
is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
flag manipulations.
o Callers that built their own GFP flags instead of starting with GFP_KERNEL
and friends now also need to specify __GFP_KSWAPD_RECLAIM.
The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.
The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL. They may
now wish to specify __GFP_KSWAPD_RECLAIM. It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
software_reset() may fail
- due to unresponsive chip with -EBUSY (-16), or
- due to ejected or unseated card with -ENODEV (-19).
Let the PCI probe and resume routines log the actual error code instead
of hardwired -EBUSY.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
32 bit systems using 'struct timeval' will break in the year 2038, so
we replace the code appropriately. However, this driver is not broken
in 2038 since we are using only the microseconds portion of the
current time.
This patch replaces timeval with timespec64.
Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo
controllers: Often or even most of the time, the controller is
initialized with the message "added OHCI v1.10 device as card 0, 4 IR +
0 IT contexts, quirks 0x10". With 0 isochronous transmit DMA contexts
(IT contexts), applications like audio output are impossible.
However, OHCI-1394 demands that at least 4 IT contexts are implemented
by the link layer controller, and indeed JMicron JMB38x do implement
four of them. Only their IsoXmitIntMask register is unreliable at early
access.
With my own JMB381 single function controller I found:
- I can reproduce the problem with a lower probability than Craig's.
- If I put a loop around the section which clears and reads
IsoXmitIntMask, then either the first or the second attempt will
return the correct initial mask of 0x0000000f. I never encountered
a case of needing more than a second attempt.
- Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)
before the first write, the subsequent read will return the correct
result.
- If I merely ignore a wrong read result and force the known real
result, later isochronous transmit DMA usage works just fine.
So let's just fix this chip bug up by the latter method. Tested with
JMB381 on kernel 3.13 and 4.3.
Since OHCI-1394 generally requires 4 IT contexts at a minium, this
workaround is simply applied whenever the initial read of IsoXmitIntMask
returns 0, regardless whether it's a JMicron chip or not. I never heard
of this issue together with any other chip though.
I am not 100% sure that this fix works on the OHCI-1394 part of JMB380
and JMB388 combo controllers exactly the same as on the JMB381 single-
function controller, but so far I haven't had a chance to let an owner
of a combo chip run a patched kernel.
Strangely enough, IsoRecvIntMask is always reported correctly, even
though it is probed right before IsoXmitIntMask.
Reported-by: Clifford Dunn
Reported-by: Craig Moore <craig.moore@qenos.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
'0' is now used as the default cmd_per_lun value,
so there's no need to explicitly set it to '1' in the
host template.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Conflicts:
drivers/net/ethernet/rocker/rocker.c
The rocker commit was two overlapping changes, one to rename
the ->vport member to ->pport, and another making the bitmask
expression use '1ULL' instead of plain '1'.
Signed-off-by: David S. Miller <davem@davemloft.net>
Now that there are no more users kill dev_rebuild_header and all of it's
implementations.
This is long overdue.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The kernel was using the vendor ID 0xd00d1e, which was inherited from
the old ieee1394 driver stack. However, this ID was not registered, and
invalid.
Instead, use the vendor/model IDs that are now officially assigned to
the kernel:
https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments
[stefanr:
- The vendor ID 001f11 is Openmoko, Inc.'s identifier, registered at
IEEE Registration Authority.
- The range of model IDs 023900...0239ff are the Linux kernel 1394
subsystem's identifiers, registered at Openmoko.
- Model ID 023901 is picked by the subsystem developers as
firewire-core's model ID.]
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
[Bart van Asche:] SCSI core never sets cmd->sc_data_direction to
DMA_BIDIRECTIONAL; scsi_bidi_cmnd(cmd) should be used instead to
test for a bidirectional command.
[Christoph Hellwig:] Bidirectional commands won't ever be queued
anyway, unless a LLD or transport driver sets QUEUE_FLAG_BIDI.
So, simply remove the respective queuecommand check in the SBP-2
transport driver.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Remove the function ar_prev_buffer_index() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
firewire-core uses fw_card.lock to protect topology data and transaction
data. firewire-sbp2 uses fw_card.lock for entirely unrelated purposes.
Introduce a sbp2_target.lock to firewire-sbp2 and replace all
fw_card.lock uses in the driver. fw_card.lock is now entirely private
to firewire-core. This has no immediate advantage apart from making it
clear in the code that firewire-sbp2 does not interact with the core
via the core lock.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Users of card->lock Calling context
------------------------------------------------------------------------
sbp2_status_write AR-req handler, tasklet
complete_transaction AR-resp or AT-req handler, tasklet
sbp2_send_orb among else scsi host .queuecommand, which may
be called in some sort of atomic context
sbp2_cancel_orbs sbp2_send_management_orb/
sbp2_{login,reconnect,remove},
worklet or process
sbp2_scsi_abort, scsi eh thread
sbp2_allow_block sbp2_login, worklet
sbp2_conditionally_block among else complete_command_orb, tasklet
sbp2_conditionally_unblock sbp2_{login,reconnect}, worklet
sbp2_unblock sbp2_{login,remove}, worklet or process
Drop the IRQ flags saving from sbp2_cancel_orbs,
sbp2_conditionally_unblock, and sbp2_unblock.
It was already omitted in sbp2_allow_block.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The assertion in the comment in sbp2_allow_block() is no longer true.
Or maybe it never was true. At least now, the sole caller of
sbp2_allow_block(), sbp2_login, can run concurrently to one of
sbp2_unblock()'s callers, sbp2_remove.
sbp2_login is performed by sbp2_logical_unit.work.
sbp2_remove is performed by fw_device.work.
sbp2_remove cancels sbp2_logical_unit.work, but only after it called
sbp2_unblock.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
fw_csr_string() truncates and terminates target strings like strlcpy()
does. Unlike strlcpy(), it returns the target strlen, not the source
strlen, hence users of fw_csr_string() are unable to detect truncation.
Point this behavior out in the kerneldoc comment.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
vm_map_ram() is intended for short-lived objects, so using it for the AR
buffers could fragment address space, especially on a 32-bit machine.
For an allocation that lives as long as the device, vmap() is the better
choice.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Found by the UC-KLEE tool: A user could supply less input to
firewire-cdev ioctls than write- or write/read-type ioctl handlers
expect. The handlers used data from uninitialized kernel stack then.
This could partially leak back to the user if the kernel subsequently
generated fw_cdev_event_'s (to be read from the firewire-cdev fd)
which notably would contain the _u64 closure field which many of the
ioctl argument structures contain.
The fact that the handlers would act on random garbage input is a
lesser issue since all handlers must check their input anyway.
The fix simply always null-initializes the entire ioctl argument buffer
regardless of the actual length of expected user input. That is, a
runtime overhead of memset(..., 40) is added to each firewirew-cdev
ioctl() call. [Comment from Clemens Ladisch: This part of the stack is
most likely to be already in the cache.]
Remarks:
- There was never any leak from kernel stack to the ioctl output
buffer itself. IOW, it was not possible to read kernel stack by a
read-type or write/read-type ioctl alone; the leak could at most
happen in combination with read()ing subsequent event data.
- The actual expected minimum user input of each ioctl from
include/uapi/linux/firewire-cdev.h is, in bytes:
[0x00] = 32, [0x05] = 4, [0x0a] = 16, [0x0f] = 20, [0x14] = 16,
[0x01] = 36, [0x06] = 20, [0x0b] = 4, [0x10] = 20, [0x15] = 20,
[0x02] = 20, [0x07] = 4, [0x0c] = 0, [0x11] = 0, [0x16] = 8,
[0x03] = 4, [0x08] = 24, [0x0d] = 20, [0x12] = 36, [0x17] = 12,
[0x04] = 20, [0x09] = 24, [0x0e] = 4, [0x13] = 40, [0x18] = 4.
Reported-by: David Ramos <daramos@stanford.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Pull networking updates from David Miller:
"Highlights:
1) Steady transitioning of the BPF instructure to a generic spot so
all kernel subsystems can make use of it, from Alexei Starovoitov.
2) SFC driver supports busy polling, from Alexandre Rames.
3) Take advantage of hash table in UDP multicast delivery, from David
Held.
4) Lighten locking, in particular by getting rid of the LRU lists, in
inet frag handling. From Florian Westphal.
5) Add support for various RFC6458 control messages in SCTP, from
Geir Ola Vaagland.
6) Allow to filter bridge forwarding database dumps by device, from
Jamal Hadi Salim.
7) virtio-net also now supports busy polling, from Jason Wang.
8) Some low level optimization tweaks in pktgen from Jesper Dangaard
Brouer.
9) Add support for ipv6 address generation modes, so that userland
can have some input into the process. From Jiri Pirko.
10) Consolidate common TCP connection request code in ipv4 and ipv6,
from Octavian Purdila.
11) New ARP packet logger in netfilter, from Pablo Neira Ayuso.
12) Generic resizable RCU hash table, with intial users in netlink and
nftables. From Thomas Graf.
13) Maintain a name assignment type so that userspace can see where a
network device name came from (enumerated by kernel, assigned
explicitly by userspace, etc.) From Tom Gundersen.
14) Automatic flow label generation on transmit in ipv6, from Tom
Herbert.
15) New packet timestamping facilities from Willem de Bruijn, meant to
assist in measuring latencies going into/out-of the packet
scheduler, latency from TCP data transmission to ACK, etc"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1536 commits)
cxgb4 : Disable recursive mailbox commands when enabling vi
net: reduce USB network driver config options.
tg3: Modify tg3_tso_bug() to handle multiple TX rings
amd-xgbe: Perform phy connect/disconnect at dev open/stop
amd-xgbe: Use dma_set_mask_and_coherent to set DMA mask
net: sun4i-emac: fix memory leak on bad packet
sctp: fix possible seqlock seadlock in sctp_packet_transmit()
Revert "net: phy: Set the driver when registering an MDIO bus device"
cxgb4vf: Turn off SGE RX/TX Callback Timers and interrupts in PCI shutdown routine
team: Simplify return path of team_newlink
bridge: Update outdated comment on promiscuous mode
net-timestamp: ACK timestamp for bytestreams
net-timestamp: TCP timestamping
net-timestamp: SCHED timestamp on entering packet scheduler
net-timestamp: add key to disambiguate concurrent datagrams
net-timestamp: move timestamp flags out of sk_flags
net-timestamp: extend SCM_TIMESTAMPING ancillary data struct
cxgb4i : Move stray CPL definitions to cxgb4 driver
tcp: reduce spurious retransmits due to transient SACK reneging
qlcnic: Initialize dcbnl_ops before register_netdev
...
Pull timer and time updates from Thomas Gleixner:
"A rather large update of timers, timekeeping & co
- Core timekeeping code is year-2038 safe now for 32bit machines.
Now we just need to fix all in kernel users and the gazillion of
user space interfaces which rely on timespec/timeval :)
- Better cache layout for the timekeeping internal data structures.
- Proper nanosecond based interfaces for in kernel users.
- Tree wide cleanup of code which wants nanoseconds but does hoops
and loops to convert back and forth from timespecs. Some of it
definitely belongs into the ugly code museum.
- Consolidation of the timekeeping interface zoo.
- A fast NMI safe accessor to clock monotonic for tracing. This is a
long standing request to support correlated user/kernel space
traces. With proper NTP frequency correction it's also suitable
for correlation of traces accross separate machines.
- Checkpoint/restart support for timerfd.
- A few NOHZ[_FULL] improvements in the [hr]timer code.
- Code move from kernel to kernel/time of all time* related code.
- New clocksource/event drivers from the ARM universe. I'm really
impressed that despite an architected timer in the newer chips SoC
manufacturers insist on inventing new and differently broken SoC
specific timers.
[ Ed. "Impressed"? I don't think that word means what you think it means ]
- Another round of code move from arch to drivers. Looks like most
of the legacy mess in ARM regarding timers is sorted out except for
a few obnoxious strongholds.
- The usual updates and fixlets all over the place"
* 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (114 commits)
timekeeping: Fixup typo in update_vsyscall_old definition
clocksource: document some basic timekeeping concepts
timekeeping: Use cached ntp_tick_length when accumulating error
timekeeping: Rework frequency adjustments to work better w/ nohz
timekeeping: Minor fixup for timespec64->timespec assignment
ftrace: Provide trace clocks monotonic
timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC
seqcount: Add raw_write_seqcount_latch()
seqcount: Provide raw_read_seqcount()
timekeeping: Use tk_read_base as argument for timekeeping_get_ns()
timekeeping: Create struct tk_read_base and use it in struct timekeeper
timekeeping: Restructure the timekeeper some more
clocksource: Get rid of cycle_last
clocksource: Move cycle_last validation to core code
clocksource: Make delta calculation a function
wireless: ath9k: Get rid of timespec conversions
drm: vmwgfx: Use nsec based interfaces
drm: i915: Use nsec based interfaces
timekeeping: Provide ktime_get_raw()
hangcheck-timer: Use ktime_get_ns()
...
with some isochronous workloads (regression since v3.16-rc1).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJT02gRAAoJEHnzb7JUXXnQJDcQAOQ7w0+/QNR9xQUuj4Kmn8Kw
paUJ0ccGa5LdfTZIThbVPdn3R5mdKgCYVookRbSktmAXo8C7IzLsGk8hw35SdA7g
Ap638MKIfY1+tNajG4fRZGptIRf04SzJpH3qYtApZQIaXZ3NWS9zHhobyOX/wFIf
HyiorPp6PEy1BBGdnMavS71v3L04oQ84eg2bUyWvi2sKT1RHO1pcHTl25FgXARsX
k1a35waw2fiP7USlYWdq+dNFnKxirlij9P1Ma72stLY16/NoxDiLRHs+hQTWBfM2
BsHtx739THyTYA0rpsO7U7YypsxM+SihnwJAC0ZRk760FsCrWBvOIcjHuqP3Wh1j
vzydxLYTpOCtdrRJ1epZpC96BSBgq2+N8vf4dNC/MOxX4/O8im80jGf5QpMuARxu
MqLkTfIeFPirvXv2PNtWvomeAzDTvyaH/OYxh6G8389yIRD9hs9kxc0bjyfXbPlh
I/Yl7XhhQq3Gbq09th3rMy6LZUW9IW50w9HHDeGVJWwsltMV0cR2Wm9R4nWcRmtB
TxGuGAxiwFI13eEcJvtHf/CB2JvR24t51kmje/0s+ag4KOw7ByDGZH60K3y14tb0
9vVisqfputElv0rz7heW+gYFi9+3Jo0NGGRDTUoJ4wTTJvCUyoUsiXTXl3ryc+ux
tayMjniMBsPKLA/iKbuX
=xNu7
-----END PGP SIGNATURE-----
Merge tag 'firewire-fix-vt6315' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire regression fix from Stefan Richter:
"IEEE 1394 (FireWire) subsystem fix: MSI don't work on VIA PCIe
controllers with some isochronous workloads (regression since
v3.16-rc1)"
* tag 'firewire-fix-vt6315' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: disable MSI for VIA VT6315 again
Revert half of commit d151f9854f21: If isochronous I/O is attempted with
packets larget than 1 kByte, VIA VT6315 rev 01 immediately stops to generate
any interrupts if MSI are used. Fix this by going back to legacy interrupts.
[Thread "Isochronous streaming with VT6315 OHCI",
http://marc.info/?t=139049641500003]
With smaller packets, the loss of IRQs happens too but only very rarely ---
rarely eneough that it was not yet possible for me to determine whether
QUIRK_NO_MSI is an actual fix for this rare variation of this chip bug.
I am keeping QUIRK_CYCLE_TIMER off of VT6315 rev >= 1 because this has been
verified by myself with certainty. On the other hand, I am also keeping
QUIRK_CYCLE_TIMER on for VT6315 rev 0 because I don't know at this time
whether this revision accesses Cycle Timer non-atomically like most of the
other VIA OHCIs are known to do.
Reported-by: Rémy Bruno <remy-fw@remy.trinnov.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
to be built on platforms which don't provide the DMA mapping API.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJTxCGPAAoJEHnzb7JUXXnQ0W8QAKTGboWwSU5kznTcWGveIgEl
fckaDnyinK9Vd6lOpixxsSc0rxdaKPmMmoC1ta2AGcD4NgRyfM2aD3Lw6dArzlHr
xgcDRPE4K/41atxf6Z/wZnsXFSLrNEJbr6e8oZncGDzcRp4DKzv7tX2meNzyQRFE
ns0/sjeN7QJEamd8vUkELiVdBED7NLiQjxXdULQ9AjY/cC3byzWAHzyoII0ff5NY
+URYGtTIxwJ2KoNAtqD9OAazwPUV8rt1XXWnqkUHS89TnACsKiWmHpaBq+6jTkqG
YsRxY9h0eZ+sSHoeEBUS2WLiaKWufvsBWBTCOUVoO0eS2iYHJQ1SwSLYU1+Zh0IR
Fey2N2YaMA1HNthJ0OJJdC+sqSZ/tBmE+ytN7rTVHu0Yw0ZffzSPgJ303jIO0y87
rYQ57K6dXhn5kDqh/PheDJCZ1OwMqz+zvgJDyv9XaEcm9lynDmmhc2IqmzlqONmz
0UbiHITiqMrv6bSzZ83+PVeoROw2DBgH/fEu/Xk2vC1hBA7s4NynGSllEht1tXT3
zLbVW/bBbZfjqc0a1UADBRHVKSllac+BPlxvGHSUxJusqC2VN9S9tgEhboj7+baY
7VHbGkuCaEqtZeErzfNTN9uGvUsBN0KGDatW4Kp0g2CZ33dFDpJFOt7O5QaephnF
DhlO4daXNsvHvFVgpBGZ
=vY8J
-----END PGP SIGNATURE-----
Merge tag 'firewire-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire fix from Stefan Richter:
"The 1394 drivers cannot and are not supposed to be built on platforms
which don't provide the DMA mapping API (regression since v3.16-rc1
with CONFIG_COMPILE_TEST=y on some architectures)"
* tag 'firewire-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: IEEE 1394 (FireWire) support should depend on HAS_DMA
Commit b3d681a4fc ("firewire: Use
COMPILE_TEST for build testing") added COMPILE_TEST as an alternative
dependency for the purpose of build testing the firewire core.
However, this bypasses all other implicit dependencies assumed by PCI,
like HAS_DMA.
If NO_DMA=y:
drivers/built-in.o: In function `fw_iso_buffer_destroy':
(.text+0x36a096): undefined reference to `dma_unmap_page'
drivers/built-in.o: In function `fw_iso_buffer_map_dma':
(.text+0x36a164): undefined reference to `dma_map_page'
drivers/built-in.o: In function `fw_iso_buffer_map_dma':
(.text+0x36a172): undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `sbp2_send_management_orb':
sbp2.c:(.text+0x36c6b4): undefined reference to `dma_map_single'
sbp2.c:(.text+0x36c6c8): undefined reference to `dma_mapping_error'
sbp2.c:(.text+0x36c772): undefined reference to `dma_map_single'
sbp2.c:(.text+0x36c786): undefined reference to `dma_mapping_error'
sbp2.c:(.text+0x36c854): undefined reference to `dma_unmap_single'
sbp2.c:(.text+0x36c872): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `sbp2_map_scatterlist':
sbp2.c:(.text+0x36ccbc): undefined reference to `scsi_dma_map'
sbp2.c:(.text+0x36cd36): undefined reference to `dma_map_single'
sbp2.c:(.text+0x36cd4e): undefined reference to `dma_mapping_error'
sbp2.c:(.text+0x36cd84): undefined reference to `scsi_dma_unmap'
drivers/built-in.o: In function `sbp2_unmap_scatterlist':
sbp2.c:(.text+0x36cda6): undefined reference to `scsi_dma_unmap'
sbp2.c:(.text+0x36cdc6): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `complete_command_orb':
sbp2.c:(.text+0x36d6ac): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `sbp2_scsi_queuecommand':
sbp2.c:(.text+0x36d8e0): undefined reference to `dma_map_single'
sbp2.c:(.text+0x36d8f6): undefined reference to `dma_mapping_error'
Add an explicit dependency on HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
do_posix_clock_monotonic_gettime() is a leftover from the initial
posix timer implementation which maps to ktime_get_ts()
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Link: http://lkml.kernel.org/r/20140611234607.351283464@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
At this time, majority of changes come from ASoC world while we got a
few new drivers in other places for FireWire and USB. There have been
lots of ASoC core cleanups / refactoring, but very little visible to
external users.
ASoC
- Support for specifying aux CODECs in DT
- Removal of the deprecated mux and enum macros
- More moves towards full componentisation
- Removal of some unused I/O code
- Lots of cleanups, fixes and enhancements to the davinci, Freescale,
Haswell and Realtek drivers
- Several drivers exposed directly in Kconfig for use with simple-card
- GPIO descriptor support for jacks
- More updates and fixes to the Freescale SSI, Intel and rsnd drivers
- New drivers for Cirrus CS42L56, Realtek RT5639, RT5642 and RT5651 and
ST STA350, Analog Devices ADAU1361, ADAU1381, ADAU1761 and ADAU1781,
and Realtek RT5677
HD-audio:
- Clean up Dell headset quirks
- Noise fixes for Dell and Sony laptops
- Thinkpad T440 dock fix
- Realtek codec updates (ALC293,ALC233,ALC3235)
- Tegra HD-audio HDMI support
FireWire-audio:
- FireWire audio stack enhancement (AMDTP, MIDI), support for incoming
isochronous stream and duplex streams with timestamp synchronization
- BeBoB-based devices support
- Fireworks-based device support
USB-audio:
- Behringer BCD2000 USB device support
Misc:
- Clean up of a few old drivers, atmel, fm801, etc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTjzW4AAoJEGwxgFQ9KSmkUrMP/1z43Kp+F9Y0v0VBH6oR/d4N
l9IyxBno/ABxfWloGFnRLEyzZyj2yG8A7inT0alVXJifHJN4iPOKBb5dPE9LMRvc
qLhJjMwznAirkuE8Wsk+IAoKuyXEI4m+KKEIXt5WJ3UyAo/j1lySZVMChzcTFFk/
oc2C6CciYrQLziaaL/K5zD9v9XdDr9koOaSHK/xjUOCbDlEBJu6T2IvRI/tkqJmy
8oRRhRteXZ9D959+ftntKrFVf10APQ4ZQbsX/pHboduaoozYAJSJGFhQNbh/UZnb
zwwwanNZvLwzn+rRXJJuzHF4jra34CuQFL2awsDP9Wck9E3YLmt4audNQ6LM6J8z
IVZs5IjMIL1ey1T2oRczLnv7EoDp0xdP38GqXnQ88j3zd+Ifi77idNw1ssU1aZ5B
LzEFEytT1UbEUkqom9qtIG+GId9hSmVmHQuLsc6Ayg7md0oBeJnBC05Xt5FATdrp
HseHYfSrNNDBFKyj8+j0TVtHc9Xf4SKziSVWz/PT0gaROzOsR2e46HC2Hvut+OFZ
rLLPXn9up5viQFxOTbO7sdYGCYa/iVH7IwB2oCP6Z5/I8+fhsU7aA4Hl+0wBikin
PDSwuchmRlNpHJ18YDonjzFtWA51wG4IlcNbQY4ywO/jFae06KYxQPTwvmJI0+oV
GXyKtjdBnQg8nnWJlS8J
=nxFA
-----END PGP SIGNATURE-----
Merge tag 'sound-3.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into next
Pull sound updates from Takashi Iwai:
"At this time, majority of changes come from ASoC world while we got a
few new drivers in other places for FireWire and USB. There have been
lots of ASoC core cleanups / refactoring, but very little visible to
external users.
ASoC:
- Support for specifying aux CODECs in DT
- Removal of the deprecated mux and enum macros
- More moves towards full componentisation
- Removal of some unused I/O code
- Lots of cleanups, fixes and enhancements to the davinci, Freescale,
Haswell and Realtek drivers
- Several drivers exposed directly in Kconfig for use with
simple-card
- GPIO descriptor support for jacks
- More updates and fixes to the Freescale SSI, Intel and rsnd drivers
- New drivers for Cirrus CS42L56, Realtek RT5639, RT5642 and RT5651
and ST STA350, Analog Devices ADAU1361, ADAU1381, ADAU1761 and
ADAU1781, and Realtek RT5677
HD-audio:
- Clean up Dell headset quirks
- Noise fixes for Dell and Sony laptops
- Thinkpad T440 dock fix
- Realtek codec updates (ALC293,ALC233,ALC3235)
- Tegra HD-audio HDMI support
FireWire-audio:
- FireWire audio stack enhancement (AMDTP, MIDI), support for
incoming isochronous stream and duplex streams with timestamp
synchronization
- BeBoB-based devices support
- Fireworks-based device support
USB-audio:
- Behringer BCD2000 USB device support
Misc:
- Clean up of a few old drivers, atmel, fm801, etc"
* tag 'sound-3.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (480 commits)
ASoC: Fix wrong argument for card remove callbacks
ASoC: free jack GPIOs before the sound card is freed
ALSA: firewire-lib: Remove a comment about restriction of asynchronous operation
ASoC: cache: Fix error code when not using ASoC level cache
ALSA: hda/realtek - Fix COEF widget NID for ALC260 replacer fixup
ALSA: hda/realtek - Correction of fixup codes for PB V7900 laptop
ALSA: firewire-lib: Use IEC 61883-6 compliant labels for Raw Audio data
ASoC: add RT5677 CODEC driver
ASoC: intel: The Baytrail/MAX98090 driver depends on I2C
ASoC: rt5640: Add the function "get_clk_info" to RL6231 shared support
ASoC: rt5640: Add the function of the PLL clock calculation to RL6231 shared support
ASoC: rt5640: Add RL6231 class device shared support for RT5640, RT5645 and RT5651
ASoC: cache: Fix possible ZERO_SIZE_PTR pointer dereferencing error.
ASoC: Add helper functions to cast from DAPM context to CODEC/platform
ALSA: bebob: sizeof() vs ARRAY_SIZE() typo
ASoC: wm9713: correct mono out PGA sources
ALSA: synth: emux: soundfont.c: Cleaning up memory leak
ASoC: fsl: Remove dependencies of boards for SND_SOC_EUKREA_TLV320
ASoC: fsl-ssi: Use regmap
ASoC: fsl-ssi: reorder and document fsl_ssi_private
...
One optimization for some VIA controllers, one fix, one kconfig brushup.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTjjgrAAoJEHnzb7JUXXnQK7wP/0SaXBk/sWSaxn0JM50xRv2e
90rt2V2QFrlEuk/kNOJHJIgMdIhl+z14caCMxNhXnlHVD6gPnLUAXPCLrf1Kth0R
kcpQ+nILuigMWm8GnyA1o/pr62J/gyF47xvceHqadkPEsESRT3allWe5kCtRLasT
FRBd/tAhcdtZlsbjZS8qsCbZeg6T38P2w3kHlvx7gTt87UTD1NkqJOwKhxcTAd3C
YK+T6XG9RsHJDv6mfQNp29RTQbkrkUewjoD62sqoDQkb1VgGnNanr1YlBvtwrrvl
MYAR6tsaH2fV9fb3ztM6iERuG3zLBsB6t5IImGL5R7AnAxQx4rDby0qmUVismrMA
AkDI1XDBoyhAcfF+1qPlCAvQOmbIoVo3BH428WREf33Nq4RV4lkTwKb+jq+RKOJ4
2Z5DdRrbiaimwChkbznk93tLAF4FiqzX8NI5BQnGHWB7ZD1LsteJRgcDRYu90Fxr
dR16y4mnbWTwPcxZprQcDMF5NH8KhAGkL7A1K0nbz5ZblDtBkbqwRdwZ6xhs/RSc
NBcnR+eMXp3KRLqN7qnD8lIon8EezW0tn46EBTkI+iGWd+mLR4FMu6spF2gcwOjM
tXF+YotZ08H5NHCVSKe2GudDedPjf/gPKJ6z2+bXrwtaXvtfLS8cNYK7jpTBfrq5
zR/2fhPPf4iCy5vuSwQY
=27Wn
-----END PGP SIGNATURE-----
Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 into next
Pull firewire updates from Stefan Richter:
"IEEE 1394 (FireWire) subsystem changes: One optimization for some VIA
controllers, one fix, one kconfig brushup"
* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: enable MSI for VIA VT6315 rev 1, drop cycle timer quirk
firewire: Use COMPILE_TEST for build testing
firewire: net: fix NULL derefencing in fwnet_probe()
Commit af0cdf4947 "firewire: ohci: fix regression with VIA VT6315,
disable MSI" acted upon a report against VT6315 rev 0:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02301.html
$ lspci -nn
VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403]
I now got a card with
$ lspci -nn
VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403] (rev 01)
and this works fine with MSI enabled.
Second, I tested this VT6315 rev 1 without CYCLE_TIMER quirk flag using
http://me.in-berlin.de/~s5r6/linux1394/utils/test_cycle_time_v20100125.c
and found that this chip does in fact access the cycle timer atomically.
Things I can't test because I don't have the hardware:
- whether VT6315 rev 0 really needs QUIRK_CYCLE_TIMER,
- whether the VT6320 PCI device needs QUIRK_CYCLE_TIMER,
- whether the VT6325 and VT6330 PCIe devices need QUIRK_CYCLE_TIMER
and QUIRK_NO_MSI.
Hence, just add a whitelist entry specifically for VT6315 rev >= 1
without any quirk flags. Before this entry we need an extra entry to
catch VT6315 rev <= 0 due to how our ID matching logic works.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Undo a feature introduced in v3.14 by commit fcd46b3442
"firewire: Enable remote DMA above 4 GB". That change raised the
minimum address at which protocol drivers and user programs can register
for request reception from 0x0001'0000'0000 to 0x8000'0000'0000.
It turned out that at least one vendor-specific protocol exists which
uses lower addresses: https://bugzilla.kernel.org/show_bug.cgi?id=76921
For the time being, revert most of commit fcd46b3442 so that affected
protocols work like with kernel v3.13 and before. Just keep the valid
documentation parts from the regressing commit, and the ability to
identify controllers which could be programmed to accept >32 bit
physical DMA addresses. The rest of fcd46b3442 should probably be
brought back as an optional instead of default feature.
Reported-by: Fabien Spindler <fabien.spindler@inria.fr>
Cc: <stable@vger.kernel.org> # 3.14+
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
In post commit, a quirk of this firmware about transactions is reported.
This commit apply a workaround for this quirk.
They often fail transactions due to gap_count mismatch. This state is changed
by generating bus reset.
The fw_schedule_bus_reset() is an exported symbol in firewire-core. But there
are no header for public. This commit moves its prototype from
drivers/firewire/core.h to include/linux/firewire.h.
This mismatch still affects bus management before generating this bus reset.
It still takes a time to call driver's probe() because transactions are still
often failed.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Stop using BROKEN as an alternative dependency for the purpose of
build testing the firewire core. The newly introduced COMPILE_TEST is
better suited for that purpose.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
"dev" and "net" are NULL when alloc_netdev() is failed.
So just unlock and return an error.
Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Pull workqueue fix from Tejun Heo:
"This pull request contains a workqueue usage fix for firewire.
For quite a long time now, workqueue only treats two work items
identical iff both their addresses and callbacks match. This is to
avoid introducing false dependency through the work item being
recycled while being executed. This changes non-reentrancy guarantee
for the users of PREPARE[_DELAYED]_WORK() - if the function changes,
reentrancy isn't guaranteed against the previous instance. Firewire
depended on such nonreentrancy guarantee.
This is fixed by doing the work item multiplexing from firewire proper
while keeping the work function unchanged"
* 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
firewire: don't use PREPARE_DELAYED_WORK
PREPARE_[DELAYED_]WORK() are being phased out. They have few users
and a nasty surprise in terms of reentrancy guarantee as workqueue
considers work items to be different if they don't have the same work
function.
firewire core-device and sbp2 have been been multiplexing work items
with multiple work functions. Introduce fw_device_workfn() and
sbp2_lu_workfn() which invoke fw_device->workfn and
sbp2_logical_unit->workfn respectively and always use the two
functions as the work functions and update the users to set the
->workfn fields instead of overriding work functions using
PREPARE_DELAYED_WORK().
This fixes a variety of possible regressions since a2c1c57be8
"workqueue: consider work function when searching for busy work items"
due to which fw_workqueue lost its required non-reentrancy property.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux1394-devel@lists.sourceforge.net
Cc: stable@vger.kernel.org # v3.9+
Cc: stable@vger.kernel.org # v3.8.2+
Cc: stable@vger.kernel.org # v3.4.60+
Cc: stable@vger.kernel.org # v3.2.40+
Since commit bd972688eb
"firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8",
there is a high chance that firewire-ohci fails to initialize LSI née
Agere controllers.
https://bugzilla.kernel.org/show_bug.cgi?id=65151
Peter Hurley points out the reason: IEEE 1394a:2000 clause 5A.1 (or
IEEE 1394:2008 clause 17.2.1) say: "The PHY shall insure that no more
than 10 ms elapse from the reassertion of LPS until the interface is
reset. The link shall not assert LReq until the reset is complete."
In other words, the link needs to give the PHY at least 10 ms to get
the interface operational.
With just the msleep(1) in bd972688eb, the first read_phy_reg()
during ohci_enable() may happen before the phy-link interface reset was
finished, and fail. Due to the high variability of msleep(n) with small
n, this failure was not fully reproducible, and not apparent at all with
low CONFIG_HZ setting.
On the other hand, Peter can no longer reproduce the issue with FW643
rev8. The read phy reg failures that happened back then may have had an
unrelated cause. So, just revert bd972688eb, except for the valid
comment on TSB82AA2 cards.
Reported-by: Mikhail Gavrilov
Reported-by: Jay Fenlason <fenlason@redhat.com>
Reported-by: Clemens Ladisch <clemens@ladisch.de>
Reported-by: Peter Hurley <peter@hurleysoftware.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Commit 8408dc1c14 "firewire: net: use dev_printk API" introduced a
use-after-free in a failure path. fwnet_transmit_packet_failed(ptask)
may free ptask, then the dev_err() call dereferenced it. The fix is
straightforward; simply reorder the two calls.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This makes all of a machine's memory accessible to remote debugging via
FireWire, using the physical response unit (i.e. RDMA) of OHCI-1394 link
layer controllers.
This requires actual support by the controller. The only ones currently
known to support it are Agere/LSI FW643. Most if not all other OHCI-1394
controllers do not implement the optional Physical Upper Bound register.
With them, RDMA will continue to be limited to the lowermost 4 GB.
firewire-ohci's startup message in the kernel log is augmented to tell
whether the controller does expose more than 4 GB to RDMA.
While OHCI-1394 allows for a maximum Physical Upper Bound of
0xffff'0000'0000 (near 256 TB), this implementation sets it to
0x8000'0000'0000 (128 TB) in order to avoid interference with applications
that require interrupt-served asynchronous request reception at
respectively low addresses.
Note, this change does not switch remote DMA on. It only increases the
range of remote access to all memory (instead of just 4 GB) whenever
remote DMA was switched on by other means. The latter is achieved by
setting firewire-ohci's remote_dma parameter, or if the physical DMA
filter is opened through firewire-sbp2.
Derived from patch "firewire: Enable physical DMA above 4GB" by
Peter Hurley <peter@hurleysoftware.com> from March 27, 2013.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This makes it possible to debug kernel over FireWire without the need to
recompile it.
[Stefan R: changed description from "...0" to "...N"]
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Commit 54b2b50c20 "[SCSI] Disable WRITE SAME for RAID and virtual
host adapter drivers" disabled WRITE SAME support for all SBP-2 attached
targets. But as described in the changelog of commit b0ea5f19d3
"firewire: sbp2: allow WRITE SAME and REPORT SUPPORTED OPERATION CODES",
it is not required to blacklist WRITE SAME.
Bring the feature back by reverting the sbp2.c hunk of commit 54b2b50c20.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: stable@kernel.org
Some host adapters do not pass commands through to the target disk
directly. Instead they provide an emulated target which may or may not
accurately report its capabilities. In some cases the physical device
characteristics are reported even when the host adapter is processing
commands on the device's behalf. This can lead to adapter firmware hangs
or excessive I/O errors.
This patch disables WRITE SAME for devices connected to host adapters
that provide an emulated target. Driver writers can disable WRITE SAME
by setting the no_write_same flag in the host adapter template.
[jejb: fix up rejections due to eh_deadline patch]
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: stable@kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Use this new function to make code more comprehensible, since we are
reinitialzing the completion, not initializing.
[akpm@linux-foundation.org: linux-next resyncs]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13)
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Put bus_reset_work into its own workqueue. By doing this, forward
progress of bus_reset_work() is guaranteed if the work is switched over
to a rescuer thread.
Switching work to a rescuer thread happens if a new worker thread could
not be allocated in certain time (MAYDAY_INITIAL_TIMEOUT, typically 10
ms). This might not be possible under high memory pressure or even on a
heavily loaded embedded system running a slow serial console.
The former deadlock occured in the following situation:
The rescuer thread ran
fw_device_init->read_config_rom->read_rom->fw_run_transaction.
fw_run_transaction blocked waiting for the completion object.
This completion object would have been completed in bus_reset_work,
but this work was never executed in the rescuer thread due to its
strictly sequential behaviour.
[Stefan R.: Removed WQ_NON_REENTRANT flag from allocation because
it is no longer needed in current kernels. Add it back if you backport
to kernels older than 3.7, i.e. one which does not contain dbf2576e37
"workqueue: make all workqueues non-reentrant". Swapped order of
destroy_workqueue and pci_unregister_driver.]
Signed-off-by: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This is a prerequisite to allocate a per driver self_id workqueue.
This reverts the ohci.c part of patch
fe2af11c22.
Signed-off-by: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
a) Sort device IDs by vendor -- device -- revision.
b) Write quirk flags in hexadecimal. This affects the user-visible
output of "modinfo firewire-ohci". Since more flags have been added
recently, it is now easier to cope with them in hexadecimal represen-
tation. Besides, the device-specific combination of quirk flags is
shown in hexadecimal in the kernel log too. (And firewire-sbp2
presents its own quirk flags in modinfo as hexadecimals as well.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
We have got
struct descriptor *descriptors;
dma_addr_t descriptors_bus;
dma_addr_t buffer_bus;
struct descriptor buffer[0];
void *misc_buffer;
dma_addr_t misc_buffer_bus;
__be32 *config_rom;
dma_addr_t config_rom_bus;
__be32 *next_config_rom;
dma_addr_t next_config_rom_bus;
But then we have got
__le32 *self_id_cpu;
dma_addr_t self_id_bus;
Better apply the pattern of xyz vs. xyz_bus to self_id vs. self_id_bus
as well. The _cpu suffix looks particularly weird in conversions from
little endian to CPU endian.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
An idr related patch introduced the following sparse warning:
drivers/firewire/core-cdev.c:488:33: warning: incorrect type in initializer (different base types)
drivers/firewire/core-cdev.c:488:33: expected bool [unsigned] [usertype] preload
drivers/firewire/core-cdev.c:488:33: got restricted gfp_t
So let's convert from gfp_t bitfield to Boolean explicitly and safely.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
dbf2576e37 ("workqueue: make all workqueues non-reentrant") made
WQ_NON_REENTRANT no-op and the flag is going away. Remove its usages.
This patch doesn't introduce any behavior changes.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Commit 18d627113b (firewire: prevent dropping of completed iso packet
header data) was intended to be an obvious bug fix, but libdc1394 and
FlyCap2 depend on the old behaviour by ignoring all returned information
and thus not noticing that not all packets have been received yet. The
result was that the video frame buffers would be saved before they
contained the correct data.
Reintroduce the old behaviour for old clients.
Tested-by: Stepan Salenikovich <stepan.salenikovich@gmail.com>
Tested-by: Josep Bosch <jep250@gmail.com>
Cc: <stable@vger.kernel.org> # 3.4+
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
After all IEEE 1394 high-level drivers being converted to bus-specific
.probe/.remove methods, remove support of the obsolete generic methods.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
FireWire upper layer drivers are converted from generic
struct driver.probe() and .remove()
to bus-specific
struct fw_driver.probe() and .remove().
The new .probe() adds a const struct ieee1394_device_id *id argument,
indicating the entry in the driver's device identifiers table which
matched the fw_unit to be probed. This new argument is used by the
snd-firewire-speakers driver to look up device-specific parameters and
methods. There is at least one other FireWire audio driver currently in
development in which this will be useful too.
The new .remove() drops the unused error return code.
Although all in-tree drivers are being converted to the new methods,
support for the old methods is left in place in this commit. This
allows public developer trees to merge this commit and then move to the
new fw_driver methods.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: Clemens Ladisch <clemens@ladisch.de> (for sound/firewire/)
Cc: Peter Hurley <peter@hurleysoftware.com> (for drivers/staging/fwserial/)
- fix controller removal when controller is in suspended state
- fix video reception on VIA VT6306 with gstreamer, MythTV, and maybe dv4l
- fix a startup issue with Agere/LSI FW643-e2
- error logging improvements and other small updates
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJRi5gtAAoJEHnzb7JUXXnQKnAP/0TzrfuDeUY5pyIUt4Ce9emt
8DGlMNRGSg6+VztSWQN23Heo9pvr3oWfQMtBcBsh6Jhj3ovXwXmpbhbledJxevJT
iVofTMc/pTRlAGaNv+cEszFkOrnH9nqqDYs9sK8hibgNu7tNbivmzyG+tF7OsIIp
aAjsFpTelKqgwo7LqTOLNvQoYx1HRTyQnp1OBa2gc76pXR1GLLuSjNlvh8b7ops5
FCt7gmfpEzJ6U/+AWTU/QBdXdXNRzle9rwZil3d1y80qfej7+V+lGRKzuVDaZHRY
C0t09SoYRop0m+UpnC3iXs5w0h09F4KKvRMfZ4m3sBmcRKYQeGkdKn2RRZn35hb9
D1Oa6NhXbYw4vzvQPRWzvDqrwyOXNce/wCysQXbkBnaB05ojYzchU5KGSnoQUiBD
G/TTLgmpiO4YPNxQgazeWesW+Y0gzd1alJvn6LPxRXTeRJLGZapYQxFZkJMkI2KU
0hjBblF2xxLnGjy0SpxOGQNiSo2Gg6vyRkqlSXu9kKpk6h7aAGPn0eIVxjaI/aJ9
qkqq7Qi2uPhn3y6SIO23/3tIULl+ws3+i9UzQEUtXlgFgowzOljbnkKnabjqIfl3
OjkD3mEn0njz6mXQGsCV7MTPlUvST9ysvPi5PbkevBeLCBx8F9fiuNGdGFBqCIUb
kHl3zh9YbyS4QtWRnpWb
=f8Yl
-----END PGP SIGNATURE-----
Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewure updates from Stefan Richter:
- fix controller removal when controller is in suspended state
- fix video reception on VIA VT6306 with gstreamer, MythTV, and maybe dv4l
- fix a startup issue with Agere/LSI FW643-e2
- error logging improvements and other small updates
* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: dump_stack() for PHY regs read/write failures
firewire: ohci: Improve bus reset error messages
firewire: ohci: Alias dev_* log functions
firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8
firewire: ohci: fix VIA VT6306 video reception
firewire: ohci: Check LPS before register access on pci removal
firewire: ohci: Fix double free_irq()
firewire: remove unnecessary alloc/OOM messages
firewire: sbp2: replace BUG_ON by WARN_ON
firewire: core: remove an always false test
firewire: Remove two unneeded checks for macros
A stack trace is an invaluable tool in determining the basis
and cause of PHY regs read/write failures.
Include PHY reg addr (and value for writes) in the diagnostic.
[Stefan R: changed whitespace]
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Many of the error messages possible from bus_reset_work() do not
contain enough information to distinguish which error condition
occurred nor enough information to evaluate the error afterwards.
Differentiate all error conditions in bus_reset_work(); add
additional information to make error diagnosis possible.
[Stefan R: fixed self-ID endian conversion]
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Convert dev_xxxx(ohci->card.device, ...) log functions to
ohci_xxxx(ohci, ...).
[Stefan R: Peter argues that this increases readability of the code.]
[Stefan R: changed whitespace]
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Add quirk for VT6306 wake bit behavior.
VT6306 seems to reread the wrong descriptor when the wake bit is
written. work around by putting a copy of the branch address in the
first descriptor of the block.
[Stefan R: This fixes the known broken video reception via gstreamer
on VIA VT6306. 100% repeatable testcase:
$ gst-launch-0.10 dv1394src \! dvdemux \! dvdec \! xvimagesink
with a camcorder or other DV source connected. Likewise for MPEG2-TS
reception via gstreamer, e.g. from TV settop boxes.
Perhaps this also fixes dv4l on VT6306, but this is as yet untested.
Kino, dvgrab or FFADO had not been affected by this chip quirk.
Additional comments from Andy:]
I've looked into some problems with the wake bit on a vt6306 family
chip (1106:3044, rev 46).
I used this firewire card in a mythtv setup (ISO receive MPEG2 stream)
with Debian 2.6.32 kernels for ~2 years without problems.
Since upgrading to 3.2, I've been having problems with the input stream
freezing -- input data stops until I restart mythtv (I expect closing
and reopening the device would be sufficient). This happens
infrequently, maybe one out of 20 recordings. I eventually determined
that the problem is more likely to occur if the system is loaded.
I isolated the kernel version as the triggering SW factor and then
specifically the change from dualbuffer back to packet-per-buffer DMA
mode.
The possibility that the controller does not properly respond to the
wake bit was suggested in
https://bugzilla.redhat.com/show_bug.cgi?id=415841, but not proven.
Based on the fact that dualbuffer mode worked while packet-per-buffer
has trouble, I guessed that upon seeing the wake bit written, the vt6306
controller only checks the branch address in the first descriptor of the
block, even if that is not the correct place to look (because the block
has multiple descriptors).
This theory seems to be correct. When the ISO reception is hung, I am
able to resume it by manually writing the branch address to the first
descriptor in the block, and then writing the wake bit.
I've had luck so far with the attached patch, so I'm including it. It's
probably not a complete solution -- I haven't tested transmit modes to
see whether they have a similar issue.
I doubt that the quirk test is any cheaper than just writing the extra
branch address in all cases, but it does reduce the risk of breaking
other hardware.
[Stefan R: omitted QUIRK_NO_MSI from VT6306 quirks table entry,
changed whitespace]
Signed-off-by: Andy Leiserson <andy@leiserson.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
A pci device can be removed while in its suspended state. If the ohci
host controller is suspended, the PHY is also in low-power mode and
LPS is disabled. If LPS is disabled, most of the host registers aren't
accessible, including IntMaskClear. Furthermore, access to these registers
when LPS is disabled can cause hard lockups on some hardware. Since
interrupts are already disabled in this mode, further action is
unnecessary.
Test LPS before attempting to write IntMaskClear to disable interrupts.
[Stefan R: whitespace changes]
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
A pci device can be removed while in its suspended state.
Because the ohci driver freed the irq to suspend, free_irq() is
called twice; once from pci_remove() and again from pci_suspend(),
which issues the warning below [1].
Rather than allocate the irq in the .enable() path, move the
allocation to .probe(). Consequently, the irq is not reallocated
upon pci_resume() and thus is not freed upon pci_suspend().
[1] Warning reported by Mark Einon <mark.einon@gmail.com> when
suspending an MSI MS-1727 GT740 laptop on Ubuntu 3.5.0-22-generic
WARNING: at ./kernel/irq/manage.c:1198 __free_irq+0xa3/0x1e0()
Hardware name: MS-1727
Trying to free already-free IRQ 16
Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables <...snip...>
Pid: 4, comm: kworker/0:0 Tainted: P O 3.5.0-22-generic #34-Ubuntu
Call Trace:
[<ffffffff81051c1f>] warn_slowpath_common+0x7f/0xc0
[<ffffffff81051d16>] warn_slowpath_fmt+0x46/0x50
[<ffffffff8103fa39>] ? default_spin_lock_flags+0x9/0x10
[<ffffffff810df6b3>] __free_irq+0xa3/0x1e0
[<ffffffff810df844>] free_irq+0x54/0xc0
[<ffffffffa005a27e>] pci_remove+0x6e/0x210 [firewire_ohci]
[<ffffffff8135ae7f>] pci_device_remove+0x3f/0x110
[<ffffffff8141fdbc>] __device_release_driver+0x7c/0xe0
[<ffffffff8141fe4c>] device_release_driver+0x2c/0x40
[<ffffffff8141f5f1>] bus_remove_device+0xe1/0x120
[<ffffffff8141cd1a>] device_del+0x12a/0x1c0
[<ffffffff8141cdc6>] device_unregister+0x16/0x30
[<ffffffff81354784>] pci_stop_bus_device+0x94/0xa0
[<ffffffffa0091c67>] acpiphp_disable_slot+0xb7/0x1a0 [acpiphp]
[<ffffffffa0090716>] ? get_slot_status+0x46/0xc0 [acpiphp]
[<ffffffffa0091d7d>] acpiphp_check_bridge.isra.15+0x2d/0xf0 [acpiphp]
[<ffffffffa0092442>] _handle_hotplug_event_bridge+0x372/0x4d0 [acpiphp]
[<ffffffff81390f8c>] ? acpi_os_execute_deferred+0x2f/0x34
[<ffffffff8116e22d>] ? kfree+0xed/0x110
[<ffffffff8107086a>] process_one_work+0x12a/0x420
[<ffffffffa00920d0>] ? _handle_hotplug_event_func+0x1d0/0x1d0 [acpiphp]
[<ffffffff8107141e>] worker_thread+0x12e/0x2f0
[<ffffffff810712f0>] ? manage_workers.isra.26+0x200/0x200
[<ffffffff81075f13>] kthread+0x93/0xa0
[<ffffffff8168d024>] kernel_thread_helper+0x4/0x10
[<ffffffff81075e80>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff8168d020>] ? gs_change+0x13/0x13
Reported-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Christoph Hellwig