Is tlsdate a better alternative?

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com

Hi!

I'm almost done getting SSL working between the BBB and hawkbit. The last
piece of the puzzle is to get NTP working on the BBB (since I need valid
time to ensure that the server certificate is valid). Unfortunately,
I'm

Notice that in this case SSL is not adding as much security as you
think it does.

SSL attempts to protect against active attackers, and those can
manipulate NTP easily.

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

Hello all,

The IRC logger was down yesterday, so please see a dirty copy/paste from the meeting below.

Kind regards, Chris

/start log

patersonc
Hello
wens
hi
szlin
hi
suzuki
hi
paveltest
hi
patersonc
I'm in charge today - sorry in advance!
#startmeeting CIP IRC weekly meeting
bwh joined the room.
bwh
hi
patersonc
#topic rollcall
Say hi etc.
(Doesn't look like the logger is working for me?)
dineshk
Hi
patersonc
I guess everyone has said hi already ;)
bwh
patersonc: It's not in the channel
patersonc
Ah
szlin
patersonc: it seems like the bot is not around
paveltest
Umm, I guess we can just pretend it works and create the logs manually or something.
patersonc
Sure
#topic AI review
Combine root filesystem with kselftest binary - iwamatsu
Any updates iwamatsu?
szlin
patersonc: Today is the national holiday in Japan
paveltest
I don't think he is around... did not say hi.
patersonc
Ah is it? I didn't realise :(
Moving on...
Post LTP results to KernelCI - patersonc
No updates from me
Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu
szlin
Done
patersonc
Huzzah. Thanks szlin
szlin
I uploaded the new version of swupdate few weeks ago.
patersonc
Thanks. It could be that the action list I'm using is out of date...
Moving on...
#topic Kernel maintenance updates
wens
3 new CVEs, all fixed and backported (if needed); 3 old CVEs fixed.
paveltest
I have reviewed patches for 4.19.134.
bwh
I have reviewed kernel-sec updates by wens
patersonc
I have a question for the mainainers
Is anyone maintaining the CIP patchwork?
(or using)
paveltest
Hmm... We used it some time ago.
...but then I somehow forgot it exists.
patersonc
#link https://patchwork.kernel.org/project/cip-dev/list/
I wonder if someone should take ownership of it?
paveltest
Ammount of patches on the list is quite low, so patchwork is not really useful.
I believe we cna
can simply declare it dead.
It is currently not useful.
patersonc
Would it become more useful when LTS support ends?
paveltest
I don't think so.
It would become useful if we got a lot of patches
from participating companies.
patersonc
Any thoughts from anyone else?
paveltest
Currently we are just getting patches from Biju and ammount is quite low.
patersonc
Okay. Thanks
paveltest
bwh
I don't have experience using patchwork, so I don't have a feel for when it's more or less useful
wens
I guess it really depends on the maintainers? It's less common for patch submitters to go on patchwork to update status for their own patches
(hence the unmaintained mess for lakml patchwork)
paveltest
I see patchwork as a service for patch submitters. If they are okay without it, it is easier for maintainer.
patersonc
I know that it's useful for those who want a nice URL to their submitted patch before it gets merged
wens
paveltest: I always thought it was the other way around.
patersonc: I believe lore takes care of that now
patersonc
I'll send an email to the wider maintainer/cip-dev group to see if everyone agrees that we should kill it, or leave it running (un)maintained
#action patersonc: Email Kernel team/cip-dev about patchwork usage
paveltest
Wens: well, if there are so many patches maintainer loses track, it is useful for maintainer too. But that is not currently the case.
patersonc
Any other topics/comments for/from the Kernel team?
5
4
3
2
1
#topic Kernel testing
KernelCI have agreed to add the CIP trees to kernelci.org
I've submitted a PR accordingly: https://github.com/kernelci/kernelci-core/pull/448
Fix renesas-soc repository and add CIP branches.
We also plan to have our own instance, initially running on KCI's servers at cip.kernelci.org.
Any testing related topics/questions from anyone else?
wens
are the instances completely separate, or sharing data / control?
patersonc
Separate. If we add any useful features on our fork we'd aim to upstream them back to kernelci
Initially we'd be using KCI's build infrastructure, with the aim of integrating it into our own
If anyone is interested in helping out with this effort please let me know.
Anyone for anymore before the next topic?
5
4
3
2
1
#topic Software update
suzuki
Hello.
I had found some problems with the current software update mechanism uploaded to cip-sw-updates-demo repository.
paveltest left the room.
suzuki
The problems had been that some needed files and settings didn't exist in the root file system.
I created gitlab issues about them: https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/15, https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/16
And I'm working on them. One of them has been already done.
Apart from that, Mohammed is working on the task which is to support HTTPS connection between SWUpdate and hawkBit: https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/8
That's all from me.
patersonc
Thank you suzuki-san
Any queries from anyone?
5
4
3
2
1
#topic CIP Security
dineshk
hello
I guess Kent is not around so I will update
patersonc
Thank you
dineshk
Completed verification of single node security requirements on CIP LAVA
Working with Chris to verify multi-node security requirements on LAVA
SOW signed with exida for CIP gap assessment for IEC-62443-4-2 & IEC-62443-4-1
Kick-off meeting with exida held for Gap assessment yesterday
That's all from security WG
patersonc
Thank you dineshk
Any comments/queries?
5
4
3
2
1
#topic AOB
Any other topics from anyone today?
If not, then I guess we'll close for today.
Thank you all for your time!
#endmeeting

/end log

Hi!

Add RZ/G2E Dual LVDS display support. All patches in this series are
cherry-picked from upstream kernel.

I could not find any issues besides double of_node_put in 11/.

It is currently being tested:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/169687006

If noone objects (and tests pass), I can apply/push the series.

Applied, thanks for patches.

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

Hi Jan,

On Thu, Jul 23, 2020 at 04:10 PM, Jan Kiszka wrote:

On 21.07.20 10:16, Venkata Pyla wrote:

From: venkata <venkata.pyla@...>

Signed-off-by: venkata <venkata.pyla@...>
---
README.md | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/README.md b/README.md
index bbad1a0..b2c4166 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,16 @@ card, run
dd

if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-buster-bbb.wic.img \

of=/dev/<medium-device> bs=1M status=progress

+## Building Security target images
+Building images for QEMU x86-64bit machine
+
+ ./kas-docker --isar build --target cip-core-image-security

kas.yml:board-qemu-amd64.yml

+
+Run the generated securiy images on QEMU (x86-64bit)
+
+ TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64
+
+
## Community Resources

TBD

This patch is fine, but I'm missing 4/4: Add this image to CI (same
comment as I had on the MR on gitlab).

Adding cip security image to CI,
i need some suggestions to use the current format present in .gitlab-ci.yml

Currently i have the below problem for using script deploy-cip-core.sh:
1. image name formation in the script should have another variable
.../$IMG_PREFIX-cip-core-$RELEASE-$TARGET
where $IMG_PREFIX is default to "cip-core-image" if not specified
for security image it will be passed as 4th argument "cip-core-image-security"
2. currently scrit is expecting the image format in *.wic.img so,
for qemu i think we should have wks file to generate image with format .wic.img

or for this security image do we need to deploy it seperatley?
please guide me

Thanks

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

On 23.07.20 15:13, Venkata Pyla wrote:

Hi Jan,
sorry i am resending this mail
On Thu, Jul 23, 2020 at 04:07 PM, Jan Kiszka wrote:

On 21.07.20 10:16, Venkata Pyla wrote:

From: Kazuhiro Hayashi <kazuhiro3.hayashi@...>

Identified security packages are added to the target image
and that will be used for IEC-62443-4-2 evaluation

Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@...>
Signed-off-by: pvenkata2 <venkata.pyla@...>

^^^^^^^^^
Can you configure your git to add you written name here as well? It's in
the email, yes, but it would be nicer to have it displayed as well.

sure, i didn't notice, it was missed in my git config

---
.../images/cip-core-image-security.bb | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 recipes-core/images/cip-core-image-security.bb

diff --git a/recipes-core/images/cip-core-image-security.bb

b/recipes-core/images/cip-core-image-security.bb

new file mode 100644
index 0000000..8253952
--- /dev/null
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -0,0 +1,37 @@
+#
+# A reference image which includes security packages
+#
+# Copyright (c) Toshiba Corporation, 2020
+#
+# Authors:
+# Kazuhiro Hayashi <kazuhiro3.hayashi@...>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit image
+
+DESCRIPTION = "CIP Core image including security packages"
+
+# Use the same customizations as cip-core-image

That comment is not needed. It just creates the risk of becoming
outdated if cip-core-image decides to do something else.

Understood, i will modify and resend this patch series

+IMAGE_INSTALL += "customizations"
+
+# Debian packages that provide security features
+IMAGE_PREINSTALL += " \
+ openssl libssl1.1 \
+ fail2ban \
+ openssh-server openssh-sftp-server openssh-client \
+ syslog-ng-core syslog-ng-mod-journal \
+ aide aide-common \
+ libnftables0 nftables \
+ libpam-pkcs11 \
+ chrony \
+ tpm2-tools \
+ tpm2-abrmd \
+ libtss2-esys0 libtss2-udev \
+ libpam-cracklib \
+ acl \
+ libauparse0 audispd-plugins auditd \
+ uuid-runtime \
+ sudo \
+"

Can you close
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/8
if this series obsoletes it?

I have rebased the branch and sent the patches over mail,
I think i should close this MR in gitlab, i will do that.

BTW, a cover letter would help structuring the patches together. And
please add a tag like "[isar-cip-core]" in order to clarify the series
target. That is all configurable in git format-patch/send-email.

Got it,
i was sending the patches to the community for the first time so i was missing some basic stuff.
next time i will do care of it,
thanks for showing patience on me

Don't worry. The submission looked fairly good otherwise, not like first-time!

BTW, I'm still ambivalent whether to do UI (MRs) or cip-dev based patch reviews for isar-cip-core. As contributions increase, you contributors need to express your preference. I'm used to both by now, I have troubles with both by now. However, we just need to consolidate over one system because we can't couple them reasonably.

And then we should document the current state of affairs, I know. There is a CONTRIBUTING guild missing for this repo.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Hi Jan,

sorry i am resending this mail

On Thu, Jul 23, 2020 at 04:07 PM, Jan Kiszka wrote:

On 21.07.20 10:16, Venkata Pyla wrote:

From: Kazuhiro Hayashi <kazuhiro3.hayashi@...>

Identified security packages are added to the target image
and that will be used for IEC-62443-4-2 evaluation

Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@...>
Signed-off-by: pvenkata2 <venkata.pyla@...>

^^^^^^^^^
Can you configure your git to add you written name here as well? It's in
the email, yes, but it would be nicer to have it displayed as well.

sure, i didn't notice, it was missed in my git config

---
.../images/cip-core-image-security.bb | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 recipes-core/images/cip-core-image-security.bb

diff --git a/recipes-core/images/cip-core-image-security.bb

b/recipes-core/images/cip-core-image-security.bb

new file mode 100644
index 0000000..8253952
--- /dev/null
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -0,0 +1,37 @@
+#
+# A reference image which includes security packages
+#
+# Copyright (c) Toshiba Corporation, 2020
+#
+# Authors:
+# Kazuhiro Hayashi <kazuhiro3.hayashi@...>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit image
+
+DESCRIPTION = "CIP Core image including security packages"
+
+# Use the same customizations as cip-core-image

That comment is not needed. It just creates the risk of becoming
outdated if cip-core-image decides to do something else.

Understood, i will modify and resend this patch series

+IMAGE_INSTALL += "customizations"
+
+# Debian packages that provide security features
+IMAGE_PREINSTALL += " \
+ openssl libssl1.1 \
+ fail2ban \
+ openssh-server openssh-sftp-server openssh-client \
+ syslog-ng-core syslog-ng-mod-journal \
+ aide aide-common \
+ libnftables0 nftables \
+ libpam-pkcs11 \
+ chrony \
+ tpm2-tools \
+ tpm2-abrmd \
+ libtss2-esys0 libtss2-udev \
+ libpam-cracklib \
+ acl \
+ libauparse0 audispd-plugins auditd \
+ uuid-runtime \
+ sudo \
+"

Can you close
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/8
if this series obsoletes it?

I have rebased the branch and sent the patches over mail,
I think i should close this MR in gitlab, i will do that.

BTW, a cover letter would help structuring the patches together. And
please add a tag like "[isar-cip-core]" in order to clarify the series
target. That is all configurable in git format-patch/send-email.

Got it,
i was sending the patches to the community for the first time so i was missing some basic stuff.
next time i will do care of it,
thanks for showing patience on me

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Hi Jan,

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com

Hi Pavel,

Thanks for the feedback.

Subject: Re: [PATCH 4.19.y-cip 11/17] drm: of: Add
drm_of_lvds_get_dual_link_pixel_order

Hi!

commit 6529007522ded00b8912c079250620fa7a732166 upstream.

An LVDS dual-link connection is made of two links, with even pixels
transitting on one link, and odd pixels on the other link. The device
tree can be used to fully describe dual-link LVDS connections between
encoders and bridges/panels.
The sink of an LVDS dual-link connection is made of two ports, the
corresponding OF graph port nodes can be marked with either
dual-lvds-even-pixels or dual-lvds-odd-pixels, and that fully
describes an LVDS dual-link connection, including pixel order.

There is double-free bug here, AFAICT:

+for_each_child_of_node(port_node, endpoint) {
+struct device_node *remote_port;
+int current_pt;
+
+if (!of_node_name_eq(endpoint, "endpoint"))
+continue;
+
+remote_port = of_graph_get_remote_port(endpoint);
+if (!remote_port) {
+of_node_put(remote_port);
+return -EPIPE;
+}
+
+current_pt =

drm_of_lvds_get_port_pixels_type(remote_port);

+of_node_put(remote_port);

You have put remote_port here.

+if (pixels_type < 0)
+pixels_type = current_pt;
+
+/*
+ * Sanity check, ensure that all remote endpoints have the

same

+ * pixel type. We may lift this restriction later if we need to
+ * support multiple sinks with different dual-link
+ * configurations by passing the endpoints explicitly to
+ * drm_of_lvds_get_dual_link_pixel_order().
+ */
+if (!current_pt || pixels_type != current_pt) {
+of_node_put(remote_port);
+return -EINVAL;

And again here.

Now... it is only a problem in error path, so maybe easiest way is to fix it in
the mainline and then backport the fix here...

Yes I agree with you, there is double-free bug in error path. As you suggested, We should send a patch in mainline to fix this and backport here.

Cheers,
Biju


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

On 21.07.20 10:16, Venkata Pyla wrote:

From: venkata <venkata.pyla@...>
Signed-off-by: venkata <venkata.pyla@...>
---
README.md | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/README.md b/README.md
index bbad1a0..b2c4166 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,16 @@ card, run
dd if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-buster-bbb.wic.img \
of=/dev/<medium-device> bs=1M status=progress
+## Building Security target images
+Building images for QEMU x86-64bit machine
+
+ ./kas-docker --isar build --target cip-core-image-security kas.yml:board-qemu-amd64.yml
+
+Run the generated securiy images on QEMU (x86-64bit)
+
+ TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64
+
+
## Community Resources
TBD

This patch is fine, but I'm missing 4/4: Add this image to CI (same comment as I had on the MR on gitlab).

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

On 21.07.20 10:16, Venkata Pyla wrote:

From: Kazuhiro Hayashi <kazuhiro3.hayashi@...>
Identified security packages are added to the target image
and that will be used for IEC-62443-4-2 evaluation
Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@...>
Signed-off-by: pvenkata2 <venkata.pyla@...>

^^^^^^^^^
Can you configure your git to add you written name here as well? It's in the email, yes, but it would be nicer to have it displayed as well.

---
.../images/cip-core-image-security.bb | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 recipes-core/images/cip-core-image-security.bb
diff --git a/recipes-core/images/cip-core-image-security.bb b/recipes-core/images/cip-core-image-security.bb
new file mode 100644
index 0000000..8253952
--- /dev/null
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -0,0 +1,37 @@
+#
+# A reference image which includes security packages
+#
+# Copyright (c) Toshiba Corporation, 2020
+#
+# Authors:
+# Kazuhiro Hayashi <kazuhiro3.hayashi@...>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit image
+
+DESCRIPTION = "CIP Core image including security packages"
+
+# Use the same customizations as cip-core-image

That comment is not needed. It just creates the risk of becoming outdated if cip-core-image decides to do something else.

+IMAGE_INSTALL += "customizations"
+
+# Debian packages that provide security features
+IMAGE_PREINSTALL += " \
+ openssl libssl1.1 \
+ fail2ban \
+ openssh-server openssh-sftp-server openssh-client \
+ syslog-ng-core syslog-ng-mod-journal \
+ aide aide-common \
+ libnftables0 nftables \
+ libpam-pkcs11 \
+ chrony \
+ tpm2-tools \
+ tpm2-abrmd \
+ libtss2-esys0 libtss2-udev \
+ libpam-cracklib \
+ acl \
+ libauparse0 audispd-plugins auditd \
+ uuid-runtime \
+ sudo \
+"

Can you close https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/8 if this series obsoletes it?

BTW, a cover letter would help structuring the patches together. And please add a tag like "[isar-cip-core]" in order to clarify the series target. That is all configurable in git format-patch/send-email.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Hello all,

CIP has a Patchwork instance [0] that monitors the cip-dev mainline list for patches.

It doesn't look like it's particularly maintained, with most patches in the "new" state.
As a project, do we want to start maintaining Patchwork? Should we kill it off? Or just stick with the status-quo?

We briefly discussed this in the IRC meeting today, but I thought we should check with a wider audience before making a decision.

So, any thoughts?

[0] https://patchwork.kernel.org/project/cip-dev/list/

Kind regards, Chris

Hi!

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
I cannot attend the meeting today. Chris-san will host the meeting instead.

I should be able to attend the meeting, but in case reality
interferes:

I have reviewed patches for 4.19.134.

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

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
I cannot attend the meeting today. Chris-san will host the meeting instead.

*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=7&day=23&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/07/cip.2020-07-16-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

* Kernel maintenance updates
* Kernel testing
* 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.

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com

Hi!

Add RZ/G2E Dual LVDS display support. All patches in this series are
cherry-picked from upstream kernel.

I could not find any issues besides double of_node_put in 11/.

It is currently being tested:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/169687006

If noone objects (and tests pass), I can apply/push the series.

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

Hi!

commit 6529007522ded00b8912c079250620fa7a732166 upstream.

An LVDS dual-link connection is made of two links, with even
pixels transitting on one link, and odd pixels on the other
link. The device tree can be used to fully describe dual-link
LVDS connections between encoders and bridges/panels.
The sink of an LVDS dual-link connection is made of two ports,
the corresponding OF graph port nodes can be marked
with either dual-lvds-even-pixels or dual-lvds-odd-pixels,
and that fully describes an LVDS dual-link connection,
including pixel order.

There is double-free bug here, AFAICT:

+ for_each_child_of_node(port_node, endpoint) {
+ struct device_node *remote_port;
+ int current_pt;
+
+ if (!of_node_name_eq(endpoint, "endpoint"))
+ continue;
+
+ remote_port = of_graph_get_remote_port(endpoint);
+ if (!remote_port) {
+ of_node_put(remote_port);
+ return -EPIPE;
+ }
+
+ current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
+ of_node_put(remote_port);

You have put remote_port here.

+ if (pixels_type < 0)
+ pixels_type = current_pt;
+
+ /*
+ * Sanity check, ensure that all remote endpoints have the same
+ * pixel type. We may lift this restriction later if we need to
+ * support multiple sinks with different dual-link
+ * configurations by passing the endpoints explicitly to
+ * drm_of_lvds_get_dual_link_pixel_order().
+ */
+ if (!current_pt || pixels_type != current_pt) {
+ of_node_put(remote_port);
+ return -EINVAL;

And again here.

Now... it is only a problem in error path, so maybe easiest way is to
fix it in the mainline and then backport the fix here...

Best regards,

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

From: Fabrizio Castro <fabrizio.castro@...>

commit ae56c940f188c1dde440c8456229adaad733908e upstream.

The EK874 is advertised as compatible with panel IDK-2121WR from
Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
to work with the EK874, is the most convenient way to support the
EK874 when it's connected to the IDK-2121WR.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Acked-by: Laurent Pinchart <laurent.pinchart@...>
Link: https://lore.kernel.org/r/1576590361-28244-7-git-send-email-fabrizio.castro@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Biju Das <biju.das.jz@...>
---
arch/arm64/boot/dts/renesas/Makefile | 3 +-
.../dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 ++++++++++++++++++
2 files changed, 118 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts

diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index c05feec80636..d22ede9e3ee4 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -4,7 +4,8 @@ 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
+dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb \
+ r8a774c0-ek874-idk-2121wr.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-h3ulcb-kf.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-xs.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
new file mode 100644
index 000000000000..a7b27d09f6c2
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Silicon Linux RZ/G2E evaluation kit (EK874),
+ * connected to an Advantech IDK-2121WR 21.5" LVDS panel
+ *
+ * Copyright (C) 2019 Renesas Electronics Corp.
+ */
+
+#include "r8a774c0-ek874.dts"
+
+/ {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm5 0 50000>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+
+ power-supply = <&reg_12p0v>;
+ enable-gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <44>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in0: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in1: endpoint {
+ remote-endpoint = <&lvds1_out>;
+ };
+ };
+ };
+ };
+};
+
+&gpio0 {
+ /*
+ * When GP0_17 is low LVDS[01] are connected to the LVDS connector
+ * When GP0_17 is high LVDS[01] are connected to the LT8918L
+ */
+ lvds-connector-en-gpio{
+ gpio-hog;
+ gpios = <17 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lvds-connector-en-gpio";
+ };
+};
+
+&lvds0 {
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in0>;
+ };
+ };
+ };
+};
+
+&lvds1 {
+ status = "okay";
+
+ clocks = <&cpg CPG_MOD 727>, <&x13_clk>, <&extal_clk>;
+ clock-names = "fck", "dclkin.0", "extal";
+
+ ports {
+ port@1 {
+ lvds1_out: endpoint {
+ remote-endpoint = <&panel_in1>;
+ };
+ };
+ };
+};
+
+&pfc {
+ pwm5_pins: pwm5 {
+ groups = "pwm5_a";
+ function = "pwm5";
+ };
+};
+
+&pwm5 {
+ pinctrl-0 = <&pwm5_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
2.17.1