linux-stable.git/drivers/w1, branch v5.7.7 Linux kernel stable tree w1: omap-hdq: fix interrupt handling which did show spurious timeouts 2020-06-22T07:33:11+00:00 H. Nikolaus Schaller hns@goldelico.com 2020-05-23T17:32:56+00:00 4033c367eebea259241c9a6ba37ea9e9aeb75d83 commit 13db4c40fe0b20b80c7d1c91a9da8411e26b5c27 upstream. Since commit 27d13da8782a ("w1: omap-hdq: Simplify driver with PM runtime autosuspend") was applied, I did see timeouts and wrong values when reading a bq27000 connected to hdq of the omap3. This occurred mainly after boot but remained and only sometimes settled down after several reads. root@letux:~# time cat /sys/class/power_supply/bq27000-battery/uevent POWER_SUPPLY_NAME=bq27000-battery POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_VOLTAGE_NOW=0 POWER_SUPPLY_CURRENT_NOW=0 POWER_SUPPLY_CAPACITY=0 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_TEMP=-2731 POWER_SUPPLY_TIME_TO_EMPTY_NOW=0 POWER_SUPPLY_TIME_TO_EMPTY_AVG=0 POWER_SUPPLY_TIME_TO_FULL_NOW=0 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CHARGE_FULL=0 POWER_SUPPLY_CHARGE_NOW=0 POWER_SUPPLY_CHARGE_FULL_DESIGN=0 POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_ENERGY_NOW=0 POWER_SUPPLY_POWER_AVG=0 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_MANUFACTURER=Texas Instruments real    0m15.761s user    0m0.001s sys     0m0.025s root@letux:~# Sometimes the effect did disappear after accessing the device multiple times, speed went up and results became correct. All this indicates that some interrupts from the hdq controller are lost by the driver. Enabling debugging revealed that there were spurious tx and rx timeouts, i.e. the driver does not always recognise interrupts. The main problem is that rx and tx interrupts share a single variable which was sometimes reset to 0 wiping out other interrupts. And it was overwritten by a second interrupt, independent of whether the previous interrupt was already processed or not. This patch improves interrupt handling to avoid such races and loss of interrupt flags. The ideas are: * only the hdq_isr() sets bits in hdq_status * it does not reset any bits * it does wake_up() if any interrupt is pending * bits are only reset by the read/write/break functions if they were waited for * this makes sure that no interrupts can be lost * rx/tx/timeout bits are completely decoupled from each other (and not reset all after waiting for any of them) * which bits to reset is now specified by a new parameter to hdq_reset_irqstatus() * hdq_reset_irqstatus() also returns the state before resetting so that we can encapsulate the spinlock * this should now handle the case that the write and read are both already finished quickly before the hdq_write_byte() ends. * Or that two interrupts occur in succession before they are processed by the driver. Old code may have reset all status bits making the next hdq_read_byte() timeout. * the spinlock now always protects changing of bits in function hdq_reset_irqstatus() which could become a read-write-modify problem if the interrupt handler tries to read-modify-write exactly at the same moment * we add mutex protection also for hdq_write_byte() just to be safe to not to disturb a hdq_read_byte() triggered by some other thread/process. This patch was tested on a GTA04 and results in no boot problems any more. And first read after boot is now ok: root@letux:~# time cat /sys/class/power_supply/bq27000-battery/uevent POWER_SUPPLY_NAME=bq27000-battery POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_VOLTAGE_NOW=3970000 POWER_SUPPLY_CURRENT_NOW=354144 POWER_SUPPLY_CAPACITY=82 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_TEMP=266 POWER_SUPPLY_TIME_TO_EMPTY_NOW=7680 POWER_SUPPLY_TIME_TO_EMPTY_AVG=7380 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CHARGE_FULL=934856 POWER_SUPPLY_CHARGE_NOW=763976 POWER_SUPPLY_CHARGE_FULL_DESIGN=1233792 POWER_SUPPLY_CYCLE_COUNT=82 POWER_SUPPLY_ENERGY_NOW=2852840 POWER_SUPPLY_POWER_AVG=1392840 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_MANUFACTURER=Texas Instruments real 0m0.233s user 0m0.000s sys 0m0.025s root@letux:~# It was also tested with dev_dbg enabled and more printk that all activities behave correctly, especially hdq_write_byte(), hdq_read_byte(), omap_hdq_break(). Not tested is omap_w1_triplet(). Fixes: 27d13da8782a ("w1: omap-hdq: Simplify driver with PM runtime autosuspend") Cc: stable@vger.kernel.org # v5.6+ Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/68fc8623ae741878beef049273696d2377526165.1590255176.git.hns@goldelico.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 13db4c40fe0b20b80c7d1c91a9da8411e26b5c27 upstream.

Since

commit 27d13da8782a ("w1: omap-hdq: Simplify driver with PM runtime autosuspend")

was applied,

I did see timeouts and wrong values when reading a bq27000 connected
to hdq of the omap3. This occurred mainly after boot but remained and
only sometimes settled down after several reads.

root@letux:~# time cat /sys/class/power_supply/bq27000-battery/uevent
POWER_SUPPLY_NAME=bq27000-battery
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_VOLTAGE_NOW=0
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CAPACITY=0
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_TEMP=-2731
POWER_SUPPLY_TIME_TO_EMPTY_NOW=0
POWER_SUPPLY_TIME_TO_EMPTY_AVG=0
POWER_SUPPLY_TIME_TO_FULL_NOW=0
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CHARGE_FULL=0
POWER_SUPPLY_CHARGE_NOW=0
POWER_SUPPLY_CHARGE_FULL_DESIGN=0
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_ENERGY_NOW=0
POWER_SUPPLY_POWER_AVG=0
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_MANUFACTURER=Texas Instruments

real    0m15.761s
user    0m0.001s
sys     0m0.025s
root@letux:~#

Sometimes the effect did disappear after accessing
the device multiple times, speed went up and results
became correct.

All this indicates that some interrupts from the hdq
controller are lost by the driver.

Enabling debugging revealed that there were spurious tx
and rx timeouts, i.e. the driver does not always recognise
interrupts. The main problem is that rx and tx interrupts
share a single variable which was sometimes reset to
0 wiping out other interrupts. And it was overwritten
by a second interrupt, independent of whether the
previous interrupt was already processed or not.

This patch improves interrupt handling to avoid such
races and loss of interrupt flags.

The ideas are:
* only the hdq_isr() sets bits in hdq_status
* it does not reset any bits
* it does wake_up() if any interrupt is pending
* bits are only reset by the read/write/break functions
  if they were waited for
* this makes sure that no interrupts can be lost
* rx/tx/timeout bits are completely decoupled from each
  other (and not reset all after waiting for any of them)
* which bits to reset is now specified by a new parameter
  to hdq_reset_irqstatus()
* hdq_reset_irqstatus() also returns the state before
  resetting so that we can encapsulate the spinlock
* this should now handle the case that the write and read
  are both already finished quickly before the hdq_write_byte()
  ends.
* Or that two interrupts occur in succession before
  they are processed by the driver.
  Old code may have reset all status bits making the next
  hdq_read_byte() timeout.
* the spinlock now always protects changing of bits in function
  hdq_reset_irqstatus() which could become a read-write-modify
  problem if the interrupt handler tries to read-modify-write
  exactly at the same moment
* we add mutex protection also for hdq_write_byte() just to
  be safe to not to disturb a hdq_read_byte() triggered by
  some other thread/process.

This patch was tested on a GTA04 and results in no
boot problems any more. And first read after boot is now ok:

root@letux:~# time cat /sys/class/power_supply/bq27000-battery/uevent
POWER_SUPPLY_NAME=bq27000-battery
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_VOLTAGE_NOW=3970000
POWER_SUPPLY_CURRENT_NOW=354144
POWER_SUPPLY_CAPACITY=82
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_TEMP=266
POWER_SUPPLY_TIME_TO_EMPTY_NOW=7680
POWER_SUPPLY_TIME_TO_EMPTY_AVG=7380
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CHARGE_FULL=934856
POWER_SUPPLY_CHARGE_NOW=763976
POWER_SUPPLY_CHARGE_FULL_DESIGN=1233792
POWER_SUPPLY_CYCLE_COUNT=82
POWER_SUPPLY_ENERGY_NOW=2852840
POWER_SUPPLY_POWER_AVG=1392840
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_MANUFACTURER=Texas Instruments

real    0m0.233s
user    0m0.000s
sys     0m0.025s
root@letux:~#

It was also tested with dev_dbg enabled and more
printk that all activities behave correctly, especially
hdq_write_byte(), hdq_read_byte(), omap_hdq_break().

Not tested is omap_w1_triplet().

Fixes: 27d13da8782a ("w1: omap-hdq: Simplify driver with PM runtime autosuspend")
Cc: stable@vger.kernel.org # v5.6+
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/68fc8623ae741878beef049273696d2377526165.1590255176.git.hns@goldelico.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
w1: omap-hdq: fix return value to be -1 if there is a timeout 2020-06-22T07:33:11+00:00 H. Nikolaus Schaller hns@goldelico.com 2020-05-23T17:32:55+00:00 d7603a157a0953f43a6d41d57a7f1be829b212f0 commit 2d4100632fa1947bf3e8d7a091e94e2cf21923af upstream. omap_w1_read_byte() should return -1 (or 0xff) in case of error (e.g. missing battery). The code accidentially overwrites the variable ret and not val, which is returned. So it will return the initial value 0 instead of -1. Fixes: 27d13da8782a ("w1: omap-hdq: Simplify driver with PM runtime autosuspend") Cc: stable@vger.kernel.org # v5.6+ Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/b2c2192b461fbb9b8e9bea4ad514a49557a7210b.1590255176.git.hns@goldelico.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2d4100632fa1947bf3e8d7a091e94e2cf21923af upstream.

omap_w1_read_byte() should return -1 (or 0xff) in case of
error (e.g. missing battery).

The code accidentially overwrites the variable ret and not val,
which is returned. So it will return the initial value 0 instead
of -1.

Fixes: 27d13da8782a ("w1: omap-hdq: Simplify driver with PM runtime autosuspend")
Cc: stable@vger.kernel.org # v5.6+
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/b2c2192b461fbb9b8e9bea4ad514a49557a7210b.1590255176.git.hns@goldelico.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
w1: omap-hdq: cleanup to add missing newline for some dev_dbg 2020-06-22T07:33:11+00:00 H. Nikolaus Schaller hns@goldelico.com 2020-05-23T17:32:54+00:00 de45e00848a262fec5a56ddcac2874d725237276 commit 5e02f3b31704e24537697bce54f8156bdb72b7a6 upstream. Otherwise it will corrupt the console log during debugging. Fixes: 7b5362a603a1 ("w1: omap_hdq: Fix some error/debug handling.") Cc: stable@vger.kernel.org Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/cd0d55749a091214106575f6e1d363c6db56622f.1590255176.git.hns@goldelico.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5e02f3b31704e24537697bce54f8156bdb72b7a6 upstream.

Otherwise it will corrupt the console log during debugging.

Fixes: 7b5362a603a1 ("w1: omap_hdq: Fix some error/debug handling.")
Cc: stable@vger.kernel.org
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/cd0d55749a091214106575f6e1d363c6db56622f.1590255176.git.hns@goldelico.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'char-misc-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc 2020-01-29T18:35:54+00:00 Linus Torvalds torvalds@linux-foundation.org 2020-01-29T18:35:54+00:00 701a9c8092ddf299d7f90ab2d66b19b4526d1186 Pull char/misc driver updates from Greg KH: "Here is the big char/misc/whatever driver changes for 5.6-rc1 Included in here are loads of things from a variety of different driver subsystems: - soundwire updates - binder updates - nvmem updates - firmware drivers updates - extcon driver updates - various misc driver updates - fpga driver updates - interconnect subsystem and driver updates - bus driver updates - uio driver updates - mei driver updates - w1 driver cleanups - various other small driver updates All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (86 commits) mei: me: add jasper point DID char: hpet: Use flexible-array member binder: fix log spam for existing debugfs file creation. mei: me: add comet point (lake) H device ids nvmem: add QTI SDAM driver dt-bindings: nvmem: add binding for QTI SPMI SDAM dt-bindings: imx-ocotp: Add i.MX8MP compatible dt-bindings: soundwire: fix example soundwire: cadence: fix kernel-doc parameter descriptions soundwire: intel: report slave_ids for each link to SOF driver siox: Use the correct style for SPDX License Identifier w1: omap-hdq: Simplify driver with PM runtime autosuspend firmware: stratix10-svc: Remove unneeded semicolon firmware: google: Probe for a GSMI handler in firmware firmware: google: Unregister driver_info on failure and exit in gsmi firmware: google: Release devices before unregistering the bus slimbus: qcom: add missed clk_disable_unprepare in remove slimbus: Use the correct style for SPDX License Identifier slimbus: qcom-ngd-ctrl: Use dma_request_chan() instead dma_request_slave_channel() dt-bindings: SLIMBus: add slim devices optional properties ... 
Pull char/misc driver updates from Greg KH:
 "Here is the big char/misc/whatever driver changes for 5.6-rc1

  Included in here are loads of things from a variety of different
  driver subsystems:
   - soundwire updates
   - binder updates
   - nvmem updates
   - firmware drivers updates
   - extcon driver updates
   - various misc driver updates
   - fpga driver updates
   - interconnect subsystem and driver updates
   - bus driver updates
   - uio driver updates
   - mei driver updates
   - w1 driver cleanups
   - various other small driver updates

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'char-misc-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (86 commits)
  mei: me: add jasper point DID
  char: hpet: Use flexible-array member
  binder: fix log spam for existing debugfs file creation.
  mei: me: add comet point (lake) H device ids
  nvmem: add QTI SDAM driver
  dt-bindings: nvmem: add binding for QTI SPMI SDAM
  dt-bindings: imx-ocotp: Add i.MX8MP compatible
  dt-bindings: soundwire: fix example
  soundwire: cadence: fix kernel-doc parameter descriptions
  soundwire: intel: report slave_ids for each link to SOF driver
  siox: Use the correct style for SPDX License Identifier
  w1: omap-hdq: Simplify driver with PM runtime autosuspend
  firmware: stratix10-svc: Remove unneeded semicolon
  firmware: google: Probe for a GSMI handler in firmware
  firmware: google: Unregister driver_info on failure and exit in gsmi
  firmware: google: Release devices before unregistering the bus
  slimbus: qcom: add missed clk_disable_unprepare in remove
  slimbus: Use the correct style for SPDX License Identifier
  slimbus: qcom-ngd-ctrl: Use dma_request_chan() instead dma_request_slave_channel()
  dt-bindings: SLIMBus: add slim devices optional properties
  ...
w1: omap-hdq: Simplify driver with PM runtime autosuspend 2020-01-14T20:46:48+00:00 Tony Lindgren tony@atomide.com 2019-12-17T00:40:48+00:00 27d13da8782aa2c59a3c71c1c31e65c9af72b7fb We've had generic code handling module sysconfig and OCP reset registers for omap variants for many years now and all the drivers really needs to do is just call runtime PM functions. Looks like the omap-hdq driver got only partially updated over the years to use runtime PM, and still has lots of custom PM code left. We can replace all the custom code for sysconfig, OCP reset, and PM with just a few lines of runtime PM autosuspend code. In order to set the device mode properly when pm_runtime_get_sync() is called during probe, we need to also move parsing of "ti,mode" to happen earlier before we call pm_runtime_enable(). Since we now disable interrupts lazily in omap_hdq_runtime_suspend(), we must remove the call to hdq_disable_interrupt() in omap_w1_read_byte(). And we must clear irqstatus calling wait_event_timeout() on it, so let's add hdq_reset_irqstatus() for that. Note that the earlier driver specific usage count limit of four seems completely artificial and should not be an issue in normal use. Cc: Adam Ford <aford173@gmail.com> Cc: Andrew F. Davis <afd@ti.com> Cc: Andreas Kemnade <andreas@kemnade.info> Cc: H. Nikolaus Schaller <hns@goldelico.com> Cc: Vignesh R <vigneshr@ti.com> Tested-by: Andreas Kemnade <andreas@kemnade.info> # gta04 Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20191217004048.46298-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
We've had generic code handling module sysconfig and OCP reset registers
for omap variants for many years now and all the drivers really needs to
do is just call runtime PM functions.

Looks like the omap-hdq driver got only partially updated over the years
to use runtime PM, and still has lots of custom PM code left.

We can replace all the custom code for sysconfig, OCP reset, and PM with
just a few lines of runtime PM autosuspend code.

In order to set the device mode properly when pm_runtime_get_sync() is
called during probe, we need to also move parsing of "ti,mode" to happen
earlier before we call pm_runtime_enable().

Since we now disable interrupts lazily in omap_hdq_runtime_suspend(), we
must remove the call to hdq_disable_interrupt() in omap_w1_read_byte().
And we must clear irqstatus calling wait_event_timeout() on it, so let's
add hdq_reset_irqstatus() for that.

Note that the earlier driver specific usage count limit of four seems
completely artificial and should not be an issue in normal use.

Cc: Adam Ford <aford173@gmail.com>
Cc: Andrew F. Davis <afd@ti.com>
Cc: Andreas Kemnade <andreas@kemnade.info>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Vignesh R <vigneshr@ti.com>
Tested-by: Andreas Kemnade <andreas@kemnade.info> # gta04
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20191217004048.46298-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
remove ioremap_nocache and devm_ioremap_nocache 2020-01-06T08:45:59+00:00 Christoph Hellwig hch@lst.de 2020-01-06T08:43:50+00:00 4bdc0d676a643140bdf17dbf7eafedee3d496a3c ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Arnd Bergmann <arnd@arndb.de> 
ioremap has provided non-cached semantics by default since the Linux 2.6
days, so remove the additional ioremap_nocache interface.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
w1: new driver. DS2430 chip 2019-11-14T05:06:33+00:00 Angelo Dureghello angelo.dureghello@timesys.com 2019-10-19T20:40:15+00:00 c6bf3842a34abe3ec2f5bc81754883689aea6c0d add support for ds2430, 1 page, 256bit (32bytes) eeprom (family 0x14). Tests done: 32 bytes dump: x@y:~# hexdump -C -n 32 /sys/bus/w1/devices/14-00000158556e/eeprom 00000000 39 39 0a 00 00 36 0a ff ff ff ff ff ff ff ff ff 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00000020 34 bytes dump: 32 only displayed x@y:~# hexdump -C -n 34 /sys/bus/w1/devices/14-00000158556e/eeprom 00000000 39 39 0a 00 00 36 0a ff ff ff ff ff ff ff ff ff 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00000020 pattern write: x@y:~# echo 123456789 > /sys/bus/w1/devices/14-00000158556e/eeprom x@y:~# hexdump -C -n 54 /sys/bus/w1/devices/14-00000158556e/eeprom 00000000 31 32 33 34 35 36 37 38 39 0a ff ff ff ff ff ff 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00000020 specific address 1-byte write x@y:~# dd if=/dev/zero of=/sys/bus/w1/devices/14-00000158556e/eeprom \ count=1 bs=1 seek=4 1+0 records in 1+0 records out x@y:~# hexdump -C -n 54 /sys/bus/w1/devices/14-00000158556e/eeprom 00000000 31 32 33 34 00 36 37 38 39 0a ff ff ff ff ff ff 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00000020 writing binary block x@y:~# cat dump-128bytes.bin > /sys/bus/w1/devices/14-00000158556e/eeprom cat: write error: File too large x@y:~# cat dump-32bytes.bin > /sys/bus/w1/devices/14-00000158556e/eeprom x@y:~# hexdump -C -n 54 /sys/bus/w1/devices/14-00000158556e/eeprom 00000000 10 0b 5b ff ff ff ff ff ff ff ff ff ff ff ff ff 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 40 00000020 Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> Link: https://lore.kernel.org/r/20191019204015.61474-1-angelo.dureghello@timesys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
add support for ds2430, 1 page, 256bit (32bytes) eeprom
(family 0x14).

Tests done:

32 bytes dump:

x@y:~# hexdump -C -n 32 /sys/bus/w1/devices/14-00000158556e/eeprom
00000000  39 39 0a 00 00 36 0a ff  ff ff ff ff ff ff ff ff
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
00000020

34 bytes dump: 32 only displayed

x@y:~# hexdump -C -n 34 /sys/bus/w1/devices/14-00000158556e/eeprom
00000000  39 39 0a 00 00 36 0a ff  ff ff ff ff ff ff ff ff
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
00000020

pattern write:

x@y:~# echo 123456789 > /sys/bus/w1/devices/14-00000158556e/eeprom
x@y:~# hexdump -C -n 54 /sys/bus/w1/devices/14-00000158556e/eeprom
00000000  31 32 33 34 35 36 37 38  39 0a ff ff ff ff ff ff
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
00000020

specific address 1-byte write

x@y:~# dd if=/dev/zero of=/sys/bus/w1/devices/14-00000158556e/eeprom \
		count=1 bs=1 seek=4
1+0 records in
1+0 records out
x@y:~# hexdump -C -n 54 /sys/bus/w1/devices/14-00000158556e/eeprom
00000000  31 32 33 34 00 36 37 38  39 0a ff ff ff ff ff ff
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
00000020

writing binary block

x@y:~# cat dump-128bytes.bin > /sys/bus/w1/devices/14-00000158556e/eeprom
cat: write error: File too large

x@y:~# cat dump-32bytes.bin > /sys/bus/w1/devices/14-00000158556e/eeprom
x@y:~# hexdump -C -n 54 /sys/bus/w1/devices/14-00000158556e/eeprom
00000000  10 0b 5b ff ff ff ff ff  ff ff ff ff ff ff ff ff
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff 40
00000020

Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com>
Link: https://lore.kernel.org/r/20191019204015.61474-1-angelo.dureghello@timesys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge 5.4-rc3 into char-misc-next 2019-10-14T05:36:49+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2019-10-14T05:36:49+00:00 97856e59384de326174360a780038113fea19f42 We need the char/misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
We need the char/misc fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
w1: ds250x: Fix build error without CRC16 2019-10-10T13:35:41+00:00 YueHaibing yuehaibing@huawei.com 2019-09-20T06:03:18+00:00 b058b2552edb4a6ce62922bf904149bbafd5fd9d If CRC16 is not set, building will fails: drivers/w1/slaves/w1_ds250x.o: In function `w1_ds2505_read_page': w1_ds250x.c:(.text+0x82f): undefined reference to `crc16' w1_ds250x.c:(.text+0x90a): undefined reference to `crc16' w1_ds250x.c:(.text+0x91a): undefined reference to `crc16' Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 25ec8710d9c2 ("w1: add DS2501, DS2502, DS2505 EPROM device driver") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20190920060318.35020-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
If CRC16 is not set, building will fails:

drivers/w1/slaves/w1_ds250x.o: In function `w1_ds2505_read_page':
w1_ds250x.c:(.text+0x82f): undefined reference to `crc16'
w1_ds250x.c:(.text+0x90a): undefined reference to `crc16'
w1_ds250x.c:(.text+0x91a): undefined reference to `crc16'

Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 25ec8710d9c2 ("w1: add DS2501, DS2502, DS2505 EPROM device driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20190920060318.35020-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
w1: sgi_w1: use devm_platform_ioremap_resource() to simplify code 2019-10-10T13:24:18+00:00 YueHaibing yuehaibing@huawei.com 2019-10-09T14:44:35+00:00 71200fcbb91c1a6b6da7fe1c806c6dd27b42e14c Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20191009144435.12656-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20191009144435.12656-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>