Main updates from version V14[1]:
Fix Rename missing load() to load_segments() in pru_rproc.c.
Main updates from version V13[2]:
- Introduce new rproc_ops operation: load_fw() and release_fw(),
- Rename load() operation to load_segments() in rproc_ops structure and
drivers.
More details are ava
Main updates from version V13[1]:
- Introduce new rproc_ops operation: load_fw() and release_fw(),
- Rename load() operation to load_segments() in rproc_ops structure and
drivers.
More details are available in each patch commit message.
[1]
https://lore.kernel.org/linux-arm-kernel/202411041335
Main updates from version V12[1]:
Fix warning build by fixing the inline declaration in
remoteproc_tee.h (when CONFIG_REMOTEPROC_TEE is not set).
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202410262040.pwnrkv2q-...@intel.com/
Main updates from version V11[2]:
-
Main updates from version V11[1]:
- rename structures, functions, and variables from "tee_rproc_xxx" to
"rproc_tee_xxx",
- update rproc_tee_register to return an error instead of
"struct rproc_tee *" pointer
[1] https://lore.kernel.org/lkml/ZxZ4cBilIlpf3IPw@p14s/T/
Tested-on: 42f7652d3eb
Main updates from version V10[1]:
- remove "select REMOTEPROC_TEE" in STM32_RPROC config to fix kernel robot
To keep history of the updates I have kept in each patches the description
of the updates versus the V9[2] revision.
Main updates from version V9[2]:
- Introduce release_fw remoteproc
Main updates from version V9[1]:
- Introduce release_fw remoteproc ops to avoid direct call of
tee_rproc_release_fw() in remoteproc_core.c:
- allow to remove link between remoteproc and remoteproc_tee
- allow to build the remoteproc_tee as a module
[1] https://lore.kernel.org/linux-arm-kern
Main updates from version V8[1]:
Add support for tee_rproc_release_fw(), which allows releasing firmware
that has been loaded. This service is used if an error occurs between
the loading of the firmware image and the start of the remote processor.
It is also called on remote processor shutdown.
A
Main updates from version V7[1]
Update the series based on Mathieu Poirier's comments.
Details of the updates are listed in the commit messages of the patches.
[1]
https://lore.kernel.org/linux-arm-kernel/20240611073904.475019-1-arnaud.pouliq...@foss.st.com/
base-commit: 1613e604df0cd359cf2a7fb
table
physical address to virtual address based on remoteproc carveouts.
2) Merge the 2 "st,stm32-rproc.yaml" bindings patch in one
As the st,rproc-id" is linked to the introduction of the
"st,stm32mp1-m4-tee" compatible, merge following patches to add
roc-id" is linked to the introduction of the
"st,stm32mp1-m4-tee" compatible, merge following patches to address
Krzysztof concern.
- [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for TEE support
- [PATCH v5 3/7] dt-bindings: remoteproc: Add processor identifier
Main updates from the previous version [1]:
--
1) use proc->table_ptr as unique reference to point to the resource table
--> update remoteproc_core.c to implement management of the resource table
base on rproc->rproc->tee_interface new field:
- on
Main updates from the previous version [1]:
--
1) use proc->table_ptr as unique reference to point to the resource table
--> update remoteproc_core.c to implement management of the resource table
base on rproc->rproc->tee_interface new field:
- on
Main updates from the previous version [1]:
- Remove the alternate boot sequence: rproc_alt_fw_boot()
- Introduce tee_rproc_parse_fw function
- create a cached table as done inrproc_elf_load_rsc_table[2],
- PR sent to OP-TEE to allow TA_RPROC_FW_CMD_LOAD_FW service
re-en
On 2/22/24 10:55, Naman Jain wrote:
> On 2/22/2024 2:17 PM, Arnaud POULIQUEN wrote:
>> Hello Naman,
>>
>> On 2/22/24 06:43, Naman Jain wrote:
>>> On 2/14/2024 10:51 PM, Arnaud Pouliquen wrote:
Updates from the previous version [1]:
This version proposes another approach based on a
On 2/22/2024 2:17 PM, Arnaud POULIQUEN wrote:
Hello Naman,
On 2/22/24 06:43, Naman Jain wrote:
On 2/14/2024 10:51 PM, Arnaud Pouliquen wrote:
Updates from the previous version [1]:
This version proposes another approach based on an alternate load and boot
of the coprocessor. Therefore, the co
Hello Naman,
On 2/22/24 06:43, Naman Jain wrote:
> On 2/14/2024 10:51 PM, Arnaud Pouliquen wrote:
>> Updates from the previous version [1]:
>>
>> This version proposes another approach based on an alternate load and boot
>> of the coprocessor. Therefore, the constraint introduced by tee_remoteproc
On 2/14/2024 10:51 PM, Arnaud Pouliquen wrote:
Updates from the previous version [1]:
This version proposes another approach based on an alternate load and boot
of the coprocessor. Therefore, the constraint introduced by tee_remoteproc
is that the firmware has to be authenticated and loaded befo
Updates from the previous version [1]:
This version proposes another approach based on an alternate load and boot
of the coprocessor. Therefore, the constraint introduced by tee_remoteproc
is that the firmware has to be authenticated and loaded before the resource
table can be obtained.
The exist
Updates from the previous version [1]
- fix issues reported by kernel test robot,
- address Rob Herring comment on bindings.
[1]
https://lore.kernel.org/linux-arm-kernel/20240115135249.296822-1-arnaud.pouliq...@foss.st.com/T/
This series proposes the implementation of a remoteproc tee driver to
This series proposes the implementation of a remoteproc tee driver to
communicate with a TEE trusted application responsible for authenticating and
loading the remoteproc firmware image in an Arm secure context.
1) Principle:
The remoteproc tee driver provides services to communicate with the OP-
x-asp...@lists.ozlabs.org;
linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-...@vger.kernel.org
Subject: Re: [PATCH v29 0/6] JTAG driver introduction
Hi Andy,
On Tue, Apr 06, 2021 at 04:22:04PM +0300, Andy Shevchenko wrote:
> On Fri, Jan 15, 2021 at 01:46:35PM +0300, Paul Ferts
Hi Andy,
On Tue, Apr 06, 2021 at 04:22:04PM +0300, Andy Shevchenko wrote:
> On Fri, Jan 15, 2021 at 01:46:35PM +0300, Paul Fertser wrote:
> > I have to note that the current v29 version of the series is broken in
> > several aspects:
>
> Is it correct that this series is actually abandoned so fa
On Fri, Jan 15, 2021 at 01:46:35PM +0300, Paul Fertser wrote:
> Hello,
>
> This is a multi-part review of the series, with general notes inline
> in this message, and specific points raised as replies to the
> individual patches.
>
> On Mon, Apr 13, 2020 at 03:29:14PM -0700, Ernesto Corona wrote:
This serie introduces the 4KOpen (stih418-b2264) board based
on a stih418 soc. Since it is the first board to use the spi-fsm
SPI NOR controller available since stih407, the controller is
also added within the stih407-family DT.
It also contains a fix within the stih418 DT since the rng11 is not
av
your e-mail contact prior to a private search while in
need of your assistance.
INTRODUCTION: Am Mr Ali Musa a Banker and in one way or the other was
hoping you will cooperate with me as a partner in a project of
transferring an abandoned fund of a late customer of the bank worth of
$18,000,000
your e-mail contact prior to a private search while in
need of your assistance.
INTRODUCTION: Am Mr Ali Musa a Banker and in one way or the other was
hoping you will cooperate with me as a partner in a project of
transferring an abandoned fund of a late customer of the bank worth of
$18,000,000
On 2020-12-09 06:09, Jianyong Wu wrote:
PTP_KVM implementation depends on hypercall using SMCCC. So we
introduce a new SMCCC service ID. This doc explains how does the
ID define and how does PTP_KVM works on arm/arm64.
Signed-off-by: Jianyong Wu
---
Documentation/virt/kvm/api.rst | 9
This serie introduces the 4KOpen (stih418-b2264) board based
on a stih418 soc. Since it is the first board to use the spi-fsm
SPI NOR controller available since stih407, the controller is
also added within the stih407-family DT.
It also contains a fix within the stih418 DT since the rng11 is not
av
This serie introduces the 4KOpen (stih418-b2264) board based
on a stih418 soc. Since it is the first board to use the spi-fsm
SPI NOR controller available since stih407, the controller is
also added within the stih407-family DT.
It also contains a fix within the stih418 DT since the rng11 is not
av
Hello,
This is a multi-part review of the series, with general notes inline
in this message, and specific points raised as replies to the
individual patches.
On Mon, Apr 13, 2020 at 03:29:14PM -0700, Ernesto Corona wrote:
> We propose to implement general JTAG interface and infrastructure
> to co
PTP_KVM implementation depends on hypercall using SMCCC. So we
introduce a new SMCCC service ID. This doc explains how does the
ID define and how does PTP_KVM works on arm/arm64.
Signed-off-by: Jianyong Wu
---
Documentation/virt/kvm/api.rst | 9 +++
Documentation/virt/kvm/arm/index.
ject: Re: [PATCH v15 8/9] doc: add ptp_kvm introduction for arm64
> support
>
> On 2020-11-11 06:22, Jianyong Wu wrote:
> > PTP_KVM implementation depends on hypercall using SMCCC. So we
> > introduce a new SMCCC service ID. This doc explains how does the ID
> > define and ho
On 2020-11-11 06:22, Jianyong Wu wrote:
PTP_KVM implementation depends on hypercall using SMCCC. So we
introduce a new SMCCC service ID. This doc explains how does the
ID define and how does PTP_KVM works on arm/arm64.
Signed-off-by: Jianyong Wu
---
Documentation/virt/kvm/api.rst | 9
PTP_KVM implementation depends on hypercall using SMCCC. So we
introduce a new SMCCC service ID. This doc explains how does the
ID define and how does PTP_KVM works on arm/arm64.
Signed-off-by: Jianyong Wu
---
Documentation/virt/kvm/api.rst | 9 +++
Documentation/virt/kvm/arm/index.
(+ intel-gfx for being i915 related)
(+ Chris who has looked into the issue)
Hi,
Thanks for reporting!
Could you open a bug report according to following instructions:
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
A full dmesg of a bad boot and git bisect logs will be
Quoting Joonas Lahtinen (2020-09-29 09:18:34)
> (+ intel-gfx for being i915 related)
> (+ Chris who has looked into the issue)
>
> Hi,
>
> Thanks for reporting!
Fixed in commit a4d63c3732f1a0c91abcf5b7f32b4ef7dcd82025
Author: Jason A. Donenfeld
Date: Mon Sep 28 12:35:07 2020 +0200
mm: do
On Mon, Sep 28, 2020 at 02:14:16PM -0400, Tony Fischetti wrote:
> After a length git bisection, I determined the commit that introduced
> a change that ultimately caused a bug/oops null dereference (see below
> for relevant syslog entries) was 008cfe4418b3dbda2ff.. (mm: Introduce
> mm_struct.has_pi
After a length git bisection, I determined the commit that introduced
a change that ultimately caused a bug/oops null dereference (see below
for relevant syslog entries) was 008cfe4418b3dbda2ff.. (mm: Introduce
mm_struct.has_pinned)
The RIP (according to syslog) occurs in function
`__get_user_page
Hi Jacopo,
thanks for reviewing.
On 15/09/20 15:34, Jacopo Mondi wrote:
> Hi Luca,
>
> On Fri, Sep 04, 2020 at 11:51:41PM +0200, Luca Ceresoli wrote:
>> This paragraph provides generic information to explain what v4l2_subdev is
>> useful for. Placing it in the middle of paragraphs describing the
On Tue, Sep 15, 2020 at 11:11:30AM +0200, Alain Volmat wrote:
> Commit 68302245720a ("i2c: stm32f7: Add SMBus Host-Notify protocol support")
> added a new slot specific for handling host-notify however failed
> to update the previous slot ID leading to having the 7bit address
> only slot with the w
Hi Luca,
On Fri, Sep 04, 2020 at 11:51:41PM +0200, Luca Ceresoli wrote:
> This paragraph provides generic information to explain what v4l2_subdev is
> useful for. Placing it in the middle of paragraphs describing the details
> of subdev registration does not make much sense. Move it near the begin
Commit 68302245720a ("i2c: stm32f7: Add SMBus Host-Notify protocol support")
added a new slot specific for handling host-notify however failed
to update the previous slot ID leading to having the 7bit address
only slot with the wrong number.
Signed-off-by: Alain Volmat
---
drivers/i2c/busses/i2c
com;
> richardcoch...@gmail.com; Mark Rutland ;
> w...@kernel.org; Suzuki Poulose ; Steven Price
> ; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
> k...@vger.kernel.org; Steve Capper ; Justin He
> ; nd
> Subject: Re: [PATCH v14 0
This paragraph provides generic information to explain what v4l2_subdev is
useful for. Placing it in the middle of paragraphs describing the details
of subdev registration does not make much sense. Move it near the beginning
of the section when the v4l2_subdev idea has just been introduced and
befo
On Fri, 04 Sep 2020 10:27:43 +0100,
Jianyong Wu wrote:
>
> ptp_kvm implementation depends on hypercall using SMCCC. So we
> introduce a new SMCCC service ID. This doc explain how we define
> and use this new ID.
>
> Signed-off-by: Jianyong Wu
> ---
> Documentation/virt/kvm/arm/ptp_kvm.rst | 72
ptp_kvm implementation depends on hypercall using SMCCC. So we
introduce a new SMCCC service ID. This doc explain how we define
and use this new ID.
Signed-off-by: Jianyong Wu
---
Documentation/virt/kvm/arm/ptp_kvm.rst | 72 ++
1 file changed, 72 insertions(+)
create mod
Add documentation for introduction to
-context-switch
-x86 context-switch
-MIPS context switch
Suggested-by: Lukas Bulwahn
Co-developed-by: Mostafa Chamanara
Signed-off-by: Mostafa Chamanara
Co-developed-by: Oleg Tsymbal
Signed-off-by: Oleg Tsymbal
Signed-off-by: John Mathew
From: Al Viro
Two new helpers: given a process and regset, dump into a buffer.
regset_get() takes a buffer and size, regset_get_alloc() takes size
and allocates a buffer.
Return value in both cases is the amount of data actually dumped in
case of success or -E... on error.
In both cases the si
On Fri, Jun 19, 2020 at 04:40:46PM -0600, Alex Williamson wrote:
> On Tue, 9 Jun 2020 20:37:31 -0400
> Yan Zhao wrote:
>
> > On Fri, Jun 05, 2020 at 03:39:50PM +0100, Dr. David Alan Gilbert wrote:
> > > > > > I tried to simplify the problem a bit, but we keep going backwards.
> > > > > > If
> >
On Tue, 9 Jun 2020 20:37:31 -0400
Yan Zhao wrote:
> On Fri, Jun 05, 2020 at 03:39:50PM +0100, Dr. David Alan Gilbert wrote:
> > > > > I tried to simplify the problem a bit, but we keep going backwards.
> > > > > If
> > > > > the requirement is that potentially any source device can migrate to
On Fri, Jun 05, 2020 at 03:39:50PM +0100, Dr. David Alan Gilbert wrote:
> > > > I tried to simplify the problem a bit, but we keep going backwards. If
> > > > the requirement is that potentially any source device can migrate to any
> > > > target device and we cannot provide any means other than w
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Fri, 5 Jun 2020 11:22:24 +0100
> "Dr. David Alan Gilbert" wrote:
>
> > * Alex Williamson (alex.william...@redhat.com) wrote:
> > > On Wed, 3 Jun 2020 01:24:43 -0400
> > > Yan Zhao wrote:
> > >
> > > > On Tue, Jun 02, 2020 at 09:55:28P
On Fri, 5 Jun 2020 11:22:24 +0100
"Dr. David Alan Gilbert" wrote:
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > On Wed, 3 Jun 2020 01:24:43 -0400
> > Yan Zhao wrote:
> >
> > > On Tue, Jun 02, 2020 at 09:55:28PM -0600, Alex Williamson wrote:
> > > > On Tue, 2 Jun 2020 23:19:48
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Wed, 3 Jun 2020 01:24:43 -0400
> Yan Zhao wrote:
>
> > On Tue, Jun 02, 2020 at 09:55:28PM -0600, Alex Williamson wrote:
> > > On Tue, 2 Jun 2020 23:19:48 -0400
> > > Yan Zhao wrote:
> > >
> > > > On Tue, Jun 02, 2020 at 04:55:27PM -06
From: John Mathew
Add documentation for introduction to
-context-switch
-x86 context-switch
-MIPS context switch
Suggested-by: Lukas Bulwahn
Co-developed-by: Mostafa Chamanara
Signed-off-by: Mostafa Chamanara
Co-developed-by: Oleg Tsymbal
Signed-off-by: Oleg Tsymbal
Signed-off-by: John
On Wed, 3 Jun 2020 01:24:43 -0400
Yan Zhao wrote:
> On Tue, Jun 02, 2020 at 09:55:28PM -0600, Alex Williamson wrote:
> > On Tue, 2 Jun 2020 23:19:48 -0400
> > Yan Zhao wrote:
> >
> > > On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> > > > On Wed, 29 Apr 2020 20:39:50 -040
On Tue, Jun 02, 2020 at 09:55:28PM -0600, Alex Williamson wrote:
> On Tue, 2 Jun 2020 23:19:48 -0400
> Yan Zhao wrote:
>
> > On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> > > On Wed, 29 Apr 2020 20:39:50 -0400
> > > Yan Zhao wrote:
> > >
> > > > On Wed, Apr 29, 2020 at 05
On Tue, 2 Jun 2020 23:19:48 -0400
Yan Zhao wrote:
> On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> > On Wed, 29 Apr 2020 20:39:50 -0400
> > Yan Zhao wrote:
> >
> > > On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Alan Gilbert wrote:
> > >
> > > > > > > > > > > > >
On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> On Wed, 29 Apr 2020 20:39:50 -0400
> Yan Zhao wrote:
>
> > On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Alan Gilbert wrote:
> >
> > > > > > > > > > > > > > > An mdev type is meant to define a software
> > > > > > > > > >
On Wed, 29 Apr 2020 20:39:50 -0400
Yan Zhao wrote:
> On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Alan Gilbert wrote:
>
> > > > > > > > > > > > > > An mdev type is meant to define a software
> > > > > > > > > > > > > > compatible interface, so in
> > > > > > > > > > > > > > the case of m
From: John Mathew
Add documentation for introduction to
-context-switch
-x86 context-switch
-MIPS context switch
Suggested-by: Lukas Bulwahn
Co-developed-by: Mostafa Chamanara
Signed-off-by: Mostafa Chamanara
Co-developed-by: Oleg Tsymbal
Signed-off-by: Oleg Tsymbal
Signed-off-by: John
On Tue, May 26, 2020 at 1:26 PM Srikar Dronamraju
wrote:
>
> * john mathew [2020-05-14 12:26:37]:
>
> > +
> > +Context Switching
> > +-
> > +
> > +Context switching, the switching from a running task to another,
> > +is done by the context_switch() function defined in kernel/sched
From: John Mathew
Add documentation for introduction to
-context-switch
-x86 context-switch
-MIPS context switch
Suggested-by: Lukas Bulwahn
Co-developed-by: Mostafa Chamanara
Signed-off-by: Mostafa Chamanara
Co-developed-by: Oleg Tsymbal
Signed-off-by: Oleg Tsymbal
Signed-off-by: John
* john mathew [2020-05-14 12:26:37]:
> +
> +Context Switching
> +-
> +
> +Context switching, the switching from a running task to another,
> +is done by the context_switch() function defined in kernel/sched.c.
context_switch is defined in kernel/sched/core.c
> +It is called by
From: John Mathew
Add documentation for introduction to
-context-switch
-x86 context-switch
-MIPS context switch
Suggested-by: Lukas Bulwahn
Co-developed-by: Mostafa Chamanara
Signed-off-by: Mostafa Chamanara
Co-developed-by: Oleg Tsymbal
Signed-off-by: Oleg Tsymbal
Signed-off-by: John
From: John Mathew
Add documentation for introduction to
-context-switch
-x86 context-switch
-MIPS context switch
Suggested-by: Lukas Bulwahn
Co-developed-by: Mostafa Chamanara
Signed-off-by: Mostafa Chamanara
Co-developed-by: Oleg Tsymbal
Signed-off-by: Oleg Tsymbal
Signed-off-by: John
Add documentation for introduction to
-context-switch
-x86 context-switch
-MIPS context switch
Suggested-by: Lukas Bulwahn
Co-developed-by: Mostafa Chamanara
Signed-off-by: Mostafa Chamanara
Co-developed-by: Oleg Tsymbal
Signed-off-by: Oleg Tsymbal
Signed-off-by: John Mathew
On 5/6/20 7:39 AM, john mathew wrote:
> From: John Mathew
>
> Add documentation for introduction to
> -context-switch
> -x86 context-switch
> -MIPS context switch
>
> Suggested-by: Lukas Bulwahn
> Co-developed-by: Mostafa Chamanara
> Signed-off-by: Mostaf
From: John Mathew
Add documentation for introduction to
-context-switch
-x86 context-switch
-MIPS context switch
Suggested-by: Lukas Bulwahn
Co-developed-by: Mostafa Chamanara
Signed-off-by: Mostafa Chamanara
Co-developed-by: Oleg Tsymbal
Signed-off-by: Oleg Tsymbal
Signed-off-by: John
On Wed, Apr 29, 2020 at 10:13:01PM +0800, Eric Blake wrote:
> [meta-comment]
>
> On 4/29/20 4:35 AM, Yan Zhao wrote:
> > On Wed, Apr 29, 2020 at 04:22:01PM +0800, Dr. David Alan Gilbert wrote:
> [...]
> > This patchset introduces a migration_version attribute
> > u
On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Alan Gilbert wrote:
> > > > > > > > > > > > > An mdev type is meant to define a software compatible
> > > > > > > > > > > > > interface, so in
> > > > > > > > > > > > > the case of mdev->mdev migration, doesn't migrating
> > > > > > > > > > > >
[meta-comment]
On 4/29/20 4:35 AM, Yan Zhao wrote:
On Wed, Apr 29, 2020 at 04:22:01PM +0800, Dr. David Alan Gilbert wrote:
[...]
This patchset introduces a migration_version attribute under sysfs
of VFIO
Mediated devices.
Hmm, several pages with up to 16 levels of quoting, with editors mak
* Yan Zhao (yan.y.z...@intel.com) wrote:
> On Wed, Apr 29, 2020 at 04:22:01PM +0800, Dr. David Alan Gilbert wrote:
> > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > On Tue, Apr 28, 2020 at 10:14:37PM +0800, Dr. David Alan Gilbert wrote:
> > > > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > > > On
On Wed, Apr 29, 2020 at 04:22:01PM +0800, Dr. David Alan Gilbert wrote:
> * Yan Zhao (yan.y.z...@intel.com) wrote:
> > On Tue, Apr 28, 2020 at 10:14:37PM +0800, Dr. David Alan Gilbert wrote:
> > > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > > On Mon, Apr 27, 2020 at 11:37:43PM +0800, Dr. David A
* Yan Zhao (yan.y.z...@intel.com) wrote:
> On Tue, Apr 28, 2020 at 10:14:37PM +0800, Dr. David Alan Gilbert wrote:
> > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > On Mon, Apr 27, 2020 at 11:37:43PM +0800, Dr. David Alan Gilbert wrote:
> > > > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > > > On
On Tue, Apr 28, 2020 at 10:14:37PM +0800, Dr. David Alan Gilbert wrote:
> * Yan Zhao (yan.y.z...@intel.com) wrote:
> > On Mon, Apr 27, 2020 at 11:37:43PM +0800, Dr. David Alan Gilbert wrote:
> > > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > > On Sat, Apr 25, 2020 at 03:10:49AM +0800, Dr. David A
On Tue, Apr 28, 2020 at 04:52:07PM -0700, Paul E. McKenney wrote:
> On Tue, Apr 28, 2020 at 04:50:48PM -0700, Paul E. McKenney wrote:
> > On Tue, Apr 28, 2020 at 06:21:30PM -0400, Sal Carrasco wrote:
> > > Hi Paul,
> > >
> > > As for the stalls, we've seen them either be self-detected or detected
On Tue, Apr 28, 2020 at 04:50:48PM -0700, Paul E. McKenney wrote:
> On Tue, Apr 28, 2020 at 06:21:30PM -0400, Sal Carrasco wrote:
> > Hi Paul,
> >
> > As for the stalls, we've seen them either be self-detected or detected by
> > another CPU on the system. We've also seen stalls in various
> > situ
On Tue, Apr 28, 2020 at 06:21:30PM -0400, Sal Carrasco wrote:
> Hi Paul,
>
> As for the stalls, we've seen them either be self-detected or detected by
> another CPU on the system. We've also seen stalls in various
> situations where we remove ebtables out of the equation which I think
> validates
* Yan Zhao (yan.y.z...@intel.com) wrote:
> On Mon, Apr 27, 2020 at 11:37:43PM +0800, Dr. David Alan Gilbert wrote:
> > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > On Sat, Apr 25, 2020 at 03:10:49AM +0800, Dr. David Alan Gilbert wrote:
> > > > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > > > On
On Fri, 11 Oct 2019 16:43:43 +0200
Miquel Raynal wrote:
> Maxim's max1027/29/31 series returns the measured voltages with a
> resolution of 10 bits. There is a very similar series, max1227/29/31
> which works identically but uses a resolution of 12 bits. Prepare the
> support for these chips by t
Maxim's max1027/29/31 series returns the measured voltages with a
resolution of 10 bits. There is a very similar series, max1227/29/31
which works identically but uses a resolution of 12 bits. Prepare the
support for these chips by turning the 'depth' into a macro parameter
instead of hardcoding it
Maxim's max1027/29/31 series returns the measured voltages with a
resolution of 10 bits. There is a very similar series, max1227/29/31
which works identically but uses a resolution of 12 bits. Prepare the
support for these chips by turning the 'depth' into a macro parameter
instead of hardcoding it
Hi Jonathan,
> >
> > +#define MAX1X27_CHANNELS(depth)\
> > + MAX1027_T_CHAN, \
> > + MAX1027_V_CHAN(0, depth), \
> > + MAX1027_V_CHAN(1, depth), \
> > + MAX1027_V_CHAN(2, depth), \
> > + MAX1027_V_CHA
On Thu, 3 Oct 2019 19:33:58 +0200
Miquel Raynal wrote:
> Maxim's max1027/29/31 series returns the measured voltages with a
> resolution of 10 bits. There is a very similar series, max1227/29/31
> which works identically but uses a resolution of 12 bits. Prepare the
> support for these chips by t
Maxim's max1027/29/31 series returns the measured voltages with a
resolution of 10 bits. There is a very similar series, max1227/29/31
which works identically but uses a resolution of 12 bits. Prepare the
support for these chips by turning the 'depth' into a macro parameter
instead of hardcoding it
Hello,
Miquel Raynal wrote on Wed, 2 Oct 2019
14:30:22 +0200:
> Maxim's max1027/29/31 series returns the measured voltages with a
> resolution of 10 bits. There is a very similar series, max1227/29/31
> which works very similarly but uses a resolution of 12 bits. Prepare
> the support for these
Maxim's max1027/29/31 series returns the measured voltages with a
resolution of 10 bits. There is a very similar series, max1227/29/31
which works very similarly but uses a resolution of 12 bits. Prepare
the support for these chips by turning the 'depth' into a macro
parameter instead of hardcoding
On Mon, 24 Jun 2019, Dan Murphy wrote:
> Lee
>
> On 6/24/19 9:42 AM, Lee Jones wrote:
> > On Wed, 05 Jun 2019, Dan Murphy wrote:
> >
> > > Hello
> > >
> > > The v5 patchset missed adding in the new validation code.
> > > Patch 1 of the v5 series was squashed into patch 4 of the v5 series.
> > >
Lee
On 6/24/19 9:42 AM, Lee Jones wrote:
On Wed, 05 Jun 2019, Dan Murphy wrote:
Hello
The v5 patchset missed adding in the new validation code.
Patch 1 of the v5 series was squashed into patch 4 of the v5 series.
So this will reduce the patchset by 1.
Sorry for the extra noise on the patchse
On Wed, 05 Jun 2019, Dan Murphy wrote:
> Hello
>
> The v5 patchset missed adding in the new validation code.
> Patch 1 of the v5 series was squashed into patch 4 of the v5 series.
> So this will reduce the patchset by 1.
>
> Sorry for the extra noise on the patchsets. The change was lost when I
Jacek
Reviewed and tested the updated branch. Looks good to me.
Dan
On 6/5/19 2:31 PM, Jacek Anaszewski wrote:
Hi Dan,
Thank you for the v6.
Patches 4/5 and 5/5 don't contain amendments I made to
the respective patches on the ib-leds-mfd-regulator branch
(that address issues raised by Pavel
Hi Dan,
Thank you for the v6.
Patches 4/5 and 5/5 don't contain amendments I made to
the respective patches on the ib-leds-mfd-regulator branch
(that address issues raised by Pavel), so I just kept those
unchanged. Besides that I updated the remaining ones.
Please check the ib-leds-mfd-regulato
Hello
The v5 patchset missed adding in the new validation code.
Patch 1 of the v5 series was squashed into patch 4 of the v5 series.
So this will reduce the patchset by 1.
Sorry for the extra noise on the patchsets. The change was lost when I
converted
the patches from the mainline branch to th
Hello
This is v5 of the patchset. There is only one patch that has changed in the
series and that is the regulator: lm363x: Add support for LM36274 patch. This
patch was updated to add flexibility in setting the bit to enable GPIO regulator
control.
This change was made on top of the branch
re
On Tue, Jun 04, 2019 at 03:29:32AM +0800, Alex Williamson wrote:
> On Thu, 30 May 2019 20:44:38 -0400
> Yan Zhao wrote:
>
> > This patchset introduces a migration_version attribute under sysfs of VFIO
> > Mediated devices.
> >
> > This migration_version attribute is used to check migration compa
Hello
This is patch set v4 for the LM36274. There were no changes made
to this patch set except to rebase this on top of the latest TI LMU common code
patchset.
This patch set was rebased on the series at:
https://lore.kernel.org/patchwork/project/lkml/list/?series=393071
Dan
Dan Murphy (6):
Jacek
On 5/22/19 2:37 PM, Jacek Anaszewski wrote:
> Hi Dan,
>
> On 5/22/19 9:27 PM, Dan Murphy wrote:
>> Hello
>>
>> This is patch set v4 for the LM36274. There were no changes made
>> to this patch set except to rebase this on top of the latest TI LMU common
>> code
>> patchset.
>
> Why the r
Hi Dan,
On 5/22/19 9:27 PM, Dan Murphy wrote:
Hello
This is patch set v4 for the LM36274. There were no changes made
to this patch set except to rebase this on top of the latest TI LMU common code
patchset.
Why the rebase was needed? leds-lm36274.c was already including
leds-ti-lmu-common.h.
I need acks from regulator framework maintainer for patches
1/6 and 4/6.
Adding Liam and Mark.
On 5/7/19 10:11 PM, Dan Murphy wrote:
Hello
This is patch set v4 for the LM36274. There were no changes made
to this patch set except to rebase this on top of the latest TI LMU common code
patchset.
1 - 100 of 362 matches
Mail list logo
