The parent clock is get only to have its name, and then the clock is no
more used, so we can safely free it using clk_put. Furthermore as between
the successful devm_clk_get() and the devm_clk_put() call we don't exit
the probe function in error so I can use non managed version of clk_get()
and
The parent clock is get only to have its name, and then the clock is no
more used, so we can safely free it using clk_put. Furthermore as between
the successful devm_clk_get() and the devm_clk_put() call we don't exit
the probe function in error so I can use non managed version of clk_get()
and
On Wed, Oct 10, 2018 at 01:16:05PM -0500, Josh Poimboeuf wrote:
> On Wed, Oct 10, 2018 at 11:03:43AM -0700, Andy Lutomirski wrote:
> > > +#define DECLARE_STATIC_CALL(tramp, func) \
> > > + extern typeof(func) tramp; \
> > > +
On Wed, Oct 10, 2018 at 01:16:05PM -0500, Josh Poimboeuf wrote:
> On Wed, Oct 10, 2018 at 11:03:43AM -0700, Andy Lutomirski wrote:
> > > +#define DECLARE_STATIC_CALL(tramp, func) \
> > > + extern typeof(func) tramp; \
> > > +
On 10/10/18 10:26 AM, Jann Horn wrote:
> On Wed, Oct 10, 2018 at 7:19 PM Michal Hocko wrote:
>> On Wed 10-10-18 17:27:36, Jann Horn wrote:
>>> Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an
>>> application causes that application to randomly crash. The existing check
>>>
On 10/10/18 10:26 AM, Jann Horn wrote:
> On Wed, Oct 10, 2018 at 7:19 PM Michal Hocko wrote:
>> On Wed 10-10-18 17:27:36, Jann Horn wrote:
>>> Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an
>>> application causes that application to randomly crash. The existing check
>>>
On Wed, Oct 10, 2018 at 11:03:43AM -0700, Andy Lutomirski wrote:
> > +#define DECLARE_STATIC_CALL(tramp, func) \
> > + extern typeof(func) tramp; \
> > + static void __used __section(.discard.static_call_tramps) \
On Wed, Oct 10, 2018 at 11:03:43AM -0700, Andy Lutomirski wrote:
> > +#define DECLARE_STATIC_CALL(tramp, func) \
> > + extern typeof(func) tramp; \
> > + static void __used __section(.discard.static_call_tramps) \
On Wed, Oct 10, 2018 at 10:02:19AM -0700, Dmitry Torokhov wrote:
On Wed, Oct 10, 2018 at 10:29:58AM -0400, Sasha Levin wrote:
On Mon, Oct 08, 2018 at 12:20:26PM -0700, Dmitry Torokhov wrote:
> Hi Michael,
>
> On Mon, Oct 8, 2018 at 12:09 PM Michael Schmitz wrote:
> >
> > Dmitry,
> >
> >
On Wed, Oct 10, 2018 at 10:02:19AM -0700, Dmitry Torokhov wrote:
On Wed, Oct 10, 2018 at 10:29:58AM -0400, Sasha Levin wrote:
On Mon, Oct 08, 2018 at 12:20:26PM -0700, Dmitry Torokhov wrote:
> Hi Michael,
>
> On Mon, Oct 8, 2018 at 12:09 PM Michael Schmitz wrote:
> >
> > Dmitry,
> >
> >
Hi Stephen,
On mer., oct. 10 2018, Stephen Boyd wrote:
> Quoting Gregory CLEMENT (2018-09-14 08:34:21)
>> The parent clock is get only to have its name, and then the clock is no
>> more used, so we can safely free it using devm_clk_put.
>>
>> Signed-off-by: Gregory CLEMENT
>> ---
>>
On 10/10/2018 12:53 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 10/10/2018 7:11 AM, Moger, Babu wrote:
>> On 10/09/2018 05:01 PM, Reinette Chatre wrote:
>>> On 10/9/2018 2:17 PM, Moger, Babu wrote:
On 10/09/2018 11:39 AM, Reinette Chatre wrote:
> On 10/5/2018 1:55 PM, Moger, Babu
Hi Stephen,
On mer., oct. 10 2018, Stephen Boyd wrote:
> Quoting Gregory CLEMENT (2018-09-14 08:34:21)
>> The parent clock is get only to have its name, and then the clock is no
>> more used, so we can safely free it using devm_clk_put.
>>
>> Signed-off-by: Gregory CLEMENT
>> ---
>>
On 10/10/2018 12:53 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 10/10/2018 7:11 AM, Moger, Babu wrote:
>> On 10/09/2018 05:01 PM, Reinette Chatre wrote:
>>> On 10/9/2018 2:17 PM, Moger, Babu wrote:
On 10/09/2018 11:39 AM, Reinette Chatre wrote:
> On 10/5/2018 1:55 PM, Moger, Babu
On Wed, Oct 10, 2018 at 10:52 AM Josh Poimboeuf wrote:
>
> On Mon, Oct 08, 2018 at 11:57:50PM -0400, Steven Rostedt wrote:
> > On Mon, 8 Oct 2018 21:17:10 -0500
> > Josh Poimboeuf wrote:
> >
> > > I'm not really convinced we need objtool for this, maybe I'll try
> > > whipping up a POC.
> >
> >
On Wed, Oct 10, 2018 at 10:52 AM Josh Poimboeuf wrote:
>
> On Mon, Oct 08, 2018 at 11:57:50PM -0400, Steven Rostedt wrote:
> > On Mon, 8 Oct 2018 21:17:10 -0500
> > Josh Poimboeuf wrote:
> >
> > > I'm not really convinced we need objtool for this, maybe I'll try
> > > whipping up a POC.
> >
> >
On 10/10/18 10:38 AM, Michal Hocko wrote:
> On Wed 10-10-18 19:26:50, Jann Horn wrote:
> [...]
>> As you can see, the first page of the mapping at 0x10001000 was clobbered.
>>
diff --git a/mm/mmap.c b/mm/mmap.c
index 5f2b2b184c60..f7cd9cb966c0 100644
--- a/mm/mmap.c
+++
On 10/10/18 10:38 AM, Michal Hocko wrote:
> On Wed 10-10-18 19:26:50, Jann Horn wrote:
> [...]
>> As you can see, the first page of the mapping at 0x10001000 was clobbered.
>>
diff --git a/mm/mmap.c b/mm/mmap.c
index 5f2b2b184c60..f7cd9cb966c0 100644
--- a/mm/mmap.c
+++
Hi Babu,
On 10/10/2018 7:11 AM, Moger, Babu wrote:
> On 10/09/2018 05:01 PM, Reinette Chatre wrote:
>> On 10/9/2018 2:17 PM, Moger, Babu wrote:
>>> On 10/09/2018 11:39 AM, Reinette Chatre wrote:
On 10/5/2018 1:55 PM, Moger, Babu wrote:
> New generation of AMD processors start support
Hi Babu,
On 10/10/2018 7:11 AM, Moger, Babu wrote:
> On 10/09/2018 05:01 PM, Reinette Chatre wrote:
>> On 10/9/2018 2:17 PM, Moger, Babu wrote:
>>> On 10/09/2018 11:39 AM, Reinette Chatre wrote:
On 10/5/2018 1:55 PM, Moger, Babu wrote:
> New generation of AMD processors start support
On Mon, Oct 08, 2018 at 11:57:50PM -0400, Steven Rostedt wrote:
> On Mon, 8 Oct 2018 21:17:10 -0500
> Josh Poimboeuf wrote:
>
> > I'm not really convinced we need objtool for this, maybe I'll try
> > whipping up a POC.
>
> Awesome!
>
> I wasn't thinking of actually having objtool itself
On Mon, Oct 08, 2018 at 11:57:50PM -0400, Steven Rostedt wrote:
> On Mon, 8 Oct 2018 21:17:10 -0500
> Josh Poimboeuf wrote:
>
> > I'm not really convinced we need objtool for this, maybe I'll try
> > whipping up a POC.
>
> Awesome!
>
> I wasn't thinking of actually having objtool itself
Ingo Molnar writes:
> I've Cc:-ed a handful of gents who worked on CFS bandwidth details to widen
> the discussion.
> Patch quoted below.
>
> Looks like a real bug that needs to be fixed - and at first sight the quota
> of 1000 looks very
> low - could we improve the arithmetics perhaps?
>
>
Ingo Molnar writes:
> I've Cc:-ed a handful of gents who worked on CFS bandwidth details to widen
> the discussion.
> Patch quoted below.
>
> Looks like a real bug that needs to be fixed - and at first sight the quota
> of 1000 looks very
> low - could we improve the arithmetics perhaps?
>
>
The following changes since commit c6b6265d718d118e28e1ce8f91769aa886b54c94:
Merge tag 'iwlwifi-fw-2018-10-03' of
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware
(2018-10-08 09:23:53 -0400)
are available in the git repository at:
The following changes since commit c6b6265d718d118e28e1ce8f91769aa886b54c94:
Merge tag 'iwlwifi-fw-2018-10-03' of
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware
(2018-10-08 09:23:53 -0400)
are available in the git repository at:
On Mon, Oct 8, 2018 at 11:00 AM Tycho Andersen wrote:
>
> On Mon, Oct 08, 2018 at 05:16:30PM +0200, Christian Brauner wrote:
> > On Thu, Sep 27, 2018 at 09:11:16AM -0600, Tycho Andersen wrote:
> > > As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> > > version which can
On Mon, Oct 8, 2018 at 11:00 AM Tycho Andersen wrote:
>
> On Mon, Oct 08, 2018 at 05:16:30PM +0200, Christian Brauner wrote:
> > On Thu, Sep 27, 2018 at 09:11:16AM -0600, Tycho Andersen wrote:
> > > As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> > > version which can
On Wed 10-10-18 19:26:50, Jann Horn wrote:
[...]
> As you can see, the first page of the mapping at 0x10001000 was clobbered.
>
> > > diff --git a/mm/mmap.c b/mm/mmap.c
> > > index 5f2b2b184c60..f7cd9cb966c0 100644
> > > --- a/mm/mmap.c
> > > +++ b/mm/mmap.c
> > > @@ -1410,7 +1410,7 @@ unsigned
On Wed 10-10-18 19:26:50, Jann Horn wrote:
[...]
> As you can see, the first page of the mapping at 0x10001000 was clobbered.
>
> > > diff --git a/mm/mmap.c b/mm/mmap.c
> > > index 5f2b2b184c60..f7cd9cb966c0 100644
> > > --- a/mm/mmap.c
> > > +++ b/mm/mmap.c
> > > @@ -1410,7 +1410,7 @@ unsigned
Quoting Gregory CLEMENT (2018-09-14 08:34:21)
> The parent clock is get only to have its name, and then the clock is no
> more used, so we can safely free it using devm_clk_put.
>
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/clk/mvebu/armada-37xx-tbg.c | 1 +
> 1 file changed, 1
Quoting Gregory CLEMENT (2018-09-14 08:34:21)
> The parent clock is get only to have its name, and then the clock is no
> more used, so we can safely free it using devm_clk_put.
>
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/clk/mvebu/armada-37xx-tbg.c | 1 +
> 1 file changed, 1
On Wed, 2018-10-10 at 18:16 +0100, John Garry wrote:
> (to: get_maintainers -f include/linux/bitfield.h)
>
> Hi,
>
> I would like to use FIELD_PREP() macro for assigning a static array,
> like this:
> function()
> {
> static u32 val[2] = {FIELD_PREP(GENMASK_ULL(10, 0), 5), 0};
>
> }
>
>
On Wed, 2018-10-10 at 18:16 +0100, John Garry wrote:
> (to: get_maintainers -f include/linux/bitfield.h)
>
> Hi,
>
> I would like to use FIELD_PREP() macro for assigning a static array,
> like this:
> function()
> {
> static u32 val[2] = {FIELD_PREP(GENMASK_ULL(10, 0), 5), 0};
>
> }
>
>
Hello Lukasz,
On 10/10/2018 11:35 AM, Lukasz Luba wrote:
> Hi Thara,
>
> I have run it on Exynos5433 mainline.
> When it is enabled with step_wise thermal governor,
> some of my tests are showing ~30-50% regression (i.e. hackbench),
> dhrystone ~10%.
That is interesting. If I understand
Hello Lukasz,
On 10/10/2018 11:35 AM, Lukasz Luba wrote:
> Hi Thara,
>
> I have run it on Exynos5433 mainline.
> When it is enabled with step_wise thermal governor,
> some of my tests are showing ~30-50% regression (i.e. hackbench),
> dhrystone ~10%.
That is interesting. If I understand
Reviewed-by: Pavel Tatashin
On 10/2/18 10:38 AM, Masayoshi Mizuma wrote:
> From: Naoya Horiguchi
>
> There is a kernel panic that is triggered when reading /proc/kpageflags
> on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
>
> BUG: unable to handle kernel paging request
Reviewed-by: Pavel Tatashin
On 10/2/18 10:38 AM, Masayoshi Mizuma wrote:
> From: Naoya Horiguchi
>
> There is a kernel panic that is triggered when reading /proc/kpageflags
> on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
>
> BUG: unable to handle kernel paging request
On Wed, Oct 10, 2018 at 7:19 PM Michal Hocko wrote:
> On Wed 10-10-18 17:27:36, Jann Horn wrote:
> > Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an
> > application causes that application to randomly crash. The existing check
> > for handling MAP_FIXED_NOREPLACE looks up
On Wed, Oct 10, 2018 at 7:19 PM Michal Hocko wrote:
> On Wed 10-10-18 17:27:36, Jann Horn wrote:
> > Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an
> > application causes that application to randomly crash. The existing check
> > for handling MAP_FIXED_NOREPLACE looks up
On Fri, 2018-09-21 at 22:34 +0200, Robert Jarzmik wrote:
> Lubomir Rintel writes:
>
> > That seems to be the correct type.
> Okay, but what happens here when adev_id->driver_data is a value out
> of enum
> range ? Does the following assignment make sense ?
> > + type = (enum
On Fri, 2018-09-21 at 22:34 +0200, Robert Jarzmik wrote:
> Lubomir Rintel writes:
>
> > That seems to be the correct type.
> Okay, but what happens here when adev_id->driver_data is a value out
> of enum
> range ? Does the following assignment make sense ?
> > + type = (enum
On non-preempt kernels this loop can take a long time (more than 50
ticks) processing through entries.
Signed-off-by: Khazhismel Kumykov
---
fs/fat/fatent.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c
index defc2168de91..f58c0cacc531 100644
---
On non-preempt kernels this loop can take a long time (more than 50
ticks) processing through entries.
Signed-off-by: Khazhismel Kumykov
---
fs/fat/fatent.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c
index defc2168de91..f58c0cacc531 100644
---
It's based off the driver from the OLPC kernel sources. Somewhat
modernized and cleaned up, for better or worse.
Modified to plug into the olpc-ec driver infrastructure (so that battery
interface and debugfs could be reused) and the SPI slave framework.
Signed-off-by: Lubomir Rintel
---
It's based off the driver from the OLPC kernel sources. Somewhat
modernized and cleaned up, for better or worse.
Modified to plug into the olpc-ec driver infrastructure (so that battery
interface and debugfs could be reused) and the SPI slave framework.
Signed-off-by: Lubomir Rintel
---
All OLPC ECs are able to turn the power to the DCON on an off. Use the
regulator framework to expose the functionality.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/Kconfig | 1 +
drivers/platform/olpc/olpc-ec.c | 65 +
2 files changed, 66
The global variables for private data are not too nice. I'd like some
more, and that would clutter the global name space even further.
Signed-off-by: Lubomir Rintel
---
drivers/power/supply/olpc_battery.c | 73 +++--
1 file changed, 38 insertions(+), 35 deletions(-)
All OLPC ECs are able to turn the power to the DCON on an off. Use the
regulator framework to expose the functionality.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/Kconfig | 1 +
drivers/platform/olpc/olpc-ec.c | 65 +
2 files changed, 66
The global variables for private data are not too nice. I'd like some
more, and that would clutter the global name space even further.
Signed-off-by: Lubomir Rintel
---
drivers/power/supply/olpc_battery.c | 73 +++--
1 file changed, 38 insertions(+), 35 deletions(-)
The battery and the protocol are essentially the same as OLPC XO 1.5,
but the responses from the EC are LSB first.
Signed-off-by: Lubomir Rintel
---
drivers/power/supply/olpc_battery.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git
The battery and the protocol are essentially the same as OLPC XO 1.5,
but the responses from the EC are LSB first.
Signed-off-by: Lubomir Rintel
---
drivers/power/supply/olpc_battery.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git
Avoid using the x86 OLPC platform specific call to get the board
version. It won't work on FDT-based ARM MMP2 platform.
Signed-off-by: Lubomir Rintel
---
drivers/power/supply/olpc_battery.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
Just return ENODEV, so that whoever attempted to use the EC call can
defer their work.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
The XO-1 and XO-1.5 batteries apparently differ in an ability to report
ambient temperature. Add a different compatible string to the 1.5
battery.
Signed-off-by: Lubomir Rintel
---
arch/x86/platform/olpc/olpc_dt.c | 59 +++-
1 file changed, 42 insertions(+), 17
This wouldn't work on the DT-based ARM platform. Let's read the EC version
directly from the EC driver instead.
This makes the driver no longer x86 specific.
Signed-off-by: Lubomir Rintel
---
drivers/power/supply/Kconfig| 2 +-
drivers/power/supply/olpc_battery.c | 35
Avoid using the x86 OLPC platform specific call to get the board
version. It won't work on FDT-based ARM MMP2 platform.
Signed-off-by: Lubomir Rintel
---
drivers/power/supply/olpc_battery.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
Just return ENODEV, so that whoever attempted to use the EC call can
defer their work.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
The XO-1 and XO-1.5 batteries apparently differ in an ability to report
ambient temperature. Add a different compatible string to the 1.5
battery.
Signed-off-by: Lubomir Rintel
---
arch/x86/platform/olpc/olpc_dt.c | 59 +++-
1 file changed, 42 insertions(+), 17
This wouldn't work on the DT-based ARM platform. Let's read the EC version
directly from the EC driver instead.
This makes the driver no longer x86 specific.
Signed-off-by: Lubomir Rintel
---
drivers/power/supply/Kconfig| 2 +-
drivers/power/supply/olpc_battery.c | 35
The XO-1 and XO-1.5 batteries apparently differ in an ability to report
ambient temperature.
Signed-off-by: Lubomir Rintel
---
Documentation/devicetree/bindings/power/supply/olpc_battery.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
There are ARM OLPC machines that use mostly the same drivers, including
EC infrastructure, DCON and Battery.
While at that, fix Kconfig to allow building this as a module.
Signed-off-by: Lubomir Rintel
---
arch/x86/Kconfig | 11 ---
drivers/input/mouse/Kconfig |
It is actually plaform independent. Move it to the olpc-ec driver from
the X86 OLPC platform, so that it could be used by the ARM based laptops
too.
Signed-off-by: Lubomir Rintel
---
arch/x86/include/asm/olpc.h | 17 -
arch/x86/platform/olpc/olpc.c | 119
The XO-1 and XO-1.5 batteries apparently differ in an ability to report
ambient temperature.
Signed-off-by: Lubomir Rintel
---
Documentation/devicetree/bindings/power/supply/olpc_battery.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
There are ARM OLPC machines that use mostly the same drivers, including
EC infrastructure, DCON and Battery.
While at that, fix Kconfig to allow building this as a module.
Signed-off-by: Lubomir Rintel
---
arch/x86/Kconfig | 11 ---
drivers/input/mouse/Kconfig |
It is actually plaform independent. Move it to the olpc-ec driver from
the X86 OLPC platform, so that it could be used by the ARM based laptops
too.
Signed-off-by: Lubomir Rintel
---
arch/x86/include/asm/olpc.h | 17 -
arch/x86/platform/olpc/olpc.c | 119
It doesn't make sense to always have this built-in, e.g. on ARM
multiplatform kernels. A better way to address the problem the original
commit aimed to solve is to fix Kconfig.
This reverts commit f48d1496b8537d75776478c6942dd87f34d7f270.
Signed-off-by: Lubomir Rintel
---
The OLPC XO-1.75 Embedded Controller is a SPI master that uses extra
signals for handshaking. It needs to know when is the slave (Linux)
side's TX FIFO ready for transfer (the ready-gpio signal on the SPI
controller node) and when does it wish to respond with a command (the
cmd-gpio property).
It doesn't make sense to always have this built-in, e.g. on ARM
multiplatform kernels. A better way to address the problem the original
commit aimed to solve is to fix Kconfig.
This reverts commit f48d1496b8537d75776478c6942dd87f34d7f270.
Signed-off-by: Lubomir Rintel
---
The OLPC XO-1.75 Embedded Controller is a SPI master that uses extra
signals for handshaking. It needs to know when is the slave (Linux)
side's TX FIFO ready for transfer (the ready-gpio signal on the SPI
controller node) and when does it wish to respond with a command (the
cmd-gpio property).
Also, the header is x86 specific, while there are non-x86 OLPC machines.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index f99b183d5296..35a21c66cd0d 100644
According to [1] and [2], the temperature values are in tenths of degree
Celsius. Exposing the Celsius value makes the battery appear on fire:
$ upower -i /org/freedesktop/UPower/devices/battery_olpc_battery
...
temperature: 236.9 degrees C
Tested on OLPC XO-1 and OLPC XO-1.75
Hi.
This patchset adds support for the Embedded Controller on an OLPC XO
1.75 machine. OLPC XO 1.75 is a MMP2 based ARM laptop. It plugs into
the existing OLPC platform infrastructure, currently used by the x86
based models.
The EC operates in SPI master mode, meaning the SOC is the SPI slave.
Also, the header is x86 specific, while there are non-x86 OLPC machines.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index f99b183d5296..35a21c66cd0d 100644
According to [1] and [2], the temperature values are in tenths of degree
Celsius. Exposing the Celsius value makes the battery appear on fire:
$ upower -i /org/freedesktop/UPower/devices/battery_olpc_battery
...
temperature: 236.9 degrees C
Tested on OLPC XO-1 and OLPC XO-1.75
Hi.
This patchset adds support for the Embedded Controller on an OLPC XO
1.75 machine. OLPC XO 1.75 is a MMP2 based ARM laptop. It plugs into
the existing OLPC platform infrastructure, currently used by the x86
based models.
The EC operates in SPI master mode, meaning the SOC is the SPI slave.
Em Wed, 10 Oct 2018 16:53:08 +0100
Alan Cox escreveu:
> > -Maintainers have the right and responsibility to remove, edit, or reject
> > +Maintainers may remove, edit, or reject
> > comments, commits, code, wiki edits, issues, and other contributions that
> > are
> > not aligned to this Code
Em Wed, 10 Oct 2018 16:53:08 +0100
Alan Cox escreveu:
> > -Maintainers have the right and responsibility to remove, edit, or reject
> > +Maintainers may remove, edit, or reject
> > comments, commits, code, wiki edits, issues, and other contributions that
> > are
> > not aligned to this Code
On Wed, Oct 10, 2018 at 04:25:01PM +0200, Lubomir Rintel wrote:
> This is a device-tree enabled driver. Moreover CONFIG_OLPC is specific
> to the x86 platform code, while the driver is for an ARM-based laptop.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/input/serio/Kconfig | 2 +-
> 1
On Wed, Oct 10, 2018 at 04:25:01PM +0200, Lubomir Rintel wrote:
> This is a device-tree enabled driver. Moreover CONFIG_OLPC is specific
> to the x86 platform code, while the driver is for an ARM-based laptop.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/input/serio/Kconfig | 2 +-
> 1
On Wed, Oct 10, 2018 at 04:41:16PM +0800, Chao Fan wrote:
> In the earliest time, I tried to dig ACPI tabls to solve this problem.
> But I didn't splite the code in 'compressed/' and ACPI code, so the patch
> is hard to follow so refused by community.
> Somebody suggest to add a kernel parameter
On Wed, Oct 10, 2018 at 04:41:16PM +0800, Chao Fan wrote:
> In the earliest time, I tried to dig ACPI tabls to solve this problem.
> But I didn't splite the code in 'compressed/' and ACPI code, so the patch
> is hard to follow so refused by community.
> Somebody suggest to add a kernel parameter
(to: get_maintainers -f include/linux/bitfield.h)
Hi,
I would like to use FIELD_PREP() macro for assigning a static array,
like this:
function()
{
static u32 val[2] = {FIELD_PREP(GENMASK_ULL(10, 0), 5), 0};
}
However the compiler complains of non-const expression:
(to: get_maintainers -f include/linux/bitfield.h)
Hi,
I would like to use FIELD_PREP() macro for assigning a static array,
like this:
function()
{
static u32 val[2] = {FIELD_PREP(GENMASK_ULL(10, 0), 5), 0};
}
However the compiler complains of non-const expression:
On Wed, Oct 10, 2018 at 10:10:13AM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 10, 2018 at 04:25:04PM +0200, Lubomir Rintel wrote:
> > Take the GPIO lines are used by the SP. The driver doesn't touch the
> > lines -- this is done to disallow anything else from fiddling with
> > them because that
On Wed, Oct 10, 2018 at 10:10:13AM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 10, 2018 at 04:25:04PM +0200, Lubomir Rintel wrote:
> > Take the GPIO lines are used by the SP. The driver doesn't touch the
> > lines -- this is done to disallow anything else from fiddling with
> > them because that
This spares drivers from #ifdef-ing on CONFIG_PCI if the driver can be
optionally built on machines without PCI bus.
Consistent with acpi_driver_match_device() and similar.
Acked-by: Bjorn Helgaas
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Capitalization in the commit message
This spares drivers from #ifdef-ing on CONFIG_PCI if the driver can be
optionally built on machines without PCI bus.
Consistent with acpi_driver_match_device() and similar.
Acked-by: Bjorn Helgaas
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Capitalization in the commit message
This is used to indicate that the chip attached to this controller is a SPI
master.
Signed-off-by: Lubomir Rintel
---
Documentation/devicetree/bindings/spi/spi-pxa2xx.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-pxa2xx.txt
Some drivers, such as spi-pxa2xx return from the transfer_one callback
immediately, idicating that the transfer will be finished asynchronously.
Normally, spi_transfer_one_message() synchronously waits for the
transfer to finish with wait_for_completion_timeout(). For slaves, we
don't want the
On Wed, Oct 10, 2018 at 04:25:04PM +0200, Lubomir Rintel wrote:
> Take the GPIO lines are used by the SP. The driver doesn't touch the
> lines -- this is done to disallow anything else from fiddling with
> them because that would confuse the SP firmware.
>
> Also, the lines are now nicely visible
This is used to indicate that the chip attached to this controller is a SPI
master.
Signed-off-by: Lubomir Rintel
---
Documentation/devicetree/bindings/spi/spi-pxa2xx.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-pxa2xx.txt
Some drivers, such as spi-pxa2xx return from the transfer_one callback
immediately, idicating that the transfer will be finished asynchronously.
Normally, spi_transfer_one_message() synchronously waits for the
transfer to finish with wait_for_completion_timeout(). For slaves, we
don't want the
On Wed, Oct 10, 2018 at 04:25:04PM +0200, Lubomir Rintel wrote:
> Take the GPIO lines are used by the SP. The driver doesn't touch the
> lines -- this is done to disallow anything else from fiddling with
> them because that would confuse the SP firmware.
>
> Also, the lines are now nicely visible
This this is used to let the SPI master know that our FIFO is filled and
we're ready to service a transfer. Only useful in slave mode.
A signal like this is used by an embedded controller on a OLPC XO 1.75
machine, that happens to be a SPI master.
Signed-off-by: Lubomir Rintel
---
There doesn't seem to be a way to empty TXFIFO on MMP2. The datasheet is
super-secret and the method described in Armada 16x manual won't work:
"The TXFIFO and RXFIFO are cleared to 0b0 when the SSPx port is reset or
disabled (by writing a 0b0 to the field
in the SSP Control Register 0)."
Tested on an OLPC XO-1.75 machine, where the Embedded Controller happens
to be a SPI master.
Signed-off-by: Lubomir Rintel
---
drivers/spi/spi-pxa2xx.c | 81 +++---
include/linux/spi/pxa2xx_spi.h | 1 +
2 files changed, 75 insertions(+), 7 deletions(-)
diff
Tested on an OLPC XO-1.75 machine, where the Embedded Controller happens
to be a SPI master.
Signed-off-by: Lubomir Rintel
---
drivers/spi/spi-pxa2xx.c | 81 +++---
include/linux/spi/pxa2xx_spi.h | 1 +
2 files changed, 75 insertions(+), 7 deletions(-)
diff
This this is used to let the SPI master know that our FIFO is filled and
we're ready to service a transfer. Only useful in slave mode.
A signal like this is used by an embedded controller on a OLPC XO 1.75
machine, that happens to be a SPI master.
Signed-off-by: Lubomir Rintel
---
There doesn't seem to be a way to empty TXFIFO on MMP2. The datasheet is
super-secret and the method described in Armada 16x manual won't work:
"The TXFIFO and RXFIFO are cleared to 0b0 when the SSPx port is reset or
disabled (by writing a 0b0 to the field
in the SSP Control Register 0)."
601 - 700 of 1504 matches
Mail list logo
