* [Intel-wired-lan] [RFC 08/13] ice: Don't explicitly set port_vlan_bits to 0
From: Shannon Nelson @ 2018-07-23 16:57 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180720195446.4346-9-anirudh.venkataramanan@intel.com>
On 7/20/2018 12:54 PM, Anirudh Venkataramanan wrote:
> From: Brett Creeley <brett.creeley@intel.com>
>
> This patch fixes the following smatch warning originally reported by
> Dan Carpenter:
> ice_set_dflt_vsi_ctx() warn: odd binop '0x0 & 0x18'
>
> In ice_set_dflt_vsi_ctx() we are currently doing logic that is intended
> to explicitly clear bits 3 and 4 for port_vlan_flags. Clearing these
> bits results in legacy behavior (showing VLAN, DEI, and UP) in the
> descriptors. The issue was this was reporting the Smatch error shown
> below. To fix this remove this logic because the port_vlan_flags field
There is no "smatch warning shown below"
> is set to 0 initially by memset so by default we have the correct legacy
> behavior for bits 3 and 4. A comment was added above where we set
> port_vlan_flags in ice_set_dflt_vsi_ctx() to note that this is the
> desired behavior.
>
> Signed-off-by: Brett Creeley <brett.creeley@intel.com>
> [Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> cleaned up commit message]
This would be a better comment after the "---". Check you other patches
as well for this.
> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_main.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index feeca75912ec..586c6e615a98 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -1367,14 +1367,13 @@ static void ice_set_dflt_vsi_ctx(struct ice_vsi_ctx *ctxt)
> ctxt->info.sw_flags = ICE_AQ_VSI_SW_FLAG_SRC_PRUNE;
> /* Traffic from VSI can be sent to LAN */
> ctxt->info.sw_flags2 = ICE_AQ_VSI_SW_FLAG_LAN_ENA;
> - /* Allow all packets untagged/tagged */
> + /* By default bits 3 and 4 in port_vlan_flags are 0's which results in
> + * legacy behavior (show VLAN, DEI, and UP) in descriptor. Also, allow
> + * all packets untagged/tagged.
> + */
> ctxt->info.port_vlan_flags = ((ICE_AQ_VSI_PVLAN_MODE_ALL &
> ICE_AQ_VSI_PVLAN_MODE_M) >>
> ICE_AQ_VSI_PVLAN_MODE_S);
> - /* Show VLAN/UP from packets in Rx descriptors */
> - ctxt->info.port_vlan_flags |= ((ICE_AQ_VSI_PVLAN_EMOD_STR_BOTH &
> - ICE_AQ_VSI_PVLAN_EMOD_M) >>
> - ICE_AQ_VSI_PVLAN_EMOD_S);
> /* Have 1:1 UP mapping for both ingress/egress tables */
> table |= ICE_UP_TABLE_TRANSLATE(0, 0);
> table |= ICE_UP_TABLE_TRANSLATE(1, 1);
>
^ permalink raw reply
* Re: [PATCH 1/9] contrib: add a script to initialize VS Code configuration
From: Jonathan Nieder @ 2018-07-23 16:57 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget
Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <e2e449a00385531d326d6811a871dde59624b818.1532353966.git.gitgitgadget@gmail.com>
Hi,
Thanks for working on this.
Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> VS Code is a lightweight but powerful source code editor which runs on
> your desktop and is available for Windows, macOS and Linux. Among other
> languages, it has support for C/C++ via an extension.
This doesn't really seem relevant to the change. The relevant bits
are that (1) VS Code is a popular source code editor, and that (2)
it's one worth recommending to newcomers.
> To start developing Git with VS Code, simply run the Unix shell script
> contrib/vscode/init.sh, which creates the configuration files in
> .vscode/ that VS Code consumes.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This doesn't tell me what the patch will actually do.
VSCode is an editor. Is the idea that this will help configure the
editor to do the right thing with whitespace or something? Or does it
configure IDE features to build git?
Thanks,
Jonathan
^ permalink raw reply
* [Intel-wired-lan] [RFC 00/13] Bug fixes for ice
From: Shannon Nelson @ 2018-07-23 16:57 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180720195446.4346-1-anirudh.venkataramanan@intel.com>
On 7/20/2018 12:54 PM, Anirudh Venkataramanan wrote:
> This patch set fixes multiple bugs for the ice driver.
Since the ice driver original patches are still under review and not yet
upstream, why are these bug fixes not rolled into the original patch
set? Put these into the initial patch set and have a clearer upstream
submission.
sln
>
> Anirudh Venkataramanan (4):
> ice: Fix static analyser warning
> ice: Cleanup magic number
> ice: Fix bugs in control queue processing
> ice: Fix couple of null pointer dereference issues
>
> Brett Creeley (2):
> ice: Don't explicitly set port_vlan_bits to 0
> ice: Set VLAN flags correctly
>
> Bruce Allan (3):
> ice: Fix missing shift
> ice: Update to interrupts enabled in OICR
> ice: Change struct members from bool to u8
>
> Jacob Keller (2):
> ice: Report stats for allocated queues via ethtool stats
> ice: Use order_base_2 to calculate higher power of 2
>
> Jesse Brandeburg (1):
> ice: Fix potential return of uninitialized value
>
> Preethi Banala (1):
> ice: Clean control queues only when they are initialized
>
> drivers/net/ethernet/intel/ice/ice.h | 15 ++--
> drivers/net/ethernet/intel/ice/ice_adminq_cmd.h | 1 +
> drivers/net/ethernet/intel/ice/ice_controlq.c | 29 +++++---
> drivers/net/ethernet/intel/ice/ice_ethtool.c | 52 ++++++++++----
> drivers/net/ethernet/intel/ice/ice_hw_autogen.h | 8 ---
> drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h | 1 +
> drivers/net/ethernet/intel/ice/ice_main.c | 91 +++++++++++++++----------
> drivers/net/ethernet/intel/ice/ice_switch.c | 3 +-
> drivers/net/ethernet/intel/ice/ice_switch.h | 6 +-
> drivers/net/ethernet/intel/ice/ice_txrx.h | 2 +-
> drivers/net/ethernet/intel/ice/ice_type.h | 16 ++---
> 11 files changed, 141 insertions(+), 83 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v6 4/5] ARM: dts: imx7s: add i.MX7 messaging unit support
From: Lucas Stach @ 2018-07-23 16:57 UTC (permalink / raw)
To: Oleksij Rempel, Shawn Guo, Fabio Estevam, Rob Herring,
Mark Rutland, A.s. Dong, Vladimir Zapolskiy
Cc: kernel, devicetree, dl-linux-imx, linux-arm-kernel
In-Reply-To: <20180722063923.30222-5-o.rempel@pengutronix.de>
Am Sonntag, den 22.07.2018, 08:39 +0200 schrieb Oleksij Rempel:
> Define the Messaging Unit (MU) for i.MX7 in the processor's dtsi.
> The respective driver is added in the next commit.
>
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> arch/arm/boot/dts/imx7s.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index ce85b3ca1a55..191a0286fa3b 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -1001,6 +1001,25 @@
> > status = "disabled";
> > };
>
> > > + mu0a: mailbox@30aa0000 {
> + compatible = "fsl,imx7s-mu", "fsl,imx6sx-mu";
Those compatibles are missing documentation in the binding.
> + reg = <0x30aa0000 0x10000>;
> > + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> > + #mbox-cells = <1>;
> > + status = "disabled";
> > + };
> +
> > > + mu0b: mailbox@30ab0000 {
> > + compatible = "fsl,imx7s-mu", "fsl,imx6sx-mu";
> > + reg = <0x30ab0000 0x10000>;
> > + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> > + #mbox-cells = <1>;
> > + fsl,mu-side-b;
> > + status = "disabled";
> > + };
> +
> > > usbotg1: usb@30b10000 {
> > compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> > reg = <0x30b10000 0x200>;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 4/5] ARM: dts: imx7s: add i.MX7 messaging unit support
From: Lucas Stach @ 2018-07-23 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180722063923.30222-5-o.rempel@pengutronix.de>
Am Sonntag, den 22.07.2018, 08:39 +0200 schrieb Oleksij Rempel:
> Define the Messaging Unit (MU) for i.MX7 in the processor's dtsi.
> The respective driver is added in the next commit.
>
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> ?arch/arm/boot/dts/imx7s.dtsi | 19 +++++++++++++++++++
> ?1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index ce85b3ca1a55..191a0286fa3b 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -1001,6 +1001,25 @@
> > ? status = "disabled";
> > ? };
> ?
> > > + mu0a: mailbox at 30aa0000 {
> + compatible = "fsl,imx7s-mu", "fsl,imx6sx-mu";
Those compatibles are missing documentation in the binding.
> + reg = <0x30aa0000 0x10000>;
> > + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> > + #mbox-cells = <1>;
> > + status = "disabled";
> > + };
> +
> > > + mu0b: mailbox at 30ab0000 {
> > + compatible = "fsl,imx7s-mu", "fsl,imx6sx-mu";
> > + reg = <0x30ab0000 0x10000>;
> > + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> > + #mbox-cells = <1>;
> > + fsl,mu-side-b;
> > + status = "disabled";
> > + };
> +
> > > ? usbotg1: usb at 30b10000 {
> > ? compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> > ? reg = <0x30b10000 0x200>;
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 31/40] target/mips: Fix ERET/ERETNC behavior related to ADEL exception
From: Richard Henderson @ 2018-07-23 16:56 UTC (permalink / raw)
To: Stefan Markovic, qemu-devel
Cc: laurent, riku.voipio, philippe.mathieu.daude, aurelien, amarkovic,
smarkovic, pjovanovic, pburton
In-Reply-To: <1532004912-13899-32-git-send-email-stefan.markovic@rt-rk.com>
On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> if (env->insn_flags & ISA_NANOMIPS32) {
> /* Don't clear MIPS_HFLAG_M16 */
> + if (error_pc & 1) {
> + if (!(env->hflags & MIPS_HFLAG_DM)) {
> + env->CP0_BadVAddr = error_pc;
> + }
> + env->active_tc.PC = error_pc;
> + do_raise_exception(env, EXCP_AdEL, 0);
> + }
> return;
Why does this need to be done here, when it is also done in translate.c?
r~
^ permalink raw reply
* Re: [PATCH 3/4] perf/x86/intel/ds: Handle PEBS overflow for fixed counters
From: Liang, Kan @ 2018-07-23 16:56 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tglx, mingo, linux-kernel, acme, alexander.shishkin,
vincent.weaver, jolsa, ak
In-Reply-To: <20180723162114.GD2512@hirez.programming.kicks-ass.net>
On 7/23/2018 12:21 PM, Peter Zijlstra wrote:
> On Mon, Jul 23, 2018 at 04:59:44PM +0200, Peter Zijlstra wrote:
>> On Thu, Mar 08, 2018 at 06:15:41PM -0800, kan.liang@linux.intel.com wrote:
>>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>>> index ef47a418d819..86149b87cce8 100644
>>> --- a/arch/x86/events/intel/core.c
>>> +++ b/arch/x86/events/intel/core.c
>>> @@ -2280,7 +2280,10 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
>>> * counters from the GLOBAL_STATUS mask and we always process PEBS
>>> * events via drain_pebs().
>>> */
>>> - status &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK);
>>> + if (x86_pmu.flags & PMU_FL_PEBS_ALL)
>>> + status &= ~(cpuc->pebs_enabled & EXTENDED_PEBS_COUNTER_MASK);
>>> + else
>>> + status &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK);
>>>
>>> /*
>>> * PEBS overflow sets bit 62 in the global status register
>>
>> Doesn't this re-introduce the problem fixed in commit fd583ad1563be,
>> where pebs_enabled:32-34 are PEBS Load Latency, instead of fixed
>> counters?
>
> Also, since they 'fixed' that conflict, the PEBS_ALL version could be:
>
> state &= cpuc->pebs_enabled;
>
> Right?
Right.
Thanks,
Kan
^ permalink raw reply
* [PATCH xf86-video-ati] Remove drmmode_terminate_leases
From: Michel Dänzer @ 2018-07-23 16:56 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
From: Michel Dänzer <michel.daenzer@amd.com>
The RandR screen private is already freed when our CloseScreen runs, so
this can't do anything useful. This cleanup has to be done by the X
server itself.
(Ported from amdgpu commit 5f06d6b8ba570b500956ad26fee711d5ac427818)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
---
src/drmmode_display.c | 20 --------------------
src/drmmode_display.h | 2 --
src/radeon_kms.c | 1 -
3 files changed, 23 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index ff098975f..60c1cdc18 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -2522,26 +2522,6 @@ drmmode_terminate_lease(RRLeasePtr lease)
#endif // XF86_LEASE_VERSION
-void
-drmmode_terminate_leases(ScrnInfoPtr pScrn)
-{
-#ifdef XF86_LEASE_VERSION
- ScreenPtr screen = xf86ScrnToScreen(pScrn);
- RADEONEntPtr pRADEONEnt = RADEONEntPriv(pScrn);
- rrScrPrivPtr scr_priv = rrGetScrPriv(screen);
- RRLeasePtr lease, next;
-
- xorg_list_for_each_entry_safe(lease, next, &scr_priv->leases, list) {
- drmmode_lease_private_ptr lease_private = lease->devPrivate;
- drmModeRevokeLease(pRADEONEnt->fd, lease_private->lessee_id);
- free(lease_private);
- lease->devPrivate = NULL;
- RRLeaseTerminated(lease);
- RRLeaseFree(lease);
- }
-#endif
-}
-
static const xf86CrtcConfigFuncsRec drmmode_xf86crtc_config_funcs = {
.resize = drmmode_xf86crtc_resize,
#ifdef XF86_LEASE_VERSION
diff --git a/src/drmmode_display.h b/src/drmmode_display.h
index 4551e0c77..c5a55891a 100644
--- a/src/drmmode_display.h
+++ b/src/drmmode_display.h
@@ -227,8 +227,6 @@ PixmapPtr drmmode_crtc_scanout_create(xf86CrtcPtr crtc,
extern void drmmode_uevent_init(ScrnInfoPtr scrn, drmmode_ptr drmmode);
extern void drmmode_uevent_fini(ScrnInfoPtr scrn, drmmode_ptr drmmode);
-extern void drmmode_terminate_leases(ScrnInfoPtr scrn);
-
Bool drmmode_set_mode(xf86CrtcPtr crtc, struct drmmode_fb *fb,
DisplayModePtr mode, int x, int y);
diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index c8a5726ad..36840ad36 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -2154,7 +2154,6 @@ static Bool RADEONCloseScreen_KMS(ScreenPtr pScreen)
/* Clear mask of assigned crtc's in this generation */
pRADEONEnt->assigned_crtcs = 0;
- drmmode_terminate_leases(pScrn);
drmmode_uevent_fini(pScrn, &info->drmmode);
radeon_drm_queue_close(pScrn);
radeon_cs_flush_indirect(pScrn);
--
2.18.0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Re: [PATCH] ARM: dts: r8a77470: Use r8a77470-sysc binding definitions
From: Simon Horman @ 2018-07-23 15:53 UTC (permalink / raw)
To: Biju Das
Cc: Rob Herring, Mark Rutland, Magnus Damm, Chris Paterson,
Fabrizio Castro, devicetree, linux-renesas-soc
In-Reply-To: <1532092022-64918-1-git-send-email-biju.das@bp.renesas.com>
On Fri, Jul 20, 2018 at 02:07:02PM +0100, Biju Das wrote:
> Replace the hardcoded power domain indices by R8A77470_PD_* symbols.
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Chris Paterson <chris.paterson2@renesas.com>
> ---
> Commit 964f7c0dd23de68c0 ("soc: renesas: rcar-sysc: Add r8a77470 support")
> is in Linus' tree
> ---
> arch/arm/boot/dts/r8a77470.dtsi | 27 ++++++++++++++-------------
> 1 file changed, 14 insertions(+), 13 deletions(-)
Thanks,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v5 1/3] crypto/openssl: add rsa and mod asym op
From: Verma, Shally @ 2018-07-23 16:55 UTC (permalink / raw)
To: Stephen Hemminger
Cc: pablo.de.lara.guarch@intel.com, dev@dpdk.org,
Athreya, Narayana Prasad, Murthy, Nidadavolu, Sahu, Sunila,
Gupta, Ashish
In-Reply-To: <20180723095027.40c7c1bf@xeon-e3>
>-----Original Message-----
>From: Stephen Hemminger <stephen@networkplumber.org>
>Sent: 23 July 2018 22:20
>To: Verma, Shally <Shally.Verma@cavium.com>
>Cc: pablo.de.lara.guarch@intel.com; dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy,
>Nidadavolu <Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish
><Ashish.Gupta@cavium.com>
>Subject: Re: [dpdk-dev] [PATCH v5 1/3] crypto/openssl: add rsa and mod asym op
>
>External Email
>
>On Mon, 23 Jul 2018 20:16:03 +0530
>Shally Verma <shally.verma@caviumnetworks.com> wrote:
>
>> +#define set_rsa_params(rsa, p, q, ret) \
>> + do {rsa->p = p; rsa->q = q; ret = 0; } while (0)
>> +
>> +#define set_rsa_crt_params(rsa, dmp1, dmq1, iqmp, ret) \
>> + do { \
>> + rsa->dmp1 = dmp1; \
>> + rsa->dmq1 = dmq1; \
>> + rsa->iqmp = iqmp; \
>> + ret = 0; \
>> + } while (0)
>> +
>> +#define set_rsa_keys(rsa, n, e, d, ret) \
>> + do { \
>> + rsa->n = n; rsa->e = e; rsa->d = d; ret = 0; \
>> + } while (0)
>> +
>> +#else
>> +
>> +#define set_rsa_params(rsa, p, q, ret) \
>> + (ret = !RSA_set0_factors(rsa, p, q))
>> +
>> +#define set_rsa_crt_params(rsa, dmp1, dmq1, iqmp, ret) \
>> + (ret = !RSA_set0_crt_params(rsa, dmp1, dmq1, iqmp))
>> +
>> +/* n, e must be non-null, d can be NULL */
>> +#define set_rsa_keys(rsa, n, e, d, ret) \
>> + (ret = !RSA_set0_key(rsa, n, e, d))
>> +
>> +#endif /* version < 10100000 */
>> +
>> +#endif /* __RTA_COMPAT_H__ */
>
>Please use inline functions instead of macros.
>The crypto code seems to favor macros?
>
Since amount of code is very miniscule under each, so keeping as macro looked reasonable however, what goes in favour of inline than macros?
Thanks for feedback.
Shally
>Macro's have no type checking and are not faster anyway.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 30/40] target/mips: Adjust set_pc() for nanoMIPS
From: Richard Henderson @ 2018-07-23 16:55 UTC (permalink / raw)
To: Stefan Markovic, qemu-devel
Cc: laurent, riku.voipio, philippe.mathieu.daude, aurelien, amarkovic,
smarkovic, pjovanovic, pburton
In-Reply-To: <1532004912-13899-31-git-send-email-stefan.markovic@rt-rk.com>
On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> From: James Hogan <james.hogan@mips.com>
>
> ERET and ERETNC shouldn't clear MIPS_HFLAG_M16 for nanoMIPS since there
> is no ISA bit, so fix set_pc() to skip the hflags update.
>
> Signed-off-by: James Hogan <james.hogan@mips.com>
> Signed-off-by: Yongbok Kim <yongbok.kim@mips.com>
> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> ---
> target/mips/op_helper.c | 4 ++++
> 1 file changed, 4 insertions(+)
See my comments for 28/40.
r~
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 29/40] target/mips: Adjust set_hflags_for_handler() for nanoMIPS
From: Richard Henderson @ 2018-07-23 16:54 UTC (permalink / raw)
To: Stefan Markovic, qemu-devel
Cc: laurent, riku.voipio, philippe.mathieu.daude, aurelien, amarkovic,
smarkovic, pjovanovic, pburton
In-Reply-To: <1532004912-13899-30-git-send-email-stefan.markovic@rt-rk.com>
On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> From: James Hogan <james.hogan@mips.com>
>
> We shouldn't clear M16 mode when entering an interrupt on nanoMIPS,
> otherwise we'll start interpreting the code as normal MIPS code.
>
> Signed-off-by: James Hogan <james.hogan@mips.com>
> Signed-off-by: Yongbok Kim <yongbok.kim@mips.com>
> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> ---
> target/mips/helper.c | 3 +++
> 1 file changed, 3 insertions(+)
See my comments for 28/40.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 28/40] target/mips: Adjust exception_resume_pc() for nanoMIPS
From: Richard Henderson @ 2018-07-23 16:54 UTC (permalink / raw)
To: Stefan Markovic, qemu-devel
Cc: laurent, riku.voipio, philippe.mathieu.daude, aurelien, amarkovic,
smarkovic, pjovanovic, pburton
In-Reply-To: <1532004912-13899-29-git-send-email-stefan.markovic@rt-rk.com>
On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> From: James Hogan <james.hogan@mips.com>
>
> We shouldn't set the ISA bit in CP0_EPC for nanoMIPS.
>
> Signed-off-by: James Hogan <james.hogan@mips.com>
> Signed-off-by: Yongbok Kim <yongbok.kim@mips.com>
> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> ---
> target/mips/helper.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/target/mips/helper.c b/target/mips/helper.c
> index dc8f2a5..fb47018 100644
> --- a/target/mips/helper.c
> +++ b/target/mips/helper.c
> @@ -656,7 +656,8 @@ target_ulong exception_resume_pc (CPUMIPSState *env)
> target_ulong bad_pc;
> target_ulong isa_mode;
>
> - isa_mode = !!(env->hflags & MIPS_HFLAG_M16);
> + isa_mode = env->hflags & MIPS_HFLAG_M16 &&
> + !(env->insn_flags & ISA_NANOMIPS32);
Is there a compelling reason to have MIPS_HFLAG_M16 *set* for ISA_NANOMIPS?
This seems like the 6th or 7th patch that works around M16. If M16 were always
unset for nanomips, it would have avoided a lot of extra effort, it would seem.
In addition, looking at the fully patched tree and grepping for HFLAG_M16,
there appear to be further uses that have been missed for the extra NANOMIPS check.
r~
^ permalink raw reply
* Re: [PATCH v3 4/5] compress/zlib: support burst enqueue/dequeue
From: Stephen Hemminger @ 2018-07-23 16:53 UTC (permalink / raw)
To: Shally Verma
Cc: pablo.de.lara.guarch, dev, pathreya, mchalla, ashish.gupta,
sunila.sahu, Sunila Sahu
In-Reply-To: <1532197069-24224-5-git-send-email-shally.verma@caviumnetworks.com>
On Sat, 21 Jul 2018 23:47:48 +0530
Shally Verma <shally.verma@caviumnetworks.com> wrote:
> -/** Parse comp xform and set private xform/stream parameters */
> +/** Compute next mbuf in the list, assign data buffer and length,
> + * returns 0 if mbuf is NULL
> + */
> +#define COMPUTE_BUF(mbuf, data, len) \
> + ((mbuf = mbuf->next) ? \
> + (data = rte_pktmbuf_mtod(mbuf, uint8_t *)), \
> + (len = rte_pktmbuf_data_len(mbuf)) : 0)
> +
Could this be an inline not a macro?
^ permalink raw reply
* [PATCH] gpio: ml-ioh: Fix buffer underwrite on probe error path
From: Anton Vasilyev @ 2018-07-23 16:53 UTC (permalink / raw)
To: Linus Walleij; +Cc: Anton Vasilyev, linux-gpio, linux-kernel, ldv-project
If ioh_gpio_probe() fails on devm_irq_alloc_descs() then chip may point
to any element of chip_save array, so reverse iteration from pointer chip
may become chip_save[-1] and gpiochip_remove() will operate with wrong
memory.
The patch fix the error path of ioh_gpio_probe() to correctly bypass
chip_save array.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
---
drivers/gpio/gpio-ml-ioh.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-ml-ioh.c b/drivers/gpio/gpio-ml-ioh.c
index b23d9a36be1f..51c7d1b84c2e 100644
--- a/drivers/gpio/gpio-ml-ioh.c
+++ b/drivers/gpio/gpio-ml-ioh.c
@@ -496,9 +496,10 @@ static int ioh_gpio_probe(struct pci_dev *pdev,
return 0;
err_gpiochip_add:
+ chip = chip_save;
while (--i >= 0) {
- chip--;
gpiochip_remove(&chip->gpio);
+ chip++;
}
kfree(chip_save);
--
2.18.0
^ permalink raw reply related
* Re: [PATCH] ARM: dts: rcar: Correct SATA device sizes to 2 MiB
From: Simon Horman @ 2018-07-23 15:51 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Magnus Damm, linux-renesas-soc
In-Reply-To: <20180720122857.30235-1-geert+renesas@glider.be>
On Fri, Jul 20, 2018 at 02:28:57PM +0200, Geert Uytterhoeven wrote:
> Update the SATA device nodes on R-Car H1, H2, and M2-W to use a 2 MiB
> I/O space, as specified in Rev.1.0 of the R-Car H1 and R-Car Gen2
> hardware user manuals.
>
> See also commit e9f0089b2d8a3d45 ("arm64: dts: r8a7795: Correct SATA
> device size to 2MiB").
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Max Gurtovoy @ 2018-07-23 16:53 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, 'Sagi Grimberg', 'Leon Romanovsky',
'Doug Ledford', 'RDMA mailing list',
'Saeed Mahameed', 'linux-netdev'
In-Reply-To: <20180723164910.GS31540@mellanox.com>
On 7/23/2018 7:49 PM, Jason Gunthorpe wrote:
> On Fri, Jul 20, 2018 at 04:25:32AM +0300, Max Gurtovoy wrote:
>>
>>>>> [ 2032.194376] nvme nvme0: failed to connect queue: 9 ret=-18
>>>>
>>>> queue 9 is not mapped (overlap).
>>>> please try the bellow:
>>>>
>>>
>>> This seems to work. Here are three mapping cases: each vector on its
>>> own cpu, each vector on 1 cpu within the local numa node, and each
>>> vector having all cpus in its numa node. The 2nd mapping looks kinda
>>> funny, but I think it achieved what you wanted? And all the cases
>>> resulted in successful connections.
>>>
>>
>> Thanks for testing this.
>> I slightly improved the setting of the left CPUs and actually used Sagi's
>> initial proposal.
>>
>> Sagi,
>> please review the attached patch and let me know if I should add your
>> signature on it.
>> I'll run some perf test early next week on it (meanwhile I run login/logout
>> with different num_queues successfully and irq settings).
>>
>> Steve,
>> It will be great if you can apply the attached in your system and send your
>> findings.
>>
>> Regards,
>> Max,
>
> So the conlusion to this thread is that Leon's mlx5 patch needs to wait
> until this block-mq patch is accepted?
Yes, since nvmf is the only user of this function.
Still waiting for comments on the suggested patch :)
>
> Thanks,
> Jason
>
^ permalink raw reply
* Re: [PATCH] sched: add 64-bit counter retrieval API
From: Stephen Hemminger @ 2018-07-23 16:52 UTC (permalink / raw)
To: alangordondewar; +Cc: cristian.dumitrescu, dev, Alan Dewar
In-Reply-To: <1531925499-938-1-git-send-email-alan.dewar@att.com>
On Wed, 18 Jul 2018 15:51:39 +0100
alangordondewar@gmail.com wrote:
> From: Alan Dewar <alan.dewar@att.com>
>
> Add new APIs to retrieve counters in 64-bit wide fields.
>
> Signed-off-by: Alan Dewar <alan.dewar@att.com>
Do you want to consider 64 bit counter roll over on 32 bit platform?
The problem is that incrementing an 64 bit value is not atomic on
32 bit cpu. The carry operation can race with reading.
The kernel has special case code to do restartable sequence for
accessing 64 bit counter on 32 bit CPU. These functions become
nop's on 64bit.
^ permalink raw reply
* Re: Does /dev/urandom now block until initialised ?
From: Ken Moffat @ 2018-07-23 16:52 UTC (permalink / raw)
To: Theodore Y. Ts'o, Ken Moffat, linux-crypto, lkml
In-Reply-To: <20180723151608.GE3358@thunk.org>
On 23 July 2018 at 16:16, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Mon, Jul 23, 2018 at 04:43:01AM +0100, Ken Moffat wrote:
>>
>> Did that, no change. Ran strace from the bootscript, confirmed that
>> only /dev/urandom was being used, and that it seemed to be blocking.
>
> Nope, /dev/urandom still doesn't block. Are you sure it isn't caused
> by something calling getrandom(2) --- which *will* block?
I'm not at all sure, which was why I asked.
>
> We intentionally left /dev/urandom non-blocking, because of backwards
> compatibility.
>
>> BUT: I'm not sure if I've correctly understood what is happening.
>> It seems to me that the fix for CVE-2018-1108 (4.17-rc1, 4.16.4)
>> means /dev/urandom will now block until fully initialised.
>>
>> Is that correct and intentional ?
>
> No, that's not right. What the fix does is more accurately account
> for the entropy accounting before getrandom(2) would become
> non-blocking. There were a bunch of things we were doing wrong,
> including assuming that 100% of the bytes being sent via
> add_device_entropy() were random --- when some of the things that were
> feeding into it was the (fixed) information you would get from running
> dmidecode (e.g., the fixed results from the BIOS configuration data).
>
> Some of those bytes might not be known to an external adversary (such
> as your CPU mainboard's serial number), but it's not exactly *Secret*.
>
>> If so, to get the affected desktop machines to boot I seem to have
>> some choices...
>
> Well, this probably isn't going to be popular, but the other thing
> that might help is you could switch distro's. I'm guessing you run a
> Red Hat distro, probably Fedora, right?
>
Wrong, linuxfromscratch (sysv version) and beyond linuxfromscratch
plus extras such as chronyd. The only initrd is on the haswell, and just
for intel microcode.
> The problem which most people are seeing turns out to be a terrible
> interaction between dracut-fips, systemd and a Red Hat specific patch
> to libgcrypt for FIPS/FEDRAMP compliance:
>
> https://src.fedoraproject.org/rpms/libgcrypt/blob/master/f/libgcrypt-1.6.2-fips-ctor.patch#_23
>
> Uninstalling dracut-fips and recreating the initramfs might also help.
>
> One of the reasons why I didn't see the problem when I was developing
> the remediation patch for CVE-2018-1108 is because I run Debian
> testing, which doesn't have this particular Red Hat patch.
>
>> The latter certainly lets it boot in a reasonable time, but people
>> who understand this seem to regard it as untrustworthy. For users
>> of /dev/urandom that is no big deal, but does it not mean that the
>> values from /dev/random will be similarly untrustworthy and
>> therefore I should not use this machine for generating long-lived
>> secure keys ?
>
> This really depends on how paranoid / careful you are. Remember, your
> keyboard controller was almost certainly built in Shenzhen, China, and
> Matt Blaze published a paper on the Jitterbug in 2006:
>
> http://www.crypto.com/papers/jbug-Usenix06-final.pdf
>
> In practice, after 30 minutes of operation, especially if you are
> using the keyboard, the entropy pool *will* be sufficiently
> randomized, whether or not it was sufficientl randomized at boot. The
> real danger of CVE-2018-1108 was always long-term keys generated at
> first boot. That was the problem that was discussed in the "Mining
> your p's and q's: Detection of Widespread Weak Keys in Network
> Devices" (see https://factorable.net).
>
> So generating long-lived keys means (a) you need to be sure you trust
> all of the software on the system --- some very paranoid people such
> as Bruce Schneier used a freshly installed machine from CD-ROM that
> was never attached to the network before examining materials from
> Edward Snowden, and (b) making sure the entropy pool is initialized.
>
> Remember we are constantly feeding input from the hardware sources
> into the entropy pool; it doesn't stop the moment we think the entropy
> pool is initialized. And you can always mix extra "stuff" into the
> entropy pool by echoing the results of say, taking series of dice
> rolls, aond sending it via the "cat" or "echo" command into
> /dev/urhandom.
>
> So it should be possible to use the machine for generated long lived
> keys; you might just need to be a bit more careful before you do it.
> It's really keys generated automatically at boot that are most at risk
> --- and you can always regenerate the host SSH keys after a fresh
> install. In fact, what I have done in the past when I first login to
> a freshly created Cloud VM system is to run command like "dd
> if=/dev/urandom count=1 bs=256 | od -x", then login to VM, and then
> run "cat > /dev/urandom", and cut and paste the results of the od -x
> output into the guest VM, to better initialize the entropy pool on the
> VM before regenerating the host SSH keys.
>
> Cheers,
>
> - Ted
Thanks. In that case I'll go with the simple fix (haveged).
ĸen
^ permalink raw reply
* [Cluster-devel] [GFS2 PATCH] gfs2: Return all reservations when rgrp_brelse is called
From: Andreas Gruenbacher @ 2018-07-23 16:52 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <972293249.53472433.1532359760435.JavaMail.zimbra@redhat.com>
On 23 July 2018 at 17:29, Bob Peterson <rpeterso@redhat.com> wrote:
> ----- Original Message -----
>> > Before this patch, function gfs2_rgrp_brelse would release its
>> > buffer_heads for the rgrp bitmaps, but it did not release its
>> > reservations. The problem is: When we need to call brelse, we're
>> > basically letting go of the bitmaps, which means our reservations
>> > are no longer valid: someone on another node may have reserved those
>> > blocks and even used them. This patch makes the function returns all
>> > the block reservations held for the rgrp whose buffer_heads are
>> > being released.
>> What advantage does this give us? The reservations are intended to be
>> hints, so this should not be a problem,
>>
>> Steve.
>
> Hi Steve,
>
> I've been working toward a block reservation system that allows multiple
> writers to allocate blocks while sharing resource groups (rgrps) that
> are locked for EX. The goal, of course, is to improve write concurrency
> and eliminate intra-node write imbalances.
>
> My patches all work reasonably well until rgrps fill up and get down
> to their last few blocks, in which case the spans of free blocks aren't
> long enough for a minimum reservation, due to rgrp fragmentation. With
> today's current code, multiple processes doing block allocations can't
> bump heads and interfere with one another because they each lock the
> rgrp in EX for a span that covers from the block reservation all the
> way up to block allocation. But when we enable multiple processes to
> share the rgrp, we need to ensure they can't over-commit the rgrp.
>
> So the problem is over-commitment of rgrps.
>
> For example, let's say you have 10 processes that each want to write
> 5 blocks. The rgrp glock is locked in EX and they begin sharing it.
> When they check the rgrp's free space in inplace_reserve, each one of
> the 10, in turn, asks the question, "Does this rgrp have 5 free blocks
> available?" Let's say the rgrp has 20 free blocks, so of course the
> answer is "yes" for all 10 processes. But when they go to actually
> allocate those blocks, the first 4 processes use up those 20 free
> blocks. At that point, the rgrp is completely full, but the other 6
> processes are over-committed to use that rgrp based on their
> requirements. Now we have 6 processes that are unable to allocate
> a single block from an rgrp that had previously deemed to have enough.
>
> So basically, the problem is that our current block reservations system
> has a concept of (a) "This rgrp has X reservations," and (b) "there are
> Y blocks leftover that cannot be reserved for general use." That allows
> for rgrps to be over-committed.
>
> (1) My proposed solution
>
> To allow for rgrp sharing, I'm trying to tighten things up and
> eliminate the "slop". I'm trying to transition the system from a simple
> hint to an actual "promise", i.e. an accounting system so that
> over-committing is not possible. With this new system there is still a
> concept of (a) "This rgrp has X reservations," but (b) now becomes
> "This rgrp has X of my remaining blocks promised to various processes."
> So accounting is done to keep track of how many of the free blocks are
> promised for allocations outside of reservations. After all block
> allocations have been done for a transaction, any remaining blocks that
> have been promised from the rgrp to that process are then rescinded,
> which means they go back to the general pool of free blocks for
> other processes to use.
I'd call that a reservation, as opposed to what the code does
currently. Right now, processes are asking for a TARGET number of
blocks and at least MIN_TARGET blocks, but they get whatever is
available in the chosen resource group. There is no checking if
processes overrun what they've been asking for, and we don't know if
the reservations were large enough.
> There are, of course, other ways we can do this. For example, we can:
>
> (2) Alternate solution 1 - "the rest goes to process n"
>
> Automatically assign "all remaining unreserved blocks" to
> the first process needing them and force all the others to a different
> rgrp. But after years of use, when the rgrps become severely
> fragmented, that system would cause much more of a slowdown.
>
> (3) Alternate solution 2 - "hold the lock from reservation to allocation"
>
> Of course, we could also block other processes from the rgrp from
> reservation to allocation, but that would have almost no advantage
> over what we do today: it would pretty much negate rgrp sharing
> and we'd end up with the write imbalance problems we have today.
>
> (4) Alternate solution 3 - "Hint with looping"
>
> We could also put a system in place whereby we still use "hints".
> Processes that had called inplace_reserve for a given rgrp, but
> are now out of free blocks because of over-commitment (we had a
> hint, not a promise) must then loop back around and call function
> inplace_reserve again, searching for a different rgrp that might
> work instead, in which case it could run into the same situation
> multiple times. That would most likely be a performance disaster.
>
> (5) Alternate solution 4 - "One (or small) block reservations"
>
> We could allow for one-block (or at least small-block) reservations
> and keep a queue of them or something to fulfill a multi-block
> allocation requirement. I suspect this would be a nightmare of
> kmem_cache_alloc requests and have a lot more overhead than simply
> making promises.
>
> (6) Alternate solution 5 - "assign unique rgrps"
>
> We could go back to a system where multiple allocators are
> given unique rgrps to work on (which I've proposed in the past,
> but been rejected) but it's pretty much what RHEL6 and prior
> releases do by using "try" locks on rgrps. (Which is why
> simultaneous allocators often perform better on RHEL6 and oder.)
>
> In my opinion, there's no advantage to using a hint when we can
> do actual accounting to keep track of spans of blocks too small
> to be considered for a reservation.
AFAIK, fallocate is the only caller based on "give me all you have"
semantics. It shouldn't be hard to change that to simply take out
pretty large reservations; regular writes should have a reasonably
good idea how many blocks they may require. And with the recent iomap
restructuring, they'll know exactly how many blocks they'll require
pretty soon. So I'm all for moving to actual reservations.
> Regards,
>
> Bob Peterson
> Red Hat File Systems
Thanks,
Andreas
^ permalink raw reply
* Re: [PATCH] net/p9/trans_fd.c: fix double list_del()
From: Tomas Bortoli @ 2018-07-23 16:51 UTC (permalink / raw)
To: Dominique Martinet
Cc: ericvh, rminnich, lucho, jiangyiwen, davem, v9fs-developer,
netdev, linux-kernel, syzkaller
In-Reply-To: <20180723125701.GA17971@nautica>
On 07/23/2018 02:57 PM, Dominique Martinet wrote:
> Tomas Bortoli wrote on Mon, Jul 23, 2018:
>> A double list_del(&req->req_list) is possible in p9_fd_cancel() as
>> shown by Syzbot. To prevent it we have to ensure that we have the
>> client->lock when deleting the list. Furthermore, we have to update
>> the status of the request before releasing the lock, to prevent the
>> race.
>
> Nice, so no need to change the list_del to list_del_init!
>
> I still have a nitpick on the last moved unlock, but it's mostly
> aesthetic - the change looks much better to me now.
>
> (Since that will require a v2 I'll be evil and go further than Yiwen
> about the commit message: let it breathe a bit! :) I think a line break
> before "furthermore" for example will make it easier to read)
>
agree
>>
>> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
>> Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
>> ---
>> net/9p/trans_fd.c | 9 ++++-----
>> 1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
>> index a64b01c56e30..370c6c69a05c 100644
>> --- a/net/9p/trans_fd.c
>> +++ b/net/9p/trans_fd.c
>> @@ -199,15 +199,14 @@ static void p9_mux_poll_stop(struct p9_conn *m)
>> static void p9_conn_cancel(struct p9_conn *m, int err)
>> {
>> struct p9_req_t *req, *rtmp;
>> - unsigned long flags;
>> LIST_HEAD(cancel_list);
>>
>> p9_debug(P9_DEBUG_ERROR, "mux %p err %d\n", m, err);
>>
>> - spin_lock_irqsave(&m->client->lock, flags);
>> + spin_lock(&m->client->lock);
>>
>> if (m->err) {
>> - spin_unlock_irqrestore(&m->client->lock, flags);
>> + spin_unlock(&m->client->lock);
>> return;
>> }
>>
>> @@ -219,7 +218,6 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
>> list_for_each_entry_safe(req, rtmp, &m->unsent_req_list, req_list) {
>> list_move(&req->req_list, &cancel_list);
>> }
>> - spin_unlock_irqrestore(&m->client->lock, flags);
>>
>> list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
>> p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
>> @@ -228,6 +226,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
>> req->t_err = err;
>> p9_client_cb(m->client, req, REQ_STATUS_ERROR);
>> }
>> + spin_unlock(&m->client->lock);
>> }
>>
>> static __poll_t
>> @@ -370,12 +369,12 @@ static void p9_read_work(struct work_struct *work)
>> if (m->req->status != REQ_STATUS_ERROR)
>> status = REQ_STATUS_RCVD;
>> list_del(&m->req->req_list);
>> - spin_unlock(&m->client->lock);
>> p9_client_cb(m->client, m->req, status);
>> m->rc.sdata = NULL;
>> m->rc.offset = 0;
>> m->rc.capacity = 0;
>> m->req = NULL;
>> + spin_unlock(&m->client->lock);
>
> It took me a while to understand why you extended this lock despite
> having just read the commit message, I'd suggest:
> - moving the spin_unlock to right after p9_client_cb (afterall that's
> what we want, the m->rc and m->req don't need to be protected)
yes, better.
> - add a comment before p9_client_cb saying something like 'updates
> req->status' or try to explain why it needs to be locked here but other
> transports don't need such a lock (they're not dependant on req->status
> like this)
>
ok
thanks for the feedback
^ permalink raw reply
* arch/arc/ allmodconfig
From: Leon Romanovsky @ 2018-07-23 16:51 UTC (permalink / raw)
To: linux-snps-arc
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075012B07F319@us01wembx1.internal.synopsys.com>
On Mon, Jul 23, 2018@04:36:57PM +0000, Vineet Gupta wrote:
> Hi Ofer,
>
> On 07/23/2018 01:34 AM, Ofer Levi(SW) wrote:
> > Hi Vineet, randy
> >
> > Indeed this structure is missing, following is a patch based on linux-4.17.9.
> > Sorry about that.
> >
> > Thanks
> >
> >
> > diff -uprN linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h
> > --- linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h 2018-07-22 16:16:09.000000000 +0300
> > +++ linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h 2018-07-23 11:18:12.179402620 +0300
> > @@ -143,6 +143,15 @@ struct nps_host_reg_gim_p_int_dst {
> > };
> >
> > /* AUX registers definition */
> > +struct nps_host_reg_aux_dpc {
> > + union {
> > + struct {
> > + u32 ien:1, men:1, hen:1, reserved:29;
> > + };
> > + u32 value;
> > + };
> > +};
> > +
> > struct nps_host_reg_aux_udmc {
> > union {
> > struct {
>
> Thx for this change. Can you please send a proper patch with changelog, citing the
> issue as Reported-by etc.
> Also if Mellanox is interested in maintaining the NPS port going fwd, someone (you
> ?) should add their name to MAINTAINERS file under arch/arc/plat-eznps and send
> that patch as well.
Hi Vineet,
Thanks for your feedback, I'll work with Ofer to make it happen.
>
> Thx,
> -Vineet
>
>
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Meir Lichtinger
> >> Sent: Friday, July 20, 2018 10:19
> >> To: Vineet Gupta <Vineet.Gupta1 at synopsys.com>; Randy Dunlap
> >> <rdunlap at infradead.org>; LKML <linux-kernel at vger.kernel.org>; linux-
> >> snps-arc at lists.infradead.org; Ofer Levi(SW) <oferle at mellanox.com>
> >> Cc: Leon Romanovsky <leonro at mellanox.com>
> >> Subject: RE: arch/arc/ allmodconfig
> >>
> >> Hi Vineet,
> >> Ofer Levi is now the maintainer of arch/arc/plat-eznps
> >>
> >> Ofer,
> >> Please take care of the issue below
> >>
> >> Thanks
> >>
> >>
> >> -----Original Message-----
> >> From: Vineet Gupta [mailto:Vineet.Gupta1 at synopsys.com]
> >> Sent: Thursday, July 19, 2018 19:22
> >> To: Randy Dunlap <rdunlap at infradead.org>; LKML <linux-
> >> kernel at vger.kernel.org>; Vineet Gupta <Vineet.Gupta1 at synopsys.com>;
> >> linux-snps-arc at lists.infradead.org
> >> Cc: Elad Kanfi <eladkan at mellanox.com>; Leon Romanovsky
> >> <leonro at mellanox.com>
> >> Subject: Re: arch/arc/ allmodconfig
> >>
> >> +CC some folks from Mellanox
> >>
> >> On 07/18/2018 10:37 PM, Randy Dunlap wrote:
> >>> Hi,
> >>>
> >>> When I try to (cross-)build arch/arc/ allmodconfig, I get a syntax error here:
> >>>
> >>> ./arch/arc/plat-eznps/mtm.c: In function 'mtm_enable_core':
> >>> ../arch/arc/plat-eznps/mtm.c:113:30: error: storage size of 'dpc' isn't known
> >>> struct nps_host_reg_aux_dpc dpc;
> >>> ^~~
> >>>
> >>> There is no struct nps_host_reg_aux_dpc in the kernel tree.
> >>>
> >>> Can you do something about this, please?
> >> Thx for the report Randy. I'm calling out Mellanox folks to see if they can
> >> provide a fixup, else we will revert the corresponding change.
> >>
> >> @Elad, upstream commit 3f9cd874dcc8705 "ARC: [plat-eznps] avoid toggling
> >> of DPC register" added reference to struct nps_host_reg_aux_dpc but the
> >> definition is missing. Can you please provide a fixup as I have no idea of that
> >> platform specific struct.
> >>
> >> @ Leon, reaching our to you, since it seems you removed Elad from
> >> MAINTAINERS file, so I'm not sure if he is still at Mellanox.
> >> The two folks I worked with on EZCHiip Linux port Noam Camus and Gilad
> >> have left Mellanox.
> >> If you or someone from Mellanox are interested in maintaining this platform,
> >> please update the arch/arc/plat-eznps section of MAINTAINERS file.
> >>
> >>
> >> Thx,
> >> -Vineet
>
^ permalink raw reply
* Re: [PATCH v2 08/10] coresight: perf: Add helper to retrieve sink configuration
From: Mathieu Poirier @ 2018-07-23 16:50 UTC (permalink / raw)
To: Suzuki K. Poulose
Cc: linux-arm-kernel, Linux Kernel Mailing List, Robert Walker,
Mike Leach, coresight
In-Reply-To: <ed621d62-a1d2-abe1-3763-60ea6e5f615f@arm.com>
On Fri, 20 Jul 2018 at 02:43, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
>
> On 19/07/18 21:07, Mathieu Poirier wrote:
> > On Tue, Jul 17, 2018 at 06:11:39PM +0100, Suzuki K Poulose wrote:
> >> We can always find the sink configuration for a given perf_output_handle.
> >> Add a helper to retrieve the sink configuration for a given
> >> perf_output_handle. This will be used to get rid of the set_buffer()
> >> call back.
> >>
> >> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> >> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >> ---
> >> drivers/hwtracing/coresight/coresight-etm-perf.c | 14 -------------
> >> drivers/hwtracing/coresight/coresight-etm-perf.h | 26 ++++++++++++++++++++++++
> >> 2 files changed, 26 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> >> index 6a4252b..3cc4a0b 100644
> >> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> >> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> >> @@ -23,20 +23,6 @@
> >> static struct pmu etm_pmu;
> >> static bool etm_perf_up;
> >>
> >> -/**
> >> - * struct etm_event_data - Coresight specifics associated to an event
> >> - * @work: Handle to free allocated memory outside IRQ context.
> >> - * @mask: Hold the CPU(s) this event was set for.
> >> - * @snk_config: The sink configuration.
> >> - * @path: An array of path, each slot for one CPU.
> >> - */
> >> -struct etm_event_data {
> >> - struct work_struct work;
> >> - cpumask_t mask;
> >> - void *snk_config;
> >> - struct list_head * __percpu *path;
> >> -};
> >> -
> >
> > If this is moved to coresight-etm-perf.h, the #include <linux/percpu-defs.h> can
> > be removed.
>
> Actually, we do have the PER_CPU variables in the file already, which is why I left
> them there. See the next line.
Of course...
> >
> >> static DEFINE_PER_CPU(struct perf_output_handle, ctx_handle);
> >> static DEFINE_PER_CPU(struct coresight_device *, csdev_src);
> >>
>
>
> >> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
> >> index 4197df4..da7d933 100644
> >> --- a/drivers/hwtracing/coresight/coresight-etm-perf.h
> >> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
> >> @@ -7,6 +7,7 @@
> >> #ifndef _CORESIGHT_ETM_PERF_H
> >> #define _CORESIGHT_ETM_PERF_H
> >>
> >> +#include <linux/percpu-defs.h>
> >> #include "coresight-priv.h"
> >>
> >> struct coresight_device;
> >> @@ -42,14 +43,39 @@ struct etm_filters {
> >> bool ssstatus;
> >> };
> >>
> >> +/**
> >> + * struct etm_event_data - Coresight specifics associated to an event
> >> + * @work: Handle to free allocated memory outside IRQ context.
> >> + * @mask: Hold the CPU(s) this event was set for.
> >> + * @snk_config: The sink configuration.
> >> + * @path: An array of path, each slot for one CPU.
> >> + */
> >> +struct etm_event_data {
> >> + struct work_struct work;
> >> + cpumask_t mask;
> >> + void *snk_config;
> >> + struct list_head * __percpu *path;
> >> +};
> >>
> >> #ifdef CONFIG_CORESIGHT
> >> int etm_perf_symlink(struct coresight_device *csdev, bool link);
> >> +static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
> >> +{
> >> + struct etm_event_data *data = perf_get_aux(handle);
> >>
> >> + if (data)
> >> + return data->snk_config;
> >> + return NULL;
> >> +}
> >> #else
> >> static inline int etm_perf_symlink(struct coresight_device *csdev, bool link)
> >> { return -EINVAL; }
> >>
> >> +static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
> >> +{
> >> + return NULL;
> >> +}
> >> +
> >
> > I think we can do without those... See my comment in the next patch.
>
> Sure
^ permalink raw reply
* [PATCH v2 08/10] coresight: perf: Add helper to retrieve sink configuration
From: Mathieu Poirier @ 2018-07-23 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ed621d62-a1d2-abe1-3763-60ea6e5f615f@arm.com>
On Fri, 20 Jul 2018 at 02:43, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
>
> On 19/07/18 21:07, Mathieu Poirier wrote:
> > On Tue, Jul 17, 2018 at 06:11:39PM +0100, Suzuki K Poulose wrote:
> >> We can always find the sink configuration for a given perf_output_handle.
> >> Add a helper to retrieve the sink configuration for a given
> >> perf_output_handle. This will be used to get rid of the set_buffer()
> >> call back.
> >>
> >> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> >> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >> ---
> >> drivers/hwtracing/coresight/coresight-etm-perf.c | 14 -------------
> >> drivers/hwtracing/coresight/coresight-etm-perf.h | 26 ++++++++++++++++++++++++
> >> 2 files changed, 26 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> >> index 6a4252b..3cc4a0b 100644
> >> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> >> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> >> @@ -23,20 +23,6 @@
> >> static struct pmu etm_pmu;
> >> static bool etm_perf_up;
> >>
> >> -/**
> >> - * struct etm_event_data - Coresight specifics associated to an event
> >> - * @work: Handle to free allocated memory outside IRQ context.
> >> - * @mask: Hold the CPU(s) this event was set for.
> >> - * @snk_config: The sink configuration.
> >> - * @path: An array of path, each slot for one CPU.
> >> - */
> >> -struct etm_event_data {
> >> - struct work_struct work;
> >> - cpumask_t mask;
> >> - void *snk_config;
> >> - struct list_head * __percpu *path;
> >> -};
> >> -
> >
> > If this is moved to coresight-etm-perf.h, the #include <linux/percpu-defs.h> can
> > be removed.
>
> Actually, we do have the PER_CPU variables in the file already, which is why I left
> them there. See the next line.
Of course...
> >
> >> static DEFINE_PER_CPU(struct perf_output_handle, ctx_handle);
> >> static DEFINE_PER_CPU(struct coresight_device *, csdev_src);
> >>
>
>
> >> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
> >> index 4197df4..da7d933 100644
> >> --- a/drivers/hwtracing/coresight/coresight-etm-perf.h
> >> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
> >> @@ -7,6 +7,7 @@
> >> #ifndef _CORESIGHT_ETM_PERF_H
> >> #define _CORESIGHT_ETM_PERF_H
> >>
> >> +#include <linux/percpu-defs.h>
> >> #include "coresight-priv.h"
> >>
> >> struct coresight_device;
> >> @@ -42,14 +43,39 @@ struct etm_filters {
> >> bool ssstatus;
> >> };
> >>
> >> +/**
> >> + * struct etm_event_data - Coresight specifics associated to an event
> >> + * @work: Handle to free allocated memory outside IRQ context.
> >> + * @mask: Hold the CPU(s) this event was set for.
> >> + * @snk_config: The sink configuration.
> >> + * @path: An array of path, each slot for one CPU.
> >> + */
> >> +struct etm_event_data {
> >> + struct work_struct work;
> >> + cpumask_t mask;
> >> + void *snk_config;
> >> + struct list_head * __percpu *path;
> >> +};
> >>
> >> #ifdef CONFIG_CORESIGHT
> >> int etm_perf_symlink(struct coresight_device *csdev, bool link);
> >> +static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
> >> +{
> >> + struct etm_event_data *data = perf_get_aux(handle);
> >>
> >> + if (data)
> >> + return data->snk_config;
> >> + return NULL;
> >> +}
> >> #else
> >> static inline int etm_perf_symlink(struct coresight_device *csdev, bool link)
> >> { return -EINVAL; }
> >>
> >> +static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
> >> +{
> >> + return NULL;
> >> +}
> >> +
> >
> > I think we can do without those... See my comment in the next patch.
>
> Sure
^ permalink raw reply
* Re: [PATCH v5 1/3] crypto/openssl: add rsa and mod asym op
From: Stephen Hemminger @ 2018-07-23 16:50 UTC (permalink / raw)
To: Shally Verma
Cc: pablo.de.lara.guarch, dev, pathreya, nmurthy, Sunila Sahu,
Ashish Gupta
In-Reply-To: <1532357165-8575-2-git-send-email-shally.verma@caviumnetworks.com>
On Mon, 23 Jul 2018 20:16:03 +0530
Shally Verma <shally.verma@caviumnetworks.com> wrote:
> +#define set_rsa_params(rsa, p, q, ret) \
> + do {rsa->p = p; rsa->q = q; ret = 0; } while (0)
> +
> +#define set_rsa_crt_params(rsa, dmp1, dmq1, iqmp, ret) \
> + do { \
> + rsa->dmp1 = dmp1; \
> + rsa->dmq1 = dmq1; \
> + rsa->iqmp = iqmp; \
> + ret = 0; \
> + } while (0)
> +
> +#define set_rsa_keys(rsa, n, e, d, ret) \
> + do { \
> + rsa->n = n; rsa->e = e; rsa->d = d; ret = 0; \
> + } while (0)
> +
> +#else
> +
> +#define set_rsa_params(rsa, p, q, ret) \
> + (ret = !RSA_set0_factors(rsa, p, q))
> +
> +#define set_rsa_crt_params(rsa, dmp1, dmq1, iqmp, ret) \
> + (ret = !RSA_set0_crt_params(rsa, dmp1, dmq1, iqmp))
> +
> +/* n, e must be non-null, d can be NULL */
> +#define set_rsa_keys(rsa, n, e, d, ret) \
> + (ret = !RSA_set0_key(rsa, n, e, d))
> +
> +#endif /* version < 10100000 */
> +
> +#endif /* __RTA_COMPAT_H__ */
Please use inline functions instead of macros.
The crypto code seems to favor macros?
Macro's have no type checking and are not faster anyway.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.