Since commit 3812b8c5c5 ("kbuild: make -r/-R effective in top
Makefile for old Make versions"), make-kpkg is not working.
make-kpkg directly includes the top Makefile of Linux kernel, and
appends some debian_* targets.
/usr/share/kernel-package/ruleset/kernel_version.mk:
# Include the kernel makefile
override dot-config := 1
include Makefile
dot-config := 1
I did not know the kernel Makefile was used in that way, and it is
hard to guarantee the behavior when the kernel Makefile is included
by another Makefile from a different project.
It looks like Debian Stretch stopped providing make-kpkg. Maybe it is
obsolete and being replaced with 'make deb-pkg' etc. but still widely
used.
This commit adds a workaround; if the top Makefile is included by
another Makefile, skip sub-make in order to make the main part visible.
'MAKEFLAGS += -rR' does not become effective for GNU Make < 4.0, but
Debian/Ubuntu is already using newer versions.
The effect of this commit:
Debian 8 (Jessie) : Fixed
Debian 9 (Stretch) : make-kpkg (kernel-package) is not provided
Ubuntu 14.04 LTS : NOT Fixed
Ubuntu 16.04 LTS : Fixed
Ubuntu 18.04 LTS : Fixed
This commit cannot fix Ubuntu 14.04 because it installs GNU Make 3.81,
but its support will end in Apr 2019, which is before the Linux v5.1
release.
I added warning so that nobody would try to include the top Makefile.
Fixes: 3812b8c5c5 ("kbuild: make -r/-R effective in top Makefile for old Make versions")
Reported-by: Liz Zhang <lizzha@microsoft.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Lili Deng <v-lide@microsoft.com>
Cc: Manoj Srivastava <srivasta@debian.org>
As commit 423a8155fa ("kbuild: Fix reading of .config in
link-vmlinux.sh") addressed, some shells fail to perform '.' if
${KCONFIG_CONFIG} does not contain a slash at all.
Instead, we can source include/config/auto.conf, which obviously
contain slashes, and we do not expect its file path overridden by
a user. Perhaps, the performance might be slightly better since
unset CONFIG options are stripped from include/config/auto.conf.
scripts/setlocalversion already works this way.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
When I was searching for unneeded $(KCONFIG_CONFIG) usages, I noticed
this strange build dependency.
It can use $(call if_changed,...) in case ZTEXTADDR and ZBSSADDR are
changed, but even a simpler way is to use the pattern rule in
scripts/Makefile.build. This is what arch/arm/boot/compressed/Makefile
does.
I did only build test. I confirmed equivalent vmlinux.lds was generated.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It believe it is a bad idea to hardcode a specific compiler prefix
that may or may not be installed on a user's system. It is annoying
when testing features that should not require compilers at all.
For example, mrproper, headers_install, etc. should work without
any compiler.
They look like follows on my machine.
$ make ARCH=h8300 mrproper
./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found
./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found
make: h8300-unknown-linux-gcc: Command not found
make: h8300-unknown-linux-gcc: Command not found
[ a bunch of the same error messages continue ]
$ make ARCH=h8300 headers_install
./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found
./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found
make: h8300-unknown-linux-gcc: Command not found
HOSTCC scripts/basic/fixdep
make: h8300-unknown-linux-gcc: Command not found
WRAP arch/h8300/include/generated/uapi/asm/kvm_para.h
[ snip ]
The solution is to delete this line, or to use cc-cross-prefix like
some architectures do. I chose the latter as a moderate fixup.
I added an alternative 'h8300-linux-' because it is available at:
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
scripts/Makefile.build and arch/s390/boot/Makefile use the same
command (thin archiving with symbol table creation).
Avoid the code duplication, and move it to scripts/Makefile.lib.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Unless CONFIG_DEBUG_SECTION_MISMATCH is enabled, modpost only shows
the number of section mismatches.
If you want to know the symbols causing the issue, you need to rebuild
with CONFIG_DEBUG_SECTION_MISMATCH. It is tedious.
I think it is fine to show annoying warning when a new section mismatch
comes in.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5b
("kbuild: do not drop -I without parameter").
I removed some header search paths because I was able to build ia64
without them.
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5b
("kbuild: do not drop -I without parameter").
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
bison/flex is now needed always for building for kconfig. Some build
dependencies depend on kernel configuration, enable them as needed:
- libelf-dev when UNWINDER_ORC is set
- libssl-dev for SYSTEM_TRUSTED_KEYRING
Since the libssl-dev is needed for extract_cert binary, denote with
:native to install the libssl-dev for the build machines architecture,
rather than for the architecture of the kernel being built.
Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: maximilian attems <maks@stro.at>
[masahiro.yamada: change 'flex' to 'flex | flex:native' ]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Before this commit the i2c-designware-platdrv assumes that if the pdev
has an apci-companion it should use a dynamic adapter-nr and it sets
adapter->nr to -1, otherwise it will use pdev->id as adapter->nr.
There are 3 ways how platform_device-s to which i2c-designware-platdrv
will bind can be instantiated:
1) Through of / devicetree
2) Through ACPI enumeration
3) Explicitly instantiated through platform_device_create + add
1) In case of devicetree-instantiation the drivers/of code always sets
pdev->id to PLATFORM_DEVID_NONE, which is -1 so in this case both paths
to set adapter->nr end up doing the same thing.
2) In case of ACPI instantiation the device will always have an
ACPI-companion, so we are already using dynamic adapter-nrs.
3) There are 2 places manually instantiating a designware_i2c platform_dev:
drivers/mfd/intel_quark_i2c_gpio.c
drivers/mfd/intel-lpss.c
In the intel_quark_i2c_gpio.c case pdev->id is always 0, so switching to
dynamic adapter-nrs here could lead to the bus-number no longer being
stable, but the quark X1000 only has 1 i2c-controller, which will also
be assigned bus-number 0 when using dynamic adapter-nrs.
In the intel-lpss.c case intel_lpss_probe() is called from either
intel-lpss-acpi.c in which case there always is an ACPI-companion, or
from intel-lpss-pci.c. In most cases devices handled by intel-lpss-pci.c
also have an ACPI-companion, so we use a dynamic adapter-nr. But in some
cases the ACPI-companion is missing and we would use pdev->id (allocated
from intel_lpss_devid_ida). Devices which use the intel-lpss-pci.c code
typically have many i2c busses, so using pdev->id in this case may lead
to a bus-number conflict, triggering a WARN(id < 0, "couldn't get idr")
in i2c-core-base.c causing an oops an the adapter registration to fail.
So in this case using non dynamic adapter-nrs is actually undesirable.
One machine on which this oops was triggering is the Apollo Lake based
Acer TravelMate Spin B118.
TL;DR: Switching to always using dynamic adapter-numbers does not make
any difference in most cases and in the one case where it does make a
difference the behavior change is desirable because the old behavior
caused an oops.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1687065
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
i2c-designware-platdrv assumes that if the pdev has an apci-companion
it should use a dynamic adapter-nr and otherwise it will use pdev->id
as adapter-nr.
Before this commit the setting of the adapter.nr was somewhat convoluted,
in the acpi_companion case it was set from dw_i2c_acpi_configure, in the
non acpi_companion case it was set from dw_i2c_set_fifo_size based on
tx_fifo_depth not being set yet indicating that dw_i2c_acpi_configure was
not executed.
This cleans this up, directly setting the adapter-nr from
dw_i2c_plat_probe for both cases.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Make sure we report 'no buffer' for 0-length messages. This can only
happen if threshold is set to 0 which is kind of bogus but we should
still handle this situation. Update the docs and add a debug message
to educate callers of this function.
Reported-by: Hsin-Yi Wang <hsinyi@chromium.org>
Fixes: e94bc5d18b ("i2c: add helpers to ease DMA handling")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The changes for this cycle are across the board. The bulk of it is
cleanups, but there's also new device support in some drivers as well as
more conversions to the atomic API.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlyJFvUZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zobfREACTyAxr02GyEQFm4wLLV/OG
ynJ45IY2g/9OEY6RGmHQXzcBKycmFtifV6uF5PhMr0KZzdfp/uIMnyHsxV7Gm+ia
NNhG7gQPrb3yZev2AGmc6N/je2+5SL6AZH3+C5ocRqThNKKFknr3uZHbZpmTQlQf
QV63UYNpwtUrFu7jvzNz1kCBBUispXoDY44W0YSv8RYiKOxwJabPott0oOJH8miF
lVyCa2yyA8KuW1DTP13XSHMpmUwKGNkiqaFWGIMPFz6ViK5zj/rY92dUIwLegmh7
l/A7CBMCilw9yd9o1bhSWp2yUJ1gf8QeC64awa0euk9abgX574Nxt+vJsF8EtpaF
8aCcQrJpjlpPCQV4rP62G8Dcr7tWRNmKWKRNMaXQICpdhcLXuwg6tz4HH8z+I1um
W+w+9wsiqrRqKyqxlmQEXBi3qSPepJkU/DUsrE7QoO2jbmi21xyVIi1AQHXqNZYo
y2NzAADuh4i7L8AVFtJ1KcvdZZIBF/XrQXgXEgjX6fQpcs6aMyNOHTu9Xod7XW59
8yBKKqYmvSmmxDcFFfajkBuUbIuUqIzFxr4U6JYHQsWNnVN1ey+MSlZK6bHA8gw0
UngjRNv8fEAU0Hck2Z0iwDe1zHVW6g/ZNKZC2TUqzETPvZHg9QKt0sJYGkmxoR5O
JW1eTekpW57XahV2oX7f3g==
=TyJJ
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"The changes for this cycle are across the board.
The bulk of it is cleanups, but there's also new device support in
some drivers as well as more conversions to the atomic API"
* tag 'pwm/for-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (24 commits)
pwm: atmel: Remove useless symbolic definitions
pwm: bcm-kona: Update macros to remove braces around numbers
pwm: imx27: Only enable the clocks once in .get_state()
pwm: rcar: Improve calculation of divider
pwm: rcar: Remove legacy APIs
pwm: rcar: Use "atomic" API on rcar_pwm_resume()
pwm: rcar: Add support "atomic" API
pwm: atmel: Add support for SAM9X60's PWM controller
pwm: atmel: Add PWM binding for SAM9X60
pwm: atmel: Rename objects of type atmel_pwm_data
pwm: atmel: Add support for controllers with 32 bit counters
pwm: atmel: Add struct atmel_pwm_data
pwm: Add MediaTek MT8183 display PWM driver support
pwm: hibvt: Add hi3559v100 support
dt-bindings: pwm: hibvt: Add hi3559v100 support
pwm: hibvt: Use individual struct per of-data
pwm: imx: Signedness bug in imx_pwm_get_state()
pwm: imx: Split into two drivers
pwm: imx: Don't print an error on -EPROBE_DEFER
pwm: imx: Set driver data earlier simplifying the end of ->probe()
...
Pull crypto fixes from Herbert Xu:
"This fixes a bug in the newly added Exynos5433 AES code as well as an
old one in the caam driver"
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: caam - add missing put_device() call
crypto: s5p-sss - fix AES support for Exynos5433
Pull MD fixes from Song.
* 'for-5.1/md-post' of https://github.com/liu-song-6/linux:
md: Fix failed allocation of md_register_thread
It's wrong to add len to sector_nr in raid10 reshape twice
raid5: set write hint for PPL
* Fix nfit-bus command submission regression
* Support retrieval of short-ARS results if the ARS state is "requires
continuation", and even if the "no_init_ars" module parameter is
specified.
* Allow busy-polling of the kernel ARS state by allowing root to reset
the exponential back-off timer.
* Filter potentially stale ARS results by tracking query-ARS relative to
the previous start-ARS.
* Enhance dax_device alignment checks
* Add support for the Hyper-V family of device-specific-methods (DSMs)
* Add several fixes and workarounds for Hyper-V compatibility.
* Fix support to cache the dirty-shutdown-count at init.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJchsnlAAoJEB7SkWpmfYgCzNcP+gIsRwy2nklV78CoIX9rMOF+
8AF/o3kb+XbAGziTkFRk5SXsAGLQl1PNTzfaJDiBfS0vX6c3ja4cDhX4wgLi/w1c
2opBA3Fd1qAk2XXkOtQQ+yqFFxXR3zFV+Iflue39XJhwgR0yoY10mKEIGkelMur5
kOZjfWA6qseVGlyujHoM4Ta19Le88S3Yx1Da2jYTxHOYYnpRqq/epuO3hqojL/CT
GIrJFD6ayyuGjeA4CD3LsDAGgISQbLSRg1DXbCebmIsuoQ9TZeD7egqxjWKutcSU
xQVbI7Dw/dUKnAdo4DO9x0kMKV7XWDfpPOk4eZc3TSY/2g7muatsc3ZhY347F4Ia
3R9ox23WS1hd41jGbYT1CeKPvTnqnIZ6zwCEIRTq+exXSEp+lzOdF3De6olMcgYR
b37aKCR3PNZwF+esQ1XLA7tHLbLfdjY/TcFQET9i4vUMOlC/NeVpJY6g4kgd/1Lu
MNHu5NxTGtuK6Hp8zJESQ4X+yhhIMPd5VwOeDOjTzuLwgMA2c4MtXeZTABfuBe1W
bN6Kthv8mk5+CnEvXZDAEdSRijTo8inTmYQuIyaLSkWFhvANHKZX4xTc9VVhTW2I
8IONqBD3ZtFW+z+qTRB3VbOp7qj3/gA7F+T5C+MV8gj/YAO6hCzGYq8kUtQ4FeuO
OZwXxuFYY+iOOF1XEM3f
=wt4z
-----END PGP SIGNATURE-----
Merge tag 'libnvdimm-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
Pull libnvdimm updates from Dan Williams:
"The bulk of this has been in -next since before the merge window
opened, with no known collisions / issues reported.
The only detail worth noting, outside the summary below, is that the
"libnvdimm-start-pad" topic has been truncated to just cleanups and
small fixes. The full topic branch would have doubled down on hacks
around the "section alignment" limitation of the core-mm, instead
effort is now being spent to address that root issue in the memory
hotplug implementation for v5.2.
- Fix nfit-bus command submission regression
- Support retrieval of short-ARS results if the ARS state is
"requires continuation", and even if the "no_init_ars" module
parameter is specified
- Allow busy-polling of the kernel ARS state by allowing root to
reset the exponential back-off timer
- Filter potentially stale ARS results by tracking query-ARS relative
to the previous start-ARS
- Enhance dax_device alignment checks
- Add support for the Hyper-V family of device-specific-methods
(DSMs)
- Add several fixes and workarounds for Hyper-V compatibility
- Fix support to cache the dirty-shutdown-count at init"
* tag 'libnvdimm-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: (25 commits)
libnvdimm/namespace: Clean up holder_class_store()
libnvdimm/of_pmem: Fix platform_no_drv_owner.cocci warnings
acpi/nfit: Update NFIT flags error message
libnvdimm/btt: Fix LBA masking during 'free list' population
libnvdimm/btt: Remove unnecessary code in btt_freelist_init
libnvdimm/pfn: Remove dax_label_reserve
dax: Check the end of the block-device capacity with dax_direct_access()
nfit/ars: Avoid stale ARS results
nfit/ars: Allow root to busy-poll the ARS state machine
nfit/ars: Introduce scrub_flags
nfit/ars: Remove ars_start_flags
nfit/ars: Attempt short-ARS even in the no_init_ars case
nfit/ars: Attempt a short-ARS whenever the ARS state is idle at boot
acpi/nfit: Require opt-in for read-only label configurations
libnvdimm/pmem: Honor force_raw for legacy pmem regions
libnvdimm/pfn: Account for PAGE_SIZE > info-block-size in nd_pfn_init()
libnvdimm: Fix altmap reservation size calculation
libnvdimm, pfn: Fix over-trim in trim_pfn_device()
acpi/nfit: Fix bus command validation
libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
...
* Fix handling of PMD-sized entries in the Xarray that lead to a crash
scenario.
* Miscellaneous cleanups and small fixes
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJciDrAAAoJEB7SkWpmfYgCv2MQAMAnZ/FQ6HsVeqTp+/pZ3PTo
APLU8+sL35/7cxeEysy5+CIWMlUQ1nyt6NhDeCfCVKeYbW7A4HWmm1dbptMRzCMd
suSGGraw60oQb02iKxUdRB3NTA2voU0gHJKdmCjUljk5FwGHGYFcGXJwrRzYku9z
ZqL15cGzfbBwA+5C50ZxDcgk/MQ+lqcHoSLCq8rJyLm/Tf81xszCMIAZylAuyH5N
Li4jDlNABJh9EGB/WmQU0I61IyVYrTTVGHvDH3X2HAqkwpvroYBkRXhPcyqkntx2
jtv6OP9sU0k4bej2purGoatfVGZH84AUy9NRIFBG/SNvMxdb1ZfgSu3pccan92ar
t0cfWPSVl4nJJj8lLKiNDNruPJ+QU1IWOV+qaGp5J2ygePVgWifFfJxTDgVYTCrl
PY+Ijl3VClZvj0CQsNiaxvikYKWSyAClODua81sEgmd9JrpYzYBYe+xcxW0Zqv+z
adc5etbeAsponUVZRc2rgyCAD4Y97Ajbea07Oni6ZIaW0NMtvoY3qxI1Jbzp9VTi
E8y5NWKuaqOAGIBL1hy6WnD+33OqAW26Dbpa2xE7XarzRObzwK9JRuYF/Lr0xUMj
xXnYfHAJzU+vcunCZoXTYzrVv8i1FxJYvdOc1GbnkNUizAgFvhdpC2rqWH6bnTrl
1i1XOxR1M8wWocG8Hjac
=HwZT
-----END PGP SIGNATURE-----
Merge tag 'fsdax-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
Pull filesystem-dax updates from Dan Williams:
- Fix handling of PMD-sized entries in the Xarray that lead to a crash
scenario
- Miscellaneous cleanups and small fixes
* tag 'fsdax-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
dax: Flush partial PMDs correctly
fs/dax: NIT fix comment regarding start/end vs range
fs/dax: Convert to use vmf_error()
- A new interface for UBI to deal better with read disturb
- Reject unsupported ioctl flags in UBIFS (xfstests found it)
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEdgfidid8lnn52cLTZvlZhesYu8EFAlyHyMUWHHJpY2hhcmRA
c2lnbWEtc3Rhci5hdAAKCRBm+VmF6xi7wf9+EACFjPJaTJeLPHQofH3+u9O8gPzh
ptQFzkEcRrr7Y7WjXnYGhjw83Nx4o5iM17gfqq7zYfuCMxVbC8zm0WZ9Ujj3p7xV
p3IJ0bu/9sdIgdo+X9P8XJugAlWit1cW4mI8ZIAl2/CmYBzho8Zo55BNngNQ5G+Y
o3JujvP7TAHm9gbqIUMrGpweBHKX0GoooYZBTPdkLyKnFT0yxzOc/jdVILspIxi5
GtDl4738xV7Ts3Fwson1BVqDdwqLvd2j+LBWeRTSYXKyQLIizxRHtk1EZHZtBDZk
hWS/IW6HOzJJ5EQHn1EFAyQEGhfm4Yty+X0/BaPn8wvGE3Oud7bd9zgUCoBrhhTv
ztLPXY1U1LV8aTCmww6IOXwFj+6BGpj5fIu7my14aqGPKVV5M2kkf+prnLimb9QN
C3WxUz1Spz6CwrexoncvGm9ujoQbmwYLtKVNjRFIJ267OelaVD8icuAp1pZLSDom
1B6l39UQctrMiNqxuzJL+eq2raVZnnSQTlDqbUjFnUuU3LccRRNYgzhT1O6Ph50U
xqSO2k7Pf41/zZXhdB009HLecVL4gsZOunhGOE7Vv4kr7hin0AfrnoegdL37YG8W
GF6BNBgeegOxYDyvbOIWOxDqwyBWY2TPLJJ1IUE6j0lU6P1293IlsYHyTXUIK6bM
CQinKMNAXICWvXG0YQ==
=DlM9
-----END PGP SIGNATURE-----
Merge tag 'upstream-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs
Pull UBI and UBIFS updates from Richard Weinberger:
- A new interface for UBI to deal better with read disturb
- Reject unsupported ioctl flags in UBIFS (xfstests found it)
* tag 'upstream-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs:
ubi: wl: Silence uninitialized variable warning
ubifs: Reject unsupported ioctl flags explicitly
ubi: Expose the bitrot interface
ubi: Introduce in_pq()
Use regulator_set/get_current_limit_regmap helpers to save some code.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use regulator_set/get_current_limit_regmap helpers to save some code.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
.set_current_limit callback should select the current closest to max_uA.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
.set_current_limit callback should select the current closest to max_uA.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: d1c6b4fe66 ("regulator: Add WM831x LDO support")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: d4d6b722e7 ("regulator: Add WM831x ISINK support")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This driver has been converted to use regulator core's simplified DT
parsing code. So the match_init_data/match_of_node functions are not
necessary now, remove them.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The da903x driver produces an annoying false-positive warning
when built with clang:
drivers/regulator/da903x.c:395:2: error: division by zero is undefined [-Werror,-Wdivision-by-zero]
DA9030_LDO(13, 2100, 2100, 0, INVAL, 0, 0, RCTL11, 3), /* fixed @2.1V */
^ ~
drivers/regulator/da903x.c:359:2: note: expanded from macro 'DA9030_LDO'
DA903x_LDO(DA9030, _id, min, max, step, vreg, shift, nbits, ereg, ebit)
^ ~~~~
drivers/regulator/da903x.c:320:39: note: expanded from macro 'DA903x_LDO'
.n_voltages = (step) ? ((max - min) / step + 1) : 1, \
^ ~~~~
drivers/regulator/da903x.c:415:2: error: division by zero is undefined [-Werror,-Wdivision-by-zero]
DA9034_LDO(5, 3100, 3100, 0, INVAL, 0, 0, OVER3, 7), /* fixed @3.1V */
^ ~
drivers/regulator/da903x.c:356:2: note: expanded from macro 'DA9034_LDO'
DA903x_LDO(DA9034, _id, min, max, step, vreg, shift, nbits, ereg, ebit)
^ ~~~~
drivers/regulator/da903x.c:320:39: note: expanded from macro 'DA903x_LDO'
.n_voltages = (step) ? ((max - min) / step + 1) : 1, \
^ ~~~~
I already reported this as a bug in clang, but it may take a
while to fix it. As I have not been able to come up with any
reasonable workaround, I would just disable compilation here.
Link: https://bugs.llvm.org/show_bug.cgi?id=38789
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: f307a7e9b7 ("regulator: pv88060: new regulator driver")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 37b918a034 ("regulator: Add LTC3676 support")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 3eb2c7ecb7 ("regulator: Add LTC3589 support")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: b59320cc5a ("regulator: lp8755: new driver for LP8755")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 1028a37daa ("regulator: da9211: new regulator driver")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 69ca3e58d1 ("regulator: da9063: Add Dialog DA9063 voltage regulators support.")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: e4ee831f94 ("regulator: Add WM831x DC-DC buck convertor support")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: c90456e36d ("regulator: pv88090: new regulator driver")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 99cf3af5e2 ("regulator: pv88080: new regulator driver")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 4068e5182a ("regulator: da9062: DA9062 regulator driver")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: f6130be652 ("regulator: DA9055 regulator driver")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
gpio_regulator_voltage_ops and gpio_regulator_current_ops should never
change, make them const.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As reported back in 2016-11 [1], the "ftdump" kdb command triggers a
BUG for "sleeping function called from invalid context".
kdb's "ftdump" command wants to call ring_buffer_read_prepare() in
atomic context. A very simple solution for this is to add allocation
flags to ring_buffer_read_prepare() so kdb can call it without
triggering the allocation error. This patch does that.
Note that in the original email thread about this, it was suggested
that perhaps the solution for kdb was to either preallocate the buffer
ahead of time or create our own iterator. I'm hoping that this
alternative of adding allocation flags to ring_buffer_read_prepare()
can be considered since it means I don't need to duplicate more of the
core trace code into "trace_kdb.c" (for either creating my own
iterator or re-preparing a ring allocator whose memory was already
allocated).
NOTE: another option for kdb is to actually figure out how to make it
reuse the existing ftrace_dump() function and totally eliminate the
duplication. This sounds very appealing and actually works (the "sr
z" command can be seen to properly dump the ftrace buffer). The
downside here is that ftrace_dump() fully consumes the trace buffer.
Unless that is changed I'd rather not use it because it means "ftdump
| grep xyz" won't be very useful to search the ftrace buffer since it
will throw away the whole trace on the first grep. A future patch to
dump only the last few lines of the buffer will also be hard to
implement.
[1] https://lkml.kernel.org/r/20161117191605.GA21459@google.com
Link: http://lkml.kernel.org/r/20190308193205.213659-1-dianders@chromium.org
Reported-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Apply the HP_MIC_NO_PRESENCE fixups for the more HP Z2 G4 and
HP Z240 models.
Reported-by: Jeff Burrell <jeff.burrell@hp.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It will be lose Mic JD state when Chrome OS boot and headset was plugged.
Implement of reset combo jack JD. It will show normally.
Fixes: e854747d75 ("ALSA: hda/realtek - Enable headset button support for new codec")
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Acer TravelMate X514-51T with ALC255 cannot detect the headset MIC
until ALC255_FIXUP_ACER_HEADSET_MIC quirk applied. Although, the
internal DMIC uses another module - snd_soc_skl as the driver. We still
need the NID 0x1a in the quirk to enable the headset MIC.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The #ifdef protection around the PM functions is wrong, leading to
a failed reference in some configurations:
sound/pci/hda/hda_tegra.c: In function 'hda_tegra_runtime_suspend':
sound/pci/hda/hda_tegra.c:273:2: error: implicit declaration of function 'hda_tegra_disable_clocks'; did you mean 'hda_tegra_enable_clocks'? [-Werror=implicit-function-declaration]
Better remove the #ifdefs entirely and rely on the compiler silently
dropping unused functions marked __maybe_unused.
Fixes: 707e0759f2 ("ALSA: hda/tegra: implement runtime suspend/resume")
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
usb_alloc_urb() can fail due to kmalloc failure and push the error
upstream. Further this can cause a NULL pointer dereference in
init_pipe_urbs(). This patch avoids such a scenario.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Make sure to include <asm/nmi.h> to provide the following prototype:
hv_nmi_check_nonrecoverable.
Remove the following warning treated as error (W=1):
arch/powerpc/kernel/traps.c:393:6: error: no previous prototype for 'hv_nmi_check_nonrecoverable'
Fixes: ccd477028a ("powerpc/64s: Fix HV NMI vs HV interrupt recoverability test")
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Masahiro Yamada
Riku Voipio
Hans de Goede
Linus Torvalds
Wolfram Sang
Jens Axboe
Axel Lin
Steve Twiss
Arnd Bergmann
Douglas Anderson
Jaroslav Kysela
Kailang Yang
Jian-Hong Pan
zhengbin
Aditya Pakki
Mariusz Ceier
Mathieu Malaterre