Dear CIP friends,

this is the report of the major actions related with those activities led by Codethink Ltd. Some of the reported topics were already communicated through this mailing list.

++ Kernel maintenance

1. Backported of the basic support for the Renesas board (family) has been merged.

2. The first round of kernel features review has been provided. Some feedback is still pending. Ben H. participated in the CIP TSC bi-weekly call.

3. Now we need to define the next steps in the kernel maintenance front.

4. As usual, Ben H. is contributing to the upstream 4.4 LTS cycle.

++ CIP Testing

1. E-mail configuration in LAVA is done. Robert Marshall is publishing the outcome of the basic health checks in the cip-testing-results mailing list. Feel free to join: https://lists.cip-project.org/mailman/listinfo/cip-testing-results The documentation for CIP members to send reports through mail is work in progress. https://gitlab.com/cip-project/cip-testing/testing/issues/102

2. B@D now works on a W10 machine with little additional configurations. Both, Windows and Linux users share the same installations and configuration steps except when specifically mentioned. Waiting to receive feedback from Members. https://gitlab.com/cip-project/cip-testing/testing/issues/106

3. A change in git://git.linaro.org/qa/test-definitions.git had a major impact in B@D. It has been fixed now. https://gitlab.com/cip-project/cip-testing/testing/issues/116

4. There is progress in using B@D behind a web proxy. https://gitlab.com/cip-project/cip-testing/testing/issues/99

5. Robert has started the trials to update the LAVA version shipped with B@D. It includes several fixed to issues we are facing plus several improvements we will need in the near future. https://gitlab.com/cip-project/cip-testing/testing/issues/114

6. Other topics

* Some weeks ago we reported to the LAVA team an issue that has already been fixed upstream. Another good reason for updating LAVA. https://gitlab.com/cip-project/cip-testing/testing/issues/84

* Several issues has been fixed like tickets #112, #92

* As reported, new repositories has been created and populated. https://gitlab.com/cip-project/cip-testing/testing/issues/100
** We are starting to populate CIP-kernel-test-logs repository as a first step towards publishing the "passed test" logs in a public repo in order to compare the logs from tests done by other Members.

* There is no room for celebrating the CIP workshop at ELCE during the even. We will need to include it the previous day, right after the CIP TSC f2f meeting.

* At least Agustin B.B. and Ben H. will attend to ELCE.

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...

Hi Ben,

Thanks for the consideration and suggestion.

From: Ben Hutchings
Performance events (CONFIG_PERF_EVENTS) provide a significant attack
surface and generally allow unprivileged users to crash the system. If
you do need them enabled in production - which I can understand - you
might want to apply the Grsecurity/Debian/Android patch that disables
use by unprivileged users.

Is it difficult to support for super long term? I think it is up to
users to enable it or not.

User namespaces (CONFIG_USER_NS) open up a huge attack surface to
unprivileged users, which has resulted in a large number of privilege
escalation vulnerabilities. This is enabled in the plathome_obsvx1,
siemens_iot2000 and siemens_server configs. Do you need it?

I'm not sure how vulnerable it is, but I think we may want to adopt the
same approach with the CONFIG_PERF_EVENTS case.
https://github.com/copperhead/linux-hardened/commit/358b303ebdc0b4a74b66a41ddfd2a69322d5404a.patch

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

Hello Ben,

I'm sorry for the late reply.

From: Behalf Of Ben Hutchings

nouveau (CONFIG_DRM_NOUVEAU) is enabled in the hitachi_omap config. I'm
not sure how this could be useful in an OMAP system, and I don't expect
the driver to be supportable. Please disable it.

e100 (CONFIG_E100) and e1000 (CONFIG_E1000) drivers are enabled in
several configs (hitachi_omap, plathome_obsvx1, siemens_server) but are
not maintained upstream. (Don't confuse e1000 with e1000e, which is for
PCI Express and is still maintained.) Please disable them.

These drivers are not used. We'll simply disable them.

USB-attached network drivers (CONFIG_USB_USBNET) are enabled in several
configs (hitachi_omap, toshiba_tegra, plathome_obsvx1) but few of them
seem to be properly maintained upstream. Do you need them?

It is used as a convenient network interface for engineering.
If it is difficult to support them for super long term, we don't mind
too much even if CIP doesn't support them.

KVM (CONFIG_VIRTUALIZATION) adds a large attack surface (guest-to-host)
and is likely to be hard to maintain in the long term. Several of the
configurations (hitachi_omap, plathome_obsvx1, siemens_iot2000,
siemens_server) enable this. Do you need it?

It is not used at this point, but may be need in the future.

As long as we don't use KVM to build up a multi tenant VM service,
i.e. all users are the same legitimate user, the security risk of
guest-to-host attack will not become higher. So with regard to the
security risk, it will not be a problem for some use cases.

/dev/kmem (CONFIG_DEVKMEM) is only rarely needed for kernel debugging,
but is enabled in many configs. Please disable it.

/dev/mem (CONFIG_DEVMEM) is needed by some userland drivers, though UIO
provides a cleaner way to do this. Please check whether you can disable
it.

I tried to grep executable files in /usr/{bin,sbin}, and I found multiple
commands which may access /dev/mem. But I'm not sure how much impact
disabling /dev/mem has on us. We also use /dev/mem for a user land
driver, but we will be able to reimplement it via UIO.


By the way, I think that `supporting a feature' is not the same as
`enabling a feature'. Does `please disable it' mean that this is a
suggestion for a secure config, or imply that CIP shouldn't support
this feature?

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

Robert Marshall <robert.marshall@...> writes:

Hi,

A change yesterday to the git://git.linaro.org/qa/test-definitions.git
repos, removing obsolete directories, has removed the ubuntu one that the
b@d BBB health check used so that the default beaglebone health check will
now fail. We're working on a fix!

The repos versions of the beaglebone black tests have been updated with
a valid test. If you have an already provisioned box you will need to
manually change the tests/bbb* files with this diff:


from: git
- path: ubuntu/smoke-tests-basic.yaml
+ path: common/dt-selftests.yaml
name: smoke-tests


Robert

Hi,

A change yesterday to the git://git.linaro.org/qa/test-definitions.git
repos, removing obsolete directories, has removed the ubuntu one that the
b@d BBB health check used so that the default beaglebone health check will
now fail. We're working on a fix!

Robert

On 2017-07-21 19:11, Ben Hutchings wrote:

On Fri, 2017-07-21 at 17:19 +0200, Jan Kiszka wrote:

On 2017-07-21 15:18, Ben Hutchings wrote:

Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
siemens_iot2000 config. Are you really using Quark SoCs?

Yeah...
http://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/pages/default.aspx.
This revision will stop being shipped at latest in 2020, but there will
be a lot of these chips in the field until then.

Likely all needed patches will be in 4.13 (just still struggling to get
userspace software ported from the Intel BSP to mainline). So I'm
planning to submit the essential patches for CIP integration "soon".

I assume you're aware of erratum #24 affecting the LOCK prefix? There
seems to be no solution except to use Intel's forked version of binutils
which deletes the LOCK prefix.

That switch is even upstream. But, yeah, we need to rebuild everything
in userland from scratch and can't use, e.g., normal Debian packages.
For the next version, we software folks will be involved now.

I don't know if it's an issue for kernel
code, but probably not - the kernel shouldn't use LOCK if CONFIG_SMP is
not enabled, and in any case shouldn't get a page fault on such an
instruction..

Exactly, the kernel is fine as-is.

Jan

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

On Fri, 2017-07-21 at 17:19 +0200, Jan Kiszka wrote:

On 2017-07-21 15:18, Ben Hutchings wrote:

Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
siemens_iot2000 config. Are you really using Quark SoCs?

Yeah...
http://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/pages/default.aspx.
This revision will stop being shipped at latest in 2020, but there will
be a lot of these chips in the field until then.

Likely all needed patches will be in 4.13 (just still struggling to get
userspace software ported from the Intel BSP to mainline). So I'm
planning to submit the essential patches for CIP integration "soon".

I assume you're aware of erratum #24 affecting the LOCK prefix? There
seems to be no solution except to use Intel's forked version of binutils
which deletes the LOCK prefix. I don't know if it's an issue for kernel
code, but probably not - the kernel shouldn't use LOCK if CONFIG_SMP is
not enabled, and in any case shouldn't get a page fault on such an
instruction..

uhci-hcd (CONFIG_USB_UHCI_HCD) is for obsolete hardware (so far as I
know) but is enabled in the plathome_obsvx1, siemens_server and toshiba
x86 configs. Please disable it.

You need it for old USB 2.0 chipsets that have separate USB 1.1 and 2.0
interfaces. Those would then no longer word with 1.1 devices. But I bet
none of the provided products contain that.

I know there were some UHCI/EHCI pairings but I haven't seen a UHCI in a
long time.

KVM (CONFIG_VIRTUALIZATION) adds a large attack surface (guest-to-host)
and is likely to be hard to maintain in the long term. Several of the
configurations (hitachi_omap, plathome_obsvx1, siemens_iot2000,
siemens_server) enable this. Do you need it?

Not on the IOT2000 (f...ine Yocto rules made that pop up, I still need
to convert to a plain defconfig), not for production purposes on our
server, but we do have products (not listed so far) with KVM.

With - buzzword alarm - "edge computing", it is getting more and more
important as isolation tool for "apps". Containers/namespaces are
sometimes not strong enough.

[...]

I understand that - just trying to check that is actually being used.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.

This is the third and last part. There are actually a few features that
I'm recommending to *enable* here.

All the configs I was given *disable* the stack protector
(CONFIG_CC_STACKPROTECTOR_NONE enabled). Please enable
CONFIG_CC_STACKPROTECTOR_REGULAR or CONFIG_CC_STACKPROTECTOR_STRONG
instead.

Some configs disable heap randomisation (CONFIG_COMPAT_BRK enabled), but
this is only necessary for old C libraries and it weakens. Please
enable heap randomisation by default, i.e. disable CONFIG_COMPAT_BRK.

Module symbol versioning (CONFIG_MODVERSIONS) is disabled in some
configs. Consider enabling it in order to catch mistakes.

Performance events (CONFIG_PERF_EVENTS) provide a significant attack
surface and generally allow unprivileged users to crash the system. If
you do need them enabled in production - which I can understand - you
might want to apply the Grsecurity/Debian/Android patch that disables
use by unprivileged users.

Obsolete syscalls (CONFIG_SGETMASK_SYSCALL, CONFIG_SYSCTL_SYSCALL,
CONFIG_SYSFS_SYSCALL, CONFIG_UID16, CONFIG_USELIB) are enabled in some
configs. Consider disabling these.

Deprecated sysfs entries (CONFIG_SYSFS_DEPRECATED,
CONFIG_SYSFS_DEPRECATED_V2) are enabled in the toshiba powerpc config.
This is incompatible with current udev and other tools. Please disable
them.

User namespaces (CONFIG_USER_NS) open up a huge attack surface to
unprivileged users, which has resulted in a large number of privilege
escalation vulnerabilities. This is enabled in the plathome_obsvx1,
siemens_iot2000 and siemens_server configs. Do you need it?

Magic Sysrq (CONFIG_MAGIC_SYSRQ) can leak sensitive information if it's
possible for an untrusted user to invoke it. Consider setting
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x01b6 (this is what Debian uses) or
some other restrictive mask for production builds.

Linked list debug checks (CONFIG_LIST_DEBUG) are disabled in all
configs. Consider enabling them as these can make it harder to exploit
some bugs.

Kernel timer statistics (CONFIG_TIMER_STATS) have been removed upstream,
but are enabled in toshiba_zynq and plathome_obsvx1 configs. Apparently
there are tracepoints that provide similar functionality. Please
disable this.

Kernel shared memory (CONFIG_KSM) has an inherent security problem that
the merging of memory introduces a timing side-channel between VMs. On
systems vulnerable to Rowhammer, it can also be used to *modify* memory
belonging to other VMs. This is enabled in the toshiba_tegra,
plathome_obsvx1 and siemens_server configs. Please consider disabling
it.

--
Ben Hutchings
Software Developer, Codethink Ltd.

On 2017-07-21 15:18, Ben Hutchings wrote:

Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
siemens_iot2000 config. Are you really using Quark SoCs?

Yeah...
http://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/pages/default.aspx.
This revision will stop being shipped at latest in 2020, but there will
be a lot of these chips in the field until then.

Likely all needed patches will be in 4.13 (just still struggling to get
userspace software ported from the Intel BSP to mainline). So I'm
planning to submit the essential patches for CIP integration "soon".

uhci-hcd (CONFIG_USB_UHCI_HCD) is for obsolete hardware (so far as I
know) but is enabled in the plathome_obsvx1, siemens_server and toshiba
x86 configs. Please disable it.

You need it for old USB 2.0 chipsets that have separate USB 1.1 and 2.0
interfaces. Those would then no longer word with 1.1 devices. But I bet
none of the provided products contain that.

KVM (CONFIG_VIRTUALIZATION) adds a large attack surface (guest-to-host)
and is likely to be hard to maintain in the long term. Several of the
configurations (hitachi_omap, plathome_obsvx1, siemens_iot2000,
siemens_server) enable this. Do you need it?

Not on the IOT2000 (f...ine Yocto rules made that pop up, I still need
to convert to a plain defconfig), not for production purposes on our
server, but we do have products (not listed so far) with KVM.

With - buzzword alarm - "edge computing", it is getting more and more
important as isolation tool for "apps". Containers/namespaces are
sometimes not strong enough.

I can contribute to reviewing patches when needed or talk to the current
maintainers to have a look as well. At least on x86, it is mature by
now. ARM seems to be catching up quickly.

/dev/mem (CONFIG_DEVMEM) is needed by some userland drivers, though UIO
provides a cleaner way to do this. Please check whether you can disable
it.

I just explained this these days to someone who wanted to build an API
around it. In current embedded, it can be tricky, but I'm with you and
will promote its removal further.

Chrome platform support (CONFIG_CHROME_PLATFORMS) is enabled in the
siemens_server config. Assuming you don't need to support these
platforms, please disable it.

Ack.

Jan

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

Dear CIP friends,

On 21/07/17 15:18, Ben Hutchings wrote:

Sorry for the delay in reviewing feature support. I previously reviewed
filesystems and networking options, and this covers most of the rest. I
will send one more mail after this covering the remaining options.

please remember that Ben H. will join us at the TSC bi-weekly call next Monday. It would be very good if you can take a look at this mail before the meeting.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...

On Thu, 2017-07-20 at 09:48 +0100, Chris Paterson wrote:

This series adds iWave to the vendor list, and documents the iWave RZ/G1M
board.

Patches based on linux-4.4.y-cip 7bac4ad.

Applied and pushed, thanks.

Ben.

Biju Das (3):
of: Add vendor prefix for iWave Systems Technologies Pvt. Ltd
ARM: shmobile: document iW-RainboW-G20M-Qseven-RZG1M system on module
ARM: shmobile: document iW-RainboW-G20D-Qseven-RZG1M board

Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 5 insertions(+)

--
Ben Hutchings
Software Developer, Codethink Ltd.

Sorry for the delay in reviewing feature support. I previously reviewed
filesystems and networking options, and this covers most of the rest. I
will send one more mail after this covering the remaining options.

# x86

a.out support (CONFIG_IA32_AOUT) is enabled in plathome_obsvx but is
only needed for programs built before about 1995! Please disable it.

Vsyscall emulation (CONFIG_LEGACY_VSYSCALL_EMULATE) should be disabled
as it's only needed by older C libraries. Please select
CONFIG_LEGACY_VSYSCALL_NONE instead.

The modify_ldt syscall (CONFIG_MODIFY_LDT_SYSCALL) and 16-bit code
support (CONFIG_X86_16BIT) should be disabled; they're only needed to
run WINE.

Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
siemens_iot2000 config. Are you really using Quark SoCs?

X32 syscall support (CONFIG_X86_X32) adds some attack surface that is
not well-tested. Several of the configurations (plathome_obsvx1,
siemens_server and toshiba) enable this. Do you need it?

KVM old-style device assignment (CONFIG_KVM_DEVICE_ASSIGNMENT) is
deprecated and the feature has been removed upstream in 4.12, so it is
definitely not supportable. Only the plathome_obsvx1 config has this
enabled. Please disable it. If you are actually using this feature, it
should be replaced by VFIO.

i7300_idle (CONFIG_I7300_IDLE) has been removed upstream, but is enabled
in the plathome_obsvx1, siemens_server and toshiba configs). This is
only useful for the Intel i7300 chipset, so it should be fine to disable
it.

Several drivers (CONFIG_HP_WIRELESS, CONFIG_INTEL_RST,
CONFIG_INTEL_SMARTCONNECT) appear to only be useful for laptops, but are
enabled in the siemens_server config. Please consider disabling them.

SFI (CONFIG_SFI) seems to only be useful for Intel smartphone platforms,
but is enabled in the siemens_server config. Please disable it.

# Storage drivers

nbd (CONFIG_BLK_DEV_NBD) was not in good shape in 4.4, but is enabled in
plathome_obsvx1.config and
siemens_iot2000. Do you need it?

dm-cache (CONFIG_DM_CACHE) is marked as experimental in 4.4 and has
changed a lot upstream, which will make it hard to maintain. The
siemens_server config has it enabled. Do you need it?

dm-switch (CONFIG_DM_SWITCH) is marked as experimental in 4.4, but is
enabled in the siemens_server config. Do you need it?

MD multipath (CONFIG_MD_MULTIPATH) is "not under active development",
and should be replaced with dm-multipath. It is enabled in the
plathome_obsvx1, siemens_iot2000, and siemens_server configs. Do you
need it?

Many old SCSI drivers (CONFIG_BLK_DEV_3W_XXXX_RAID, CONFIG_SCSI_3W_9XXX,
CONFIG_SCSI_3W_SAS, CONFIG_SCSI_ACARD, CONFIG_SCSI_ADVANSYS,
CONFIG_SCSI_AM53C974, CONFIG_SCSI_BUSLOGIC, CONFIG_SCSI_DC395x,
CONFIG_SCSI_DMX3191D, CONFIG_SCSI_DPT_I2O, CONFIG_SCSI_EATA,
CONFIG_SCSI_GDTH, CONFIG_SCSI_IMM, CONFIG_SCSI_INIA100,
CONFIG_SCSI_INITIO, CONFIG_SCSI_IPS, CONFIG_SCSI_MVUMI,
CONFIG_SCSI_PMCRAID, CONFIG_SCSI_PPA, CONFIG_SCSI_QLOGIC_1280,
CONFIG_SCSI_SYM53C8XX_2, CONFIG_SCSI_WD719X, CONFIG_SCSI_AIC79XX,
CONFIG_SCSI_AIC7XXX, CONFIG_SCSI_AIC94XX, CONFIG_SCSI_ESAS2R,
CONFIG_MEGARAID_LEGACY, CONFIG_SCSI_MVSAS, CONFIG_SCSI_QLA_ISCSI) are
enabled in siemens_server config and I very much doubt you need any of
these. Please disable them.

# Graphics drivers

gma500 (CONFIG_DRM_GMA{3600,500,600}) is not maintained upstream and
will be unsupportable, but is enabled in the plathome_obsvx1 config. Do
you need it?

nouveau (CONFIG_DRM_NOUVEAU) is enabled in the hitachi_omap config. I'm
not sure how this could be useful in an OMAP system, and I don't expect
the driver to be supportable. Please disable it.

# Network drivers

Many old Ethernet drivers (CONFIG_TYPHOON, CONFIG_VORTEX,
CONFIG_NE2K_PCI, CONFIG_DNET, CONFIG_ETHOC, CONFIG_FEALNX, CONFIG_JME,
CONFIG_ADAPTEC_STARFIRE, CONFIG_AMD8111_ETH, CONFIG_PCNET32,
CONFIG_ATL1, CONFIG_ATL1C, CONFIG_ATL1E, CONFIG_ATL2, CONFIG_B44,
CONFIG_BCMGENET, CONFIG_CHELSIO_T1, CONFIG_DE2104X, CONFIG_DE4X5,
CONFIG_DM9102, CONFIG_NET_TULIP, CONFIG_ULI526X, CONFIG_WINBOND_840,
CONFIG_DL2K, CONFIG_SUNDANCE, CONFIG_HP100, CONFIG_SKY2, CONFIG_KS8842,
CONFIG_KSZ884X_PCI, CONFIG_ENC28J60, CONFIG_MYRI10GE, CONFIG_NATSEMI,
CONFIG_NS83820, CONFIG_S2IO, CONFIG_VXGE, CONFIG_FORCEDETH,
CONFIG_HAMACHI, CONFIG_YELLOWFIN, CONFIG_NETXEN_NIC, CONFIG_QLA3XXX,
CONFIG_QLGE, CONFIG_R6040, CONFIG_8139CP, CONFIG_8139TOO, CONFIG_ATP,
CONFIG_SC92031, CONFIG_SIS190, CONFIG_SIS900, CONFIG_EPIC100,
CONFIG_SMSC9420, CONFIG_CASSINI, CONFIG_HAPPYMEAL, CONFIG_NIU,
CONFIG_TEHUTI, CONFIG_TLAN, CONFIG_VIA_RHINE, CONFIG_VIA_VELOCITY,
CONFIG_WIZNET_W5100, CONFIG_WIZNET_W5300) are enabled in siemens_server
config and I very much doubt you need any of these. samsung-sxgbe
(CONFIG_SXGBE_ETH) is also enabled, but this hardware only exists in
Samsung SoCs. Please disable them.

e100 (CONFIG_E100) and e1000 (CONFIG_E1000) drivers are enabled in
several configs (hitachi_omap, plathome_obsvx1, siemens_server) but are
not maintained upstream. (Don't confuse e1000 with e1000e, which is for
PCI Express and is still maintained.) Please disable them.

sungem (CONFIG_SUNGEM) is enabled in the siemens_server and toshiba
powerpc configs, but I doubt that this driver is needed. Please
consider disabling it.

USB-attached network drivers (CONFIG_USB_USBNET) are enabled in several
configs (hitachi_omap, toshiba_tegra, plathome_obsvx1) but few of them
seem to be properly maintained upstream. Do you need them?

i2400m-usb (CONFIG_WIMAX_I2400M_USB) is enabled in plathome_obsvx1, but
is unmaintained upstream. Do you need it? (I also noted previously
that wimax in general is dead.)

Wifi drivers may be hard to support in the long term due to changes in
the softMAC (mac80211) driver API. However I will assume that they are
needed for some applications.

The ipw2x00 drivers (CONFIG_IPW2100, CONFIG_IPW2200) are not maintained
and only found in some old x86 systems, but is enabled in the
plathome_obsvx1 config. Please disable them.

zd1211rw (CONFIG_ZD1211RW) seems to be unmaintained but is enabled in
the plathome_obsvx1 config. Please disable it.

r8172u (CONFIG_R8712U) is in drivers/staging (and has been for nearly 7
years!) and is therefore unlikely to be supportable, but is enabled in
the siemens_iot2000 config. Do you need it?

# USB drivers

fotg210-hcd (CONFIG_USB_FOTG210_HCD) is a platform driver that doesn't
look usable on x86, but is enabled in the siemens_server config. Please
disable it.

uhci-hcd (CONFIG_USB_UHCI_HCD) is for obsolete hardware (so far as I
know) but is enabled in the plathome_obsvx1, siemens_server and toshiba
x86 configs. Please disable it.

ehset (CONFIG_USB_EHSET_TEST_FIXTURE) and usb3503
(CONFIG_USB_HSIC_USB3503) are unlikely to be needed but are enabled in
the siemens_server config. Please consider disabling them.

# Misc drivers

OProfile (CONFIG_OPROFILE) seems to be barely maintained and redundant
with perf, but all the configs still enable it (mostly because it's
enabled in upstream defconfigs). Please consider disabling it.

KVM (CONFIG_VIRTUALIZATION) adds a large attack surface (guest-to-host)
and is likely to be hard to maintain in the long term. Several of the
configurations (hitachi_omap, plathome_obsvx1, siemens_iot2000,
siemens_server) enable this. Do you need it?

/dev/kmem (CONFIG_DEVKMEM) is only rarely needed for kernel debugging,
but is enabled in many configs. Please disable it.

/dev/mem (CONFIG_DEVMEM) is needed by some userland drivers, though UIO
provides a cleaner way to do this. Please check whether you can disable
it.

Chrome platform support (CONFIG_CHROME_PLATFORMS) is enabled in the
siemens_server config. Assuming you don't need to support these
platforms, please disable it.

--
Ben Hutchings
Software Developer, Codethink Ltd.

Hi,

in order to better accommodate the meeting to Ben Hutchings availability, so he can attend on regular basis, we have moved the Thursday meeting from the morning to 15:30 UK (summer) time.

Please remember you can attend through video chat: https://plus.google.com/hangouts/_/codethink.co.uk/team-event-cip?hceid=YWd1c3Rpbi5iZW5pdG9AY29kZXRoaW5rLmNvLnVr.m6jv292u7masvpa1lb221rom1g&authuser=0

We can always have a meeting in the morning if anybody from Asia is attending.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...

From: Biju Das <biju.das@...>

Document the iW-RainboW-G20D-Qseven-RZG1M device tree bindings,
listing it as a supported board.

Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Chris Paterson <chris.paterson2@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 9086120f8b883034940e5228c83824ed21999537)
Signed-off-by: Chris Paterson <chris.paterson2@...>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 90b6bd8..7ec024c 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -49,6 +49,8 @@ Boards:
compatible = "renesas,gose", "renesas,r8a7793"
- Henninger
compatible = "renesas,henninger", "renesas,r8a7791"
+ - iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven)
+ compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743"
- iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven)
compatible = "iwave,g20m", "renesas,r8a7743"
- Koelsch (RTP0RC7791SEB00010S)
--
1.9.1

From: Biju Das <biju.das@...>

Document the iW-RainboW-G20M-Qseven-RZG1M device tree bindings,
listing it as a supported system on module.

Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Chris Paterson <chris.paterson2@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 427bc40375df765b6146ce917d5a3d3832482935)
Signed-off-by: Chris Paterson <chris.paterson2@...>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index b29d9c7..90b6bd8 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -49,6 +49,8 @@ Boards:
compatible = "renesas,gose", "renesas,r8a7793"
- Henninger
compatible = "renesas,henninger", "renesas,r8a7791"
+ - iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven)
+ compatible = "iwave,g20m", "renesas,r8a7743"
- Koelsch (RTP0RC7791SEB00010S)
compatible = "renesas,koelsch", "renesas,r8a7791"
- Kyoto Microcomputer Co. KZM-A9-Dual
--
1.9.1

From: Biju Das <biju.das@...>

This patch adds vendor prefix for iWave Systems Technologies Pvt. Ltd.
Website: http://www.iwavesystems.com/

Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Chris Paterson <chris.paterson2@...>
Acked-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Rob Herring <robh@...>
(cherry picked from commit 9b6782e7f0efc2bf483e000b95fc7c06322a0703)
Signed-off-by: Chris Paterson <chris.paterson2@...>

Conflicts:
Documentation/devicetree/bindings/vendor-prefixes.txt

Signed-off-by: Chris Paterson <chris.paterson2@...>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 55df1d4..6264752 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -119,6 +119,7 @@ intercontrol Inter Control Group
invensense InvenSense Inc.
isee ISEE 2007 S.L.
isil Intersil
+iwave iWave Systems Technologies Pvt. Ltd.
jedec JEDEC Solid State Technology Association
karo Ka-Ro electronics GmbH
keymile Keymile GmbH
--
1.9.1

This series adds iWave to the vendor list, and documents the iWave RZ/G1M
board.

Patches based on linux-4.4.y-cip 7bac4ad.

Biju Das (3):
of: Add vendor prefix for iWave Systems Technologies Pvt. Ltd
ARM: shmobile: document iW-RainboW-G20M-Qseven-RZG1M system on module
ARM: shmobile: document iW-RainboW-G20D-Qseven-RZG1M board

Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 5 insertions(+)

--
1.9.1

Hi Robert,

On 19 July 2017 14:01:13 CEST, Robert Marshall <robert.marshall@...> wrote:

The 0.9.1 release box of B@D has been successfully imported into
Windows
10 and both a QEMU and BBB health check have been run on that virtual
machine.
This setup also works when provisioning a box from a clone of the git
repository.

The steps to get B@D running on Windows 10 are as follows:

- Install the guest additions `vagrant plugin install vagrant-vbguest`
- Install rsync/ssh/git in cygwin.
- core.autocrlf=input is needed in the git settings for the scripts to
run under the Debian of the virtual machine.
- Once the vm is up then in virtualbox add a USB filter for the FTDI
device.
- For kernelci access you need to use either Firefox or Chrome - the
Microsoft
browsers will not work.
- You may need the vagrant scp command (if you wish to copy other files
onto the VM) if so -
vagrant plugin install vagrant-scp
- setup mybbb.dat to use the IP address of the VM rather than that of
the host.

Congratulations for this accomplishment.

The wiki has been updated to document these steps.

So the former 5 steps documentation now includes the specific steps to take if you are a Windows 10 user. There is no separate documentation since most of the instructions to execute are the same in both cases (Windows and Linux).

Robert
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On Wed, 2017-07-19 at 13:59 +0000, Biju Das wrote:
[...]

Then I think I should just make this change:

Subject: CIP: Build essential clock driver for Renesas RZ/G1 platforms

[...]

Right?

Yes. That is correct.

I've applied this.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.