On Wed, Nov 14, 2018 at 03:49:17PM -0700, Keith Busch wrote:
> System memory may have side caches to help improve access speed. While
> the system provided cache is transparent to the software accessing
> these memory ranges, applications can optimize their own access based
> on cache attributes.
On Wed, Nov 14, 2018 at 03:49:17PM -0700, Keith Busch wrote:
> System memory may have side caches to help improve access speed. While
> the system provided cache is transparent to the software accessing
> these memory ranges, applications can optimize their own access based
> on cache attributes.
On Wed, Nov 14, 2018 at 03:49:17PM -0700, Keith Busch wrote:
> System memory may have side caches to help improve access speed. While
> the system provided cache is transparent to the software accessing
> these memory ranges, applications can optimize their own access based
> on cache attributes.
On Wed, Nov 14, 2018 at 03:49:17PM -0700, Keith Busch wrote:
> System memory may have side caches to help improve access speed. While
> the system provided cache is transparent to the software accessing
> these memory ranges, applications can optimize their own access based
> on cache attributes.
On Mon, Nov 26, 2018 at 11:49:54AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.5 release.
> There are 118 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Nov 22, 2018 at 05:45:10PM +0530, Balakrishna Godavarthi wrote:
> wcn3990 requires a power pulse to turn ON/OFF along with
> regulators. Sometimes we are observing the power pulses are sent
> out with some time delay, due to queuing these commands. This is
> causing synchronization issues
On Mon, Nov 26, 2018 at 11:49:54AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.5 release.
> There are 118 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Nov 22, 2018 at 05:45:10PM +0530, Balakrishna Godavarthi wrote:
> wcn3990 requires a power pulse to turn ON/OFF along with
> regulators. Sometimes we are observing the power pulses are sent
> out with some time delay, due to queuing these commands. This is
> causing synchronization issues
On Mon, Nov 26, 2018 at 11:50:49AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.141 release.
> There are 46 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Nov 26, 2018 at 11:50:49AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.141 release.
> There are 46 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Nov 26, 2018 at 11:50:54AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.127 release.
> There are 24 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Nov 26, 2018 at 11:50:54AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.127 release.
> There are 24 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Wed, 21 Nov 2018 17:33:02 PST (-0800), atish.pa...@wdc.com wrote:
On 11/21/18 5:07 PM, Paul Walmsley wrote:
For IP blocks that are generated from the public, open-source
sifive-blocks repository, describe the version numbering policy
that its maintainers intend to use, upon request from Rob
On Wed, 21 Nov 2018 17:06:56 PST (-0800), Paul Walmsley wrote:
For IP blocks that are generated from the public, open-source
sifive-blocks repository, describe the version numbering policy
that its maintainers intend to use, upon request from Rob
Herring .
Cc: Rob Herring
Cc: Palmer Dabbelt
On Wed, 21 Nov 2018 17:33:02 PST (-0800), atish.pa...@wdc.com wrote:
On 11/21/18 5:07 PM, Paul Walmsley wrote:
For IP blocks that are generated from the public, open-source
sifive-blocks repository, describe the version numbering policy
that its maintainers intend to use, upon request from Rob
On Wed, 21 Nov 2018 17:06:56 PST (-0800), Paul Walmsley wrote:
For IP blocks that are generated from the public, open-source
sifive-blocks repository, describe the version numbering policy
that its maintainers intend to use, upon request from Rob
Herring .
Cc: Rob Herring
Cc: Palmer Dabbelt
On Mon, Nov 26, 2018 at 01:55:37PM +, Ran Rozenstein wrote:
> >
> > Hearing no objections, here is the updated patch.
> >
> > Thanx, Paul
> >
> >
> >
> >
On Mon, Nov 26, 2018 at 01:55:37PM +, Ran Rozenstein wrote:
> >
> > Hearing no objections, here is the updated patch.
> >
> > Thanx, Paul
> >
> >
> >
> >
On Mon, Nov 26, 2018 at 05:07:46PM +, Will Deacon wrote:
> The current ioremap() code uses a phys_addr variable at each level of
> page table, which is confusingly offset by subtracting the base virtual
> address being mapped so that adding the current virtual address back on
> when iterating
On Mon, Nov 26, 2018 at 05:07:46PM +, Will Deacon wrote:
> The current ioremap() code uses a phys_addr variable at each level of
> page table, which is confusingly offset by subtracting the base virtual
> address being mapped so that adding the current virtual address back on
> when iterating
On Thu, 22 Nov 2018 13:23:40 +0530, Taniya Das wrote:
> Add device tree bindings for Low Power Audio subsystem clock controller for
> Qualcomm Technology Inc's SDM845 SoCs.
>
> Signed-off-by: Taniya Das
> ---
> .../devicetree/bindings/clock/qcom,gcc.txt | 4 +++-
>
On Thu, 22 Nov 2018 13:23:40 +0530, Taniya Das wrote:
> Add device tree bindings for Low Power Audio subsystem clock controller for
> Qualcomm Technology Inc's SDM845 SoCs.
>
> Signed-off-by: Taniya Das
> ---
> .../devicetree/bindings/clock/qcom,gcc.txt | 4 +++-
>
Add s700 compatible string to Actions Semi SoC dt-bindings.
Signed-off-by: Parthiban Nallathambi
---
Documentation/devicetree/bindings/i2c/i2c-owl.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-owl.txt
Add s700 compatible string to Actions Semi SoC dt-bindings.
Signed-off-by: Parthiban Nallathambi
---
Documentation/devicetree/bindings/i2c/i2c-owl.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-owl.txt
Add pinctrl definitions for Actions Semiconductor S700 I2C controllers.
Pinctrl definitions are only available for I2C0, I2C1 and I2C2.
Enable I2C0 (PMIC), I2C1 (gyro, touchscreen) in cubieboard7.
Signed-off-by: Parthiban Nallathambi
---
.../boot/dts/actions/s700-cubieboard7.dts | 53
Add pinctrl definitions for Actions Semiconductor S700 I2C controllers.
Pinctrl definitions are only available for I2C0, I2C1 and I2C2.
Enable I2C0 (PMIC), I2C1 (gyro, touchscreen) in cubieboard7.
Signed-off-by: Parthiban Nallathambi
---
.../boot/dts/actions/s700-cubieboard7.dts | 53
This patch series adds support for Actions Semi Owl SoC family S700
I2C controller. S700 provides 4 I2C masters and with cubieboard7
2 (I2C0 and I2C1) are exposed.
Added pinctrl definition for I2C controllers in cubieboard7. This patch
depends on s700 pinctrl driver support (yet to be merged),
Add S700 to the list of devices supported by Owl I2C driver.
Add Actions Semiconductor Owl family S900 I2C driver.
Signed-off-by: Parthiban Nallathambi
---
drivers/i2c/busses/i2c-owl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-owl.c
Add I2C controller nodes for Actions Semiconductor S700 SoC.
Signed-off-by: Parthiban Nallathambi
---
arch/arm64/boot/dts/actions/s700.dtsi | 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi
On Thu, 22 Nov 2018 13:23:39 +0530, Taniya Das wrote:
> Add protected-clocks list which could used to specify the clocks to be
> bypassed on certain devices.
>
> Signed-off-by: Taniya Das
> ---
> Documentation/devicetree/bindings/clock/qcom,gcc.txt | 14 ++
> 1 file changed, 14
This patch series adds support for Actions Semi Owl SoC family S700
I2C controller. S700 provides 4 I2C masters and with cubieboard7
2 (I2C0 and I2C1) are exposed.
Added pinctrl definition for I2C controllers in cubieboard7. This patch
depends on s700 pinctrl driver support (yet to be merged),
Add S700 to the list of devices supported by Owl I2C driver.
Add Actions Semiconductor Owl family S900 I2C driver.
Signed-off-by: Parthiban Nallathambi
---
drivers/i2c/busses/i2c-owl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-owl.c
Add I2C controller nodes for Actions Semiconductor S700 SoC.
Signed-off-by: Parthiban Nallathambi
---
arch/arm64/boot/dts/actions/s700.dtsi | 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi
On Thu, 22 Nov 2018 13:23:39 +0530, Taniya Das wrote:
> Add protected-clocks list which could used to specify the clocks to be
> bypassed on certain devices.
>
> Signed-off-by: Taniya Das
> ---
> Documentation/devicetree/bindings/clock/qcom,gcc.txt | 14 ++
> 1 file changed, 14
On Wed, Nov 21, 2018 at 10:02:36AM -0800, Matthias Kaehlcke wrote:
> On Wed, Nov 21, 2018 at 04:12:46PM +0530, Taniya Das wrote:
> > Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
> > SoCs. This is required for managing the cpu frequency transitions which are
> >
On Wed, Nov 21, 2018 at 10:02:36AM -0800, Matthias Kaehlcke wrote:
> On Wed, Nov 21, 2018 at 04:12:46PM +0530, Taniya Das wrote:
> > Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
> > SoCs. This is required for managing the cpu frequency transitions which are
> >
Signed-off-by: Ryan Lee
---
Changes : Created max98373_reset function to minimize code duplication.
Changed regmap_write to regmap_update_bits. Other bits except LSB
need to be masked.
Added reset verification step to make sure software reset is
completed well. Software
Signed-off-by: Ryan Lee
---
Changes : Created max98373_reset function to minimize code duplication.
Changed regmap_write to regmap_update_bits. Other bits except LSB
need to be masked.
Added reset verification step to make sure software reset is
completed well. Software
Hi Shameer,
Sorry for the delay...
On 18/10/2018 16:27, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Linuxarm [mailto:linuxarm-boun...@huawei.com] On Behalf Of
Shameerali Kolothum Thodi
Sent: 18 October 2018 14:34
To: Robin Murphy ; lorenzo.pieral...@arm.com;
Hi Shameer,
Sorry for the delay...
On 18/10/2018 16:27, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Linuxarm [mailto:linuxarm-boun...@huawei.com] On Behalf Of
Shameerali Kolothum Thodi
Sent: 18 October 2018 14:34
To: Robin Murphy ; lorenzo.pieral...@arm.com;
This device makes a loud buzzing sound when a headphone is inserted while
playing audio at full volume through the speaker.
Signed-off-by: Girija Kumar Kasinadhuni
---
Apologies for the earlier patch not being tested properly. Verified this
time, and on the actual hardware. Here' s the alsa-info
This device makes a loud buzzing sound when a headphone is inserted while
playing audio at full volume through the speaker.
Signed-off-by: Girija Kumar Kasinadhuni
---
Apologies for the earlier patch not being tested properly. Verified this
time, and on the actual hardware. Here' s the alsa-info
On Mon, Nov 26, 2018 at 05:11:03PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 26, 2018 at 04:53:54PM +0100, Frederic Weisbecker wrote:
> > > > + irq_work_queue_on(_cpu(vtime_set_nice_work, cpu), cpu);
> > >
> > > What happens if you already had one pending? Do we loose updates?
> >
> > No,
On Mon, Nov 26, 2018 at 05:11:03PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 26, 2018 at 04:53:54PM +0100, Frederic Weisbecker wrote:
> > > > + irq_work_queue_on(_cpu(vtime_set_nice_work, cpu), cpu);
> > >
> > > What happens if you already had one pending? Do we loose updates?
> >
> > No,
On Mon, Nov 19, 2018 at 6:10 AM Lucas Stach wrote:
>
> Hi Andrey,
>
> Am Samstag, den 17.11.2018, 10:12 -0800 schrieb Andrey Smirnov:
> > Everyone:
> >
> > This series contains changes I made to add support for i.MX8MQ to
> > GPCv2 driver in order to enable support of PCIE IP block on i.MX8MQ
> >
On Mon, Nov 19, 2018 at 6:10 AM Lucas Stach wrote:
>
> Hi Andrey,
>
> Am Samstag, den 17.11.2018, 10:12 -0800 schrieb Andrey Smirnov:
> > Everyone:
> >
> > This series contains changes I made to add support for i.MX8MQ to
> > GPCv2 driver in order to enable support of PCIE IP block on i.MX8MQ
> >
On 11/22/2018 11:37 PM, Ingo Molnar wrote:
>>> I think all the call paths from prctl and seccomp coming here
>>> has tsk == current.
>>
>> We had that discussion before with SSBD:
>>
>> seccomp_set_mode_filter()
>>seccomp_attach_filter()
>> seccomp_sync_threads()
>>
On 11/22/2018 11:37 PM, Ingo Molnar wrote:
>>> I think all the call paths from prctl and seccomp coming here
>>> has tsk == current.
>>
>> We had that discussion before with SSBD:
>>
>> seccomp_set_mode_filter()
>>seccomp_attach_filter()
>> seccomp_sync_threads()
>>
Hi Mathew,
Thanks for your response!
On 11/26/18 12:22 PM, Matthew Wilcox wrote:
On Mon, Nov 26, 2018 at 04:55:21PM +, Vineeth Remanan Pillai wrote:
+ do {
+ XA_STATE(xas, >i_pages, start);
+ int i;
+ int entries = 0;
+ struct
Hi Mathew,
Thanks for your response!
On 11/26/18 12:22 PM, Matthew Wilcox wrote:
On Mon, Nov 26, 2018 at 04:55:21PM +, Vineeth Remanan Pillai wrote:
+ do {
+ XA_STATE(xas, >i_pages, start);
+ int i;
+ int entries = 0;
+ struct
On Mon, Nov 19, 2018 at 5:22 PM Trent Piepho wrote:
>
> On Sat, 2018-11-17 at 10:12 -0800, Andrey Smirnov wrote:
> > PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
> > so none of the code in current implementation of imx6_pcie_reset_phy()
> > is applicable.
>
> Tested on
On Mon, Nov 19, 2018 at 5:22 PM Trent Piepho wrote:
>
> On Sat, 2018-11-17 at 10:12 -0800, Andrey Smirnov wrote:
> > PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
> > so none of the code in current implementation of imx6_pcie_reset_phy()
> > is applicable.
>
> Tested on
On Sun, Nov 25, 2018 at 07:33:47PM +0100, Thomas Gleixner wrote:
> Move the conditional invocation of __switch_to_xtra() into an inline
> function so the logic can be shared between 32 and 64 bit.
>
> Remove the handthrough of the TSS pointer and retrieve the pointer directly
On Sun, Nov 25, 2018 at 07:33:47PM +0100, Thomas Gleixner wrote:
> Move the conditional invocation of __switch_to_xtra() into an inline
> function so the logic can be shared between 32 and 64 bit.
>
> Remove the handthrough of the TSS pointer and retrieve the pointer directly
On Mon, Nov 26, 2018 at 10:11:48AM -0800, Doug Anderson wrote:
> just takes the load you pass it and sends it on. It looks like you
> can still force the mode but it looks like it's using a custom
> attribute for that (qcom,force-mode). I wonder if that should be
> changed to use
On Mon, Nov 26, 2018 at 10:11:48AM -0800, Doug Anderson wrote:
> just takes the load you pass it and sends it on. It looks like you
> can still force the mode but it looks like it's using a custom
> attribute for that (qcom,force-mode). I wonder if that should be
> changed to use
On Mon, Nov 26, 2018 at 9:10 AM Josh Poimboeuf wrote:
>
> On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > > index
On Mon, Nov 26, 2018 at 9:10 AM Josh Poimboeuf wrote:
>
> On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > > index
On Tue, Nov 20, 2018 at 2:49 AM Leonard Crestez wrote:
>
> On Sat, 2018-11-17 at 10:12 -0800, Andrey Smirnov wrote:
> > @@ -921,7 +1004,28 @@ static int imx6_pcie_probe(struct platform_device
> > *pdev)
> > - case IMX7D:
> > + case IMX8MQ:
> > + if (of_property_read_u32(node,
On Tue, Nov 20, 2018 at 2:49 AM Leonard Crestez wrote:
>
> On Sat, 2018-11-17 at 10:12 -0800, Andrey Smirnov wrote:
> > @@ -921,7 +1004,28 @@ static int imx6_pcie_probe(struct platform_device
> > *pdev)
> > - case IMX7D:
> > + case IMX8MQ:
> > + if (of_property_read_u32(node,
Hello,
Mathias Kresin wrote:
> In case the nd_sd group is set to the sd-card function, Pins 45 + 46 are
> configured as GPIOs. If they are blocked by the sd function, they can't
> be used as GPIOs.
>
> Signed-off-by: Mathias Kresin
> Reported-by: Kristian Evensen
> Fixes: f576fb6a0700 ("MIPS:
Hello,
Mathias Kresin wrote:
> In case the nd_sd group is set to the sd-card function, Pins 45 + 46 are
> configured as GPIOs. If they are blocked by the sd function, they can't
> be used as GPIOs.
>
> Signed-off-by: Mathias Kresin
> Reported-by: Kristian Evensen
> Fixes: f576fb6a0700 ("MIPS:
On Mon, Nov 26, 2018 at 3:00 AM Dr. Greg wrote:
>
> On Sun, Nov 25, 2018 at 04:37:00PM -0800, Andy Lutomirski wrote:
>
> > Bah, I hit send on a partially written draft. I???ll try again soon.
> >
> > --Andy
>
> Your first issue seems to be complete so I will respond to that in
> order to make
On Mon, Nov 26, 2018 at 3:00 AM Dr. Greg wrote:
>
> On Sun, Nov 25, 2018 at 04:37:00PM -0800, Andy Lutomirski wrote:
>
> > Bah, I hit send on a partially written draft. I???ll try again soon.
> >
> > --Andy
>
> Your first issue seems to be complete so I will respond to that in
> order to make
On Mon, Nov 26, 2018 at 09:43:42AM -0800, Doug Anderson wrote:
> NOTE: another option would be to change the regulator driver to just
> force this rail to a high power mode and never let it change. That's
> what we're doing on a SDM845-based board. When the regulator is off
> the mode doesn't
On Mon, Nov 26, 2018 at 09:43:42AM -0800, Doug Anderson wrote:
> NOTE: another option would be to change the regulator driver to just
> force this rail to a high power mode and never let it change. That's
> what we're doing on a SDM845-based board. When the regulator is off
> the mode doesn't
If cdev_add() fails, cdev_del() should be called.
Add the missing cdev_del() call as pointed out by
Dan Carpenter.
Signed-off-by: Michael Straube
---
v1 -> v2
Use goto and label.
drivers/staging/pi433/pi433_if.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
If cdev_add() fails, cdev_del() should be called.
Add the missing cdev_del() call as pointed out by
Dan Carpenter.
Signed-off-by: Michael Straube
---
v1 -> v2
Use goto and label.
drivers/staging/pi433/pi433_if.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On 11/26/2018 6:42 PM, Rob Landley wrote:
On 11/26/18 6:56 AM, Roberto Sassu wrote:
On 11/23/2018 9:21 PM, Rob Landley wrote:
The aim of this patch is to provide the same functionality without
introducing a new format. The value of xattrs is placed in regular files
having the same file name as
On 11/26/2018 6:42 PM, Rob Landley wrote:
On 11/26/18 6:56 AM, Roberto Sassu wrote:
On 11/23/2018 9:21 PM, Rob Landley wrote:
The aim of this patch is to provide the same functionality without
introducing a new format. The value of xattrs is placed in regular files
having the same file name as
On 11/26/18 7:01 PM, Dan Carpenter wrote:
On Mon, Nov 26, 2018 at 06:53:55PM +0100, Michael Straube wrote:
retval = cdev_add(device->cdev, device->devt, 1);
if (retval) {
dev_dbg(device->dev, "register of cdev failed");
+ cdev_del(device->cdev);
On 11/26/18 7:01 PM, Dan Carpenter wrote:
On Mon, Nov 26, 2018 at 06:53:55PM +0100, Michael Straube wrote:
retval = cdev_add(device->cdev, device->devt, 1);
if (retval) {
dev_dbg(device->dev, "register of cdev failed");
+ cdev_del(device->cdev);
Hi,
On Mon, Nov 26, 2018 at 9:59 AM Mark Brown wrote:
>
> On Mon, Nov 26, 2018 at 09:43:42AM -0800, Doug Anderson wrote:
>
> > NOTE: another option would be to change the regulator driver to just
> > force this rail to a high power mode and never let it change. That's
> > what we're doing on a
Hi,
On Mon, Nov 26, 2018 at 9:59 AM Mark Brown wrote:
>
> On Mon, Nov 26, 2018 at 09:43:42AM -0800, Doug Anderson wrote:
>
> > NOTE: another option would be to change the regulator driver to just
> > force this rail to a high power mode and never let it change. That's
> > what we're doing on a
On Sun, Nov 18, 2018 at 11:07 PM Richard Zhu wrote:
>
> Hi Andrey:
> Thanks for your patch-set.
> I have comment about the L1SS implementation below.
> It's better to figure out one method to fix it.
>
> BR
> Richard
>
> > -Original Message-
> > From: Andrey Smirnov
On Sun, Nov 18, 2018 at 11:07 PM Richard Zhu wrote:
>
> Hi Andrey:
> Thanks for your patch-set.
> I have comment about the L1SS implementation below.
> It's better to figure out one method to fix it.
>
> BR
> Richard
>
> > -Original Message-
> > From: Andrey Smirnov
On Mon, Nov 26, 2018 at 8:42 AM Dave Hansen wrote:
>
> On 11/23/18 1:13 PM, Dan Williams wrote:
> >> A new system call makes total sense to me. I have the same concern
> >> about the completeness of what's exposed in sysfs, I just don't see a
> >> _route_ to completeness with sysfs itself.
On Mon, Nov 26, 2018 at 8:42 AM Dave Hansen wrote:
>
> On 11/23/18 1:13 PM, Dan Williams wrote:
> >> A new system call makes total sense to me. I have the same concern
> >> about the completeness of what's exposed in sysfs, I just don't see a
> >> _route_ to completeness with sysfs itself.
On 11/26/18 10:56 AM, Jeff Kirsher wrote:
> On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is
>> encoded
>> as -1. Even though implicitly understood it is always better to have
>> macros
>> in there. Replace these open
On 11/26/18 10:56 AM, Jeff Kirsher wrote:
> On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is
>> encoded
>> as -1. Even though implicitly understood it is always better to have
>> macros
>> in there. Replace these open
Hi Enric,
On Mon, Nov 26, 2018 at 9:52 AM Enric Balletbo i Serra
wrote:
>
> Use devm_mfd_add_devices() for adding cros-ec core MFD child devices. This
> reduces the need of remove callback from platform/chrome for removing the
> MFD child devices.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
Hi Enric,
On Mon, Nov 26, 2018 at 9:52 AM Enric Balletbo i Serra
wrote:
>
> Use devm_mfd_add_devices() for adding cros-ec core MFD child devices. This
> reduces the need of remove callback from platform/chrome for removing the
> MFD child devices.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
Hi Bjorn,
The SD card reader in my Acer Aspire S5 doesn't work with 4.20-rc.
Here's what lspci -v says about it (in a bad kernel):
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI
Express Card Reader
(rev 01)
Subsystem: Acer Incorporated [ALI] Device 0704
Hi Bjorn,
The SD card reader in my Acer Aspire S5 doesn't work with 4.20-rc.
Here's what lspci -v says about it (in a bad kernel):
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI
Express Card Reader
(rev 01)
Subsystem: Acer Incorporated [ALI] Device 0704
On Mon, Nov 26, 2018 at 11:10:36AM -0600, Josh Poimboeuf wrote:
> On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > > index
On Mon, Nov 26, 2018 at 11:10:36AM -0600, Josh Poimboeuf wrote:
> On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > > index
Bjørn Mork wrote:
> Not that it matters much I guess, but I think LX SFPs were unsupported
> at that time. The LX support appears to have been added under the radar
> while refactoring ixgbe_setup_sfp_modules_X550em in commit e23f33367882
> ("ixgbe: Fix 1G and 10G link stability for X550EM_x
Bjørn Mork wrote:
> Not that it matters much I guess, but I think LX SFPs were unsupported
> at that time. The LX support appears to have been added under the radar
> while refactoring ixgbe_setup_sfp_modules_X550em in commit e23f33367882
> ("ixgbe: Fix 1G and 10G link stability for X550EM_x
If cdev_add() fails, cdev_del() should be called.
Add the missing cdev_del() call as pointed out by
Dan Carpenter.
Signed-off-by: Michael Straube
---
drivers/staging/pi433/pi433_if.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/pi433/pi433_if.c
If cdev_add() fails, cdev_del() should be called.
Add the missing cdev_del() call as pointed out by
Dan Carpenter.
Signed-off-by: Michael Straube
---
drivers/staging/pi433/pi433_if.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/pi433/pi433_if.c
The entire way how cros sysfs attibutes are created is broken.
cros_ec_lightbar should be its own driver and its attributes should be
associated with a lightbar driver not the mfd driver. In order to retain
the path, the lightbar attributes are attached to the cros_class.
The patch also adds the
Hi,
This is another patchset to try to cleanup a bit more the crossed
references for cros-ec driver between the MFD and the platform/chrome
subsystems.
The purpose of these patches is get rid of the different cros-ec attributes
from mfd/cros_ec_dev to its own sub-driver in platform/chrome.
On 26 November 2018 4:20:54 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 3.18.127 release.
>There are 24 patches in this series, all will be posted as a response
>to this one. If anyone has any issues with these being applied, please
>let me know.
>
The entire way how cros sysfs attibutes are created is broken.
cros_ec_vbc should be its own driver and its attributes should be
associated with a vbc driver not the mfd driver. In order to retain
the path, the vbc attributes are attached to the cros_class.
The patch also adds the sysfs
The entire way how cros sysfs attibutes are created is broken.
cros_ec_lightbar should be its own driver and its attributes should be
associated with a lightbar driver not the mfd driver. In order to retain
the path, the lightbar attributes are attached to the cros_class.
The patch also adds the
Hi,
This is another patchset to try to cleanup a bit more the crossed
references for cros-ec driver between the MFD and the platform/chrome
subsystems.
The purpose of these patches is get rid of the different cros-ec attributes
from mfd/cros_ec_dev to its own sub-driver in platform/chrome.
On 26 November 2018 4:20:54 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 3.18.127 release.
>There are 24 patches in this series, all will be posted as a response
>to this one. If anyone has any issues with these being applied, please
>let me know.
>
The entire way how cros sysfs attibutes are created is broken.
cros_ec_vbc should be its own driver and its attributes should be
associated with a vbc driver not the mfd driver. In order to retain
the path, the vbc attributes are attached to the cros_class.
The patch also adds the sysfs
Devices are required to provide a release method. This patch fixes the
following WARN():
[ 47.218707] [ cut here ]
[ 47.223901] Device 'cros_ec' does not have a release() function, it is
broken and must be fixed.
[ 47.234430] WARNING: CPU: 0 PID: 3585 at
Due to the way attribute groups visibility work, the function
cros_ec_lightbar_attrs_are_visible is called multiple times, once per
attribute, and each of these calls makes an EC transaction. For what is
worth the EC log reports multiple errors on boot when the lightbar is
not available. Instead,
601 - 700 of 2196 matches
Mail list logo
