|
[PATCH 4.19.y-cip 01/17] drm: rcar-du: lvds: Remove LVDS double-enable checks
Biju Das <biju.das.jz@...>
From: Laurent Pinchart <laurent.pinchart+renesas@...>
commit 968328496b0fbee42abb6fae98ba0dc720bda977 upstream. The DRM core and DU driver guarantee that the LVDS bridge will not be double-enabled or double-disabled. Remove the corresponding unnecessary checks. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@...> Reviewed-by: Jacopo Mondi <jacopo@...> Tested-by: Jacopo Mondi <jacopo+renesas@...> Acked-by: Sam Ravnborg <sam@...> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@...> Signed-off-by: Biju Das <biju.das.jz@...> --- drivers/gpu/drm/rcar-du/rcar_lvds.c | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 21fd248e5cbf..067017d25993 100644 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c @@ -62,7 +62,6 @@ struct rcar_lvds { struct clk *extal; /* External clock */ struct clk *dotclkin[2]; /* External DU clocks */ } clocks; - bool enabled; struct drm_display_mode display_mode; enum rcar_lvds_mode mode; @@ -367,15 +366,12 @@ int rcar_lvds_clk_enable(struct drm_bridge *bridge, unsigned long freq) dev_dbg(lvds->dev, "enabling LVDS PLL, freq=%luHz\n", freq); - WARN_ON(lvds->enabled); - ret = clk_prepare_enable(lvds->clocks.mod); if (ret < 0) return ret; __rcar_lvds_pll_setup_d3_e3(lvds, freq, true); - lvds->enabled = true; return 0; } EXPORT_SYMBOL_GPL(rcar_lvds_clk_enable); @@ -389,13 +385,9 @@ void rcar_lvds_clk_disable(struct drm_bridge *bridge) dev_dbg(lvds->dev, "disabling LVDS PLL\n"); - WARN_ON(!lvds->enabled); - rcar_lvds_write(lvds, LVDPLLCR, 0); clk_disable_unprepare(lvds->clocks.mod); - - lvds->enabled = false; } EXPORT_SYMBOL_GPL(rcar_lvds_clk_disable); @@ -416,8 +408,6 @@ static void rcar_lvds_enable(struct drm_bridge *bridge) u32 lvdcr0; int ret; - WARN_ON(lvds->enabled); - ret = clk_prepare_enable(lvds->clocks.mod); if (ret < 0) return; @@ -502,16 +492,12 @@ static void rcar_lvds_enable(struct drm_bridge *bridge) drm_panel_prepare(lvds->panel); drm_panel_enable(lvds->panel); } - - lvds->enabled = true; } static void rcar_lvds_disable(struct drm_bridge *bridge) { struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge); - WARN_ON(!lvds->enabled); - if (lvds->panel) { drm_panel_disable(lvds->panel); drm_panel_unprepare(lvds->panel); @@ -522,8 +508,6 @@ static void rcar_lvds_disable(struct drm_bridge *bridge) rcar_lvds_write(lvds, LVDPLLCR, 0); clk_disable_unprepare(lvds->clocks.mod); - - lvds->enabled = false; } static bool rcar_lvds_mode_fixup(struct drm_bridge *bridge, @@ -587,8 +571,6 @@ static void rcar_lvds_mode_set(struct drm_bridge *bridge, { struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge); - WARN_ON(lvds->enabled); - lvds->display_mode = *adjusted_mode; rcar_lvds_get_lvds_mode(lvds); @@ -788,7 +770,6 @@ static int rcar_lvds_probe(struct platform_device *pdev) lvds->dev = &pdev->dev; lvds->info = of_device_get_match_data(&pdev->dev); - lvds->enabled = false; ret = rcar_lvds_parse_dt(lvds); if (ret < 0) -- 2.17.1
|
|
|
|
[PATCH 4.19.y-cip 08/17] drm: Add atomic variants for bridge enable/disable
Biju Das <biju.das.jz@...>
From: Sean Paul <seanpaul@...>
commit 5ade071ba13e3bb24e3a9d5f8d6a3cf145deeb18 upstream. This patch adds atomic variants for all of pre_enable/enable/disable/post_disable bridge functions. These will be called from the appropriate atomic helper functions. If the bridge driver doesn't implement the atomic version of the function, we will fall back to the vanilla implementation. Note that some drivers call drm_bridge_disable directly, and these cases are not covered. It's up to the driver to decide whether to implement both atomic_disable and disable, or if it's not necessary. Changes in v3: - Added to the patchset Changes in v4: - Fix up docbook references (Daniel) Changes in v5: - None Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-4-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-4-sean@poorly.run Cc: Daniel Vetter <daniel@...> Cc: Ville Syrjälä <ville.syrjala@...> Tested-by: Heiko Stuebner <heiko@...> Reviewed-by: Daniel Vetter <daniel.vetter@...> Reviewed-by: Andrzej Hajda <a.hajda@...> Signed-off-by: Sean Paul <seanpaul@...> Link: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-4-sean@poorly.run Signed-off-by: Biju Das <biju.das.jz@...> --- drivers/gpu/drm/drm_atomic_helper.c | 8 +- drivers/gpu/drm/drm_bridge.c | 110 ++++++++++++++++++++++++++++ include/drm/drm_bridge.h | 106 +++++++++++++++++++++++++++ 3 files changed, 220 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index c22062cc9992..84bc8af8fc71 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -951,7 +951,7 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state) * Each encoder has at most one connector (since we always steal * it away), so we won't call disable hooks twice. */ - drm_bridge_disable(encoder->bridge); + drm_atomic_bridge_disable(encoder->bridge, old_state); /* Right function depends upon target state. */ if (funcs) { @@ -963,7 +963,7 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state) funcs->dpms(encoder, DRM_MODE_DPMS_OFF); } - drm_bridge_post_disable(encoder->bridge); + drm_atomic_bridge_post_disable(encoder->bridge, old_state); } for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { @@ -1262,7 +1262,7 @@ void drm_atomic_helper_commit_modeset_enables(struct drm_device *dev, * Each encoder has at most one connector (since we always steal * it away), so we won't call enable hooks twice. */ - drm_bridge_pre_enable(encoder->bridge); + drm_atomic_bridge_pre_enable(encoder->bridge, old_state); if (funcs) { if (funcs->enable) @@ -1271,7 +1271,7 @@ void drm_atomic_helper_commit_modeset_enables(struct drm_device *dev, funcs->commit(encoder); } - drm_bridge_enable(encoder->bridge); + drm_atomic_bridge_enable(encoder->bridge, old_state); } drm_atomic_helper_commit_writebacks(dev, old_state); diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index 1638bfe9627c..190f43380e29 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -348,6 +348,116 @@ void drm_bridge_enable(struct drm_bridge *bridge) } EXPORT_SYMBOL(drm_bridge_enable); +/** + * drm_atomic_bridge_disable - disables all bridges in the encoder chain + * @bridge: bridge control structure + * @state: atomic state being committed + * + * Calls &drm_bridge_funcs.atomic_disable (falls back on + * &drm_bridge_funcs.disable) op for all the bridges in the encoder chain, + * starting from the last bridge to the first. These are called before calling + * &drm_encoder_helper_funcs.atomic_disable + * + * Note: the bridge passed should be the one closest to the encoder + */ +void drm_atomic_bridge_disable(struct drm_bridge *bridge, + struct drm_atomic_state *state) +{ + if (!bridge) + return; + + drm_atomic_bridge_disable(bridge->next, state); + + if (bridge->funcs->atomic_disable) + bridge->funcs->atomic_disable(bridge, state); + else if (bridge->funcs->disable) + bridge->funcs->disable(bridge); +} +EXPORT_SYMBOL(drm_atomic_bridge_disable); + +/** + * drm_atomic_bridge_post_disable - cleans up after disabling all bridges in the + * encoder chain + * @bridge: bridge control structure + * @state: atomic state being committed + * + * Calls &drm_bridge_funcs.atomic_post_disable (falls back on + * &drm_bridge_funcs.post_disable) op for all the bridges in the encoder chain, + * starting from the first bridge to the last. These are called after completing + * &drm_encoder_helper_funcs.atomic_disable + * + * Note: the bridge passed should be the one closest to the encoder + */ +void drm_atomic_bridge_post_disable(struct drm_bridge *bridge, + struct drm_atomic_state *state) +{ + if (!bridge) + return; + + if (bridge->funcs->atomic_post_disable) + bridge->funcs->atomic_post_disable(bridge, state); + else if (bridge->funcs->post_disable) + bridge->funcs->post_disable(bridge); + + drm_atomic_bridge_post_disable(bridge->next, state); +} +EXPORT_SYMBOL(drm_atomic_bridge_post_disable); + +/** + * drm_atomic_bridge_pre_enable - prepares for enabling all bridges in the + * encoder chain + * @bridge: bridge control structure + * @state: atomic state being committed + * + * Calls &drm_bridge_funcs.atomic_pre_enable (falls back on + * &drm_bridge_funcs.pre_enable) op for all the bridges in the encoder chain, + * starting from the last bridge to the first. These are called before calling + * &drm_encoder_helper_funcs.atomic_enable + * + * Note: the bridge passed should be the one closest to the encoder + */ +void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge, + struct drm_atomic_state *state) +{ + if (!bridge) + return; + + drm_atomic_bridge_pre_enable(bridge->next, state); + + if (bridge->funcs->atomic_pre_enable) + bridge->funcs->atomic_pre_enable(bridge, state); + else if (bridge->funcs->pre_enable) + bridge->funcs->pre_enable(bridge); +} +EXPORT_SYMBOL(drm_atomic_bridge_pre_enable); + +/** + * drm_atomic_bridge_enable - enables all bridges in the encoder chain + * @bridge: bridge control structure + * @state: atomic state being committed + * + * Calls &drm_bridge_funcs.atomic_enable (falls back on + * &drm_bridge_funcs.enable) op for all the bridges in the encoder chain, + * starting from the first bridge to the last. These are called after completing + * &drm_encoder_helper_funcs.atomic_enable + * + * Note: the bridge passed should be the one closest to the encoder + */ +void drm_atomic_bridge_enable(struct drm_bridge *bridge, + struct drm_atomic_state *state) +{ + if (!bridge) + return; + + if (bridge->funcs->atomic_enable) + bridge->funcs->atomic_enable(bridge, state); + else if (bridge->funcs->enable) + bridge->funcs->enable(bridge); + + drm_atomic_bridge_enable(bridge->next, state); +} +EXPORT_SYMBOL(drm_atomic_bridge_enable); + #ifdef CONFIG_OF /** * of_drm_find_bridge - find the bridge corresponding to the device node in diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h index d26eaa317fc2..97b17cb9cc51 100644 --- a/include/drm/drm_bridge.h +++ b/include/drm/drm_bridge.h @@ -237,6 +237,103 @@ struct drm_bridge_funcs { * The enable callback is optional. */ void (*enable)(struct drm_bridge *bridge); + + /** + * @atomic_pre_enable: + * + * This callback should enable the bridge. It is called right before + * the preceding element in the display pipe is enabled. If the + * preceding element is a bridge this means it's called before that + * bridge's @atomic_pre_enable or @pre_enable function. If the preceding + * element is a &drm_encoder it's called right before the encoder's + * &drm_encoder_helper_funcs.atomic_enable hook. + * + * The display pipe (i.e. clocks and timing signals) feeding this bridge + * will not yet be running when this callback is called. The bridge must + * not enable the display link feeding the next bridge in the chain (if + * there is one) when this callback is called. + * + * Note that this function will only be invoked in the context of an + * atomic commit. It will not be invoked from &drm_bridge_pre_enable. It + * would be prudent to also provide an implementation of @pre_enable if + * you are expecting driver calls into &drm_bridge_pre_enable. + * + * The @atomic_pre_enable callback is optional. + */ + void (*atomic_pre_enable)(struct drm_bridge *bridge, + struct drm_atomic_state *state); + + /** + * @atomic_enable: + * + * This callback should enable the bridge. It is called right after + * the preceding element in the display pipe is enabled. If the + * preceding element is a bridge this means it's called after that + * bridge's @atomic_enable or @enable function. If the preceding element + * is a &drm_encoder it's called right after the encoder's + * &drm_encoder_helper_funcs.atomic_enable hook. + * + * The bridge can assume that the display pipe (i.e. clocks and timing + * signals) feeding it is running when this callback is called. This + * callback must enable the display link feeding the next bridge in the + * chain if there is one. + * + * Note that this function will only be invoked in the context of an + * atomic commit. It will not be invoked from &drm_bridge_enable. It + * would be prudent to also provide an implementation of @enable if + * you are expecting driver calls into &drm_bridge_enable. + * + * The enable callback is optional. + */ + void (*atomic_enable)(struct drm_bridge *bridge, + struct drm_atomic_state *state); + /** + * @atomic_disable: + * + * This callback should disable the bridge. It is called right before + * the preceding element in the display pipe is disabled. If the + * preceding element is a bridge this means it's called before that + * bridge's @atomic_disable or @disable vfunc. If the preceding element + * is a &drm_encoder it's called right before the + * &drm_encoder_helper_funcs.atomic_disable hook. + * + * The bridge can assume that the display pipe (i.e. clocks and timing + * signals) feeding it is still running when this callback is called. + * + * Note that this function will only be invoked in the context of an + * atomic commit. It will not be invoked from &drm_bridge_disable. It + * would be prudent to also provide an implementation of @disable if + * you are expecting driver calls into &drm_bridge_disable. + * + * The disable callback is optional. + */ + void (*atomic_disable)(struct drm_bridge *bridge, + struct drm_atomic_state *state); + + /** + * @atomic_post_disable: + * + * This callback should disable the bridge. It is called right after the + * preceding element in the display pipe is disabled. If the preceding + * element is a bridge this means it's called after that bridge's + * @atomic_post_disable or @post_disable function. If the preceding + * element is a &drm_encoder it's called right after the encoder's + * &drm_encoder_helper_funcs.atomic_disable hook. + * + * The bridge must assume that the display pipe (i.e. clocks and timing + * signals) feeding it is no longer running when this callback is + * called. + * + * Note that this function will only be invoked in the context of an + * atomic commit. It will not be invoked from &drm_bridge_post_disable. + * It would be prudent to also provide an implementation of + * @post_disable if you are expecting driver calls into + * &drm_bridge_post_disable. + * + * The post_disable callback is optional. + */ + void (*atomic_post_disable)(struct drm_bridge *bridge, + struct drm_atomic_state *state); }; /** @@ -323,6 +420,15 @@ void drm_bridge_mode_set(struct drm_bridge *bridge, void drm_bridge_pre_enable(struct drm_bridge *bridge); void drm_bridge_enable(struct drm_bridge *bridge); +void drm_atomic_bridge_disable(struct drm_bridge *bridge, + struct drm_atomic_state *state); +void drm_atomic_bridge_post_disable(struct drm_bridge *bridge, + struct drm_atomic_state *state); +void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge, + struct drm_atomic_state *state); +void drm_atomic_bridge_enable(struct drm_bridge *bridge, + struct drm_atomic_state *state); + #ifdef CONFIG_DRM_PANEL_BRIDGE struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel, u32 connector_type); -- 2.17.1
|
|
|
|
[PATCH 4.19.y-cip 00/17] Add RZ/G2E Dual LVDS display
Biju Das <biju.das.jz@...>
Add RZ/G2E Dual LVDS display support. All patches in this series are
cherry-picked from upstream kernel. Fabrizio Castro (7): drm: rcar-du: lvds: Improve identification of panels drm: of: Add drm_of_lvds_get_dual_link_pixel_order drm: rcar-du: lvds: Get dual link configuration from DT drm: rcar-du: lvds: Allow for even and odd pixels swap arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1 dt-bindings: display: Add idk-2121wr binding arm64: dts: renesas: Add EK874 board with idk-2121wr display support Geert Uytterhoeven (1): arm64: dts: renesas: rzg2: Add reset control properties for display Jacopo Mondi (1): drm: rcar_lvds: Fix dual link mode operations Laurent Pinchart (7): drm: rcar-du: lvds: Remove LVDS double-enable checks drm: bridge: Add dual_link field to the drm_bridge_timings structure dt-bindings: display: renesas: lvds: Add renesas,companion property drm: rcar-du: lvds: Add support for dual-link mode drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode drm: Add drm_atomic_get_(old|new)_connector_for_encoder() helpers drm: rcar-du: lvds: Get mode from state Sean Paul (1): drm: Add atomic variants for bridge enable/disable .../bindings/display/bridge/renesas,lvds.txt | 18 +- .../display/panel/advantech,idk-2121wr.yaml | 122 ++++++ arch/arm64/boot/dts/renesas/Makefile | 3 +- arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 5 +- arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 5 +- .../dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 ++++++ arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 8 +- drivers/gpu/drm/drm_atomic.c | 113 ++++++ drivers/gpu/drm/drm_atomic_helper.c | 8 +- drivers/gpu/drm/drm_bridge.c | 110 ++++++ drivers/gpu/drm/drm_of.c | 116 ++++++ drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +- drivers/gpu/drm/rcar-du/rcar_lvds.c | 348 +++++++++++------- drivers/gpu/drm/rcar-du/rcar_lvds.h | 5 + include/drm/drm_atomic.h | 7 + include/drm/drm_bridge.h | 114 ++++++ include/drm/drm_connector.h | 9 + include/drm/drm_of.h | 20 + 19 files changed, 996 insertions(+), 145 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts -- 2.17.1
|
|
|
|
Re: [isar-cip-core] tests: put all tests into a opt layer
Jan Kiszka
On 22.07.20 12:46, Daniel Sangorrin wrote:
Hi JanNobuhiro, is something missing from your perspective in Daniels approach? If not, I'd like to have one patch that takes us to that level.-----Original Message-----Sorry for the confusion. By now, I think an opt-testtools.yml is better (an "option", not a "layer") than a separate image. That allows to test the security image eventually as well. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
|
|
|
|
Re: [isar-cip-core] tests: put all tests into a opt layer
Daniel Sangorrin <daniel.sangorrin@...>
Hi Jan
toggle quoted messageShow quoted text
-----Original Message-----Sorry for the confusion. If you apply MR7, I will move the rt-tests and stress-ng packages from the customization "package" to the test image. If you instead apply MR5, I will move them to opt-testtools.yml Or is there any special reason for rt-tests and stress-ng to be in the customization package? Thanks, Daniel
|
|
|
|
Re: [isar-cip-core] tests: put all tests into a opt layer
Jan Kiszka
On 22.07.20 09:25, daniel.sangorrin@... wrote:
________________________________________That would confuse me now: What creating a separate test image first, just to remove it again? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
|
|
|
|
Re: [isar-cip-core] tests: put all tests into a opt layer
Daniel Sangorrin <daniel.sangorrin@...>
________________________________________
From: Jan Kiszka <jan.kiszka@...> Sent: Wednesday, July 22, 2020 3:44 PM To: cip-dev@...; sangorrin daniel(サンゴリン ダニエル □ＳＷＣ◯ＡＣＴ); iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ) Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt layer On 21.07.20 14:42, Daniel Sangorrin wrote: having an opt-tests layer makes it easier to see whatJAN: "Having ... as well." Does this obsolete https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/7, where I just commented on? DANIEL: Maybe you can apply Iwamatsu-san merge request first, and I will prepare a new patch on top of that to avoid confusion. Thanks, Daniel Wording: It's not a testing layer, it's "test packages", no? +This, in fact, has some benefit over a separate image in that it would also allow to make the security image testable by appending the snippet +No extra line at EOF, please. diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bbMaybe "reference customizations" - typically, you will replace this package for a real product with a, well, product specific customization. No extra line at EOF, please. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
|
|
|
|
Re: [isar-cip-core] tests: put all tests into a opt layer
Jan Kiszka
On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what"Having ... as well." Does this obsolete https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/7, where I just commented on? Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>Wording: It's not a testing layer, it's "test packages", no? +This, in fact, has some benefit over a separate image in that it would also allow to make the security image testable by appending the snippet +No extra line at EOF, please. diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bbMaybe "reference customizations" - typically, you will replace this package for a real product with a, well, product specific customization. SRC_URI = " \No extra line at EOF, please. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
|
|
|
|
Re: Kindly review for kernel config changes
Daniel Sangorrin <daniel.sangorrin@...>
Hi Kent,
Let me check if we can use the cip-kernel-config version on ISAR and remove the one in isar-cip-core. I will also add nftables as a fragment to isar-cip-core until you tell me that it needs long-term support. If it needs long-term support we will have to move it to cip-kernel-config. Thanks, Daniel ________________________________________ From: cip-dev@... <cip-dev@...> on behalf of Kento Yoshida <kento.yoshida.wz@...> Sent: Tuesday, July 21, 2020 5:40 PM To: cip-dev@... Subject: Re: [cip-dev] Kindly review for kernel config changes isar-cip-core and deby share cip-kernel-config configuration files.I see. Thank you, Daniel. But, I'm wondering why conf/machine/qemu-amd64.conf doesn't define USE_CIP_KERNEL_CONFIG = "1". Do you have any information for this, Dinesh or Venkata? I think we should reconfirm to add these configs to https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/-/blob/master/4.19.y-cip/x86/cip_qemu_defconfig. Or, have you already confirmed to build the image using this? BR, Kent -----Original Message-----
|
|
|
|
Fw: [isar-cip-core] tests: put all tests into a opt layer
Daniel Sangorrin <daniel.sangorrin@...>
Hi Jan,
Sorry, I failed to put you in the Cc when I sent this patch. There are also 3 patches from Venkata-san on the cip-dev mailing list (sent yesterday) Apart from that there are some merge requests on gitlab. Thanks, Daniel ________________________________________ From: Daniel Sangorrin <daniel.sangorrin@...> Sent: Tuesday, July 21, 2020 7:59 PM To: sangorrin daniel(サンゴリン ダニエル □ＳＷＣ◯ＡＣＴ) Subject: [isar-cip-core] tests: put all tests into a opt layer having an opt-tests layer makes it easier to see what tests are installed, and allows creating images without them as well Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...> --- .gitlab-ci.yml | 8 ++++---- README.md | 4 ++++ opt-tests.yml | 19 +++++++++++++++++++ recipes-core/customizations/customizations.bb | 5 ++--- recipes-core/images/cip-core-image.bb | 3 +-- 5 files changed, 30 insertions(+), 9 deletions(-) create mode 100644 opt-tests.yml diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 6f1dc91..90eec1f 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -13,17 +13,17 @@ all: - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY - - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster simatic-ipc227e - sudo rm -rf build/tmp - - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb - sudo rm -rf build/tmp - - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb - sudo rm -rf build/tmp - - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb diff --git a/README.md b/README.md index bbad1a0..7339396 100644 --- a/README.md +++ b/README.md @@ -25,6 +25,10 @@ this: This image can be run using `start-qemu.sh x86`. +If you want to include the testing layer add ':opt-tests.yml' like this + + ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml + The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19. diff --git a/opt-tests.yml b/opt-tests.yml new file mode 100644 index 0000000..a1f431d --- /dev/null +++ b/opt-tests.yml @@ -0,0 +1,19 @@ +# +# CIP Core, generic profile +# +# Copyright (c) Toshiba corp., 2020 +# +# Authors: +# Daniel Sangorrin <daniel.sangorrin@...> +# +# SPDX-License-Identifier: MIT +# + +header: + version: 8 + +local_conf_header: + tests: | + IMAGE_INSTALL += "ltp-full" + IMAGE_PREINSTALL += "rt-tests stress-ng" + diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb index 38881fb..cbd6daf 100644 --- a/recipes-core/customizations/customizations.bb +++ b/recipes-core/customizations/customizations.bb @@ -11,7 +11,7 @@ inherit dpkg-raw -DESCRIPTION = "CIP Core image demo & test customizations" +DESCRIPTION = "CIP Core image demo customizations" SRC_URI = " \ file://postinst \ @@ -21,8 +21,7 @@ SRC_URI = " \ DEPENDS += "sshd-regen-keys" DEBIAN_DEPENDS = " \ - ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \ - rt-tests, stress-ng" + ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys" do_install() { install -v -d ${D}/etc/network/interfaces.d diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb index 9ee4b25..188c714 100644 --- a/recipes-core/images/cip-core-image.bb +++ b/recipes-core/images/cip-core-image.bb @@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always DESCRIPTION = "CIP Core image" IMAGE_INSTALL += "customizations" -# for cip-testing -IMAGE_INSTALL += "ltp-full" + -- 2.25.1
|
|
|
|
Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms
Biju Das <biju.das.jz@...>
Hi Pavel,
Thanks for the feedback. Subject: Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additionalYes, Will do. Regards, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647
|
|
|
|
Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms
Pavel Machek
Hi!
I see it is already pushed, thank you!On Mon 2020-07-20 18:52:23, Biju Das wrote:Both patches seem to be okay to me.From: Geert Uytterhoeven <geert+renesas@...>Ok, I can apply this if there are no comments. Biju, the first patch seems like a bugfix suitable for -stable. Can you send it to Greg (etc) for inclusion? Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
|
|
|
|
[isar-cip-core] tests: put all tests into a opt layer
Daniel Sangorrin <daniel.sangorrin@...>
having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without them as well Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...> --- .gitlab-ci.yml | 8 ++++---- README.md | 4 ++++ opt-tests.yml | 19 +++++++++++++++++++ recipes-core/customizations/customizations.bb | 5 ++--- recipes-core/images/cip-core-image.bb | 3 +-- 5 files changed, 30 insertions(+), 9 deletions(-) create mode 100644 opt-tests.yml diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 6f1dc91..90eec1f 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -13,17 +13,17 @@ all: - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY - - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster simatic-ipc227e - sudo rm -rf build/tmp - - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb - sudo rm -rf build/tmp - - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb - sudo rm -rf build/tmp - - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb diff --git a/README.md b/README.md index bbad1a0..7339396 100644 --- a/README.md +++ b/README.md @@ -25,6 +25,10 @@ this: This image can be run using `start-qemu.sh x86`. +If you want to include the testing layer add ':opt-tests.yml' like this + + ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml + The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19. diff --git a/opt-tests.yml b/opt-tests.yml new file mode 100644 index 0000000..a1f431d --- /dev/null +++ b/opt-tests.yml @@ -0,0 +1,19 @@ +# +# CIP Core, generic profile +# +# Copyright (c) Toshiba corp., 2020 +# +# Authors: +# Daniel Sangorrin <daniel.sangorrin@...> +# +# SPDX-License-Identifier: MIT +# + +header: + version: 8 + +local_conf_header: + tests: | + IMAGE_INSTALL += "ltp-full" + IMAGE_PREINSTALL += "rt-tests stress-ng" + diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb index 38881fb..cbd6daf 100644 --- a/recipes-core/customizations/customizations.bb +++ b/recipes-core/customizations/customizations.bb @@ -11,7 +11,7 @@ inherit dpkg-raw -DESCRIPTION = "CIP Core image demo & test customizations" +DESCRIPTION = "CIP Core image demo customizations" SRC_URI = " \ file://postinst \ @@ -21,8 +21,7 @@ SRC_URI = " \ DEPENDS += "sshd-regen-keys" DEBIAN_DEPENDS = " \ - ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \ - rt-tests, stress-ng" + ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys" do_install() { install -v -d ${D}/etc/network/interfaces.d diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb index 9ee4b25..188c714 100644 --- a/recipes-core/images/cip-core-image.bb +++ b/recipes-core/images/cip-core-image.bb @@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always DESCRIPTION = "CIP Core image" IMAGE_INSTALL += "customizations" -# for cip-testing -IMAGE_INSTALL += "ltp-full" + -- 2.25.1
|
|
|
|
Re: Kindly review for kernel config changes
Kento Yoshida
isar-cip-core and deby share cip-kernel-config configuration files.I see. Thank you, Daniel. But, I'm wondering why conf/machine/qemu-amd64.conf doesn't define USE_CIP_KERNEL_CONFIG = "1". Do you have any information for this, Dinesh or Venkata? I think we should reconfirm to add these configs to https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/-/blob/master/4.19.y-cip/x86/cip_qemu_defconfig. Or, have you already confirmed to build the image using this? BR, Kent -----Original Message-----
|
|
|
|
[PATCH 3/3] README: Add steps to build cip-security image
Venkata Pyla
From: venkata <venkata.pyla@...>
Signed-off-by: venkata <venkata.pyla@...> --- README.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/README.md b/README.md index bbad1a0..b2c4166 100644 --- a/README.md +++ b/README.md @@ -36,6 +36,16 @@ card, run dd if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-buster-bbb.wic.img \ of=/dev/<medium-device> bs=1M status=progress +## Building Security target images +Building images for QEMU x86-64bit machine + + ./kas-docker --isar build --target cip-core-image-security kas.yml:board-qemu-amd64.yml + +Run the generated securiy images on QEMU (x86-64bit) + + TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64 + + ## Community Resources TBD -- 2.27.0.windows.1 The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use.
|
|
|
|
[PATCH 2/3] start-qemu.sh: use TARGET_IMAGE to pick respective image file
Venkata Pyla
From: venkata <venkata.pyla@...>
if 'TARGET_IMAGE' variable is not set then it pick "cip-core-image", to pick different target image set the 'TARGET_IMAGE' variable as below e.g: $TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64 Signed-off-by: venkata <venkata.pyla@...> --- start-qemu.sh | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/start-qemu.sh b/start-qemu.sh index 49f0266..5c17d74 100755 --- a/start-qemu.sh +++ b/start-qemu.sh @@ -75,7 +75,11 @@ if [ -z "${DISTRO_RELEASE}" ]; then DISTRO_RELEASE="buster" fi -IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/cip-core-image-cip-core-${DISTRO_RELEASE}-qemu-${DISTRO_ARCH}" +if [ -z "${TARGET_IMAGE}" ]; then + TARGET_IMAGE="cip-core-image" +fi + +IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/${TARGET_IMAGE}-cip-core-${DISTRO_RELEASE}-qemu-${DISTRO_ARCH}" IMAGE_FILE=$(ls ${IMAGE_PREFIX}.ext4.img) if [ -z "${DISPLAY}" ]; then -- 2.27.0.windows.1 The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use.
|
|
|
|
[PATCH 1/3] cip-security: Add packages for IEC-62443-4-2 Evaluation.
Venkata Pyla
From: Kazuhiro Hayashi <kazuhiro3.hayashi@...>
Identified security packages are added to the target image and that will be used for IEC-62443-4-2 evaluation Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@...> Signed-off-by: pvenkata2 <venkata.pyla@...> --- .../images/cip-core-image-security.bb | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 recipes-core/images/cip-core-image-security.bb diff --git a/recipes-core/images/cip-core-image-security.bb b/recipes-core/images/cip-core-image-security.bb new file mode 100644 index 0000000..8253952 --- /dev/null +++ b/recipes-core/images/cip-core-image-security.bb @@ -0,0 +1,37 @@ +# +# A reference image which includes security packages +# +# Copyright (c) Toshiba Corporation, 2020 +# +# Authors: +# Kazuhiro Hayashi <kazuhiro3.hayashi@...> +# +# SPDX-License-Identifier: MIT +# + +inherit image + +DESCRIPTION = "CIP Core image including security packages" + +# Use the same customizations as cip-core-image +IMAGE_INSTALL += "customizations" + +# Debian packages that provide security features +IMAGE_PREINSTALL += " \ + openssl libssl1.1 \ + fail2ban \ + openssh-server openssh-sftp-server openssh-client \ + syslog-ng-core syslog-ng-mod-journal \ + aide aide-common \ + libnftables0 nftables \ + libpam-pkcs11 \ + chrony \ + tpm2-tools \ + tpm2-abrmd \ + libtss2-esys0 libtss2-udev \ + libpam-cracklib \ + acl \ + libauparse0 audispd-plugins auditd \ + uuid-runtime \ + sudo \ +" -- 2.27.0.windows.1 The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use.
|
|
|
|
Re: Kindly review for kernel config changes
Daniel Sangorrin <daniel.sangorrin@...>
Hi Kent,
The configuration should go to https://gitlab.com/cip-project/cip-kernel/cip-kernel-config not isar-cip-core. isar-cip-core and deby share cip-kernel-config configuration files. *isar-cip-core still has the configuration files there but conf/machine files with USE_CIP_KERNEL_CONFIG = "1" do not use them anymore. Actually that is a nother AI. Thanks, Daniel ________________________________________ From: cip-dev@... <cip-dev@...> on behalf of Kento Yoshida <kento.yoshida.wz@...> Sent: Tuesday, July 21, 2020 4:12 PM To: cip-dev@... Subject: [cip-dev] Kindly review for kernel config changes Hi, The security working group need to use "nftables", and it requires to add the below kernel configs to work. Before merging to the master branch of "isar-cip-core", would you kindly review to add the below configs by this Friday, everyone? --- a/recipes-kernel/linux/files/qemu-amd64_defconfig +++ b/recipes-kernel/linux/files/qemu-amd64_defconfig @@ -351,3 +351,34 @@ CONFIG_CRYPTO_DEV_CCP=y # CONFIG_XZ_DEC_ARM is not set # CONFIG_XZ_DEC_ARMTHUMB is not set # CONFIG_XZ_DEC_SPARC is not set +CONFIG_NF_TABLES=y +CONFIG_NF_TABLES_INET=y +CONFIG_NF_TABLES_NETDEV=y +CONFIG_NFT_EXTHDR=y +CONFIG_NFT_META=y +CONFIG_NFT_CT=y +CONFIG_NFT_RBTREE=y +CONFIG_NFT_HASH=y +CONFIG_NFT_COUNTER=y +CONFIG_NFT_LOG=y +CONFIG_NFT_LIMIT=y +CONFIG_NFT_MASQ=y +CONFIG_NFT_REDIR=y +CONFIG_NFT_NAT=y +CONFIG_NFT_QUEUE=y +CONFIG_NFT_REJECT=y +CONFIG_NFT_REJECT_INET=y +CONFIG_NFT_COMPAT=y +CONFIG_NFT_CHAIN_ROUTE_IPV4=y +CONFIG_NFT_REJECT_IPV4=y +CONFIG_NFT_CHAIN_NAT_IPV4=y +CONFIG_NFT_MASQ_IPV4=y +# CONFIG_NFT_REDIR_IPV4 is not set +CONFIG_NFT_CHAIN_ROUTE_IPV6=y +CONFIG_NFT_REJECT_IPV6=y +CONFIG_NFT_CHAIN_NAT_IPV6=y +CONFIG_NFT_MASQ_IPV6=y +# CONFIG_NFT_REDIR_IPV6 is not set +CONFIG_NFT_BRIDGE_META=y +CONFIG_NFT_BRIDGE_REJECT=y +CONFIG_NF_LOG_BRIDGE=y BR, Kent
|
|
|
|
Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms
Biju Das <biju.das.jz@...>
Hi Pavel and Nobuhiro,
toggle quoted messageShow quoted text
Thanks for the feedback.
-----Original Message-----Yes Will do. Regards, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647
|
|
|
|
Kindly review for kernel config changes
Kento Yoshida
Hi,
The security working group need to use "nftables", and it requires to add the below kernel configs to work. Before merging to the master branch of "isar-cip-core", would you kindly review to add the below configs by this Friday, everyone?
--- a/recipes-kernel/linux/files/qemu-amd64_defconfig +++ b/recipes-kernel/linux/files/qemu-amd64_defconfig @@ -351,3 +351,34 @@ CONFIG_CRYPTO_DEV_CCP=y # CONFIG_XZ_DEC_ARM is not set # CONFIG_XZ_DEC_ARMTHUMB is not set # CONFIG_XZ_DEC_SPARC is not set +CONFIG_NF_TABLES=y +CONFIG_NF_TABLES_INET=y +CONFIG_NF_TABLES_NETDEV=y +CONFIG_NFT_EXTHDR=y +CONFIG_NFT_META=y +CONFIG_NFT_CT=y +CONFIG_NFT_RBTREE=y +CONFIG_NFT_HASH=y +CONFIG_NFT_COUNTER=y +CONFIG_NFT_LOG=y +CONFIG_NFT_LIMIT=y +CONFIG_NFT_MASQ=y +CONFIG_NFT_REDIR=y +CONFIG_NFT_NAT=y +CONFIG_NFT_QUEUE=y +CONFIG_NFT_REJECT=y +CONFIG_NFT_REJECT_INET=y +CONFIG_NFT_COMPAT=y +CONFIG_NFT_CHAIN_ROUTE_IPV4=y +CONFIG_NFT_REJECT_IPV4=y +CONFIG_NFT_CHAIN_NAT_IPV4=y +CONFIG_NFT_MASQ_IPV4=y +# CONFIG_NFT_REDIR_IPV4 is not set +CONFIG_NFT_CHAIN_ROUTE_IPV6=y +CONFIG_NFT_REJECT_IPV6=y +CONFIG_NFT_CHAIN_NAT_IPV6=y +CONFIG_NFT_MASQ_IPV6=y +# CONFIG_NFT_REDIR_IPV6 is not set +CONFIG_NFT_BRIDGE_META=y +CONFIG_NFT_BRIDGE_REJECT=y +CONFIG_NF_LOG_BRIDGE=y
BR, Kent
|
|
|