Date   

Re: [PATCH 1/2] dt-bindings: display: Add idk-1110wr binding

Pavel Machek <pavel@...>
 

Hi!

Add binding for the idk-1110wr LVDS panel from Advantech.

Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm

This patch is based on commit d26087162857b12bd9d0424f2dea2cd9654e50a0
upstream ("dt-bindings: display: Add idk-1110wr binding") which adds yaml
bindings.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Okay. In future, I believe we can take yaml binding, even for kernel
where yaml support is not included. The markup is designed to be
human-readable anyway.
Thanks I shall do that in future. Just for reference in case a yaml binding has a reference to other yaml binding so should there be a patch for converting to yaml format (for example panel.txt -> panel.yaml) ?
Goal here is to save work, and this is just a documentation, so no, I
don't believe we need to do more conversions.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 0/2] Add HiHope RZ/G2M board with idk-1110wr display

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Pavel Machek via lists.cip-project.org
Sent: 20 April 2020 21:25
To: cip-dev@lists.cip-project.org
Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>; Chris Paterson
<Chris.Paterson2@renesas.com>
Subject: Re: [cip-dev] [PATCH 0/2] Add HiHope RZ/G2M board with idk-1110wr display

Hi!

This patch series adds support idk-1110wr display on RZ/G2M board.
I assume it is for 4.19; subject does not say. Otherwise it looks good,
so I'll test it and apply unless someone sees problem with it.
Oops my bad, yes it's for 4.19.

Cheers,
--Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


Re: [PATCH 0/2] Add HiHope RZ/G2M board with idk-1110wr display

Pavel Machek <pavel@...>
 

Hi!

This patch series adds support idk-1110wr display on RZ/G2M board.
I assume it is for 4.19; subject does not say. Otherwise it looks good,
so I'll test it and apply unless someone sees problem with it.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 1/2] dt-bindings: display: Add idk-1110wr binding

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Pavel Machek via lists.cip-project.org
Sent: 20 April 2020 21:16
To: cip-dev@lists.cip-project.org
Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>; Chris Paterson
<Chris.Paterson2@renesas.com>
Subject: Re: [cip-dev] [PATCH 1/2] dt-bindings: display: Add idk-1110wr binding

Hi!

Add binding for the idk-1110wr LVDS panel from Advantech.

Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm

This patch is based on commit d26087162857b12bd9d0424f2dea2cd9654e50a0
upstream ("dt-bindings: display: Add idk-1110wr binding") which adds yaml
bindings.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Okay. In future, I believe we can take yaml binding, even for kernel
where yaml support is not included. The markup is designed to be
human-readable anyway.
Thanks I shall do that in future. Just for reference in case a yaml binding has a reference to other yaml binding so should there be a patch for converting to yaml format (for example panel.txt -> panel.yaml) ?

Cheers,
--Prabhakar

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


Re: [PATCH 1/2] dt-bindings: display: Add idk-1110wr binding

Pavel Machek <pavel@...>
 

Hi!

Add binding for the idk-1110wr LVDS panel from Advantech.

Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm

This patch is based on commit d26087162857b12bd9d0424f2dea2cd9654e50a0
upstream ("dt-bindings: display: Add idk-1110wr binding") which adds yaml
bindings.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Okay. In future, I believe we can take yaml binding, even for kernel
where yaml support is not included. The markup is designed to be
human-readable anyway.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


[PATCH 2/2] arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display

Lad Prabhakar
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit e30f56800e69db6d2763a1f7f64dfcc79f9b5ea7 upstream.

The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
from Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
work the HiHope RZ/G2M, is the most convenient way to support the
HiHope RZ/G2M when it's connected to the idk-1110wr.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/1583957020-16359-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm64/boot/dts/renesas/Makefile | 1 +
.../r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts | 52 ++++++++++++++++++++++
2 files changed, 53 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts

diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index 17785e1..c05feec 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex.dtb
+dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex-idk-1110wr.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex.dtb
dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts b/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
new file mode 100644
index 0000000..2ab5edd
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the HiHope RZ/G2M sub board connected to an
+ * Advantech IDK-1110WR 10.1" LVDS panel
+ *
+ * Copyright (C) 2020 Renesas Electronics Corp.
+ */
+
+#include "r8a774a1-hihope-rzg2m-ex.dts"
+#include "rzg2-advantech-idk-1110wr-panel.dtsi"
+
+/ {
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm0 0 50000>;
+
+ brightness-levels = <0 2 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ };
+
+};
+
+&gpio1 {
+ /*
+ * When GP1_20 is LOW LVDS0 is connected to the LVDS connector
+ * When GP1_20 is HIGH LVDS0 is connected to the LT8918L
+ */
+ lvds-connector-en-gpio {
+ gpio-hog;
+ gpios = <20 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lvds-connector-en-gpio";
+ };
+};
+
+&lvds0 {
+ status = "okay";
+};
+
+&pfc {
+ pwm0_pins: pwm0 {
+ groups = "pwm0";
+ function = "pwm0";
+ };
+};
+
+&pwm0 {
+ pinctrl-0 = <&pwm0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
2.7.4


[PATCH 1/2] dt-bindings: display: Add idk-1110wr binding

Lad Prabhakar
 

Add binding for the idk-1110wr LVDS panel from Advantech.

Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm

This patch is based on commit d26087162857b12bd9d0424f2dea2cd9654e50a0
upstream ("dt-bindings: display: Add idk-1110wr binding") which adds yaml
bindings.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
.../display/panel/advantech,idk-1110wr.txt | 45 ++++++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.txt

diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.txt b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.txt
new file mode 100644
index 0000000..c5388b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.txt
@@ -0,0 +1,45 @@
+Advantech IDK-1110WR 10.1" WSVGA LVDS Display Panel
+===================================================
+
+The Advantech IDK-1110WR is a 10.1" industrial grade LCD display with
+4-wire resistive touch.
+
+These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
+with the following device-specific properties.
+
+Required properties:
+
+- compatible: Shall contain "advantech,idk-1110wr" and "panel-lvds", in that
+ order.
+
+
+Example
+-------
+
+panel {
+ compatible = "advantech,idk-1110wr", "panel-lvds";
+
+ width-mm = <223>;
+ height-mm = <125>;
+
+ data-mapping = "jeida-24";
+
+ panel-timing {
+ /* 1024x600 @60Hz */
+ clock-frequency = <51200000>;
+ hactive = <1024>;
+ vactive = <600>;
+ hsync-len = <240>;
+ hfront-porch = <40>;
+ hback-porch = <40>;
+ vsync-len = <10>;
+ vfront-porch = <15>;
+ vback-porch = <10>;
+ };
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds_encoder>;
+ };
+ };
+};
--
2.7.4


[PATCH 0/2] Add HiHope RZ/G2M board with idk-1110wr display

Lad Prabhakar
 

Hi All,

This patch series adds support idk-1110wr display on RZ/G2M board.

Cheers,
--Prabhakar

Fabrizio Castro (1):
arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display

Lad Prabhakar (1):
dt-bindings: display: Add idk-1110wr binding

.../display/panel/advantech,idk-1110wr.txt | 45 +++++++++++++++++++
arch/arm64/boot/dts/renesas/Makefile | 1 +
.../r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts | 52 ++++++++++++++++++++++
3 files changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.txt
create mode 100644 arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts

--
2.7.4


Re: [cip-members] [cip-dev] Migration complete - Re: Mailman2 to Groups.io reminder

Pavel Machek
 

Hi!

I just set it for cip-dev . See if that is working now?

Happy to do it for other lists if needed.
I believe it makes sense for all the lists, as signed emails make
sense in all cases. Especially cip-security should get it. If it works
now -- we'll see after this email. I'll let you know if not.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: Migration complete - Re: Mailman2 to Groups.io reminder

Neal Caidin
 

In the original email (below), the links were incorrect, as I think someone in the community had pointed out. For the sake of clarity and completeness, I am reposting with the correct links. Thank you for your patience and understanding.

Please do NOT unsubscribe from the "main" list. This would unsubscribe you from all of the CIP lists. "main" is an administrative list used by Groups.io as a parent list to manage the other lists. Please let me know if you have any questions or issues. 

Neal Caidin
Program Manager, Program Management & Operations
The Linux Foundation
+1 (919) 238-9104 (w/h)
+1 (919) 949-1861 (m)


On Mon, Apr 6, 2020 at 5:45 PM Neal Caidin <ncaidin@...> wrote:
Dear CIP Community,

The migration is complete. 

You should receive an email shortly asking you to log in with your email address and set a password.

One important note, please do NOT unsubscribe from the "main" list. This would unsubscribe you from all of the CIP lists. "main" is an administrative list used by Groups.io as a parent list to manage the other lists. Please let me know if you have any questions or issues. 

Lists

On Mon, Apr 6, 2020 at 3:34 PM Neal Caidin <ncaidin@...> wrote:
Reminder.  Mailman2 to Groups.io conversion about to kick off (about an 1 1/2 hours from now).


Please see schedule below.

Best Regards,
Neal



Neal Caidin
Program Manager, Program Management & Operations
The Linux Foundation
+1 (919) 238-9104 (w/h)
+1 (919) 949-1861 (m)


On Thu, Apr 2, 2020 at 4:56 PM Neal Caidin <ncaidin@...> wrote:
[cross posted]

Reminder.  Mailman2 to Groups.io email is scheduled to start on 

Pacific - 2 pm , Monday, April 6
Eastern - 5 pm, Monday April 6
CET - 11 pm, Monday April 6
JST - 6 am, Tuesday, April 7

It is expected to take several hours, but could be as much as a full 24 hours. 

When the migration is completed, I will send out the links so that you can access email archives.

Best regards,
Neal


Neal Caidin
Program Manager, Program Management & Operations
The Linux Foundation
+1 (919) 238-9104 (w/h)
+1 (919) 949-1861 (m)


[ANNOUNCE] v4.19.115-cip24-rt9

Pavel Machek
 

Hi!

v4.19.115-cip24-rt9 should be available at kernel.org.

de0-nano boot problem should be fixed in mainline, so we are now back
to zero realtime-specific patches in the CIP project.

Trees are available at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt-rebase

And their content should be identical.

Best regards,
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: [cip-security] [cip-dev] Python 3.x vs 2.7

Kento Yoshida
 

Hi,

I'll share you the functional requirements for system backup:

1. Regular periodic backup
2. Differential archives backup (to be light not to affect normal operation)
3. Encrypting/Decrypting the backup data
4. Return to checkpoint and restart

We selected the duplicity as the package that meet these requirement, and the duplicity had smaller dependencies compared to similar packages.

But we need to deeply consider the following point:

"How to handle packages with dependent packages such as python 2.7 that are not suitable for long-term maintenance, i.e. EOL."
Do we need to exclude that kind of package?
Or, do we backport from the upper version? by CIP? Or, funding? etc...

I'll submit to the list as the agenda of next CIP core meeting as an issue that requires a common policy, not just a duplicity issue.

Best regards, Kent

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
masashi.kudo@cybertrust.co.jp via lists.cip-project.org
Sent: Wednesday, April 8, 2020 6:24 PM
To: cip-security@lists.cip-project.org; pavel@denx.de; jan.kiszka@siemens.com
Cc: cip-dev@lists.cip-project.org
Subject: Re: [cip-security] [cip-dev] Python 3.x vs 2.7

Hi,

The security WG nominated duplicity as a solution for "Control system backup"
(CR7.3).
One of the common requirements of such backup software is check-point restart
capability.
Duplicity provides this like the following.
https://lists.nongnu.org/archive/html/duplicity-announce/2009-06/msg00000.ht
ml

IMHO, I think tar is not met IEC63443-4-2 requirement, because tar itself does not
have this capability,

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-security@lists.cip-project.org <cip-security@lists.cip-project.org> On
Behalf Of Kento Yoshida
Sent: Tuesday, April 7, 2020 3:49 PM
To: Pavel Machek <pavel@denx.de>; Jan Kiszka <jan.kiszka@siemens.com>
Cc: cip-security@lists.cip-project.org; cip-dev@lists.cip-project.org
Subject: Re: [cip-security] [cip-dev] Python 3.x vs 2.7

Hi,

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: Tuesday, April 7, 2020 6:52 AM
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Pavel Machek <pavel@denx.de>; Kento Yoshida
<kento.yoshida.wz@renesas.com>; cip-security@lists.cip-project.org;
cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Python 3.x vs 2.7

On Mon 2020-04-06 12:15:16, Jan Kiszka wrote:
On 03.04.20 23:47, Pavel Machek wrote:
Hi!


FYI, unfortunately we couldn't find the alternative package for
system backup. The duplicity is the best package for us from the
license and num of dependencies point of view.

See the following.
<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht
I'm not sure what your exact requirements are, but have you
considered
"tar"? It should be possible to pipe its output to aespipe (and
possibly other tools) to get encryption, and it should be able to
do
incremental backups...
I suppose there is that concern about GPLv3 again (as with broadly
used
rsync) - which is generally overrated. There exists legal views that
already
GPLv2 requires to keep such licensed components replaceable on the
target.
What then effectively remains with v3 is its, well, wording
complexity.

Does "tar" match the requirements?

And I agree that best option would be to accept GPLv3.
Some of the security members didn't accept GPLv3, so currently we dropped
GPLv3 packages from the candidates.

BTW, I'm not sure but is the CIP policy on accepting GPLv3 still to be decided?

If that's out of question, I'm pretty sure we can get GPLv2 tar
implementation somewhere. busybox has implementation, and I'm pretty
sure there's GPLv2 fork of busybox. Old version of tar should be GPLv2.
Still better than porting duplicity to different python version...
Thank you for introduction about "tar".
I will investigate whether it meets the requirements.
And also I'll search GPLv2 implementation if it meets the requirements.
If it's not decided yet about the CIP policy on accepting GPLv3, we cannot adopt
GPLv3 packages.

Anyway, I agreed it is difficult to support python 2 for a super long term. And
everyone agreed on this point.
So, we cannot support each libraries using python 2, at least.

Best regards, Kent

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi, Chris-san,

 

Sure, please rest at ease, and stay safe. See you next week.

 

Best regards,

--

M. Kudo

 

From: cip-dev@... <cip-dev@...> On Behalf Of Chris Paterson
Sent: Thursday, April 16, 2020 5:16 PM
To: cip-dev@...
Subject: Re: [cip-dev] CIP IRC weekly meeting today

 

Hello Kudo-san,

Please accept my apologies for today's meeting as I am on leave this week.

No major updates to report from the testing working group.

Kind regards, Chris


From: cip-dev@... <cip-dev@...> on behalf of masashi.kudo@... via lists.cip-project.org <masashi.kudo=cybertrust.co.jp@...>
Sent: Thursday, April 16, 2020 3:02:49 AM
To: cip-dev@... <cip-dev@...>
Subject: [cip-dev] CIP IRC weekly meeting today

 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=4&day=16&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest  USEast  UK      DE      TW      JP
02:00   05:00   10:00   11:00   17:00   18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/04/cip.2020-04-09-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - Iwamatsu-san
2. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
 2-1. Workflow for identifying important fixes, backporting, and reviewing them
 2-2. Prepare the tools to be used for this workflow
 2-3. Get practice in backporting patches
3. Upload a guideline for reference hardware platform addition - masashi910
4. Identify target boards and configs for RT kernel testing (4.4rt and 4.19rt) - masashi910
5. Clarify the requirement about system-backup - Yoshida-san

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: CIP IRC weekly meeting today

Chris Paterson
 

Hello Kudo-san,

Please accept my apologies for today's meeting as I am on leave this week.

No major updates to report from the testing working group.

Kind regards, Chris


From: cip-dev@... <cip-dev@...> on behalf of masashi.kudo@... via lists.cip-project.org <masashi.kudo=cybertrust.co.jp@...>
Sent: Thursday, April 16, 2020 3:02:49 AM
To: cip-dev@... <cip-dev@...>
Subject: [cip-dev] CIP IRC weekly meeting today
 
Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=4&day=16&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest  USEast  UK      DE      TW      JP
02:00   05:00   10:00   11:00   17:00   18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/04/cip.2020-04-09-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - Iwamatsu-san
2. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
 2-1. Workflow for identifying important fixes, backporting, and reviewing them
 2-2. Prepare the tools to be used for this workflow
 2-3. Get practice in backporting patches
3. Upload a guideline for reference hardware platform addition - masashi910
4. Identify target boards and configs for RT kernel testing (4.4rt and 4.19rt) - masashi910
5. Clarify the requirement about system-backup - Yoshida-san

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi, Punit-san,

Thanks for letting me know the status. See you next week!

Best regards,
--
M. Kudo

-----Original Message-----
From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
Sent: Thursday, April 16, 2020 4:22 PM
To: 工藤 雅司(CTJ OSS事業推進室) <masashi.kudo@cybertrust.co.jp>
Cc: cip-dev@lists.cip-project.org; Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Subject: Re: [cip-dev] CIP IRC weekly meeting today

Hi Kudo-san,

I won't be able to attend the meeting today. Some updates below -

"masashi.kudo@cybertrust.co.jp" <masashi.kudo@cybertrust.co.jp> writes:

[...]

* CIP Core
- Discussion around projected EOL for CIP core support on cip-dev. Based
on the comments in the TSC I will update the proposal to YYYY-MM
format.
- Daniel to take over CIP Core activities going forward

Thanks,
Punit

[...]


Re: CIP IRC weekly meeting today

punit1.agrawal@...
 

Hi Kudo-san,

I won't be able to attend the meeting today. Some updates below -

"masashi.kudo@cybertrust.co.jp" <masashi.kudo@cybertrust.co.jp> writes:

[...]

* CIP Core
- Discussion around projected EOL for CIP core support on cip-dev. Based
on the comments in the TSC I will update the proposal to YYYY-MM
format.
- Daniel to take over CIP Core activities going forward

Thanks,
Punit

[...]


CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=4&day=16&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/04/cip.2020-04-09-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - Iwamatsu-san
2. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
2-1. Workflow for identifying important fixes, backporting, and reviewing them
2-2. Prepare the tools to be used for this workflow
2-3. Get practice in backporting patches
3. Upload a guideline for reference hardware platform addition - masashi910
4. Identify target boards and configs for RT kernel testing (4.4rt and 4.19rt) - masashi910
5. Clarify the requirement about system-backup - Yoshida-san

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


[ANNOUNCE] Release v4.19.114-cip24 and v4.4.218-cip44

Nobuhiro Iwamatsu
 

Hi all,

CIP kernel team has released Linux kernel v4.19.114-cip24 and v4.4.218-cip44.
The linux-4.19.y-cip tree has been updated base version from v4.19.113 to v4.19.114,
and linux-4.4.y-cip tree has been updated base version from v4.4.216 to v4.4.218.

You can get this release via the git tree at:

v4.19.114-cip24:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
7389e9e1d8fc1e0a456a5cf8fe336c78388d108c
added commits:
CIP: Bump version suffix to -cip24 after merge from stable

v4.4.218-cip44:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.4.y-cip
commit hash:
e219b8481eddce3f76bc1efc70d560434d235efd
added commits:
CIP: Bump version suffix to -cip44 after merge from stable

Best regards,
Nobuhiro


[ANNOUNCE] v4.4.215-cip42-rt28

Pavel Machek <pavel@...>
 

Hi!

v4.4.215-cip42-rt28 should be available at kernel.org.

Trees are available at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.4.y-cip-rt

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.4.y-cip-rt-rebase

And their content should be identical.

Problem that broke boot on 4.19-rt with de0-nano was present in
v4.4-rt, according to my code inspection. de0-nano is not supported
platform for 4.4-rt and I could not easily test the bug or the fix,
but I believe fixing it was safer choice. Problem would not affect
configuration with realtime enabled.

Best regards,
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: CIP Core target EOL dates

punit1.agrawal@...
 

Hi Kudo-san,

"masashi.kudo@cybertrust.co.jp" <masashi.kudo@cybertrust.co.jp> writes:

Hi, Punit-san,

I also calculated, and my conclusion is the following.

Debian
- Jessie 2015-04-26
- Stretch 2017-06-17
- Buster 2019-07-06
CIP SLTS Kernel
- SLTS4.4 2017-01-17
- SLTS4.19 2019-01-11
* https://docs.google.com/presentation/d/1R2r7_hVijKN1VTuVc92IE4U94p9AUU90bMFUoGRroUI/edit?pli=1#slide=id.p7

Combination Earlier date btw two
---------------------------------------
4.4 x Jessie 2015-04-26 -> EOL: 2025-04-26
4.4 x Stretch 2017-01-17 -> EOL: 2027-01-17
4.19 x Stretch 2017-06-17 -> EOL: 2027-06-17
4.19 x Buster 2019-01-11 -> EOL: 2029-01-11
+----------+--------------+--------------+--------------+
| | Debian 8 | Debian 9 | Debian 10 |
| SLTS | Jessie | Stretch | Buster |
| Kernel | | | |
+----------+--------------+--------------+--------------+
| v4.4 | 2025-04-26 | 2027-01-17 | |
+----------+--------------+--------------+--------------+
| v4.19 | | 2027-06-17 | 2029-01-11 |
+----------+--------------+--------------+--------------+

By doing this, I felt dizzy... :) So I would appreciate it if you can
double-check.
I definitely went through it a couple of times and still made an obvious
mistake. Thanks for re-calculating and checking. The two sets match so I
am happy to accept them.

Let's wait to see if there is any more feedback on duration of support
or the methodology. We can then move to the next steps.

Thanks,
Punit


Best regards,
--
M. Kudo

-----Original Message-----
From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
Sent: Friday, April 10, 2020 11:02 AM
To: 工藤 雅司(CTJ OSS事業推進室) <masashi.kudo@cybertrust.co.jp>
Cc: cip-dev@lists.cip-project.org; daniel.sangorrin@toshiba.co.jp; kazuhiro3.hayashi@toshiba.co.jp
Subject: Re: [cip-dev] CIP Core target EOL dates

Hello Kudo-san,

Thanks for your comments.

"masashi.kudo@cybertrust.co.jp" <masashi.kudo@cybertrust.co.jp> writes:

Hi, Punit-san,

Thanks for initiating the discussion.

Regarding the EOL of "v4.19" x "Debian Buster", it should be
"2029-01-11" if we follow the following rule.

earlier of (Kernel, Debian) release date + 10 yrs
For the calculation, I used the upstream kernel release date as reference but we can use CIP kernel release dates from your slides.

I wasn't sure if CIP maintenance is based on upstream release or CIP release.

With that update, the proposed dates look like -

+----------+--------------+--------------+--------------+
| | Debian 8 | Debian 9 | Debian 10 |
| | Jessie | Stretch | Buster |
| Kernel | | | |
+----------+--------------+--------------+--------------+
| v4.4 | 2025-04-26 | 2026-01-10 | |
+----------+--------------+--------------+--------------+
| v4.19 | | 2027-01-17 | 2029-01-11 |
+----------+--------------+--------------+--------------+

Note: There's a typo in my original mail - for Debian Buster (v4.19) the EOL date should've been 2029-10-18.

[...]

Ideally, the dates for the Core components should be aligned with CIP
maintained kernels but there doesn't seem to be any public
documentation for the CIP kernel EOL dates. Let me know if this is
written down somewhere.
The projected EOLs are stated in the above document.
Regarding the web site, I noticed that the following page is not updated.

https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernel
maintenance

I will discuss this inside the kernel team.
Thanks. It would be good to publish the information on CIP website. It's easier to find and reference.

Once agreed, we should do the same for Core components as well.

Thanks,
Punit


[...]

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On
Behalf Of punit1.agrawal@toshiba.co.jp
Sent: Thursday, April 9, 2020 2:27 PM
To: cip-dev@lists.cip-project.org
Cc: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>; Kazuhiro
Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
Subject: [cip-dev] CIP Core target EOL dates

Hi,

CIP is planning to support the Kernels + Debian Rootfs combinations marked with 'x' in the table below.

+----------+----------+-----------+-----------+
| | Debian 8 | Debian 9 | Debian 10 |
| | Jessie | Stretch | Buster |
| Kernel | | | |
+----------+----------+-----------+-----------+
| v4.4 | x | x | |
+----------+----------+-----------+-----------+
| v4.19 | | x | x |
+----------+----------+-----------+-----------+

So far, the details of when the support is expected to end haven't been explicitly called out for Core components. It would be good to rectify this in order to set expectations and gather feedback from the user community.

In addition, it will be helpful in estimating the required effort and planning to resource the projects appropriately.

To start the conversation, I would like to propose the following target EOL dates for each of the supported combination.

Note: All the dates are in YYYY-MM-DD format

+----------+--------------+--------------+--------------+
| | Debian 8 | Debian 9 | Debian 10 |
| | Jessie | Stretch | Buster |
| Kernel | | | |
+----------+--------------+--------------+--------------+
| v4.4 | 2025-04-26 | 2026-01-10 | |
+----------+--------------+--------------+--------------+
| v4.19 | | 2027-06-17 | 2019-10-18 |
+----------+--------------+--------------+--------------+

The proposed dates have been calculated as

earlier of (Kernel, Debian) release date + 10 yrs

The choice of duration (10 yrs) is arbitrary and should be adjusted based on requirement and available resources. Also, some of the combinations could be dropped if there are no users for them.

Ideally, the dates for the Core components should be aligned with CIP maintained kernels but there doesn't seem to be any public documentation for the CIP kernel EOL dates. Let me know if this is written down somewhere.

All feedback welcome.

Thanks,
Punit


The relevant Debian[0][1][2] and Kernel[3] release dates are copied below for reference.

Debian Release Dates
--------------------
Jessie - 2015-04-26
Stretch - 2017-06-17
Buster - 2019-07-06

Linux Kernel Release Dates
--------------------------
v4.4 - 2016-01-10
v4.19 - 2018-10-18


[0] https://www.debian.org/releases/jessie/
[1] https://www.debian.org/releases/stretch/
[2] https://www.debian.org/releases/buster/
[3] https://www.kernel.org/category/releases.html

2481 - 2500 of 7074