ABI: testing: sysfs-class-power: Document absence of "present" property

Document how the absence of the "present" property in the sysfs
power_supply class should be handled.

Link: https://gitlab.fr

ABI: testing: sysfs-class-power: Document absence of "present" property

Document how the absence of the "present" property in the sysfs
power_supply class should be handled.

Link: https://gitlab.freedesktop.org/upower/upower/-/merge_requests/173
Cc: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

docs: ABI: charge_control_end_threshold may not support all values

Some laptops (for example Toshiba Satellite Z830) only supports some fixed
values. Allow for this and document the expected behavio

docs: ABI: charge_control_end_threshold may not support all values

Some laptops (for example Toshiba Satellite Z830) only supports some fixed
values. Allow for this and document the expected behaviour in such cases.

Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Arvid Norlander <lkml@vorpal.se>
Link: https://lore.kernel.org/r/20220902180037.1728546-4-lkml@vorpal.se
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

show more ...

ABI: testing: sysfs-class-power: Adds "Long Life" entry

Adds a brief desciption of the "Long Life" charge type and adds "Long Life"
to the list of valid values.

Signed-off-by: Ricardo Rivera-Matos

ABI: testing: sysfs-class-power: Adds "Long Life" entry

Adds a brief desciption of the "Long Life" charge type and adds "Long Life"
to the list of valid values.

Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: Introduces bypass charging property

Adds a POWER_SUPPLY_CHARGE_TYPE_BYPASS option to the POWER_SUPPLY_PROP_CHARGE_TYPE
property to facilitate bypass charging operation.

In bypass cha

power: supply: Introduces bypass charging property

Adds a POWER_SUPPLY_CHARGE_TYPE_BYPASS option to the POWER_SUPPLY_PROP_CHARGE_TYPE
property to facilitate bypass charging operation.

In bypass charging operation, the charger bypasses the charging path around the
integrated converter allowing for a "smart" wall adaptor to perform the power
conversion externally.

This operational mode is critical for the USB PPS standard of power adaptors and is
becoming a common feature in modern charging ICs such as:

- BQ25980
- BQ25975
- BQ25960
- LN8000
- LN8410

Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: fix table problem in sysfs-class-power

Add a bottom table border to complete the table format and prevent
a documentation build warning.

Documentation/ABI/testing/sysfs-class-power:4

power: supply: fix table problem in sysfs-class-power

Add a bottom table border to complete the table format and prevent
a documentation build warning.

Documentation/ABI/testing/sysfs-class-power:459: WARNING: Malformed table.
No bottom table border found.

Fixes: 1b0b6cc8030d0 ("power: supply: add charge_behaviour attributes")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Thomas Weißschuh <linux@weissschuh.net>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: linux-pm@vger.kernel.org
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: add charge_behaviour attributes

This a revised version of
"[RFC] add standardized attributes for force_discharge and inhibit_charge" [0],
incorporating discussion results.

The bigges

power: supply: add charge_behaviour attributes

This a revised version of
"[RFC] add standardized attributes for force_discharge and inhibit_charge" [0],
incorporating discussion results.

The biggest change is the switch from two boolean attributes to a single
enum attribute.

[0] https://lore.kernel.org/platform-driver-x86/21569a89-8303-8573-05fb-c2fec29983d1@gmail.com/

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20211123232704.25394-2-linux@weissschuh.net
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

show more ...

power: supply: core: add POWER_SUPPLY_HEALTH_NO_BATTERY

Some chargers can keep the system powered from the mains even when no
battery is present. It this case none of the currently defined health
st

power: supply: core: add POWER_SUPPLY_HEALTH_NO_BATTERY

Some chargers can keep the system powered from the mains even when no
battery is present. It this case none of the currently defined health
statuses applies. Add a new status to report that no battery is present.

Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

docs: ABI: sysfs-class-power: Documented cycle_count property

Commit c955fe8e0bdd ("POWER: Add support for cycle_count") added a
POWER_SUPPLY_PROP_CYCLE_COUNT "cycle_count" property to the set of
st

docs: ABI: sysfs-class-power: Documented cycle_count property

Commit c955fe8e0bdd ("POWER: Add support for cycle_count") added a
POWER_SUPPLY_PROP_CYCLE_COUNT "cycle_count" property to the set of
standard power-supply properties, but this was never documented,
document it now.

Link: https://gitlab.freedesktop.org/upower/upower/-/issues/152
Reported-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

docs: ABI: sysfs-class-power: unify duplicated properties

The ABI is not supposed to have duplicated entries, as warned
by get_abi.pl:

$ ./scripts/get_abi.pl validate 2>&1|grep sysfs-class-power

docs: ABI: sysfs-class-power: unify duplicated properties

The ABI is not supposed to have duplicated entries, as warned
by get_abi.pl:

$ ./scripts/get_abi.pl validate 2>&1|grep sysfs-class-power
Warning: /sys/class/power_supply/<supply_name>/current_avg is defined 2 times: Documentation/ABI/testing/sysfs-class-power:108 Documentation/ABI/testing/sysfs-class-power:391
Warning: /sys/class/power_supply/<supply_name>/current_max is defined 2 times: Documentation/ABI/testing/sysfs-class-power:121 Documentation/ABI/testing/sysfs-class-power:404
Warning: /sys/class/power_supply/<supply_name>/current_now is defined 2 times: Documentation/ABI/testing/sysfs-class-power:130 Documentation/ABI/testing/sysfs-class-power:414
Warning: /sys/class/power_supply/<supply_name>/temp is defined 2 times: Documentation/ABI/testing/sysfs-class-power:281 Documentation/ABI/testing/sysfs-class-power:493
Warning: /sys/class/power_supply/<supply_name>/temp_alert_max is defined 2 times: Documentation/ABI/testing/sysfs-class-power:291 Documentation/ABI/testing/sysfs-class-power:505
Warning: /sys/class/power_supply/<supply_name>/temp_alert_min is defined 2 times: Documentation/ABI/testing/sysfs-class-power:306 Documentation/ABI/testing/sysfs-class-power:521
Warning: /sys/class/power_supply/<supply_name>/temp_max is defined 2 times: Documentation/ABI/testing/sysfs-class-power:322 Documentation/ABI/testing/sysfs-class-power:537
Warning: /sys/class/power_supply/<supply_name>/temp_min is defined 2 times: Documentation/ABI/testing/sysfs-class-power:333 Documentation/ABI/testing/sysfs-class-power:547
Warning: /sys/class/power_supply/<supply_name>/voltage_max is defined 2 times: Documentation/ABI/testing/sysfs-class-power:356 Documentation/ABI/testing/sysfs-class-power:571
Warning: /sys/class/power_supply/<supply_name>/voltage_min is defined 2 times: Documentation/ABI/testing/sysfs-class-power:367 Documentation/ABI/testing/sysfs-class-power:581
Warning: /sys/class/power_supply/<supply_name>/voltage_now is defined 2 times: Documentation/ABI/testing/sysfs-class-power:378 Documentation/ABI/testing/sysfs-class-power:591

Yet, both USB and Battery share a common set of charging-related
properties.

Unify the entries for such properties in order to avoid
duplication, while preserving the battery and USB-specific
data properly documented.

Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/bcdf5f76326ea48a990a7cac612af216c387537d.1604042072.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

docs: ABI: cleanup several ABI documents

There are some ABI documents that, while they don't generate
any warnings, they have issues when parsed by get_abi.pl script
on its output result.

Address t

docs: ABI: cleanup several ABI documents

There are some ABI documents that, while they don't generate
any warnings, they have issues when parsed by get_abi.pl script
on its output result.

Address them, in order to provide a clean output.

Reviewed-by: Tom Rix <trix@redhat.com> # for fpga-manager
Reviewed-By: Kajol Jain<kjain@linux.ibm.com> # for sysfs-bus-event_source-devices-hv_gpci and sysfs-bus-event_source-devices-hv_24x7
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> #for IIO
Acked-by: Oded Gabbay <oded.gabbay@gmail.com> # for Habanalabs
Acked-by: Vaibhav Jain <vaibhav@linux.ibm.com> # for sysfs-bus-papr-pmem
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com> # for catpt
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Ilya Dryomov <idryomov@gmail.com> # for rbd
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/5bc78e5b68ed1e9e39135173857cb2e753be868f.1604042072.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

docs: ABI: testing: make the files compatible with ReST output

Some files over there won't parse well by Sphinx.

Fix them.

Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for IIO
Acked-

docs: ABI: testing: make the files compatible with ReST output

Some files over there won't parse well by Sphinx.

Fix them.

Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for IIO
Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/58cf3c2d611e0197fb215652719ebd82ca2658db.1604042072.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

power: supply: document current direction

Currently the sign for CURRENT_NOW and CURRENT_AVG is a bit
of a mess. There are basically 3 different ways battery fuel
gauges report the current:

1. uses

power: supply: document current direction

Currently the sign for CURRENT_NOW and CURRENT_AVG is a bit
of a mess. There are basically 3 different ways battery fuel
gauges report the current:

1. uses negative values for discharging and positive values
for charging
2. uses positive values for discharging and negative values
for discharging (opposit of 1)
3. only uses positive values

As a result userspace currently cannot use the sign at all in
a generic way. Let's solve the issue by documenting a canonical
way for reporting the data and ensure new drivers follow this
way. Then existing drivers can be fixed on a case-by-case basis.

The 'negative value = battery discharging' has been choosen,
since there are only very few drivers doing it the other way
around.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: add wireless type

Currently, power_supply framework supports only Battery, UPS,
Mains and USB power_supply_type. Add wireless power_supply_type
so that the drivers which supports wire

power: supply: add wireless type

Currently, power_supply framework supports only Battery, UPS,
Mains and USB power_supply_type. Add wireless power_supply_type
so that the drivers which supports wireless can register a power
supply class device with POWER_SUPPLY_TYPE_WIRELESS.

Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power_supply: Add additional health properties to the header

Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum.

HEALTH_WARM, HEALTH_COOL, and HEALTH_HOT properties are taken
from JEITA

power_supply: Add additional health properties to the header

Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum.

HEALTH_WARM, HEALTH_COOL, and HEALTH_HOT properties are taken
from JEITA specification JISC8712:2015

Acked-by: Andrew F. Davis <afd@ti.com>
Tested-by: Guru Das Srinagesh <gurus@codeaurora.org>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: core: add POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED

Some battery fuel gauges know when the battery needs to
be recalibrated before providing usable values. This
should be reported via

power: supply: core: add POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED

Some battery fuel gauges know when the battery needs to
be recalibrated before providing usable values. This
should be reported via the health property.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: core: add manufacture date properties

Some smart batteries store their manufacture date, which is
useful to identify the battery and/or to know about the cell
quality.

Signed-off-by:

power: supply: core: add manufacture date properties

Some smart batteries store their manufacture date, which is
useful to identify the battery and/or to know about the cell
quality.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: core: add capacity error margin property

Add a property for reporting the error margin expected
by fuel gauge chips.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

power: supply: core: Update sysfs-class-power ABI document

Add the "Over Current" string to /sys/class/power_supply/<supply_name>/health
description.

Fixes: e3e83cc601e57 ("power: supply: core: Add

power: supply: core: Update sysfs-class-power ABI document

Add the "Over Current" string to /sys/class/power_supply/<supply_name>/health
description.

Fixes: e3e83cc601e57 ("power: supply: core: Add POWER_SUPPLY_HEALTH_OVERCURRENT constant")
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: add input power and voltage limit properties

For thermal management strategy you might be interested on limit the
input power for a power supply. We already have current limit but
bas

power: supply: add input power and voltage limit properties

For thermal management strategy you might be interested on limit the
input power for a power supply. We already have current limit but
basically what we probably want is to limit power. So, introduce the
input_power_limit property.

Although the common use case is limit the input power, in some
specific cases it is the voltage that is problematic (i.e some regulators
have different efficiencies at higher voltage resulting in more heat).
So introduce also the input_voltage_limit property.

This happens in one Chromebook and is used on the Pixel C's thermal
management strategy to effectively limit the input power to 5V 3A when
the screen is on. When the screen is on, the display, the CPU, and the GPU
all contribute more heat to the system than while the screen is off, and
we made a tradeoff to throttle the charger in order to give more of the
thermal budget to those other components.

So there's nothing fundamentally broken about the hardware that would
cause the Pixel C to malfunction if we were charging at 9V or 12V instead
of 5V when the screen is on, i.e. if userspace doesn't change this.

What would happen is that you wouldn't meet Google's skin temperature
targets on the system if the charger was allowed to run at 9V or 12V with
the screen on.

For folks hacking on Pixel Cs (which is now outside of Google's official
support window for Android) and customizing their own kernel and userspace
this would be acceptable, but we wanted to expose this feature in the
power supply properties because the feature does exist in the Emedded
Controller firmware of the Pixel C and all of Google's Chromebooks with
USB-C made since 2015 in case someone running an up to date kernel wanted
to limit the charging power for thermal or other reasons.

This patch exposes a new property, similar to input current limit, to
re-configure the maximum voltage from the external supply at runtime
based on system-level knowledge or user input.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: core: Add missing documentation for CHARGE_CONTROL_* properties

The existing POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT and
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX properties
don't hav

power: supply: core: Add missing documentation for CHARGE_CONTROL_* properties

The existing POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT and
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX properties
don't have documentation. I add that documentation here.

v5 changes:
- Split this commit out from the previous two commits.

Signed-off-by: Nick Crews <ncrews@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: core: Add CHARGE_CONTROL_{START_THRESHOLD,END_THRESHOLD} properties

Add POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD
and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties,

power: supply: core: Add CHARGE_CONTROL_{START_THRESHOLD,END_THRESHOLD} properties

Add POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD
and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties, to expand
the existing CHARGE_CONTROL_* properties. I am adding them in order
to support a new Chrome OS device, but these properties should be
general enough that they can be used on other devices.

When the charge_type is "Custom", the charge controller uses the
POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some
other algorithm. For example, in the use case that I am supporting,
this means the battery begins charging when the percentage
level drops below POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
charging ceases when the percentage level goes above
POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD.

v5 changes:
- Add the other missing CHARGE_CONTROL_* properties documentation in
a separate commit
- Split up adding the charge types and adding the
POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into
two different commits.
v4 changes:
- Add documentation for the new properties, and add documentation for
the the previously missing charge_control_limit and
charge_control_limit_max properties.

Signed-off-by: Nick Crews <ncrews@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: core: Add Standard, Adaptive, and Custom charge types

Add "Standard", "Adaptive", and "Custom" modes to the charge_type
property, to expand the existing "Trickle" and "Fast" modes.
I

power: supply: core: Add Standard, Adaptive, and Custom charge types

Add "Standard", "Adaptive", and "Custom" modes to the charge_type
property, to expand the existing "Trickle" and "Fast" modes.
I am adding them in order to support a new Chrome OS device,
but these properties should be general enough that they can be
used on other devices.

The meaning of "Standard" is obvious, but "Adaptive" and "Custom" are
more tricky: "Adaptive" means that the charge controller uses some
custom algorithm to change the charge type automatically, with no
configuration needed. "Custom" means that the charge controller uses the
POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some
other algorithm.

v5 changes:
- Split up adding the charge types and adding the
POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into
two different commits.
v4 changes:
- Add documentation for the new properties, and add documentation for
the the previously missing charge_control_limit and
charge_control_limit_max properties.

Signed-off-by: Nick Crews <ncrews@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

show more ...

power: supply: Add 'usb_type' property and supporting code

This commit adds the 'usb_type' property to represent USB supplies
which can report a number of different types based on a connection
event

power: supply: Add 'usb_type' property and supporting code

This commit adds the 'usb_type' property to represent USB supplies
which can report a number of different types based on a connection
event.

Examples of this already exist in drivers whereby the existing 'type'
property is updated, based on an event, to represent what was
connected (e.g. USB, USB_DCP, USB_ACA, ...). Current implementations
however don't show all supported connectable types, so this knowledge
has to be exlicitly known for each driver that supports this.

The 'usb_type' property is intended to fill this void and show users
all possible USB types supported by a driver. The property, when read,
shows all available types for the driver, and the one currently chosen
is highlighted/bracketed. It is expected that the 'type' property
would then just show the top-level type 'USB', and this would be
static.

Currently the 'usb_type' enum contains all of the USB variant types
that exist for the 'type' enum at this time, and in addition has
SDP and PPS types. The mirroring is intentional so as to not impact
existing usage of the 'type' property.

Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

Documentation: power: Initial effort to document power_supply ABI

This commit adds generic ABI information regarding power_supply
properties. This is an initial attempt to try and align the usage
of

Documentation: power: Initial effort to document power_supply ABI

This commit adds generic ABI information regarding power_supply
properties. This is an initial attempt to try and align the usage
of these properties between drivers. As part of this commit,
common Battery and USB related properties have been listed.

Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

power: supply: Change Krzysztof Kozlowski's email to kernel.org

Change my email address to kernel.org instead of Samsung one for the
purpose of any future contact. The copyrights remain untouched an

power: supply: Change Krzysztof Kozlowski's email to kernel.org

Change my email address to kernel.org instead of Samsung one for the
purpose of any future contact. The copyrights remain untouched and are
attributed to Samsung.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>

show more ...