Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: d525914b5b ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-10-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: b36bf0a0fe ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-9-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: 612e048e6a ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-8-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: 8fc6f1f042 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-7-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Reported-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Fixes: 553508cec2 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-6-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: 6dd09f775b ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-5-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: f6341f6448 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-4-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: dbffc8ccdf ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-3-miquel.raynal@bootlin.com
Originally, commit d7157ff49a ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.
Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.
Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: 59d9347332 ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-2-miquel.raynal@bootlin.com
Make cpufreq_online() return negative error codes on all errors that
cause the policy to be destroyed, as appropriate.
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fix up the remaining kerneldoc comments that don't adhere to the
expected format and clarify some of them a bit.
No functional changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
local_clock() has better precision and accuracy as compared to jiffies,
lets use it for time management in cpufreq stats.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Rearrange a conditional to make it more straightforward.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Avoid doing the same assignment in both branches of a conditional,
do it after the whole conditional instead.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit
57d563c829 ("x86: ia32_setup_rt_frame(): consolidate uaccess areas")
dropped a __user annotation in a cast when refactoring __put_user() to
unsafe_put_user().
Hence, since then, sparse warns in arch/x86/ia32/ia32_signal.c:350:9:
warning: cast removes address space '__user' of expression
warning: incorrect type in argument 1 (different address spaces)
expected void const volatile [noderef] __user *ptr
got unsigned long long [usertype] *
Add the __user annotation to restore the propagation of address spaces.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20201207124141.21859-1-lukas.bulwahn@gmail.com
Detailed description for this pull request:
1. Update devfreq core
- Add new devfreq_frequency tracepoint to show the frequency change
information.
- Add governor feature flag. The devfreq governor is able to
have the specific flag in order to contain the non-common feature.
For example, if governor contains the 'immutable' feature, don't allow
user to change the governor via sysfs.
- Add governor sysfs attribute flag for each sysfs file. Prior to that
devfreq subsystem show the all sysfs files regardless of governor type.
But, some sysfs fils are not supported on the specific devfreq governor.
In order to show the only supported sysfs files according to the governor,
clarify the access permission of sysfs attributes according to governor.
When adding the devfreq governor, can specify the available attribute
information by using DEVFREQ_GOV_ATTR_* constant variable. The user can
read or write the sysfs attributes in accordance to the specified attributes.
- Clean-up the code to remove the duplicate code for the devfreq tracepoint
and to remove redundant governor_name field from struct devfreq
2. Update exynos-bus.c devfreq driver
- Add interconnect API support for the Samsung Exynos Bus Frequency driver
of exynos-bus.c. Complementing the devfreq driver with an interconnect
functionality allows to ensure the QoS requirements of devices accessing
the system memory (e.g. video processing devices) are fulfilled
and allows to avoid issues like the DMA underrun.
3. Update tegra devfreq driver
- Add interconnect support and OPP interface for tegra30-devfreq.c.
Also, it is to guarantee the QoS requirement of some devices like
display controller.
- Move tegra20-devfreq.c from drivers/devfreq/ into driver/memory/tegra/
in order to use the more proper monitoring feature such as EMC_STAT
which is based in driver/memory/tegra/.
- Separate the configuration information for different SoC on
tegra30-devfrqe.c. The tegra30-devfreq.c had been supported both
tegra30-actmon and tegra124-actmon devices. In order to use
the more correct configuration data, separate them.
- Use dev_err_probe() to handle the deferred probe error on tegra30-devfreq.c.
4. Pull the request of 'Tegra SoC and clock controller changes for v5.11'
sent by Krzysztof Kozlowski <krzk@kernel.org> in order to prevent the
build error.
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEEsSpuqBtbWtRe4rLGnM3fLN7rz1MFAl/TI+UWHGN3MDAuY2hv
aUBzYW1zdW5nLmNvbQAKCRCczd8s3uvPU8M/EAClq1DatrIsc6eysfvUUYhZgGD4
QC3WrIQ858y9/rZT1If+uZeif6DonOSIYBetCa0Wo5kiuN3BvSCZEnAsndqRPjk1
NyvRbThXUCMrtlgah/rsVPRCgwS8UidTeCqhO1n2kvHlIINgyvqS8EVpDbrOjf8s
0MFAmsh/PK0bIQC53yHs24XhLm4ddk+K1Gw2xlyd+c2E/+6MGeKbtc1nfqSy337K
3GJe9IwC0JHQGC1tPi4wnA+/S+gK0/tP3RGPlF9fk+fnccWSDhIu6tQQh1hjaLwC
5hbjwavEcr67/E0/zkQs+Bm7mEHtHFERAOPKv3C4UzPCL5wg/Z6hVphaKb+hjFDE
kD2JRCyNHwSFemu78+ooef2Af745AH9OJ6Z1ADwTyyI6wPS0qUm0/m3Eu33kJdPb
f7v+DMkqEnzEGn6gMJ2/WAEXmGi7vjwp6W6bqf5Ft13te7K8OKK8jNiFcgDPXznN
7km9gG8/j/nS9J5s01VhxU9QmwD65RsKR8upBhIpkPoMktBoH7Q4P2Ab9XlZbliG
F0p1S6dnwxQI3BIP+BwkGVwgSINPd6bd7PyTCQJx2d3VqF5JVW3jEfXouWw6h8zO
pW+lgUBr8+M5K99UYj8wktROtt5kKQQ0yd85XBdIqSZWZJ2J/D71XxcDjvZdvF3L
4vAeDY224dRuy+PP7g==
=t1gj
-----END PGP SIGNATURE-----
Merge tag 'devfreq-next-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux
Pull devfreq updates for 5.11 from Chanwoo Choi:
1. Update devfreq core
- Add new devfreq_frequency tracepoint to show the frequency change
information.
- Add governor feature flag. The devfreq governor is able to set the
specific flag in order to support a non-common feature. For
example, if the governor supports the 'immutable' feature, don't
allow user space to change the governor via sysfs.
- Add governor sysfs attribute flag for each sysfs file. Prior to that
the devfreq subsystem allowed all of the sysfs files to be accessed
regardless of the governor type. But some sysfs fils are not
supported by specific devfreq governors. In order to only allow the
sysfs files supported by the governor to be accessed, clarify the
access permissions of sysfs attributes according to the governor.
When adding the devfreq governor, specify the available attribute
information by using DEVFREQ_GOV_ATTR_* symbols. The user can read
or write the sysfs attributes in accordance to the specified
access permissions.
- Clean-up the code to reduce duplication for the devfreq tracepoint
and to remove redundant governor_name field from struct devfreq.
2. Update exynos-bus.c devfreq driver
- Add interconnect API support to the Samsung Exynos Bus Frequency
driver, exynos-bus.c. Complementing the devfreq driver with
interconnect functionality allows to ensure that the QoS
requirements regarding devices accessing the system memory (e.g.
video processing devices) will be met and allows to avoid issues
like DMA underrun.
3. Update tegra devfreq driver
- Add interconnect support and OPP interface to tegra30-devfreq.c.
Also, it is to guarantee the QoS requirement of some devices like
the display controller.
- Move tegra20-devfreq.c from drivers/devfreq/ into drivers/memory/tegra/
in order to use the more proper monitoring feature such as EMC_STAT
which is located in drivers/memory/tegra/.
- Separate the configuration information for different SoCs in
tegra30-devfrqe.c. The tegra30-devfreq.c had been supporting both
tegra30-actmon and tegra124-actmon devices. In order to use the
more correct configuration data, separate them.
- Use dev_err_probe() to handle the deferred probe error in
tegra30-devfreq.c.
4. Pull the request of 'Tegra SoC and clock controller changes for
v5.11' sent by Krzysztof Kozlowski <krzk@kernel.org> in order to
avoid a build error."
* tag 'devfreq-next-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux:
PM / devfreq: tegra30: Separate configurations per-SoC generation
PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver
PM / devfreq: exynos-bus: Add registration of interconnect child device
dt-bindings: devfreq: Add documentation for the interconnect properties
soc/tegra: fuse: Add stub for tegra_sku_info
soc/tegra: fuse: Export tegra_read_ram_code()
clk: tegra: Export Tegra20 EMC kernel symbols
PM / devfreq: tegra30: Silence deferred probe error
PM / devfreq: tegra20: Relax Kconfig dependency
PM / devfreq: tegra20: Silence deferred probe error
PM / devfreq: Remove redundant governor_name from struct devfreq
PM / devfreq: Add governor attribute flag for specifc sysfs nodes
PM / devfreq: Add governor feature flag
PM / devfreq: Add tracepoint for frequency changes
PM / devfreq: Unify frequency change to devfreq_update_target func
trace: events: devfreq: Use fixed indentation size to improve readability
debugfs nodes were created in genpd_debug_init alled in late_initcall
preventing power domains registered though loadable modules to have
a debugfs entry.
Create/remove debugfs nodes when the power domain is added/removed
to/from the internal gpd_list.
Signed-off-by: Thierry Strudel <tstrudel@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Kernel test robot reported warning:
drivers/net/wireless/mediatek/mt76/tx.c: In function
'mt76_txq_schedule':
>> drivers/net/wireless/mediatek/mt76/tx.c:499:21: warning: variable 'q'
>> set but not used [-Wunused-but-set-variable]
499 | struct mt76_queue *q;
| ^
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1607542617-4005-1-git-send-email-jrdr.linux@gmail.com
- Fix up some SPI group and a register offset on Intel Jasperlake.
- Set default bias on Intel Merrifield.
- Preserve debouncing on Intel Baytrail.
- Stop .set_type() irqchip callback in the AMD driver from fiddling
with the debounce filter.
- Fix access to GPIO banks that are pass-thru on the Aspeed.
- Fix a fix for the Intel pin control driver to disable Rx/Tx when
requesting a UART line as GPIO.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl/TMjIACgkQQRCzN7AZ
XXOagw//UOHZDJIIoTJiVSksz8yFNjvoidY/O2f419fM/UtF+Mtk4HcZoeVOL2z/
TtpH/wmdd6gzG17gCFGFsfzCGdaWOa9xQA8oiXtThkgiw+HyQPXCWqHnYeNNYPO+
c70VD3fYkGouqY6btQkCmN/koKu6PWuysjYwv3xpSmKZWVlVSDxx6asvZztcoy4T
Fc1q6PqsaM9ixqJI5tDb/CYAXngfyuG045maq/Hg3TCErx4DIxQcL6639vEzcU/4
DuU84cAtsS3Lw+Ke4pAfyfDLCVKTk+f40Ka/iQPZlnEnuDyXr6+xwoEZ0FMubFiQ
D9hNpT4oFJZU6pDRVBUFJ6mtvakP13qGc1rwv7YAmPBO27Umhgrdaw/GPOOcUiE1
Q7INiRFPIWWTmboKhv/oheRNkoDETqBGj0YpkT47RxOEG7GsxVQwmln1vXoWSKCY
t8HtG6pLrhZuibhSebhEF5qT1dm2Th/H99vCuBsb5Y1nkbAQCJbMPfHJTEvWGHj/
JfmIEt1T9JN3AT+hJdqfJuZSsdN6Lh+xECoS7pug/TQHipAs1Xz/dhhS/YrBSikN
rzcCZ148P5OxpakiVDb15gdOQChRMq3f9OYYV0I1G6hCV3I4k48BiqNsySgPfopH
Pt246bFN79O1SgrsBlFio+GhsgtrFE4cVmIrjTJ1KopMhITA0k0=
=QTVd
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here is a late set of pin control fixes for v5.10, most concern some
minor and major issues found in the Intel drivers. Some are so hairy
that I have no idea what is going on there, but luckily the maintainer
knows what's up.
We also have an interesting fix for AMD, which makes AMD-based laptops
more stable IIUC.
Summary:
- Fix up some SPI group and a register offset on Intel Jasperlake
- Set default bias on Intel Merrifield
- Preserve debouncing on Intel Baytrail
- Stop .set_type() irqchip callback in the AMD driver from fiddling
with the debounce filter
- Fix access to GPIO banks that are pass-thru on the Aspeed
- Fix a fix for the Intel pin control driver to disable Rx/Tx when
requesting a UART line as GPIO"
* tag 'pinctrl-v5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: intel: Actually disable Tx and Rx buffers on GPIO request
pinctrl: aspeed: Fix GPIO requests on pass-through banks
pinctrl: amd: remove debounce filter setting in IRQ type setting
pinctrl: baytrail: Avoid clearing debounce value when turning it off
pinctrl: merrifield: Set default bias in case no particular value given
pinctrl: jasperlake: Fix HOSTSW_OWN offset
pinctrl: jasperlake: Unhide SPI group of pins
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'dev' not described in 'iwl_acpi_get_dsm_object'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'rev' not described in 'iwl_acpi_get_dsm_object'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'func' not described in 'iwl_acpi_get_dsm_object'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'args' not described in 'iwl_acpi_get_dsm_object'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:142: warning: Function parameter or member 'dev' not described in 'iwl_acpi_get_dsm_u8'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:142: warning: Function parameter or member 'rev' not described in 'iwl_acpi_get_dsm_u8'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:142: warning: Function parameter or member 'func' not described in 'iwl_acpi_get_dsm_u8'
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-17-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/fw/dbg.c:1932: warning: Function parameter or member 'reg_data' not described in 'iwl_dump_ini_mem'
drivers/net/wireless/intel/iwlwifi/fw/dbg.c:1932: warning: Excess function parameter 'reg' description in 'iwl_dump_ini_mem'
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-15-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/iwl-phy-db.c:97: warning: Function parameter or member 'trans' not described in 'iwl_phy_db'
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-14-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c:340: warning: cannot understand function prototype: 'struct iwl_eeprom_enhanced_txpwr '
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-9-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function parameter or member 'trans' not described in 'iwl_read_eeprom'
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function parameter or member 'eeprom' not described in 'iwl_read_eeprom'
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function parameter or member 'eeprom_size' not described in 'iwl_read_eeprom'
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-8-lee.jones@linaro.org
Also add documentation for 'mvm'.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:400: warning: cannot understand function prototype: 'const u16 expected_tpt_legacy[IWL_RATE_COUNT] = '
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'mvm' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'tbl' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'scale_index' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'attempts' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'successes' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'window' not described in '_rs_collect_tx_data'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2677: warning: duplicate section name 'NOTE'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'mvm' not described in 'rs_initialize_lq'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'sta' not described in 'rs_initialize_lq'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'lq_sta' not described in 'rs_initialize_lq'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'band' not described in 'rs_initialize_lq'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:3761: warning: Function parameter or member 'mvm' not described in 'rs_program_fix_rate'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:3761: warning: Function parameter or member 'lq_sta' not described in 'rs_program_fix_rate'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4213: warning: Function parameter or member 'mvm' not described in 'iwl_mvm_tx_protection'
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-3-lee.jones@linaro.org
- Fix runtime PM balancing on the errorpath of the Arizona driver.
- Fix a suspend NULL pointer reference in the dwapb driver.
- Balance free:ing in gpiochip_generic_free()
- Fix runtime PM balancing on the errorpath of the zynq driver.
- Fix irqdomain use-after-free in the mvebu driver.
- Break an eternal loop in the spreadtrum EIC driver.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl/TLq8ACgkQQRCzN7AZ
XXOUMg//aCi2slJSSYmIcg8NKKUpj2UL2n4JUTdOu/PzWUXc9c427mAlJkWexr/s
h5FTPqv8+AoUpJunxct6bsOmaaXrpAfzfLzgUl0NK+3WZ9B+rAnBM5E3g1RY2+bh
08k4vx0nAoSsi25OgQaWz64soK83/Gqx5VHaGQJDI5RaCVWyagLMgciSt2ZXZf02
gC31q8kVG/+Jv7o1RQF2ET81kW2R/C6LDq6c7PtHH9DKatIJc0/yEQu/lRAOPD9J
u72enRyW42Pd6TWP/TccsyiYBp9j6ijgPsnPp4EcoiJjiDuJm2PvDlr+q7iirhyg
Ore8+n9ezR8B1C9g6k/TcCEcc6Ojh4+UQTCpexJfjIOenr8s+gRZyNcrFONzpUyq
Kg71JwRKazn0cU8UQyL557x84DFgG/gWQt29+t21UtkCgRNVmDuFCAukZAS3Eox0
l4om2IidfRhl7Sdln4ipXp9GXR4UQL7L1sKz2DEAboXjo1+tsQVNXaKSU7dQQIcD
n7SN8Bl8fKr1a+FJ/UCtcBJrilasspZc3ZV/jExzKVa6saZPGGy2E6dMk6kmAaCv
MckZxaqmyo90EvBUBT+soqmK4d4kusUg8Ac5ZzsOWi2meLYzCvc87rl3M8nj5rdY
F1kuhpkgmmO1ympfxsvTC5RPG8B+yNtFcmVyjFWZYwioUGIQXL8=
=w5eY
-----END PGP SIGNATURE-----
Merge tag 'v5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"These are hopefully the last GPIO fixes for this cycle.
All are driver fixes except a small resource leak for pin ranges in
the gpiolib. Two are PM related, which is nice because when developers
start to find PM bugs it is usually because they have smoked out the
bugs of more severe nature.
Summary:
- Fix runtime PM balancing on the errorpath of the Arizona driver
- Fix a suspend NULL pointer reference in the dwapb driver
- Balance free:ing in gpiochip_generic_free()
- Fix runtime PM balancing on the errorpath of the zynq driver
- Fix irqdomain use-after-free in the mvebu driver
- Break an eternal loop in the spreadtrum EIC driver"
* tag 'v5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: eic-sprd: break loop when getting NULL device resource
gpio: mvebu: fix potential user-after-free on probe
gpio: zynq: fix reference leak in zynq_gpio functions
gpiolib: Don't free if pin ranges are not defined
gpio: dwapb: fix NULL pointer dereference at dwapb_gpio_suspend()
gpio: arizona: disable pm_runtime in case of failure
In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by replacing a /* fall through */ comment with the new
pseudo-keyword macro fallthrough; instead of letting the code fall
through to the next case.
Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/edd98d194bfc98b4be93a9bdc303630b719c0e66.1605896060.git.gustavoars@kernel.org
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly using the fallthrough pseudo-keyword as a
replacement for a number of "fall through" markings.
Notice that Clang doesn't recognize "fall through" comments as
implicit fall-through.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201117155904.GA14551@embeddedor
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly using the fallthrough pseudo-keyword as a
replacement for a number of "fall through" markings.
Notice that Clang doesn't recognize "fall through" comments as
implicit fall-through.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201117135053.GA13248@embeddedor
- Remove __packed from a Renesas struct to improve portability
- Fix a linking problem with i.MX when config options don't agree
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAl/TGaoRHHNib3lkQGtl
cm5lbC5vcmcACgkQrQKIl8bklSW/Zw/9ER+igKcTyu2FbV3TQqikxvxwrgEUFgdn
dzOZfRr6JS50hUnhrCFg6n1S4V+6E03hoB9sL5jitL7x1a05mDHGIJVbQy4ld6G2
Vrgf6Tc1UFGKc6wQ2pN7hFhwGISMFCQ9r5Vk6ksCy3ZhOkjjrvoYfIuZIIpVrcvQ
TWasN6zMEeSoUSOTny5jnkyw7e3FPZMS49w4oKbJaoL/GcgfBZhVQKXJ1Huf4qqO
KeTW9YiPf71DgiTE7P36zEi5YUyRpvyFcoLAiNN/EVYHN6fq9s+WZP8dQPJLluVE
gre0/UliOyP+eybOHeHv5L3xqwUdyntUgcTTGQlp/r4EJ4Oql9hYeVO43025p7hf
BxTd8/1nITpvj2Lp+70oFJ1ZuYUPNm3cnRzXVAFNNJDnGUjqV1cZw4Dx0kbaDggv
XjQTHiMugPz2zPjnZRd3fUZGcnPsMy1Y4vBu1sKWAY3y/GVhSozH4lRNv5qDaBi0
oH6IKu0vYX8AeZNsLv2GRPMk05sl9lLJpnXY60Spl2gXLInGm9TNEgGWDpVW13IE
6xxfat4WWL+sC0fcO06iM6t8/2raJ71ytKvFsvwLzdXEaEaFjHVlAQ5WECN5DIeo
5bSjbWg9ZP7EgvaXnGWfGwaZymDkmJ/WZSoqHGwv74s/juSger0SmU4kfFNvFHqq
aL82CrorJZo=
=NxjH
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
"Two small clk driver build fixes
- Remove __packed from a Renesas struct to improve portability
- Fix a linking problem with i.MX when config options don't agree"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: renesas: r9a06g032: Drop __packed for portability
clk: imx: scu: fix MXC_CLK_SCU module build break
Small series that addresses a problem where DSP status dump
for a failure case, ends up being printed as as debug print. This
is important information for any bug report. While at it, the series
contains a few cleanups to related code.
Ranjani Sridharan (3):
ASoC: SOF: Intel: hda: remove duplicated status dump
ASoC: SOF: modify the SOF_DBG flags
ASoC: SOF: Intel: hda: fix the condition passed to sof_dev_dbg_or_err
sound/soc/sof/debug.c | 2 +-
sound/soc/sof/intel/byt.c | 2 +-
sound/soc/sof/intel/hda-loader.c | 19 +++++++++++++------
sound/soc/sof/intel/hda.c | 10 ++++------
sound/soc/sof/loader.c | 4 ++--
sound/soc/sof/ops.c | 2 +-
sound/soc/sof/sof-priv.h | 13 ++++++++-----
7 files changed, 30 insertions(+), 22 deletions(-)
--
2.29.2
Since commit d73dfc6a41 ("serial: 8250_pci: remove __devexit
usage") in v3.9, the 8250/16550 PCI serial driver no longer has any code
or data located in initmem, hence there is no need to annotate the
pci_serial_quirks structure with __refdata. Drop the annotation, to
avoid suppressing future section warnings.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201211133907.2970460-1-geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There's a confusion between the preferred_depth uapi and the generic
fbdev helpers. Former wants depth, latter wants bpp, and for XRGB8888
they don't match. Which hit me with vkms, which wants that.
All other drivers setting this and using the generic fbdev helpers use
16, where both numbers match, for RGB565.
Since fixing this is a bit involved (I think for atomic drivers we
should just compute this all internally from the format list of the
first primary plane) paper over the issue in vkms by using defaults
everywhere. Then userspace will pick XRGB8888, and fbdev helpers will
do the same, and we have what we want.
Reported-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Simon Ser <contact@emersion.fr>
Cc: Simon Ser <contact@emersion.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Melissa Wen <melissa.srw@gmail.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201211161113.3350061-1-daniel.vetter@ffwll.ch
I wanted to look up something and noticed the hyperlink doesn't work.
While fixing that also noticed a trivial kerneldoc comment typo in the
same section, fix that too.
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204200242.2671481-1-daniel.vetter@ffwll.ch
Enable serial driver to be built as a module. To do so, init the
console support on driver/module load instead of using
console_initcall().
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20201211005744.12855-1-khilman@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit adds support for PKTDMA in k3-udma glue driver. Use new
psil_endpoint_config struct to get static data for a given channel or a
flow during setup. Make sure that the RX flows being mapped to a RX
channel is within the range of flows that is been allocated to that RX
channel.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201208090440.31792-21-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
One of the DMAs introduced with AM64 is the Packet DMA (PKTDMA).
It serves similar purpose as K3 UDMAP channels in packet mode, but with
notable differences, like tflow support and channels being allocated to
service specific peripherals.
The rings for the PKTDMA is integrated within the DMA itself instead of
using rings from the general purpose ringacc.
PKTDMA can be used to service PSI-L peripherals, similarly to
K3 UDMA channels.
Most of the driver code can be reused for PKTDMA tchan/rchan support but
new setup and allocation functions are needed to handle the differences
between the DMAs.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201208090440.31792-20-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Unlike UDMAP the BCDMA defines the channel TPL levels per channel type.
In UDMAP the number of high and ultra-high channels applies to both tchan
and rchan.
BCDMA defines the TPL per channel types: bchan, tchan and rchan can have
different number of high and ultra-high channels.
In order to support BCDMA channel TPL we need to move the tpl information
as per channel type property for the DMAs.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201208090440.31792-19-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
One of the DMAs introduced with AM64 is the Block Copy DMA (BCDMA).
It serves similar purpose as K3 UDMAP channels in TR mode.
The rings for the BCDMA is integrated within the DMA itself instead of
using rings from the general purpose ringacc.
A BCDMA have two different type of channels:
- Block Copy Channels (bchan)
- Split Channels (tchan and rchan)
tchan and rchan can be used to service PSI-L peripherals, similarly to
K3 UDMA channels.
bchan can be only used for block copy operation (TR type15) like the
paired K3 UDMA tchan/rchan configured in block copy mode.
bchans can be also used to service peripherals directly if an external
trigger is selected for the channel.
Most of the driver code can be reused for BCDMA bchan/tchan/rchan support
but new setup and allocation functions are needed to handle the
differences between the DMAs.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201208090440.31792-18-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a
separate and generic ringacc is used.
The ring SW interface is similar to ringacc with some major architectural
differences, like
They are part of the DMA (BCDMA or PKTDMA).
They are dual mode rings are modeled as pair of Rings objects which has
common configuration and memory buffer, but separate real-time control
register sets for each direction mem2dev (forward) and dev2mem (reverse).
The ringacc driver must be initialized for DMA rings use with
k3_ringacc_dmarings_init() as it is not an independent device as ringacc
is.
AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
and forward ring must always be initialized/configured. After this any
other Ringacc APIs can be used without any callers changes.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201208090440.31792-17-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
