The EDAC is a sub-function of the SDRAM Memory Controller. Rename the
node to the appropriate generic node name.
Cc: Stefan M Schaeckeler <sschaeck@cisco.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Stefan Schaeckeler <sschaeck@cisco.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Previously the register interface was not attached to any internal bus,
which is not correct - it lives on the APB.
Cc: Stefan M Schaeckeler <sschaeck@cisco.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Stefan Schaeckeler <sschaeck@cisco.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
There are some extra data transfer in dsi.
ex. LPX, hs_prepare, hs_zero, hs_exit and the sof/eof of dsi packet.
This signal will enlarge the line time. So the real frame on dsi bus
will be lower than calc by video timing.
So dsi driver reduces the hbp and hfp to keep the line time.
Fixes: 7a5bc4e22e ("drm/mediatek: change the dsi phytiming calculate method")
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Tested-by: Hsin-Yi Wang <hsinyi@chromium.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Instead of repeatedly calling tpm_chip_start/tpm_chip_stop when
issuing commands to the tpm during initialization, just reserve the
chip after wait_startup, and release it when we are ready to call
tpm_chip_register.
Cc: Christian Bundy <christianbundy@fraction.io>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Peter Huewe <peterhuewe@gmx.de>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Fixes: a3fbfae82b ("tpm: take TPM chip power gating out of tpm_transmit()")
Fixes: 5b359c7c43 ("tpm_tis_core: Turn on the TPM before probing IRQ's")
Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
I didn't get a batch in this weekend, so here's what we queued up last
week and today.
- A couple of defconfigs add back debugfs -- it used to be implicitly
enabled through CONFIG_TRACING, but 0e4a459f56 ("tracing: Remove
unnecessary DEBUG_FS dependency") removed that.
- The rest are mostly minor fixlets of the usual kind; some DT tweaks,
a headerfile refactor that needs a build fix now, etc.
-----BEGIN PGP SIGNATURE-----
iQJDBAABCAAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAl33/BcPHG9sb2ZAbGl4
b20ubmV0AAoJEIwa5zzehBx3DtAP+wWlWswNVYUypZp5qhsTQ9cezsACbR+kh7WD
qpEFxylLxqI1MqKnbZ7CTOKWQHPiqA5hMnuK1gBpzOvXTK+akYa0VtdG1ETRkJni
L9QXjWq7ax1J68yAeKgIff6WWBBKr98C+HZ3uK/3jdat1xKLHUXrH6T/cgUjG0jm
JtomFEIVtMb/RdW3rbfxA4IfmrxfCAs4fQQwc9xkc23dEeF3Y9oSxsRxRT9C7J4I
ZnqvWTWaWN77y/4V4hUMhdPwGI4hH8fv71DFEgP+9LqG3OVQvKfc+H5UrR0KUjEY
qk8bAD1jcLbkICpazeQDozAbdTt1NBSt+4zBm4gZA9vZc78Tk3mbJ4+m5JlZNt4h
PQf8r6n8GYZ266mr6k5rPZ/kNv4dxL59HIkZL1EER8vUvZykEl1nztjw4PMt0xX1
xK7xfx9p6YN/jKDcwTTCuSzMd8d3YWqbuXzpbTbZCe4dsDiwfsSMaskIGRU7bx2U
LvGZ0uVc8x7m7lV2NHvOVVzBg/i7H7l3Xq7Qq7doHExqmenFWcjG0YKiMeGUOE3X
sCvHH0ip45x3vxiYzRRnUWmNyrcHnR1M2X3UwqXt9GHLgJ2vD+jS32cve2x643XN
tby+szKimDbyeqxPDfWkUV0K1if66PFt3Czr0erFHYadS3o47v23pHjhsl+fIcY6
2xx8hH8O
=cr5E
-----END PGP SIGNATURE-----
Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC fixes from Olof Johansson:
"I didn't get a batch in this weekend, so here's what we queued up last
week and today.
- A couple of defconfigs add back debugfs -- it used to be implicitly
enabled through CONFIG_TRACING, but 0e4a459f56 ("tracing:
Remove unnecessary DEBUG_FS dependency") removed that.
- The rest are mostly minor fixlets of the usual kind; some DT
tweaks, a headerfile refactor that needs a build fix now, etc"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (30 commits)
ARM: bcm: Add missing sentinel to bcm2711_compat[]
ARM: shmobile: defconfig: Restore debugfs support
bus: ti-sysc: Fix missing reset delay handling
ARM: imx: Fix boot crash if ocotp is not found
ARM: imx_v6_v7_defconfig: Explicitly restore CONFIG_DEBUG_FS
ARM: dts: imx6ul-evk: Fix peripheral regulator
arm64: dts: ls1028a: fix reboot node
ARM: mmp: include the correct cputype.h
ARM: dts: am437x-gp/epos-evm: fix panel compatible
arm64: dts: ls1028a: fix typo in TMU calibration data
ARM: imx: Correct ocotp id for serial number support of i.MX6ULL/ULZ SoCs
ARM: dts: bcm283x: Fix critical trip point
ARM: omap2plus_defconfig: Add back DEBUG_FS
ARM: omap2plus_defconfig: enable NET_SWITCHDEV
ARM: dts: am335x-sancloud-bbe: fix phy mode
bus: ti-sysc: Fix missing force mstandby quirk handling
reset: Do not register resource data for missing resets
reset: Fix {of,devm}_reset_control_array_get kerneldoc return types
reset: brcmstb: Remove resource checks
dt-bindings: reset: Fix brcmstb-reset example
...
In caif_xmit, there is a crash if the ptr dev is NULL. However, by
returning the error to the callers, the error can be handled. The
patch fixes this issue.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
In fore200e_send and fore200e_close, the pointers from the arguments
are dereferenced in the variable declaration block and then checked
for NULL. The patch fixes these issues by avoiding NULL pointer
dereferences.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the implementation of gmac_setup_txqs() the allocated desc_ring is
leaked if TX queue base is not aligned. Release it via
dma_free_coherent.
Fixes: 4d5ae32f5e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now that the i2c-bcm-iproc driver has been fixed to permit reading more
than 63 bytes in a single transaction with commit fd01eecdf9 ("i2c:
iproc: Fix i2c master read more than 63 bytes") we no longer need to
bitbang i2c over GPIOs which was necessary before to allow the
PHYLINK/SFP subsystems to read SFP modules.
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Ido Schimmel says:
====================
Simplify IPv4 route offload API
Motivation
==========
The aim of this patch set is to simplify the IPv4 route offload API by
making the stack a bit smarter about the notifications it is generating.
This allows driver authors to focus on programming the underlying device
instead of having to duplicate the IPv4 route insertion logic in their
driver, which is error-prone.
This is the first patch set out of a series of four. Subsequent patch
sets will simplify the IPv6 API, add offload/trap indication to routes
and add tests for all the code paths (including error paths). Available
here [1].
Details
=======
Today, whenever an IPv4 route is added or deleted a notification is sent
in the FIB notification chain and it is up to offload drivers to decide
if the route should be programmed to the hardware or not. This is not an
easy task as in hardware routes are keyed by {prefix, prefix length,
table id}, whereas the kernel can store multiple such routes that only
differ in metric / TOS / nexthop info.
This series makes sure that only routes that are actually used in the
data path are notified to offload drivers. This greatly simplifies the
work these drivers need to do, as they are now only concerned with
programming the hardware and do not need to replicate the IPv4 route
insertion logic and store multiple identical routes.
The route that is notified is the first FIB alias in the FIB node with
the given {prefix, prefix length, table ID}. In case the route is
deleted and there is another route with the same key, a replace
notification is emitted. Otherwise, a delete notification is emitted.
The above means that in the case of multiple routes with the same key,
but different TOS, only the route with the highest TOS is notified.
While the kernel can route a packet based on its TOS, this is not
supported by any hardware devices I am familiar with. Moreover, this is
not supported by IPv6 nor by BIRD/FRR from what I could see. Offload
drivers should therefore use the presence of a non-zero TOS as an
indication to trap packets matching the route and let the kernel route
them instead. mlxsw has been doing it for the past two years.
Testing
=======
To ensure there is no degradation in route insertion rates, I averaged
the insertion rate of 512k routes (/24 and /32) over 50 runs. Did not
observe any degradation.
Functional tests are available here [1]. They rely on route trap
indication, which is only added in the last patch set.
In addition, I have been running syzkaller for the past week with all
four patch sets and debug options enabled. Did not observe any problems.
Patch set overview
==================
Patches #1-#8 gradually introduce the new FIB notifications
Patch #9 converts mlxsw to use the new notifications
Patch #10 converts the remaining listeners and removes the old
notifications
v2:
* Extend fib_find_alias() with another argument instead of introducing a
new function (David Ahern)
RFC: https://patchwork.ozlabs.org/cover/1170530/
[1] https://github.com/idosch/linux/tree/fib-notifier
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Unlike mlxsw, the other listeners to the FIB notification chain do not
require any special modifications as they never considered multiple
identical routes.
This patch removes the old route notifications and converts all the
listeners to use the new replace / delete notifications.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
With the new notifications mlxsw does not need to handle identical
routes itself, as this is taken care of by the core IPv4 code.
Instead, mlxsw only needs to take care of inserting and removing routes
from the device.
Convert mlxsw to use the new IPv4 route notifications and simplify the
code.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a new listener is registered to the FIB notification chain it
receives a dump of all the available routes in the system. Instead, make
sure to only replay the IPv4 routes that are actually used in the data
path and are of any interest to the new listener.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In a similar fashion to previous patch, when a route is deleted as part
of table flushing, promote the next route in the list, if exists.
Otherwise, simply emit a delete notification.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a route is deleted we potentially need to promote the next route in
the FIB alias list (e.g., with an higher metric). In case we find such a
route, a replace notification is emitted. Otherwise, a delete
notification for the deleted route.
v2:
* Convert to use fib_find_alias() instead of fib_find_first_alias()
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a route is added, it should only be notified in case it is the
first route in the FIB alias list with the given {prefix, prefix length,
table ID}. Otherwise, it is not used in the data path and should not be
considered by switch drivers.
v2:
* Convert to use fib_find_alias() instead of fib_find_first_alias()
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When replacing a route, its replacement should only be notified in case
the replaced route is of any interest to listeners. In other words, if
the replaced route is currently used in the data path, which means it is
the first route in the FIB alias list with the given {prefix, prefix
length, table ID}.
v2:
* Convert to use fib_find_alias() instead of fib_find_first_alias()
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Extend the function with another argument, 'find_first'. When set, the
function returns the first FIB alias with the matching {prefix, prefix
length, table ID}. The TOS and priority parameters are ignored. Current
callers are converted to pass 'false' in order to maintain existing
behavior.
This will be used by subsequent patches in the series.
v2:
* New patch
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Suggested-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, a new route is notified in the FIB notification chain before
it is inserted to the FIB alias list.
Subsequent patches will use the placement of the new route in the
ordered FIB alias list in order to determine if the route should be
notified or not.
As a preparatory step, change the order so that the route is first
inserted into the FIB alias list and only then notified.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Subsequent patches are going to simplify the IPv4 route offload API,
which will only use two events - replace and delete.
Introduce a temporary version of these two events in order to make the
conversion easier to review.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Huazhong Tan says:
====================
net: hns3: some optimizaions related to work task
This series refactors the work task of the HNS3 ethernet driver.
[patch 1/5] uses delayed workqueue to replace the timer for
hclgevf_service task, make the code simpler.
[patch 2/5] & [patch 3/5] unifies current mailbox, reset and
service work into one.
[patch 4/5] allocates a private work queue with WQ_MEM_RECLAIM
for the HNS3 driver.
[patch 5/5] adds a new flag to indicate whether reset fails,
and prevent scheduling service task to handle periodic task
when this flag has been set.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
service_task will be scheduled per second to do some periodic
jobs. When reset fails, it means this device is not available
now, so the periodic jobs do not need to be handled.
This patch adds flag HCLGE_STATE_RST_FAIL/HCLGEVF_STATE_RST_FAIL
to indicate that reset fails, and checks this flag before
schedule periodic task.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The hns3 driver may be used in memory reclaim path when it
is the low level transport of a network file system, so it
needs to guarantee forward progress even under memory pressure.
This patch allocates a private WQ with WQ_MEM_RECLAIM set for
both hclge_main and hclgevf_main modules.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There are four work (mbx_service_task, service_task,
rst_service_task and keep_alive_task)in the hclgevf module,
mbx_service_task is for handling mailbox issue, service_task is
for periodic management issue and rst_service_task is for reset
related issue, keep_alive_task is used to keepalive between PF
and VF, which can be done in a single work.
This patch removes the mbx_service_task, rst_service_task and
keep_alive_task, and moves the related handling to the
service_task work in order to remove concurrency between the four
work and to improve efficiency.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There are three work (mbx_service_task, service_task,
rst_service_task) in the HNS3 driver, mbx_service_task is for
handling mailbox work, service_task is for periodic management
issue and rst_service_task is for reset related issue, which can
be handled in a single work.
This patch removes the mbx_service_task and rst_service_task
work, and moves the related handling to the service_task work
in order to remove concurrency between the three work and to
improve efficiency.
BTW, since stats_timer in struct hclge_hw_stats is not needed
anymore, so removes the definition of struct hclge_hw_stats,
and moves mac_stats into struct hclge_dev.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, a timer is defined to schedule hclgevf_service per
second. To simplify the code, this patch uses the delayed work
instead of timer to schedule hclgevf_serive.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The sparse commit 6002ded74587 ("add a flag to warn on casts to/from
bitwise pointers") introduced a check for non-direct casts from/to
restricted datatypes (when -Wbitwise-pointer is enabled).
This triggered a warning in the 64 bit optimized ipv6_addr_is_*() functions
because sparse doesn't know that the buffer already points to some data in
the correct bitwise integer format. But these were correct and can
therefore be marked with __force to signalize sparse an intended cast to a
specific bitwise type.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The sparse commit 6002ded74587 ("add a flag to warn on casts to/from
bitwise pointers") introduced a check for non-direct casts from/to
restricted datatypes (when -Wbitwise-pointer is enabled).
This triggered a warning in ipv6_get_dsfield() because sparse doesn't know
that the buffer already points to some data in the correct bitwise integer
format. This was already fixed in ipv6_change_dsfield() by the __force
attribute and can be fixed here the same way.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
There were several issues with 53568438e3 ("net: dsa: b53: Add support for port_egress_floods callback") that resulted in breaking connectivity for standalone ports:
- both user and CPU ports must allow unicast and multicast forwarding by
default otherwise this just flat out breaks connectivity for
standalone DSA ports
- IP multicast is treated similarly as multicast, but has separate
control registers
- the UC, MC and IPMC lookup failure register offsets were wrong, and
instead used bit values that are meaningful for the
B53_IP_MULTICAST_CTRL register
Fixes: 53568438e3 ("net: dsa: b53: Add support for port_egress_floods callback")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Stefano Garzarella says:
====================
vsock/virtio: fix null-pointer dereference and related precautions
This series mainly solves a possible null-pointer dereference in
virtio_transport_recv_listen() introduced with the multi-transport
support [PATCH 1].
PATCH 2 adds a WARN_ON check for the same potential issue
and a returned error in the virtio_transport_send_pkt_info() function
to avoid crashing the kernel.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
virtio_transport_get_ops() and virtio_transport_send_pkt_info()
can only be used on connecting/connected sockets, since a socket
assigned to a transport is required.
This patch adds a WARN_ON() on virtio_transport_get_ops() to check
this requirement, a comment and a returned error on
virtio_transport_send_pkt_info(),
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some users complained about problems with r8169 and it turned out that
the generic PHY driver was used instead instead of the dedicated one.
In all cases reason was that r8169.ko was in initramfs, but realtek.ko
not. Manually adding realtek.ko to initramfs fixed the issues.
Root cause seems to be that tools like dracut and genkernel don't
consider softdeps. Add a check for loaded Realtek PHY driver module
and provide the user with a hint if it's not loaded.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Yangbo Lu says:
====================
dpaa2-ptp: support external trigger event
This patch-set is to add external trigger event support for
dpaa2-ptp driver since MC firmware has supported external
trigger interrupt with a new v2 dprtc_set_irq_mask() API.
And extts_clean_up() function in ptp_qoriq driver needs to be
exported with minor fixes for dpaa2-ptp reusing.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch is to add external trigger event support
for dpaa2-ptp driver with v2 dprtc_set_irq_mask() API.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Export extts_clean_up() function so that dpaa2-ptp
driver is able to reuse it.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For PTP timer supporting external trigger timestamp FIFO,
there is a valid bit in TMR_STAT register indicating the
timestamp is available. For PTP timer without FIFO, there
is not TMR_STAT register.
This patch is to check the valid bit for the FIFO before
reading timestamp, and to avoid operating TMR_STAT register
for PTP timer without the FIFO.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We need this to pass auxdata to all the sdma instances.
Cc: devicetree@vger.kernel.org
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Vinod Koul <vkoul@kernel.org>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The P2A controller node sits under a syscon device, and can assume
offsets from the base of the syscon based on the compatible. However,
for devicetree correctness allow a reg property to be specified, which
an associated driver may choose to use to discover associated resources.
Cc: Patrick Venture <venture@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
The pinctrl node sits under a syscon device, and can assume offsets from
the base of the syscon based on the compatible. However, for devicetree
correctness allow a reg property to be specified, which an associated
driver may choose to use to discover associated resources.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
We currently use an error-prone mutex_trylock to grab another timeline
to find an earlier request along it. However, with a bit of a
sleight-of-hand, we can reduce the mutex_trylock to a spin_lock on the
immediate request and careful pointer chasing to acquire a reference on
the previous request.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191216165317.2742896-1-chris@chris-wilson.co.uk
With a couple more memory barriers dotted around the place we can
significantly reduce the MTBF on Ivybridge. Still doesn't really help
Haswell though.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191216142409.2605211-1-chris@chris-wilson.co.uk
