Date   

[PATCH 4.19.y-cip 00/23] Clock enhancements

Biju Das <biju.das@...>
 

This patch series add OPP tables,HS400 quirk for SD clock,
add support Z2 clock and fix some of parent clocks.

This patch series is based on linux-4.19.y-cip and all the patches
in this series are cherry-picked from linux rc tree.

Biju Das (2):
clk: renesas: rcar-gen3: Parameterise Z and Z2 clock fixed divisor
clk: renesas: rcar-gen3: Parameterise Z and Z2 clock offset

Fabrizio Castro (3):
clk: renesas: r8a774a1: Add missing CANFD clock
clk: renesas: r8a774a1: Fix LAST_DT_CORE_CLK
arm64: dts: renesas: r8a774c0: Add OPPs table for cpu devices

Geert Uytterhoeven (2):
clk: renesas: r8a774a1: Add CPEX clock
clk: renesas: rcar-gen3: Pass name/offset to cpg_sd_clk_register()

Kazuya Mizuguchi (2):
clk: renesas: rcar-gen3: Correct parent clock of EHCI/OHCI
clk: renesas: rcar-gen3: Correct parent clock of HS-USB

Niklas Söderlund (3):
clk: renesas: rcar-gen3: Set state when registering SD clocks
clk: renesas: rcar-gen3: Add documentation for SD clocks
clk: renesas: rcar-gen3: Add HS400 quirk for SD clock

Sergei Shtylyov (2):
clk: renesas: rcar-gen3: Factor out cpg_reg_modify()
clk: renesas: rcar-gen3: Add spinlock

Simon Horman (4):
clk: renesas: rcar-gen3: Remove CLK_TYPE_GEN3_Z2
math64: New DIV64_U64_ROUND_CLOSEST helper
clk: renesas: rcar-gen3: Support Z and Z2 clocks with high frequency
parents
clk: renesas: r8a774c0: Add Z2 clock

Stephen Boyd (2):
clk: renesas: Remove usage of CLK_IS_BASIC
clk: renesas: rcar-gen3: Remove unused variable

Takeshi Kihara (3):
clk: renesas: rcar-gen3: Correct parent clock of SYS-DMAC
clk: renesas: rcar-gen3: Correct parent clock of Audio-DMAC
clk: renesas: rcar-gen3: Fix cpg_sd_clock_round_rate() return value

arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 25 ++++
drivers/clk/renesas/clk-div6.c | 2 +-
drivers/clk/renesas/clk-mstp.c | 2 +-
drivers/clk/renesas/r8a774a1-cpg-mssr.c | 23 ++--
drivers/clk/renesas/r8a774c0-cpg-mssr.c | 7 +-
drivers/clk/renesas/r8a7795-cpg-mssr.c | 25 ++--
drivers/clk/renesas/r8a7796-cpg-mssr.c | 19 +--
drivers/clk/renesas/r8a77965-cpg-mssr.c | 16 +--
drivers/clk/renesas/r8a77990-cpg-mssr.c | 6 +-
drivers/clk/renesas/r8a77995-cpg-mssr.c | 2 +-
drivers/clk/renesas/rcar-gen3-cpg.c | 174 ++++++++++++++------------
drivers/clk/renesas/rcar-gen3-cpg.h | 5 +-
drivers/clk/renesas/renesas-cpg-mssr.c | 2 +-
include/dt-bindings/clock/r8a774a1-cpg-mssr.h | 1 +
include/linux/math64.h | 13 ++
15 files changed, 193 insertions(+), 129 deletions(-)

--
2.7.4


Re: [ANNOUNCE] 4.4.176-cip31-rt23

Pavel Machek
 

Hi!

I'm pleased to announce the 4.4.176-cip31-rt23 stable release.

This release is just an update to the new stable 4.4.176-cip31 version
and no RT specific changes have been made.

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git

branch: linux-4.4.y-cip-rt
Head SHA1: b51a171ad762ba4a78b0ed0c7ec83fb9f6fb135f
Is there a chance to update 4.4-rt based on Daniel' 4.4.179-rt181 release, but
then to 4.4.182 in order to have SACK fixes in?
I'm looking into it. I have -rt-rebase based on
v4.4.179-rt181-cip34-rebase (close to what you want but not quite
there; I can publish it if it would be useful), but duplicating same
result with merges might be tricky.

Best regards,
Pavel

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


Re: RT testing

Pavel Machek
 

Hi!

(List added to the cc).

Here are the links I was pasting into the Zoom chat regarding RT testing.
Thanks for all the help!

I got -cip-rt kernel to work on EBV Socrates, and it seems to be
suitable machine for testing. Latencies are under 70 usec under normal
loads. They go up-to 150 usec in longer tests and under very heavy
loads... These results are also consistent with osdal data:
https://www.osadl.org/Latency-plot-of-system-in-rack-7-slot.qa-latencyplot-r7s5.0.html?shadow=1

On iwg20m, I was getting 299 usec on cyclictest alone (job/1726) and
some mysterious 2000usec+ latencies on 4.19.50-cip3-rt1 (job/1797). I verified
Thinkpad X60 is not suitable due to hwlat. Thinkpad T40p is somehow
more promising (nothing detected by hwlat), but latencies cyclictest
is often in 500 usec range, and I have seen 755 usec with
4.4.176-cip31-rt23.

So.. EBV Socrates seems like best board to test on. Fortunately we
have very similar board in the lab:
https://lava.ciplatform.org/scheduler/device_type/Altera-Terasic-Deo-Nano
.

I believe we should do the following steps:

1) Add -rt configuration for socfpga to cip-kernel-config repositories
(me)

2) Enable CONFIG_HIGH_RES_TIMERS=y in all configs (realtime or not) so
we have comparison (me)

3) Prepare rt and non-rt kernels for socfpga. (I can do it one time,
but it would be good to do it automatically as part of checkin tests).

4) Tune cyclictest (length of test, background load) so that it
reproduces cca 100 usec latency on socfpga. If we set threshold to
cca 200 usec, it should consistently fail on non-RT_FULL
configurations. (I'll need help).

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


Re: Regarding backporting RTC PCF85263 driver to cip 4.4 kernel

Biju Das <biju.das@...>
 

Hi Nobuhiro,

Thanks for the feedback.

.feghali.xb@...>; cip-
dev@...
Subject: RE: [cip-dev] Regarding backporting RTC PCF85263 driver to cip 4.4
kernel

Hi,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Pavel
Machek
Sent: Monday, July 15, 2019 6:46 AM
To: Biju Das <biju.das@...>
Cc: Christopher Feghali <christopher.feghali.xb@...>;
cip-dev@...
Subject: Re: [cip-dev] Regarding backporting RTC PCF85263 driver to
cip
4.4 kernel

Hi!

RTC PCF85263 is used by iWave RZ/G1C SBC( iwg23s) platform. We have
upstreamed this driver support on 4.19 kernel [1] [1].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
om
mit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=fc979933bcf162595b6004d0de4
ef
fb64c323152

This driver is based on RTC PCF 85363 driver which has rtc
nvmem/alarm support [2] . Rtc nvmem framework is introduced in 4.13
[2].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
om
mit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=a9687aa2764dd2669602bd19dc6
36
cbeef5293d5

We are seeing the following options for backporting this driver to
4.4 kernel
First, you did a lot of work there...

Option 1:
Backport this driver[1] to 4.4 kernel along with nvmem/alarm support.
we have already done this work and patches are available at [3] [3].
https://gitlab.com/bijud/pcf85263/tree/master
Ok, this is rather long/big series, and some parts are quite scary:
https://gitlab.com/bijud/pcf85263/blob/master/0013-rtc-nvmem-allow-r
egistering-the-nvmem-device-before-.patch

Option 2:
Backport RTC PCF85263 driver, removing Alarm/nvmem functionality
from [2] .
So we basically get this one, and few patches on top, local to the new
files.
https://gitlab.com/bijud/pcf85263/blob/master/0015-rtc-add-support-f
or-NXP-PCF85363-real-time-clock.patch

I think I prefer option 2.

Option 3:
Don't backport RTC support at all.
Applying patch #15 is easy. We can do option 2 I believe.
I think that option 2 is good.
OK. Will send patch based on option 2.

Regards,
Biju


Re: Regarding backporting RTC PCF85263 driver to cip 4.4 kernel

Biju Das <biju.das@...>
 

Hi Pavel,

Thanks for the feedback.

Subject: Re: [cip-dev] Regarding backporting RTC PCF85263 driver to cip 4.4
kernel

Hi!

RTC PCF85263 is used by iWave RZ/G1C SBC( iwg23s) platform. We have
upstreamed this driver support on 4.19 kernel [1] [1].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
mit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=fc979933bcf162595b6004d0de4ef
fb64c323152

This driver is based on RTC PCF 85363 driver which has rtc
nvmem/alarm support [2] . Rtc nvmem framework is introduced in 4.13
[2].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
mit/drivers/rtc/rtc-
pcf85363.c?h=v5.2&id=a9687aa2764dd2669602bd19dc636
cbeef5293d5

We are seeing the following options for backporting this driver to
4.4 kernel
First, you did a lot of work there...

Option 1:
Backport this driver[1] to 4.4 kernel along with nvmem/alarm support.
we have already done this work and patches are available at [3] [3].
https://gitlab.com/bijud/pcf85263/tree/master
Ok, this is rather long/big series, and some parts are quite scary:
https://gitlab.com/bijud/pcf85263/blob/master/0013-rtc-nvmem-allow-
registering-the-nvmem-device-before-.patch

Option 2:
Backport RTC PCF85263 driver, removing Alarm/nvmem functionality from
[2] .
So we basically get this one, and few patches on top, local to the new files.
https://gitlab.com/bijud/pcf85263/blob/master/0015-rtc-add-support-for-
NXP-PCF85363-real-time-clock.patch

I think I prefer option 2.

Option 3:
Don't backport RTC support at all.
Applying patch #15 is easy. We can do option 2 I believe.
Ok. I will send patch based on option 2.

Regards,
Biju


Re: Regarding backporting RTC PCF85263 driver to cip 4.4 kernel

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Pavel
Machek
Sent: Monday, July 15, 2019 6:46 AM
To: Biju Das <biju.das@...>
Cc: Christopher Feghali <christopher.feghali.xb@...>;
cip-dev@...
Subject: Re: [cip-dev] Regarding backporting RTC PCF85263 driver to cip
4.4 kernel

Hi!

RTC PCF85263 is used by iWave RZ/G1C SBC( iwg23s) platform. We have
upstreamed this driver support on 4.19 kernel [1] [1].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
om
mit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=fc979933bcf162595b6004d0de4
ef
fb64c323152

This driver is based on RTC PCF 85363 driver which has rtc
nvmem/alarm support [2] . Rtc nvmem framework is introduced in 4.13
[2].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
om
mit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=a9687aa2764dd2669602bd19dc6
36
cbeef5293d5

We are seeing the following options for backporting this driver to
4.4 kernel
First, you did a lot of work there...

Option 1:
Backport this driver[1] to 4.4 kernel along with nvmem/alarm support.
we have already done this work and patches are available at [3] [3].
https://gitlab.com/bijud/pcf85263/tree/master
Ok, this is rather long/big series, and some parts are quite scary:
https://gitlab.com/bijud/pcf85263/blob/master/0013-rtc-nvmem-allow-r
egistering-the-nvmem-device-before-.patch

Option 2:
Backport RTC PCF85263 driver, removing Alarm/nvmem functionality from
[2] .
So we basically get this one, and few patches on top, local to the new
files.
https://gitlab.com/bijud/pcf85263/blob/master/0015-rtc-add-support-f
or-NXP-PCF85363-real-time-clock.patch

I think I prefer option 2.

Option 3:
Don't backport RTC support at all.
Applying patch #15 is easy. We can do option 2 I believe.
I think that option 2 is good.

Best regards,
Nobuhiro


Re: Request for guidance: removal of old config files [was: Kernel configurations for 4.19?]

Nobuhiro Iwamatsu
 

Hi Ben,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Ben
Hutchings
Sent: Saturday, July 13, 2019 1:35 AM
To: Jan Kiszka <jan.kiszka@...>
Cc: takehisa.katayama.bx@...; sz.lin@...;
cip-dev@...
Subject: Re: [cip-dev] Request for guidance: removal of old config files
[was: Kernel configurations for 4.19?]

On Thu, 2019-07-11 at 18:51 +0200, Jan Kiszka wrote:
[...]
4.19/arm/hitachi_omap_defconfig
4.19/arm/moxa_mxc_defconfig
4.19/arm/siemens_am335x-axm2_defconfig
4.19/arm/siemens_am335x-draco_defconfig
4.19/arm/siemens_am335x-dxr2_defconfig
4.19/arm/siemens_am335x-etamin_defconfig
4.19/arm/siemens_am57xx-pxm3_defconfig
Those can go, I'm not aware of their usage on 4.19. But do we have one
for the am335-x-based BBB, our reference board?
Good point. I have not yet tried running 4.19 on the BBB, but I can look
at adding one - or perhaps Nobuhiro or Pavel already has a suitable config?
I have a BBB, but I do not try running 4.19 on BBB.
I will try this.


4.19/arm/toshiba_tegra_defconfig
4.19/arm/toshiba_zynq_defconfig
4.19/powerpc/toshiba_defconfig
4.19/x86/plathome_obsvx1.config
4.19/x86/siemens_i386-rt.config
I do not recall the history of that one anymore. We should have at
least one -rt config for x86 somewhere.
Yes, and also the build rules should check out -rt branches instead of
the main CIP branches when processing an -rt configuration.

4.19/x86/siemens_iot2000.config
4.19/x86/siemens_server_defconfig
Those two should stay.
But they need to be reviewed, as automatic config updates usually don't
cope with renaming of config symbols.
Best regards,
Nobuhiro


Re: Regarding backporting RTC PCF85263 driver to cip 4.4 kernel

Pavel Machek
 

Hi!

RTC PCF85263 is used by iWave RZ/G1C SBC( iwg23s) platform. We have upstreamed this driver support on 4.19 kernel [1]
[1]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=fc979933bcf162595b6004d0de4effb64c323152

This driver is based on RTC PCF 85363 driver which has rtc nvmem/alarm support [2] . Rtc nvmem framework is introduced in 4.13
[2]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=a9687aa2764dd2669602bd19dc636cbeef5293d5

We are seeing the following options for backporting this driver to
4.4 kernel
First, you did a lot of work there...

Option 1:
Backport this driver[1] to 4.4 kernel along with nvmem/alarm support. we have already done this work and patches are available at [3]
[3]. https://gitlab.com/bijud/pcf85263/tree/master
Ok, this is rather long/big series, and some parts are quite scary:
https://gitlab.com/bijud/pcf85263/blob/master/0013-rtc-nvmem-allow-registering-the-nvmem-device-before-.patch

Option 2:
Backport RTC PCF85263 driver, removing Alarm/nvmem functionality
from [2] .
So we basically get this one, and few patches on top, local to the new files.
https://gitlab.com/bijud/pcf85263/blob/master/0015-rtc-add-support-for-NXP-PCF85363-real-time-clock.patch

I think I prefer option 2.

Option 3:
Don't backport RTC support at all.
Applying patch #15 is easy. We can do option 2 I believe.

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


Re: Request for guidance: removal of old config files [was: Kernel configurations for 4.19?]

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2019-07-11 at 18:51 +0200, Jan Kiszka wrote:
[...]
4.19/arm/hitachi_omap_defconfig
4.19/arm/moxa_mxc_defconfig
4.19/arm/siemens_am335x-axm2_defconfig
4.19/arm/siemens_am335x-draco_defconfig
4.19/arm/siemens_am335x-dxr2_defconfig
4.19/arm/siemens_am335x-etamin_defconfig
4.19/arm/siemens_am57xx-pxm3_defconfig
Those can go, I'm not aware of their usage on 4.19. But do we have one for the
am335-x-based BBB, our reference board?
Good point. I have not yet tried running 4.19 on the BBB, but I can
look at adding one - or perhaps Nobuhiro or Pavel already has a
suitable config?

4.19/arm/toshiba_tegra_defconfig
4.19/arm/toshiba_zynq_defconfig
4.19/powerpc/toshiba_defconfig
4.19/x86/plathome_obsvx1.config
4.19/x86/siemens_i386-rt.config
I do not recall the history of that one anymore. We should have at least one -rt
config for x86 somewhere.
Yes, and also the build rules should check out -rt branches instead of
the main CIP branches when processing an -rt configuration.

4.19/x86/siemens_iot2000.config
4.19/x86/siemens_server_defconfig
Those two should stay.
But they need to be reviewed, as automatic config updates usually don't
cope with renaming of config symbols.

Ben.

4.19/x86/toshiba_defconfig

Ben.
Thanks,
Jan
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


[ANNOUNCE] Release 4.19.58-cip6 and 4.4.185-cip35

Nobuhiro Iwamatsu
 

Hi all,

CIP kernel team has released Linux kernel 4.19.58-cip6 and 4.4.185-cip35.

Linux-4.19.y-cip has been updated from base version from 4.19.56 to 4.19.58,
and linux-4.4.y-cip has been updated from 4.4.182 to 4.4.185 with pxa2xx's
spi fix.
And CIP's gitlab CI configuration file (.gitlab-ci.yml) has been added.

You can get this release via the git tree at:

4.19.58-cip6:

repository: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch: linux-4.19.y-cip
commit: 2be2d3f02499e9d3a68f9e2ad1b1c4a0c42189b2

4.4.185-cip35:

This release has updated the base version from 4.4.182 to 4.4.185.

repository: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch: linux-4.4.y-cip
commit: 7b3d18ad0155a525f36903fc950dd27fe7ef1443

Best regards,
Nobuhiro


Regarding backporting RTC PCF85263 driver to cip 4.4 kernel

Biju Das <biju.das@...>
 

Hi All,

 

RTC PCF85263 is used by iWave RZ/G1C SBC( iwg23s) platform.  We have upstreamed  this driver support  on 4.19 kernel [1]

[1]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=fc979933bcf162595b6004d0de4effb64c323152

 

This driver is based  on RTC PCF 85363 driver which has rtc nvmem/alarm support [2] .  Rtc nvmem framework is introduced in 4.13

[2]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=a9687aa2764dd2669602bd19dc636cbeef5293d5

 

We are seeing the following options for backporting this driver to 4.4 kernel

 

Option 1:

Backport this driver[1] to 4.4 kernel along with nvmem/alarm support. we have already done this work and patches are available at [3]

[3]. https://gitlab.com/bijud/pcf85263/tree/master

 

Option 2:

Backport RTC PCF85263 driver, removing  Alarm/nvmem functionality from  [2] .

 

Option 3:

Don't backport RTC support at all.

 

Please share your views, so that I can work on this accordingly.

 

Regards,

Biju

 

 


Re: Kernel configurations for 4.19?

daniel.sangorrin@...
 

Hello Ben,

[Note] repeating the reply because I got some rejected mails.

From: Ben Hutchings
I have received new config files from most members, but no-one told me
if the old configs can be deleted. For reference, these are the files
we have for 4.19 that are based on those submitted for 4.4:
You can discard the 4.4 old configurations from Toshiba. At the moment, we only need support for this one:
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/blob/master/4.19/x86/toshiba_atom_baytrail_cip.config

[Note] we may send more configuration files in the near future.

Thanks,
Daniel

4.19/arm/hitachi_omap_defconfig
4.19/arm/moxa_mxc_defconfig
4.19/arm/siemens_am335x-axm2_defconfig
4.19/arm/siemens_am335x-draco_defconfig
4.19/arm/siemens_am335x-dxr2_defconfig
4.19/arm/siemens_am335x-etamin_defconfig
4.19/arm/siemens_am57xx-pxm3_defconfig
4.19/arm/toshiba_tegra_defconfig
4.19/arm/toshiba_zynq_defconfig
4.19/powerpc/toshiba_defconfig
4.19/x86/plathome_obsvx1.config
4.19/x86/siemens_i386-rt.config
4.19/x86/siemens_iot2000.config
4.19/x86/siemens_server_defconfig
4.19/x86/toshiba_defconfig

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

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


Re: [PATCH v3 4.19.y-cip] Add gitlab-ci.yaml

Pavel Machek
 

Hi!

This is configured to build and test the following configurations:

* BUILD_ARCH: arm
* CONFIG: renesas_shmobile_defconfig
* CONFIG_LOC: cip-kernel-config
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

* BUILD_ARCH: arm64
* CONFIG: renesas_defconfig
* CONFIG_LOC: cip-kernel-config
* DEVICES: r8a774c0-ek874
* DTBS: r8a774c0-ek874.dtb

* BUILD_ARCH: arm
* CONFIG: shmobile_defconfig
* CONFIG_LOC: intree
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

Over time support will be added for all CIP supported architectures and
configurations.

At the moment only simple boot tests are run. Real tests will be added in
the future
I went ahead, and applied this to linux-4.19.y-cip-rt-rebase branch,
too. If it is easy to add that one to testing, it would be nice.

Best regards,
Pavel

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


Re: [PATCH v3 4.4.y-cip] Add gitlab-ci.yaml

Pavel Machek
 

On Mon 2019-07-08 14:16:03, Chris Paterson wrote:
This is configured to build and test the following configurations:

* BUILD_ARCH: arm
* CONFIG: renesas_shmobile_defconfig
* CONFIG_LOC: cip-kernel-config
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

* BUILD_ARCH: arm
* CONFIG: shmobile_defconfig
* CONFIG_LOC: intree
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

Over time support will be added for all CIP supported architectures and
configurations.

At the moment only simple boot tests are run. Real tests will be added in
the future
Thanks, applied to 4.4-cip, and pushed out.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: [PATCH v3 4.19.y-cip] Add gitlab-ci.yaml

Pavel Machek
 

Hi!

This is configured to build and test the following configurations:

* BUILD_ARCH: arm
* CONFIG: renesas_shmobile_defconfig
* CONFIG_LOC: cip-kernel-config
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

* BUILD_ARCH: arm64
* CONFIG: renesas_defconfig
* CONFIG_LOC: cip-kernel-config
* DEVICES: r8a774c0-ek874
* DTBS: r8a774c0-ek874.dtb

* BUILD_ARCH: arm
* CONFIG: shmobile_defconfig
* CONFIG_LOC: intree
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

Over time support will be added for all CIP supported architectures and
configurations.
Thanks, applied and pushed out. Sorry for the delay.

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


Re: [ANNOUNCE] 4.4.176-cip31-rt23

Jan Kiszka
 

Hi Pavel,

On 29.03.19 12:06, Daniel Wagner wrote:
Hello CIP RT Folks!

I'm pleased to announce the 4.4.176-cip31-rt23 stable release.

This release is just an update to the new stable 4.4.176-cip31 version
and no RT specific changes have been made.

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git

branch: linux-4.4.y-cip-rt
Head SHA1: b51a171ad762ba4a78b0ed0c7ec83fb9f6fb135f
Is there a chance to update 4.4-rt based on Daniel' 4.4.179-rt181 release, but
then to 4.4.182 in order to have SACK fixes in?

Thanks,
Jan

PS: Please make it -rt24 then. ;)

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


Re: About CIP kernel maintenance policy for new hardware support backporting

Hiraku Toyooka
 

Hi,

You can find the following sentence on the page.
an SLTS branch may include larger changes to support new hardware, to bridge the gap between SLTS branches.
Oh, I missed the sentence. Thank you very much for telling it.

In addition to these, we may need to describe the supported hardware (CPU, boards) and
test environment as well.
Is the backporting limited to the supported hardware?

Best regards,
Hiraku Toyooka

2019年7月11日(木) 8:47 <nobuhiro1.iwamatsu@...>:


Hi,


Thanks for pointed out.
You can find the following sentence on the page.
an SLTS branch may include larger changes to support new hardware, to bridge the gap between SLTS branches.
I think we need to write much clear to mention what kind of patches we can accept to CIP SLTS tree and how to approve(?) it by CIP.
Agree.

We think that we need to add the following sentences.
---
We do not apply patches that have not been applied to upstream
(Linus tree:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git).
If you want to add new features or hardware, they need to be applied into upstream.
Also, you may not be able to easily apply the patches on Upstream. In such a case,
you need to describe in the commit message of patch what modifications have been made
from the original patch.
---

In addition to these, we may need to describe the supported hardware (CPU, boards) and
test environment as well.

Best regards,
Nobuhiro

From: Yoshitake Kobayashi [mailto:yoshitake.kobayashi@...]
Sent: Wednesday, July 10, 2019 9:56 PM
To: hiraku.toyooka@...
Cc: cip-dev@...; pavel@...; iwamatsu nobuhiro(岩松 信洋 ○SWC□OST) <nobuhiro1.iwamatsu@...>
Subject: Re: [cip-dev] About CIP kernel maintenance policy for new hardware support backporting

Hi,

Thanks for pointed out.
You can find the following sentence on the page.
an SLTS branch may include larger changes to support new hardware, to bridge the gap between SLTS branches.
I think we need to write much clear to mention what kind of patches we can accept to CIP SLTS tree and how to approve(?) it by CIP.

Best regards,
Yoshi



2019年7月10日(水) 15:42 <hiraku.toyooka@...>:
Hello,

I have a question about CIP kernel maintenance policy.
Can CIP kernel accept backport patches for new hardware support (not
only fixes)?

I read the following document and it seems to describe only acceptable fixes.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance

On the other hand, Current linux-4.19.y-cip branch accepts some hardware
support patches such as RZ/G2E(r8a774c0) from upstream.
So I wonder if some policy about new hardware support exists.

--
Hiraku Toyooka
Cybertrust Japan Co., Ltd.
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


--
Hiraku Toyooka
Cybertrust Japan Co., Ltd.


[cip-kernel-sec][Quickstart v2] docs: add a quickstart with practical information

Daniel Sangorrin <daniel.sangorrin@...>
 

Although the README already contains all the information
that users may need, there are some bits of know-how that
are better expressed through a step-by-step quickstart or
tutorial. This files tries to fill that gap.

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
---
QUICKSTART.md | 132 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 132 insertions(+)
create mode 100644 QUICKSTART.md

diff --git a/QUICKSTART.md b/QUICKSTART.md
new file mode 100644
index 0000000..c79af41
--- /dev/null
+++ b/QUICKSTART.md
@@ -0,0 +1,132 @@
+# Quickstart
+
+## Overview
+
+This project tracks the status of CVEs in mainline and stable kernels. Each CVE is described in YAML format that includes data such as:
+
+```
+$ cat issues/CVE-2019-1999.yml
+description: 'binder: fix race between munmap() and direct reclaim'
+references:
+- https://source.android.com/security/bulletin/2019-02-01
+comments:
+ Debian-bwh: |-
+ Introduced in 4.14 by f2517eb76f1f "android: binder: Add global lru
+ shrinker to binder". Backports of the fix to stable have incorrect
+ metadata.
+ bwh: Backports to stable have incorrect metadata
+introduced-by:
+ mainline: [f2517eb76f1f2f7f89761f9db2b202e89931738c]
+fixed-by:
+ linux-4.14.y: [33c6b9ca70a8b066a613e2a3d0331ae8f82aa31a]
+ linux-4.19.y: [6bf7d3c5c0c5dad650bfc4345ed553c18b69d59e]
+ linux-5.0.y: [bbb19ca082ce27ce60ca65be016a951806ea947c]
+ mainline: [5cec2d2e5839f9c0fec319c523a911e0a7fd299f]
+```
+
+## Quickstart
+
+Clone `cip-kernel-sec` and install its dependencies:
+
+```
+$ git clone https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec
+$ cd cip-kernel-sec/
+$ sudo apt install python3-yaml python3-html5lib python3-cherrypy3 python3-jinja2
+```
+
+Prepare kernel remote repositories according to `conf/remotes.yml`:
+
+```
+$ ./scripts/prepare_remotes.py
+```
+
+Alternatively, you can do that manually:
+
+```
+$ mkdir ../kernel
+$ cd ../kernel
+$ git remote add torvalds https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+$ git remote add stable https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+$ git remote add cip https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
+$ cd ../cip-kernel-sec
+```
+
+Download CVE information from [Debian] (https://salsa.debian.org/kernel-team/kernel-sec.git), [Ubuntu] (https://git.launchpad.net/ubuntu-cve-tracker) and Stable:
+
+```
+
+$ ./scripts/import_debian.py
+ -> import/debian
+$ ./scripts/import_ubuntu.py
+ -> import/ubuntu
+$ ./scripts/import_stable.py
+ -> import/stable_branches.yml
+```
+
+Check issues that affect a linux-cip branch:
+
+```
+$ ./scripts/report_affected.py linux-4.4.y
+```
+
+You can show a short description on your report:
+
+```
+$ ./scripts/report_affected.py --show-description linux-4.4.y
+```
+
+Check issues that affect a tag:
+
+```
+$ ./scripts/report_affected.py v4.4.181-cip33
+```
+
+Browse kernel branches and issues interactively:
+
+```
+$ ./scripts/webview.py
+$ firefox http://localhost:8080
+```
+
+[Note] Use Ctr-c to stop the `webview.py` script.
+
+## Kernel maintainer workflow
+
+Import or update the latest CVE information:
+
+```
+$ ./scripts/import_debian.py
+$ ./scripts/import_ubuntu.py
+$ ./scripts/import_stable.py
+```
+
+Edit by hand the newly created issues if you see that some imported information is incorrect or there is missing information:
+
+```
+$ vi issues/CVE-xx.yml
+```
+
+Validate the issue files against the YAML schema.
+
+```
+$ ./scripts/validate.py
+```
+
+YAML allows the same thing to be written in different ways, e.g. bracketed vs bulleted lists. Use `cleanup.py` to make the syntax and ordering of items consistent with the importers, to reduce "noise" in diffs:
+
+```
+$ ./scripts/cleanup.py
+```
+
+Check if the current issues:
+
+```
+$ ./scripts/report_affected.py
+```
+
+## Changelog
+
+- 20190614: First version <daniel.sangorrin@...>
+- 20190618: Add workflow information provided by Ben
+- 20190711: Add tag reporting <daniel.sangorrin@...>
+
--
2.17.1


(No subject)

Daniel Sangorrin <daniel.sangorrin@...>
 

Hello Ben,

Sorry, I realized that there were a few issues in the Quickstart
so I am resending the patch. Please ignore the previous one.

[cip-kernel-sec][Quickstart v2] docs: add a quickstart with practical

Thanks,
Daniel


[cip-kernel-sec] readme: add info about tag_regexp and show-description

Daniel Sangorrin <daniel.sangorrin@...>
 

Probably this should be squashed into the corresponding
patches.

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
---
README.md | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 576cc75..8164826 100644
--- a/README.md
+++ b/README.md
@@ -41,7 +41,8 @@ current or previous year or that are already tracked here.
stable and other configured branches, by reading the git commit logs.

* `scripts/report_affected.py` - report which issues affect the
-specified branches, or all active branches.
+specified branches, or all active branches. You can use --show-description
+to obtain a short description for each CVE ID.

* `scripts/validate.py` - validate all issue files against the
schema.
@@ -72,6 +73,7 @@ keys:
* `base_ver`: Stable version that the branch is based on, e.g.
"4.4". This needs to be quoted so that it's a string not a
number.
+* `tag_regexp`: A regular expression that matches tags on a branch.

### Remotes

--
2.17.1

7081 - 7100 of 9694