Date   

Bluetooth CVEs deciphered?

Pavel Machek
 

Hi!

I believe Google has good information which CVE corresponds to which
patch, and I used that to improve cip-kernel-sec. Result is here. Can
you take a look before I start fighting yml?

Best regards,
Pavel

diff --git a/issues/CVE-2020-12351.yml b/issues/CVE-2020-12351.yml
index 63f8b60..b7f519b 100644
--- a/issues/CVE-2020-12351.yml
+++ b/issues/CVE-2020-12351.yml
@@ -1,37 +1,9 @@
-description: INTEL-SA-00435
+description: |
+ A heap-based type confusion affecting Linux kernel 4.8 and higher was discovered in net/bluetooth/l2cap_core.c.
+advisory: |
references:
-- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
-comments:
- debian/carnil: |-
- CVE-2020-12351, CVE-2020-12352 and CVE-2020-24490 are three
- issues covered by a set of commits/patches sent upstream but
- there is no clear association from the CVEs to the commits. So
- duplicate this entry for now to all three CVEs.
- The commits are:
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-2-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
- which are not yet in mainline, and
- a2ec905d1e16 ("Bluetooth: fix kernel oops in
- store_pending_adv_report") which is in 5.8 (and which was
- backported to 5.7.13, 5.4.56 and 4.19.137).
- The "fixed version" information in INTEL-SA-00435 is thus as
- well contradictory as it mentions the issue to be fixed in 5.9
- or later.
- wens: |-
- The four patches are already in net-next as of 2020-10-14 and should hit
- mainline soon. As far as I can tell, ("Bluetooth: A2MP: Fix not
- initializing all members") fixes commits going all the way back to
- 3.6, when A2MP was added.
- Regarding the culprit commits, the first commit is fixed by a2ec905d1e16
- ("Bluetooth: fix kernel oops in store_pending_adv_report"); the next
- nine are the various "not fully initialized stack variables"; the last
- two are the sk_filter and BT_HS ones, respectfully.
+ https://github.com/google/security-research/security/advisories/GHSA-h637-c88j-47wq
+aliases:
+ GHSA-h637-c88j-47wq
introduced-by:
- mainline: [c215e9397b00b3045a668120ed7dbd89f2866e74, 6b44d9b8d96b37f72ccd7335b32f386a67b7f1f4,
- a28381dc9ca3e54b0678e2cd7c68c1afb2d7cc76, e072f5dab22e7bf0a10daf854acc0fc271396ee7,
- 6113f84fc1a8962aed25f54a115b196e9aea151f, 8e2a0d92c56ec6955526a8b60838c9b00f70540d,
- aa09537d80bf7e6282103618eb496f03e76f2953, 0d868de9d8760c76f6d4c6c777935c05ef272caa,
- 8e05e3ba88adcf7ac644e6ef26676ea7c048a08c, 93c3e8f5c9a0e4dc6b6c93108dcf3ec54ab1191a,
- dbb50887c8f619fc5c3489783ebc3122bc134a31, 6d80dfd094a7b286e95cdcac79efeb7bbb4e226f]
+ mainline: dbb50887c8f619fc5c3489783ebc3122bc134a31
diff --git a/issues/CVE-2020-12352.yml b/issues/CVE-2020-12352.yml
index 63f8b60..372e3ce 100644
--- a/issues/CVE-2020-12352.yml
+++ b/issues/CVE-2020-12352.yml
@@ -1,37 +1,13 @@
-description: INTEL-SA-00435
+description: |
+ BadChoice: Stack-Based Information Leak (BleedingTooth)
+ A stack-based information leak affecting Linux kernel 3.6 and higher was discovered in net/bluetooth/a2mp.c.
+advisory: |
references:
-- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
-comments:
- debian/carnil: |-
- CVE-2020-12351, CVE-2020-12352 and CVE-2020-24490 are three
- issues covered by a set of commits/patches sent upstream but
- there is no clear association from the CVEs to the commits. So
- duplicate this entry for now to all three CVEs.
- The commits are:
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-2-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
- which are not yet in mainline, and
- a2ec905d1e16 ("Bluetooth: fix kernel oops in
- store_pending_adv_report") which is in 5.8 (and which was
- backported to 5.7.13, 5.4.56 and 4.19.137).
- The "fixed version" information in INTEL-SA-00435 is thus as
- well contradictory as it mentions the issue to be fixed in 5.9
- or later.
- wens: |-
- The four patches are already in net-next as of 2020-10-14 and should hit
- mainline soon. As far as I can tell, ("Bluetooth: A2MP: Fix not
- initializing all members") fixes commits going all the way back to
- 3.6, when A2MP was added.
- Regarding the culprit commits, the first commit is fixed by a2ec905d1e16
- ("Bluetooth: fix kernel oops in store_pending_adv_report"); the next
- nine are the various "not fully initialized stack variables"; the last
- two are the sk_filter and BT_HS ones, respectfully.
+ https://github.com/google/security-research/security/advisories/GHSA-7mh3-gq28-gfrq
+aliases:
+ GHSA-7mh3-gq28-gfrq
introduced-by:
- mainline: [c215e9397b00b3045a668120ed7dbd89f2866e74, 6b44d9b8d96b37f72ccd7335b32f386a67b7f1f4,
- a28381dc9ca3e54b0678e2cd7c68c1afb2d7cc76, e072f5dab22e7bf0a10daf854acc0fc271396ee7,
- 6113f84fc1a8962aed25f54a115b196e9aea151f, 8e2a0d92c56ec6955526a8b60838c9b00f70540d,
- aa09537d80bf7e6282103618eb496f03e76f2953, 0d868de9d8760c76f6d4c6c777935c05ef272caa,
- 8e05e3ba88adcf7ac644e6ef26676ea7c048a08c, 93c3e8f5c9a0e4dc6b6c93108dcf3ec54ab1191a,
- dbb50887c8f619fc5c3489783ebc3122bc134a31, 6d80dfd094a7b286e95cdcac79efeb7bbb4e226f]
+ mainline:
+ 47f2d97d38816aaca94c9b6961c6eff1cfcd0bd6
+ 8e2a0d92c56ec6955526a8b60838c9b00f70540d
+fixed-by:
\ No newline at end of file
diff --git a/issues/CVE-2020-24490.yml b/issues/CVE-2020-24490.yml
index 63f8b60..8fe3617 100644
--- a/issues/CVE-2020-24490.yml
+++ b/issues/CVE-2020-24490.yml
@@ -1,37 +1,25 @@
-description: INTEL-SA-00435
+description: |
+ BadVibes: Heap-Based Buffer Overflow (BleedingTooth)
+ A heap-based buffer overflow affecting Linux kernel 4.19 and higher was discovered in net/bluetooth/hci_event.c.
+advisory: |
+
references:
-- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
+ https://github.com/google/security-research/security/advisories/GHSA-ccx2-w2r4-x649
+aliases:
+ GHSA-ccx2-w2r4-x649
comments:
- debian/carnil: |-
- CVE-2020-12351, CVE-2020-12352 and CVE-2020-24490 are three
- issues covered by a set of commits/patches sent upstream but
- there is no clear association from the CVEs to the commits. So
- duplicate this entry for now to all three CVEs.
- The commits are:
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-2-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
- which are not yet in mainline, and
- a2ec905d1e16 ("Bluetooth: fix kernel oops in
- store_pending_adv_report") which is in 5.8 (and which was
- backported to 5.7.13, 5.4.56 and 4.19.137).
- The "fixed version" information in INTEL-SA-00435 is thus as
- well contradictory as it mentions the issue to be fixed in 5.9
- or later.
- wens: |-
- The four patches are already in net-next as of 2020-10-14 and should hit
- mainline soon. As far as I can tell, ("Bluetooth: A2MP: Fix not
- initializing all members") fixes commits going all the way back to
- 3.6, when A2MP was added.
- Regarding the culprit commits, the first commit is fixed by a2ec905d1e16
- ("Bluetooth: fix kernel oops in store_pending_adv_report"); the next
- nine are the various "not fully initialized stack variables"; the last
- two are the sk_filter and BT_HS ones, respectfully.
+ Pavel Machek:
+ This actually looks like most severe from the recent bluetooth stuff.
+
+ Fix is not one-liner but also not scary. Adds checking at expected places.
introduced-by:
- mainline: [c215e9397b00b3045a668120ed7dbd89f2866e74, 6b44d9b8d96b37f72ccd7335b32f386a67b7f1f4,
- a28381dc9ca3e54b0678e2cd7c68c1afb2d7cc76, e072f5dab22e7bf0a10daf854acc0fc271396ee7,
- 6113f84fc1a8962aed25f54a115b196e9aea151f, 8e2a0d92c56ec6955526a8b60838c9b00f70540d,
- aa09537d80bf7e6282103618eb496f03e76f2953, 0d868de9d8760c76f6d4c6c777935c05ef272caa,
- 8e05e3ba88adcf7ac644e6ef26676ea7c048a08c, 93c3e8f5c9a0e4dc6b6c93108dcf3ec54ab1191a,
- dbb50887c8f619fc5c3489783ebc3122bc134a31, 6d80dfd094a7b286e95cdcac79efeb7bbb4e226f]
+ mainline:
+ c215e9397b00b3045a668120ed7dbd89f2866e74
+ b2cc9761f144e8ef714be8c590603073b80ddc13
+fixed-by:
+ mainline:
+ a2ec905d1e160a33b2e210e45ad30445ef26ce0e
+ 4.19:
+ 5df9e5613d1c51e16b1501a4c75e139fbbe0fb6c
+ -- needs to be backported to 4.4?
+
\ No newline at end of file

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


Re: [RFC PATCH 4.19.y-cip 41/50] PCI: rcar: Add endpoint mode support

Pavel Machek
 

Hi!

Plain 0 would be enough
Agreed.

Ill post patches upstream to fix this and then backport or do you
want me to do the changes in place ?
Yes, thank you.

+val |= ASTINTX;
+rcar_pci_write_reg(pcie, val, PCIEINTXR);
+usleep_range(1000, 1001);
+val = rcar_pci_read_reg(pcie, PCIEINTXR);
This is crazy. Either you need exact timing or you don't, but I don't
believe usleep can guarantee microsecond accuracy.

(And you probably don't need it, right?)
Indeed a sleep is needed but checkpatch complains about it so usleep_range() was added.
checkpatch should not be an excuse for crazy code... and this one is
crazy.

Sleep has nowhere near microsecond accuracy. If you can tolerate
bigger delay, feel free to specify reasonable range. But in this case
you probably want "as close as possible to 1msec", and no,
usleep_range is not right primitive for that.

Best regards,
Pavel

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


Re: [RFC PATCH 4.19.y-cip 41/50] PCI: rcar: Add endpoint mode support

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 14 October 2020 10:22
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>; Biju Das
<biju.das.jz@bp.renesas.com>
Subject: Re: [RFC PATCH 4.19.y-cip 41/50] PCI: rcar: Add endpoint mode support

Hi!

commit 2a6d0d63d99956a66f6605832f11755d74a41951 upstream.

Add support for R-Car PCIe controller to work in endpoint mode.
+ep->ob_window[i].phys_base = res->start;
+ep->ob_window[i].size = resource_size(res);
+/* controller doesn't support multiple allocation
+ * from same window, so set page_size to window size
+ */
Comment not according to CodingStyle.
Yep
+memset(&win, 0x0, sizeof(win));
+memset(&res, 0x0, sizeof(res));
Plain 0 would be enough
Agreed.

Ill post patches upstream to fix this and then backport or do you want me to do the changes in place ?

+val |= ASTINTX;
+rcar_pci_write_reg(pcie, val, PCIEINTXR);
+usleep_range(1000, 1001);
+val = rcar_pci_read_reg(pcie, PCIEINTXR);
This is crazy. Either you need exact timing or you don't, but I don't
believe usleep can guarantee microsecond accuracy.

(And you probably don't need it, right?)
Indeed a sleep is needed but checkpatch complains about it so usleep_range() was added.

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: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 14 October 2020 11:08
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>; Biju Das
<biju.das.jz@bp.renesas.com>
Subject: Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Hi!

* I was skeptic with patch 36/50 "Rename pcie-rcar.c to pcie-rcar-host.c"
this is required as patch 38/50 adds a new file named pcie-rcar.c. Open
for suggestions if this can be handled differently.
* In patch 37/48 I have dropped the changes for host driver as the patch
doesn't apply cleanly and manually applying it was resulting in a
big diff.
I have no good ideas how to avoid rename.

Given the change in locking previously in the series, manual review of
changes in this area might be good idea, anyway.
The locking changes are wrt EPF framework anyway. OK so I assume you are happy to manual changes to PCIe host driver while posting non RFC version.

In 4.19, there were 75 patches in this area so far, and 5 patches that
would reject due to the rename.

pavel@amd:~/cip/krc$ git log --pretty=oneline v4.19.. drivers/pci/controller/ | wc -l
75
pavel@amd:~/cip/krc$ git log --pretty=oneline v4.19.. drivers/pci/controller/pcie-rcar*.c | wc -l
5

...so we'll get a bit of additional workload from this. It would be
more scary if there were -rt specific changes in this area, but
hopefully there are none.

I expect that you are willing to help if -stable or -rt introduces
conflicting patches in this area?
indeed.

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: If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

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: 14 October 2020 10:39
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>; Biju Das
<biju.das.jz@bp.renesas.com>
Subject: [cip-dev] If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and
RZ/G2x

Hi!

This patch series adds support for PCIe EP on Renesas R-Car Gen3 and
RZ/G2x platforms.
I quickly went through a series and code seems reasonably nice.
Thank you for the review. That’s a relief 😊

* Since the changes are huge I am sending the patches as RFC.
And yes, it is quite big, which might be a problem. OTOH only Renesas
seems to have PCIe EP drivers enabled in their CIP defconfigs, so
there's good chance noone else in CIP project is using this code.
Fingers crossed.

[If someone else _is_ using it or is considering using it, please
speak up.]

Could we get better explanation for 24/ of the series? spinlock is
okay as long as code inside does not sleep, does not neccessarily have
to do with interrupts.
Sure this was cherry picked from upstream I haven’t modified the description. Moreover this I had include because the subsequent patches could apply cleanly.

Do want me to just elaborate the commit message you mean ?

Should 30/ and 31/ be submitted to stable?
Yes I do agree.

* Required EP framework changes and fixes are ported as well.
* All the patches have been cheery picked from upstream kernel.
* Patches [43, 44, 45, 46, 48]/50 are picked from linux-next.
Ok, so we definitely want them in upstream, not in -next. And it might
be good to wait a bit after merge, so it gets some testing in upstream.
Sure Ill wait for them, (fyi these are just dt binding documentation and PCI-ID addition patches)

* I was skeptic with patch 36/50 "Rename pcie-rcar.c to pcie-rcar-host.c"
this is required as patch 38/50 adds a new file named pcie-rcar.c. Open
for suggestions if this can be handled differently.
* In patch 37/48 I have dropped the changes for host driver as the patch
doesn't apply cleanly and manually applying it was resulting in a
big diff.
Let me take a look at these in bigger detail.
Sure.

* As the changes touches three other controller drivers I have build tested them
as done similarly while upstreaming R-Car Gen3 PCIe EP driver.
Will this be tested somehow by our automated tests?
You mean the R-Car Gen3 PCIe EP driver ?

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


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=10&day=15&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/10/cip.2020-10-08-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Check whether CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 needs to be backported to 4.4 - masashi910

* Kernel maintenance updates
* Kernel testing
* 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: Backporting of security patches for Intel i40e drivers required?

Chen-Yu Tsai (Moxa) <wens@...>
 

On Wed, Oct 14, 2020 at 10:14 PM Pavel Machek <pavel@denx.de> wrote:

Hi!

given the exposure of such a device but also the fact that I can't tell
for sure if/where it's used (not only by us), I would recommend backporting.
There are multiple patches fixed for 4.19, which can be separated by feature.

- i40e: add num_vectors checker in iwarp handler

This issue has been produced by e3219ce6a7754 ("i40e: Add support for client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.
It is interesting this one is listed in both CVE-145, CVE-147 in
cip-kernel-sec. Is that an error?
Given that Intel's security notice did not state which patches fixed which
issues, nor which commits caused them, I tried to guess which patch fixed
which issue, based solely on their descriptions. Then I looked at the history
of the driver to see which commit the patches fixed.

Grouping by feature is probably a better way to determine if the backport
is required or not.

ChenYu

- i40e: Wrong truncation from u16 to u8
This can be apply in 4.4.y.

- i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c

This issue has been produced by e284fc280473b ("i40e: Add and delete cloud filter").
It is not included in 4.4.y. However, this patch has several different fixes, so some patches need to be applied.
I see also

- i40e: Set RX_ONLY mode for unicast promiscuous on VLAN

which apparently allows people to listen to packets they should not
see. But I assume this requires elevated priviledges to begin with...

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


Re: Backporting of security patches for Intel i40e drivers required?

Pavel Machek
 

Hi!

given the exposure of such a device but also the fact that I can't tell
for sure if/where it's used (not only by us), I would recommend backporting.
There are multiple patches fixed for 4.19, which can be separated by feature.

- i40e: add num_vectors checker in iwarp handler

This issue has been produced by e3219ce6a7754 ("i40e: Add support for client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.
It is interesting this one is listed in both CVE-145, CVE-147 in
cip-kernel-sec. Is that an error?

- i40e: Wrong truncation from u16 to u8
This can be apply in 4.4.y.

- i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c

This issue has been produced by e284fc280473b ("i40e: Add and delete cloud filter").
It is not included in 4.4.y. However, this patch has several different fixes, so some patches need to be applied.
I see also

- i40e: Set RX_ONLY mode for unicast promiscuous on VLAN

which apparently allows people to listen to packets they should not
see. But I assume this requires elevated priviledges to begin with...

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


Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Pavel Machek
 

Hi!

* I was skeptic with patch 36/50 "Rename pcie-rcar.c to pcie-rcar-host.c"
this is required as patch 38/50 adds a new file named pcie-rcar.c. Open
for suggestions if this can be handled differently.
* In patch 37/48 I have dropped the changes for host driver as the patch
doesn't apply cleanly and manually applying it was resulting in a
big diff.
I have no good ideas how to avoid rename.

Given the change in locking previously in the series, manual review of
changes in this area might be good idea, anyway.

In 4.19, there were 75 patches in this area so far, and 5 patches that
would reject due to the rename.

pavel@amd:~/cip/krc$ git log --pretty=oneline v4.19.. drivers/pci/controller/ | wc -l
75
pavel@amd:~/cip/krc$ git log --pretty=oneline v4.19.. drivers/pci/controller/pcie-rcar*.c | wc -l
5

...so we'll get a bit of additional workload from this. It would be
more scary if there were -rt specific changes in this area, but
hopefully there are none.

I expect that you are willing to help if -stable or -rt introduces
conflicting patches in this area?

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


If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Pavel Machek
 

Hi!

This patch series adds support for PCIe EP on Renesas R-Car Gen3 and
RZ/G2x platforms.
I quickly went through a series and code seems reasonably nice.

* Since the changes are huge I am sending the patches as RFC.
And yes, it is quite big, which might be a problem. OTOH only Renesas
seems to have PCIe EP drivers enabled in their CIP defconfigs, so
there's good chance noone else in CIP project is using this code.

[If someone else _is_ using it or is considering using it, please
speak up.]

Could we get better explanation for 24/ of the series? spinlock is
okay as long as code inside does not sleep, does not neccessarily have
to do with interrupts.

Should 30/ and 31/ be submitted to stable?

* Required EP framework changes and fixes are ported as well.
* All the patches have been cheery picked from upstream kernel.
* Patches [43, 44, 45, 46, 48]/50 are picked from linux-next.
Ok, so we definitely want them in upstream, not in -next. And it might
be good to wait a bit after merge, so it gets some testing in upstream.

* I was skeptic with patch 36/50 "Rename pcie-rcar.c to pcie-rcar-host.c"
this is required as patch 38/50 adds a new file named pcie-rcar.c. Open
for suggestions if this can be handled differently.
* In patch 37/48 I have dropped the changes for host driver as the patch
doesn't apply cleanly and manually applying it was resulting in a
big diff.
Let me take a look at these in bigger detail.

* As the changes touches three other controller drivers I have build tested them
as done similarly while upstreaming R-Car Gen3 PCIe EP driver.
Will this be tested somehow by our automated tests?

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


Re: [RFC PATCH 4.19.y-cip 41/50] PCI: rcar: Add endpoint mode support

Pavel Machek
 

Hi!

commit 2a6d0d63d99956a66f6605832f11755d74a41951 upstream.

Add support for R-Car PCIe controller to work in endpoint mode.
+ ep->ob_window[i].phys_base = res->start;
+ ep->ob_window[i].size = resource_size(res);
+ /* controller doesn't support multiple allocation
+ * from same window, so set page_size to window size
+ */
Comment not according to CodingStyle.

+ memset(&win, 0x0, sizeof(win));
+ memset(&res, 0x0, sizeof(res));
Plain 0 would be enough


+ val |= ASTINTX;
+ rcar_pci_write_reg(pcie, val, PCIEINTXR);
+ usleep_range(1000, 1001);
+ val = rcar_pci_read_reg(pcie, PCIEINTXR);
This is crazy. Either you need exact timing or you don't, but I don't
believe usleep can guarantee microsecond accuracy.

(And you probably don't need it, right?)

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


Re: [cip-kernel-sec 3/3] issues: fill in the description field of remaining CVEs

Chen-Yu Tsai (Moxa) <wens@...>
 

On Wed, Oct 14, 2020 at 12:16 PM Daniel Sangorrin
<daniel.sangorrin@toshiba.co.jp> wrote:

Hello Chen-yu,

Thanks for your check.

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Chen-Yu Tsai (Moxa)
Sent: Thursday, October 8, 2020 5:19 PM
To: cip-dev@lists.cip-project.org
Cc: SZ Lin (林上智) <sz.lin@moxa.com>; Ben Hutchings <ben.hutchings@codethink.co.uk>
Subject: Re: [cip-dev] [cip-kernel-sec 3/3] issues: fill in the description field of remaining CVEs

On Fri, Sep 25, 2020 at 12:01 PM Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp> wrote:

From: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>

I noticed that some issues have the description field empty when using
the --show-description option.

Signed-off-by: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Looks like all the new descriptions were copied from MITRE.

Reviewed-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
Is there a problem with that?
The MITRE license is included in the COPYING file as far as I know.
Not at all. I'm merely stating that the descriptions match a known source.

ChenYu


Re: [cip-kernel-sec 3/3] issues: fill in the description field of remaining CVEs

Daniel Sangorrin <daniel.sangorrin@...>
 

Hello Chen-yu,

Thanks for your check.

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Chen-Yu Tsai (Moxa)
Sent: Thursday, October 8, 2020 5:19 PM
To: cip-dev@lists.cip-project.org
Cc: SZ Lin (林上智) <sz.lin@moxa.com>; Ben Hutchings <ben.hutchings@codethink.co.uk>
Subject: Re: [cip-dev] [cip-kernel-sec 3/3] issues: fill in the description field of remaining CVEs

On Fri, Sep 25, 2020 at 12:01 PM Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp> wrote:

From: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>

I noticed that some issues have the description field empty when using
the --show-description option.

Signed-off-by: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Looks like all the new descriptions were copied from MITRE.

Reviewed-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
Is there a problem with that?
The MITRE license is included in the COPYING file as far as I know.

Thanks,
Daniel


FW: [Automated-testing] RFC: dashboards, visualization and analytics for test results

Chris Paterson
 

FYI

Please feel free to add any use cases or comments to the mail thread below from KernelCI.

Kind regards, Chris

From: automated-testing@lists.yoctoproject.org <automated-
testing@lists.yoctoproject.org> On Behalf Of Kevin Hilman via
lists.yoctoproject.org
Sent: 07 October 2020 18:48
To: automated-testing@lists.yoctoproject.org; kernelci@groups.io
Cc: tools@linux.kernel.org
Subject: [Automated-testing] RFC: dashboards, visualization and analytics for
test results

Hello folks interested in kernel testing/automation,

The KernelCI project is starting to look at what's next for dashboards,
visualization and analytics for the various Linux focused testing
projects.

At Linux Plumbers, we launched some discussions[1] around common ways
to
collect test results, logs and metadata into a public, shared dataset,
and we've already started collecting data from several different
sources.

So the next question is... how do we best use all of this data?

We're beginning to brainstorm how to visualize, analyze and learn from
this data in useful ways.

To that end, we're starting to collect a set of user stories to help us
brainstorm a new design for web based dashboard and analytics, and we'd
like to hear from you.

Below is the start of a list of user stories[2], but we want to grow
this list with your ideas, so please share them on this thread.

We're also very interested in talking with any big data people and data
scientists who might be willing to look at this growing set of data and
help us better plan for the future full of lots of test data.

We appreciate your ideas and feedback,

Kevin (on behalf of the KernelCI team)


[1] c.f. Unifying Test Reporting with KernelCI from the testing/fuzzing
micro-conference:
https://linuxplumbersconf.org/event/7/sessions/80/#20200826



[2] Example user stories

A kernel developer has sent a patch which caused a regression
- Find the details, how to reproduce, check when it’s fixed

A maintainer is getting a branch ready for the next merge window
- Compare results against mainline, ensure all tests were run correctly

An OEM or SoC vendor needs to upgrade their kernel or move to upstream
- See all results for a particular platform on various stable releases

Regular visitors who want to know how the kernel is doing
- Highlight new regressions, show trends for pass/fail and performance
- Does kernel X work on my hardware?

Distro vendor wants to know
- Is the latest kernel stable enough for my distro?
- Why does this test fail on my distro kernel but not stable kernel?

Stable kernel maintainer wants to know
- Is this kernel stable enough to release?

Kernel / subsystem maintainer wants to know
- Is my code/subsystem being tested? How much coverage?
- Is the kernel size growing? Why? Which subsystems
- Is boot time / test execution time increasing/decreasing? What are the
historical trends?


[RFC PATCH 4.19.y-cip 50/50] tools: PCI: Fix fd leakage

Lad Prabhakar
 

From: Hewenliang <hewenliang4@huawei.com>

commit 3c379a59b4795d7279d38c623e74b9790345a32b upstream.

We should close fd before the return of run_test.

Fixes: 3f2ed8134834 ("tools: PCI: Add a userspace tool to test PCI endpoint")
Signed-off-by: Hewenliang <hewenliang4@huawei.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
tools/pci/pcitest.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c
index b7e3b6a64956..9f3d2e584ce4 100644
--- a/tools/pci/pcitest.c
+++ b/tools/pci/pcitest.c
@@ -140,6 +140,7 @@ static int run_test(struct pci_test *test)
}

fflush(stdout);
+ close(fd);
return (ret < 0) ? ret : 1 - ret; /* return 0 if test succeeded */
}

--
2.17.1


[RFC PATCH 4.19.y-cip 49/50] tools: PCI: Exit with error code when test fails

Lad Prabhakar
 

From: Jean-Jacques Hiblot <jjhiblot@ti.com>

commit b71f0a0b1e3fea212a6a5042ced8b48a81738ac9 upstream.

This makes it easier to use pcitest in automated setups.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
tools/pci/pcitest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c
index 4c5be77c211f..b7e3b6a64956 100644
--- a/tools/pci/pcitest.c
+++ b/tools/pci/pcitest.c
@@ -140,6 +140,7 @@ static int run_test(struct pci_test *test)
}

fflush(stdout);
+ return (ret < 0) ? ret : 1 - ret; /* return 0 if test succeeded */
}

int main(int argc, char **argv)
@@ -228,6 +229,5 @@ int main(int argc, char **argv)
return -EINVAL;
}

- run_test(test);
- return 0;
+ return run_test(test);
}
--
2.17.1


[RFC PATCH 4.19.y-cip 48/50] misc: pci_endpoint_test: Add Device ID for RZ/G2M and RZ/G2N PCIe controllers

Lad Prabhakar
 

commit cfb824ddd1c040a7ac65eea3f900f14268e8f383 upstream.

Add Renesas R8A774A1 and R8A774B1 in pci_device_id table so that
pci-epf-test can be used for testing PCIe EP on RZ/G2M and RZ/G2N.

Link: https://lore.kernel.org/r/20200814173037.17822-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
[PL: Manually applied changes]
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/misc/pci_endpoint_test.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index aff8cbca5d18..a1083f568d2c 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -80,6 +80,8 @@
#define is_am654_pci_dev(pdev) \
((pdev)->device == PCI_DEVICE_ID_TI_AM654)

+#define PCI_DEVICE_ID_RENESAS_R8A774A1 0x0028
+#define PCI_DEVICE_ID_RENESAS_R8A774B1 0x002b
#define PCI_DEVICE_ID_RENESAS_R8A774C0 0x002d

static DEFINE_IDA(pci_endpoint_test_ida);
@@ -816,8 +818,9 @@ static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
.driver_data = (kernel_ulong_t)&am654_data
},
- { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774C0),
- },
+ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774A1),},
+ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774B1),},
+ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774C0),},
{ }
};
MODULE_DEVICE_TABLE(pci, pci_endpoint_test_tbl);
--
2.17.1


[RFC PATCH 4.19.y-cip 47/50] misc: pci_endpoint_test: Add Device ID for RZ/G2E PCIe controller

Lad Prabhakar
 

commit b03025c57396b23fe2423384c25aa580000e9883 upstream.

Add Renesas R8A774C0 in pci_device_id table so that pci-epf-test can be
used for testing PCIe EP on RZ/G2E.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/1589493809-2602-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/misc/pci_endpoint_test.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 7d166f57f624..aff8cbca5d18 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -80,6 +80,8 @@
#define is_am654_pci_dev(pdev) \
((pdev)->device == PCI_DEVICE_ID_TI_AM654)

+#define PCI_DEVICE_ID_RENESAS_R8A774C0 0x002d
+
static DEFINE_IDA(pci_endpoint_test_ida);

#define to_endpoint_test(priv) container_of((priv), struct pci_endpoint_test, \
@@ -814,6 +816,8 @@ static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
.driver_data = (kernel_ulong_t)&am654_data
},
+ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774C0),
+ },
{ }
};
MODULE_DEVICE_TABLE(pci, pci_endpoint_test_tbl);
--
2.17.1


[RFC PATCH 4.19.y-cip 46/50] arm64: dts: renesas: r8a774b1: Add PCIe EP nodes

Lad Prabhakar
 

commit d12d16205f7993da195002eea24b7467deb9ac8c upstream.

Add PCIe EP nodes to R8A774B1 (RZ/G2N) SoC dtsi.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20200814173037.17822-5-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 38 +++++++++++++++++++++++
1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 62d011107cc5..b48bf2aed612 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -1973,6 +1973,44 @@
status = "disabled";
};

+ pciec0_ep: pcie-ep@fe000000 {
+ compatible = "renesas,r8a774b1-pcie-ep",
+ "renesas,rcar-gen3-pcie-ep";
+ reg = <0x0 0xfe000000 0 0x80000>,
+ <0x0 0xfe100000 0 0x100000>,
+ <0x0 0xfe200000 0 0x200000>,
+ <0x0 0x30000000 0 0x8000000>,
+ <0x0 0x38000000 0 0x8000000>;
+ reg-names = "apb-base", "memory0", "memory1", "memory2", "memory3";
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 319>;
+ clock-names = "pcie";
+ resets = <&cpg 319>;
+ power-domains = <&sysc R8A774B1_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ pciec1_ep: pcie-ep@ee800000 {
+ compatible = "renesas,r8a774b1-pcie-ep",
+ "renesas,rcar-gen3-pcie-ep";
+ reg = <0x0 0xee800000 0 0x80000>,
+ <0x0 0xee900000 0 0x100000>,
+ <0x0 0xeea00000 0 0x200000>,
+ <0x0 0xc0000000 0 0x8000000>,
+ <0x0 0xc8000000 0 0x8000000>;
+ reg-names = "apb-base", "memory0", "memory1", "memory2", "memory3";
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 318>;
+ clock-names = "pcie";
+ resets = <&cpg 318>;
+ power-domains = <&sysc R8A774B1_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
fdp1@fe940000 {
compatible = "renesas,fdp1";
reg = <0 0xfe940000 0 0x2400>;
--
2.17.1


[RFC PATCH 4.19.y-cip 45/50] arm64: dts: renesas: r8a774a1: Add PCIe EP nodes

Lad Prabhakar
 

commit 578450883bb1ff878ac8e3d38060802b222adcbe upstream.

Add PCIe EP nodes to R8A774A1 (RZ/G2M) SoC dtsi.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20200814173037.17822-4-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 38 +++++++++++++++++++++++
1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 16166f3b66a0..90f5fb49957e 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -2115,6 +2115,44 @@
status = "disabled";
};

+ pciec0_ep: pcie-ep@fe000000 {
+ compatible = "renesas,r8a774a1-pcie-ep",
+ "renesas,rcar-gen3-pcie-ep";
+ reg = <0x0 0xfe000000 0 0x80000>,
+ <0x0 0xfe100000 0 0x100000>,
+ <0x0 0xfe200000 0 0x200000>,
+ <0x0 0x30000000 0 0x8000000>,
+ <0x0 0x38000000 0 0x8000000>;
+ reg-names = "apb-base", "memory0", "memory1", "memory2", "memory3";
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 319>;
+ clock-names = "pcie";
+ resets = <&cpg 319>;
+ power-domains = <&sysc R8A774A1_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ pciec1_ep: pcie-ep@ee800000 {
+ compatible = "renesas,r8a774a1-pcie-ep",
+ "renesas,rcar-gen3-pcie-ep";
+ reg = <0x0 0xee800000 0 0x80000>,
+ <0x0 0xee900000 0 0x100000>,
+ <0x0 0xeea00000 0 0x200000>,
+ <0x0 0xc0000000 0 0x8000000>,
+ <0x0 0xc8000000 0 0x8000000>;
+ reg-names = "apb-base", "memory0", "memory1", "memory2", "memory3";
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 318>;
+ clock-names = "pcie";
+ resets = <&cpg 318>;
+ power-domains = <&sysc R8A774A1_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
fdp1@fe940000 {
compatible = "renesas,fdp1";
reg = <0 0xfe940000 0 0x2400>;
--
2.17.1

1881 - 1900 of 7464