This is a usual small bump in the middle, we've got a set of ASoC
fixes in this week as shown in diffstat.
The only change in the core stuff is about (somewhat minor) PCM
debugfs error handling. The major changes are rather for Intel
SOF and topology coverage, as well as other platform (rockchip,
samsung, stm) and codec fixes.
As non-ASoC changes, a couple of new HD-audio chip fixes and a
typo correction of USB-audio driver validation code are found.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl2xNWwOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE/Rjg/9GWIetA2nCM121bS1yCYAx81K+EkEGPZmLxi3
EquGO47IYMPZ8tBzvE4E20AKjicsWV3/5tDVGh0pYBr+6LbWOY1+5WUHXS2ysvF6
PXt//ZPmsEQWv5awKnASW1I22Kgw9o9BjG+6Y6RuiGkWSjDrtdNyZMxlGs5/aYCi
D7AG7znKsJOH7r3Q/g0Urou6cTUlj4ni9WWIzKtO3yyXvbu8aa1bbUIhKi3U3/xn
EckXmRI5lU8Ov4AqKoXrtUfC+eBK7sfH5wDXYkyBby7wpZzehFbgzw4dg2LDBf7k
dQ9ID91R715wpKn15+9r5y9qycSNgZAqqaOSln6i5xPAwzaWbiDj2P8avq4Vemy/
Kd/slBNdr3PR7PloXWpsB2ia9bnEi4F9kyNpOoU1gXghWvzxZv/b09cj+XQ0Rip3
+Y4fwyF8HBRykUEOVey2+IxpzYqYZ2eYMThwBF9EfVnTUTo53lx1uxmcCCAhPnQN
nHQd1/1AzSdpKLoRyhE9QyI3c4VDnQL3NoOk9vVei4TOLl8ONDnX7Era9W8rafix
hLgkh5agGIqVaU4v/7joDR1BUFUILar5kgOGZMH4N8O0uAOByNMjge17ENjXTkiE
XWUVaoBMDCqs6KRGV63hkvTTlmT8AGhZBoxsZpavOvBA3uHhthPaaqcr/+ENgxsl
MnajcUY=
=jDN8
-----END PGP SIGNATURE-----
Merge tag 'sound-5.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This is a usual small bump in the middle, we've got a set of ASoC
fixes in this week as shown in diffstat.
The only change in the core stuff is about (somewhat minor) PCM
debugfs error handling. The major changes are rather for Intel SOF and
topology coverage, as well as other platform (rockchip, samsung, stm)
and codec fixes.
As non-ASoC changes, a couple of new HD-audio chip fixes and a typo
correction of USB-audio driver validation code are found"
* tag 'sound-5.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (29 commits)
ALSA: hda: Add Tigerlake/Jasperlake PCI ID
ALSA: usb-audio: Fix copy&paste error in the validator
ALSA: hda/realtek - Add support for ALC711
ASoC: SOF: control: return true when kcontrol values change
ASoC: stm32: sai: fix sysclk management on shutdown
ASoC: Intel: sof-rt5682: add a check for devm_clk_get
ASoC: rsnd: Reinitialize bit clock inversion flag for every format setting
ASoC: simple_card_utils.h: Fix potential multiple redefinition error
ASoC: msm8916-wcd-digital: add missing MIX2 path for RX1/2
ASoC: core: Fix pcm code debugfs error
ASoc: rockchip: i2s: Fix RPM imbalance
ASoC: wm_adsp: Don't generate kcontrols without READ flags
ASoC: intel: bytcr_rt5651: add null check to support_button_press
ASoC: intel: sof_rt5682: add remove function to disable jack
ASoC: rt5682: add NULL handler to set_jack function
ASoC: intel: sof_rt5682: use separate route map for dmic
ASoC: SOF: Intel: hda: Disable DMI L1 entry during capture
ASoC: SOF: Intel: initialise and verify FW crash dump data.
ASoC: SOF: Intel: hda: fix warnings during FW load
ASoC: SOF: pcm: harden PCM STOP sequence
...
ioapic_irqd_[un]mask() are misnomers as both functions do way more than
masking and unmasking the interrupt line. Both deal with the moving the
affinity of the interrupt within interrupt context. The mask/unmask is just
a tiny part of the functionality.
Rename them to ioapic_prepare/finish_move(), fixup the call sites and
rename the related variables in the code to reflect what this is about.
No functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20191017101938.412489856@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There is an issue with threaded interrupts which are marked ONESHOT
and using the fasteoi handler:
if (IS_ONESHOT())
mask_irq();
....
cond_unmask_eoi_irq()
chip->irq_eoi();
if (setaffinity_pending) {
mask_ioapic();
...
move_affinity();
unmask_ioapic();
}
So if setaffinity is pending the interrupt will be moved and then
unconditionally unmasked at the ioapic level, which is wrong in two
aspects:
1) It should be kept masked up to the point where the threaded handler
finished.
2) The physical chip state and the software masked state are inconsistent
Guard both the mask and the unmask with a check for the software masked
state. If the line is marked masked then the ioapic line is also masked, so
both mask_ioapic() and unmask_ioapic() can be skipped safely.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Fixes: 3aa551c9b4 ("genirq: add threaded interrupt handler support")
Link: https://lkml.kernel.org/r/20191017101938.321393687@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
syzbot reported the following issue :
BUG: KCSAN: data-race in update_defense_level / update_defense_level
read to 0xffffffff861a6260 of 4 bytes by task 3006 on cpu 1:
update_defense_level+0x621/0xb30 net/netfilter/ipvs/ip_vs_ctl.c:177
defense_work_handler+0x3d/0xd0 net/netfilter/ipvs/ip_vs_ctl.c:225
process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
worker_thread+0xa0/0x800 kernel/workqueue.c:2415
kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
write to 0xffffffff861a6260 of 4 bytes by task 7333 on cpu 0:
update_defense_level+0xa62/0xb30 net/netfilter/ipvs/ip_vs_ctl.c:205
defense_work_handler+0x3d/0xd0 net/netfilter/ipvs/ip_vs_ctl.c:225
process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
worker_thread+0xa0/0x800 kernel/workqueue.c:2415
kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 7333 Comm: kworker/0:5 Not tainted 5.4.0-rc3+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events defense_work_handler
Indeed, old_secure_tcp is currently a static variable, while it
needs to be a per netns variable.
Fixes: a0840e2e16 ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Joel Stanley <joel@jms.id.au>
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: James Morse <james.morse@arm.com>
Cc: kernel-janitors@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-aspeed@lists.ozlabs.org
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Robert Richter <rrichter@marvell.com>
Cc: Stefan Schaeckeler <sschaeck@cisco.com>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/baabb9e9-a1b2-3a04-9fb6-aa632de5f722@web.de
Add missing parentheses to correctly hyperlink the reference to
reset_control_get_shared().
Fixes: 0b52297f22 ("reset: Add support for shared reset controls")
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a missing colon to fix a documentation build warning:
./include/linux/reset-controller.h:45: warning: Function parameter or member 'con_id' not described in 'reset_control_lookup'
Fixes: 6691dffab0 ("reset: add support for non-DT systems")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a newline and remove a superfluous kerneldoc marker before the
of_reset_control_get_count kerneldoc comment, to fix documentation
build warnings:
./drivers/reset/core.c:832: warning: Incorrect use of kernel-doc format: * of_reset_control_get_count - Count number of resets available with a device
./drivers/reset/core.c:840: warning: Function parameter or member 'node' not described in 'of_reset_control_get_count'
Fixes: 17c82e206d ("reset: Add APIs to manage array of resets")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
The flags parameter never made it into the API, but was erroneously
included in the kerneldoc comment. Remove it to fix a documentation
build warning:
./drivers/reset/core.c:86: warning: Excess function parameter 'flags' description in 'of_reset_simple_xlate'
Fixes: 61fc413176 ("reset: Add reset controller API")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Make trebly sure that all possible callbacks and their delayed brethren
are complete before asserting that the i915_active should be idle after
flushing all barriers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191023235359.27132-1-chris@chris-wilson.co.uk
Enable RESET_SIMPLE for ARCH_REALTEK.
They can reuse the DesignWare bindings to avoid a new compatible.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Restore alphabetical order for Kconfig dependencies and help text.
Compatibles got out of order too, but no functional change done here.
Goal is to make it obvious where to add new platforms.
Fixes: 64c47b624f ("reset: Add reset controller support for BM1880 SoC")
Fixes: 1d7592f84f ("reset: simple: Enable for ASPEED systems")
Fixes: 96a2f50305 ("reset: build simple reset controller driver for Agilex")
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
add Section in MAINTAINERS file for poweroff driver
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
add poweroff driver for mt6323 and make Makefile and Kconfig-Entries
Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
use mt6397 rtc driver also for mt6323 but with different
base/size see "mfd: mt6323: add mt6323 rtc+pwrc"
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
- use regmap_read_poll_timeout to drop while-loop
- use devm-api to drop remove-callback
Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
move code to separate header-file to reuse definitions later
in poweroff-driver (drivers/power/reset/mt6323-poweroff.c)
Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
add missing devicetree-binding document for mt6397 rtc
in later patch driver is extended with mt6323 chip
Suggested-By: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Part 3 from this series [1] was not merged due to wrong splitting
and breaks mt6323 pmic on bananapi-r2
dmesg prints this line and at least switch is not initialized on bananapi-r2
mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0
this patch contains only the probe-changes and chip_data structs
from original part 3 by Hsin-Hsiung Wang
[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=164155
Fixes: a4872e80ce ("mfd: mt6397: Extract IRQ related code from core driver")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Currently, we do not check memory allocation
result for ei->i_block_alloc_info in ioctl,
this patch checks it and returns error in
failure case.
Link: https://lore.kernel.org/r/20191023135643.28837-1-cgxu519@mykernel.net
Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
Signed-off-by: Jan Kara <jack@suse.cz>
The attachment list is now protected by the dma_resv object.
Stop holding the dma_buf->lock while calling ->attach/->detach,
this allows for concurrent attach/detach operations.
v2: cleanup commit message and locking in _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336790
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
The defaults for the sigfuz test is to run for 4000 iterations, but
that can take quite a while and the test harness may kill the test.
Reduce the number of iterations to 600, which gives a runtime of
roughly 1 minute on a Power8 system.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20191013234643.3430-1-mpe@ellerman.id.au
Fix the following sparse warnings.
sparse: symbol 'rtl8723bu_set_coex_with_type' was not declared.
Should it be static?
sparse: symbol 'rtl8723bu_update_bt_link_info' was not declared.
Should it be static?
sparse: symbol 'rtl8723bu_handle_bt_inquiry' was not declared.
Should it be static?
sparse: symbol 'rtl8723bu_handle_bt_info' was not declared.
Should it be static?
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:4484:6:
warning: variable rate_mask set but not used [-Wunused-but-set-variable]
It is never used since commit a9bb0b5157 ("rtl8xxxu: Improve
TX performance of RTL8723BU on rtl8xxxu driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/atmel/atmel_cs.c:120:21:
warning: variable dev set but not used [-Wunused-but-set-variable]
It is never used, so can remove it.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/admtek/adm8211.c:1784:16:
warning: variable mem_addr set but not used [-Wunused-but-set-variable]
drivers/net/wireless/admtek/adm8211.c:1785:15:
warning: variable io_addr set but not used [-Wunused-but-set-variable]
They are never used, so can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When building with Clang + -Wtautological-pointer-compare:
drivers/net/wireless/realtek/rtlwifi/regd.c:389:33: warning: comparison
of address of 'rtlpriv->regd' equal to a null pointer is always false
[-Wtautological-pointer-compare]
if (wiphy == NULL || &rtlpriv->regd == NULL)
~~~~~~~~~^~~~ ~~~~
1 warning generated.
The address of an array member is never NULL unless it is the first
struct member so remove the unnecessary check. This was addressed in
the staging version of the driver in commit f986978b32 ("Staging:
rtlwifi: remove unnecessary NULL check").
While we are here, fix the following checkpatch warning:
CHECK: Comparison to NULL could be written "!wiphy"
35: FILE: drivers/net/wireless/realtek/rtlwifi/regd.c:389:
+ if (wiphy == NULL)
Fixes: 0c8173385e ("rtl8192ce: Add new driver")
Link:https://github.com/ClangBuiltLinux/linux/issues/750
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This commit adds several Tx/Rx physical information to phy_info
debugfs for 8822B/8822C. By this debugfs, we can know physical
information, such as Tx/Rx rate, RSSI, EVM,SNR, etc. The
information is gotten from the packets of Tx/Rx path. It has
no impact for the performance of 8822B/8822C.
In the fields, we may meet different kinds of problems, but
we may have no professional instrument to check them. At
this moment, this debugfs is a good tool, and it may provide
useful information for debug.
Signed-off-by: Tsang-Shian Lin <thlin@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Support setting bit rate from upper layer.
After configuring the original rate control result in the driver, the
result is then masked by the bit rate mask received from the ops
set_bitrate_mask. Lastly, the masked result will be sent to firmware.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Enable MU-MIMO transmit beamformee support for chipset 8822b and 8822c.
If the driver is in station mode and associated with an AP, and the
capabilities of both meet the requirement of beamforming, driver will
run as a beamformee and the corresponding chip settings will be set.
In addition, module parameter support_bf is added to enable or disable
beamforming. Sometimes driver will need to disable for inter-operate
issues, and it would be easier for driver to debug.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The temperature of the chip can affect the output power
of the RF components. Hence driver requires to compensate
the power by adjusting the power index recorded in the
power swing table.
And if the difference of current thermal value to the
default thermal value exceeds a threshold, the RF IQK
should be triggered to re-calibrate the characteristics
of the RF components, to keep the output IQ vectors of
the RF components orthogonal enough.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Add macros to see which band we are, based on the current channel.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
asm/sgi/sgi.h is unused, time to remove it.
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
The LAN8740, like the 8720, also requires a reset after enabling clock.
The datasheet [1] 3.8.5.1 says:
"During a Hardware reset, an external clock must be supplied
to the XTAL1/CLKIN signal."
I have observed this issue on a custom i.MX6 based board with
the LAN8740A.
[1] http://ww1.microchip.com/downloads/en/DeviceDoc/8740a.pdf
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/usb/lan78xx.c:3995:6: warning:
variable event set but not used [-Wunused-but-set-variable]
It is never used, so can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel says:
====================
mlxsw: Update main pool computation and pool size limits
Petr says:
In Spectrum ASICs, the shared buffer is an area of memory where packets are
kept until they can be transmitted. There are two resources associated with
shared buffer size: cap_total_buffer_size and cap_guaranteed_shared_buffer.
So far, mlxsw has been using the former as a limit when validating shared
buffer pool size configuration. However, the total size also includes
headrooms and reserved space, which really cannot be used for shared buffer
pools. Patch #1 mends this and has mlxsw use the guaranteed size.
To configure default pool sizes, mlxsw has historically hard-coded one or
two smallish pools, and one "main" pool that took most of the shared buffer
(that would be pool 0 on ingress and pool 4 on egress). During the
development of Spectrum-2, it became clear that the shared buffer size
keeps shrinking as bugs are identified and worked around. In order to
prevent having to tweak the size of pools 0 and 4 to catch up with updates
to values reported by the FW, patch #2 changes the way these pools are set.
Instead of hard-coding a fixed value, the main pool now takes whatever is
left from the guaranteed size after the smaller pool(s) are taken into
account.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of hard-coding the size of the largest pool, calculate it from the
reported guaranteed shared buffer size and sizes of other pools (currently
only the CPU port pool).
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There are two resources associated with shared buffer size:
cap_total_buffer_size, and cap_guaranteed_shared_buffer. So far, mlxsw has
been using the former as a limit to determine how large a pool size is
allowed to be. However, the total size also includes headrooms and reserved
space, which really cannot be used for shared buffer pools.
Therefore convert mlxsw to use the latter resource as a limit. Adjust
hard-coded pool sizes to be the guaranteed size minus 256000 bytes for CPU
port pool. On Spectrum-1 that actually leads to an increase. A follow-up
patch will have this size calculated automatically.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
build_restore_pagemask() will restore the value of register $1/$at when
its restore_scratch argument is non-zero, and aims to do so by filling a
branch delay slot. Commit 0b24cae4d5 ("MIPS: Add missing EHB in mtc0
-> mfc0 sequence.") added an EHB instruction (Execution Hazard Barrier)
prior to restoring $1 from a KScratch register, in order to resolve a
hazard that can result in stale values of the KScratch register being
observed. In particular, P-class CPUs from MIPS with out of order
execution pipelines such as the P5600 & P6600 are affected.
Unfortunately this EHB instruction was inserted in the branch delay slot
causing the MFC0 instruction which performs the restoration to no longer
execute along with the branch. The result is that the $1 register isn't
actually restored, ie. the TLB refill exception handler clobbers it -
which is exactly the problem the EHB is meant to avoid for the P-class
CPUs.
Similarly build_get_pgd_vmalloc() will restore the value of $1/$at when
its mode argument equals refill_scratch, and suffers from the same
problem.
Fix this by in both cases moving the EHB earlier in the emitted code.
There's no reason it needs to immediately precede the MFC0 - it simply
needs to be between the MTC0 & MFC0.
This bug only affects Cavium Octeon systems which use
build_fast_tlb_refill_handler().
Signed-off-by: Paul Burton <paulburton@kernel.org>
Fixes: 0b24cae4d5 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.")
Cc: Dmitry Korotin <dkorotin@wavecomp.com>
Cc: stable@vger.kernel.org # v3.15+
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
IP27 uses ARC prom only for parsing prom arguments and has a hack
for IP27 to make the ARC code behave. By introducing config symbol
ARC_CMDLINE_ONLY IP27 only drags in ARC cmdline parsing and does
everything else in IP27 specific code.
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
prom_argc and prom_argv are only used by prom_init_cmdline(), so
we could pass them directly as function argument.
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Calling register_smp_ops() in plat_mem_setup() is still early enough.
So by doing this we could remove the ugly #ifdef CONFIG_SGI_IP27 in
fw/arc/init.c.
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
IP27 code has a few externs distributed over .c files. Collect them
together into one commcon header file.
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
