Originally I only wanted to drop the unneeded inclusion of
<linux/i2c.h>, but then noticed that struct
microread_nfc_platform_data isn't actually used, and
MICROREAD_DRIVER_NAME is redefined in the only file where it is used,
so we can get rid of the header file and dead code altogether.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Lauro Ramos Venancio <[email protected]>
Cc: Aloisio Almeida Jr <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
Log successful error injections so that injected errors can be
differentiated from real errors.
Suggested-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: Borislav Petkov <[email protected]>
The aer_inject driver is very quiet. In most cases, it merely returns an
error code to user-space, leaving the user with little clue about the
actual reason for the failure.
So, log error messages for 4 of the most frequent causes of failure:
* Can't find the root port of the specified device.
* Device doesn't support AER.
* Root port doesn't support AER.
* AER device not found.
This gives the user a chance to understand why aer-inject failed.
Based on a preliminary patch by Thomas Renninger.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: Borislav Petkov <[email protected]>
CC: Thomas Renninger <[email protected]>
dev_warn() is better than printk(LOG_WARNING...) as it records which device
the message relates to. Also add a prefix "aer_inject:" to help
differentiate real errors from injected errors.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: Borislav Petkov <[email protected]>
EPERM means "Operation not permitted", which doesn't reflect the lack of
support for AER. EPROTONOSUPPORT (Protocol not supported) is a better
choice of error code if the device or its root port lack support for AER.
Likewise, EINVAL means "Invalid argument", which is not suitable for cases
where the AER error device is missing or unusable. ENODEV and
EPROTONOSUPPORT, respectively, fit better.
Suggested-by: Borislav Petkov <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: Borislav Petkov <[email protected]>
CC: Prarit Bhargava <[email protected]>
Kconfig option SERIAL_8250_RT288X seems to be only relevant on MIPS
platforms, so do not present it on other architectures, unless
build-testing.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Mans Rullgard <[email protected]>
Cc: Jiri Slaby <[email protected]>
Acked-by: John Crispin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The Technologic Systems TS-4800 is an i.MX515 board, so its drivers
are useless unless building a SOC_IMX51 kernel, except for build
testing purposes.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
The BCM7038 watchdog driver is specific to Broadcom ARM and MIPS
SoCs so do not present it on other architectures, unless
build-testing.
Signed-off-by: Jean Delvare <[email protected]>
Reviewed-by: Justin Chen <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
The Technologic Systems TS-4800 is an i.MX515 board, so its drivers
are useless unless building a SOC_IMX51 kernel, except for build
testing purposes.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Damien Riegel <[email protected]>
Cc: Rob Herring <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
Shift the port number at initialization time, so that it is ready to
use at run time. That way we don't have to do it again for every SMBus
transaction.
Signed-off-by: Jean Delvare <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Sometimes u8 is used to store the port number, sometimes unsigned
short is used. Consistently stick to a single type, for consistency
and to avoid implicit casts.
Signed-off-by: Jean Delvare <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
The SB800 register reference guide says that the SMBus port selection
bits may not always be in register Smbus0En (0x2c) but could
alternatively be found in register Smbus0Sel (0x2e) depending on the
settings in register Smbus0SelEn (0x2f.) Add support for this
configuration.
The "alternative" register is the only one working for the Bolton
(aka Hudson-2) chipset anyway. I do not have any documentation for
the "kerncz" chipset so we treat it the same as the Bolton for now.
Signed-off-by: Jean Delvare <[email protected]>
Tested-by: Christian Fetzer <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
The pinctrl-amd driver builds just fine as a module so give
users this option.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Linus Walleij <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
The i2c-designware-platform module has duplicate module information
when CONFIG_I2C_DESIGNWARE_BAYTRAIL is set. It gets the information
from both i2c-designware-platdrv and i2c-designware-baytrail. The
latter is optional extra code which ends up in the same module so it
should not export module information.
Signed-off-by: Jean Delvare <[email protected]>
Acked-by: Jarkko Nikula <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
pinctrl-intel doesn't use anything from <linux/init.h>,
<linux/acpi.h>, <linux/gpio.h> or <linux/pm.h>, so it should not
include these header files.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Heikki Krogerus <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
DRIVER_NAME is too generic to be used in a driver-specific platform
data file. Use a name specific to the driver instead, to avoid
collisions.
Signed-off-by: Jean Delvare <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Cc: Jiri Slaby <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The I2C bus names are supposed to be stable as they can be used by
userspace to uniquely identify a specific I2C bus. So restore the
original names for all legacy (pre-SB800) devices.
For SB800 devices and later, improve the names. "SDA" refers to the
serial data pin of each SMBus port, it's an implementation detail the
user doesn't need to know. Use "port" instead, which is easier to
understand.
Signed-off-by: Jean Delvare <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Tested-by: Christian Fetzer <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
This closes a race window where I2C device drivers attempt to access
I2C buses which aren't fully initialized yet.
Signed-off-by: Jean Delvare <[email protected]>
Tested-by: Christian Fetzer <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
We need a single mutex for all 4 shared SMBus ports on the SB800. A
per-port mutex doesn't protect us from concurrent access.
In theory the mutex should be per PCI device, however in practice we
know that there's only ever a single instance of the device in a given
system so we can use a global.
Also take the mutex during initialization, as first port may be already
in use when second port is initialized.
Signed-off-by: Jean Delvare <[email protected]>
Tested-by: Christian Fetzer <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
[wsa: made mutex static]
Signed-off-by: Wolfram Sang <[email protected]>
I don't think it makes sense for a module to have a soft dependency
on itself. This seems quite cyclic by nature and I can't see what
purpose it could serve.
OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty
much assumes that some incarnation of the "crc32c" hash algorithm has
been loaded. Therefore it makes sense to have the soft dependency
there (as crc-t10dif does.)
Cc: [email protected]
Cc: Tim Chen <[email protected]>
Cc: "David S. Miller" <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Since commit d6f346f2d2 (cpuidle: improve governor Kconfig options)
the best cpuidle governor is selected automatically. There is little
point in additionally selecting the other one as it will not be used,
so don't select both governors by default.
Being able to select more than one governor is still good for
developers booting with cpuidle_sysfs_switch, though.
This fixes the second half of kernel BZ #65531.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=65531
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The menu governor is currently the default on all systems. However the
documentation claims that the ladder governor is preferred on ticking
systems. So bump the rating of the ladder governor when NO_HZ is
disabled, or when booting with nohz=off.
This fixes the first half of kernel BZ #65531.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=65531
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The description of dmi_find_device was apparently copied from a
similar function in a different subsystem, but the parameter names
were not adjusted as needed.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Andrey Panin <[email protected]>
Get rid of the arbitrary 5-byte pointer offset, it served no purpose
and made it harder to match the code with the SMBIOS specification.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Jordan Hargrave <[email protected]>
Cc: Narendra K <[email protected]>
Calling dmi_string_nosave isn't cheap, so avoid calling it twice in a
row for the same string.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Jordan Hargrave <[email protected]>
Cc: Narendra K <[email protected]>
The double negation is costly and can be avoided by shifting the
register value before masking the requested bit.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Linus Walleij <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
The first part of the comment is wrong since November 2007, delete it.
The second part of the comment is related to I2C_PEC, not I2C_SLAVE, so
move it where it belongs.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Wolfram Sang <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
The ioctl is named I2C_RDWR for "I2C read/write". But references to it
were misspelled "rdrw". Fix them.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
As I understand it, the core nfcmrvl module is useless without
either the USB or the UART access module. So hide NFC_MRVL and select
it automatically if either NFC_MRVL_USB or NFC_MRVL_UART is selected.
This avoids presenting NFC_MRVL when neither NFC_MRVL_USB nor
NFC_MRVL_UART can be selected.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Lauro Ramos Venancio <[email protected]>
Cc: Aloisio Almeida Jr <[email protected]>
Cc: Samuel Ortiz <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
As I understand it, the core nfc_microread module is useless without
either the I2C or the MEI access module. So hide NFC_MICROREAD and
select it automatically if either NFC_MICROREAD_I2C or
NFC_MICROREAD_MEI is selected.
This avoids presenting NFC_MICROREAD when neither NFC_MICROREAD_I2C
nor NFC_MICROREAD_MEI can be selected.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Lauro Ramos Venancio <[email protected]>
Cc: Aloisio Almeida Jr <[email protected]>
Cc: Samuel Ortiz <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
As I understand it, the core nfc_pn544 module is useless without
either the I2C or the MEI access module. So hide NFC_PN544 and
select it automatically if either NFC_PN544_I2C or NFC_PN544_MEI is
selected.
This avoids presenting NFC_PN544 when neither NFC_PN544_I2C nor
NFC_PN544_MEI can be selected.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Lauro Ramos Venancio <[email protected]>
Cc: Aloisio Almeida Jr <[email protected]>
Cc: Samuel Ortiz <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
"Y" was the right answer for MDIO_OCTEON when this option was only
available on CAVIUM_OCTEON_SOC. But now that the option is visible on
all (64-bit) systems, this piece of advice no longer makes sense. This
helper module is selected automatically by drivers which need it
anyway.
Signed-off-by: Jean Delvare <[email protected]>
Fixes: a6d6786452 ("net: mdio-octeon: Modify driver to work on both ThunderX and Octeon")
Cc: Florian Fainelli <[email protected]>
Cc: Sunil Goutham <[email protected]>
Cc: Radha Mohan Chintakuntla <[email protected]>
Cc: David Daney <[email protected]>
Cc: David S. Miller <[email protected]>
Acked-by: David Daney <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
If indent is not found, bail out immediately instead of spitting random
shell script error messages.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Joe Perches <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The temperature registers appear to report values in degrees Celsius
while the hwmon API mandates values to be exposed in millidegrees
Celsius. Do the conversion so that the values reported by "sensors"
are correct.
Fixes: aed93e0bf4 ("tg3: Add hwmon support for temperature")
Signed-off-by: Jean Delvare <[email protected]>
Cc: Prashant Sreedharan <[email protected]>
Cc: Michael Chan <[email protected]>
Cc: [email protected] [v3.6+]
Signed-off-by: David S. Miller <[email protected]>
Add an item to the checklist when submitting a new hwmon driver: only
some I2C addresses can be probed, others should not for safety
reasons.
Signed-off-by: Jean Delvare <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Apparently the compiler does fine without it, but it feels safer and
clearer to add the missing attribute.
Signed-off-by: Jean Delvare <[email protected]>
The SMBIOS v3 entry points specify a maximum length for the DMI table,
not the exact length. Thus there may be garbage after the end-of-table
marker, which we don't want to export to user-space. Adjust dmi_len
when we find the end-of-table marker, so that only the actual table
payload is exported.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Ivan Khoronzhuk <[email protected]>
A 32-bit entry point to a DMI table says how many structures the table
contains. The SMBIOS specification explicitly says that end-of-table
markers should be ignored if they are not actually at the end of the
DMI table. So only honor the end-of-table marker for tables accessed
through 64-bit entry points, as they do not specify a structure count.
Fixes: fc43026278 ("dmi: add support for SMBIOS 3.0 64-bit entry point")
Signed-off-by: Jean Delvare <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Cc: Leif Lindholm <[email protected]>
Cc: Matt Fleming <[email protected]>
WDIOC_SETOPTIONS makes it possible to disable and re-enable the
watchdog timer while the hpwdt driver is loaded.
Signed-off-by: Jean Delvare <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
This new location was supposed to be temporary, but a couple years
have elapsed and it's still there, so apparently it's there to stay.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
In function dmi_present(), dmi_walk_early() calls dmi_table(), which
calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last
function makes a decision based on the value of global variable
dmi_ver. The problem is that this variable is set right _after_
dmi_walk_early() returns. So dmi_save_uuid() always sees dmi_ver == 0
regardless of the actual version implemented.
This causes /sys/class/dmi/id/product_uuid to always use the old
ordering even on systems implementing DMI/SMBIOS 2.6 or later, which
should use the new ordering.
This is broken since kernel v3.8 for legacy DMI implementations and
since kernel v3.10 for SMBIOS 2 implementations. SMBIOS 3
implementations with the 64-bit entry point are not affected.
The first breakage does not matter much as in practice legacy DMI
implementations are always for versions older than 2.6, which is when
the UUID ordering changed. The second breakage is more problematic as
it affects the vast majority of x86 systems manufactured since 2009.
Signed-off-by: Jean Delvare <[email protected]>
Fixes: 9f9c9cbb60 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists")
Fixes: 79bae42d51 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()")
Acked-by: Zhenzhong Duan <[email protected]>
Cc: Ben Hutchings <[email protected]>
Cc: Artem Savkov <[email protected]>
Cc: Ivan Khoronzhuk <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: [email protected] [v3.10+]
The trailing .x adds no information for the reader, and if anyone
tries to parse that line, this is more work as they have 3 different
formats to handle instead of 2. Plus, this makes backporting fixes
harder.
Signed-off-by: Jean Delvare <[email protected]>
Fixes: 95be58df74 ("firmware: dmi_scan: Use full dmi version for SMBIOS3")
Cc: Ivan Khoronzhuk <[email protected]>
The amd-xgbe driver currently only works with the Seattle SoC, which
is ARM64 architecture, so there is no point in building this driver on
other architectures except for build testing purpose. The dependency
list can be updated later if the driver ever supports other
architectures.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Tom Lendacky <[email protected]>
Cc: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Fix the following warning:
warning: "static" is not at beginning of declaration
void static hotkey_mask_warn_incomplete_mask(void)
^
Signed-off-by: Jean Delvare <[email protected]>
Cc: Henrique de Moraes Holschuh <[email protected]>
Cc: Darren Hart <[email protected]>
Signed-off-by: Darren Hart <[email protected]>
The SMBIOS3 table should appear before the SMBIOS table in
/sys/firmware/efi/systab. This allows user-space utilities which
support both to pick the SMBIOS3 table with a single pass on systems
where both are implemented. The SMBIOS3 entry point is more capable
than the SMBIOS entry point so it should be preferred.
This follows the same logic as the ACPI20 table being listed before
the ACPI table.
Signed-off-by: Jean Delvare <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Cc: Leif Lindholm <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
The comment explaining what value max_threads is set to is outdated. The
maximum memory consumption ratio for thread structures was 1/2 until
February 2002, then it was briefly changed to 1/16 before being set to 1/8
which we still use today. The comment was never updated to reflect that
change, it's about time.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
dmi_num is a u16, dmi_len is a u32, so this construct:
dmi_num = dmi_len / 4;
would result in an integer overflow for a DMI table larger than
256 kB. I've never see such a large table so far, but SMBIOS 3.0
makes it possible so maybe we'll see such tables in the future.
So instead of faking a structure count when the entry point does
not provide it, adjust the loop condition in dmi_table() to properly
deal with the case where dmi_num is not set.
This bug was introduced with the initial SMBIOS 3.0 support in commit
fc43026278 ("dmi: add support for SMBIOS 3.0 64-bit entry point").
Signed-off-by: Jean Delvare <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Ivan Khoronzhuk <[email protected]>
Cc: <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
I am familiar with these drivers and I care about them so let me add
myself as their maintainer.
Signed-off-by: Jean Delvare <[email protected]>
Acked-by: Matt Fleming <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
It was brought to my attention that the sdhci-pxav3 driver is needed
on a few more ARM machines than I initially thought. Add the missing
architectures to the dependency list.
Credits to Peter Robinson for noticing my mistake and reporting.
Reported-by: Peter Robinson <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>
Cc: Chris Ball <[email protected]>
Cc: Ulf Hansson <[email protected]>
Cc: Eric Miao <[email protected]>
Cc: Haojian Zhuang <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
The bh1780gli driver does not create an i2c module alias for the
device it supports, preventing the driver from being loaded
automatically when needed on non-OF/DT systems. Add it.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
If io-pgtable-arm is an ARM-specific driver then configuration option
IOMMU_IO_PGTABLE_LPAE should not be presented to the user by default
for non-ARM kernels.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Joerg Roedel <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
I find the Kconfig dependencies of the various Unisys drivers rather
confusing. Due to the dependencies, you must select the drivers one by
one to see the following ones. So if you are looking for a specific
driver, it is not visible by default. And if you don't know exactly
what you need, it's even worse as you don't know what is available.
In a case like this with several helper drivers and many dependencies,
I think it makes more sense to list all the drivers at first, and use
select statements to fulfill the dependencies for the user.
As a nice side effect, it avoids the weird indentation, which was
technically correct but still somewhat confusing.
I also dropped the dependencies on HAS_IOMEM, as the whole driver set
is for X86_64 only anyway which always has HAS_IOMEM set. And I
dropped the redundant dependencies on UNISYSSPAR as all drivers are
already inside an "if UNISYSSPAR" block.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Benjamin Romer <[email protected]>
Cc: David Kershner <[email protected]>
Signed-off-by: Benjamin Romer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
I seem to understand that the sdhci-pxav3 and sdhci-pxav2 drivers are
only needed on the MMP architecture. So add a hardware dependency on
ARCH_MMP, so that other users don't get to build useless drivers.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Chris Ball <[email protected]>
Cc: Ulf Hansson <[email protected]>
Cc: Eric Miao <[email protected]>
Acked-by: Haojian Zhuang <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Let MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER depend on MMC_SDHCI. Not
only this is more correct, but this also avoids breaking the alignment
of all other MMC_SDHCI_* options in menuconfig.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Chris Ball <[email protected]>
Cc: Ulf Hansson <[email protected]>
Cc: Albert Herranz <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Config option MMC_RICOH_MMC's help text reads:
If unsure, say Y.
However the option defaults to N. Set the default to Y to match the
recommendation in the help text.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Chris Ball <[email protected]>
Cc: Ulf Hansson <[email protected]>
Cc: Philipl Langdale <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
included unconditionally, even when it is not needed.
I2C bus drivers which implement slave support must select
I2C_SLAVE.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
The driver supports negative high and critical limits, it can return
negative hysteresis values, so there is no good reason to not let the
user write negative hysteresis values.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
On many motherboards, for an unknown reason, the thermal sensor seems
to be disabled and will return a constant temperature value of 36.5
degrees Celsius. Don't bind to the device in that case, so that we
don't report this bogus value to userspace.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Romain Dolbeau <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Use devm_hwmon_device_register_with_groups() to simplify the code a
bit.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Romain Dolbeau <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
The Intel 5500, 5520 and X58 chipsets embed a digital thermal sensor.
This new driver supports it.
Note that on many boards the sensor seems to be disabled and reports
the minimum value (36.5 degrees Celsius) all the time.
Signed-off-by: Jean Delvare <[email protected]>
Tested-by: Romain Dolbeau <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Don't log the host status register value in i801_isr(), it has very
little value and fills up the log when debugging is enabled.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
There is a control bit in the PCI configuration space which disables
interrupts. If this bit is set, the driver should not try to make use
of interrupts, it won't receive any.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
The i2c-i801 driver can work without interrupts, so there is no reason
to make a request_irq failure fatal. Instead we can simply fallback
to polling.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Some systems have been reported to have trouble with interrupts. Use
wait_event_timeout() instead of wait_event() so we don't get stuck in
that case, and log the problem.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
When CONFIG_FUJITSU_LAPTOP_DEBUG is disabled and W=1, the
fujitsu-laptop driver builds with the following warnings:
drivers/platform/x86/fujitsu-laptop.c: In function "bl_update_status":
drivers/platform/x86/fujitsu-laptop.c:409:8: warning: suggest braces around empty body in an "if" statement [-Wempty-body]
ret);
^
drivers/platform/x86/fujitsu-laptop.c:418:8: warning: suggest braces around empty body in an "if" statement [-Wempty-body]
ret);
^
Rework the debug printk helper macro to get rid of these. I verified
that this change has no effect on the generated binary, both in the
debug and non-debug case.
Signed-off-by: Jean Delvare <[email protected]>
Acked-by: Jonathan Woithe <[email protected]>
Cc: Matthew Garrett <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
The rtc-moxart driver is only useful on MOXA ART systems so it should
depend on ARCH_MOXART as all other MOXA ART drivers already do. Add
COMPILE_TEST as an alternative to allow for build testing on other
systems.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Alessandro Zummo <[email protected]>
Cc: Jonas Jensen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Move the DS2404 entry together with the other Dallas entries, and add
Maxim so that it looks nicer (and more correct, too.)
Signed-off-by: Jean Delvare <[email protected]>
Cc: Sven Schnelle <[email protected]>
Cc: Alessandro Zummo <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Commit a0682a31 ("i2c: gpio: Use devm_gpio_request()") left unused
code behind, clean it up.
Fixes: a0682a3158 ("i2c: gpio: Use devm_gpio_request()")
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
I2C block transfers can have a size up to 32 bytes. If starting close
to the end of the address space, there may not be enough room to write
that many bytes (on I2C block writes) or not enough bytes to be read
(on I2C block reads.) In that case, we must shorten the transfer so
that it does not exceed the address space.
Signed-off-by: Jean Delvare <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
A long name broke the alignment, shift the columns a bit to fix it and
make the table look nice again. While we're here, switch to the
standard comment style to make checkpatch happy, and use tabs instead
of spaces for column alignment.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Some chips implement banked register ranges. This allows implementing
more registers than the limited 8-bit address space originally allows.
In order to access a register on these chips, you must first select
the proper bank. Add support for this mechanism to the i2c-stub driver
so that such chips can be emulated. All the bank settings are passed
as module parameters.
Signed-off-by: Jean Delvare <[email protected]>
Tested-by: Guenter Roeck <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
As far as I know, the CS5535 and CS5536 chipsets are companions of the
Geode series of processors, which are 32-bit only. So the CS5535
drivers are not needed on x86-64, except for build testing purpose.
This aligns the dependencies to what FB_GEODE already uses.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
As far as I know the Timberdale chip was only used as a companion for
Intel Atom E600 series processors. As such, its drivers are only
useful on X86_32.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
The ptp_pch driver is for a companion chip to the Intel Atom E600
series processors. These are 32-bit x86 processors so the driver is
only needed on X86_32.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Richard Cochran <[email protected]>
Acked-by: Richard Cochran <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
There are 2 HISAX_AVM_A1_PCMCIA Kconfig entries. The kbuild system
ignores the second one, and apparently nobody noticed the problem so
far, so let's remove that second entry.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Karsten Keil <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
The first half of the HiSax config options is presented if
ISDN_DRV_HISAX!=n, while the second half of the options is presented
if ISDN_DRV_HISAX. That's the same, so merge both conditionals.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Karsten Keil <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Generic detection leads to too many false positives, so drop it. FWIW
sensors-detect does not have such generic detection. If the user wants
to force the driver to bind to a not yet supported chip, he/she can
still do so using sysfs attribute new_device.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Let the xo15-ebook driver depend on OLPC as all other OLPC drivers
already do. Add COMPILE_TEST as an alternative for both xo1-rfkill
and xo15-ebook, to increase the build testing coverage.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Matthew Garrett <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
According to its Kconfig help text, the sbc8360 watchdog driver is
only used on the Axiomtek SBC8360 single-board computer. This piece of
hardware is 32-bit x86 so the driver is useless beyond X86_32.
Signed-off-by: Jean Delvare <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
The ec_bhf driver is specific to the Beckhoff CX embedded PC series.
These are based on Intel x86 CPU. So we can add a dependency on
X86, with COMPILE_TEST as an alternative to still allow for broader
build-testing.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Darek Marcinkiewicz <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Jean Delvare