Add support for the same output format as the bash script,
and use its implementation instead of the previous one.
I opted to do such patch in order to have a single script
responsible for parsing Documentation/features and
produce different outputs.
As someone may rely on the past format, which is easy
to parse it, get_feat.pl now gains a new command with
the same output format as the previous script.
As a side effect, the perl script is a lot faster, as it reads
each file only once, instead of parsing files several times
via a for command and grep commands inside it.
This patch also changes the features list order to be
case-insensitive, in order to better match the output of
the existing script.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/a97f49677805ad4e6b982d02c0db8c9dfbbd20a6.1606748711.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The Documentation/features contains a set of parseable files.
It is not worth converting them to ReST format, as they're
useful the way it is. It is, however, interesting to parse
them and produce output on different formats:
1) Output the contents of a feature in ReST format;
2) Output what features a given architecture supports;
3) Output a matrix with features x architectures.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/8b0c1ad06d689283a6d78c4ccd188a02c3acc0de.1606748711.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
v2: Fix some missing Sign offs from me that Greg found in v1.
Includes low priority/late breaking/long standing bug fixes.
Note this includes the last few patches that were listed in the description
for the previous pull request but weren't actually in the PULL.
New devices support
* bosch,bmc150-accel
- Support for BMA222, including adding binding doc that was previously
missing.
* st,lsm6dsx
- Support LSM6DSOP accelerometer + gyroscope sensor.
yaml-conversions by manufacturer
* core
- adc
- iio-binding (drop as now in dt-schema)
- temperature (drop as not clear it is generic)
* generic (no specific manufacturer)
- dpot-dac
- current-sense-amplifier
- current-sense-shunt
- envelope-detector
- voltage-divider
* adi,ad5592r adi,ad7124 adi,ad7292 adi,adf4350
* atmel,sama9260-adc
* bosch,bma180 bosch,bmg180
* brcm,iproc-static-adc
* capella,cm3605
* fsl,mma8452
* kionix,kxcjk1013
* maxim,max1027 (from trivial)
* mediatek,mt2701-auxdac
* microchip,mcp4531 (from trivial)
* qcom,pm8018-adc qcom,spi-iadc
* st,st-sensors
* ti,ads124s08 ti,afe4403 ti,afe4404 ti,lmp91000 ti,palmas-gpadc
Features
* bosch,bmc150
- Handle unusual ACPI binding where two devices are provided in a single
ACPI device (BOSC0200).
- ACPI based mount matrix handling
* st,hts221
- regulator control
* st,lsm6dsx
- regulator control
Cleanup + minor fixes
* core
- Reduce duplication in iio_format_avail_{list,range}() and iio_format_list()
- Fix an issue in the demux update code that could lead to misaligned data.
Possible no existing driver hits this. Been there a very long time with
no bug reports.
- Improve iio_map_array_register() error handling.
- Avoid polling driver again if try_reenable() callback returns non 0.
Only users of this were bugs so also drop the return value.
* core/cb_buffer
- Return an error if no callback provided (include adding a dummy for one
unusual case where no callback is valid).
* trigger/hrtimer-trig, sysfs-trig
- Fix an issue seen with PREEMPT_RT by marking irq_work as expiring in hard
interrupt context.
* adi,ad_sigma_delta library
- Avoid putting SPI transfer buffers on stack for DMA safety reasons
* adi,ad5272
- Fix discrepancy in polarity of reset line between binding documentation
(which was right) and driver.
* adi,ad7298
- Use devm for all of probe
* atmel,at91_adc
- Drop at91_adc_ids as only support DT probe
- Simplify resolution selection and bindings
- Drop binding for triggers and move into driver based on compatible.
- Merge at91_adc_probe_dt() into main at91_adc_probe()
* bosch,bmc150
- Drop unused structure member.
* bosch,bmi160
- Fix overly long buffer due to wrong channel count.
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* fsl,mag3110
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* fsl,mpl3115
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* invn,mpu3050
- Use 64 bit local variable and FIELD_GET to simplify code that extracts
values from OTP.
* qcom,spmi-vadc
- Drop wrong use of io-channel-ranges in binding doc.
* rockchip,saradc
- Fix a missing clk_disable_unprepare() in an error path.
* rohm,rpr0521
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* samsung,exynos-adc
- Drop wrong use of io-channel-ranges in binding doc.
* st,lsm6dsx
- Reduce duplication in the chip model specific tables.
- Fix an issue with missed edge-interrupts that can occur when using
the FIFO.
* st,uvis21
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* ti,adc084s021
- Tidy up endian types to clear a warning.
* ti,ads124s08
- Fix too long a buffer.
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
Counter
* microchip,tcb-counter
- Add Kamel Bouhara to MAINTAINERS
- Fix CMR value check
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAl/JP7cRHGppYzIzQGtl
cm5lbC5vcmcACgkQVIU0mcT0FojIDRAAgm7Evn9xropmg1LY3GdPuaEXrK3PMTCK
l2/YQSbtb2LMMNUgFCPypuxXnPDaASNY/iORQACZ2bPyO89I1F8cZjFK214G8uRb
YuVP60/j1qRbT42LmgNH+mPz5ANseguDcz63/RIcXYXrIADJqpfPUHPSsgv9asGF
a1aKhn7G3z17DUSAQKNhYkXQ1O1ojwTaXNPPklfV0+G6oJJ6zD7/jNCQh+KxZPXo
GNLaSJh2jHNqrSPhScQeB6RMy6GEAF8PMYHK38A6S/UldO8YuuZLeRGqWKaC1v9j
67CuDVwkGZ2NHpv4/aU3wUGYbxU2sPpF9HZLiqxCkFOlhMK00XM3susMndjkdApT
gB2KuhMIRDjsoE/GievcZxwCGuWvnO7A47lk6hLbFGzxRzzr8qZ44e4VT0/4jPD9
NkqDrF0/u1WqdLPkD7vFMT0FjKhXaeIYxpNmD9z6HiUdFHgFwrrd2d58mEGP4EKt
YVlGd3tZh4giP56W30Yd96fk5B5JtLr33mXk9+9aOJa+tMI6rPLHgCPm2AklVeMF
7ZtG+1so1AdXAyDeeBw9f0nyjikcIfTEMrwxd223QKH7q9SYQ6UCuj6UqOp1laQK
OKAPVTouPrgjSf4pRbwU0LETjMj9qIpSPhMSQ2xVYU5dgzj5TvtYe/Ew+oFqd7nQ
GpBgXmyjnL0=
=1uz5
-----END PGP SIGNATURE-----
Merge tag 'iio-for-5.11b-take2' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
2nd set of IIO device support, features, cleanups and yaml conversions for 5.11
v2: Fix some missing Sign offs from me that Greg found in v1.
Includes low priority/late breaking/long standing bug fixes.
Note this includes the last few patches that were listed in the description
for the previous pull request but weren't actually in the PULL.
New devices support
* bosch,bmc150-accel
- Support for BMA222, including adding binding doc that was previously
missing.
* st,lsm6dsx
- Support LSM6DSOP accelerometer + gyroscope sensor.
yaml-conversions by manufacturer
* core
- adc
- iio-binding (drop as now in dt-schema)
- temperature (drop as not clear it is generic)
* generic (no specific manufacturer)
- dpot-dac
- current-sense-amplifier
- current-sense-shunt
- envelope-detector
- voltage-divider
* adi,ad5592r adi,ad7124 adi,ad7292 adi,adf4350
* atmel,sama9260-adc
* bosch,bma180 bosch,bmg180
* brcm,iproc-static-adc
* capella,cm3605
* fsl,mma8452
* kionix,kxcjk1013
* maxim,max1027 (from trivial)
* mediatek,mt2701-auxdac
* microchip,mcp4531 (from trivial)
* qcom,pm8018-adc qcom,spi-iadc
* st,st-sensors
* ti,ads124s08 ti,afe4403 ti,afe4404 ti,lmp91000 ti,palmas-gpadc
Features
* bosch,bmc150
- Handle unusual ACPI binding where two devices are provided in a single
ACPI device (BOSC0200).
- ACPI based mount matrix handling
* st,hts221
- regulator control
* st,lsm6dsx
- regulator control
Cleanup + minor fixes
* core
- Reduce duplication in iio_format_avail_{list,range}() and iio_format_list()
- Fix an issue in the demux update code that could lead to misaligned data.
Possible no existing driver hits this. Been there a very long time with
no bug reports.
- Improve iio_map_array_register() error handling.
- Avoid polling driver again if try_reenable() callback returns non 0.
Only users of this were bugs so also drop the return value.
* core/cb_buffer
- Return an error if no callback provided (include adding a dummy for one
unusual case where no callback is valid).
* trigger/hrtimer-trig, sysfs-trig
- Fix an issue seen with PREEMPT_RT by marking irq_work as expiring in hard
interrupt context.
* adi,ad_sigma_delta library
- Avoid putting SPI transfer buffers on stack for DMA safety reasons
* adi,ad5272
- Fix discrepancy in polarity of reset line between binding documentation
(which was right) and driver.
* adi,ad7298
- Use devm for all of probe
* atmel,at91_adc
- Drop at91_adc_ids as only support DT probe
- Simplify resolution selection and bindings
- Drop binding for triggers and move into driver based on compatible.
- Merge at91_adc_probe_dt() into main at91_adc_probe()
* bosch,bmc150
- Drop unused structure member.
* bosch,bmi160
- Fix overly long buffer due to wrong channel count.
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* fsl,mag3110
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* fsl,mpl3115
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* invn,mpu3050
- Use 64 bit local variable and FIELD_GET to simplify code that extracts
values from OTP.
* qcom,spmi-vadc
- Drop wrong use of io-channel-ranges in binding doc.
* rockchip,saradc
- Fix a missing clk_disable_unprepare() in an error path.
* rohm,rpr0521
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* samsung,exynos-adc
- Drop wrong use of io-channel-ranges in binding doc.
* st,lsm6dsx
- Reduce duplication in the chip model specific tables.
- Fix an issue with missed edge-interrupts that can occur when using
the FIFO.
* st,uvis21
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* ti,adc084s021
- Tidy up endian types to clear a warning.
* ti,ads124s08
- Fix too long a buffer.
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
Counter
* microchip,tcb-counter
- Add Kamel Bouhara to MAINTAINERS
- Fix CMR value check
* tag 'iio-for-5.11b-take2' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (80 commits)
iio: adc: rockchip_saradc: fix missing clk_disable_unprepare() on error in rockchip_saradc_resume
iio: imu: st_lsm6dsx: fix edge-trigger interrupts
counter: microchip-tcb-capture: Fix CMR value check
iio: sysfs-trigger: Mark irq_work to expire in hardirq context
iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt context
iio: accel: bmc150: Get mount-matrix from ACPI
iio: accel: bmc150: Check for a second ACPI device for BOSC0200
iio: accel: bmc150: Removed unused bmc150_accel_dat irq member
iio:gyro:mpu3050 Treat otp value as a __le64 and use FIELD_GET() to break up
iio:adc:ti-ads124s08: Fix alignment and data leak issues.
iio:adc:ti-ads124s08: Fix buffer being too long.
iio:pressure:mpl3115: Force alignment of buffer
iio:imu:bmi160: Fix alignment and data leak issues
iio:imu:bmi160: Fix too large a buffer.
iio:magnetometer:mag3110: Fix alignment and data leak issues.
iio:light:st_uvis25: Fix timestamp alignment and prevent data leak.
iio:light:rpr0521: Fix timestamp alignment and prevent data leak.
iio:adc:ti-adc084s021 Tidy up endian types
iio:trigger: rename try_reenable() to reenable() plus return void
iio: Fix: Do not poll the driver again if try_reenable() callback returns non 0.
...
Florian Westphal says:
====================
mptcp: reject invalid mp_join requests right away
At the moment MPTCP can detect an invalid join request (invalid token,
max number of subflows reached, and so on) right away but cannot reject
the connection until the 3WHS has completed.
Instead the connection will complete and the subflow is reset afterwards.
To send the reset most information is already available, but we don't have
good spot where the reset could be sent:
1. The ->init_req callback is too early and also doesn't allow to return an
error that could be used to inform the TCP stack that the SYN should be
dropped.
2. The ->route_req callback lacks the skb needed to send a reset.
3. The ->send_synack callback is the best fit from the available hooks,
but its called after the request socket has been inserted into the queue
already. This means we'd have to remove it again right away.
From a technical point of view, the second hook would be best:
1. Its before insertion into listener queue.
2. If it returns NULL TCP will drop the packet for us.
Problem is that we'd have to pass the skb to the function just for MPTCP.
Paolo suggested to merge init_req and route_req callbacks instead:
This makes all info available to MPTCP -- a return value of NULL drops the
packet and MPTCP can send the reset if needed.
Because 'route_req' has a 'const struct sock *', this means either removal
of const qualifier, or a bit of code churn to pass 'const' in security land.
This does the latter; I did not find any spots that need write access to struct
sock.
To recap, the two alternatives are:
1. Solve it entirely in MPTCP: use the ->send_synack callback to
unlink the request socket from the listener & drop it.
2. Avoid 'security' churn by removing the const qualifier.
====================
Link: https://lore.kernel.org/r/20201130153631.21872-1-fw@strlen.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
RFC 8684 says:
If the token is unknown or the host wants to refuse subflow establishment
(for example, due to a limit on the number of subflows it will permit),
the receiver will send back a reset (RST) signal, analogous to an unknown
port in TCP, containing an MP_TCPRST option (Section 3.6) with an
"MPTCP specific error" reason code.
mptcp-next doesn't support MP_TCPRST yet, this can be added in another
change.
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Multipath-TCP standard (RFC 8684) says that an MPTCP host should send
a TCP reset if the token in a MP_JOIN request is unknown.
At this time we don't do this, the 3whs completes and the 'new subflow'
is reset afterwards. There are two ways to allow MPTCP to send the
reset.
1. override 'send_synack' callback and emit the rst from there.
The drawback is that the request socket gets inserted into the
listeners queue just to get removed again right away.
2. Send the reset from the 'route_req' function instead.
This avoids the 'add&remove request socket', but route_req lacks the
skb that is required to send the TCP reset.
Instead of just adding the skb to that function for MPTCP sake alone,
Paolo suggested to merge init_req and route_req functions.
This saves one indirection from syn processing path and provides the skb
to the merged function at the same time.
'send reset on unknown mptcp join token' is added in next patch.
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A followup change to tcp_request_sock_op would have to drop the 'const'
qualifier from the 'route_req' function as the
'security_inet_conn_request' call is moved there - and that function
expects a 'struct sock *'.
However, it turns out its also possible to add a const qualifier to
security_inet_conn_request instead.
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: James Morris <jamorris@linux.microsoft.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Set up all the parameters required for SMU fan control if supported.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=201539
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The function name at kernel-doc markup doesn't match the name
of the function:
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1534: warning: expecting prototype for amdgpu_debugfs_print_bo_info(). Prototype was for amdgpu_bo_print_info() instead
Fix it.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CAN0 and CAN1 instances share the same message ram configured
at 0x210000 on sama5d2 Linux systems.
According to current configuration of CAN0, we need 0x1c00 bytes
so that the CAN1 don't overlap its message ram:
64 x RX FIFO0 elements => 64 x 72 bytes
32 x TXE (TX Event FIFO) elements => 32 x 8 bytes
32 x TXB (TX Buffer) elements => 32 x 72 bytes
So a total of 7168 bytes (0x1C00).
Fix offset to match this needed size.
Make the CAN0 message ram ioremap match exactly this size so that is
easily understandable. Adapt CAN1 size accordingly.
Fixes: bc6d5d7666 ("ARM: dts: at91: sama5d2: add m_can nodes")
Reported-by: Dan Sneddon <dan.sneddon@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Tested-by: Cristian Birsan <cristian.birsan@microchip.com>
Cc: stable@vger.kernel.org # v4.13+
Link: https://lore.kernel.org/r/20201203091949.9015-1-nicolas.ferre@microchip.com
Due to strobe signal not being propagated from CPU to securam
the securam needs to be mapped as device or strongly ordered memory
to work properly. Otherwise, updating to one offset may affect
the adjacent locations in securam.
Fixes: d4ce5f44d4 ("ARM: dts: at91: sama5d2: Add securam node")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/1606903025-14197-3-git-send-email-claudiu.beznea@microchip.com
atmel,osc-bypass property sets the bit 1 at main oscillator register.
On SAM9X60 this bit is not valid according to datasheet (chapter
28.16.9 PMC Clock Generator Main Oscillator Register).
Fixes: 1e5f532c27 ("ARM: dts: at91: sam9x60: add device tree for soc and board")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Marco Cardellini <marco.cardellini@microchip.com>
Link: https://lore.kernel.org/r/1606903025-14197-2-git-send-email-claudiu.beznea@microchip.com
Commit 2024b130b0 ("ARM: dts: exynos: Add Ethernet to Artik 5 board")
added ethernet chip on SPI0 bus and the whole bunch of assigned clock
entries to ensure proper clock rates and topology. Limit the assigned
clock parents only to the direct clocks of the SPI0 device and assume
that MPLL clock is already properly configured.
The applied clock topology was incorrect as some clocks between were
missing, what resulted in the following warning:
clk: failed to reparent div_mpll_pre to mout_mpll: -22
Fixes: 2024b130b0 ("ARM: dts: exynos: Add Ethernet to Artik 5 board")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20201202122029.22198-1-m.szyprowski@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
My patch caused kernel Oopses and delays in boot. Revert it.
The problem was that I moved the "mem->dma = paddr;" before the call to
be_fill_queue(). But the first thing that the be_fill_queue() function
does is memset the whole struct to zero which overwrites the assignment.
Link: https://lore.kernel.org/r/X8jXkt6eThjyVP1v@mwanda
Fixes: 38b2db564d ("scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs()")
Cc: stable <stable@vger.kernel.org>
Reported-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Expand the driver to support I2C_SMBUS_BLOCK_PROC_CALL since
HW supports it already.
Co-developed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mario Alejandro Posso Escobar <mario.posso.escobar@intel.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Since commit 7723f4c5ec ("driver core: platform: Add an error message to
platform_get_irq*()"), platform_get_irq() will call dev_err() on an error.
In case of i2c ocores this leads to a false-positive error being logged:
[ 4.173989] 007: ocores-i2c ocores-i2c: IRQ index 0 not found
i2c ocores already handles the case when the IRQ cannot be found and
therefore there is no benefit in having this error message being logged.
This commit switches to platform_get_irq_optional(), which does not log
in case the IRQ cannot be found.
Signed-off-by: Stefan Lässer <stefan.laesser@omicronenergy.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
A combination of recent bug fixes by Doug Anderson and the proper
definition of iommu streams means that this hack is no longer needed.
Let's clean up the code by reverting '127068abe85b ("i2c: qcom-geni:
Disable DMA processing on the Lenovo Yoga C630")'.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Caleb Connolly <caleb@connolly.tech>
Tested-by: Steev Klimaszewski <steev@kali.org>
Reviewed-by: Akash Asthana <akashast@codeaurora.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
This object lives inside the trunner output dir,
i.e. tools/testing/selftests/bpf/no_alu32/btf_data.o
At some point it gets copied into the parent directory during another
part of the build, but that doesn't happen when building
test_progs-no_alu32 from clean.
Signed-off-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Link: https://lore.kernel.org/bpf/20201203120850.859170-1-jackmanb@google.com
I've seen a situation, where a process that's under pprof constantly
generates SIGPROF which prevents program loading indefinitely.
The right thing to do probably is to disable signals in the upper
layers while loading, but it still would be nice to get some error from
libbpf instead of an endless loop.
Let's add some small retry limit to the program loading:
try loading the program 5 (arbitrary) times and give up.
v2:
* 10 -> 5 retires (Andrii Nakryiko)
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20201202231332.3923644-1-sdf@google.com
- fix logical vs physical CPU address confusion in PCI code
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEECMNfWEw3SLnmiLkZIg7DeRspbsIFAl/JNlgACgkQIg7DeRsp
bsKdgA//TQrq8oN33N/kCGcqLqXito9c5hLVUDapGYvBF9eJmjDoWPYJln6y8yRa
PUmzH2ONKyJNXbbPrj8/YP2qYwUZ/gL5ehussdxNU57ZQ7+uX20GrXjTsjIJFO/T
X2EXhk79iBfO0rbayZvxEJZVRrEXiDGrRWouZwUDiR08BLrFCugTP7u+kc4W4BJu
nxPkPi8TrGAD6hMVUv8In2w5rnHzjnHyrCRZPvCFSf2d3zxn+vlb0ZT5sgmqoZKb
xqfJhvJPZNcl4D58diHGWNWOZDw2su9CQG9OcZrv6PSexzDCPU4+GdZpr0Jc5HQ5
TE3u3CFpQEORNCFjPP4ailptqpIN1/7Y6ZA5xOwgdAeU0kFvpRhkd3Nftpl1gqkl
VI4eEAIJ3+2ob2WKWlX6ecIS82YyH03avskWyfj6MoAtRkICJKVWYdTEHGZwswcY
JYmL8tg0nq/UuAepdGReh61LjSatQDY9Z4DSU0U9Y02231mpSxZ8sYuv/YlMQp49
pJX3G6Yi4G3Mz+w9mt6Ly5Iq7mzwRLoHgzkPQvbhnnXgCOnWI6PyzqWhlqztZ/At
/3qdxn8NpD2POJbdSSWPlqCVXLQHEtQN1QRi6f/awsJ5vT8bTqTEvQj8y79IeBJO
5Wx2wbXAuvzCNEoQOKRFJV1Ddtono+idAMVRTwTUv1jUfxE2MIE=
=NaIp
-----END PGP SIGNATURE-----
Merge tag 's390-5.10-6' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Heiko Carstens:
"One commit is fixing lockdep irq state tracing which broke with -rc6.
The other one fixes logical vs physical CPU address mixup in our PCI
code.
Summary:
- fix lockdep irq state tracing
- fix logical vs physical CPU address confusion in PCI code"
* tag 's390-5.10-6' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390: fix irq state tracing
s390/pci: fix CPU address in MSI for directed IRQ
When we added sanitising of map names before loading programs to libbpf, we
still allowed periods in the name. While the kernel will accept these for
the map names themselves, they are not allowed in file names when pinning
maps. This means that bpf_object__pin_maps() will fail if called on an
object that contains internal maps (such as sections .rodata).
Fix this by replacing periods with underscores when constructing map pin
paths. This only affects the paths generated by libbpf when
bpf_object__pin_maps() is called with a path argument. Any pin paths set
by bpf_map__set_pin_path() are unaffected, and it will still be up to the
caller to avoid invalid characters in those.
Fixes: 113e6b7e15 ("libbpf: Sanitise internal map names so they are not rejected by the kernel")
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20201203093306.107676-1-toke@redhat.com
Fix the missing clk_disable_unprepare() of info->pclk
before return from rockchip_saradc_resume in the error
handling case when fails to prepare and enable info->clk.
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Fixes: 44d6f2ef94 ("iio: adc: add driver for Rockchip saradc")
Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201103120743.110662-1-miaoqinglang@huawei.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
If we are using edge IRQs, new samples can arrive while processing
current interrupt since there are no hw guarantees the irq line
stays "low" long enough to properly detect the new interrupt.
In this case the new sample will be missed.
Polling FIFO status register in st_lsm6dsx_handler_thread routine
allow us to read new samples even if the interrupt arrives while
processing previous data and the timeslot where the line is "low"
is too short to be properly detected.
Fixes: 89ca88a7cd ("iio: imu: st_lsm6dsx: support active-low interrupts")
Fixes: 290a6ce11d ("iio: imu: add support to lsm6dsx driver")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/5e93cda7dc1e665f5685c53ad8e9ea71dbae782d.1605378871.git.lorenzo@kernel.org
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ATMEL_TC_ETRGEDG_* defines are not masks but rather possible values
for CMR. This patch fixes the action_get() callback to properly check
for these values rather than mask them.
Fixes: 106b104137 ("counter: Add microchip TCB capture counter")
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201114232805.253108-1-vilhelm.gray@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Mark the IIO sysfs-trigger irq_work with IRQ_WORK_HARD_IRQ to ensure that
it is always executed in hard interrupt context, even with PREEMPT_RT=y.
The IIO sysfs-trigger irq_work needs to run in hard interrupt context since
it will end up calling generic_handle_irq() which has the requirement to
run in hard interrupt context.
Note that the IRQ_WORK_HARD_IRQ flag, while it exists, does not seem to do
anything in the mainline kernel yet. It does have an effect in the RT
patchset though and presumably this is sooner or later going to be added to
mainline as well.
Reported-by: Christian Eggers <ceggers@arri.de>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20201117103751.16131-2-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft
interrupt expiry mode by default.
The IIO hrtimer-trigger needs to run in hard interrupt context since it
will end up calling generic_handle_irq() which has the requirement to run
in hard interrupt context.
Explicitly specify that the timer needs to run in hard interrupt context by
using the HRTIMER_MODE_REL_HARD flag.
Fixes: f5c2f0215e ("hrtimer: Move unmarked hrtimers to soft interrupt expiry on RT")
Reported-by: Christian Eggers <ceggers@arri.de>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20201117103751.16131-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
bmc150 accelerometers with an ACPI hardware-id of BOSC0200 have an ACPI
method providing their mount-matrix, add support for retrieving this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20201130141954.339805-3-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI
device. Normally we would handle this by letting the special
drivers/platform/x86/i2c-multi-instantiate.c driver handle the BOSC0200
ACPI id and let it instantiate 2 bmc150_accel type i2c_client-s for us.
But doing so changes the modalias for the first accelerometer
(which is already supported and used on many devices) from
acpi:BOSC0200 to i2c:bmc150_accel. The modalias is not only used
to load the driver, but is also used by hwdb matches in
/lib/udev/hwdb.d/60-sensor.hwdb which provide a mountmatrix to
userspace by setting the ACCEL_MOUNT_MATRIX udev property.
Switching the handling of the BOSC0200 over to i2c-multi-instantiate.c
will break the hwdb matches causing the ACCEL_MOUNT_MATRIX udev prop
to no longer be set. So switching over to i2c-multi-instantiate.c is
not an option.
Changes by Hans de Goede:
-Add explanation to the commit message why i2c-multi-instantiate.c
cannot be used
-Also set the dev_name, fwnode and irq i2c_board_info struct members
for the 2nd client
Signed-off-by: Jeremy Cline <jeremy@jcline.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20201130141954.339805-2-hdegoede@redhat.com
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198671
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The bmc150_accel_dat struct irq member is only ever used inside
bmc150_accel_core_probe, drop it and just use the function argument
directly.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20201130141954.339805-1-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Inspired by Andy Shevchenko's proposal to use get_unaligned_leXX().
The whole one time programable memory is treated as a single 64bit
little endian value. Thus we can avoid a lot of messy handling
of fields overlapping byte boundaries by just loading and manipulating
it as an __le64 converted to a u64. That lets us just use FIELD_GET()
and GENMASK() to extract the values desired.
Note only build tested. We need to use GENMASK_ULL and %llX formatters
to account for the larger types used in computing the various fields.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201128185156.428327-1-jic23@kernel.org
Link: https://lore.kernel.org/r/20201129184459.647538-1-jic23@kernel.org
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc() so no
data can leak apart from previous readings.
In this driver the timestamp can end up in various different locations
depending on what other channels are enabled. As a result, we don't
use a structure to specify it's position as that would be misleading.
Fixes: e717f8c6df ("iio: adc: Add the TI ads124s08 ADC code")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-9-jic23@kernel.org
The buffer is expressed as a u32 array, yet the extra space for
the s64 timestamp was expressed as sizeof(s64)/sizeof(u16).
This will result in 2 extra u32 elements.
Fix by dividing by sizeof(u32).
Fixes: e717f8c6df ("iio: adc: Add the TI ads124s08 ADC code")
Signed-off-by: Jonathan Cameron<Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-8-jic23@kernel.org
Whilst this is another case of the issue Lars reported with
an array of elements of smaller than 8 bytes being passed
to iio_push_to_buffers_with_timestamp(), the solution here is
a bit different from the other cases and relies on __aligned
working on the stack (true since 4.6?)
This one is unusual. We have to do an explicit memset() each time
as we are reading 3 bytes into a potential 4 byte channel which
may sometimes be a 2 byte channel depending on what is enabled.
As such, moving the buffer to the heap in the iio_priv structure
doesn't save us much. We can't use a nice explicit structure
on the stack either as the data channels have different storage
sizes and are all separately controlled.
Fixes: cc26ad455f ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-7-jic23@kernel.org
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable array in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc() so no
data can leak apart from previous readings.
In this driver, depending on which channels are enabled, the timestamp
can be in a number of locations. Hence we cannot use a structure
to specify the data layout without it being misleading.
Fixes: 77c4ad2d6a ("iio: imu: Add initial support for Bosch BMI160")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Daniel Baluta <daniel.baluta@oss.nxp.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org
The comment implies this device has 3 sensor types, but it only
has an accelerometer and a gyroscope (both 3D). As such the
buffer does not need to be as long as stated.
Note I've separated this from the following patch which fixes
the alignment for passing to iio_push_to_buffers_with_timestamp()
as they are different issues even if they affect the same line
of code.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Daniel Baluta <daniel.baluta@oss.nxp.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-5-jic23@kernel.org
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data.
This data is allocated with kzalloc() so no data can leak apart from
previous readings.
The explicit alignment of ts is not necessary in this case but
does make the code slightly less fragile so I have included it.
Fixes: 39631b5f95 ("iio: Add Freescale mag3110 magnetometer driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv()
This data is allocated with kzalloc() so no data can leak apart
from previous readings.
A local unsigned int variable is used for the regmap call so it
is clear there is no potential issue with writing into the padding
of the structure.
Fixes: 3025c8688c ("iio: light: add support for UVIS25 sensor")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-3-jic23@kernel.org
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv().
This data is allocated with kzalloc() so no data can leak apart
from previous readings and in this case the status byte from the device.
The forced alignment of ts is not necessary in this case but it
potentially makes the code less fragile.
>From personal communications with Mikko:
We could probably split the reading of the int register, but it
would mean a significant performance cost of 20 i2c clock cycles.
Fixes: e12ffd241c ("iio: light: rpr0521 triggered buffer")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Mikko Koivunen <mikko.koivunen@fi.rohmeurope.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-2-jic23@kernel.org
By adding a few local variables and avoiding a void * for
a parameter we can easily make all the endian types explicit and
get rid of the warnings from sparse:
CHECK drivers/iio/adc/ti-adc084s021.c
drivers/iio/adc/ti-adc084s021.c:84:26: warning: incorrect type in assignment (different base types)
drivers/iio/adc/ti-adc084s021.c:84:26: expected unsigned short [usertype]
drivers/iio/adc/ti-adc084s021.c:84:26: got restricted __be16
drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16
drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16
drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16
drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200722155103.979802-23-jic23@kernel.org
As we no longer support a try again if we cannot reenable the trigger
rename the function to reflect this. Also we don't do anything with
the value returned so stop it returning anything. For the few drivers
that didn't already print an error message in this patch, add such
a print.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Christian Oder <me@myself5.de>
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Nishant Malpani <nish.malpani25@gmail.com>
Cc: Daniel Baluta <daniel.baluta@oss.nxp.com>
Link: https://lore.kernel.org/r/20200920132548.196452-3-jic23@kernel.org
The original reason for this behaviour is long gone and no current
drivers are making use of this function correctly. Note however, that
you would be very unlucky to actually hit the problem as it would
require a bus comms failure in the callback.
This dates back a long way. The original board on which I did a lot
of early IIO development only supported edge interrupts, but some of the
sensors were level interrupt based. As such, the lis3l02dq driver did
a dance with checking a GPIO to identify if it should retrigger.
That was an unsustainable hack so we later just stopped supporting interrupts
for that particular combination.
There are a number of drivers where a fault on a bus read in the
try_reenable() callback will result in them returning non 0 and
incorrectly then causing iio_trigger_poll() to be called.
Anyhow, this handling is unused and causing issues so let us rip it out.
Link: https://lore.kernel.org/linux-iio/20200813075358.13310-1-lars@metafoo.de/
After this the try_reenable() naming makes no sense, so as a follow up
patch I'll rename it to simply reenable(). I haven't done that here
as it will add noise to the fix for backporting.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Christian Eggers <ceggers@arri.de>
Link: https://lore.kernel.org/r/20200920132548.196452-2-jic23@kernel.org
In function iio_map_array_register() properly rewind in case of error.
Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/1606571059-13974-2-git-send-email-LinoSanfilippo@gmx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Introduce an unlocked version of iio_map_array_unregister(). This function
can help to unwind in case of error while the iio_map_list_lock mutex is
held.
Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/1606571059-13974-1-git-send-email-LinoSanfilippo@gmx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
