This is a preparation patch for adding more helpers.
Signed-off-by: Hans de Goede
---
drivers/staging/typec/Makefile| 2 +
drivers/staging/typec/{tcpm.c => tcpm-core.c} | 40 --
drivers/staging/typec/tcpm-helpers.c | 60 +++
3 fil
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. We may want to revisit to replace these with properties which
are part of a (to be written) generic type-c controller devicetree
bi
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.
Signed-off-by: Hans de Goede
---
drivers/staging/typec/fusb302/fusb302.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/stagin
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
for USB2 power-sources (through e.g. BC1.2 detection).
This commit adds an optional get_usb2_cu
Register a power_supply and use tcpm_set_current_limit_psy as
set_current_limit so that another driver (e.g. the charger driver) can
pick the limit up and configure the system accordingly.
Signed-off-by: Hans de Goede
---
drivers/staging/typec/fusb302/fusb302.c | 18 ++
1 file ch
Commit 2848e039c562 ("power: supply: Make power_supply_am_i_supplied return
-ENODEV if there are no suppliers") was supposed to make
power_supply_am_i_supplied() return -ENODEV when there are no supplies
which supply the supply passed to it.
But instead it will only return -ENODEV when there are n
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
Some type-c port-controllers, such as the fusb302 port-controller, rely
on an external device doing USB2 charger-type detection.
Existing PMIC (and charger) drivers already use extcon to communicate the
detected charger-type from the PMIC (extcon) driver to the charger driver.
Rather then inventi
On devicetree platforms the fusb302 dt-node will have a vbus regulator
property with a phandle to the regulator.
On ACPI platforms, there are no phandles and we need to get the vbus by a
system wide unique name. Add support for a new "fcs,vbus-regulator-name"
device-property which ACPI platform co
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
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
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
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.
Signed-off-by: Hans de Goede
---
drivers/st
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
Not all type-c port-controller can control the current-limit directly,
in cases where the current limit can not be controlled directly it needs
to be exported so that another driver (e.g. the charger driver) can pick
the limit up and configure the system accordingly.
The power-supply subsys alread
Add device-properties to make the bq24292i controller 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.
Signed-off-by: Hans de Goede
---
drivers/i2c/busses/Kconfig | 5 +
drivers/i2c/busses/i2c-cht-wc.c
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
---
drivers/power/supply/bq24190_charger.c | 107 -
1 file changed,
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
Register the 5V boost converter as a regulator named
"regulator-bq24190-usb-vbus". Note the name includes "bq24190" because
the bq24190 family is also used on ACPI devices where there are no
device-tree phandles, so regulator_get will fallback to the name and thus
it must be unique on the system.
On driver cleanup we need to call fb_deferred_io_cleanup() if build
with CONFIG_FB_DEFERRED_IO set.
Suggested-by: Michael Thayer
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_fb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/vboxvideo/vbox_fb.c
b/d
On 08/06/2017 05:35 AM, Hans de Goede wrote:
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. We may want to revisit to replace these with properties which
are part of a (to be w
On 08/06/2017 05:35 AM, Hans de Goede wrote:
Some type-c port-controllers, such as the fusb302 port-controller, rely
on an external device doing USB2 charger-type detection.
Existing PMIC (and charger) drivers already use extcon to communicate the
detected charger-type from the PMIC (extcon) dri
On 08/06/2017 05:35 AM, Hans de Goede wrote:
Not all type-c port-controller can control the current-limit directly,
in cases where the current limit can not be controlled directly it needs
to be exported so that another driver (e.g. the charger driver) can pick
the limit up and configure the syst
On 08/06/2017 05:35 AM, Hans de Goede wrote:
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
for USB2 power-sources (through e.g. BC1.2 detect
Hi,
On 06-08-17 16:13, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
Not all type-c port-controller can control the current-limit directly,
in cases where the current limit can not be controlled directly it needs
to be exported so that another driver (e.g. the charger driver
On 08/06/2017 05:35 AM, Hans de Goede wrote:
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 comm
On 08/06/2017 05:35 AM, Hans de Goede wrote:
Register a power_supply and use tcpm_set_current_limit_psy as
set_current_limit so that another driver (e.g. the charger driver) can
pick the limit up and configure the system accordingly.
Signed-off-by: Hans de Goede
---
drivers/staging/typec/fusb
Hi,
On 06-08-17 16:18, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
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
for
On 08/06/2017 05:35 AM, Hans de Goede wrote:
On devicetree platforms the fusb302 dt-node will have a vbus regulator
property with a phandle to the regulator.
On ACPI platforms, there are no phandles and we need to get the vbus by a
system wide unique name. Add support for a new "fcs,vbus-regulat
On 08/06/2017 05:35 AM, Hans de Goede wrote:
Commit 2848e039c562 ("power: supply: Make power_supply_am_i_supplied return
-ENODEV if there are no suppliers") was supposed to make
power_supply_am_i_supplied() return -ENODEV when there are no supplies
which supply the supply passed to it.
But inste
On 08/06/2017 05:35 AM, Hans de Goede wrote:
Add device-properties to make the bq24292i controller 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.
Signed-off-by: Hans de Goede
---
drivers/i2c/busses/Kconfig
Hi,
On 06-08-17 16:22, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
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-t
On 08/06/2017 07:21 AM, Hans de Goede wrote:
Hi,
On 06-08-17 16:13, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
Not all type-c port-controller can control the current-limit directly,
in cases where the current limit can not be controlled directly it needs
to be exported s
On 08/06/2017 07:29 AM, Hans de Goede wrote:
Hi,
On 06-08-17 16:18, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
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
Hi,
On 06-08-17 16:30, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
On devicetree platforms the fusb302 dt-node will have a vbus regulator
property with a phandle to the regulator.
On ACPI platforms, there are no phandles and we need to get the vbus by a
system wide unique
Hi,
On 06-08-17 16:31, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
Commit 2848e039c562 ("power: supply: Make power_supply_am_i_supplied return
-ENODEV if there are no suppliers") was supposed to make
power_supply_am_i_supplied() return -ENODEV when there are no supplies
wh
On 08/06/2017 07:36 AM, Hans de Goede wrote:
Hi,
On 06-08-17 16:22, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
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 s
Hi,
On 06-08-17 16:35, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
Add device-properties to make the bq24292i controller 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.
Signed-off-by: H
On 08/06/2017 07:52 AM, Hans de Goede wrote:
Hi,
On 06-08-17 16:30, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
On devicetree platforms the fusb302 dt-node will have a vbus regulator
property with a phandle to the regulator.
On ACPI platforms, there are no phandles and w
Hi,
On 06-08-17 16:30, Guenter Roeck wrote:
On 08/06/2017 05:35 AM, Hans de Goede wrote:
On devicetree platforms the fusb302 dt-node will have a vbus regulator
property with a phandle to the regulator.
On ACPI platforms, there are no phandles and we need to get the vbus by a
system wide uni
On Sun, Aug 6, 2017 at 6:05 PM, Hans de Goede wrote:
> On 06-08-17 16:35, Guenter Roeck wrote:
>> On 08/06/2017 05:35 AM, Hans de Goede wrote:
> FWIW all DSTDs I've seen are all copy and paste and all declare a INT33FE
> ACPI
> device with identical i2c client addresses which strongly suggests th
Fixes userspace compilation errors:
error: unknown type name ‘pid_t’
pid_t sender_pid
error: unknown type name ‘uid_t’
uid_t sender_euid;
Signed-off-by: Mikko Rapeli
Cc: Greg Kroah-Hartman
Cc: Arve Hjønnevåg
Cc: Riley Andrews
Cc: Todd Kjos
Cc: Martijn Coenen
Cc: de...@driverdev.osuosl
From: K. Y. Srinivasan
Miscellaneous fixes.
Alex Ng (5):
Tools: hv: vss: Skip freezing filesystems backed by loop
Drivers: hv: balloon: Correctly update onlined page count
Drivers: hv: balloon: Show the max dynamic memory assigned
Drivers: hv: balloon: Initialize last_post_time on startu
From: Alex Ng
Previously, num_pages_onlined was updated using value from memory online
notifier. This is incorrect because they assume that all hot-added pages
are online, even though we only online the amount that's backed by the
host. We should update num_pages_onlined only when the balloon dri
From: Alex Ng
There's a bug which passes the output buffer size as MAX_IP_ADDR_SIZE,
when converting the adapter_id field to UTF16. This is much larger than
the actual size (MAX_ADAPTER_ID_SIZE). Fix this by passing the proper
size.
Fortunately, the translation is limited by the length of the in
From: Alex Ng
Since a loop device is backed by a file, a backup will already result in
its parent filesystem being frozen. It's sufficient to just freeze the
parent filesystem, so we can skip the loop device.
This avoids a situation where a loop device and its parent filesystem are
both frozen a
From: Alex Ng
Previously we were only showing max number of pages. We should make it
more clear that this value is the max amount of dynamic memory that the
Hyper-V host is willing to assign to this guest.
Signed-off-by: Alex Ng
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_balloon.c |
From: Alex Ng
When left uninitialized, this sometimes fails the following check in
post_status():
if (!time_after(now, (last_post_time + HZ))) {
return;
}
This causes unnecessary delays in reporting memory pressure to host after
booting up.
Signed-off-by: Alex N
On 2017/8/4 23:29, Boris Brezillon wrote:
We are planning to share more code between different NAND based
devices (SPI NAND, OneNAND and raw NANDs), but before doing that
we need to move the existing include/linux/mtd/nand.h file into
include/linux/mtd/rawnand.h so we can later create a nand.h
From: Stephen Hemminger
Date: Thu, 3 Aug 2017 17:13:54 -0700
> The existing sub channel code did not wait for all the sub-channels
> to completely initialize. This could lead to race causing crash
> in napi_netif_del() from bad list. The existing code would send
> an init message, then wait only
From: Stephen Hemminger
Date: Fri, 4 Aug 2017 12:14:00 -0700
> With new transparent VF support, it is possible to get a deadlock
> when some of the deferred work is running and the unregister_vf
> is trying to cancel the work element. The solution is to use
> trylock and reschedule (similar to b
51 matches
Mail list logo
