From: Vitaly Kuznetsov Sent: Tuesday, April 20, 2021 2:32
AM
>
> Michael Kelley writes:
>
> > When running in Azure, disks may be connected to a Linux VM with
> > read/write caching enabled. If a VM panics and issues a VMbus
> > UNLOAD request to Hyper-V, the response is delayed until all
On Tue, Apr 20, 2021 at 11:31:54AM +0200, Vitaly Kuznetsov wrote:
> Michael Kelley writes:
>
> > When running in Azure, disks may be connected to a Linux VM with
> > read/write caching enabled. If a VM panics and issues a VMbus
> > UNLOAD request to Hyper-V, the response is delayed until all
Michael Kelley writes:
> When running in Azure, disks may be connected to a Linux VM with
> read/write caching enabled. If a VM panics and issues a VMbus
> UNLOAD request to Hyper-V, the response is delayed until all dirty
> data in the disk cache is flushed. In extreme cases, this flushing
>
Add support for the SMBus-Alert protocol to the STM32F7 that has
dedicated control and status logic.
If SMBus-Alert is used, the SMBALERT# pin must be configured as alternate
function for I2C Alert.
Signed-off-by: Alain Volmat
Reviewed-by: Pierre-Yves MORDRET
---
v2: - rely on st,smbus-alert
Based on the SMBus specification, SMBus Alert active state is low.
As often on SoC, the SMBus Alert pin is not only dedicated to this
feature and can also be used for another purpose (by configuring it
as alternate function for other functions via pinctrl).
"smbus" dt-binding has been
This serie adds support for SMBus Alert on the STM32F7.
A new binding st,smbus-alert is added in order to differenciate
with the existing smbus binding.
SMBA alert control and status logic must be enabled along with
SMBALERT# pin configured via pinctrl in the device tree. This is the
rational
On Thu, Mar 18, 2021 at 02:44:48PM +0100, Alain Volmat wrote:
> Based on the SMBus specification, SMBus Alert active state is low.
> As often on SoC, the SMBus Alert pin is not only dedicated to this
> feature and can also be used for another purpose (by configuring it
> as altern
Hi All
On 3/18/21 2:44 PM, Alain Volmat wrote:
> Add support for the SMBus-Alert protocol to the STM32F7 that has
> dedicated control and status logic.
>
> If SMBus-Alert is used, the SMBALERT# pin must be configured as alternate
> function for I2C Alert.
>
> Signed
This serie adds support for SMBus Alert on the STM32F7.
A new binding st,smbus-alert is added in order to differenciate
with the existing smbus binding.
SMBA alert control and status logic must be enabled along with
SMBALERT# pin configured via pinctrl in the device tree. This is the
rational
Add support for the SMBus-Alert protocol to the STM32F7 that has
dedicated control and status logic.
If SMBus-Alert is used, the SMBALERT# pin must be configured as alternate
function for I2C Alert.
Signed-off-by: Alain Volmat
---
v2: - rely on st,smbus-alert binding instead of smbus
Based on the SMBus specification, SMBus Alert active state is low.
As often on SoC, the SMBus Alert pin is not only dedicated to this
feature and can also be used for another purpose (by configuring it
as alternate function for other functions via pinctrl).
"smbus" dt-binding has been
From: Vitaly Kuznetsov Sent: Tuesday, March 2, 2021 4:57
AM
>
> Michael Kelley writes:
>
> > The Hyper-V page allocator functions are implemented in an architecture
> > neutral way. Move them into the architecture neutral VMbus module so
> > a separate implementation for ARM64 is not needed.
Michael Kelley writes:
> The Hyper-V page allocator functions are implemented in an architecture
> neutral way. Move them into the architecture neutral VMbus module so
> a separate implementation for ARM64 is not needed.
>
> No functional change.
>
> Signed-off-by: Michael Kelley
>
We have been trying to reach you as regards the estate of Late George Brumley,
you were made one of the beneficiaries of his estate. Do get back to me at your
earliest convenience. The Trustees
From: Qu Wenruo
commit 1465af12e254a68706e110846f59cf0f09683184 upstream.
Commit 259ee7754b67 ("btrfs: tree-checker: Add ROOT_ITEM check")
introduced btrfs root item size check, however btrfs root item has two
versions, the legacy one which just ends before generation_v2 member, is
smaller than
From: Qu Wenruo
commit 1465af12e254a68706e110846f59cf0f09683184 upstream.
Commit 259ee7754b67 ("btrfs: tree-checker: Add ROOT_ITEM check")
introduced btrfs root item size check, however btrfs root item has two
versions, the legacy one which just ends before generation_v2 member, is
smaller than
s true if alert cause was SOC change, not low SOC */
+static bool max17040_handle_soc_alert(struct max17040_chip *chip)
+{
+ bool ret = true;
+ u32 data;
+
+ regmap_read(chip->regmap, MAX17040_STATUS, );
+
+ if (data & MAX17040_STATUS_HD_MASK) {
+
Michael Kelley writes:
> vmbus_wait_for_unload() looks for a CHANNELMSG_UNLOAD_RESPONSE message
> coming from Hyper-V. But if the message isn't found for some reason,
> the panic path gets hung forever. Add a timeout of 10 seconds to prevent
> this.
If I remember correctly, the problem I was
Hi Alain
Sounds good
Reviewed-by: Pierre-Yves MORDRET
Best Regards
On 8/3/20 7:26 AM, Alain Volmat wrote:
> Add support for the SMBus-Alert protocol.
>
> Signed-off-by: Alain Volmat
> ---
> This patch has to be integrated on top of the patch
> 'i2c: stm32f7: Add
s true if alert cause was SOC change, not low SOC */
+static bool max17040_handle_soc_alert(struct max17040_chip *chip)
+{
+ bool ret = true;
+ u32 data;
+
+ regmap_read(chip->regmap, MAX17040_STATUS, );
+
+ if (data & MAX17040_STATUS_HD_MASK) {
+
Domain alerts are a mechanism for the driver to asynchronously notify
user-space applications of device reset or hardware alarms (both to be
added in later commits). This mechanism also allows the application to
enqueue an alert to its domain, as a form of (limited) IPC in a
multi-process scenario
From: Evan Quan
commit 28e628645333b7e581c4a7b04d958e4804ea10fe upstream.
Do the maths in celsius degree. This can fix the issues caused
by the changes below:
drm/amd/pm: correct Vega20 swctf limit setting
drm/amd/pm: correct Vega12 swctf limit setting
drm/amd/pm: correct Vega10 swctf limit
From: Evan Quan
commit 28e628645333b7e581c4a7b04d958e4804ea10fe upstream.
Do the maths in celsius degree. This can fix the issues caused
by the changes below:
drm/amd/pm: correct Vega20 swctf limit setting
drm/amd/pm: correct Vega12 swctf limit setting
drm/amd/pm: correct Vega10 swctf limit
Domain alerts are a mechanism for the driver to asynchronously notify
user-space applications of device reset or hardware alarms (both to be
added in later commits). This mechanism also allows the application to
enqueue an alert to its domain, as a form of (limited) IPC in a
multi-process scenario
Add support for the SMBus-Alert protocol.
Signed-off-by: Alain Volmat
---
This patch has to be integrated on top of the patch
'i2c: stm32f7: Add SMBus Host-Notify protocol support' since SMBus Alert is
enabled by the DT binding 'smbus' introduced in that patch.
drivers/i2c/busses/i2c
From: Vinay Kumar Yadav
[ Upstream commit c271042eb6a031d1333cf57422ec1d20726901ab ]
When tls data skb is pending for Tx and tls alert comes , It
is wrongly overwrite the record type of tls data to tls alert
record type. fix the issue correcting it.
v1->v2:
- Correct submission tree.
-
Hi Rob,
> > > The I2C/SMBUS framework already provides a mechanism to enable SMBus-Alert
> > > by naming an IRQ line "smbus_alert". However, on stm32, the SMBus-Alert is
> > > part of the i2c IRQ. Using the smbus_alert naming here would lead to
>
On Tue, Jun 30, 2020 at 09:41:07PM +0200, Wolfram Sang wrote:
> On Thu, Jun 25, 2020 at 09:39:28AM +0200, Alain Volmat wrote:
> > Add a new binding of the i2c-stm32f7 driver to enable the handling
> > of the SMBUS-Alert.
> >
> > The I2C/SMBUS framework already provides
Domain alerts are a mechanism for the driver to asynchronously notify
user-space applications of device reset or hardware alarms (both to be
added in later commits). This mechanism also allows the application to
enqueue an alert to its domain, as a form of (limited) IPC in a
multi-process scenario
> I've just prepared the 1st new serie with only the HostNotify bits in it.
> (basically, the core part, the dt-bindings with the enable-host-notify, and
> the usage within i2c-stm32f7).
Cool, thanks!
> You mentioned in the other thread that you still have some more review comment
> I believe.
On Tue, Jun 30, 2020 at 06:05:00PM +0200, Wolfram Sang wrote:
> On Thu, Jun 25, 2020 at 09:39:25AM +0200, Alain Volmat wrote:
> > This serie adds SMBus Alert and SMBus Host-Notify features for the
> > i2c-stm32f7.
>
> If it is not too much work for you, I think it
On Thu, Jun 25, 2020 at 09:39:28AM +0200, Alain Volmat wrote:
> Add a new binding of the i2c-stm32f7 driver to enable the handling
> of the SMBUS-Alert.
>
> The I2C/SMBUS framework already provides a mechanism to enable SMBus-Alert
> by naming an IRQ line "smbus_alert
On Thu, Jun 25, 2020 at 09:39:25AM +0200, Alain Volmat wrote:
> This serie adds SMBus Alert and SMBus Host-Notify features for the
> i2c-stm32f7.
If it is not too much work for you, I think it makes sense to split the
series into two, i.e. HostNotify and SMBusAlert parts.
signatu
This serie adds SMBus Alert and SMBus Host-Notify features for the i2c-stm32f7.
This serie v2 rework comments from the 1st serie and replace the very generic
reg_client / unreg_client callback with HOST_NOTIFY only reg_hnotify_cli
and unreg_hnotify_cli callbacks.
Alain Volmat (4):
i2c: smbus
Add a new binding of the i2c-stm32f7 driver to enable the handling
of the SMBUS-Alert.
The I2C/SMBUS framework already provides a mechanism to enable SMBus-Alert
by naming an IRQ line "smbus_alert". However, on stm32, the SMBus-Alert is
part of the i2c IRQ. Using the smbus_alert naming
ble ? MAX17040_ALSC_MASK : 0);
+}
+
static int max17040_set_rcomp(struct max17040_chip *chip, u16 rcomp)
{
u16 mask = chip->data.rcomp_bytes == 2 ?
@@ -298,11 +317,33 @@ static void max17040_work(struct work_struct *work)
max17040_queue_work(chip);
}
+/* Returns true if alert cause was SOC
t;>
>>>>> L2C: platform modifies aux control register: 0x0207 -> 0x3e470001
>>>>> L2C: platform provided aux values permit register corruption.
>>>>>
>>>>> This latency cycles value has always been set in software in sp
On Sat, May 23, 2020 at 10:36:01AM +, w...@kernel.org wrote:
>
> > > > + st,smbus-alert:
> > > > + description: Enable the SMBus Alert feature
> > > > + $ref: /schemas/types.yaml#/definitions/flag
> > > > +
> >
> > > +st,smbus-alert:
> > > + description: Enable the SMBus Alert feature
> > > + $ref: /schemas/types.yaml#/definitions/flag
> > > +
> >
> > We already have smbus_alert interrupt. Can't you just check for this in
wrote:
> Hello Rob,
>
> On Wed, May 13, 2020 at 02:19:32AM +, Rob Herring wrote:
> > On Tue, May 05, 2020 at 07:51:10AM +0200, Alain Volmat wrote:
> > > Add a new binding of the i2c-stm32f7 driver to enable the handling
> > > of the SMBUS-Alert
> &g
Hello Rob,
On Wed, May 13, 2020 at 02:19:32AM +, Rob Herring wrote:
> On Tue, May 05, 2020 at 07:51:10AM +0200, Alain Volmat wrote:
> > Add a new binding of the i2c-stm32f7 driver to enable the handling
> > of the SMBUS-Alert
> >
> > Signed-off-by: Alain Volmat
On Tue, May 05, 2020 at 07:51:10AM +0200, Alain Volmat wrote:
> Add a new binding of the i2c-stm32f7 driver to enable the handling
> of the SMBUS-Alert
>
> Signed-off-by: Alain Volmat
> ---
> Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml | 4
> 1 file
Add a new binding of the i2c-stm32f7 driver to enable the handling
of the SMBUS-Alert
Signed-off-by: Alain Volmat
---
Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
b
This serie adds SMBus Alert and SMBus Host-Notify features for the i2c-stm32f7.
For that purpore, I propose two enhancements to the i2c framework.
1. Addition of host-notify client handling as part of the
i2c-core-smbus so that any other i2c adapter can benefit from it,
even those without
On Mon, 3 Jun 2019 at 00:42, Matheus Castello wrote:
>
>
>
> On 5/29/19 11:46 AM, Krzysztof Kozlowski wrote:
> > On Mon, 27 May 2019 at 04:46, Matheus Castello
> > wrote:
> >>
> >> For configuration of fuel gauge alert for a low level state of charge
On Sun, 2 Jun 2019 at 23:42, Matheus Castello wrote:
>
> > On Mon, 27 May 2019 at 04:45, Matheus Castello
> > wrote:
> >>
> >> For configure low level state of charge threshold alert signaled from
> >> max17040 we add "maxim,alert-low-soc-le
On 5/29/19 11:46 AM, Krzysztof Kozlowski wrote:
On Mon, 27 May 2019 at 04:46, Matheus Castello wrote:
For configuration of fuel gauge alert for a low level state of charge
interrupt we add a function to config level threshold and a device tree
binding property to set it in flatned device
On Mon, 27 May 2019 at 04:45, Matheus Castello wrote:
For configure low level state of charge threshold alert signaled from
max17040 we add "maxim,alert-low-soc-level" property.
Signed-off-by: Matheus Castello
---
.../power/supply/max17040_battery.txt | 28 +
On Mon, 27 May 2019 at 04:45, Matheus Castello wrote:
>
> For configure low level state of charge threshold alert signaled from
> max17040 we add "maxim,alert-low-soc-level" property.
>
> Signed-off-by: Matheus Castello
> ---
> .../power/supply/ma
On Mon, 27 May 2019 at 04:46, Matheus Castello wrote:
>
> For configuration of fuel gauge alert for a low level state of charge
> interrupt we add a function to config level threshold and a device tree
> binding property to set it in flatned device tree node.
>
> Now we can us
On Mon, 27 May 2019 at 04:45, Matheus Castello wrote:
>
> For configure low level state of charge threshold alert signaled from
> max17040 we add "maxim,alert-low-soc-level" property.
>
> Signed-off-by: Matheus Castello
> ---
> .../power/supply/ma
On Mon, 27 May 2019 at 04:45, Matheus Castello wrote:
>
> According datasheet max17040 has a pin for alert host for low SOC.
> This pin can be used as external interrupt, so we need to check for
> interrupts assigned for device and handle it.
>
> In handler we are checking and
According datasheet max17040 has a pin for alert host for low SOC.
This pin can be used as external interrupt, so we need to check for
interrupts assigned for device and handle it.
In handler we are checking and storing fuel gauge registers values
and send an uevent to notificate user space, so
For configuration of fuel gauge alert for a low level state of charge
interrupt we add a function to config level threshold and a device tree
binding property to set it in flatned device tree node.
Now we can use "maxim,alert-low-soc-level" property with the values from
1% up to 32% to
For configure low level state of charge threshold alert signaled from
max17040 we add "maxim,alert-low-soc-level" property.
Signed-off-by: Matheus Castello
---
.../power/supply/max17040_battery.txt | 28 +++
1 file changed, 28 insertions(+)
create m
This series add IRQ handler for low level SOC alert, define a devicetree
binding attribute to configure the alert level threshold and check for
changes in SOC and power supply status for send uevents.
Max17040 have a pin for alert host about low level state of charge and
this alert can
On 4/29/19 7:13 PM, Rob Herring wrote:
On Sun, Apr 14, 2019 at 10:26:33PM -0300, Matheus Castello wrote:
For configure low level state of charge threshold alert signaled from
max17040 we add "maxim,alert-soc-level" property.
Signed-off-by: Matheus Castello
---
.../po
On Sun, Apr 14, 2019 at 10:26:33PM -0300, Matheus Castello wrote:
> For configure low level state of charge threshold alert signaled from
> max17040 we add "maxim,alert-soc-level" property.
>
> Signed-off-by: Matheus Castello
> ---
> .../power/supply/max17
Em 4/15/19 4:10 AM, Krzysztof Kozlowski escreveu:
On Mon, 15 Apr 2019 at 03:49, Matheus Castello wrote:
According datasheet max17040 has a pin for alert host for low SOC.
This pin can be used as external interrupt, so we need to check for
interrupts assigned for device and handle
On Mon, 15 Apr 2019 at 03:51, Matheus Castello wrote:
>
> For configuration of fuel gauge alert for a low level state of charge
> interrupt we add a function to config level threshold and a device tree
> binding property to set it in flatned device tree node.
>
> Now we can us
On Mon, 15 Apr 2019 at 03:50, Matheus Castello wrote:
>
> For configure low level state of charge threshold alert signaled from
> max17040 we add "maxim,alert-soc-level" property.
>
> Signed-off-by: Matheus Castello
> ---
> .../power/supply/ma
On Mon, 15 Apr 2019 at 03:49, Matheus Castello wrote:
>
> According datasheet max17040 has a pin for alert host for low SOC.
> This pin can be used as external interrupt, so we need to check for
> interrupts assigned for device and handle it.
>
> In hadler we are checking and
According datasheet max17040 has a pin for alert host for low SOC.
This pin can be used as external interrupt, so we need to check for
interrupts assigned for device and handle it.
In hadler we are checking and storing fuel gauge registers values
and send an uevent to notificate user space, so
For configure low level state of charge threshold alert signaled from
max17040 we add "maxim,alert-soc-level" property.
Signed-off-by: Matheus Castello
---
.../power/supply/max17040_battery.txt | 24 +++
1 file changed, 24 insertions(+)
create mode 100644
Doc
For configuration of fuel gauge alert for a low level state of charge
interrupt we add a function to config level threshold and a device tree
binding property to set it in flatned device tree node.
Now we can use "maxim,alert-soc-level" property with the values from
1 up to 32 to confi
This series add IRQ handler for low level SOC alert, define a devicetree
binding attribute to configure the alert level threshold and check for
changes in SOC for send uevents.
Max17040 have a pin for alert host about low level state of charge and
this alert can be configured in a threshold from
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Qu Wenruo
commit 848c23b78fafdcd3270b06a30737f8dbd70c347f upstream.
Commit 4751832da990 ("btrfs: fiemap: Cache and merge fiemap extent before
submit it to user") introduced a warning to catch
75 degrees is too aggressive for throttling the CPU. After speaking to
Qualcomm engineers, increase it to 95 degrees.
Signed-off-by: Amit Kucheria
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
On Fri, Jan 11, 2019 at 03:54:23PM +0530, Amit Kucheria wrote:
> On Thu, Jan 10, 2019 at 6:45 AM Matthias Kaehlcke wrote:
> >
> > Hi Amit,
> >
> > On Thu, Jan 10, 2019 at 05:30:55AM +0530, Amit Kucheria wrote:
> > > 75 degrees is too aggressive for throttling the CPU. After speaking to
> > >
On Thu, Jan 10, 2019 at 6:45 AM Matthias Kaehlcke wrote:
>
> Hi Amit,
>
> On Thu, Jan 10, 2019 at 05:30:55AM +0530, Amit Kucheria wrote:
> > 75 degrees is too aggressive for throttling the CPU. After speaking to
> > Qualcomm engineers, increase it to 95 degrees.
> >
> > Signed-off-by: Amit
On 10-01-19, 12:00, Matthias Kaehlcke wrote:
> Viresh helped me understand that we currently need to add cooling
> device entries for all CPUs to the DT, even though at most one will be
> active per freq domain at any time (I wonder if this could be changed
> though).
Actually we were only adding
On Thu, Jan 10, 2019 at 5:59 AM Stephen Boyd wrote:
>
> Quoting Amit Kucheria (2019-01-09 16:00:55)
> > 75 degrees is too aggressive for throttling the CPU. After speaking to
> > Qualcomm engineers, increase it to 95 degrees.
> >
> > Signed-off-by: Amit Kucheria
> > ---
> >
On Fri, Jan 11, 2019 at 01:15:09AM +0530, Amit Kucheria wrote:
> On Thu, Jan 10, 2019 at 7:45 AM Matthias Kaehlcke wrote:
> >
> > On Wed, Jan 09, 2019 at 05:15:33PM -0800, Matthias Kaehlcke wrote:
> > > Hi Amit,
> > >
> > > On Thu, Jan 10, 2019 at 05:30:55AM +0530, Amit Kucheria wrote:
> > > > 75
On Thu, Jan 10, 2019 at 7:45 AM Matthias Kaehlcke wrote:
>
> On Wed, Jan 09, 2019 at 05:15:33PM -0800, Matthias Kaehlcke wrote:
> > Hi Amit,
> >
> > On Thu, Jan 10, 2019 at 05:30:55AM +0530, Amit Kucheria wrote:
> > > 75 degrees is too aggressive for throttling the CPU. After speaking to
> > >
Hi,
On Wed, Jan 9, 2019 at 4:29 PM Stephen Boyd wrote:
>
> Quoting Amit Kucheria (2019-01-09 16:00:55)
> > 75 degrees is too aggressive for throttling the CPU. After speaking to
> > Qualcomm engineers, increase it to 95 degrees.
> >
> > Signed-off-by: Amit Kucheria
> > ---
> >
On Wed, Jan 09, 2019 at 05:15:33PM -0800, Matthias Kaehlcke wrote:
> Hi Amit,
>
> On Thu, Jan 10, 2019 at 05:30:55AM +0530, Amit Kucheria wrote:
> > 75 degrees is too aggressive for throttling the CPU. After speaking to
> > Qualcomm engineers, increase it to 95 degrees.
> >
> > Signed-off-by:
Hi Amit,
On Thu, Jan 10, 2019 at 05:30:55AM +0530, Amit Kucheria wrote:
> 75 degrees is too aggressive for throttling the CPU. After speaking to
> Qualcomm engineers, increase it to 95 degrees.
>
> Signed-off-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 16
Quoting Amit Kucheria (2019-01-09 16:00:55)
> 75 degrees is too aggressive for throttling the CPU. After speaking to
> Qualcomm engineers, increase it to 95 degrees.
>
> Signed-off-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 16
Is the plan that these are
75 degrees is too aggressive for throttling the CPU. After speaking to
Qualcomm engineers, increase it to 95 degrees.
Signed-off-by: Amit Kucheria
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
Dear user of vger.kernel.org!
I am a spyware software developer.
Your account has been hacked by me in the summer of 2018.
I understand that it is hard to believe, but here is my evidence:
- I sent you this email from your account.
- Password from account linux-kernel@vger.kernel.org: qwerty (on
Dear user of vger.kernel.org!
I am a spyware software developer.
Your account has been hacked by me in the summer of 2018.
I understand that it is hard to believe, but here is my evidence:
- I sent you this email from your account.
- Password from account linux-kernel@vger.kernel.org: qwerty (on
POWERBALL HEADQUARTERS FLORIDA
250 Marriot main street
Dr Tallahassee 32301
President Home Supplies
100 Broadway Lane
United states of America NW80QE.
REF: SNT/FRN/17LL12-2018,
POWER-BALL EMAIL JACKPOT IS ON AGAIN!!!
THE USA POWERBALL MEGA MILLION JUST REACHED AN AMAZING JACKPOT OF USD 8.2M YOU
POWERBALL HEADQUARTERS FLORIDA
250 Marriot main street
Dr Tallahassee 32301
President Home Supplies
100 Broadway Lane
United states of America NW80QE.
REF: SNT/FRN/17LL12-2018,
POWER-BALL EMAIL JACKPOT IS ON AGAIN!!!
THE USA POWERBALL MEGA MILLION JUST REACHED AN AMAZING JACKPOT OF USD 8.2M YOU
Hi Krzysztof and Sebastian,
please forgive me for the delay in working with this patch.
I've been having some personal issues these months, but leaving the
excuses I still intend to send a v2 for this.
Thanks Krzysztof for review and tips I'll work on it.
Best Regards,
Matheus Castello
On
Hi Krzysztof and Sebastian,
please forgive me for the delay in working with this patch.
I've been having some personal issues these months, but leaving the
excuses I still intend to send a v2 for this.
Thanks Krzysztof for review and tips I'll work on it.
Best Regards,
Matheus Castello
On
On Sun, 16 Sep 2018 at 22:03, Sebastian Reichel
wrote:
>
> Hi Matheus,
>
> Did I miss a v2 of this patchset, that solves the issues
> found by Krzysztof?
I did not see v2. This patchset brings nice feature so it would be a
pity if it were discontinued.
Best regards,
Krzysztof
On Sun, 16 Sep 2018 at 22:03, Sebastian Reichel
wrote:
>
> Hi Matheus,
>
> Did I miss a v2 of this patchset, that solves the issues
> found by Krzysztof?
I did not see v2. This patchset brings nice feature so it would be a
pity if it were discontinued.
Best regards,
Krzysztof
Hi Matheus,
Did I miss a v2 of this patchset, that solves the issues
found by Krzysztof?
-- Sebastian
On Mon, Jul 23, 2018 at 12:08:12AM -0400, Matheus Castello wrote:
> This series add IRQ handler for low level SOC alert, define a devicetree
> binding attribute to configure the alert
Hi Matheus,
Did I miss a v2 of this patchset, that solves the issues
found by Krzysztof?
-- Sebastian
On Mon, Jul 23, 2018 at 12:08:12AM -0400, Matheus Castello wrote:
> This series add IRQ handler for low level SOC alert, define a devicetree
> binding attribute to configure the alert
On 23 July 2018 at 06:08, Matheus Castello wrote:
> For configure low level state of charge threshold alert signaled from
> max17040 we add "maxim,alert-soc-level" property.
>
> Signed-off-by: Matheus Castello
> ---
> .../bindings/power/supply/m
On 23 July 2018 at 06:08, Matheus Castello wrote:
> For configure low level state of charge threshold alert signaled from
> max17040 we add "maxim,alert-soc-level" property.
>
> Signed-off-by: Matheus Castello
> ---
> .../bindings/power/supply/m
On 23 July 2018 at 06:08, Matheus Castello wrote:
> For configuration of fuel gauge alert for a low level state of charge
> interrupt we add a function to config level threshold and a device tree
> binding property to set it in flatned device tree node.
>
> Now we can use "m
On 23 July 2018 at 06:08, Matheus Castello wrote:
> For configuration of fuel gauge alert for a low level state of charge
> interrupt we add a function to config level threshold and a device tree
> binding property to set it in flatned device tree node.
>
> Now we can use "m
On 23 July 2018 at 06:08, Matheus Castello wrote:
> According datasheet max17040 has a pin for alert host for low SOC.
> This pin can be used as external interrupt, so we need to check for
> interrupts assigned for device and handle it.
>
> In hadler we are checking and sto
On 23 July 2018 at 06:08, Matheus Castello wrote:
> According datasheet max17040 has a pin for alert host for low SOC.
> This pin can be used as external interrupt, so we need to check for
> interrupts assigned for device and handle it.
>
> In hadler we are checking and sto
This series add IRQ handler for low level SOC alert, define a devicetree
binding attribute to configure the alert level threshold and check for changes
in SOC for send uevents.
Max17040 have a pin for alert host about low level state of charge and this
alert can be configured in a threshold
This series add IRQ handler for low level SOC alert, define a devicetree
binding attribute to configure the alert level threshold and check for changes
in SOC for send uevents.
Max17040 have a pin for alert host about low level state of charge and this
alert can be configured in a threshold
For configure low level state of charge threshold alert signaled from
max17040 we add "maxim,alert-soc-level" property.
Signed-off-by: Matheus Castello
---
.../bindings/power/supply/max17040_battery.txt | 24 ++
1 file changed, 24 insertions(+)
create m
For configure low level state of charge threshold alert signaled from
max17040 we add "maxim,alert-soc-level" property.
Signed-off-by: Matheus Castello
---
.../bindings/power/supply/max17040_battery.txt | 24 ++
1 file changed, 24 insertions(+)
create m
For configuration of fuel gauge alert for a low level state of charge
interrupt we add a function to config level threshold and a device tree
binding property to set it in flatned device tree node.
Now we can use "maxim,alert-soc-level" property with the values from
1 up to 32 to confi
1 - 100 of 329 matches
Mail list logo
