param offset and size were switched in the function signature
Change-Id: Ice7b9b6c2651940648a95bdf8fa331b62c577378
Signed-off-by: Yu SI <ysi@codeaurora.org>
A target may contain multiple defconfigs, but only one device-tree
configuration. Such a target may have device-drivers that are
only enabled in a particular defconfig, while disabled in the
others. For the kernel that boots up with disabled configuration,
since the device-tree node exists, the of_devlink logic expects
the driver to be probed, which is not possible. As a result, the
sync-state remains incomplete.
Hence, add support for a proxy consumer driver that shows a
proxy-presence of the main driver to satisfy the sync-state.
Change-Id: Ica8c2599fb66420c67e6a72e9b35e7afc0ae3220
Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
If we query the OPP table when it doesn't exist we get an error. If
we populate it again with the same operating points we get an error.
So just skip the table create if it already exists and go with
whatever we have.
Change-Id: Ic0dedbad3d5bd24b35867a82873a6ece555d8314
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Make the fallback path for claiming platform devices trigger only if a
new module parameter is specified:
serdev_ttyport.pdev_tty_port=ttyS2
Bug: 146517987
Change-Id: Ibf331ad6e6d8712a405921530f217f7122428b13
Signed-off-by: Alistair Delva <adelva@google.com>
Git-commit: 3a97aabe4f
Git-repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Akash Asthana <akashast@codeaurora.org>
This change adds the missing set_mode callback for RUMI UFS PHY driver.
Change-Id: Ib67ebf63690a1d01172d4e9c9a0c253a8595f5fb
Signed-off-by: Can Guo <cang@codeaurora.org>
Add IPC verbose log to print OOB and DB mode event and
the door bell ring status. Include the DB ring status
in data channel queue API. Add OOB/DB mode counter.
This helps to identify how long MHI host took to ring
the doorbell and how many times these events are getting
triggered. Reset mode_change count in debugfs show API
in order to track this for a given use case.
Change-Id: I2215554bff6d66098a8c7d01f587c1d726443181
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
After getting OOB driver checks for transfer ring empty
condition and rings the channel ring doorbell without
making sure if there are minimum 8 TREs queued for
GSI to perform DMA. Otherwise there is a possibility of
Host ringing doorbell after OOB with same write pointer
which was already processed in polling mode.
Change-Id: Idda28aadbd1af9b5857db71d98237ef4761427bd
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Remove unused firmware loader worker thread as MHI has moved
on to using pre-existing worker thread in order to serialize
the process.
Change-Id: I71349c97680ec1c0bf17e8f37ef8b046487a2b19
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
In some cases, the special purpose event scheduler may not run
if the interrupt comes close to mission mode entry point and if
no suspend/resume activity follows. Do a check to see if any
pending events need to be processed.
Change-Id: Ic3bf22562f250ec4bb46c14f58617c3b0d5de883
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Some device requested special purpose events can take a long
time to get processed on host. Fix that by moving to dedicated
worker thread.
Change-Id: Ibfe7c56b85cb58b9ee67e41ea1139702d475ffee
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Upon power up driver queues firmware worker thread if ee is in PBL.
Firmware worker is blocked with a timeout until state worker gets a
chance to run and unblock firmware worker. In case state worker gets a
chance to run after firmware worker timed out results into endpoint
boot up failure. Fix this issue by directly handling firmware loading
from state worker thread.
Change-Id: Id28c5a3eaa3b8075a7eb0185f7e08f21174e1d0d
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
USB 3.x SuperSpeed peripherals can draw up to 900mA of VBUS power
when in configured state. However, if a configuration wanting to
take advantage of this is added with MaxPower greater than 500
(currently possible if using a ConfigFS gadget) the composite
driver fails to accommodate this for a couple reasons:
- usb_gadget_vbus_draw() when called from set_config() and
composite_resume() will be passed the MaxPower value without
regard for the current connection speed, resulting in a
violation for USB 2.0 since the max is 500mA.
- the bMaxPower of the configuration descriptor would be
incorrectly encoded, again if the connection speed is only
at USB 2.0 or below, likely wrapping around U8_MAX since
the 2mA multiplier corresponds to a maximum of 510mA.
Fix these by adding checks against the current gadget->speed
when the c->MaxPower value is used (set_config() and
composite_resume()) and appropriately limit based on whether
it is currently at a low-/full-/high- or super-speed connection.
Because 900 is not divisible by 8, with the round-up division
currently used in encode_bMaxPower() a MaxPower of 900mA will
result in an encoded value of 0x71. When a host stack (including
Linux and Windows) enumerates this on a single port root hub, it
reads this value back and decodes (multiplies by 8) to get 904mA
which is strictly greater than 900mA that is typically budgeted
for that port, causing it to reject the configuration. Instead,
we should be using the round-down behavior of normal integral
division so that 900 / 8 -> 0x70 or 896mA to stay within range.
And we might as well change it for the high/full/low case as well
for consistency.
N.B. USB 3.2 Gen N x 2 allows for up to 1500mA but there doesn't
seem to be any any peripheral controller supported by Linux that
does two lane operation, so for now keeping the clamp at 900
should be fine.
Change-Id: I37032c83be6403004ee8d107cb8d7cae04fa0ffa
Signed-off-by: Jack Pham <jackp@codeaurora.org>
commit af34613293 ("usb: dwc3-msm: Get usb power_supply from
device tree") changed the power_supply_get_by_name() to
get_by_phandle(), however this does not work if the device
pointed to by the phandle registers multiple power_supply
objects (including battery & wireless as is the case for
QTI PMICs) as we are not guaranteed to get back the USB psy.
Hence revert back to using power_supply_get_by_name() for
the named "usb" psy. We can keep using the "qcom,usb-charger"
DT property but just treat it as boolean instead so that we
can support USB controllers that may not be tied to a charger.
Change-Id: Ic7e4c58b096b0d6210cd55f1ff6edf21ffc5b4b1
Signed-off-by: Jack Pham <jackp@codeaurora.org>
