linux-stable.git/drivers/iio, branch v5.10 Linux kernel stable tree iio: accel: kxcjk1013: Add support for KIOX010A ACPI DSM for setting tablet-mode 2020-11-14T17:33:47+00:00 Hans de Goede hdegoede@redhat.com 2020-11-10T13:38:35+00:00 e5b1032a656e9aa4c7a4df77cb9156a2a651a5f9 Some 360 degree hinges (yoga) style 2-in-1 devices use 2 KXCJ91008-s to allow the OS to determine the angle between the display and the base of the device, so that the OS can determine if the 2-in-1 is in laptop or in tablet-mode. On Windows both accelerometers are read by a special HingeAngleService process; and this process calls a DSM (Device Specific Method) on the ACPI KIOX010A device node for the sensor in the display, to let the embedded-controller (EC) know about the mode so that it can disable the kbd and touchpad to avoid spurious input while folded into tablet-mode. This notifying of the EC is problematic because sometimes the EC comes up thinking that device is in tablet-mode and the kbd and touchpad do not work. This happens for example on Irbis NB111 devices after a suspend / resume cycle (after a complete battery drain / hard reset without having booted Windows at least once). Other 2-in-1s which are likely affected too are e.g. the Teclast F5 and F6 series. The kxcjk-1013 driver may seem like a strange place to deal with this, but since it is *the* driver for the ACPI KIOX010A device, it is also the driver which has access to the ACPI handle needed by the DSM. Add support for calling the DSM and on probe unconditionally tell the EC that the device is laptop mode, fixing the kbd and touchpad sometimes not working. Fixes: 7f6232e69539 ("iio: accel: kxcjk1013: Add KIOX010A ACPI Hardware-ID") Reported-and-tested-by: russianneuromancer <russianneuromancer@ya.ru> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201110133835.129080-3-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Some 360 degree hinges (yoga) style 2-in-1 devices use 2 KXCJ91008-s
to allow the OS to determine the angle between the display and the base
of the device, so that the OS can determine if the 2-in-1 is in laptop
or in tablet-mode.

On Windows both accelerometers are read by a special HingeAngleService
process; and this process calls a DSM (Device Specific Method) on the
ACPI KIOX010A device node for the sensor in the display, to let the
embedded-controller (EC) know about the mode so that it can disable the
kbd and touchpad to avoid spurious input while folded into tablet-mode.

This notifying of the EC is problematic because sometimes the EC comes up
thinking that device is in tablet-mode and the kbd and touchpad do not
work. This happens for example on Irbis NB111 devices after a suspend /
resume cycle (after a complete battery drain / hard reset without having
booted Windows at least once). Other 2-in-1s which are likely affected
too are e.g. the Teclast F5 and F6 series.

The kxcjk-1013 driver may seem like a strange place to deal with this,
but since it is *the* driver for the ACPI KIOX010A device, it is also
the driver which has access to the ACPI handle needed by the DSM.

Add support for calling the DSM and on probe unconditionally tell the
EC that the device is laptop mode, fixing the kbd and touchpad sometimes
not working.

Fixes: 7f6232e69539 ("iio: accel: kxcjk1013: Add KIOX010A ACPI Hardware-ID")
Reported-and-tested-by: russianneuromancer <russianneuromancer@ya.ru>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201110133835.129080-3-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: accel: kxcjk1013: Replace is_smo8500_device with an acpi_type enum 2020-11-14T17:32:25+00:00 Hans de Goede hdegoede@redhat.com 2020-11-10T13:38:34+00:00 11e94f28c3de35d5ad1ac6a242a5b30f4378991a Replace the boolean is_smo8500_device variable with an acpi_type enum. For now this can be either ACPI_GENERIC or ACPI_SMO8500, this is a preparation patch for adding special handling for the KIOX010A ACPI HID, which will add a ACPI_KIOX010A acpi_type to the introduced enum. For stable as needed as precursor for next patch. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Fixes: 7f6232e69539 ("iio: accel: kxcjk1013: Add KIOX010A ACPI Hardware-ID") Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201110133835.129080-2-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Replace the boolean is_smo8500_device variable with an acpi_type enum.

For now this can be either ACPI_GENERIC or ACPI_SMO8500, this is a
preparation patch for adding special handling for the KIOX010A ACPI HID,
which will add a ACPI_KIOX010A acpi_type to the introduced enum.

For stable as needed as precursor for next patch.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fixes: 7f6232e69539 ("iio: accel: kxcjk1013: Add KIOX010A ACPI Hardware-ID")
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201110133835.129080-2-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: light: fix kconfig dependency bug for VCNL4035 2020-11-08T15:43:44+00:00 Necip Fazil Yildiran fazilyildiran@gmail.com 2020-11-02T22:35:24+00:00 44a146a44f656fc03d368c1b9248d29a128cd053 When VCNL4035 is enabled and IIO_BUFFER is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for IIO_TRIGGERED_BUFFER Depends on [n]: IIO [=y] && IIO_BUFFER [=n] Selected by [y]: - VCNL4035 [=y] && IIO [=y] && I2C [=y] The reason is that VCNL4035 selects IIO_TRIGGERED_BUFFER without depending on or selecting IIO_BUFFER while IIO_TRIGGERED_BUFFER depends on IIO_BUFFER. This can also fail building the kernel. Honor the kconfig dependency to remove unmet direct dependency warnings and avoid any potential build failures. Fixes: 55707294c4eb ("iio: light: Add support for vishay vcnl4035") Signed-off-by: Necip Fazil Yildiran <fazilyildiran@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=209883 Link: https://lore.kernel.org/r/20201102223523.572461-1-fazilyildiran@gmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
When VCNL4035 is enabled and IIO_BUFFER is disabled, it results in the
following Kbuild warning:

WARNING: unmet direct dependencies detected for IIO_TRIGGERED_BUFFER
  Depends on [n]: IIO [=y] && IIO_BUFFER [=n]
  Selected by [y]:
  - VCNL4035 [=y] && IIO [=y] && I2C [=y]

The reason is that VCNL4035 selects IIO_TRIGGERED_BUFFER without depending
on or selecting IIO_BUFFER while IIO_TRIGGERED_BUFFER depends on
IIO_BUFFER. This can also fail building the kernel.

Honor the kconfig dependency to remove unmet direct dependency warnings
and avoid any potential build failures.

Fixes: 55707294c4eb ("iio: light: Add support for vishay vcnl4035")
Signed-off-by: Necip Fazil Yildiran <fazilyildiran@gmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=209883
Link: https://lore.kernel.org/r/20201102223523.572461-1-fazilyildiran@gmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio/adc: ingenic: Fix AUX/VBAT readings when touchscreen is used 2020-11-08T15:36:48+00:00 Paul Cercueil paul@crapouillou.net 2020-11-03T20:12:38+00:00 6d6aa2907d59ddd3c0ebb2b93e1ddc84e474485b When the command feature of the ADC is used, it is possible to program the ADC, and specify at each step what input should be processed, and in comparison to what reference. This broke the AUX and battery readings when the touchscreen was enabled, most likely because the CMD feature would change the VREF all the time. Now, when AUX or battery are read, we temporarily disable the CMD feature, which means that we won't get touchscreen readings in that time frame. But it now gives correct values for AUX / battery, and the touchscreen isn't disabled for long enough to be an actual issue. Fixes: b96952f498db ("IIO: Ingenic JZ47xx: Add touchscreen mode.") Signed-off-by: Paul Cercueil <paul@crapouillou.net> Acked-by: Artur Rojek <contact@artur-rojek.eu> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201103201238.161083-1-paul@crapouillou.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
When the command feature of the ADC is used, it is possible to program
the ADC, and specify at each step what input should be processed, and in
comparison to what reference.

This broke the AUX and battery readings when the touchscreen was
enabled, most likely because the CMD feature would change the VREF all
the time.

Now, when AUX or battery are read, we temporarily disable the CMD
feature, which means that we won't get touchscreen readings in that time
frame. But it now gives correct values for AUX / battery, and the
touchscreen isn't disabled for long enough to be an actual issue.

Fixes: b96952f498db ("IIO: Ingenic JZ47xx: Add touchscreen mode.")
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Artur Rojek <contact@artur-rojek.eu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201103201238.161083-1-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio/adc: ingenic: Fix battery VREF for JZ4770 SoC 2020-11-08T15:33:11+00:00 Paul Cercueil paul@crapouillou.net 2020-11-04T19:28:43+00:00 c91ebcc578e09783cfa4d85c1b437790f140f29a The reference voltage for the battery is clearly marked as 1.2V in the programming manual. With this fixed, the battery channel now returns correct values. Fixes: a515d6488505 ("IIO: Ingenic JZ47xx: Add support for JZ4770 SoC ADC.") Signed-off-by: Paul Cercueil <paul@crapouillou.net> Acked-by: Artur Rojek <contact@artur-rojek.eu> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201104192843.67187-1-paul@crapouillou.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
The reference voltage for the battery is clearly marked as 1.2V in the
programming manual. With this fixed, the battery channel now returns
correct values.

Fixes: a515d6488505 ("IIO: Ingenic JZ47xx: Add support for JZ4770 SoC ADC.")
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Artur Rojek <contact@artur-rojek.eu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201104192843.67187-1-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: imu: st_lsm6dsx: set 10ms as min shub slave timeout 2020-11-01T20:54:15+00:00 Lorenzo Bianconi lorenzo@kernel.org 2020-11-01T16:21:18+00:00 fe0b980ffd1dd8b10c09f82385514819ba2a661d Set 10ms as minimum i2c slave configuration timeout since st_lsm6dsx relies on accel ODR for i2c master clock and at high sample rates (e.g. 833Hz or 416Hz) the slave sensor occasionally may need more cycles than i2c master timeout (2s/833Hz + 1 ~ 3ms) to apply the configuration resulting in an uncomplete slave configuration and a constant reading from the i2c slave connected to st_lsm6dsx i2c master. Fixes: 8f9a5249e3d9 ("iio: imu: st_lsm6dsx: enable 833Hz sample frequency for tagged sensors") Fixes: c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/a69c8236bf16a1569966815ed71710af2722ed7d.1604247274.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Set 10ms as minimum i2c slave configuration timeout since st_lsm6dsx
relies on accel ODR for i2c master clock and at high sample rates
(e.g. 833Hz or 416Hz) the slave sensor occasionally may need more cycles
than i2c master timeout (2s/833Hz + 1 ~ 3ms) to apply the configuration
resulting in an uncomplete slave configuration and a constant reading
from the i2c slave connected to st_lsm6dsx i2c master.

Fixes: 8f9a5249e3d9 ("iio: imu: st_lsm6dsx: enable 833Hz sample frequency for tagged sensors")
Fixes: c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/a69c8236bf16a1569966815ed71710af2722ed7d.1604247274.git.lorenzo@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: adc: stm32-adc: fix a regression when using dma and irq 2020-11-01T17:14:06+00:00 Olivier Moysan olivier.moysan@st.com 2020-10-21T08:53:13+00:00 695e2f5c289bb7f8b85351dcfa35fa236e0200a4 Since overrun interrupt support has been added, there's a regression when two ADCs are used at the same time, with: - an ADC configured to use IRQs. EOCIE bit is set. The handler is normally called in this case. - an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA request. It's then automatically cleared by DMA read. But the handler gets called due to status bit is temporarily set (IRQ triggered by the other ADC). This is a regression as similar issue had been fixed earlier by commit dcb10920179a ("iio: adc: stm32-adc: fix a race when using several adcs with dma and irq"). Issue is that stm32_adc_eoc_enabled() returns non-zero value (always) since OVR bit has been added and enabled for both DMA and IRQ case. Remove OVR mask in IER register, and rely only on CSR status for overrun. To avoid subsequent calls to interrupt routine on overrun, CSR OVR bit has to be cleared. CSR OVR bit cannot be cleared directly by software. To do this ADC must be stopped first, and OVR bit in ADC ISR has to be cleared. Also add a check in ADC IRQ handler to report spurious IRQs. Fixes: cc06e67d8fa5 ("iio: adc: stm32-adc: Add check on overrun interrupt") Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201021085313.5335-1-olivier.moysan@st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Since overrun interrupt support has been added, there's a regression when
two ADCs are used at the same time, with:
- an ADC configured to use IRQs. EOCIE bit is set. The handler is normally
  called in this case.
- an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA
  request. It's then automatically cleared by DMA read. But the handler
  gets called due to status bit is temporarily set (IRQ triggered by the
  other ADC).

This is a regression as similar issue had been fixed earlier by
commit dcb10920179a ("iio: adc: stm32-adc:
fix a race when using several adcs with dma and irq").
Issue is that stm32_adc_eoc_enabled() returns non-zero value (always)
since OVR bit has been added and enabled for both DMA and IRQ case.

Remove OVR mask in IER register, and rely only on CSR status for overrun.
To avoid subsequent calls to interrupt routine on overrun, CSR OVR bit has
to be cleared. CSR OVR bit cannot be cleared directly by software.
To do this ADC must be stopped first, and OVR bit in ADC ISR has
to be cleared.
Also add a check in ADC IRQ handler to report spurious IRQs.

Fixes: cc06e67d8fa5 ("iio: adc: stm32-adc: Add check on overrun interrupt")
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201021085313.5335-1-olivier.moysan@st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: adc: mediatek: fix unset field 2020-11-01T15:22:46+00:00 Fabien Parent fparent@baylibre.com 2020-10-18T19:46:44+00:00 15207a92e019803d62687455d8aa2ff9eb3dc82c dev_comp field is used in a couple of places but it is never set. This results in kernel oops when dereferencing a NULL pointer. Set the `dev_comp` field correctly in the probe function. Fixes: 6d97024dce23 ("iio: adc: mediatek: mt6577-auxadc, add mt6765 support") Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201018194644.3366846-1-fparent@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
dev_comp field is used in a couple of places but it is never set. This
results in kernel oops when dereferencing a NULL pointer. Set the
`dev_comp` field correctly in the probe function.

Fixes: 6d97024dce23 ("iio: adc: mediatek: mt6577-auxadc, add mt6765 support")
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201018194644.3366846-1-fparent@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: cros_ec: Use default frequencies when EC returns invalid information 2020-11-01T15:22:45+00:00 Gwendal Grignou gwendal@chromium.org 2020-06-30T15:37:30+00:00 56e4f2dda23c6d39d327944faa89efaa4eb290d1 Minimal and maximal frequencies supported by a sensor is queried. On some older machines, these frequencies are not returned properly and the EC returns 0 instead. When returned maximal frequency is 0, ignore the information and use default frequencies instead. Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs") Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20200630153730.3302889-1-gwendal@chromium.org CC: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Minimal and maximal frequencies supported by a sensor is queried.
On some older machines, these frequencies are not returned properly and
the EC returns 0 instead.
When returned maximal frequency is 0, ignore the information and use
default frequencies instead.

Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs")
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200630153730.3302889-1-gwendal@chromium.org
CC: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Merge tag 'tag-chrome-platform-for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux 2020-10-23T17:54:13+00:00 Linus Torvalds torvalds@linux-foundation.org 2020-10-23T17:54:13+00:00 090a7d046fedaaaf41fcdd84ca11764fa5d35233 Pull chrome platform updates from Benson Leung: "cros-ec: - Error code cleanup across cros-ec by Guenter - Remove cros_ec_cmd_xfer in favor of cros_ec_cmd_xfer_status cros_ec_typec: - Landed initial USB4 support in typec connector class driver for cros_ec - Role switch bugfix on disconnect, and reordering configuration steps cros_ec_lightbar: - Fix buffer outsize and result for get_lightbar_version misc: - Remove config MFD_CROS_EC, now that transition from MFD is complete - Enable KEY_LEFTMETA in new location on arm based cros-ec-keyboard keymap" * tag 'tag-chrome-platform-for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: ARM: dts: cros-ec-keyboard: Add alternate keymap for KEY_LEFTMETA platform/chrome: Use kobj_to_dev() instead of container_of() platform/chrome: cros_ec_proto: Drop cros_ec_cmd_xfer() platform/chrome: cros_ec_proto: Update cros_ec_cmd_xfer() call-sites platform/chrome: Kconfig: Remove the transitional MFD_CROS_EC config platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command platform/chrome: cros_ec_trace: Add fields to command traces platform/chrome: cros_ec_typec: Re-order connector configuration steps platform/chrome: cros_ec_typec: Avoid setting usb role twice during disconnect platform/chrome: cros_ec_typec: Send enum values to usb_role_switch_set_role() platform/chrome: cros_ec_typec: USB4 support pwm: cros-ec: Simplify EC error handling platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes platform/input: cros_ec: Replace -ENOTSUPP with -ENOPROTOOPT pwm: cros-ec: Accept more error codes from cros_ec_cmd_xfer_status platform/chrome: cros_ec_sysfs: Report range of error codes from EC cros_ec_lightbar: Accept more error codes from cros_ec_cmd_xfer_status iio: cros_ec: Accept -EOPNOTSUPP as 'not supported' error code 
Pull chrome platform updates from Benson Leung:
 "cros-ec:
   - Error code cleanup across cros-ec by Guenter
   - Remove cros_ec_cmd_xfer in favor of cros_ec_cmd_xfer_status

  cros_ec_typec:
   - Landed initial USB4 support in typec connector class driver for
     cros_ec
   - Role switch bugfix on disconnect, and reordering configuration
     steps

  cros_ec_lightbar:
   - Fix buffer outsize and result for get_lightbar_version

  misc:
   - Remove config MFD_CROS_EC, now that transition from MFD is complete
   - Enable KEY_LEFTMETA in new location on arm based cros-ec-keyboard
     keymap"

* tag 'tag-chrome-platform-for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
  ARM: dts: cros-ec-keyboard: Add alternate keymap for KEY_LEFTMETA
  platform/chrome: Use kobj_to_dev() instead of container_of()
  platform/chrome: cros_ec_proto: Drop cros_ec_cmd_xfer()
  platform/chrome: cros_ec_proto: Update cros_ec_cmd_xfer() call-sites
  platform/chrome: Kconfig: Remove the transitional MFD_CROS_EC config
  platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command
  platform/chrome: cros_ec_trace: Add fields to command traces
  platform/chrome: cros_ec_typec: Re-order connector configuration steps
  platform/chrome: cros_ec_typec: Avoid setting usb role twice during disconnect
  platform/chrome: cros_ec_typec: Send enum values to usb_role_switch_set_role()
  platform/chrome: cros_ec_typec: USB4 support
  pwm: cros-ec: Simplify EC error handling
  platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes
  platform/input: cros_ec: Replace -ENOTSUPP with -ENOPROTOOPT
  pwm: cros-ec: Accept more error codes from cros_ec_cmd_xfer_status
  platform/chrome: cros_ec_sysfs: Report range of error codes from EC
  cros_ec_lightbar: Accept more error codes from cros_ec_cmd_xfer_status
  iio: cros_ec: Accept -EOPNOTSUPP as 'not supported' error code