The current implementation of fw_devlink is very inefficient because it
tries to get away without creating fwnode links in the name of saving
memory usage. Past attempts to optimize runtime at the cost of memory
usage were blocked with request for data showing that the optimization
made significant improvement for real world scenarios.
We have those scenarios now. There have been several reports of boot
time increase in the order of seconds in this thread [1]. Several OEMs
and SoC manufacturers have also privately reported significant
(350-400ms) increase in boot time due to all the parsing done by
fw_devlink.
So this patch uses all the setup done by the previous patches in this
series to refactor fw_devlink to be more efficient. Most of the code has
been moved out of firmware specific (DT mostly) code into driver core.
This brings the following benefits:
- Instead of parsing the device tree multiple times during bootup,
fw_devlink parses each fwnode node/property only once and creates
fwnode links. The rest of the fw_devlink code then just looks at these
fwnode links to do rest of the work.
- Makes it much easier to debug probe issue due to fw_devlink in the
future. fw_devlink=on blocks the probing of devices if they depend on
a device that hasn't been added yet. With this refactor, it'll be very
easy to tell what that device is because we now have a reference to
the fwnode of the device.
- Much easier to add fw_devlink support to ACPI and other firmware
types. A refactor to move the common bits from DT specific code to
driver core was in my TODO list as a prerequisite to adding ACPI
support to fw_devlink. This series gets that done.
[1] - https://lore.kernel.org/linux-omap/ea02f57e-871d-cd16-4418-c1da4bbc4696@ti.com/
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-17-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f9aa460672)
Bug: 178143855
Bug: 169667932
Change-Id: Iabaf0f1793d1d211286218f010c8a80d76edf060
The semantics of add_links() has changed from creating device link
between devices to creating fwnode links between fwnodes. So, update the
implementation of add_links() to match the new semantics.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-16-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e82a840cb1)
Bug: 178143855
Bug: 169667932
Change-Id: Ieac21cf68ba1cc5289eee69c0891225b82878e74
To check if a device is still waiting for its supplier devices to be
added, we used to check if the devices is in a global
waiting_for_suppliers list. Since the global list will be deleted in
subsequent patches, this patch stops using this check.
Instead, this patch uses a more device specific check. It checks if the
device's fwnode has any fwnode links that haven't been converted to
device links yet.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-14-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 25ac86c6db)
Bug: 178143855
Bug: 169667932
Change-Id: I1ad987cbde98bf0fef9a850942d1910a43b54d11
This function is a wrapper around fwnode_operations.add_links().
This function parses each node in a fwnode tree and create fwnode links
for each of those nodes. The information for creating the fwnode links
(the supplier and consumer fwnode) is obtained by parsing the properties
in each of the fwnodes.
This function also ensures that no fwnode is parsed more than once by
marking the fwnodes as parsed.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-13-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c2c724c868)
Bug: 178143855
Bug: 169667932
Change-Id: I5e934d6a508d96a697016f1451cc595ef671d839
Change the meaning of fwnode_operations.add_links() to just create
fwnode links by parsing the properties of a given fwnode.
This patch doesn't actually make any code changes. To keeps things more
digestable, the actual functional changes come in later patches in this
series.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-12-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 04f63c213b)
Bug: 178143855
Bug: 169667932
Change-Id: Ifca0afb02969667e2395f25047f96d427f2b813b
Add fwnode_is_ancestor_of() helper function to check if a fwnode is an
ancestor of another fwnode.
Add fwnode_get_next_parent_dev() helper function that take as input a
fwnode and finds the closest ancestor fwnode that has a corresponding
struct device and returns that struct device.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-11-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b5d3e2fbcb)
Bug: 178143855
Bug: 169667932
Change-Id: Ia49bc3f92c67ed437825a043794b3edc2689e503
SYNC_STATE_ONLY device links only affect the behavior of sync_state()
callbacks. Specifically, they prevent sync_state() only callbacks from
being called on a device if one or more of its consumers haven't probed.
So, creating a SYNC_STATE_ONLY device link from an already probed
consumer is useless. So, don't allow creating such device links.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-10-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ac66c5bbb4)
Bug: 178143855
Bug: 169667932
Change-Id: Ife356503237b1378f80a84579b932417f257d5d8
Add support for creating supplier-consumer links between fwnodes. It is
intended for internal use the driver core and generic firmware support
code (eg. Device Tree, ACPI), so it is simple by design and the API
provided is limited.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-9-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7b337cb3eb)
Bug: 178143855
Bug: 169667932
Change-Id: I648e8f779b9f64f2544412854c084a38eb7f3c2c
This reverts commit 716a7a2596.
The fw_devlink_pause/resume() APIs added by the commit being reverted
were a first cut attempt at optimizing boot time. But these APIs don't
fully solve the problem and are very fragile (can only be used for the
top level devices being added). This series replaces them with a much
better optimization that works for all device additions and also has the
benefit of reducing the complexity of the firmware (DT, EFI) specific
code and abstracting out common code to driver core.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-7-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c84b90909e)
Bug: 178143855
Bug: 169667932
Change-Id: I6b998bff78a4d3a2939b7db607f5eb174f5d0e69
This reverts commit cec72f3efc.
Commit cec72f3efc ("driver core: Don't do deferred probe in parallel
with kernel_init thread") was fixing a commit 716a7a2596 ("driver
core: fw_devlink: Add support for batching fwnode parsing"). Since the
commit being fixed itself is going to be reverted, the fix can also be
reverted.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-4-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 96d8a9168e)
Bug: 178143855
Bug: 169667932
Change-Id: I66ce5ef3089e61e4c92ddfff785c43ad8c3f379e
This reverts commit ec7bd78498.
This field rename was done to reuse defer_syc list head for multiple
lists. That's not needed anymore and this list head will only be used
for defer sync. So revert this patch to avoid conflicts with the other
reverts coming after this.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-3-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3b052a3e30)
Bug: 178143855
Bug: 169667932
Change-Id: Ic5747a9d7e6f659fe29e09bb0f9d7f15efc52746
This reverts commit 2451e74647.
fw_devlink_pause/resume() was an incomplete attempt at boot time
optimization. That's going to get replaced by a much better optimization
at the end of the series. Since fw_devlink_pause/resume() is going away,
changes made for that can also go away.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c95d64012a)
Bug: 178143855
Bug: 169667932
Change-Id: Id9c7a6cc8d6dea4172a88a05fa9853de33500f12
We add a vendor hook for util to freq calculation in schedutil,
so we need to do corresponding change for energy calculation.
android_vh_em_cpu_energy
adjust energy calculation
Bug: 178047619
Signed-off-by: Yun Hsiang <yun.hsiang@mediatek.com>
Change-Id: Iae772cf07881602eea3f27aeb75fba753e7c2635
PD3.0 Spec 6.8.1 describes how to handle Protocol Error. There are
general rules defined in Table 6-61 which regulate incoming Message
handling. If the incoming Message is unexpected, unsupported, or
unrecognized, Protocol Error occurs. Follow the rules to handle these
situations. Also consider PD2.0 connection (PD2.0 Spec Table 6-36) for
backward compatibilities.
To know the types of AMS in all the recipient's states, identify those
AMS who are initiated by the port partner but not yet recorded in the
current code.
Besides, introduce a new state CHUNK_NOT_SUPP to delay the NOT_SUPPORTED
message after receiving a chunked message.
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Kyle Tso <kyletso@google.com>
Link: https://lore.kernel.org/r/20210114145053.1952756-3-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8dea75e113https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia0744de43bb709fcdece70848b72b8edfba8ac2e
Add hook to gather data of bug trap and summarize it with other
information.
Bug: 177483057
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Change-Id: Ic44fd1c3c4e43f04510a871a8dbeb25aafc45e95
I found one case as follows and the current flush
location doesn't guarantee disabling BKOPS in the
case of requsting device power off.
1) The exceptional event handler is queued.
2) ufs suspend starts with a request of device power off
3) BKOPS is disabled in ufs suspend
4) The queued work for the handler is done and BKOPS
is enabled again.
Bug: 177395905
Change-Id: Ib69b8ebfb97469ff37ef8a70bdbc1ac2e79adcb0
(cherry picked from commit 6948a96a0dhttps://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 5.11/scsi-fixes)
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Reviewed-by: Can Guo <cang@codeaurora.org>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Some SoCs could require one scatterlist entry for smaller than
page size, i.e. 4KB. For the cases of dispatching commands
with more than one scatterlist entry and under 4KB size,
They could behave as follows:
Given that a command to read something
from device is dispatched with two scatterlist entries that
are named AAA and BBB. After dispatching, host builds two PRDT
entries and during transmission, device sends just one DATA IN
because device doesn't care on host dma. The host then tranfers
the whole data from start address of the area named AAA.
In consequence, the area that follows AAA would be corrupted.
|<------------->|
+-------+------------ +-------+
+ AAA + (corrupted) ... + BBB +
+-------+------------ +-------+
In this case, you need to force an alignment with page size for
sg entries.
Bug: 177399609
Change-Id: I4a930e35efeed233d09ff935431c3db120c13e4d
(cherry picked from commit 2b2bfc8aa5https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 5.12/scsi-staging)
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Set optimized values for those timeouts
- FC0_PROTECTION_TIMER
- TC0_REPLAY_TIMER
- AFC0_REQUEST_TIMER
Exynos doesn't yet use traffic class #1.
Bug: 163478167
Change-Id: I66b489f1676c795548a6a2c9f4be1192fc494490
(cherry picked from commit b1d0d2eb89https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 5.12/scsi-queue)
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Unipro specification says attribute IDs of the following
thing are vendor-specific values, so some SoCs could have
no regions at the defined addresses
- DME_LocalFC0ProtectionTimeOutVal
- DME_LocalTC0ReplayTimeOutVal
- DME_LocalAFC0ReqTimeOutVal
The following things should be set considering the compatibility
between host and device, so those values must not be fixed and
you could use reset values or vendor specific values
- PA_PWRMODEUSERDATA0
- PA_PWRMODEUSERDATA1
- PA_PWRMODEUSERDATA2
- PA_PWRMODEUSERDATA3
- PA_PWRMODEUSERDATA4
- PA_PWRMODEUSERDATA5
Bug: 163478167
Change-Id: Ic56ea3d8182bc27899d17fb45370bd60ce900120
(cherry picked from commit b1d0d2eb89https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 5.12/scsi-queue)
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
As per the kernel doc for usb_ep_dequeue(), it states that "this
routine is asynchronous, that is, it may return before the completion
routine runs". And indeed since v5.0 the dwc3 gadget driver updated
its behavior to place dequeued requests on to a cancelled list to be
given back later after the endpoint is stopped.
The free_ep() was incorrectly assuming that a request was ready to
be freed after calling dequeue which results in a use-after-free
in dwc3 when it traverses its cancelled list. Fix this by moving
the usb_ep_free_request() call to the callback itself in case the
ep is disabled.
Fixes: eb9fecb9e6 ("usb: gadget: f_uac2: split out audio core")
Reported-and-tested-by: Ferry Toth <fntoth@gmail.com>
Reviewed-and-tested-by: Peter Chen <peter.chen@nxp.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20210118084642.322510-2-jbrunet@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7de8681be2https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I475306f99901f1dc0957547ffcdb857cdf6c8b92
If a gadget supports SuperSpeed Plus, then it may operate in different
sublink speeds. For example, if the gadget supports SuperSpeed Plus
gen2x2, then it can support 2 sublink speeds gen1 and gen2. Inform the
host of these speeds in the BOS descriptor.
Use 1 SSID if the gadget supports up to gen2x1, or not specified:
- SSID 0 for symmetric RX/TX sublink speed of 10 Gbps.
Use 1 SSID if the gadget supports up to gen1x2:
- SSID 0 for symmetric RX/TX sublink speed of 5 Gbps.
Use 2 SSIDs if the gadget supports up to gen2x2:
- SSID 0 for symmetric RX/TX sublink speed of 5 Gbps.
- SSID 1 for symmetric RX/TX sublink speed of 10 Gbps.
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/eb0386fdd5d87a858281e8006a72723d3732240f.1610592135.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7bf0fc5a6bhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic6411432f2c612f398df50c79cae0e9094edaa0b
Synchronize QCOM symbol list in android/abi_gki_aarch64_qcom.
Bug: 177965977
Change-Id: Id5d04f7055332a35d99dfaaf4a2cced1c7fc6b72
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
This driver can be used to collected kernel information for the
bootloader.
Bug: 169101608
Change-Id: I372026656de027ff775e7fe24a7d558b89471885
Signed-off-by: Will McVicker <willmcvicker@google.com>
Tiger Lake SOC (the versions of it that have integrated USB4
controller) may have two DWC3 controllers. One is part of
the PCH (Platform Controller Hub, i.e. the chipset) as
usual, and the other is inside the actual CPU block.
On all Intel platforms that have the two separate DWC3
controllers, the one inside the CPU handles USB3 and only
USB3 traffic, while the PCH version handles USB2 and USB2
alone. The reason for splitting the two busses like this is
to allow easy USB3 tunneling over USB4 connections. As USB2
is not tunneled over USB4, it has dedicated USB controllers
(both xHCI and DWC3).
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20210115094914.88401-4-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 73203bde3ahttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I78f511c5304a5bd9a88cf5131944dc05e0609a0e
