| Age | Commit message (Collapse) | Author |
|---|
|
Reduce duplicated code by unifying
BPF_ALU | BPF_MOD | BPF_X and BPF_ALU | BPF_DIV | BPF_X
CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
CC: Daniel Borkmann<dborkman@redhat.com>
CC: Philippe Bergheaud<felix@linux.vnet.ibm.com>
Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
A misspelled 'arbitrary' propagated to quite a few locations in the DT
binding documentation for pin-controllers. Fixing by:
git grep abitrary | cut -f1 -d: | xargs sed -i 's/abitrary/arbitrary/'
Reported-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
This patch is used to add vendor prefix for Micron Technology, Inc. in
the vendor-prefixes.txt file.
Micron Technology, Inc. is an American multinational corporation based
in Boise, Idaho, best known for producing many forms of semiconductor
devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs.
Signed-off-by: Bean Huo <bpqw@micron.com>
[robh: cleanup commit msg formatting and company name]
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Chips&Media is a developer of Video Codec IP cores.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
[robh: fix-up alphabetical ordering]
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
We have a historical hack that treats missing ranges properties as the
equivalent of an empty one. This is needed for ancient PowerMac "bad"
device-trees, and shouldn't be enabled for any other PowerPC platform,
otherwise we get some nasty layout of devices in sysfs or even
duplication when a set of otherwise identically named devices is
created multiple times under a different parent node with no ranges
property.
This fix is needed for the PowerNV i2c busses to be exposed properly
and will fix a number of other embedded cases.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
__earlycon_of_table_sentinel.compatible is a char[128], not a pointer, so
it will never be NULL. Checking it against NULL causes the match loop to
run past the end of the array, and eventually match a bogus entry, under
the following conditions:
- Kernel command line specifies "earlycon" with no parameters
- DT has a stdout-path pointing to a UART node
- The UART driver doesn't use OF_EARLYCON_DECLARE (or maybe the console
driver is compiled out)
Fix this by checking to see if match->compatible is a non-empty string.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Cc: <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
a9ecdc0fdc54 ("of/irq: Fix lookup to use 'interrupts-extended' property
first") updated the description to say that:
- Both 'interrupts' and 'interrupts-extended' may be present
- Software should prefer 'interrupts-extended'
- Software that doesn't comprehend 'interrupts-extended' may use
'interrupts'
But there is still a paragraph at the end that prohibits having both and
says 'interrupts' should be preferred.
Remove the contradictory text.
Fixes: a9ecdc0fdc54 ("of/irq: Fix lookup to use 'interrupts-extended' property first")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.13+
Acked-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
When building with the Gold linker, the .bss and .brk areas of vmlinux
are shown as consecutive instead of having the same file offset. Allow
for either state, as long as things add up correctly.
Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Junjie Mao <eternal.n08@gmail.com>
Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
When setting up permissions on kernel memory at boot, the end of the
PMD that was split from bss remained executable. It should be NX like
the rest. This performs a PMD alignment instead of a PAGE alignment to
get the correct span of memory.
Before:
---[ High Kernel Mapping ]---
...
0xffffffff8202d000-0xffffffff82200000 1868K RW GLB NX pte
0xffffffff82200000-0xffffffff82c00000 10M RW PSE GLB NX pmd
0xffffffff82c00000-0xffffffff82df5000 2004K RW GLB NX pte
0xffffffff82df5000-0xffffffff82e00000 44K RW GLB x pte
0xffffffff82e00000-0xffffffffc0000000 978M pmd
After:
---[ High Kernel Mapping ]---
...
0xffffffff8202d000-0xffffffff82200000 1868K RW GLB NX pte
0xffffffff82200000-0xffffffff82e00000 12M RW PSE GLB NX pmd
0xffffffff82e00000-0xffffffffc0000000 978M pmd
[ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
We really should unmap the reminder along with the holes
caused by init,initdata etc. but thats a different issue ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
In the situation when we apply early microcode but do *not* apply late
microcode, we fail to update the BSP's microcode on resume because we
haven't initialized the uci->mc microcode pointer. So, in order to
alleviate that, we go and dig out the stashed microcode patch during
early boot. It is basically the same thing that is done on the APs early
during boot so do that too here.
Tested-by: alex.schnaidt@gmail.com
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: <stable@vger.kernel.org> # v3.9
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Add sandisk to the list of vendors. This prefix should be used
also for companies absorbed by Sandisk, like M-Systems.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Use common can_change_mtu function.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
Use common can_change_mtu function.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
The variable err was of the type u32. It was being compared with < 0, and being
an unsigned variable the comparison would have been always false.
Moreover, err was getting the return value from set_reset_mode() and
xcan_set_bittiming(), and both are returning int.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
these variable were only assigned some values, but then never
reused again.
so they are safe to be removed.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
commit 8c328a262f ("spi: sirf: Avoid duplicate code in various
bits_per_word cases") is wrong in setting data width register of
fifo is not right, it should use sspi->word_width >> 1 to set
related bits. According to hardware spec, the mapping between
register value and data width:
0 - byte
1 - WORD
2 - DWORD
Fixes: 8c328a262f ("spi: sirf: Avoid duplicate code in various bits_per_word cases") is wrong in setting data width register of
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
the missing deallocation.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
The CAN device drivers can use can_is_canfd_skb() to check if the frame to send
is on CAN FD mode or normal CAN mode.
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
This patch fixes a typo in CAN's dev.c:
CIA -> CiA
which stands for CAN in Automation.
Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
Error) interrupt, which triggers the folloing warning:
[ 1153.360705] ------------[ cut here ]------------
[ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
[ 1153.360772] Call Trace:
[ 1153.360778] [<c167906f>] dump_stack+0x41/0x52
[ 1153.360782] [<c105bb7e>] warn_slowpath_common+0x7e/0xa0
[ 1153.360784] [<c158b909>] ? skb_release_head_state+0xb9/0xd0
[ 1153.360786] [<c158b909>] ? skb_release_head_state+0xb9/0xd0
[ 1153.360788] [<c105bc42>] warn_slowpath_null+0x22/0x30
[ 1153.360791] [<c158b909>] skb_release_head_state+0xb9/0xd0
[ 1153.360793] [<c158be90>] skb_release_all+0x10/0x30
[ 1153.360795] [<c158bf06>] kfree_skb+0x36/0x80
[ 1153.360799] [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360802] [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360805] [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
[ 1153.360809] [<c10a75b5>] handle_irq_event_percpu+0x35/0x180
[ 1153.360811] [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
[ 1153.360813] [<c10a7731>] handle_irq_event+0x31/0x50
[ 1153.360816] [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
[ 1153.360818] [<c10a9c10>] ? handle_edge_irq+0x110/0x110
[ 1153.360822] [<c1011b61>] handle_irq+0x71/0x90
[ 1153.360823] <IRQ> [<c168152c>] do_IRQ+0x3c/0xd0
[ 1153.360829] [<c1680b6c>] common_interrupt+0x2c/0x34
[ 1153.360834] [<c107d277>] ? finish_task_switch+0x47/0xf0
[ 1153.360836] [<c167c27b>] __schedule+0x35b/0x7e0
[ 1153.360839] [<c10a5334>] ? console_unlock+0x2c4/0x4d0
[ 1153.360842] [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890
[ 1153.360845] [<c10707b6>] ? process_one_work+0x196/0x370
[ 1153.360847] [<c167c723>] schedule+0x23/0x60
[ 1153.360849] [<c1070de1>] worker_thread+0x161/0x460
[ 1153.360852] [<c1090fcf>] ? __wake_up_locked+0x1f/0x30
[ 1153.360854] [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0
[ 1153.360856] [<c1074f01>] kthread+0xa1/0xc0
[ 1153.360859] [<c1680401>] ret_from_kernel_thread+0x21/0x30
[ 1153.360861] [<c1074e60>] ? kthread_create_on_node+0x110/0x110
[ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---
This patch replaces the kfree_skb() by dev_kfree_skb_any().
Signed-off-by: Thomas Körper <thomas.koerper@esd.eu>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
The microphone mute led on the Latitude E5550 can't work. We need to
apply DELL_WMI_MIC_MUTE_LED quirk to this machine.
The machine uses alc293 codec and already applied the quirk
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE through pin_fixup_tbl[].
Here we just let DELL_WMI_MIC_MUTE_LED be chained to
ALC269_FIXUP_HEADSET_MODE, then the machine will have these
quirks ALC293_FIXUP_DELL1_MIC_NO_PRESENCE-->
ALC269_FIXUP_HEADSET_MODE-->ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED.
BugLink: https://bugs.launchpad.net/bugs/1381856
Reported-and-tested-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We have one more Dell machine needs DELL_WMI_MIC_MUTE_LED quirk, but
the machine uses alc293 instead of alc255. So if
DELL_WMI_MIC_MUTE_LED still chain ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
the machine can't use this quirk.
To change this situation, let the DELL_WMI_MIC_MUTE_LED to be a
standalone quirk, and let other quirks chain it.
After this change, this quirk can be chained to any existing quirks,
and as a result, it is possible that this quirk is applied to
a non-Dell machine or a Dell machine without mic mute led on it, but
it is still safe since alc_fixup_dell_wmi() will return an error in
these situations.
And remove the quirk for machine with subsystem id 0x6010 and 0x601f,
these two machines will fall back to the quirk
ALC255_FIXUP_DELL1_MIC_NO_PRESENCE-->ALC255_FIXUP_HEADSET_MODE-->
ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED through pin_fixup_tbl[].
BugLink: https://bugs.launchpad.net/bugs/1381856
Reported-and-tested-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Due to DCBX configuration change if the VSI needs to use more than 1 TC;
it needs to disable the XPS maps that were set when operating in 1 TC mode.
Without disabling XPS the netdev layer will select queues based on those
settings and not use the TC queue mapping to make the queue selection.
This patch allows the driver to enable/disable the XPS based on the number
of TCs being enabled for the given VSI.
Change-ID: Idc4dec47a672d2a509f6d7fe11ed1ee65b4f0e08
Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Tested-By: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
When PFC is enabled we should not proceed with setting the link flow control
parameters. Also, always report the link flow Tx/Rx settings as off when
PFC is enabled.
Change-ID: Ib09ec58afdf0b2e587ac9d8851a5c80ad58206c4
Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Tested-By: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
FCoE VSI Tx queue disable times out when reconfiguring as a result of
DCB TC configuration change event.
The hardware allows us to skip disabling and enabling of Tx queues for
VSIs with single TC enabled. As FCoE VSI is configured to have only
single TC we skip it from disable/enable flow.
Change-ID: Ia73ff3df8785ba2aa3db91e6f2c9005e61ebaec2
Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Tested-By: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
When DCB TC configuration changes the firmware suspends the port's Tx.
Now, as DCB TCs may have changed the PF driver tries to reconfigure the
TC configuration of the VSIs it manages. As part of this process it disables
the VSI queues but the Tx queue disable will not complete as the port's
Tx has been suspended. So, waiting for Tx queues to go to disable state
in this flow may lead to detection of Tx queue disable timeout errors.
Hence, this patch adds a new PF state so that if a port's Tx is in
suspended state the Tx queue disable flow would just put the request for
the queue to be disabled and return without waiting for the queue to be
actually disabled.
Once the VSI(s) TC reconfiguration has been done and driver has called
firmware AQC "Resume PF Traffic" the driver checks the Tx queues requested
to be disabled are actually disabled before re-enabling them again.
Change-ID: If3e03ce4813a4e342dbd5a1eb1d2861e952b7544
Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Tested-By: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
When the port TC configuration changes as a result of DCBx the driver
modifies the enabled TCs for the VEBs it manages. But, in the process
it did not update the enabled_tc value that it caches on a per VEB basis.
So, when the next reconfiguration event occurs where the number of TC
value is same as the value cached in enabled_tc for a given VEB; driver
does not modify it's TC configuration by calling appropriate AQ command
believing it is running with the same configuration as requested.
Now, as the VEB is not actually enabled for the TCs that are there any
TC configuration command for VSI attached to that VEB with TCs that are
not enabled for the VEB fails.
This patch fixes this issue.
Change-ID: Ife5694469b05494228e0d850429ea1734738cf29
Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Tested-By: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This patch adds a check whether LLDP Agent's default AdminStatus is
enabled or disabled on a given port. If it is disabled then it sets
the DCBX status to disabled as well; and would not query firmware for
any DCBX configuration data.
Change-ID: I73c0b9f0adbf4cae177d14914b20a48c9a8f50fd
Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Tested-By: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This patch allows i40e driver to query and use DCB configuration from
firmware when firmware DCBX agent is in CEE mode.
Change-ID: I30f92a67eb890f0f024f35339696e6e83d49a274
Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Tested-By: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
When there are DCB configuration changes based on DCBX the firmware suspends
the port's Tx and generates an event to the PF. The PF is then responsible
to reconfigure the PF VSIs and switching topology as per the updated DCB
configuration and then resume the port's Tx by calling the "Resume Port Tx"
AQ command.
This patch adds this call to the flow that handles DCB re-configuration in
the PF.
Change-ID: I5b860ad48abfbf379b003143c4d3453e2ed5cc1c
Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Tested-By: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
Bumping minor version as this will be the second SW release and it
should be 1.
Change-ID: If0bd102095d2f059ae0c9b7f4ad625535ffbbdee
Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
VF interrupt processing takes a looooong time, and it's possible that we
could lose a VFLR event if it happens while we're processing a VFLR on
another VF. This would leave the VF in a semi-permanent reset state,
which would not be cleared until yet another VF experiences a VFLR.
To correct this situation, we enable the VFLR interrupt cause before we
begin processing any pending resets. This means that any VFLR that
occurs during reset processing will generate another interrupt and this
routine will get called again.
This change may cause a spurious interrupt when multiple VFLRs occur
very close together in time. If this happens, then this routine will be
called again and it will detect no outstanding VFLR events and do
nothing. No harm, no foul.
Change-ID: Id0451f3e6e73a2cf6db1668296c71e129b59dc19
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
Only warn once that PTP is not supported when linked at 100Mbit.
Yes, using a static this way means that this once-only message is not
port specific, but once only for the life of the driver, regardless of
the number of ports. That should be plenty.
Change-ID: Ie6476530056df408452e195ef06afd4f57caa4b2
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This brings in some mwifiex changes that further patches will
need to work on top to not cause merge conflicts.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This variant requires the flag BTUSB_BCM_PATCHRAM to work.
Relevant details from /sys/kernel/debug/usb/devices:
T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3404 Rev= 1.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=240A646F1XXX
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
The firmware was extracted from a Windows 8.1 64-bit installation
and converted from 'hex' to 'hcd' for use in Linux.
Under Windows it also identifies itself as BCM20702A0,
but the firmware is named "BCM20702A1_001.002.014.1315.1356.hex"
and is located in "%SYSTEMROOT%\system32\drivers\"
(md5 67cf6bfdae61c4bb819a66da984f7913)
(sha1 5f74cc6a9a3bf19ee0f8c3d01e4be34c609b188f)
The same firmware file is also available as a download at
http://www.asrock.com/mb/Intel/Z87E-ITX/?cat=Download&os=All
marked as "Bluetooth driver ver:12.0.0.7820"
'hcd' file should be placed at "brcm/BCM20702A0-13d3-3404.hcd"
inside the firmware directory (e.g. "/lib/firmware")
Signed-off-by: Fabio K <healthkit@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Doing things like hci_conn_hash_flush() while holding the hdev lock is
risky since its synchronous pending work cancellation could cause the
L2CAP layer to try to reacquire the hdev lock. Right now there doesn't
seem to be any obvious places where this would for certain happen but
it's already enough to cause lockdep to start warning against the hdev
and the work struct locks being taken in the "wrong" order:
[ +0.000373] mgmt-tester/1603 is trying to acquire lock:
[ +0.000292] ((&conn->pending_rx_work)){+.+.+.}, at: [<c104266d>] flush_work+0x0/0x181
[ +0.000270]
but task is already holding lock:
[ +0.000000] (&hdev->lock){+.+.+.}, at: [<c13b9a80>] hci_dev_do_close+0x166/0x359
[ +0.000000]
which lock already depends on the new lock.
[ +0.000000]
the existing dependency chain (in reverse order) is:
[ +0.000000]
-> #1 (&hdev->lock){+.+.+.}:
[ +0.000000] [<c105ea8f>] lock_acquire+0xe3/0x156
[ +0.000000] [<c140c663>] mutex_lock_nested+0x54/0x375
[ +0.000000] [<c13d644b>] l2cap_recv_frame+0x293/0x1a9c
[ +0.000000] [<c13d7ca4>] process_pending_rx+0x50/0x5e
[ +0.000000] [<c1041a3f>] process_one_work+0x21c/0x436
[ +0.000000] [<c1041e3d>] worker_thread+0x1be/0x251
[ +0.000000] [<c1045a22>] kthread+0x94/0x99
[ +0.000000] [<c140f801>] ret_from_kernel_thread+0x21/0x30
[ +0.000000]
-> #0 ((&conn->pending_rx_work)){+.+.+.}:
[ +0.000000] [<c105e158>] __lock_acquire+0xa07/0xc89
[ +0.000000] [<c105ea8f>] lock_acquire+0xe3/0x156
[ +0.000000] [<c1042696>] flush_work+0x29/0x181
[ +0.000000] [<c1042864>] __cancel_work_timer+0x76/0x8f
[ +0.000000] [<c104288c>] cancel_work_sync+0xf/0x11
[ +0.000000] [<c13d4c18>] l2cap_conn_del+0x72/0x183
[ +0.000000] [<c13d8953>] l2cap_disconn_cfm+0x49/0x55
[ +0.000000] [<c13be37a>] hci_conn_hash_flush+0x7a/0xc3
[ +0.000000] [<c13b9af6>] hci_dev_do_close+0x1dc/0x359
[ +0.012038] [<c13bbe38>] hci_unregister_dev+0x6e/0x1a3
[ +0.000000] [<c12d33c1>] vhci_release+0x28/0x47
[ +0.000000] [<c10dd6a9>] __fput+0xd6/0x154
[ +0.000000] [<c10dd757>] ____fput+0xd/0xf
[ +0.000000] [<c1044bb2>] task_work_run+0x6b/0x8d
[ +0.000000] [<c1001bd2>] do_notify_resume+0x3c/0x3f
[ +0.000000] [<c140fa70>] work_notifysig+0x29/0x31
[ +0.000000]
other info that might help us debug this:
[ +0.000000] Possible unsafe locking scenario:
[ +0.000000] CPU0 CPU1
[ +0.000000] ---- ----
[ +0.000000] lock(&hdev->lock);
[ +0.000000] lock((&conn->pending_rx_work));
[ +0.000000] lock(&hdev->lock);
[ +0.000000] lock((&conn->pending_rx_work));
[ +0.000000]
*** DEADLOCK ***
Fully fixing this would require some quite heavy refactoring to change
how the hdev lock and hci_conn instances are handled together. A simpler
solution for now which this patch takes is to try ensure that the hdev
workqueue is empty before proceeding with the various cleanup calls,
including hci_conn_hash_flush().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
The commit 543c043cbae7 ("powerpc/fsl_msi: change the irq handler from
chained to normal") changes the msi cascade handler from chained to
normal. Since cascade handler must run in hard interrupt context, this
will cause kernel panic if we force threading of all the interrupt
handler via kernel command parameter 'threadirqs'. So mark the irq
handler IRQF_NO_THREAD explicitly.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
|
|
The common short form of "randomizer" is "rand" in many places
(including the Bluetooth specification). The shorter version also makes
for easier to read code with less forced line breaks. This patch renames
all occurences of "randomizer" to "rand" in the Bluetooth subsystem
code.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
For now the mgmt commands dealing with remote OOB data are strictly
BR/EDR-only. This patch fixes missing checks for the passed address type
so that any non-BR/EDR value triggers the appropriate error response.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v3.18
As well as the usual driver fixes there's a few other things here:
One is a fix for a race in DPCM which is unfortuantely a rather large
diffstat, this is the result of growing usage of the mainline code and
hence more detailed testing so I'm relatively happy.
The other is a fix for non-DT machine driver matching following some of
the componentization work which is much more focused.
Both have had a while to cook in -next.
|
|
Currently, when a roc period expires, the offchannel
timer calls ieee80211_remain_on_channel_expired(), but
the roc state is cleared only when the queued work
to switch to the operating channel gets a chance to run.
This race is a problem because mac80211 can issue a
new roc request in this window. To avoid this, handle
roc completion in the offchannel timer itself.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
In a GO/STA setup, when we switch to the STA context,
the channel context timer is scheduled with a period of
half the beacon interval. If a beacon is received in
this duration, the timer is adjusted to accommodate
TSF sync done by the HW.
But, if the actual channel switch is delayed for some
reason, we end up rearming the timer every time a new
beacon is received. Avoid this by doing the adjustment
only once.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
If for some reason a beacon with a new NoA is
not sent out, then reset the mgd_prepare_tx flag.
Not doing this will result in a situation where
a GO will send a new NoA when it shouldn't.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch makes sure that pending roc/scan
operations are cancelled properly when a new
context is assigned/unassigned.
The flush_work() call to flush out any scheduled
channel context work is removed, instead, sc->mutex
is dropped to allow any pending work to get a chance
to complete by the channel scheduler. Also, increase
the timeout to allow a switch to an active GO.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
When a pending roc or scan operation is cancelled,
the offchannel operation is cleared, but the offchannel
state in the main scheduler is not cleared. This causes
problems since an active GO will try to process a stale
offchannel request that was deferred earlier. Fix this
by clearing the state when there is no pending offchannel
(roc/scan) operation.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The registers that control the on-chip thermometer
need to be programmed based on the chainmask that
the solution supports, not the chainmask that is
present in the eeprom.
Cc: Miaoqing Pan <miaoqing@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Cc: Miaoqing Pan <miaoqing@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The base TSF is used for HW timers 0..7, but chips
in the AR9003 family and above can support more generic
timers. To use them, however, a second HW TSF needs to
be enabled. This patch allows usage of the extra
timers by starting the second TSF properly.
The extra set of HW timers is apparently also present
in AR9287, but we enable it only for the AR9003 family.
Cc: Kobi Cohen-Arazi <kobic@qti.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
