> >>
> >> A nit, subject: drop second/last, redundant "binding for". The
> >> "dt-bindings" prefix is already stating that these are bindings.
> >> See also:
> >> https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/
t;dt-bindings" prefix is already stating that these are bindings.
>> See also:
>> https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>>
>>>
>>> Add a dt-binding for the Microchip IPC Remoteproc platform drive
inux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
>>
>> Add a dt-binding for the Microchip IPC Remoteproc platform driver.
>>
>
> Binding is for hardware, not driver. Please rephrase it to describe
> hardware.
>
>
On 18/09/2024 17:51, valentina.fernandezala...@microchip.com wrote:
> On 16/09/2024 21:18, Krzysztof Kozlowski wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> On 12/09/2024 19:00, Valentina Fernandez wrote:
>>> The Microchip family of R
na Fernandez wrote:
> > > > Add a dt-binding for the Microchip Inter-Processor Communication (IPC)
> > > > mailbox controller.
> > > >
> > > > Signed-off-by: Valentina Fernandez
> > > >
> > > > ---
> > > > .../bindi
On 16/09/2024 21:18, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 12/09/2024 19:00, Valentina Fernandez wrote:
>> The Microchip family of RISC-V SoCs typically has one or more clusters.
>> These clusters can be co
On Mon, Sep 16, 2024 at 05:31:36PM +0100, Conor Dooley wrote:
> On Thu, Sep 12, 2024 at 04:23:44PM -0500, Samuel Holland wrote:
> > Hi Valentina,
> >
> > On 2024-09-12 12:00 PM, Valentina Fernandez wrote:
> > > Add a dt-binding for the Microchip Inter-Processor Com
On Tue, Sep 17, 2024 at 10:45:02AM +,
valentina.fernandezala...@microchip.com wrote:
> On 16/09/2024 23:28, Bo Gan wrote:
> > Perhaps checking-in
> > the microchip SBI extensions to major SBI implementations such as openSBI
> > first would be better?
It's worth pointing out that the "major SB
On 16/09/2024 23:28, Bo Gan wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> the content is safe
>
> Hi Valentina,
Hi Bo,
>
> On 9/12/24 10:00, Valentina Fernandez wrote:
>> Additional details on the Microchip vendor extension and
Hi Valentina,
On 9/12/24 10:00, Valentina Fernandez wrote:
Additional details on the Microchip vendor extension and the IPC
function IDs described in the driver can be found in the following
documentation:
https://github.com/linux4microchip/microchip-sbi-ecall-extension
The IPC remoteproc
On 12/09/2024 19:00, Valentina Fernandez wrote:
> Add a mailbox controller driver for the Microchip Inter-processor
> Communication (IPC), which is used to send and receive data between
> processors.
>
> The driver uses the RISC-V Supervisor Binary Interface (SBI) to
> communi
On 12/09/2024 19:00, Valentina Fernandez wrote:
> The Microchip family of RISC-V SoCs typically has one or more clusters.
> These clusters can be configured to run in Asymmetric Multi-Processing
> (AMP) mode.
>
> Add a remoteproc platform driver to be able to load and boot firmware
> to the remote
dings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Add a dt-binding for the Microchip IPC Remoteproc platform driver.
>
Binding is for hardware, not
On Thu, Sep 12, 2024 at 04:23:44PM -0500, Samuel Holland wrote:
> Hi Valentina,
>
> On 2024-09-12 12:00 PM, Valentina Fernandez wrote:
> > Add a dt-binding for the Microchip Inter-Processor Communication (IPC)
> > mailbox controller.
> >
> > S
Hi Valentina,
On Thu, 12 Sept 2024 at 10:48, Valentina Fernandez
wrote:
>
> Hello all,
>
> This series adds support for the Microchip Inter-Processor Communication
> (IPC) mailbox controller, as well as an IPC remoteproc platform driver.
>
> Microchip's family of RISC-V
tent is safe
>
> Hi Valentina,
>
> On 2024-09-12 12:00 PM, Valentina Fernandez wrote:
>> +static int mchp_ipc_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct mchp_ipc_probe ipc_info;
>> + struct m
Hi Valentina,
On Thu, 12 Sept 2024 at 10:48, Valentina Fernandez
wrote:
>
> Hello all,
>
> This series adds support for the Microchip Inter-Processor Communication
> (IPC) mailbox controller, as well as an IPC remoteproc platform driver.
>
> Microchip's family of RISC-V
Hi Valentina,
On 2024-09-12 12:00 PM, Valentina Fernandez wrote:
> +static int mchp_ipc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mchp_ipc_probe ipc_info;
> + struct microchip_ipc *ipc;
> + struct ipc_chan
Hi Valentina,
On 2024-09-12 12:00 PM, Valentina Fernandez wrote:
> Add a dt-binding for the Microchip Inter-Processor Communication (IPC)
> mailbox controller.
>
> Signed-off-by: Valentina Fernandez
> ---
> .../bindings/mailbox/microchip,sbi-ipc.yaml | 115 ++
On Thu, Sep 12, 2024 at 06:00:22PM +0100, Valentina Fernandez wrote:
> Add a dt-binding for the Microchip Inter-Processor Communication (IPC)
> mailbox controller.
Before anyone else gets here, there's an erroneous "driver" in $subject
:)
> Signed-off
Binary Interface) ecalls to
request software running in machine-privileged mode (M-mode) to
start/stop the remote processor(s).
Inter-processor communication is supported through the virtio rpmsg
stack using shared memory and the Microchip IPC mailbox driver.
Currently, the driver the following
Add a mailbox controller driver for the Microchip Inter-processor
Communication (IPC), which is used to send and receive data between
processors.
The driver uses the RISC-V Supervisor Binary Interface (SBI) to
communicate with software running in machine mode (M-mode) to access
the IPC hardware
Microchip family of RISC-V SoCs typically has or more clusters. These
clusters can be configured to run in Asymmetric Multi Processing (AMP)
mode.
Add a dt-binding for the Microchip IPC Remoteproc platform driver.
Signed-off-by: Valentina Fernandez
---
.../remoteproc/microchip,ipc
Add a dt-binding for the Microchip Inter-Processor Communication (IPC)
mailbox controller.
Signed-off-by: Valentina Fernandez
---
.../bindings/mailbox/microchip,sbi-ipc.yaml | 115 ++
1 file changed, 115 insertions(+)
create mode 100644
Documentation/devicetree/bindings
Hello all,
This series adds support for the Microchip Inter-Processor Communication
(IPC) mailbox controller, as well as an IPC remoteproc platform driver.
Microchip's family of RISC-V SoCs typically has one or more clusters
that can be configured to run in Asymmetric Multi-Processing (AMP)
On Mon, Jul 01, 2024 at 04:13:00AM -0500, Hari Nagalla wrote:
> On 6/28/24 14:58, Mathieu Poirier wrote:
> > > This could lead in an incorrect IPC-only mode detection if reset line is
> > > asserted (so reset_control_status() return > 0) and c_state != 0 and
> > >
On 6/28/24 14:58, Mathieu Poirier wrote:
This could lead in an incorrect IPC-only mode detection if reset line is
asserted (so reset_control_status() return > 0) and c_state != 0 and
halted == 0.
In this case, the old code would have detected an IPC-only mode instead
of a mismatched mode.
Y
s pretty clear that the return value of reset_control_status()
> > was intended to be used instead of ti_sci_proc_get_status() return
> > value.
> >
> > This could lead in an incorrect IPC-only mode detection if reset line is
> > asserted (so reset_control_status() retu
atus() returns 0 it means
> that the reset line is deasserted.
> So, it's pretty clear that the return value of reset_control_status()
> was intended to be used instead of ti_sci_proc_get_status() return
> value.
>
> This could lead in an incorrect IPC-only mode detection
control_status()
was intended to be used instead of ti_sci_proc_get_status() return
value.
This could lead in an incorrect IPC-only mode detection if reset line is
asserted (so reset_control_status() return > 0) and c_state != 0 and
halted == 0.
In this case, the old code would have detected an I
On 06/06/2024 21:18, Luca Weiss wrote:
> The qcom,ipc-N properties are essentially providing a reference to a
> mailbox, so allow using the mboxes property to do the same in a more
> structured way.
>
> Since multiple SMSM hosts are supported, we need to be able to provide
> t
The qcom,ipc-N properties are essentially providing a reference to a
mailbox, so allow using the mboxes property to do the same in a more
structured way.
Since multiple SMSM hosts are supported, we need to be able to provide
the correct mailbox for each host. The old qcom,ipc-N properties map to
>>>>>>>>
> >>>>>>>>> Maybe also from you, any opinion between these two binding styles?
> >>>>>>>>>
> >>>>>>>>> So first using index of mboxes for the numbering, where for the
>
On Thu, 25 Apr 2024 21:14:29 +0200, Luca Weiss wrote:
> The mboxes property has been supported in those bindings since a while
> and was always meant to the replace qcom,ipc properties, so let's mark
> qcom,ipc as deprecated - and update the examples to use mboxes.
>
&
11, Luca Weiss wrote:
>>>>>>>>> Hi Krzysztof
>>>>>>>>>
>>>>>>>>> Ack, sounds good.
>>>>>>>>>
>>>>>>>>> Maybe also from you, any opinion between these two binding s
tof
> >>>>>>>
> >>>>>>> Ack, sounds good.
> >>>>>>>
> >>>>>>> Maybe also from you, any opinion between these two binding styles?
> >>>>>>>
> >>>>>>> So firs
>>>>>>> Maybe also from you, any opinion between these two binding styles?
>>>>>>>
>>>>>>> So first using index of mboxes for the numbering, where for the known
>>>>>>> usages the first element (and sometimes the 3rd
hese two binding styles?
> >>>>>
> >>>>> So first using index of mboxes for the numbering, where for the known
> >>>>> usages the first element (and sometimes the 3rd - ipc-2) are empty <>.
> >>>>>
> >>>>>
eiss wrote:
>>>>> Hi Krzysztof
>>>>>
>>>>> Ack, sounds good.
>>>>>
>>>>> Maybe also from you, any opinion between these two binding styles?
>>>>>
>>>>> So first using index of mboxes for the numbering, where
>>> Ack, sounds good.
> >>>
> >>> Maybe also from you, any opinion between these two binding styles?
> >>>
> >>> So first using index of mboxes for the numbering, where for the known
> >>> usages the first element (and sometimes
these two binding styles?
>>>
>>> So first using index of mboxes for the numbering, where for the known
>>> usages the first element (and sometimes the 3rd - ipc-2) are empty <>.
>>>
>>> The second variant is using mbox-names to get the correct ch
index of mboxes for the numbering, where for the known
> > usages the first element (and sometimes the 3rd - ipc-2) are empty <>.
> >
> > The second variant is using mbox-names to get the correct channel-mbox
> > mapping.
> >
> > - qcom,ipc-1
On 20/05/2024 17:11, Luca Weiss wrote:
> Hi Krzysztof
>
> Ack, sounds good.
>
> Maybe also from you, any opinion between these two binding styles?
>
> So first using index of mboxes for the numbering, where for the known
> usages the first element (and sometimes th
ote processor
> maxItems: 5
Hi Krzysztof
Ack, sounds good.
Maybe also from you, any opinion between these two binding styles?
So first using index of mboxes for the numbering, where for the known
usages the first element (and sometimes the 3rd - ipc-2) are empty <>.
The second vari
On 15/05/2024 17:06, Luca Weiss wrote:
> Hi Rob,
>
> Any feedback on the below topic?
Can be explained in description, like
mboxes:
description: Each entry corresponds to one remote processor
maxItems: 5
Best regards,
Krzysztof
Hi Rob,
Any feedback on the below topic?
Regards
Luca
On Donnerstag, 25. April 2024 20:54:40 MESZ Luca Weiss wrote:
> On Donnerstag, 25. April 2024 18:17:15 MESZ Rob Herring wrote:
> > On Wed, Apr 24, 2024 at 07:21:51PM +0200, Luca Weiss wrote:
> > > The qcom,ipc-N properti
On Thu, 25 Apr 2024 21:14:29 +0200, Luca Weiss wrote:
> The mboxes property has been supported in those bindings since a while
> and was always meant to the replace qcom,ipc properties, so let's mark
> qcom,ipc as deprecated - and update the examples to use mboxes.
>
&
On Thu, 25 Apr 2024 21:14:30 +0200, Luca Weiss wrote:
> Deprecate the qcom,ipc way of accessing the mailbox in favor of the
> 'mboxes' property.
>
> Update the example to use mboxes.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings
On Thu, 25 Apr 2024 21:14:31 +0200, Luca Weiss wrote:
> Deprecate the qcom,ipc way of accessing the mailbox in favor of the
> 'mboxes' property.
>
> Update the example to use mboxes.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/soc
Deprecate the qcom,ipc way of accessing the mailbox in favor of the
'mboxes' property.
Update the example to use mboxes.
Signed-off-by: Luca Weiss
---
Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Doc
Deprecate the qcom,ipc way of accessing the mailbox in favor of the
'mboxes' property.
Update the example to use mboxes.
Signed-off-by: Luca Weiss
---
Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
di
The mboxes property has been supported in those bindings since a while
and was always meant to the replace qcom,ipc properties, so let's mark
qcom,ipc as deprecated - and update the examples to use mboxes.
Related:
https://lore.kernel.org/linux-arm-msm/20240424-apcs-mboxes-v1-0-6556
On Donnerstag, 25. April 2024 18:17:15 MESZ Rob Herring wrote:
> On Wed, Apr 24, 2024 at 07:21:51PM +0200, Luca Weiss wrote:
> > The qcom,ipc-N properties are essentially providing a reference to a
> > mailbox, so allow using the mboxes property to do the same in a more
>
On Wed, Apr 24, 2024 at 07:21:51PM +0200, Luca Weiss wrote:
> The qcom,ipc-N properties are essentially providing a reference to a
> mailbox, so allow using the mboxes property to do the same in a more
> structured way.
Can we mark qcom,ipc-N as deprecated then?
> Since multiple SM
The qcom,ipc-N properties are essentially providing a reference to a
mailbox, so allow using the mboxes property to do the same in a more
structured way.
Since multiple SMSM hosts are supported, we need to be able to provide
the correct mailbox for each host. The old qcom,ipc-N properties map to
On 11/2/23 11:43, Jan Kiszka wrote:
RTI1 watchdog also powers up R5F core 1. And this could happen either in
When writing "... also powers up...", other than R5F core 1, what else is being
powered?
Would be a question for the SoC vendor - I assumed that only mcu_rti1
[1] goes on when enabling i
On 02.11.23 16:43, Mathieu Poirier wrote:
> Hi Jan,
>
> On Thu, Nov 02, 2023 at 11:07:45AM +0100, Jan Kiszka wrote:
>> On 13.02.22 21:12, Suman Anna wrote:
>>> Add support to the K3 R5F remoteproc driver to configure all the R5F
>>> cores to be either in
Hi Jan,
On Thu, Nov 02, 2023 at 11:07:45AM +0100, Jan Kiszka wrote:
> On 13.02.22 21:12, Suman Anna wrote:
> > Add support to the K3 R5F remoteproc driver to configure all the R5F
> > cores to be either in IPC-only mode or the traditional remoteproc mode.
> > The IPC-only
On 13.02.22 21:12, Suman Anna wrote:
> Add support to the K3 R5F remoteproc driver to configure all the R5F
> cores to be either in IPC-only mode or the traditional remoteproc mode.
> The IPC-only mode expects that the remote processors are already booted
> by the bootloader, and only
gt; > From: Daniele Alessandrelli
> > > >
> > > > Add DT binding documentation for the Intel Keem Bay IPC driver, which
> > >
> > > Bindings are for h/w blocks, not drivers. From a binding perspective, I
> > > don't really care what the driver
From: Wedson Almeida Filho
A port to Rust of the Android Binder IPC mechanism.
This driver is a work in progress and will be sent for review later
on, as well as separately from the Rust support.
However, we include it in the RFC so that we can show how an actual
working module written in Rust
On Mon, Mar 8, 2021 at 2:20 PM mark gross wrote:
>
> On Fri, Mar 05, 2021 at 03:01:40PM -0600, Rob Herring wrote:
> > On Fri, Feb 12, 2021 at 02:22:34PM -0800, mgr...@linux.intel.com wrote:
> > > From: Daniele Alessandrelli
> > >
> > > Add DT binding d
Am Mon, 12 Apr 2021 09:06:10 -0700
schrieb Guenter Roeck :
> On 4/12/21 8:35 AM, Henning Schild wrote:
> > Am Thu, 1 Apr 2021 18:15:41 +0200
> > schrieb "Enrico Weigelt, metux IT consult" :
> >
> >> On 29.03.21 19:49, Henning Schild wrote:
> >>
> >> Hi,
> >>
> >>> This driver adds initial sup
On 4/12/21 8:35 AM, Henning Schild wrote:
> Am Thu, 1 Apr 2021 18:15:41 +0200
> schrieb "Enrico Weigelt, metux IT consult" :
>
>> On 29.03.21 19:49, Henning Schild wrote:
>>
>> Hi,
>>
>>> This driver adds initial support for several devices from Siemens.
>>> It is based on a platform driver introd
Am Thu, 1 Apr 2021 18:15:41 +0200
schrieb "Enrico Weigelt, metux IT consult" :
> On 29.03.21 19:49, Henning Schild wrote:
>
> Hi,
>
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.
>
> Where does the w
Am Thu, 1 Apr 2021 14:04:51 +0300
schrieb Andy Shevchenko :
> On Thu, Apr 1, 2021 at 1:44 PM Henning Schild
> wrote:
> >
> > Am Wed, 31 Mar 2021 18:40:23 +0300
> > schrieb Andy Shevchenko :
> >
> > > On Tue, Mar 30, 2021 at 6:33 PM Henning Schild
> > > wrote:
> > > > Am Tue, 30 Mar 2021 15:4
Am Thu, 1 Apr 2021 14:04:51 +0300
schrieb Andy Shevchenko :
> On Thu, Apr 1, 2021 at 1:44 PM Henning Schild
> wrote:
> >
> > Am Wed, 31 Mar 2021 18:40:23 +0300
> > schrieb Andy Shevchenko :
> >
> > > On Tue, Mar 30, 2021 at 6:33 PM Henning Schild
> > > wrote:
> > > > Am Tue, 30 Mar 2021 15:4
"get_last()" using a binary search.
Right, nor do I think there are any users that try to avoid the lookup
caching the value.
As far as I see, ipc is the only user that needs get_last(), thus
implement it in ipc/util.c and not in a central location.
I find your implementation
Enable Qualcomm APCS IPC mailbox driver for IPC communication between
application processor and other masters in platforms like SDX55.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/configs/qcom_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/qcom_defconfig b
On 4/7/21 1:53 AM, Andy Shevchenko wrote:
> On Tue, Apr 6, 2021 at 5:56 PM Henning Schild
> wrote:
>>
>> Am Thu, 1 Apr 2021 18:15:41 +0200
>> schrieb "Enrico Weigelt, metux IT consult" :
>>
>>> On 29.03.21 19:49, Henning Schild wrote:
>>>
>>> Hi,
>>>
This driver adds initial support for sever
SHIFT, this could be a
loop over 16 million entries.
As there is no get_last() function for idr structures:
Implement a "get_last()" using a binary search.
As far as I see, ipc is the only user that needs get_last(), thus
implement it in ipc/util.c and not in a central location.
Signed-
On Tue, Apr 6, 2021 at 5:56 PM Henning Schild
wrote:
>
> Am Thu, 1 Apr 2021 18:15:41 +0200
> schrieb "Enrico Weigelt, metux IT consult" :
>
> > On 29.03.21 19:49, Henning Schild wrote:
> >
> > Hi,
> >
> > > This driver adds initial support for several devices from Siemens.
> > > It is based on a p
Am Thu, 1 Apr 2021 18:15:41 +0200
schrieb "Enrico Weigelt, metux IT consult" :
> On 29.03.21 19:49, Henning Schild wrote:
>
> Hi,
>
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.
>
> Where does the w
On 27.03.21 10:46, Henning Schild wrote:
In this case, they seem to be assigned to certain specific functions
(by physical labels on the box), so IMHO the LED names should reflect
that in some ways.
The choice for "status" was because of
/* Miscelleaus functions. Use functions above if you c
On 29.03.21 19:49, Henning Schild wrote:
Hi,
This driver adds initial support for several devices from Siemens. It is
based on a platform driver introduced in an earlier commit.
Where does the wdt actually come from ?
Is it in the SoC ? (which SoC exactly). SoC-builtin wdt is a pretty
usual
On Thu, Apr 1, 2021 at 1:44 PM Henning Schild
wrote:
>
> Am Wed, 31 Mar 2021 18:40:23 +0300
> schrieb Andy Shevchenko :
>
> > On Tue, Mar 30, 2021 at 6:33 PM Henning Schild
> > wrote:
> > > Am Tue, 30 Mar 2021 15:41:53 +0300
> > > schrieb Andy Shevchenko :
> > > > On Tue, Mar 30, 2021 at 3:35 PM
Am Wed, 31 Mar 2021 18:40:23 +0300
schrieb Andy Shevchenko :
> On Tue, Mar 30, 2021 at 6:33 PM Henning Schild
> wrote:
> > Am Tue, 30 Mar 2021 15:41:53 +0300
> > schrieb Andy Shevchenko :
> > > On Tue, Mar 30, 2021 at 3:35 PM Henning Schild
> > > wrote:
> > > > Am Tue, 30 Mar 2021 15:15:16 +
On Tue, Mar 30, 2021 at 6:33 PM Henning Schild
wrote:
> Am Tue, 30 Mar 2021 15:41:53 +0300
> schrieb Andy Shevchenko :
> > On Tue, Mar 30, 2021 at 3:35 PM Henning Schild
> > wrote:
> > > Am Tue, 30 Mar 2021 15:15:16 +0300
> > > schrieb Andy Shevchenko :
> > > > On Tue, Mar 30, 2021 at 2:58 PM Hen
Am Tue, 30 Mar 2021 15:41:53 +0300
schrieb Andy Shevchenko :
> On Tue, Mar 30, 2021 at 3:35 PM Henning Schild
> wrote:
> > Am Tue, 30 Mar 2021 15:15:16 +0300
> > schrieb Andy Shevchenko :
> > > On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
> > > wrote:
> > > > Am Tue, 30 Mar 2021 14:04:35 +
On Tue, Mar 30, 2021 at 3:35 PM Henning Schild
wrote:
> Am Tue, 30 Mar 2021 15:15:16 +0300
> schrieb Andy Shevchenko :
> > On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
> > wrote:
> > > Am Tue, 30 Mar 2021 14:04:35 +0300
> > > schrieb Andy Shevchenko :
> > > > On Mon, Mar 29, 2021 at 8:59 PM Hen
Am Tue, 30 Mar 2021 15:15:16 +0300
schrieb Andy Shevchenko :
> On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
> wrote:
> > Am Tue, 30 Mar 2021 14:04:35 +0300
> > schrieb Andy Shevchenko :
> > > On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
> > > wrote:
> > > >
> > > > This driver adds initi
On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
wrote:
> Am Tue, 30 Mar 2021 14:04:35 +0300
> schrieb Andy Shevchenko :
> > On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
> > wrote:
> > >
> > > This driver adds initial support for several devices from Siemens.
> > > It is based on a platform drive
Am Tue, 30 Mar 2021 14:04:35 +0300
schrieb Andy Shevchenko :
> On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
> wrote:
> >
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.
>
> ...
>
> > +#define SIMATI
On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
wrote:
>
> This driver adds initial support for several devices from Siemens. It is
> based on a platform driver introduced in an earlier commit.
...
> +#define SIMATIC_IPC_LED_PORT_BASE 0x404E
> +static struct simatic_ipc_led simatic_ipc_leds
/watchdog/simatic-ipc-wdt.c | 215 +
3 files changed, 227 insertions(+)
create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 1fe0042a48d2..948497eb4bef 100644
--- a/drivers/watchdog/Kconfig
+++ b
| 11 ++
drivers/leds/simple/Makefile | 2 +
drivers/leds/simple/simatic-ipc-leds.c | 202 +
5 files changed, 221 insertions(+)
create mode 100644 drivers/leds/simple/Kconfig
create mode 100644 drivers/leds/simple/Makefile
create mode 100644 drivers
-off-by: Henning Schild
---
drivers/platform/x86/Kconfig | 12 ++
drivers/platform/x86/Makefile | 3 +
drivers/platform/x86/simatic-ipc.c| 169 ++
.../platform_data/x86/simatic-ipc-base.h | 29 +++
include/linux/platform_data
gt; drivers/watchdog/Kconfig | 11 ++
> > drivers/watchdog/Makefile | 1 +
> > drivers/watchdog/simatic-ipc-wdt.c | 215
> > + 3 files changed, 227 insertions(+)
> > create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
>
Am Sat, 27 Mar 2021 12:16:23 +0100
schrieb Henning Schild :
> Am Thu, 18 Mar 2021 11:25:10 +0100
> schrieb "Enrico Weigelt, metux IT consult" :
>
> > On 15.03.21 10:57, Henning Schild wrote:
> >
> > Hi,
> >
> > > diff --git a/drivers/leds/s
Am Thu, 18 Mar 2021 11:25:10 +0100
schrieb "Enrico Weigelt, metux IT consult" :
> On 15.03.21 10:57, Henning Schild wrote:
>
> Hi,
>
> > diff --git a/drivers/leds/simple/simatic-ipc-leds.c
> > b/drivers/leds/simple/simatic-ipc-leds.c new file mode 100644
&g
;simatic-ipc:yellow:" LED_FUNCTION_STATUS "-2"
> > > },
> > > + {1 << 13, "simatic-ipc:red:" LED_FUNCTION_STATUS "-3" },
> > > + {1 << 5, "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-3"
>
Am Thu, 18 Mar 2021 12:38:53 +0100
schrieb "Enrico Weigelt, metux IT consult" :
> On 15.03.21 12:19, Pavel Machek wrote:
>
> > But I still don't like the naming. simantic-ipc: prefix is
> > useless. Having 6 status leds is not good, either.
>
> Do we
Am Mon, 15 Mar 2021 12:48:19 +0200
schrieb Andy Shevchenko :
> On Mon, Mar 15, 2021 at 11:57 AM Henning Schild
> wrote:
> >
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.
>
> ...
>
> > +struct simati
Fixes the following W=1 kernel build warning(s):
drivers/hid/intel-ish-hid/ipc/ipc.c:553: warning: expecting prototype for
ish_fw_reset_work_fn(). Prototype was for fw_reset_work_fn() instead
Cc: Srinivas Pandruvada
Cc: Jiri Kosina
Cc: Benjamin Tissoires
Cc: Zhang Lixu
Cc: "Krzy
Hi,
On 3/26/21 10:55 AM, Henning Schild wrote:
> Am Thu, 18 Mar 2021 12:45:01 +0100
> schrieb Hans de Goede :
>
>> Hi,
>>
>> On 3/18/21 12:30 PM, Enrico Weigelt, metux IT consult wrote:
>>> On 17.03.21 21:03, Hans de Goede wrote:
>>>
>>> Hi,
>>>
> It just identifies the box and tells subse
Am Thu, 18 Mar 2021 12:45:01 +0100
schrieb Hans de Goede :
> Hi,
>
> On 3/18/21 12:30 PM, Enrico Weigelt, metux IT consult wrote:
> > On 17.03.21 21:03, Hans de Goede wrote:
> >
> > Hi,
> >
> >>> It just identifies the box and tells subsequent drivers which one
> >>> it is, which watchdog and
gly spelt filename in the subject line, corrected.
>
> ipc/sem.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/ipc/sem.c b/ipc/sem.c
> index f6c30a85dadf..0897dac27f43 100644
> --- a/ipc/sem.c
> +++ b/ipc/sem.c
> @@ -36,7 +36,7 @@
s/runtine/runtime/
s/AQUIRE/ACQUIRE/
s/seperately/separately/
s/wont/won\'t/
s/succesfull/successful/
Signed-off-by: Bhaskar Chowdhury
---
Changes from V1:
Wrongly spelt filename in the subject line, corrected.
ipc/sem.c | 10 +-
1 file changed, 5 insertions(+), 5 dele
s/runtine/runtime/
s/AQUIRE/ACQUIRE/
s/seperately/separately/
s/wont/won\'t/
s/succesfull/successful/
Signed-off-by: Bhaskar Chowdhury
---
ipc/sem.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index f6c30a85dadf..0897dac27f43 1
Fixes the following W=1 kernel build warning(s):
drivers/hid/intel-ish-hid/ipc/ipc.c:553: warning: expecting prototype for
ish_fw_reset_work_fn(). Prototype was for fw_reset_work_fn() instead
Cc: Srinivas Pandruvada
Cc: Jiri Kosina
Cc: Benjamin Tissoires
Cc: Zhang Lixu
Cc: "Krzy
1 - 100 of 2302 matches
Mail list logo
