| Age | Commit message (Collapse) | Author |
|---|
|
This is the 4.12.24 stable release
|
|
commit 6e0c9507bf51e1517a80ad0ac171e5402528fcef upstream.
On Apollo Lake devices the BIOS does not set up IRQ routing for the i801
SMBUS controller IRQ, so we end up with dev->irq set to IRQ_NOTCONNECTED.
Detect this and do not try to use the irq in this case silencing:
i801_smbus 0000:00:1f.1: Failed to allocate irq -2147483648: -107
Cc: stable@vger.kernel.org
BugLink: https://communities.intel.com/thread/114759
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
commit 71e691f8dee3706d160dcf8b765ddecfc4e74d9b from
https://github.com/altera-opensource/linux-socfpga.git
This reverts commit 84316f46573780c07a4ecb8933b4516d3265a87c.
Signed-off-by: Alan Tull <atull@kernel.org>
Signed-off-by: Meng Li <Meng.Li@windriver.com>
|
|
commit 84316f46573780c07a4ecb8933b4516d3265a87c from
https://github.com/altera-opensource/linux-socfpga.git
This is a temporary workaround that:
* will not be submitted upstream
* will be reverted when the clock driver is fixed
Currently there are issues with writing to the stratix 10 clock
controller registers. This commit allows the i2c controller to work
without doing any clock controller register access since we know the
clocks are enabled and we know what frequency they are.
This workaround is enabled by a setting in the stratix 10 dts, so it
will not affect other platforms that don't have this setting.
Signed-off-by: Alan Tull <atull@kernel.org>
Signed-off-by: Meng Li <Meng.Li@windriver.com>
|
|
commit 09a1de04d59870b34b2a8106671c7bdea4ca9a90 upstream.
Added SMBUS PCI Ids for SMBUS for Cannon Lake PCH.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[jarkko.nikula@linux.intel.com: Add entries to Documentation and Kconfig.
Cover Cannon Lake-H too]
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
This is the 4.12.17 stable release
|
|
commit 0fe16195f89173652cf111d7b384941b00c5aabd upstream.
AMD Family 17h uses the KERNCZ SMBus controller. While its documentation
is not publicly available, it is documented in the BIOS and Kernel
Developer’s Guide for AMD Family 15h Models 60h-6Fh Processors.
On this SMBus controller, the port select register is at PMx register
0x02, bit 4:3 (PMx00 register bit 20:19).
Without this patch, the 4 SMBus channels on AMD Family 17h chips are
mirrored and report the same chips on all channels.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
commit bfd4473b850c8cfaa1cdf56b8ef52fae4e8a6ee5 upstream.
Sun, Yunying reported the following failure on Denverton micro-server:
EDAC DEBUG: pnd2_init:
EDAC DEBUG: pnd2_probe:
EDAC DEBUG: dnv_rd_reg: Read b_cr_tolud_pci=00000000_80000000
EDAC DEBUG: dnv_rd_reg: Read b_cr_touud_lo_pci=00000000_80000000
EDAC DEBUG: dnv_rd_reg: Read b_cr_touud_hi_pci=00000000_00000004
EDAC DEBUG: dnv_rd_reg: Read b_cr_asym_mem_region0_mchbar=00000000_00000000
EDAC DEBUG: dnv_rd_reg: Read b_cr_asym_mem_region1_mchbar=00000000_00000000
EDAC DEBUG: dnv_rd_reg: Read b_cr_mot_out_base_mchbar=00000000_00000000
EDAC DEBUG: dnv_rd_reg: Read b_cr_mot_out_mask_mchbar=00000000_00000000
EDAC pnd2: Failed to register device with error -19.
On Denverton micro-server, the presence of the P2SB bridge PCI device is
enabled or disabled by the item 'RelaxSecConf' in BIOS setup menu. When
'RelaxSecConf' is enabled, the P2SB PCI device is present and the pnd2_edac
EDAC driver also uses it to get BAR. Hiding the P2SB PCI device caused the
pnd2_edac EDAC driver failed to get BAR then reported the above failure.
Therefor, store the presence state of P2SB PCI device before unhiding it
for reading BAR and restore the presence state after reading BAR.
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Reported-by: Yunying Sun <yunying.sun@intel.com>
Tested-by: Yunying Sun <yunying.sun@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
commit ba201c4f5ebe13d7819081756378777d8153f23e upstream.
Compare the number of bytes actually seen on the wire to the byte
count field returned by the slave device.
Previously we just overwrote the byte count returned by the slave
with the real byte count and let the caller figure out if the
message was sane.
Signed-off-by: Stephen Douthit <stephend@adiengineering.com>
Tested-by: Dan Priamo <danp@adiengineering.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream.
According to Table 15-14 of the C2000 EDS (Intel doc #510524) the
rx data pointed to by the descriptor dptr contains the byte count.
desc->rxbytes reports all bytes read on the wire, including the
"byte count" byte. So if a device sends 4 bytes in response to a
block read, on the wire and in the DMA buffer we see:
count data1 data2 data3 data4
0x04 0xde 0xad 0xbe 0xef
That's what we want to return in data->block to the next level.
Instead we were actually prefixing that with desc->rxbytes:
bad
count count data1 data2 data3 data4
0x05 0x04 0xde 0xad 0xbe 0xef
This was discovered while developing a BMC solution relying on the
ipmi_ssif.c driver which was trying to interpret the bogus length
field as part of the IPMI response.
Signed-off-by: Stephen Douthit <stephend@adiengineering.com>
Tested-by: Dan Priamo <danp@adiengineering.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a23318feeff662c8d25d21623daebdd2e55ec221 upstream.
The commit 8503ff166504 ("i2c: designware: Avoid unnecessary resuming
during system suspend"), may suggest to the PM core to try out the so
called direct_complete path for system sleep. In this path, the PM core
treats a runtime suspended device as it's already in a proper low power
state for system sleep, which makes it skip calling the system sleep
callbacks for the device, except for the ->prepare() and the ->complete()
callbacks.
However, the PM core may unset the direct_complete flag for a parent
device, in case its child device are being system suspended before. In this
scenario, the PM core invokes the system sleep callbacks, no matter if the
device is runtime suspended or not.
Particularly in cases of an existing i2c slave device, the above path is
triggered, which breaks the assumption that the i2c device is always
runtime resumed whenever the dw_i2c_plat_suspend() is being called.
More precisely, dw_i2c_plat_suspend() calls clk_core_disable() and
clk_core_unprepare(), for an already disabled/unprepared clock, leading to
a splat in the log about clocks calls being wrongly balanced and breaking
system sleep.
To still allow the direct_complete path in cases when it's possible, but
also to keep the fix simple, let's runtime resume the i2c device in the
->suspend() callback, before continuing to put the device into low power
state.
Note, in cases when the i2c device is attached to the ACPI PM domain, this
problem doesn't occur, because ACPI's ->suspend() callback, assigned to
acpi_subsys_suspend(), already calls pm_runtime_resume() for the device.
It should also be noted that this change does not fix commit 8503ff166504
("i2c: designware: Avoid unnecessary resuming during system suspend").
Because for the non-ACPI case, the system sleep support was already broken
prior that point.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 682c6c2188f39d13548ccdc89c9888fbcb547889 upstream.
At least the Acer Iconia Tab8 / aka W1-810 uses 1MiHz instead of
1MHz for one of its busses, fix this up to 1MHz instead of failing
the probe of that bus.
This fixes the accelerometer on the Acer Iconia Tab8 not working.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The i2c-imx driver incorrectly uses readb()/writeb() to read and
write to the appropriate registers when performing a repeated start.
The appropriate imx_i2c_read_reg()/imx_i2c_write_reg() functions
should be used instead. Performing a repeated start results in
a kernel panic. The platform is imx.
Signed-off-by: Michail G Etairidis <m.etairidis@beck-ipc.com>
Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
Fixes: 054b62d9f25c ("i2c: imx: fix the i2c bus hang issue when do repeat restart")
Acked-by: Fugang Duan <fugang.duan@nxp.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Fix the following kernel bug:
kernel BUG at drivers/iommu/intel-iommu.c:3260!
invalid opcode: 0000 [#5] PREEMPT SMP
Hardware name: Intel Corp. Harcuvar/Server, BIOS HAVLCRB0.X64.0013.D39.1608311820 08/31/2016
task: ffff880175389950 ti: ffff880176bec000 task.ti: ffff880176bec000
RIP: 0010:[<ffffffff8150a83b>] [<ffffffff8150a83b>] intel_unmap+0x25b/0x260
RSP: 0018:ffff880176bef5e8 EFLAGS: 00010296
RAX: 0000000000000024 RBX: ffff8800773c7c88 RCX: 000000000000ce04
RDX: 0000000080000000 RSI: 0000000000000000 RDI: 0000000000000009
RBP: ffff880176bef638 R08: 0000000000000010 R09: 0000000000000004
R10: ffff880175389c78 R11: 0000000000000a4f R12: ffff8800773c7868
R13: 00000000ffffac88 R14: ffff8800773c7818 R15: 0000000000000001
FS: 00007fef21258700(0000) GS:ffff88017b5c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000066d6d8 CR3: 000000007118c000 CR4: 00000000003406e0
Stack:
00000000ffffac88 ffffffff8199867f ffff880176bef5f8 ffff880100000030
ffff880176bef668 ffff8800773c7c88 ffff880178288098 ffff8800772c0010
ffff8800773c7818 0000000000000001 ffff880176bef648 ffffffff8150a86e
Call Trace:
[<ffffffff8199867f>] ? printk+0x46/0x48
[<ffffffff8150a86e>] intel_unmap_page+0xe/0x10
[<ffffffffa039d99b>] ismt_access+0x27b/0x8fa [i2c_ismt]
[<ffffffff81554420>] ? __pm_runtime_suspend+0xa0/0xa0
[<ffffffff815544a0>] ? pm_suspend_timer_fn+0x80/0x80
[<ffffffff81554420>] ? __pm_runtime_suspend+0xa0/0xa0
[<ffffffff815544a0>] ? pm_suspend_timer_fn+0x80/0x80
[<ffffffff8143dfd0>] ? pci_bus_read_dev_vendor_id+0xf0/0xf0
[<ffffffff8172b36c>] i2c_smbus_xfer+0xec/0x4b0
[<ffffffff810aa4d5>] ? vprintk_emit+0x345/0x530
[<ffffffffa038936b>] i2cdev_ioctl_smbus+0x12b/0x240 [i2c_dev]
[<ffffffff810aa829>] ? vprintk_default+0x29/0x40
[<ffffffffa0389b33>] i2cdev_ioctl+0x63/0x1ec [i2c_dev]
[<ffffffff811b04c8>] do_vfs_ioctl+0x328/0x5d0
[<ffffffff8119d8ec>] ? vfs_write+0x11c/0x190
[<ffffffff8109d449>] ? rt_up_read+0x19/0x20
[<ffffffff811b07f1>] SyS_ioctl+0x81/0xa0
[<ffffffff819a351b>] system_call_fastpath+0x16/0x6e
This happen When run "i2cdetect -y 0" detect SMBus iSMT adapter.
After finished I2C block read/write, when unmap the data buffer,
a wrong device address was pass to dma_unmap_single().
To fix this, give dma_unmap_single() the "dev" parameter, just like
what dma_map_single() does, then unmap can find the right devices.
Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller")
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Because we need to transfer some bytes with PIO, the msg length is not
the length of the DMA buffer. Use the correct value which we used when
doing the mapping.
Fixes: 73e8b0528346e8 ("i2c: rcar: add DMA support")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
We need to initializes those variables to 0 for platforms that do not
provide ACPI parameters. Otherwise, we set sda_hold_time to random
values, breaking e.g. Galileo and IOT2000 boards.
Fixes: 9d6408433019 ("i2c: designware: don't infer timings described by ACPI from clock rate")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Since v4.9 i2c-tiny-usb generates the below call trace
and longer works, since it can't communicate with the
USB device. The reason is, that since v4.9 the USB
stack checks, that the buffer it should transfer is DMA
capable. This was a requirement since v2.2 days, but it
usually worked nevertheless.
[ 17.504959] ------------[ cut here ]------------
[ 17.505488] WARNING: CPU: 0 PID: 93 at drivers/usb/core/hcd.c:1587 usb_hcd_map_urb_for_dma+0x37c/0x570
[ 17.506545] transfer buffer not dma capable
[ 17.507022] Modules linked in:
[ 17.507370] CPU: 0 PID: 93 Comm: i2cdetect Not tainted 4.11.0-rc8+ #10
[ 17.508103] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[ 17.509039] Call Trace:
[ 17.509320] ? dump_stack+0x5c/0x78
[ 17.509714] ? __warn+0xbe/0xe0
[ 17.510073] ? warn_slowpath_fmt+0x5a/0x80
[ 17.510532] ? nommu_map_sg+0xb0/0xb0
[ 17.510949] ? usb_hcd_map_urb_for_dma+0x37c/0x570
[ 17.511482] ? usb_hcd_submit_urb+0x336/0xab0
[ 17.511976] ? wait_for_completion_timeout+0x12f/0x1a0
[ 17.512549] ? wait_for_completion_timeout+0x65/0x1a0
[ 17.513125] ? usb_start_wait_urb+0x65/0x160
[ 17.513604] ? usb_control_msg+0xdc/0x130
[ 17.514061] ? usb_xfer+0xa4/0x2a0
[ 17.514445] ? __i2c_transfer+0x108/0x3c0
[ 17.514899] ? i2c_transfer+0x57/0xb0
[ 17.515310] ? i2c_smbus_xfer_emulated+0x12f/0x590
[ 17.515851] ? _raw_spin_unlock_irqrestore+0x11/0x20
[ 17.516408] ? i2c_smbus_xfer+0x125/0x330
[ 17.516876] ? i2c_smbus_xfer+0x125/0x330
[ 17.517329] ? i2cdev_ioctl_smbus+0x1c1/0x2b0
[ 17.517824] ? i2cdev_ioctl+0x75/0x1c0
[ 17.518248] ? do_vfs_ioctl+0x9f/0x600
[ 17.518671] ? vfs_write+0x144/0x190
[ 17.519078] ? SyS_ioctl+0x74/0x80
[ 17.519463] ? entry_SYSCALL_64_fastpath+0x1e/0xad
[ 17.519959] ---[ end trace d047c04982f5ac50 ]---
Cc: <stable@vger.kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Till Harbaum <till@harbaum.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Commit bd698d24b1b57 ("i2c: designware: Get selected speed mode
sda-hold-time via ACPI") updated the logic that reads the timing
parameters for various I2C bus rates from the DSDT, to only read
the timing parameters for the currently selected mode.
This causes a WARN_ON() splat on platforms that legally omit the clock
frequency from the ACPI description, because in the new situation, the
core I2C designware driver still accesses the fields in the driver
struct that we no longer populate, and proceeds to calculate them from
the clock frequency. Since the clock frequency is unspecified, the
driver complains loudly using a WARN_ON().
So revert back to the old situation, where the struct fields for all
timings are populated, but retain the new logic which chooses the SDA
hold time from the timing mode that is currently in use.
Fixes: bd698d24b1b57 ("i2c: designware: Get selected speed mode ...")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
With ACPI, i2c-core requires ACPI companion to be set in order for it
to create slave device.
This patch sets the ACPI companion accordingly.
Signed-off-by: Tin Huynh <tnhuynh@apm.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
There is no reason to use platform_get_irq() for non-DT probing and
irq_of_parse_and_map() for DT probing. Indeed, platform_get_irq()
works fine for both.
In addition, using platform_get_irq() properly returns -EPROBE_DEFER
when the interrupt controller is not yet available, so instead of
inventing our own error code (-ENXIO), return the one provided by
platform_get_irq().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
As is, a failure message is printed unconditionally, which is confusing.
And noisy.
Fixes: 8d4d159f25a7 ("i2c: mux: provide more info on failure in i2c_mux_add_adapter")
Signed-off-by: Peter Rosin <peda@axentia.se>
|
|
That maintains sanity if it is ever called from some other spot, and
also makes the label names coherent.
Signed-off-by: Peter Rosin <peda@axentia.se>
|
|
It is only prudent to let go of resources that are not used.
Fixes: b3fdd32799d8 ("i2c: mux: Add register-based mux i2c-mux-reg")
Signed-off-by: Peter Rosin <peda@axentia.se>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
Pull hw lockdown support from David Howells:
"Annotation of module parameters that configure hardware resources
including ioports, iomem addresses, irq lines and dma channels.
This allows a future patch to prohibit the use of such module
parameters to prevent that hardware from being abused to gain access
to the running kernel image as part of locking the kernel down under
UEFI secure boot conditions.
Annotations are made by changing:
module_param(n, t, p)
module_param_named(n, v, t, p)
module_param_array(n, t, m, p)
to:
module_param_hw(n, t, hwtype, p)
module_param_hw_named(n, v, t, hwtype, p)
module_param_hw_array(n, t, hwtype, m, p)
where the module parameter refers to a hardware setting
hwtype specifies the type of the resource being configured. This can
be one of:
ioport Module parameter configures an I/O port
iomem Module parameter configures an I/O mem address
ioport_or_iomem Module parameter could be either (runtime set)
irq Module parameter configures an I/O port
dma Module parameter configures a DMA channel
dma_addr Module parameter configures a DMA buffer address
other Module parameter configures some other value
Note that the hwtype is compile checked, but not currently stored (the
lockdown code probably won't require it). It is, however, there for
future use.
A bonus is that the hwtype can also be used for grepping.
The intention is for the kernel to ignore or reject attempts to set
annotated module parameters if lockdown is enabled. This applies to
options passed on the boot command line, passed to insmod/modprobe or
direct twiddling in /sys/module/ parameter files.
The module initialisation then needs to handle the parameter not being
set, by (1) giving an error, (2) probing for a value or (3) using a
reasonable default.
What I can't do is just reject a module out of hand because it may
take a hardware setting in the module parameters. Some important
modules, some ipmi stuff for instance, both probe for hardware and
allow hardware to be manually specified; if the driver is aborts with
any error, you don't get any ipmi hardware.
Further, trying to do this entirely in the module initialisation code
doesn't protect against sysfs twiddling.
[!] Note that in and of itself, this series of patches should have no
effect on the the size of the kernel or code execution - that is
left to a patch in the next series to effect. It does mark
annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in
an already existing field"
* tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits)
Annotate hardware config module parameters in sound/pci/
Annotate hardware config module parameters in sound/oss/
Annotate hardware config module parameters in sound/isa/
Annotate hardware config module parameters in sound/drivers/
Annotate hardware config module parameters in fs/pstore/
Annotate hardware config module parameters in drivers/watchdog/
Annotate hardware config module parameters in drivers/video/
Annotate hardware config module parameters in drivers/tty/
Annotate hardware config module parameters in drivers/staging/vme/
Annotate hardware config module parameters in drivers/staging/speakup/
Annotate hardware config module parameters in drivers/staging/media/
Annotate hardware config module parameters in drivers/scsi/
Annotate hardware config module parameters in drivers/pcmcia/
Annotate hardware config module parameters in drivers/pci/hotplug/
Annotate hardware config module parameters in drivers/parport/
Annotate hardware config module parameters in drivers/net/wireless/
Annotate hardware config module parameters in drivers/net/wan/
Annotate hardware config module parameters in drivers/net/irda/
Annotate hardware config module parameters in drivers/net/hamradio/
Annotate hardware config module parameters in drivers/net/ethernet/
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more ACPI updates from Rafael Wysocki:
"These update the ACPICA code in the kernel to upstream revision
20170303 which adds a few minor fixes and improvements, update ACPI
SoC drivers with new device IDs, platform-related information and
similar, fix the register information in the xpower PMIC driver,
introduce a concept of "always present" devices to the ACPI device
enumeration code and use it to fix a problem with one platform, and
fix a system resume issue related to power resources.
Specifics:
- Update the ACPICA code in the kernel to upstream revision 20170303
which includes:
* Minor fixes and improvements in the core code (Bob Moore,
Seunghun Han).
* Debugger fixes (Colin Ian King, Lv Zheng).
* Compiler/disassembler improvements (Bob Moore, David Box, Lv
Zheng).
* Build-related update (Lv Zheng).
- Add new device IDs and platform-related information to the ACPI
drivers for Intel (LPSS) and AMD (APD) SoCs (Hanjun Guo, Hans de
Goede).
- Make it possible to quirk ACPI-enumerated devices as "always
present" on platforms where they are incorrectly reported as not
present by the AML and add the INT0002 device ID to the list of
"always present" devices (Hans de Goede).
- Fix the register information in the xpower PMIC driver and add
comments to map the registers to symbols used by AML to it (Hans de
Goede).
- Move the code turning off unused ACPI power resources during system
resume to a point after all devices have been resumed to avoid
issues with power resources that do not behave as expected (Hans de
Goede)"
* tag 'acpi-extra-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (22 commits)
ACPI / power: Delay turning off unused power resources after suspend
ACPI / PMIC: xpower: Fix power_table addresses
ACPI / LPSS: Call pwm_add_table() for Bay Trail PWM device
ACPICA: Update version to 20170303
ACPICA: iasl: add ASL conversion tool
ACPICA: Local cache support: Allow small cache objects
ACPICA: Disassembler: Do not unconditionally remove temporary names
ACPICA: iasl: Fix IORT SMMU GSI disassembling
ACPICA: Cleanup AML opcode definitions, no functional change
ACPICA: Debugger: Add interpreter blocking mark for single-step mode
ACPICA: debugger: fix memory leak on Pathname
ACPICA: Update for automatic repair code for objects returned by evaluate_object
ACPICA: Namespace: fix operand cache leak
ACPICA: Fix several incorrect invocations of ACPICA return macro
ACPICA: Fix a module for excessive debug output
ACPICA: Update some function headers, no funtional change
ACPICA: Disassembler: Enhance resource descriptor detection
i2c: designware: Add ACPI HID for Hisilicon Hip07/08 I2C controller
ACPI / APD: Add clock frequency for Hisilicon Hip07/08 I2C controller
ACPI / bus: Add INT0002 to list of always-present devices
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input subsystem updates from Dmitry Torokhov:
- a big update from Mauro converting input documentation to ReST format
- Synaptics PS/2 is now aware of SMBus companion devices, which means
that we can now use native RMI4 protocol to handle touchpads, instead
of relying on legacy PS/2 mode.
- we removed support from BMA180 accelerometer from input devices as it
is now handled properly by IIO
- update to TSC2007 to corretcly report pressure
- other miscellaneous driver fixes.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (152 commits)
Input: ar1021_i2c - use BIT to check for a bit
Input: twl4030-pwrbutton - use input_set_capability() helper
Input: twl4030-pwrbutton - use correct device for irq request
Input: ar1021_i2c - enable touch mode during open
Input: add uinput documentation
dt-bindings: input: add bindings document for ar1021_i2c driver
dt-bindings: input: rotary-encoder: fix typo
Input: xen-kbdfront - add module parameter for setting resolution
ARM: pxa/raumfeld: fix compile error in rotary controller resources
Input: xpad - do not suggest writing to Dominic
Input: xpad - don't use literal blocks inside footnotes
Input: xpad - note that usb/devices is now at /sys/kernel/debug/
Input: docs - freshen up introduction
Input: docs - split input docs into kernel- and user-facing
Input: docs - note that MT-A protocol is obsolete
Input: docs - update joystick documentation a bit
Input: docs - remove disclaimer/GPL notice
Input: fix "Game console" heading level in joystick documentation
Input: rotary-encoder - remove references to platform data from docs
Input: move documentation for Amiga CD32
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c updates from Wilfram Sang:
"I2C has the following updates for you:
- an immutable cross-subsystem branch fixing PMIC access on Intel
Baytrail
- bigger driver updates to the designware, meson, exynos5 drivers
- new i2c_acpi_new_device() function to create devices from ACPI
- struct i2c_driver has now a flag 'disable_i2c_core_irq_mapping' to
allow custom IRQ mapping in case the default does not fit
- mux subsystem centralized error messages in its core
- new driver for ltc4306 i2c mux
- usual set of small updates"
* 'i2c/for-4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (44 commits)
i2c: thunderx: Enable HWMON class probing
i2c: rcar: clarify PM handling with more comments
i2c: rcar: fix resume by always initializing registers before transfer
i2c: tegra: fix spelling mistake: "contoller" -> "controller"
i2c: exynos5: use core helper to get driver data
i2c: exynos5: de-duplicate error logs on clock setup
i2c: exynos5: simplify clock frequency handling
i2c: exynos5: simplify timings calculation
i2c: designware-baytrail: fix potential null pointer dereference on dev
i2c: designware: Get selected speed mode sda-hold-time via ACPI
[media] cx231xx: stop double error reporting
i2c: core: Allow drivers to disable i2c-core irq mapping
i2c: core: Add new i2c_acpi_new_device helper function
i2c: core: Allow getting ACPI info by index
i2c: img-scb: use setup_timer
i2c: i2c-scmi: add a MS HID
i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
dt-bindings: i2c: mux: ltc4306: Add dt-bindings for I2C multiplexer/switch
i2c: mux: reg: stop double error reporting
i2c: mux: pinctrl: stop double error reporting
...
|
|
Add ACPI HID HISI02A1 and HISI02A2 for Hisilicon Hip07/08,
which have different clock frequency.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Set I2C_CLASS_HWMON to enable automatic probing of BMC devices
by the ipmi-ssif driver.
Signed-off-by: Jan Glauber <jglauber@cavium.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
PM handling is correct but might be a bit subtle. Add some comments for
clarification.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Resume failed because of uninitialized registers. Instead of adding a
resume callback, we simply initialize registers before every transfer.
This lightweight change is more robust and will keep us safe if we ever
need support for power domains or dynamic frequency changes.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
trivial fix to spelling mistake in MODULE_DESCRIPTION text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Driver core provides of_device_get_match_data which can be used
to get driver data instead of custom helper.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
In case of clock setup error it is enough to log it once.
Moreover patch simplifies clock setup routines.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
There is no need to keep separate settings for high and fast speed clock.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Instead of using cryptic loop direct calculation of timings
can be used.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/i2c/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Jean Delvare <jdelvare@suse.de>
cc: linux-i2c@vger.kernel.org
|
|
The assignment to addr requires a call to get_sem_addr that dereferences
dev, however, this dereference occurs before a null pointer check on dev.
Move this assignment after the null check on dev to avoid a potential null
pointer dereference.
Detected by CoverityScan, CID#1419700 ("Dereference before null check")
Fixes: fd476fa22a1f432 ("i2c: designware-baytrail: Add support for cherrytrail")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Sda-hold-time is an important parameter for tuning i2c to meet the
electrical specification especially for high speed. I2C with incorrect
sda-hold-time may cause lost arbitration error. Instead of loading all
speed mode settings, only selected speed mode settings are loaded.
Signed-off-by: Tan Chin Yew <chin.yew.tan@intel.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>
|
|
Pull in the immutable branch with I2C ACPI core extensions to support
the INT33FE driver.
|
|
By default the i2c-core will try to get an irq with index 0 on ACPI / of
instantiated devices. This is troublesome on some ACPI systems where the
irq info at index 0 in the CRS table may contain nonsense and/or point
to an irqchip for which there is no Linux driver.
If this happens then before this commit the driver's probe method would
never get called because i2c_device_probe will try to get an irq by
calling acpi_dev_gpio_irq_get which will always return -EPROBE in this
case, as it waits for a matching irqchip driver to load. Thus causing
the driver to not get a chance to bind.
This commit adds a new disable_i2c_core_irq_mapping flag to struct
i2c_driver which a driver can set to tell the core to skip irq mapping.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
By default the i2c subsys creates an i2c-client for the first I2cSerialBus
resource of an acpi_device, but some acpi_devices have multiple
I2cSerialBus resources and we may want to instantiate i2c-clients for
the others.
This commit adds a new i2c_acpi_new_device function which can be used to
create an i2c-client for any I2cSerialBus resource of an acpi_device.
Note that the other resources may even be on a different i2c bus, so just
retrieving the client address is not enough.
Here is an example DSDT excerpt from such a device:
Device (WIDR)
{
Name (_HID, "INT33FE" /* XPOWER Battery Device */)
Name (_CID, "INT33FE" /* XPOWER Battery Device */)
Name (_DDN, "WC PMIC Battery Device")
<snip>
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x005E, ControllerInitiated, 0x000186A0,
AddressingMode7Bit, "\\_SB.PCI0.I2C7",
0x00, ResourceConsumer, , Exclusive,
)
I2cSerialBusV2 (0x0036, ControllerInitiated, 0x000186A0,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
I2cSerialBusV2 (0x0022, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
I2cSerialBusV2 (0x0054, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
"\\_SB.PCI0.I2C7.PMI5", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0012
}
GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0005
}
GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
"\\_SB.PCI0.I2C7.PMI5", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0013
}
})
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Return (RBUF) /* \_SB_.PCI0.I2C7.WIDR.RBUF */
}
<snip>
}
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Modify struct i2c_acpi_lookup and i2c_acpi_fill_info() to allow
using them to get the info from a certain index in the ACPI-resource
list rather then taking the first I2cSerialBus resource.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Use setup_timer() instead of init_timer() to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Description of the problem:
- i2c-scmi driver contains only two identifiers "SMBUS01" and "SMBUSIBM";
- the fist HID (SMBUS01) is clearly defined in "SMBus Control Method
Interface Specification, version 1.0": "Each device must specify
'SMBUS01' as its _HID and use a unique _UID value";
- unfortunately, BIOS vendors (like AMI) seem to ignore this requirement
and implement "SMB0001" HID instead of "SMBUS01";
- I speculate that they do this because only "SMB0001" is hard coded in
Windows SMBus driver produced by Microsoft.
This leads to following situation:
- SMBus works out of box in Windows but not in Linux;
- board vendors are forced to add correct "SMBUS01" HID to BIOS to make
SMBus work in Linux. Moreover the same board vendors complain that
tools (3-rd party ASL compiler) do not like the "SMBUS01" identifier
and produce errors. So they need to constantly patch the compiler for
each new version of BIOS.
As it is very unlikely that BIOS vendors implement a correct HID in
future, I would propose to consider whether it is possible to work around
the problem by adding MS HID to the Linux i2c-scmi driver.
v2: move the definition of the new HID to the driver itself.
Signed-off-by: Edgar Cherkasov <echerkasov@dev.rtsoft.ru>
Signed-off-by: Michael Brunner <Michael.Brunner@kontron.com>
Acked-by: Viktor Krasnov <vkrasnov@dev.rtsoft.ru>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
i2c/for-4.12
Pull in changes from the i2c-mux subsubsystem:
"Here are a new LTC4306/5 driver, a fix needed by the RT kernel and some
error message cleanup."
|
|
This patch adds support for the Analog Devices / Linear Technology
LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
The LTC4306 optionally provides two general purpose input/output pins
(GPIOs) that can be configured as logic inputs, opendrain outputs or
push-pull outputs via the generic GPIOLIB framework.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
|
|
Linux 4.11-rc6
drm-misc needs 4.11-rc5, may as well fix conflicts with rc6.
|
|
Bring in changes to i2c to better manage device properties and to allow
specifying client interrupt through a resource structure.
|
|
i2c_mux_add_adapter already logs a message on failure.
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Peter Rosin <peda@axentia.se>
|
Bruce Ashfield
Hans de Goede
Alan Tull
Srinivas Pandruvada
Guenter Roeck
Qiuxu Zhuo
Stephen Douthit
Ulf Hansson
Michail Georgios Etairidis
Liwei Song
Wolfram Sang
Jan Kiszka
Sebastian Reichel
Ard Biesheuvel
Tin Huynh
Thomas Petazzoni
Peter Rosin
Linus Torvalds
Hanjun Guo
Jan Glauber
Colin Ian King
Andrzej Hajda
David Howells
chin.yew.tan@intel.com
Wolfram Sang
Geliang Tang
Edgar Cherkasov
Michael Hennerich
Dave Airlie
Dmitry Torokhov