- 06 Feb, 2014 40 commits
-
-
Roberto Sassu authored
commit c502c78b upstream. Replace HASH_ALGO__LAST with HASH_ALGO_SHA1 as the initial value of the hash algorithm so that the prefix 'sha1:' is added to violation digests. Fix commit: 4d7aeee ima: define new template ima-ng and template fields d-ng and n-ng Signed-off-by:
Roberto Sassu <roberto.sassu@polito.it> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Huewe authored
commit 747d35bd upstream. Depending on the implementation strcmp might return the difference between two strings not only -1,0,1 consequently if (strcmp (a,b) == -1) might lead to taking the wrong branch -> compare with < 0 instead, which in any case is more canonical. Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
-
Peter Huewe authored
commit 85c5e0d4 upstream. The 'get_burstcount' function can in some circumstances 'return -EBUSY' which in tpm_stm_i2c_send is stored in an 'u32 burstcnt' thus converting the signed value into an unsigned value, resulting in 'burstcnt' being huge. Changing the type to u32 only does not solve the problem as the signed value is converted to an unsigned in I2C_WRITE_DATA, resulting in the same effect. Thus -> Change type of burstcnt to u32 (the return type of get_burstcount) -> Add a check for the return value of 'get_burstcount' and propagate a potential error. This makes also sense in the 'I2C_READ_DATA' case, where the there is no signed/unsigned conversion. found by coverity Signed-off-by:
-
Stephen Warren authored
commit 75fae117 upstream. Commit 384a48d7 "ALSA: hda: HDMI: Support codecs with fewer cvts than pins" dynamically enabled each pin widget's PIN_OUT only when the pin was actively in use. This was required on certain NVIDIA CODECs for correct operation. Specifically, if multiple pin widgets each had their mux input select the same audio converter widget and each pin widget had PIN_OUT enabled, then only one of the pin widgets would actually receive the audio, and often not the one the user wanted! However, this apparently broke some Intel systems, and commit 6169b673 "ALSA: hda - Always turn on pins for HDMI/DP" reverted the dynamic setting of PIN_OUT. This in turn broke the afore-mentioned NVIDIA CODECs. This change supports either dynamic or static handling of PIN_OUT, selected by a flag set up during CODEC initialization. This flag is enabled for all recent NVIDIA GPUs. Reported-by:
Uosis <uosisl@gmail.com> Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Hui Wang authored
commit 5e87d580 upstream. When we plug a 3-ring headset on the Dell machine (Vendor ID: 0x10ec0255, Subsystem ID: 0x1028064d), the headset mic can't be detected, after apply this patch, the headset mic can work well. BugLink: https://bugs.launchpad.net/bugs/1260303 Cc: David Henningsson <david.henningsson@canonical.com> Tested-by:
Doro Wu <fan-cheng.wu@canonical.com> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
Adrien Vergé authored
commit e7729a41 upstream. Similarly to other Apple products, MBA 1,1 needs a specific quirk. Pin 0x18 must be set to VREF_50 to have sound output. This was no longer done since commit 1a97b7f2, resulting in a mute built-in speaker. This patch corrects the regression by creating a fixup for the MBA 1,1. Fixes: 1a97b7f2 ("ALSA: hda/realtek - Remove the last static quirks for ALC882") Tested-by:
Adrien Vergé <adrienverge@gmail.com> Signed-off-by:
-
Dan Carpenter authored
commit 4c3773ed upstream. The test here is intended intended to prevent shift wrapping bugs when we do "1U << idx2". We should consider the number of bits in a u32 instead of the number of bytes. [fix another chunk similarly by tiwai] Fixes: 7bb2491b ('ALSA: Add kconfig to specify the max card numbers') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Hui Wang authored
commit c48ae0ab upstream. When we plug a 3-ring headset on some Dell machines, the headset mic can't be detected, after apply this patch, the headset mic can work well on all those machines. On the machine with the Subsytem ID 0x10280610, if we use ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, the headset mic can be detected and work well, but the sound can't be outputed via headphone anymore, use ALC269_FIXUP_DELL3_MIC_NO_PRESENCE can fix this problem. BugLink: https://bugs.launchpad.net/bugs/1260303 Cc: David Henningsson <david.henningsson@canonical.com> Tested-by:
David Chen <david.chen@canonical.com> Tested-by:
Cyrus Lien <cyrus.lien@canonical.com> Tested-by:
Shawn Wang <shawn.wang@canonical.com> Tested-by:
Chih-Hsyuan Ho <chih.ho@canonical.com> Signed-off-by:
-
Hui Wang authored
commit 493a52a9 upstream. On some AIO (All In One) models with the codec alc668 (Vendor ID: 0x10ec0668) on it, when we plug a headphone into the jack, the system will switch the output to headphone and set the speaker to automute as well as change the speaker Pin-ctls from 0x40 to 0x00, this will bring loud noise to the headphone. I tried to disable the corresponding EAPD, but it did not help to eliminate the noise. According to Takashi's suggestion, we use amp operation to replace the pinctl modification for the automute, this really eliminate the noise. BugLink: https://bugs.launchpad.net/bugs/1268468 Cc: David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Takashi Iwai authored
commit 80ab8eae upstream. The PCI devices with DMA masks smaller than 32bit should enable CONFIG_ZONE_DMA. Since the recent change of page allocator, page allocations via dma_alloc_coherent() with the limited DMA mask bits may fail more frequently, ended up with no available buffers, when CONFIG_ZONE_DMA isn't enabled. With CONFIG_ZONE_DMA, the system has much more chance to obtain such pages. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68221Signed-off-by:
-
Takashi Iwai authored
commit 43a8e50a upstream. AD1986A mic pins (0x1d and 0x1f) share the same widget for controlling the loopback volume/mute, but the generic parser didn't check it. This ended up with the duplicated controls for the same effect. This patch adds the check of the duplication for avoiding it. After this fix, there will be only one control although it affects both paths; this remaining issue should be fixed later in a different patch. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621Signed-off-by:
-
Takashi Iwai authored
commit ed0e0d06 upstream. The 3stack pin configs for AD1986A codec had incorrect values that resulted in broken mic and line-in. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621Signed-off-by:
-
Takashi Iwai authored
commit 770bd4bf upstream. The lack of comma leads to the wrong channel for an SPDIF channel. Unfortunately this wasn't caught by compiler because it's still a valid expression. Reported-by:
Alexander Aristov <aristov.alexander@gmail.com> Signed-off-by:
-
Charles Keepax authored
commit 34354792 upstream. Latest evaluation of the the device has given some patch file additions for improved performance. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Markus Pargmann authored
commit e8e08c52 upstream. range_min is the lowest address in the virtual register range. This is the first register with address 0, not the first register of page 1. Currently all writes to page 1 are mapped to page 0, so the codec fails to operate. Fixes: 4d208ca4 (ASoC: tlv320aic32x4: Convert to direct regmap API usage) Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
-
Markus Pargmann authored
commit 6d0d5103 upstream. This codec driver fails to probe because it has a higher regmap range_max value than max_register. This patch sets the range_max to the max_register value as described in the for struct regmap_range_cfg: "@range_max: Address of the highest register in virtual range." Fixes: 4d208ca4 (ASoC: tlv320aic32x4: Convert to direct regmap API usage) Signed-off-by:
-
Lars-Peter Clausen authored
commit e20970ad upstream. The driver defines ADAU1701_SEROCTL_WORD_LEN_16 as 0x10 while it should be b10, so 0x2. This patch fixes it. Reported-by:
Magnus Reftel <magnus.reftel@lockless.no> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 74142ffc upstream. The regmap used by max77686 MFD driver was not freed with regmap_exit() on driver exit. This lead to leak of resources. Replace regmap_init_i2c() call in driver probe with initialization of managed register map so the regmap will be properly freed by the device management code. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Dongsheng Yang authored
commit ad85ace0 upstream. Currently, if we use perf kvm --guestkallsyms --guestmodules report, we can not get the perf information from perf data file. All sample are shown as unknown. Reproducing steps: # perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules record -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.624 MB perf.data.guest (~27260 samples) ] # perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules report |grep % 100.00% [guest/6471] [unknown] [g] 0xffffffff8164f330 This bug was introduced by 207b5792 (perf kvm: Fix regression with guest machine creation). In original code, it uses perf_session__find_machine(), it means we deliver symbol to machine which has the same pid, if no machine found, deliver it to *default* guest. But if we use perf_session__findnew_machine() here, if no machine was found, new machine with pid will be built and added. Then the default guest which with pid == 0 will never get a symbol. And because the new machine initialized here has no kernel map created, the symbol delivered to it will be marked as "unknown". This patch here is to revert commit 207b5792 and fix the SEGFAULT bug in another way. Verification steps: # ./perf kvm --guestkallsyms /home/kallsyms --guestmodules /home/modules record -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.651 MB perf.data.guest (~28437 samples) ] # ./perf kvm --guestkallsyms /home/kallsyms --guestmodules /home/modules report |grep % 22.64% :6471 [guest.kernel.kallsyms] [g] update_rq_clock.part.70 19.99% :6471 [guest.kernel.kallsyms] [g] d_free 18.46% :6471 [guest.kernel.kallsyms] [g] bio_phys_segments 16.25% :6471 [guest.kernel.kallsyms] [g] dequeue_task 12.78% :6471 [guest.kernel.kallsyms] [g] __switch_to 7.91% :6471 [guest.kernel.kallsyms] [g] scheduler_tick 1.75% :6471 [guest.kernel.kallsyms] [g] native_apic_mem_write 0.21% :6471 [guest.kernel.kallsyms] [g] apic_timer_interrupt Signed-off-by:
Dongsheng Yang <yangds.fnst@cn.fujitsu.com> Acked-by:
David Ahern <dsahern@gmail.com> Cc: David Ahern <dsahern@gmail.com> Link: http://lkml.kernel.org/r/1387564907-3045-1-git-send-email-yangds.fnst@cn.fujitsu.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Chen-Yu Tsai authored
commit fa8cf57c upstream. Some GPIO users, such as fixed-regulator, request GPIO output with initial value of 1. This was ignored by sunxi driver. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Dasaratharaman Chandramouli authored
commit df5e4e8b upstream. The interrupt handler (mic_interrupt), called in the MSI/INTx mode, writes to the interrupt sources register to acknowledge the interrupt and then calls the corresponding callback handlers to handle the same. These callback handlers acknowledge the interrupts again leading to missed interrupts. This patch fixes the issue by removing the interrupt acknowlegment code from the callback handlers. Reviewed-by:
Sudeep Dutt <sudeep.dutt@intel.com> Reviewed-by:
Nikhil Rao <nikhil.rao@intel.com> Reviewed-by:
Siva Krishna Kumar Reddy Yerramreddy <siva.krishna.kumar.reddy.yerramreddy@intel.com> Signed-off-by:
Dasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com> Signed-off-by:
-
Stephen Warren authored
commit 75ea799d upstream. The current MAX8907 driver has two issues related to weekday value handling: 1) The HW WEEKDAY register has range 0..6 rather than 1..7 as documented. Note that I validated the actual HW range by observing the HW register roll from 6->0 rather than 6->7->1 as would otherwise be expected. This matches Linux's tm_wday range of 0..6. When the CMOS RAM content is lost, the date returned from the device is 2007-01-01 00:00:00, which is a Monday. The WEEKDAY register reads 1 in this case. This matches the numbering in Linux's tm_wday field. Hence we should write Linux's tm_wday value to the register without modifying it. Hence, remove the +1/-1 calculations for WEEKDAY/tm_wday. 2) There's no need to make alarms match on the WEEKDAY register, since the other fields together uniquely define the alarm date/time. Ignoring the WEEKDAY value in the match isolates the driver from any incorrect value in the current time copy of the WEEKDAY register. Each change individually, or both together, solves an issue that I observed; "hwclock -r" would time out waiting for its alarm to fire if the CMOS RAM content had been lost, and hence the WEEKDAY register value mismatched what the driver expected it to be. "hwclock -w" would solve this by over-writing the HW default WEEKDAY register value with what the driver expected. Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit d6a48452 upstream. In commit 85747f ("PATCH] parport: add NetMOS 9805 support") Max added the PCI ID for NetMOS 9805 based on a Debian bug report from 2k4 which was at the v2.4.26 time frame. The patch made into 2.6.14. Shortly before that patch akpm merged commit 296d3c78 ("[PATCH] Support NetMOS based PCI cards providing serial and parallel ports") which made into v2.6.9-rc1. Now we have two different entries for the same PCI id. I have here the NetMos 9805 which claims to support SPP/EPP/ECP mode. This patch takes Max's entry for titan_1284p1 (base != -1 specifies the ioport for ECP mode) and replaces akpm's entry for netmos_9805 which specified -1 (=none). Both share the same PCI-ID (my card has subsystem 0x1000 / 0x0020 so it should match PCI_ANY). While here I also drop the entry for titan_1284p2 which is the same as netmos_9815. Cc: Maximilian Attems <maks@stro.at> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Heiko Carstens authored
commit 4e078146 upstream. With b8668fd0 "s390/uapi: change struct statfs[64] member types to unsigned values" the size of a couple of struct statfs64 member got incorrectly changed from 64 to 32 bit for 32 bit builds. Fix this by changing the type of couple of struct statfs64 members from unsigned long to unsigned long long. The definition of struct compat_statfs64 was correct however. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Dominik Dingel authored
commit ff1f3cb4 upstream. The diagnose 500 subcode 3 contains the 32 bit subchannel id in bits 32-63 (counting from the left). As for other I/O instructions, bits 0-31 should be ignored and thus not be passed to kvm_io_bus_write_cookie(). This fixes a bug where the guest passed non-zero bits 0-31 which the host tried to interpret, leading to ioeventfd notification failures. Signed-off-by:
Dominik Dingel <dingel@linux.vnet.ibm.com> Reviewed-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
commit 743db27c upstream. The diagnose code to be used is the contents of the base register (if not zero), plus the displacement. The current code ignores the base register contents. So let's fix that... Reviewed-by:
-
Thomas Huth authored
commit e879892c upstream. The SIGP order STOP_AND_STORE_STATUS is defined to stop a CPU and store its status. However, we only stored the status if the CPU was still running, so make sure that the status is now also stored if the CPU was already stopped. This fixes the problem that the CPU information was not stored correctly in kdump files, rendering them unreadable. Signed-off-by:
Thomas Huth <thuth@linux.vnet.ibm.com> Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
commit 075dfd82 upstream. PSW32_USER_BITS should define the primary address space for user space instead of the home address space. Symptom of this bug is that gdb doesn't work in compat mode. The bug was introduced with e258d719 "s390/uaccess: always run the kernel in home space" and f26946d7 "s390/compat: make psw32_user_bits a constant value again". Reported-by:
Andreas Arnez <arnez@linux.vnet.ibm.com> Signed-off-by:
-
Stephen Warren authored
commit 3685f19e upstream. Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have their MODEM-control signals tied off to a static state. However UARTs A and B can optionally route those signals to/from package pins, depending on the exact pinmux configuration. When these signals are not routed to package pins, false interrupts may trigger either temporarily, or permanently, all while not showing up in the IIR; it will read as NO_INT. This will eventually lead to the UART IRQ being disabled due to unhandled interrupts. When this happens, the kernel may print e.g.: irq 68: nobody cared (try booting with the "irqpoll" option) In order to prevent this, enable UART_BUG_NOMSR. This prevents UART_IER_MSI from being enabled, which prevents the false interrupts from triggering. In practice, this is not needed under any of the following conditions: * On Tegra chips after Tegra30, since the HW bug has apparently been fixed. * On UARTs C..E since their MODEM control signals are tied to the correct static state which doesn't trigger the issue. * On UARTs A..B if the MODEM control signals are routed out to package pins, since they will then carry valid signals. However, we ignore these exceptions for now, since they are only relevant if a board actually hooks up more than a 4-wire UART, and no currently supported board does this. If we ever support a board that does, we can refine the algorithm that enables UART_BUG_NOMSR to take those exceptions into account, and/or read a flag from DT/... that indicates that the board has hooked up and pinmux'd more than a 4-wire UART. Reported-by: Olof Johansson <olof@lixom.net> # autotester Signed-off-by:
-
Jonathan Woithe authored
commit 9c5320f8 upstream. Fix the initialisation of older Quatech serial cards which are fitted with the AMCC PCI Matchmaker interface chip. Signed-off-by: Jonathan Woithe (jwoithe@just42.net) Signed-off-by:
-
Yegor Yefremov authored
commit 48c0247d upstream. Signed-off-by:
Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by:
-
Aaro Koskinen authored
commit 632fefaf upstream. Commit e6789cd3 (uio: Simplify uio error path by using devres functions) converted uio to use devm_request_irq(). This introduced a change in behaviour since the IRQ is associated with the parent device instead of the created UIO device. The IRQ will remain active after uio_unregister_device() is called, and some drivers will crash because of this. The patch fixes this. Signed-off-by:
Aaro Koskinen <aaro.koskinen@nsn.com> Signed-off-by:
-
Sarah Sharp authored
commit f2d9b991 upstream. Commit 35773dac "usb: xhci: Link TRB must not occur within a USB payload burst" attempted to fix an issue found with USB ethernet adapters, and inadvertently broke USB storage devices. The patch attempts to ensure that transfers never span a segment, and rejects transfers that have more than 63 entries (or possibly less, if some entries cross 64KB boundaries). usb-storage limits the maximum transfer size to 120K, and we had assumed the block layer would pass a scatter-gather list of 4K entries, resulting in no more than 31 sglist entries: http://marc.info/?l=linux-usb&m=138498190419312&w=2 That assumption was wrong, since we've seen the driver reject a write that was 218 sectors long (of probably 512 bytes each): Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd 0000:00:14.0: Too many fragments 79, max 63 ... Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00 00 da 00 Limit the number of scatter-gather entries to half a ring segment. That should be margin enough in case some entries cross 64KB boundaries. Increase the number of TRBs per segment from 64 to 256, which should result in ring segments fitting on a 4K page. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: jidanni@jidanni.org References: http://bugs.debian.org/733907 Fixes: 35773dac ('usb: xhci: Link TRB must not occur within a USB payload burst') Signed-off-by:
-
Ben Hutchings authored
commit d6c9ea90 upstream. Currently prepare_ring() returns -ENOMEM if the urb won't fit into a single ring segment. usb_sg_wait() treats this error as a temporary condition and will keep retrying until something else goes wrong. The number of retries should be limited in usb_sg_wait(), but also prepare_ring() should not return an error code that suggests it might be worth retrying. Change it to -EINVAL. Reported-by: jidanni@jidanni.org References: http://bugs.debian.org/733907 Fixes: 35773dac ('usb: xhci: Link TRB must not occur within a USB payload burst') Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Phil Pokorny authored
commit d303b1b5 upstream. Add new PCI ID to support new model "Kaveri" family. Signed-off-by:
Philip Pokorny <ppokorny@penguincomputing.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Jean-Jacques Hiblot authored
commit 1588c51c upstream. There was a copy/paste error when reading the nwe_pulse value. Signed-off-by:
Jean-Jacques Hiblot <jjhiblot@traphandler.com> Acked-by:
Boris BREZILLON <b.brezillon@overkiz.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
-
Ludovic Desroches authored
commit 0645b93f upstream. pinctrl-names property was missing from mmc nodes. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
-
Marek Roszko authored
commit 8bc661bf upstream. The uart timer will schedule a tasklet when it fires. It is possible that it can fire inside _shutdown before it is killed in the dma and pdc cleanup routines. This causes a tasklet that exists after the port is shutdown, so when the kernel finally executes it, it panics as the tty port is NULL. This is a somewhat rare condition but its possible if a program keeps on opening/closing the port. It has been observed in particular with systemd boot messages that were causing a kernel panic because of this behavior. Moving the timer deletion to the beginning of the function stops a tasklet from being scheduled unexpectedly. Signed-off-by:
Marek Roszko <mark.roszko@gmail.com> [nicolas.ferre@atmel.com: modify commit message, call setup_timer() in any case] Signed-off-by:
-
Mark Deneen authored
commit bb7e73c5 upstream. When using RX DMA, the driver won't pass any data to the uart layer until the buffer is flipped. When the port is shutdown, the dma buffers are unmapped, but the head and tail of the ring buffer are not reseted. Since the serial console will keep the port open, this will only present itself when the uart is not shared. To reproduce the issue, with an unpatched driver, run a getty on /dev/ttyS0 with no serial console and exit. Getty will exit, and when the new one returns you will be unable to log in. If you hold down a key long enough to fill the DMA buffer and flip it, you can then log in. Signed-off-by:
Mark Deneen <mdeneen@gmail.com> Acked-by:
Leilei Zhao <leilei.zhao@atmel.com> [nicolas.ferre@atmel.com: adapt to mainline kernel, handle !DMA case] Signed-off-by:
-
Marek Roszko authored
commit f50c995f upstream. The _remove callback could be called when a tasklet is scheduled. tasklet_kill was called inside the function in order to free up any scheduled tasklets. However it was called after uart_remove_one_port which destroys tty references needed in the port for atmel_tasklet_func. Simply putting the tasklet_kill at the start of the function will prevent this conflict. Signed-off-by:
-
