The V4L2 flash interface allows controlling multiple LEDs through a single
sub-devices if, and only if, these LEDs are of different types. This
approach scales badly for flash controllers that drive multiple flash LEDs
or for LED specific associations. Essentially, the original assumption of a
LED
On Mon, Aug 14, 2017 at 04:09:34PM +0100, James Simmons wrote:
>
> > Hello Nathaniel Clark,
> >
> > The patch 476f575cf070: "staging: lustre: lov: Ensure correct
> > operation for large object sizes" from Jul 26, 2017, leads to the
> > following static checker warning:
> >
> > drivers/stagin
The V4L2 flash interface allows controlling multiple LEDs through a single
sub-devices if, and only if, these LEDs are of different types. This
approach scales badly for flash controllers that drive multiple flash LEDs
or for LED specific associations. Essentially, the original assumption of a
LED
Hi All,
This series implements a number of typec changes discussed a while back:
- It exports the negotiated voltage and max-current in the form of a
power-supply class device which represents the USB Type-C power-brick
(adapter/charger)
- It adds a power_supply_set_input_current_limit_from_s
For devices not instantiated through ACPI the i2c-client's device-name
gets set to - by default, e.g. "0-0022" this means that
the device-name is dependent on the order in which the i2c-busses are
enumerated.
In some cases having a predictable constant device-name is desirable,
for example on non
Anything higher then 5V may damage hardware not capable of it, so
the only sane default here is 5V. If a board is able to handle a
higher voltage that should come from board specific data such as
device-tree and not be hard coded into the fusb302 code.
Cc: "Yueyao (Nathan) Zhu"
Signed-off-by: Han
A Rp signalling the default current limit indicates that we're possibly
connected to an USB2 power-source. In some cases the type-c port-controller
may provide the capability to detect the current-limit in this case,
through e.g. BC1.2 detection.
This commit adds an optional get_current_limit tcpc
The fusb302 port-controller relies on an external device doing USB2
charger-type detection.
The Intel Whiskey Cove PMIC with which the fusb302 is combined on some
X86/ACPI platforms already has a charger-type detection driver which
uses extcon to communicate the detected charger-type.
This commit
This is board specific info so it should come from board config, such
as devicetree.
I've chosen to prefix these with "fcs," treating them as fusb302 driver
specific for now. We may want to revisit this and replace these with
properties which are part of a (to be written) generic type-c controller
The fusb302 is also used on x86 systems where the platform code sets
the irq in client->irq and there is no gpio named fcs,int_n.
Cc: "Yueyao (Nathan) Zhu"
Signed-off-by: Hans de Goede
---
drivers/staging/typec/fusb302/fusb302.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
On some devices the USB Type-C port power (USB PD 2.0) negotiation is
done by a separate port-controller IC, while the current limit is
controlled through another (charger) IC.
It has been decided to model this by modelling the external Type-C
power brick (adapter/charger) as a power-supply class
The fusb302 Type-C port-controller cannot control the current-limit
directly, so we need to exported the limit so that another driver
(e.g. the charger driver) can pick the limit up and configure the
system accordingly.
The power-supply subsys already provides infrastructure for this,
power-supply
Register the 5V boost converter as a regulator named "usb_otg_vbus".
This commit also adds support for bq24190_platform_data, through which
non device-tree platforms can pass the regulator_init_data (containing
mappings for the consumer amongst other things).
Signed-off-by: Hans de Goede
---
Cha
On some devices the USB Type-C port power (USB PD 2.0) negotiation is
done by a separate port-controller IC, while the current limit is
controlled through another (charger) IC.
It has been decided to model this by modelling the external Type-C
power brick (adapter/charger) as a power-supply class
Now that drivers/i2c/busses/i2c-cht-wc.c uses
"input-current-limit-from-supplier" instead of "extcon-name" the last
user of the bq24190 extcon code is gone, remove it.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Move the comment with the example code for passing properties on i2c_client
ins
The fusb302 driver as merged in staging uses "typec_fusb302" as i2c-id
rather then just "fusb302" and needs us to set a number of device-
properties, adjust the intel_cht_int33fe driver accordingly.
One of the properties set is max-snk-mv which makes the fusb302 driver
negotiate up to 12V charging
Add device-properties to make the bq24292i charger connected to
the bus get its input-current-limit from the fusb302 Type-C port
controller which is used on boards with the cht-wc PMIC,
as well as regulator_init_data for the 5V boost converter on
the bq24292i.
Since this means we now hook-up the b
Export the input current limit of the charger as a
POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT property on the charger
power_supply class device.
Signed-off-by: Hans de Goede
---
drivers/power/supply/bq24190_charger.c | 35 ++
1 file changed, 35 insertions(+)
diff --gi
Without the patch, vmw_vsock_vmci_transport.ko and vmw_vmci.ko can
automatically load when an application creates an AF_VSOCK socket.
This is the expected good behavior on VMware hypervisor, but as we
are going to add hv_sock.ko (i.e. Hyper-V transport for AF_VSOCK), we
should make sure vmw_vsock
With the current code, when vsock_dequeue_accept() is removing a sock
from the list, nothing prevents vsock_enqueue_accept() from adding a new
sock into the list concurrently. We should add a lock to protect the list.
Signed-off-by: Dexuan Cui
Cc: Andy King
Cc: Dmitry Torokhov
Cc: George Zhang
Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechanism between the host and the guest. It uses VMBus ringbuffer as the
transportation layer.
PATCH 01 and 02 are for VMCI and the common infrastructure vsock.
PATCH 03 implements the necessary support in Linux guest by intro
Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechanism between the host and the guest. It uses VMBus ringbuffer as the
transportation layer.
With hv_sock, applications between the host (Windows 10, Windows Server
2016 or newer) and the guest can talk with each other using
binder_alloc_selftest tests that alloc_new_buf handles page allocation and
deallocation properly when allocate and free buffers. The test allocates 5
buffers of various sizes to cover all possible page alignment cases, and
frees the buffers using a list of exhaustive freeing order.
Test: boot the
Hold on to the pages allocated and mapped for transaction
buffers until the system is under memory pressure. When
that happens, use linux shrinker to free pages. Without
using shrinker, patch "android: binder: Move buffer out
of area shared with user space" will cause a significant
slow down for sm
Add tracepoints in binder transaction allocator to
record lru hits and alloc/free page.
Change-Id: I7715f943c57d6172c35bdff8298d8c5aef24a51a
Signed-off-by: Sherry Yang
---
drivers/android/binder_alloc.c | 27 +++--
drivers/android/binder_trace.h | 55 +
Binder driver allocates buffer meta data in a region that is mapped
in user space. These meta data contain pointers in the kernel.
This patch allocates buffer meta data on the kernel heap that is
not mapped in user space, and uses a pointer to refer to the data mapped.
Change-Id: Ie19d2393a5015d9
Change-Id: Ie2a446ad9907f0d306fd1b8e6d79d87e48826ce2
Signed-off-by: Sherry Yang
---
drivers/android/binder_alloc.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
index 40f31df60580..f15a
On 08/15/2017 04:22 PM, Badhri Jagan Sridharan wrote:
At present, TCPM does not take into account the actual resistor
value presented in the CC line and therefore reports TYPEC_PWR_MODE_USB
irrespective of the power_op_mode it is in.
This patch makes TCPM consider the actual value of Rp.
Signed-
On 08/15/2017 04:23 PM, Badhri Jagan Sridharan wrote:
While in SNK_READY state, the explicit_contract seems to be
set to true irrespective of whether an explicit contract
was established for the current connection. TCPM also seems
to report the pwr_opmode as TYPEC_PWR_MODE_PD always once
the port
hv_sock driver is automatically loaded when an application creates an
AF_VSOCK socket, so we don't really need to trigger uevents to the user
space udevd.
And hv_sock devices can appear and disappear frequency, e.g. 100 per
second, so triggering the udevents can cause a high cpu utilization of
ud
Due to commit 54a66265d675 ("Drivers: hv: vmbus: Fix rescind handling"),
we need this patch to resolve the below deadlock:
after we get the mutex in vmbus_hvsock_device_unregister() and call
vmbus_device_unregister() -> device_unregister() -> ... -> device_release()
-> vmbus_device_release(), we'
31 matches
Mail list logo
