All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: [PATCH] drm/amdgpu: Add a chunk ID for spm trace
From: He, Jacob @ 2020-02-20 10:19 UTC (permalink / raw)
  To: Zhou, David(ChunMing), Koenig, Christian,
	amd-gfx@lists.freedesktop.org
In-Reply-To: <MWHPR12MB1406B3418562F0692572C511B4130@MWHPR12MB1406.namprd12.prod.outlook.com>


[-- Attachment #1.1: Type: text/plain, Size: 10621 bytes --]

Looks like amdgpu_vm_reserve_vmid could work, let me have a try to update the RLC_SPM_VMID with pm4 packets in UMD.

Thanks
Jacob

From: Zhou, David(ChunMing)<mailto:David1.Zhou@amd.com>
Sent: Thursday, February 20, 2020 10:13 AM
To: Koenig, Christian<mailto:Christian.Koenig@amd.com>; He, Jacob<mailto:Jacob.He@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: RE: [PATCH] drm/amdgpu: Add a chunk ID for spm trace

[AMD Official Use Only - Internal Distribution Only]

Christian is right here, that will cause many problems for simply using VMID in kernel.
We already have an pair interface for RGP, I think you can use it instead of involving additional kernel change.
amdgpu_vm_reserve_vmid/ amdgpu_vm_unreserve_vmid.

-David

-----Original Message-----
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Christian König
Sent: Wednesday, February 19, 2020 7:03 PM
To: He, Jacob <Jacob.He@amd.com>; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Add a chunk ID for spm trace

Am 19.02.20 um 11:15 schrieb Jacob He:
> [WHY]
> When SPM trace enabled, SPM_VMID should be updated with the current
> vmid.
>
> [HOW]
> Add a chunk id, AMDGPU_CHUNK_ID_SPM_TRACE, so that UMD can tell us
> which job should update SPM_VMID.
> Right before a job is submitted to GPU, set the SPM_VMID accordingly.
>
> [Limitation]
> Running more than one SPM trace enabled processes simultaneously is
> not supported.

Well there are multiple problems with that patch.

First of all you need to better describe what SPM tracing is in the commit message.

Then the updating of mmRLC_SPM_MC_CNTL must be executed asynchronously on the ring. Otherwise we might corrupt an already executing SPM trace.

And you also need to make sure to disable the tracing again or otherwise we run into a bunch of trouble when the VMID is reused.

You also need to make sure that IBs using the SPM trace are serialized with each other, e.g. hack into amdgpu_ids.c file and make sure that only one VMID at a time can have that attribute.

Regards,
Christian.

>
> Change-Id: Ic932ef6ac9dbf244f03aaee90550e8ff3a675666
> Signed-off-by: Jacob He <jacob.he@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  7 +++++++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c  | 10 +++++++---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_job.h |  1 +
>   drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h |  1 +
>   drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c  | 15 ++++++++++++++-
>   drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   |  3 ++-
>   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  3 ++-
>   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   | 15 ++++++++++++++-
>   8 files changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index f9fa6e104fef..3f32c4db5232 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -113,6 +113,7 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs
>        uint32_t uf_offset = 0;
>        int i;
>        int ret;
> +     bool update_spm_vmid = false;
>
>        if (cs->in.num_chunks == 0)
>                return 0;
> @@ -221,6 +222,10 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs
>                case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL:
>                        break;
>
> +             case AMDGPU_CHUNK_ID_SPM_TRACE:
> +                     update_spm_vmid = true;
> +                     break;
> +
>                default:
>                        ret = -EINVAL;
>                        goto free_partial_kdata;
> @@ -231,6 +236,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs
>        if (ret)
>                goto free_all_kdata;
>
> +     p->job->need_update_spm_vmid = update_spm_vmid;
> +
>        if (p->ctx->vram_lost_counter != p->job->vram_lost_counter) {
>                ret = -ECANCELED;
>                goto free_all_kdata;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> index cae81914c821..36faab12b585 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> @@ -156,9 +156,13 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs,
>                return -EINVAL;
>        }
>
> -     if (vm && !job->vmid) {
> -             dev_err(adev->dev, "VM IB without ID\n");
> -             return -EINVAL;
> +     if (vm) {
> +             if (!job->vmid) {
> +                     dev_err(adev->dev, "VM IB without ID\n");
> +                     return -EINVAL;
> +             } else if (adev->gfx.rlc.funcs->update_spm_vmid && job->need_update_spm_vmid) {
> +                     adev->gfx.rlc.funcs->update_spm_vmid(adev, job->vmid);
> +             }
>        }
>
>        alloc_size = ring->funcs->emit_frame_size + num_ibs * diff --git
> a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> index 2e2110dddb76..4582536961c7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> @@ -52,6 +52,7 @@ struct amdgpu_job {
>        bool                    vm_needs_flush;
>        uint64_t                vm_pd_addr;
>        unsigned                vmid;
> +     bool                    need_update_spm_vmid;
>        unsigned                pasid;
>        uint32_t                gds_base, gds_size;
>        uint32_t                gws_base, gws_size;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> index d3d4707f2168..52509c254cbd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> @@ -126,6 +126,7 @@ struct amdgpu_rlc_funcs {
>        void (*stop)(struct amdgpu_device *adev);
>        void (*reset)(struct amdgpu_device *adev);
>        void (*start)(struct amdgpu_device *adev);
> +     void (*update_spm_vmid)(struct amdgpu_device *adev, unsigned vmid);
>   };
>
>   struct amdgpu_rlc {
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> index 5e9fb0976c6c..91eb788d6229 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> @@ -4214,6 +4214,18 @@ static int gfx_v10_0_update_gfx_clock_gating(struct amdgpu_device *adev,
>        return 0;
>   }
>
> +static void gfx_v10_0_update_spm_vmid(struct amdgpu_device *adev,
> +unsigned vmid) {
> +     u32 data;
> +
> +     data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
> +
> +     data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
> +     data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) <<
> +RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
> +
> +     WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data); }
> +
>   static const struct amdgpu_rlc_funcs gfx_v10_0_rlc_funcs = {
>        .is_rlc_enabled = gfx_v10_0_is_rlc_enabled,
>        .set_safe_mode = gfx_v10_0_set_safe_mode, @@ -4224,7 +4236,8 @@
> static const struct amdgpu_rlc_funcs gfx_v10_0_rlc_funcs = {
>        .resume = gfx_v10_0_rlc_resume,
>        .stop = gfx_v10_0_rlc_stop,
>        .reset = gfx_v10_0_rlc_reset,
> -     .start = gfx_v10_0_rlc_start
> +     .start = gfx_v10_0_rlc_start,
> +     .update_spm_vmid = gfx_v10_0_update_spm_vmid
>   };
>
>   static int gfx_v10_0_set_powergating_state(void *handle, diff --git
> a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> index 8f20a5dd44fe..b24fc55cf13a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> @@ -4221,7 +4221,8 @@ static const struct amdgpu_rlc_funcs gfx_v7_0_rlc_funcs = {
>        .resume = gfx_v7_0_rlc_resume,
>        .stop = gfx_v7_0_rlc_stop,
>        .reset = gfx_v7_0_rlc_reset,
> -     .start = gfx_v7_0_rlc_start
> +     .start = gfx_v7_0_rlc_start,
> +     .update_spm_vmid = NULL
>   };
>
>   static int gfx_v7_0_early_init(void *handle) diff --git
> a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index fa245973de12..66640d2b6b37 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -5600,7 +5600,8 @@ static const struct amdgpu_rlc_funcs iceland_rlc_funcs = {
>        .resume = gfx_v8_0_rlc_resume,
>        .stop = gfx_v8_0_rlc_stop,
>        .reset = gfx_v8_0_rlc_reset,
> -     .start = gfx_v8_0_rlc_start
> +     .start = gfx_v8_0_rlc_start,
> +     .update_spm_vmid = NULL
>   };
>
>   static void gfx_v8_0_update_medium_grain_clock_gating(struct
> amdgpu_device *adev, diff --git
> a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 9b7ff783e9a5..df872f949f68 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -4704,6 +4704,18 @@ static int gfx_v9_0_update_gfx_clock_gating(struct amdgpu_device *adev,
>        return 0;
>   }
>
> +static void gfx_v9_0_update_spm_vmid(struct amdgpu_device *adev,
> +unsigned vmid) {
> +     u32 data;
> +
> +     data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
> +
> +     data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
> +     data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) <<
> +RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
> +
> +     WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data); }
> +
>   static const struct amdgpu_rlc_funcs gfx_v9_0_rlc_funcs = {
>        .is_rlc_enabled = gfx_v9_0_is_rlc_enabled,
>        .set_safe_mode = gfx_v9_0_set_safe_mode, @@ -4715,7 +4727,8 @@
> static const struct amdgpu_rlc_funcs gfx_v9_0_rlc_funcs = {
>        .resume = gfx_v9_0_rlc_resume,
>        .stop = gfx_v9_0_rlc_stop,
>        .reset = gfx_v9_0_rlc_reset,
> -     .start = gfx_v9_0_rlc_start
> +     .start = gfx_v9_0_rlc_start,
> +     .update_spm_vmid = gfx_v9_0_update_spm_vmid
>   };
>
>   static int gfx_v9_0_set_powergating_state(void *handle,

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&amp;data=02%7C01%7Cdavid1.zhou%40amd.com%7C354be34ff18e4f424f6708d7b52b43b0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637177069753914395&amp;sdata=9rSL4kgPJweuZ4EJpdqtqTxyCVGEkmsg6aUzbtvGFrs%3D&amp;reserved=0


[-- Attachment #1.2: Type: text/html, Size: 19894 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply

* Re: [PATCH] mm: Stop kswapd early when nothing's waiting for it to free pages
From: Mel Gorman @ 2020-02-20 10:19 UTC (permalink / raw)
  To: Sultan Alsawaf
  Cc: Michal Hocko, Dave Hansen, Andrew Morton, linux-mm, linux-kernel,
	Johannes Weiner
In-Reply-To: <20200219224231.GA5190@sultan-book.localdomain>

On Wed, Feb 19, 2020 at 02:42:31PM -0800, Sultan Alsawaf wrote:
> On Wed, Feb 19, 2020 at 09:45:13PM +0000, Mel Gorman wrote:
> > This could be watermark boosting run wild again. Can you test with
> > sysctl vm.watermark_boost_factor=0 or the following patch? (preferably
> > both to compare and contrast).
> 
> I can test that, but something to note is that I've been doing equal testing
> with this on 4.4, which exhibits the same behavior, and that kernel doesn't have
> watermark boosting in it, as far as I can tell.
> 
> I don't think what we're addressing here is a "bug", but rather something
> fundamental about how we've been thinking about kswapd lifetime. The argument
> here is that it's not coherent to be letting kswapd run as it does, and instead
> gating it on outstanding allocation requests provides much more reasonable
> behavior, given real workloads and use patterns.
> 
> Does that make sense and seem reasonable?
> 

I'm not entirely convinced. The reason the high watermark exists is to have
kswapd work long enough to make progress without a process having to direct
reclaim. The most straight-forward example would be a streaming reader of
a large file. It'll keep pushing the zone towards the low watermark and
kswapd has to keep ahead of the reader. If we cut kswapd off too quickly,
the min watermark is hit and stalls occur. While kswapd could stop at the
min watermark, it leaves a very short window for kswapd to make enough
progress before the min watermark is hit.

At minimum, any change in this area would need to include the /proc/vmstats
on allocstat and pg*direct* to ensure that direct reclaim stalls are
not worse.

I'm not a fan of the patch in question because kswapd can be woken between
the low and min watermark without stalling but we really do expect kswapd
to make progress and continue to make progress to avoid future stalls. The
changelog had no information on the before/after impact of the patch and
this is an area where intuition can disagree with real behaviour.

-- 
Mel Gorman
SUSE Labs


^ permalink raw reply

* Re: [dpdk-dev] [PATCH v2] examples/fips_validation: fix incorrect string for CT length
From: David Marchand @ 2020-02-20 10:19 UTC (permalink / raw)
  To: Akhil Goyal
  Cc: Anoob Joseph, Marko Kovacevic, Fan Zhang, Narayana Prasad,
	dev@dpdk.org
In-Reply-To: <VE1PR04MB6639BCF806B4FB4559B5C894E6130@VE1PR04MB6639.eurprd04.prod.outlook.com>

On Thu, Feb 20, 2020 at 11:15 AM Akhil Goyal <akhil.goyal@nxp.com> wrote:
> > The NIST test vectors use the string 'PTlen' to denote text lengths
> > in case of encrypt & decrypt operations. So the same string need to be
> > used while parsing PT and CT.
> >
> > Fixes: 2adb3b4e7e54 ("examples/fips_validation: fix AES-GCM cipher length
> > parsing")
> >
> > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > ---
> >
> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
>
> Are you picking this patch or is it intended for crypto tree?

I'll take it.


-- 
David Marchand


^ permalink raw reply

* Re: [PATCH 1/1] RDMA/rw: map P2P memory correctly for signature operations
From: Max Gurtovoy @ 2020-02-20 10:18 UTC (permalink / raw)
  To: Jason Gunthorpe; +Cc: leon@kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <20200219164735.GK23930@mellanox.com>


On 2/19/2020 6:47 PM, Jason Gunthorpe wrote:
> On Wed, Feb 19, 2020 at 05:41:42PM +0200, Max Gurtovoy wrote:
>> Since RDMA rw API support operations with P2P memory sg list, make sure
>> to map/unmap the scatter list for signature operation correctly. while
>> we're here, fix an error flow that doesn't unmap the sg list according
>> to the memory type.
>>
>> Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
>> Signed-off-by: Israel Rukshin <israelr@mellanox.com>
>>   drivers/infiniband/core/rw.c | 44 +++++++++++++++++++++++++++-----------------
>>   1 file changed, 27 insertions(+), 17 deletions(-)
> Can you split the bug fix out please?

sure,

just sent a v2.


>
> Jason

^ permalink raw reply

* Re: [virtio-comment] [PATCH] virtio-net: Add support for correct hdr_len field.
From: Vitaly Mireyno @ 2020-02-20 10:18 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: virtio-comment@lists.oasis-open.org, jasowang@redhat.com


>-----Original Message-----
>From: Michael S. Tsirkin <mst@redhat.com>
>Sent: Thursday, 20 February, 2020 12:01
>To: Vitaly Mireyno <vmireyno@marvell.com>
>Cc: virtio-comment@lists.oasis-open.org; jasowang@redhat.com
>Subject: [EXT] Re: [virtio-comment] [PATCH] virtio-net: Add support for correct hdr_len field.
>
>----------------------------------------------------------------------
>On Thu, Feb 20, 2020 at 09:51:17AM +0000, Vitaly Mireyno wrote:
>>
>> >-----Original Message-----
>> >From: virtio-comment@lists.oasis-open.org
>> ><virtio-comment@lists.oasis-open.org> On Behalf Of Michael S. Tsirkin
>> >Sent: Thursday, 20 February, 2020 10:12
>> >To: Vitaly Mireyno <vmireyno@marvell.com>
>> >Cc: virtio-comment@lists.oasis-open.org; jasowang@redhat.com
>> >Subject: Re: [virtio-comment] [PATCH] virtio-net: Add support for correct hdr_len field.
>> >
>> >---------------------------------------------------------------------
>> >- On Thu, Oct 24, 2019 at 03:24:43PM +0000, Vitaly Mireyno wrote:
>> >> Some devices benefit from the knowledge of the exact header length for TSO processing.
>> >> Add a feature bit for a driver that is capable of providing the correct header length for TSO
>packets.
>> >>
>> >> Signed-off-by: Vitaly Mireyno <vmireyno@marvell.com>
>> >
>> >So I looked at implementing this and maybe this was not such a good idea after all.
>> >
>> >How would we implement this in Linux?
>> >Current code just puts skb_headlen there which is # of bytes in the linear buffer.
>> >Which I guess it often the header, but not at all always.
>> >
>> >Should this have been limited to TSO packets?
>> >
>> >I also could not figure out how this is useful for the host.
>> >Could you enlighten me pls?
>>
>> As see it, header length is essential for TSO, and maybe not so useful for non-TSO.
>
>So maybe we should limit this for when gso type is actually set?

Do you mean the hdr_len field will be valid only for TSO packets, or it will be accurate only for TSO packets?
I'm fine with both options.

>
>> To calculate the header length, I suppose a Linux driver could do something like:
>> skb_transport_header(skb) + tcp_hdrlen(skb) - skb->data
>
>That's parsing the header in software. Why not have the card do it in hardware?
>

It depends on hw architecture. The architecture I'm familiar with, the hw can parse the header, but it happens too late for the segmentation decision.


>--
>MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply

* Re: [CFT 6/8] net: macb: use resolved link config in mac_link_up()
From: Russell King - ARM Linux admin @ 2020-02-20 10:18 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S. Miller,
	netdev, Nicolas Ferre
In-Reply-To: <20200219143036.GB3390@piout.net>

On Wed, Feb 19, 2020 at 03:30:36PM +0100, Alexandre Belloni wrote:
> Hi,
> 
> On 17/02/2020 17:24:21+0000, Russell King wrote:
> > Convert the macb ethernet driver to use the finalised link
> > parameters in mac_link_up() rather than the parameters in mac_config().
> > 
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> >  drivers/net/ethernet/cadence/macb.h      |  1 -
> >  drivers/net/ethernet/cadence/macb_main.c | 46 ++++++++++++++----------
> >  2 files changed, 27 insertions(+), 20 deletions(-)
> > 
> 
> I did test the series after rebasing on top of the at91rm9200 fix.
> 
> Here is what I tested:
> 
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index a3f0f27fc79a..ab827fb4b6b9 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -1200,7 +1200,6 @@ struct macb {
>  	unsigned int		dma_burst_length;
>  
>  	phy_interface_t		phy_interface;
> -	int			speed;
>  
>  	/* AT91RM9200 transmit */
>  	struct sk_buff *skb;			/* holds skb until xmit interrupt completes */
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 7ab0bef5e1bd..3a7c26b08607 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -571,37 +571,20 @@ static void macb_mac_config(struct phylink_config *config, unsigned int mode,
>  
>  	old_ctrl = ctrl = macb_or_gem_readl(bp, NCFGR);
>  
> -	/* Clear all the bits we might set later */
> -	ctrl &= ~(MACB_BIT(SPD) | MACB_BIT(FD) | MACB_BIT(PAE));
> -
>  	if (bp->caps & MACB_CAPS_MACB_IS_EMAC) {
>  		if (state->interface == PHY_INTERFACE_MODE_RMII)
>  			ctrl |= MACB_BIT(RM9200_RMII);
>  	} else {
> -		ctrl &= ~(GEM_BIT(GBE) | GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
> -
> -		/* We do not support MLO_PAUSE_RX yet */
> -		if (state->pause & MLO_PAUSE_TX)
> -			ctrl |= MACB_BIT(PAE);
> +		ctrl &= ~(GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
>  
>  		if (state->interface == PHY_INTERFACE_MODE_SGMII)
>  			ctrl |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL);
>  	}
>  
> -	if (state->speed == SPEED_1000)
> -		ctrl |= GEM_BIT(GBE);
> -	else if (state->speed == SPEED_100)
> -		ctrl |= MACB_BIT(SPD);
> -
> -	if (state->duplex)
> -		ctrl |= MACB_BIT(FD);
> -
>  	/* Apply the new configuration, if any */
>  	if (old_ctrl ^ ctrl)
>  		macb_or_gem_writel(bp, NCFGR, ctrl);
>  
> -	bp->speed = state->speed;
> -
>  	spin_unlock_irqrestore(&bp->lock, flags);
>  }
>  
> @@ -635,10 +618,33 @@ static void macb_mac_link_up(struct phylink_config *config,
>  	struct net_device *ndev = to_net_dev(config->dev);
>  	struct macb *bp = netdev_priv(ndev);
>  	struct macb_queue *queue;
> +	unsigned long flags;
>  	unsigned int q;
> +	u32 ctrl;
> +
> +	spin_lock_irqsave(&bp->lock, flags);
> +
> +	ctrl = macb_or_gem_readl(bp, NCFGR);
> +
> +	ctrl &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
> +
> +	if (speed == SPEED_100)
> +		ctrl |= MACB_BIT(SPD);
> +
> +	if (duplex)
> +		ctrl |= MACB_BIT(FD);
>  
>  	if (!(bp->caps & MACB_CAPS_MACB_IS_EMAC)) {
> -		macb_set_tx_clk(bp->tx_clk, bp->speed, ndev);
> +		ctrl &= ~(GEM_BIT(GBE) | MACB_BIT(PAE));
> +
> +		if (speed == SPEED_1000)
> +			ctrl |= GEM_BIT(GBE);
> +
> +		/* We do not support MLO_PAUSE_RX yet */
> +		if (tx_pause)
> +			ctrl |= MACB_BIT(PAE);
> +
> +		macb_set_tx_clk(bp->tx_clk, speed, ndev);
>  
>  		/* Initialize rings & buffers as clearing MACB_BIT(TE) in link down
>  		 * cleared the pipeline and control registers.
> @@ -651,6 +657,10 @@ static void macb_mac_link_up(struct phylink_config *config,
>  				     bp->rx_intr_mask | MACB_TX_INT_FLAGS | MACB_BIT(HRESP));
>  	}
>  
> +	macb_or_gem_writel(bp, NCFGR, ctrl);
> +
> +	spin_unlock_irqrestore(&bp->lock, flags);
> +
>  	/* Enable Rx and Tx */
>  	macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(RE) | MACB_BIT(TE));
>  
> @@ -4432,8 +4442,6 @@ static int macb_probe(struct platform_device *pdev)
>  	else
>  		bp->phy_interface = interface;
>  
> -	bp->speed = SPEED_UNKNOWN;
> -
>  	/* IP specific init */
>  	err = init(pdev);
>  	if (err)
> 
> 

Thanks, that looks reasonable to me. I'll replace my patch with this
one if it's appropriate for net-next when I send this series for
merging.  However, I see most affected network driver maintainers
haven't responded yet, which is rather disappointing.  So, thanks
for taking the time to look at this.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply

* [LTP] [PATCH] syscalls/fgetxattr02: Use loop instead of RAM disk
From: Cyril Hrubis @ 2020-02-20 10:18 UTC (permalink / raw)
  To: ltp
In-Reply-To: <c2168ced-4634-a7d4-7112-ac8e2ceba830@cn.fujitsu.com>

Hi!
> > which makes this test fail with ENXIO when we attempt to open the block
> > device in the test setup.
> > 
> > LTP depends on heavily on loop device driver already so it makes sense
> > to switch over to a loop device backed block device instead.
> > 
> > Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> > ---
> >   testcases/kernel/syscalls/fgetxattr/fgetxattr02.c | 7 ++++---
> >   1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c b/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c
> > index 02e81810a..82fb676be 100644
> > --- a/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c
> > +++ b/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c
> > @@ -210,7 +210,8 @@ static void setup(void)
> >   	size_t i = 0;
> >   	struct sockaddr_un sun;
> >   
> > -	dev_t dev = makedev(1, 3);
> > +	dev_t chr_dev = makedev(1, 3);
> > +	dev_t blk_dev = makedev(7, 3);
>   Can we use tst_find_free_loopdev to avoid a fixed loop dev like 
> copy_file_range02.c?

I do not think that it matters here, we are not actually touching the
block device here, we just need to be able to open the block device so
that we can add an attribute to the file we have created. I does not
matter if it's used or not.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply

* Re: [dpdk-dev] [PATCH v2] examples/fips_validation: fix incorrect string for CT length
From: Akhil Goyal @ 2020-02-20 10:15 UTC (permalink / raw)
  To: Anoob Joseph, Marko Kovacevic, David Marchand
  Cc: Fan Zhang, Narayana Prasad, dev@dpdk.org
In-Reply-To: <1582021872-8173-1-git-send-email-anoobj@marvell.com>


> 
> The NIST test vectors use the string 'PTlen' to denote text lengths
> in case of encrypt & decrypt operations. So the same string need to be
> used while parsing PT and CT.
> 
> Fixes: 2adb3b4e7e54 ("examples/fips_validation: fix AES-GCM cipher length
> parsing")
> 
> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> ---
> 
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>

Hi David,
Are you picking this patch or is it intended for crypto tree?

Regards,
Akhil

^ permalink raw reply

* Re: [PATCH v4 0/6] driver core: Try to improve and cleanup driver_deferred_probe_check_state()
From: Rafael J. Wysocki @ 2020-02-20 10:15 UTC (permalink / raw)
  To: John Stultz
  Cc: lkml, Rob Herring, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson,
	Pavel Machek, Len Brown, Todd Kjos, Bjorn Andersson,
	Liam Girdwood, Mark Brown, Thierry Reding, Linus Walleij,
	Greg Kroah-Hartman, Linux PM
In-Reply-To: <20200220050440.45878-1-john.stultz@linaro.org>

On Thu, Feb 20, 2020 at 6:04 AM John Stultz <john.stultz@linaro.org> wrote:
>
> This series tries to improve and cleanup the
> driver_deferred_probe_check_state() code in the driver core.

"Do. Or do not. There is no try."
 - Master Yoda

^ permalink raw reply

* [PATCH 5/8] powerpc/uapi: Introduce uapi header 'papr_scm_dsm.h' for papr_scm DSMs
From: Vaibhav Jain @ 2020-02-20  9:58 UTC (permalink / raw)
  To: linuxppc-dev
  Cc: Vaibhav Jain, Michael Ellerman, Oliver O'Halloran,
	Alastair D'Silva, Aneesh Kumar K . V
In-Reply-To: <20200220095805.197229-1-vaibhav@linux.ibm.com>

Define and add a new uapi header for papr_scm describing device
specific methods (DSMs) and structs for libndctl. PAPR-SCM specific
implementation in libndctl will use these commands/structs to interact
with papr_scm kernel module. Currently only DSMs to retrieve health and
performance statistics information of a dimm are defined.

DSM Envelope
=============

The ioctl ND_CMD_CALL transfers data between user-space and kernel via
'envelopes'. An envelope consists of a header and user-defined payload
section. The primary structure describing this envelope is 'struct
nd_papr_scm_cmd_pkg' which expects a payload at the end of the envelop
pointed to by 'nd_papr_scm_cmd_pkg.payload_offset'. Currently two
payloads are defined 'struct nd_papr_scm_dimm_health_stat' and 'struct
nd_papr_scm_perf_stats'. These can be used to retrieve dimm-health and
performance stats respectively.

The header is defined as 'struct nd_cmd_pkg' which in return is
wrapped in a user defined struct called 'struct
nd_papr_scm_cmd_pkg'. This relationship is illustrated below:

     64-Bytes         8-Bytes
 +-------------+-------------------+------------------------------+
 | nd_family   |	       	   |				  |
 |             |                   |				  |
 | nd_size_out | cmd_status        |				  |
 |             |                   |         			  |
 | nd_size_in  | payload_version   |           PAYLOAD      	  |
 |             |                   |           			  |
 | nd_command  | payload_offset    |				  |
 |             |      |            |				  |
 | nd_fw_size  |      +----------> |				  |
 +-------------+-------------------+------------------------------+
 \ nd_cmd_pkg /                   /                              /
  \----------/                   /                              /
   \ 	nd_papr_scm_cmd_pkg     /			       /
    \--------------------------/      	       	       	      /
     \  	 		  Envelope	  	     /
      \-----------------------------------------------------/

Important fields to note in above illustration are:

* 'nd_command'	: DSM command sent by libndctl
* 'nd_family' 	: Id for newly introduced DSM family NVDIMM_FAMILY_PAPR_SCM
* 'nd_fw_size'	: Number of bytes that kernel wanted to copy to the
  payload but may not have copied due to limited size of the envelope.
* 'nd_size_in/out' : Number of bytes that kernel needs to copy from
  user-space (in) and copy-back to user-space (out).
* 'cmd_status' 	: Out variable indicating any error encountered while
  servicing the DSM.
* 'payload_version': Version number associated with the payload.
* 'payload_offset': Offset of the payload from start of the envelope.

libnvdimm enforces a hard limit of 256 bytes on the envelope size,
which leaves around 184 bytes for the envelope payload (ignoring any
padding that the compiler may silently introduce).

Envelope Payload Layout
=======================

The layout of the DSM Payload is defined by various structs defined in
'papr_scm_dsm.h'. Definition of these structs are shared between
papr_scm and libndctl so that contents of payload can be
interpreted. This patch-set introduces two such structs namely
'nd_papr_scm_dimm_health_stat' and 'nd_papr_scm_perf_stats' that can
be used to exchange dimm health and performance stats between papr_scm
and libndctl.

During servicing of a DSM the papr_scm module will read input args
from the payload field by casting its contents to an appropriate
struct pointer based on the DSM command. Similarly the output of
servicing the DSM command will be copied to the payload field using
the same struct.

Payload Version
===============

Since the structs associated with each DSM can evolve over time adding
more data and the definitions of these structs known to papr_scm and
libndctl may differ, hence the version number is associated with each
iteration of the struct. This version number is exchanged between
papr_scm <-> libndctl via the 'payload_version' of the DSM envelope.

When libndctl sends an envelope to papr_scm it populates the
'payload_version' field with the version number of the struct it had
copied and/or expects in the payload area. The papr_scm module when
servicing the DSM envelop checks the 'payload_version', if required
changes it to a different version number that it knows about and then
use the DSM struct associated with the new version number to process
the DSM (i.e read the args and copy the results to the payload
area). Libndctl on receiving the envelop back from papr_scm again
checks the 'payload_version' field and based on it use the appropriate
version dsm struct to parse the results.

Above scheme of exchanging different versioned DSM struct between
libndctl and papr_scm should work until following two assumptions
hold:

Let T(X) = { set of attributes of DSM struct 'T' versioned X }

1. T(X) is a proper subset of T(Y) if X > Y.
   i.e Each new version of DSM struct should retain existing struct
   attributes.

2. If an entity (libndctl or papr_scm) supports a DSM struct T(X) then
   it should also support T(1), T(2)...T(X - 1).
   i.e When adding support for new version of a DSM struct, libndctl
   and papr_scm should retain support of the existing DSM struct
   version they support.

Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
 arch/powerpc/include/uapi/asm/papr_scm_dsm.h | 143 +++++++++++++++++++
 1 file changed, 143 insertions(+)
 create mode 100644 arch/powerpc/include/uapi/asm/papr_scm_dsm.h

diff --git a/arch/powerpc/include/uapi/asm/papr_scm_dsm.h b/arch/powerpc/include/uapi/asm/papr_scm_dsm.h
new file mode 100644
index 000000000000..aacced453579
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/papr_scm_dsm.h
@@ -0,0 +1,143 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/*
+ * PAPR SCM Device specific methods for libndctl and ndctl
+ *
+ * (C) Copyright IBM 2020
+ *
+ * Author: Vaibhav Jain <vaibhav at linux.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _UAPI_ASM_POWERPC_PAPR_SCM_DSM_H_
+#define _UAPI_ASM_POWERPC_PAPR_SCM_DSM_H_
+
+#include <linux/types.h>
+
+#ifdef __KERNEL__
+#include <linux/ndctl.h>
+#else
+#include <ndctl.h>
+#endif
+
+/*
+ * Sub commands for ND_CMD_CALL. To prevent overlap from ND_CMD_*, values for
+ * these enums start at 0x10000. These values are then returned from
+ * cmd_to_func() making it easy to implement the switch-case block in
+ * papr_scm_ndctl()
+ */
+enum dsm_papr_scm {
+	DSM_PAPR_SCM_MIN =  0x10000,
+	DSM_PAPR_SCM_HEALTH,
+	DSM_PAPR_SCM_STATS,
+	DSM_PAPR_SCM_MAX,
+};
+
+enum dsm_papr_scm_dimm_health {
+	DSM_PAPR_SCM_DIMM_HEALTHY,
+	DSM_PAPR_SCM_DIMM_UNHEALTHY,
+	DSM_PAPR_SCM_DIMM_CRITICAL,
+	DSM_PAPR_SCM_DIMM_FATAL,
+};
+
+/* Papr-scm-header + payload expected with ND_CMD_CALL ioctl from libnvdimm */
+struct nd_papr_scm_cmd_pkg {
+	struct nd_cmd_pkg hdr;		/* Package header containing sub-cmd */
+	int32_t cmd_status;		/* Out: Sub-cmd status returned back */
+	uint16_t payload_offset;	/* In: offset from start of struct */
+	uint16_t payload_version;	/* In/Out: version of the payload */
+	uint8_t payload[];		/* In/Out: Sub-cmd data buffer */
+};
+
+/* Helpers to evaluate the size of PAPR_SCM envelope */
+/* Calculate the papr_scm-header size */
+#define ND_PAPR_SCM_ENVELOPE_CONTENT_HDR_SIZE \
+	(sizeof(struct nd_papr_scm_cmd_pkg) - sizeof(struct nd_cmd_pkg))
+/*
+ * Given a type calculate the envelope size
+ * (nd-header + papr_scm-header + payload)
+ */
+#define ND_PAPR_SCM_ENVELOPE_SIZE(_type_)	\
+	(sizeof(_type_) + sizeof(struct nd_papr_scm_cmd_pkg))
+
+/* Given a type envelope-content size (papr_scm-header + payload) */
+#define ND_PAPR_SCM_ENVELOPE_CONTENT_SIZE(_type_)	\
+	(sizeof(_type_) + ND_PAPR_SCM_ENVELOPE_CONTENT_HDR_SIZE)
+
+/*
+ * Struct exchanged between kernel & ndctl in for PAPR_DSM_PAPR_SMART_HEALTH
+ * Various bitflags indicate the health status of the dimm.
+ */
+struct nd_papr_scm_dimm_health_stat_v1 {
+	/* Dimm not armed. So contents wont persist */
+	bool dimm_unarmed;
+	/* Previous shutdown did not persist contents */
+	bool dimm_bad_shutdown;
+	/* Contents from previous shutdown werent restored */
+	bool dimm_bad_restore;
+	/* Contents of the dimm have been scrubbed */
+	bool dimm_scrubbed;
+	/* Contents of the dimm cant be modified until CEC reboot */
+	bool dimm_locked;
+	/* Contents of dimm are encrypted */
+	bool dimm_encrypted;
+
+	enum dsm_papr_scm_dimm_health dimm_health;
+};
+
+/*
+ * Typedef the current struct for dimm_health so that any application
+ * or kernel recompiled after introducing a new version autometically
+ * supports the new version.
+ */
+#define nd_papr_scm_dimm_health_stat nd_papr_scm_dimm_health_stat_v1
+
+/* Current version number for the dimm health struct */
+#define ND_PAPR_SCM_DIMM_HEALTH_VERSION 1
+
+/* Struct holding a single performance metric */
+struct nd_papr_scm_perf_stat {
+	u64 statistic_id;
+	u64 statistic_value;
+};
+
+/* Struct exchanged between kernel and ndctl reporting drc perf stats */
+struct nd_papr_scm_perf_stats_v1 {
+	/* Number of stats following */
+	u32 num_statistics;
+
+	/* zero or more performance matrics */
+	struct nd_papr_scm_perf_stat scm_statistics[];
+};
+
+/*
+ * Typedef the current struct for dimm_stats so that any application
+ * or kernel recompiled after introducing a new version autometically
+ * supports the new version.
+ */
+#define nd_papr_scm_perf_stats nd_papr_scm_perf_stats_v1
+#define ND_PAPR_SCM_DIMM_PERF_STATS_VERSION 1
+
+/* Convert a libnvdimm nd_cmd_pkg to papr_scm specific pkg */
+static struct nd_papr_scm_cmd_pkg *nd_to_papr_cmd_pkg(struct nd_cmd_pkg *cmd)
+{
+	return (struct nd_papr_scm_cmd_pkg *) cmd;
+}
+
+/* Return the payload pointer for a given pcmd */
+static void *papr_scm_pcmd_to_payload(struct nd_papr_scm_cmd_pkg *pcmd)
+{
+	if (pcmd->hdr.nd_size_in == 0 && pcmd->hdr.nd_size_out == 0)
+		return NULL;
+	else
+		return (void *)((u8 *) pcmd + pcmd->payload_offset);
+}
+#endif /* _UAPI_ASM_POWERPC_PAPR_SCM_DSM_H_ */
-- 
2.24.1


^ permalink raw reply related

* [LTP] [PATCH] syscalls/fgetxattr02: Use loop instead of RAM disk
From: Yang Xu @ 2020-02-20 10:14 UTC (permalink / raw)
  To: ltp
In-Reply-To: <20200220095908.14980-1-chrubis@suse.cz>


Hi Cyril> There are minimal systems that does not ship with RAM disk 
kernel module
> which makes this test fail with ENXIO when we attempt to open the block
> device in the test setup.
> 
> LTP depends on heavily on loop device driver already so it makes sense
> to switch over to a loop device backed block device instead.
> 
> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> ---
>   testcases/kernel/syscalls/fgetxattr/fgetxattr02.c | 7 ++++---
>   1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c b/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c
> index 02e81810a..82fb676be 100644
> --- a/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c
> +++ b/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c
> @@ -210,7 +210,8 @@ static void setup(void)
>   	size_t i = 0;
>   	struct sockaddr_un sun;
>   
> -	dev_t dev = makedev(1, 3);
> +	dev_t chr_dev = makedev(1, 3);
> +	dev_t blk_dev = makedev(7, 3);
  Can we use tst_find_free_loopdev to avoid a fixed loop dev like 
copy_file_range02.c?

Best Regards
Yang Xu
>   
>   	SAFE_TOUCH(FILENAME, 0644, NULL);
>   	SAFE_TOUCH(SYMLINKF, 0644, NULL);
> @@ -219,8 +220,8 @@ static void setup(void)
>   
>   	/* root: mknod(2) needs it to create something other than a file */
>   	SAFE_MKNOD(FIFO, S_IFIFO | 0777, 0);
> -	SAFE_MKNOD(CHR, S_IFCHR | 0777, dev);
> -	SAFE_MKNOD(BLK, S_IFBLK | 0777, dev);
> +	SAFE_MKNOD(CHR, S_IFCHR | 0777, chr_dev);
> +	SAFE_MKNOD(BLK, S_IFBLK | 0777, blk_dev);
>   
>   	for (i = 0; i < ARRAY_SIZE(tc); i++) {
>   
> 



^ permalink raw reply

* [PATCH v3] dm: uclass: don't assign aliased seq numbers
From: Michal Simek @ 2020-02-20 10:14 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <26dc4ba90f483b4c8807169b74ad1e33@walle.cc>

On 20. 02. 20 10:52, Michael Walle wrote:
> Hi Michal,
> 
> Am 2020-02-20 09:30, schrieb Michal Simek:
>> On 03. 02. 20 18:11, Michael Walle wrote:
>>> If there are aliases for an uclass, set the base for the "dynamically"
>>> allocated numbers next to the highest alias.
>>>
>>> Please note, that this might lead to holes in the sequences, depending
>>> on the device tree. For example if there is only an alias "ethernet1",
>>> the next device seq number would be 2.
>>>
>>> In particular this fixes a problem with boards which are using ethernet
>>> aliases but also might have network add-in cards like the E1000. If the
>>> board is started with the add-in card and depending on the order of the
>>> drivers, the E1000 might occupy the first ethernet device and mess up
>>> all the hardware addresses, because the devices are now shifted by one.
>>>
>>> Also adapt the test cases to the new handling and add test cases
>>> checking the holes in the seq numbers.
>>>
>>> Signed-off-by: Michael Walle <michael@walle.cc>
>>> Reviewed-by: Alex Marginean <alexandru.marginean@nxp.com>
>>> Tested-by: Alex Marginean <alexandru.marginean@nxp.com>
>>> Acked-by: Vladimir Oltean <olteanv@gmail.com>
>>> ---
>>>
>>> Please note that I've kept the R-b, T-b, and A-b tags although they were
>>> for an older version. They only affects the drivers/core/uclass.c not
>>> the
>>> test/dm/ part. OTOH none of the actual implementation has changed.
>>>
>>> I couldn't split the patch, otherwise the tests would fail.
>>>
>>> As a side effect, this should also make the following commits
>>> superfluous:
>>> ?- 7f3289bf6d ("dm: device: Request next sequence number")
>>> ?- 61607225d1 ("i2c: Fill req_seq in i2c_post_bind()")
>>> ?? Although I don't understand the root cause of the said problem.
>>>
>>> Thomas, Michal, could you please test this and then I'd add a second
>>> patch removing the old code.
>>>
>>> changes since v2:
>>> ?- adapt/new test cases, thanks Simon
>>>
>>> changes since v1:
>>> ?- move notice about superfluous commits from commit message to this
>>> ?? section.
>>> ?- fix the comment style
>>>
>>> ?arch/sandbox/dts/test.dts |? 4 ++--
>>> ?drivers/core/uclass.c???? | 21 +++++++++++++++------
>>> ?include/configs/sandbox.h |? 6 +++---
>>> ?test/dm/eth.c???????????? | 14 +++++++-------
>>> ?test/dm/test-fdt.c??????? | 22 +++++++++++++++++-----
>>> ?5 files changed, 44 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
>>> index e529c54d8d..d448892a65 100644
>>> --- a/arch/sandbox/dts/test.dts
>>> +++ b/arch/sandbox/dts/test.dts
>>> @@ -19,8 +19,8 @@
>>> ???????? pci0 = &pci0;
>>> ???????? pci1 = &pci1;
>>> ???????? pci2 = &pci2;
>>> -??????? remoteproc1 = &rproc_1;
>>> -??????? remoteproc2 = &rproc_2;
>>> +??????? remoteproc0 = &rproc_1;
>>> +??????? remoteproc1 = &rproc_2;
>>> ???????? rtc0 = &rtc_0;
>>> ???????? rtc1 = &rtc_1;
>>> ???????? spi0 = "/spi at 0";
>>> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
>>> index c520ef113a..3c216221e0 100644
>>> --- a/drivers/core/uclass.c
>>> +++ b/drivers/core/uclass.c
>>> @@ -675,13 +675,14 @@ int uclass_unbind_device(struct udevice *dev)
>>>
>>> ?int uclass_resolve_seq(struct udevice *dev)
>>> ?{
>>> +??? struct uclass *uc = dev->uclass;
>>> +??? struct uclass_driver *uc_drv = uc->uc_drv;
>>> ???? struct udevice *dup;
>>> -??? int seq;
>>> +??? int seq = 0;
>>> ???? int ret;
>>>
>>> ???? assert(dev->seq == -1);
>>> -??? ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id,
>>> dev->req_seq,
>>> -??????????????????? false, &dup);
>>> +??? ret = uclass_find_device_by_seq(uc_drv->id, dev->req_seq, false,
>>> &dup);
>>> ???? if (!ret) {
>>> ???????? dm_warn("Device '%s': seq %d is in use by '%s'\n",
>>> ???????????? dev->name, dev->req_seq, dup->name);
>>> @@ -693,9 +694,17 @@ int uclass_resolve_seq(struct udevice *dev)
>>> ???????? return ret;
>>> ???? }
>>>
>>> -??? for (seq = 0; seq < DM_MAX_SEQ; seq++) {
>>> -??????? ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, seq,
>>> -??????????????????????? false, &dup);
>>> +??? if (CONFIG_IS_ENABLED(DM_SEQ_ALIAS) &&
>>> +??????? (uc_drv->flags & DM_UC_FLAG_SEQ_ALIAS)) {
>>> +??????? /*
>>> +???????? * dev_read_alias_highest_id() will return -1 if there no
>>> +???????? * alias. Thus we can always add one.
>>> +???????? */
>>> +??????? seq = dev_read_alias_highest_id(uc_drv->name) + 1;
>>> +??? }
>>> +
>>> +??? for (; seq < DM_MAX_SEQ; seq++) {
>>> +??????? ret = uclass_find_device_by_seq(uc_drv->id, seq, false, &dup);
>>> ???????? if (ret == -ENODEV)
>>> ???????????? break;
>>> ???????? if (ret)
>>> diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
>>> index 1c13055cdc..b02c362fed 100644
>>> --- a/include/configs/sandbox.h
>>> +++ b/include/configs/sandbox.h
>>> @@ -97,9 +97,9 @@
>>> ?#endif
>>>
>>> ?#define SANDBOX_ETH_SETTINGS??????? "ethaddr=00:00:11:22:33:44\0" \
>>> -??????????????????? "eth1addr=00:00:11:22:33:45\0" \
>>> -??????????????????? "eth3addr=00:00:11:22:33:46\0" \
>>> -??????????????????? "eth5addr=00:00:11:22:33:47\0" \
>>> +??????????????????? "eth3addr=00:00:11:22:33:45\0" \
>>> +??????????????????? "eth5addr=00:00:11:22:33:46\0" \
>>> +??????????????????? "eth6addr=00:00:11:22:33:47\0" \
>>> ???????????????????? "ipaddr=1.2.3.4\0"
>>>
>>> ?#define MEM_LAYOUT_ENV_SETTINGS \
>>> diff --git a/test/dm/eth.c b/test/dm/eth.c
>>> index ad5354b4bf..75315a0c6d 100644
>>> --- a/test/dm/eth.c
>>> +++ b/test/dm/eth.c
>>> @@ -47,7 +47,7 @@ static int dm_test_eth_alias(struct unit_test_state
>>> *uts)
>>> ???? ut_assertok(net_loop(PING));
>>> ???? ut_asserteq_str("eth at 10002000", env_get("ethact"));
>>>
>>> -??? env_set("ethact", "eth1");
>>> +??? env_set("ethact", "eth6");
>>> ???? ut_assertok(net_loop(PING));
>>> ???? ut_asserteq_str("eth at 10004000", env_get("ethact"));
>>>
>>> @@ -104,7 +104,7 @@ static int dm_test_eth_act(struct unit_test_state
>>> *uts)
>>> ???? const char *ethname[DM_TEST_ETH_NUM] = {"eth at 10002000",
>>> "eth at 10003000",
>>> ???????????????????????? "sbe5", "eth at 10004000"};
>>> ???? const char *addrname[DM_TEST_ETH_NUM] = {"ethaddr", "eth5addr",
>>> -???????????????????????? "eth3addr", "eth1addr"};
>>> +???????????????????????? "eth3addr", "eth6addr"};
>>> ???? char ethaddr[DM_TEST_ETH_NUM][18];
>>> ???? int i;
>>>
>>> @@ -187,15 +187,15 @@ static int dm_test_eth_rotate(struct
>>> unit_test_state *uts)
>>>
>>> ???? /* Invalidate eth1's MAC address */
>>> ???? memset(ethaddr, '\0', sizeof(ethaddr));
>>> -??? strncpy(ethaddr, env_get("eth1addr"), 17);
>>> -??? /* Must disable access protection for eth1addr before clearing */
>>> -??? env_set(".flags", "eth1addr");
>>> -??? env_set("eth1addr", NULL);
>>> +??? strncpy(ethaddr, env_get("eth6addr"), 17);
>>> +??? /* Must disable access protection for eth6addr before clearing */
>>> +??? env_set(".flags", "eth6addr");
>>> +??? env_set("eth6addr", NULL);
>>>
>>> ???? retval = _dm_test_eth_rotate1(uts);
>>>
>>> ???? /* Restore the env */
>>> -??? env_set("eth1addr", ethaddr);
>>> +??? env_set("eth6addr", ethaddr);
>>> ???? env_set("ethrotate", NULL);
>>>
>>> ???? if (!retval) {
>>> diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
>>> index d59c449ce0..a4e5c64a1f 100644
>>> --- a/test/dm/test-fdt.c
>>> +++ b/test/dm/test-fdt.c
>>> @@ -359,20 +359,32 @@ static int dm_test_fdt_uclass_seq(struct
>>> unit_test_state *uts)
>>> ???? ut_assertok(uclass_get_device(UCLASS_TEST_FDT, 2, &dev));
>>> ???? ut_asserteq_str("d-test", dev->name);
>>>
>>> -??? /* d-test actually gets 0 */
>>> -??? ut_assertok(uclass_get_device_by_seq(UCLASS_TEST_FDT, 0, &dev));
>>> +??? /*
>>> +???? * d-test actually gets 9, because thats the next free one after
>>> the
>>> +???? * aliases.
>>> +???? */
>>> +??? ut_assertok(uclass_get_device_by_seq(UCLASS_TEST_FDT, 9, &dev));
>>> ???? ut_asserteq_str("d-test", dev->name);
>>>
>>> -??? /* initially no one wants seq 1 */
>>> -??? ut_asserteq(-ENODEV, uclass_get_device_by_seq(UCLASS_TEST_FDT, 1,
>>> +??? /* initially no one wants seq 10 */
>>> +??? ut_asserteq(-ENODEV, uclass_get_device_by_seq(UCLASS_TEST_FDT, 10,
>>> ?????????????????????????????? &dev));
>>> ???? ut_assertok(uclass_get_device(UCLASS_TEST_FDT, 0, &dev));
>>> ???? ut_assertok(uclass_get_device(UCLASS_TEST_FDT, 4, &dev));
>>>
>>> ???? /* But now that it is probed, we can find it */
>>> -??? ut_assertok(uclass_get_device_by_seq(UCLASS_TEST_FDT, 1, &dev));
>>> +??? ut_assertok(uclass_get_device_by_seq(UCLASS_TEST_FDT, 10, &dev));
>>> ???? ut_asserteq_str("f-test", dev->name);
>>>
>>> +??? /*
>>> +???? * And we should still have holes in our sequence numbers, that
>>> is 2
>>> +???? * and 4 should not be used.
>>> +???? */
>>> +??? ut_asserteq(-ENODEV, uclass_find_device_by_seq(UCLASS_TEST_FDT, 2,
>>> +?????????????????????????????? true, &dev));
>>> +??? ut_asserteq(-ENODEV, uclass_find_device_by_seq(UCLASS_TEST_FDT, 4,
>>> +?????????????????????????????? true, &dev));
>>> +
>>> ???? return 0;
>>> ?}
>>> ?DM_TEST(dm_test_fdt_uclass_seq, DM_TESTF_SCAN_PDATA |
>>> DM_TESTF_SCAN_FDT);
>>>
>>
>> Tested-by: Michal Simek <michal.simek@xilinx.com>
> 
> Thanks!
> 
> Just to be sure, did you test this patch or did you also revert
> ?61607225d1 ("i2c: Fill req_seq in i2c_post_bind()")
> before testing?

I have applied this patch on the HEAD + my xilinx patches and run on
zcu102 which has i2c muxes where every bus needs to have own id.
Only i2c0/i2c1 had aliases that's why bus 0/1 had proper links. Others
without alias continue to use 2/3/4/5...

Then I changed i2c1 hw bus to be i2c5 alias and check that aliases are
going from 6 up.

Then apply your patch and check if this behavior stayed there.

ZynqMP> i2c bus
Bus 0:	i2c at ff020000  (active 0)
   20: gpio at 20, offset len 1, flags 0
   21: gpio at 21, offset len 1, flags 0
   75: i2c-mux at 75, offset len 1, flags 0
Bus 6:	i2c at ff020000->i2c-mux at 75->i2c at 0
Bus 7:	i2c at ff020000->i2c-mux at 75->i2c at 1
Bus 8:	i2c at ff020000->i2c-mux at 75->i2c at 2
Bus 5:	i2c at ff030000  (active 5)
   74: i2c-mux at 74, offset len 1, flags 0
   75: i2c-mux at 75, offset len 1, flags 0
Bus 9:	i2c at ff030000->i2c-mux at 74->i2c at 0  (active 9)
   54: eeprom at 54, offset len 1, flags 0
Bus 10:	i2c at ff030000->i2c-mux at 74->i2c at 1
Bus 11:	i2c at ff030000->i2c-mux at 74->i2c at 2
Bus 12:	i2c at ff030000->i2c-mux at 74->i2c at 3
Bus 13:	i2c at ff030000->i2c-mux at 74->i2c at 4
Bus 14:	i2c at ff030000->i2c-mux at 75->i2c at 0
Bus 15:	i2c at ff030000->i2c-mux at 75->i2c at 1
Bus 16:	i2c at ff030000->i2c-mux at 75->i2c at 2
Bus 17:	i2c at ff030000->i2c-mux at 75->i2c at 3
Bus 18:	i2c at ff030000->i2c-mux at 75->i2c at 4
Bus 19:	i2c at ff030000->i2c-mux at 75->i2c at 5
Bus 20:	i2c at ff030000->i2c-mux at 75->i2c at 6
Bus 21:	i2c at ff030000->i2c-mux at 75->i2c at 7


I didn't revert the patch above. If I do it I see a lot of bus without
proper number like this.
ZynqMP> i2c bus
Bus 0:	i2c at ff020000  (active 0)
   20: gpio at 20, offset len 1, flags 0
   21: gpio at 21, offset len 1, flags 0
   75: i2c-mux at 75, offset len 1, flags 0
Bus -1:	i2c at ff020000->i2c-mux at 75->i2c at 0
Bus -1:	i2c at ff020000->i2c-mux at 75->i2c at 1
Bus -1:	i2c at ff020000->i2c-mux at 75->i2c at 2
Bus 5:	i2c at ff030000  (active 5)
   74: i2c-mux at 74, offset len 1, flags 0
   75: i2c-mux at 75, offset len 1, flags 0
Bus -1:	i2c at ff030000->i2c-mux at 74->i2c at 0  (active 6)
   54: eeprom at 54, offset len 1, flags 0
Bus -1:	i2c at ff030000->i2c-mux at 74->i2c at 1
Bus -1:	i2c at ff030000->i2c-mux at 74->i2c at 2
Bus -1:	i2c at ff030000->i2c-mux at 74->i2c at 3
Bus -1:	i2c at ff030000->i2c-mux at 74->i2c at 4
Bus -1:	i2c at ff030000->i2c-mux at 75->i2c at 0
Bus -1:	i2c at ff030000->i2c-mux at 75->i2c at 1
Bus -1:	i2c at ff030000->i2c-mux at 75->i2c at 2
Bus -1:	i2c at ff030000->i2c-mux at 75->i2c at 3
Bus -1:	i2c at ff030000->i2c-mux at 75->i2c at 4
Bus -1:	i2c at ff030000->i2c-mux at 75->i2c at 5
Bus -1:	i2c at ff030000->i2c-mux at 75->i2c at 6
Bus -1:	i2c at ff030000->i2c-mux at 75->i2c at 7


Thanks,
Michal

^ permalink raw reply

* Re: [dpdk-dev] [PATCH] build: add combined libs
From: Luca Boccassi @ 2020-02-20 10:13 UTC (permalink / raw)
  To: Ruslan Babayev, dev; +Cc: Richardson, Bruce
In-Reply-To: <20200219191326.35842-1-ruslan@babayev.com>

On Wed, 2020-02-19 at 11:13 -0800, Ruslan Babayev wrote:
> Add combined libdpdk.a and libdpdk.so libs for Meson similar to how
> it's done for Make builds
> 
> Signed-off-by: Ruslan Babayev <
> ruslan@babayev.com
> >
> ---
>  buildtools/group-libs.sh |  2 ++
>  buildtools/meson.build   |  1 +
>  meson.build              | 17 +++++++++++++++++
>  3 files changed, 20 insertions(+)
>  create mode 100755 buildtools/group-libs.sh
> 
> diff --git a/buildtools/group-libs.sh b/buildtools/group-libs.sh
> new file mode 100755
> index 000000000..b6e4c1c35
> --- /dev/null
> +++ b/buildtools/group-libs.sh
> @@ -0,0 +1,2 @@
> +#!/bin/sh
> +echo 'GROUP (' $(echo $* | xargs -n1 basename | sort | xargs) ')'
> diff --git a/buildtools/meson.build b/buildtools/meson.build
> index 9812917e5..eac8bc4ff 100644
> --- a/buildtools/meson.build
> +++ b/buildtools/meson.build
> @@ -6,6 +6,7 @@ subdir('pmdinfogen')
>  pkgconf = find_program('pkg-config', 'pkgconf', required: false)
>  pmdinfo = find_program('gen-pmdinfo-cfile.sh')
>  list_dir_globs = find_program('list-dir-globs.py')
> +group_libs = find_program('group-libs.sh')
>  check_experimental_syms = find_program('check-experimental-syms.sh')
>  ldflags_ibverbs_static = find_program('options-ibverbs-static.sh')
>  
> diff --git a/meson.build b/meson.build
> index b7ae9c8d9..eb6974d35 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -61,6 +61,23 @@ configure_file(output: build_cfg,
>  		install_dir: join_paths(get_option('includedir'),
>  				get_option('include_subdir_arch')))
>  
> +
> +custom_target('group_shared_libs',
> +		input: dpdk_libraries,
> +		output: 'libdpdk.so',
> +		capture: true,
> +		install: true,
> +		install_dir: get_option('libdir'),
> +		command: [group_libs, '@INPUT@'])
> +
> +custom_target('group_static_libs',
> +		input: dpdk_static_libraries + dpdk_drivers,
> +		output: 'libdpdk.a',
> +		capture: true,
> +		install: true,
> +		install_dir: get_option('libdir'),
> +		command: [group_libs, '@INPUT@'])
> +
>  # for static builds, include the drivers as libs and we need to
> "whole-archive"
>  # them.
>  dpdk_drivers = ['-Wl,--whole-archive'] + dpdk_drivers + ['-Wl,--no-
> whole-archive']

Hi,

As far as I'm aware all usage of the old hacky linker script can be
replaced with pkg-config, and that's why it was left behind. Same for
the static archive.

Is there any use case that pkg-config doesn't cover?

-- 
Kind regards,
Luca Boccassi

^ permalink raw reply

* [MODERATED] Re: Re: [PATCH 1/2] more sampling fun 1
From: Borislav Petkov @ 2020-02-20 10:13 UTC (permalink / raw)
  To: speck
In-Reply-To: <42389fc9-72b1-e04c-cc44-21487a0006e0@citrix.com>

On Thu, Feb 20, 2020 at 10:10:03AM +0000, speck for Andrew Cooper wrote:
> Because it is under embargo until May 12th.

Maybe 2/2 is - which I don't have in my mbox - but by staring only at
1/2 there's nothing to embargo there AFAICT.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

^ permalink raw reply

* [PATCH 8/8] powerpc/papr_scm: Implement support for DSM_PAPR_SCM_HEALTH
From: Vaibhav Jain @ 2020-02-20  9:58 UTC (permalink / raw)
  To: linuxppc-dev
  Cc: Vaibhav Jain, Michael Ellerman, Oliver O'Halloran,
	Alastair D'Silva, Aneesh Kumar K . V
In-Reply-To: <20200220095805.197229-1-vaibhav@linux.ibm.com>

The DSM 'DSM_PAPR_SCM_HEALTH' should return a 'struct
nd_papr_scm_dimm_health_stat' containing information in dimm health back
to user space in response to ND_CMD_CALL. We implement this DSM by
implementing a new function papr_scm_get_health() that queries the
DIMM health information and then copies these bitmaps to the package
payload whose layout is defined by 'struct papr_scm_ndctl_health'.

The patch also handle cases where in future versions of 'struct
papr_scm_ndctl_health' may want to return more health
information. Such payload envelops will contain appropriate version
information in 'struct nd_papr_scm_cmd_pkg.payload_version'. The patch
takes care of only returning the sub-data corresponding to the payload
version requested. Please see the comments in papr_scm_get_health()
for how this is done.

Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
 arch/powerpc/platforms/pseries/papr_scm.c | 73 +++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index 29f38246c59f..bf81acb0bf3f 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -415,6 +415,74 @@ static int cmd_to_func(struct nvdimm *nvdimm, unsigned int cmd, void *buf,
 	return pkg->hdr.nd_command;
 }
 
+/*
+ * Fetch the DIMM health info and populate it in provided papr_scm package.
+ * Since the caller can request a different version of payload and each new
+ * version of struct nd_papr_scm_dimm_health_stat is a proper-subset of
+ * previous version hence we return a subset of the cached 'struct
+ * nd_papr_scm_dimm_health_stat' depending on the payload version requested.
+ */
+static int papr_scm_get_health(struct papr_scm_priv *p,
+			       struct nd_papr_scm_cmd_pkg *pkg)
+{
+	int rc;
+	size_t copysize;
+	/* Map version to number of bytes to be copied to payload */
+	const size_t copysizes[] = {
+		[1] =
+		sizeof(struct nd_papr_scm_dimm_health_stat_v1),
+
+		/*  This should always be preset */
+		[ND_PAPR_SCM_DIMM_HEALTH_VERSION] =
+		sizeof(struct nd_papr_scm_dimm_health_stat),
+	};
+
+	rc = drc_pmem_query_health(p);
+	if (rc)
+		goto out;
+	/*
+	 * If the requested payload version is greater than one we know
+	 * aboute, return the payload version we know about and let
+	 * caller/userspace handle the mess.
+	 */
+	if (pkg->payload_version > ND_PAPR_SCM_DIMM_HEALTH_VERSION)
+		pkg->payload_version = ND_PAPR_SCM_DIMM_HEALTH_VERSION;
+
+	copysize = copysizes[pkg->payload_version];
+	if (!copysize) {
+		dev_dbg(&p->pdev->dev, "%s Unsupported payload version=0x%x\n",
+			__func__, pkg->payload_version);
+		rc = -ENOSPC;
+		goto out;
+	}
+
+	if (pkg->hdr.nd_size_out < copysize) {
+		dev_dbg(&p->pdev->dev, "%s Payload not large enough\n",
+			__func__);
+		dev_dbg(&p->pdev->dev, "%s Expected %lu, available %u\n",
+			__func__, copysize, pkg->hdr.nd_size_out);
+		rc = -ENOSPC;
+		goto out;
+	}
+
+	dev_dbg(&p->pdev->dev, "%s Copying payload size=%lu version=0x%x\n",
+		__func__, copysize, pkg->payload_version);
+
+	/* Copy a subset of health struct based on copysize */
+	memcpy(papr_scm_pcmd_to_payload(pkg), &p->health, copysize);
+	pkg->hdr.nd_fw_size = copysize;
+
+out:
+	/*
+	 * Put the error in out package and return success from function
+	 * so that errors if any are propogated back to userspace.
+	 */
+	pkg->cmd_status = rc;
+	dev_dbg(&p->pdev->dev, "%s completion code = %d\n", __func__, rc);
+
+	return 0;
+}
+
 int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
 		unsigned int cmd, void *buf, unsigned int buf_len, int *cmd_rc)
 {
@@ -460,6 +528,11 @@ int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
 		*cmd_rc = 0;
 		break;
 
+	case DSM_PAPR_SCM_HEALTH:
+		call_pkg = nd_to_papr_cmd_pkg(buf);
+		*cmd_rc = papr_scm_get_health(p, call_pkg);
+		break;
+
 	default:
 		dev_dbg(&p->pdev->dev, "Unknown command = %d\n", cmd_in);
 		*cmd_rc = -EINVAL;
-- 
2.24.1


^ permalink raw reply related

* Re: mvneta: comphy regression with SolidRun ClearFog
From: Russell King - ARM Linux admin @ 2020-02-20 10:12 UTC (permalink / raw)
  To: Joel Johnson
  Cc: David S. Miller, Baruch Siach, Gregory Clement, Thomas Petazzoni,
	Rob Herring, netdev
In-Reply-To: <8099d231594f1785e7149e4c6c604a5c@lixil.net>

On Wed, Feb 19, 2020 at 06:49:51AM -0700, Joel Johnson wrote:
> On 2020-02-19 02:22, Russell King - ARM Linux admin wrote:
> > On Tue, Feb 18, 2020 at 10:14:48PM -0700, Joel Johnson wrote:
> > > In updating recently I'm encountering a regression with the mvneta
> > > driver on
> > > SolidRun ClearFog Base devices. I originally filed the bug with Debian
> > > (https://bugs.debian.org/951409) since I was using distro provided
> > > packages,
> > > but after further investigation I have isolated the issue as related
> > > to
> > > comphy support added during development for kernel version 5.1.
> > > 
> > > When booting stock kernels up to 5.0 everything works as expected
> > > with three
> > > ethernet devices identified and functional. However, running any
> > > kernel 5.1
> > > or later, I only have a single ethernet device available. The single
> > > device
> > > available appears to be the one attached to the SoC itself and not
> > > connected
> > > via SerDes lanes using comphy, i.e. the one defined at
> > > f1070000.ethernet.
> > > 
> > > With some log/diff assisted bisecting, I've been able to confirm
> > > that the
> > > "tipping point" changeset is f548ced15f90, which actually performs
> > > the DT
> > > change for the ClearFog family of devices. That's the commit at
> > > which the
> > > failure starts, but is just the final enablement of the added
> > > feature in the
> > > overall series. I've also tested booting the same kernel binary
> > > (including
> > > up to v5.6-rc1) and only swapping the dtb for one excluding the
> > > problematic
> > > commit and confirmed that simply changing the dtb results in all three
> > > devices being functional, albeit obviously without comphy support.
> > 
> > Does debian have support for the comphy enabled in their kernel,
> > which is controlled by CONFIG_PHY_MVEBU_A38X_COMPHY ?
> 
> Well, doh! I stared at the patch series for way to long, but the added
> Kconfig symbol failed to register mentally somehow. I had been using the
> last known good Debian config with make olddefconfig, but it obviously
> wasn't included in earlier configs and not enabled by default.
> 
> I tested a build with v5.6-rc1 and actually enabled the platform driver and
> it worked as expected, including log output of "configuring for sgmii link
> mode". Back to moving forward on other testing. Sorry for the noise, I'll
> update the Debian bug with a patch to enable the config symbol for armmp
> kernels.
> 
> Many thanks to you and Willy Tarreau for pointing out my glaring omission!

Thanks for letting us know that you've fixed it now.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply

* Re: [REGRESSION] gpio hogging fails with pinctrl gpio drivers
From: Peter Rosin @ 2020-02-20 10:12 UTC (permalink / raw)
  To: Linus Walleij, Russell King - ARM Linux admin,
	open list:GPIO SUBSYSTEM
  Cc: Andrey Smirnov, Linux ARM
In-Reply-To: <CACRpkdbzjBnaeXJg3XvZ6G2FdtQQa0u7MPy9bgN-uo-F1vSpbQ@mail.gmail.com>

On 2020-02-20 09:17, Linus Walleij wrote:
> On Thu, Feb 6, 2020 at 6:33 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> 
>> It seems that sometime between 4.20 and 5.5, something has broken the
>> ability to specify gpio-hogs in DT for GPIOs that are written around
>> pinctrl drivers.
> (explanation that makes perfect sense)
>> Consequently, adding a gpio-hog to DT for this driver results in the
>> driver endlessly returning -EPROBE_DEFER.
> 
> I suspect this is sx150x-specific and suspect these two commits:
> 
> 1a1d39e1b8dd pinctrl: sx150x: Register pinctrl before adding the gpiochip
> b930151e5b55 pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping
> 
> I suppose people weren't using hogs very much with the sx150x and
> it didn't turn up in testing so far.
> 
> I don't think for example pinctrl-stmfx.c has this problem, as it registers
> the pin ranges from the device tree as part of the core code.
> But other drivers calling gpiochip_add_pin_range() may be experiencing
> this.
> 
> Peter/Andrey, do you have some idea? Have you tested this usecase (hogs)
> with the sx150x?

I have never created gpio hogs myself, so no, I haven't done any testing
with that. Sorry. I could of course spend some time looking at this, but I
don't know all that much about the wrinkles of the interactions between
pinctrl och gpio. Or plain gpio/pinctrl for that matter. Sure, I extended
this driver, but I haven't really looked at those sub-systems since. I
think others will come up with a solution for this with much less effort
and with less risk of introducing new problems...

Cheers,
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: Hard Disk consumes lots of power in s2idle
From: Rafael J. Wysocki @ 2020-02-20 10:12 UTC (permalink / raw)
  To: Kai-Heng Feng
  Cc: Srinivas Pandruvada, Linux PM,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	open list, Kent Lin, Tejun Heo
In-Reply-To: <235CF4F8-19BF-4B00-8C92-E59CB2D476A7@canonical.com>

On Thu, Feb 20, 2020 at 9:08 AM Kai-Heng Feng
<kai.heng.feng@canonical.com> wrote:
>
> Hi Srinivas,
>
> > On Feb 20, 2020, at 02:36, Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
> >
> > Hi Kai,
> >
> > On Wed, 2020-02-19 at 22:22 +0800, Kai-Heng Feng wrote:
> >> Hi Srinivas,
> >>
> >> Your previous work to support DEVSLP works well on SATA SSDs, so I am
> >> asking you the issue I am facing:
> >> Once a laptop has a HDD installed, the power consumption during
> >> S2Idle increases ~0.4W, which is quite a lot.
> >> However, HDDs don't seem to support DEVSLP, so I wonder if you know
> >> to do proper power management for HDDs?
> > What is the default here
> > cat /sys/power/mem_sleep
> > s2idle or deep?
>
> It defaults to s2idle.
>
> >
> > Please follow debug steps here:
> > https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux
> >
> > We need to check whether you get any PC10 residency or not.
>
> Yes it reaches PC10. It doesn't reach SLP_S0 though.
> The real number on S2Idle power consumption:
> No HDD: ~1.4W
> One HDD: ~1.8W
>
> If the SoC doesn't hit PC10 the number should be significantly higher.
> That's why I think the issue is the power management on HDD itself.

I'm assuming that you mean a non-SSD device here.

That would be handled via ata_port_suspend() I gather and whatever
that does should do the right thing.

Do you think that the disk doesn't spin down or it spins down, but the
logic stays on?

^ permalink raw reply

* Re: [REGRESSION] gpio hogging fails with pinctrl gpio drivers
From: Peter Rosin @ 2020-02-20 10:12 UTC (permalink / raw)
  To: Linus Walleij, Russell King - ARM Linux admin,
	open list:GPIO SUBSYSTEM
  Cc: Linux ARM, Andrey Smirnov
In-Reply-To: <CACRpkdbzjBnaeXJg3XvZ6G2FdtQQa0u7MPy9bgN-uo-F1vSpbQ@mail.gmail.com>

On 2020-02-20 09:17, Linus Walleij wrote:
> On Thu, Feb 6, 2020 at 6:33 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> 
>> It seems that sometime between 4.20 and 5.5, something has broken the
>> ability to specify gpio-hogs in DT for GPIOs that are written around
>> pinctrl drivers.
> (explanation that makes perfect sense)
>> Consequently, adding a gpio-hog to DT for this driver results in the
>> driver endlessly returning -EPROBE_DEFER.
> 
> I suspect this is sx150x-specific and suspect these two commits:
> 
> 1a1d39e1b8dd pinctrl: sx150x: Register pinctrl before adding the gpiochip
> b930151e5b55 pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping
> 
> I suppose people weren't using hogs very much with the sx150x and
> it didn't turn up in testing so far.
> 
> I don't think for example pinctrl-stmfx.c has this problem, as it registers
> the pin ranges from the device tree as part of the core code.
> But other drivers calling gpiochip_add_pin_range() may be experiencing
> this.
> 
> Peter/Andrey, do you have some idea? Have you tested this usecase (hogs)
> with the sx150x?

I have never created gpio hogs myself, so no, I haven't done any testing
with that. Sorry. I could of course spend some time looking at this, but I
don't know all that much about the wrinkles of the interactions between
pinctrl och gpio. Or plain gpio/pinctrl for that matter. Sure, I extended
this driver, but I haven't really looked at those sub-systems since. I
think others will come up with a solution for this with much less effort
and with less risk of introducing new problems...

Cheers,
Peter

^ permalink raw reply

* Attention:Beneficiary
From: Mrs. Susan S. Cage @ 2020-02-20 10:11 UTC (permalink / raw)


-- 
Dearest Friend,

Sorry for invading your privacy, my name is Susan S. Cage I am 81
years, citizen of United States and presently in hospital undergoing
chromatography for bronchogenic carcinomas (Lung cancer) which
affected both Lungs. The doctors said I have few days to live because
the cancer has now affected my brain.

My late husband left Fifteen Million, Five Hundred British Pounds
Sterling in my account, I want to transfer the money to you and I want
you to use it as a donate for charitable and help the needy,
motherless, less privileged and widows within your location.

I need your assurance that you will use the fund for charity, once I a
favorable reply from you, will inform my Bank through my lawyer to
transfer the fund to you as my Next of Kin and Sole Beneficiary. Once
I receive your response, I will inform my bank in writing through my
lawyer.



Thank you and God bless you.

Mrs. Susan S. Cage

^ permalink raw reply

* Attention:Beneficiary
From: Mrs. Susan S. Cage @ 2020-02-20 10:11 UTC (permalink / raw)


-- 
Dearest Friend,

Sorry for invading your privacy, my name is Susan S. Cage I am 81
years, citizen of United States and presently in hospital undergoing
chromatography for bronchogenic carcinomas (Lung cancer) which
affected both Lungs. The doctors said I have few days to live because
the cancer has now affected my brain.

My late husband left Fifteen Million, Five Hundred British Pounds
Sterling in my account, I want to transfer the money to you and I want
you to use it as a donate for charitable and help the needy,
motherless, less privileged and widows within your location.

I need your assurance that you will use the fund for charity, once I a
favorable reply from you, will inform my Bank through my lawyer to
transfer the fund to you as my Next of Kin and Sole Beneficiary. Once
I receive your response, I will inform my bank in writing through my
lawyer.



Thank you and God bless you.

Mrs. Susan S. Cage

^ permalink raw reply

* Attention:Beneficiary
From: Mrs. Susan S. Cage @ 2020-02-20 10:11 UTC (permalink / raw)
  To: kernel-janitors

-- 
Dearest Friend,

Sorry for invading your privacy, my name is Susan S. Cage I am 81
years, citizen of United States and presently in hospital undergoing
chromatography for bronchogenic carcinomas (Lung cancer) which
affected both Lungs. The doctors said I have few days to live because
the cancer has now affected my brain.

My late husband left Fifteen Million, Five Hundred British Pounds
Sterling in my account, I want to transfer the money to you and I want
you to use it as a donate for charitable and help the needy,
motherless, less privileged and widows within your location.

I need your assurance that you will use the fund for charity, once I a
favorable reply from you, will inform my Bank through my lawyer to
transfer the fund to you as my Next of Kin and Sole Beneficiary. Once
I receive your response, I will inform my bank in writing through my
lawyer.



Thank you and God bless you.

Mrs. Susan S. Cage

^ permalink raw reply

* [PATCH 7/8] powerpc/papr_scm: Re-implement 'papr_flags' using 'nd_papr_scm_dimm_health_stat'
From: Vaibhav Jain @ 2020-02-20  9:58 UTC (permalink / raw)
  To: linuxppc-dev
  Cc: Vaibhav Jain, Michael Ellerman, Oliver O'Halloran,
	Alastair D'Silva, Aneesh Kumar K . V
In-Reply-To: <20200220095805.197229-1-vaibhav@linux.ibm.com>

Previous commit [1] introduced 'struct nd_papr_scm_dimm_health_stat' for
communicating health status of an nvdimm to libndctl. This struct
however can also be used to cache the nvdimm health information in
'struct papr_scm_priv' instead of two '__be64' values. Benefit of this
re-factoring will be apparent when support for libndctl being able to
request nvdimm health stats is implemented where we can simply memcpy
this struct over to the user-space provided payload envelope.

Hence this patch introduces a new member 'struct papr_scm_priv.health'
that caches the health information of a dimm. This member is populated
inside drc_pmem_query_health() which checks for the various bit flags
returned from H_SCM_HEALTH and sets them in this struct. We also
re-factor 'papr_flags' sysfs attribute show function papr_flags_show()
to use the flags in 'struct papr_scm_priv.health' to return
appropriate status strings pertaining to dimm health.

This patch shouldn't introduce any behavioral change.

Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
 arch/powerpc/platforms/pseries/papr_scm.c | 61 ++++++++++++++++-------
 1 file changed, 44 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index d5eea2f38fa6..29f38246c59f 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -47,8 +47,7 @@ struct papr_scm_priv {
 	struct mutex dimm_mutex;
 
 	/* Health information for the dimm */
-	__be64 health_bitmap;
-	__be64 health_bitmap_valid;
+	struct nd_papr_scm_dimm_health_stat health;
 
 	/* length of the stat buffer as expected by phyp */
 	size_t len_stat_buffer;
@@ -205,6 +204,7 @@ static int drc_pmem_query_health(struct papr_scm_priv *p)
 {
 	unsigned long ret[PLPAR_HCALL_BUFSIZE];
 	int64_t rc;
+	__be64 health;
 
 	rc = plpar_hcall(H_SCM_HEALTH, ret, p->drc_index);
 	if (rc != H_SUCCESS) {
@@ -219,13 +219,41 @@ static int drc_pmem_query_health(struct papr_scm_priv *p)
 		return rc;
 
 	/* Store the retrieved health information in dimm platform data */
-	p->health_bitmap = ret[0];
-	p->health_bitmap_valid = ret[1];
+	health = ret[0] & ret[1];
 
 	dev_dbg(&p->pdev->dev,
 		"Queried dimm health info. Bitmap:0x%016llx Mask:0x%016llx\n",
-		be64_to_cpu(p->health_bitmap),
-		be64_to_cpu(p->health_bitmap_valid));
+		be64_to_cpu(ret[0]),
+		be64_to_cpu(ret[1]));
+
+	memset(&p->health, 0, sizeof(p->health));
+
+	/* Check for various masks in bitmap and set the buffer */
+	if (health & PAPR_SCM_DIMM_UNARMED_MASK)
+		p->health.dimm_unarmed = true;
+
+	if (health & PAPR_SCM_DIMM_BAD_SHUTDOWN_MASK)
+		p->health.dimm_bad_shutdown = true;
+
+	if (health & PAPR_SCM_DIMM_BAD_RESTORE_MASK)
+		p->health.dimm_bad_restore = true;
+
+	if (health & PAPR_SCM_DIMM_ENCRYPTED)
+		p->health.dimm_encrypted = true;
+
+	if (health & PAPR_SCM_DIMM_SCRUBBED_AND_LOCKED) {
+		p->health.dimm_locked = true;
+		p->health.dimm_scrubbed = true;
+	}
+
+	if (health & PAPR_SCM_DIMM_HEALTH_UNHEALTHY)
+		p->health.dimm_health = DSM_PAPR_SCM_DIMM_UNHEALTHY;
+
+	if (health & PAPR_SCM_DIMM_HEALTH_CRITICAL)
+		p->health.dimm_health = DSM_PAPR_SCM_DIMM_CRITICAL;
+
+	if (health & PAPR_SCM_DIMM_HEALTH_FATAL)
+		p->health.dimm_health = DSM_PAPR_SCM_DIMM_FATAL;
 
 	mutex_unlock(&p->dimm_mutex);
 	return 0;
@@ -513,7 +541,6 @@ static ssize_t papr_flags_show(struct device *dev,
 {
 	struct nvdimm *dimm = to_nvdimm(dev);
 	struct papr_scm_priv *p = nvdimm_provider_data(dimm);
-	__be64 health;
 	int rc;
 
 	rc = drc_pmem_query_health(p);
@@ -525,26 +552,26 @@ static ssize_t papr_flags_show(struct device *dev,
 	if (rc)
 		return rc;
 
-	health = p->health_bitmap & p->health_bitmap_valid;
-
-	/* Check for various masks in bitmap and set the buffer */
-	if (health & PAPR_SCM_DIMM_UNARMED_MASK)
+	if (p->health.dimm_unarmed)
 		rc += sprintf(buf, "not_armed ");
 
-	if (health & PAPR_SCM_DIMM_BAD_SHUTDOWN_MASK)
+	if (p->health.dimm_bad_shutdown)
 		rc += sprintf(buf + rc, "save_fail ");
 
-	if (health & PAPR_SCM_DIMM_BAD_RESTORE_MASK)
+	if (p->health.dimm_bad_restore)
 		rc += sprintf(buf + rc, "restore_fail ");
 
-	if (health & PAPR_SCM_DIMM_ENCRYPTED)
+	if (p->health.dimm_encrypted)
 		rc += sprintf(buf + rc, "encrypted ");
 
-	if (health & PAPR_SCM_DIMM_SMART_EVENT_MASK)
+	if (p->health.dimm_health)
 		rc += sprintf(buf + rc, "smart_notify ");
 
-	if (health & PAPR_SCM_DIMM_SCRUBBED_AND_LOCKED)
-		rc += sprintf(buf + rc, "scrubbed locked ");
+	if (p->health.dimm_scrubbed)
+		rc += sprintf(buf + rc, "scrubbed ");
+
+	if (p->health.dimm_locked)
+		rc += sprintf(buf + rc, "locked ");
 
 	if (rc > 0)
 		rc += sprintf(buf + rc, "\n");
-- 
2.24.1


^ permalink raw reply related

* Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: extend inline session to non AES-GCM
From: Akhil Goyal @ 2020-02-20 10:11 UTC (permalink / raw)
  To: bernard.iremonger@intel.com, Konstantin Ananyev
  Cc: dev@dpdk.org, stable@dpdk.org, Ankur Dwivedi,
	Narayana Prasad Raju Athreya, Anoob Joseph
In-Reply-To: <MN2PR18MB2877170F6022EEB72D755EDCDF140@MN2PR18MB2877.namprd18.prod.outlook.com>


> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Saturday, February 15, 2020 1:06 PM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Konstantin Ananyev
> <konstantin.ananyev@intel.com>
> Cc: Ankur Dwivedi <adwivedi@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] examples/ipsec-secgw: extend inline session to
> non AES-GCM
> 
> > This patch extends creation of inline session to all the algorithms.
> > Previously the inline session was enabled only for AES-GCM cipher.
> >
> > Fixes: 3a690d5a65e2 ("examples/ipsec-secgw: fix first packet with inline
> > crypto")
> >
> > Signed-off-by: Ankur Dwivedi <adwivedi@marvell.com>
> > ---
> >  examples/ipsec-secgw/sa.c | 26 ++++++++++++--------------
> >  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> Acked-by: Anoob Joseph <anoobj@marvell.com>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>

Hi Konstantin,

I am about to merge this patch. Do you have any issues on this.

Regards,
Akhil

^ permalink raw reply

* Re: [igt-dev] [PATCH i-g-t 1/1] tools/generate_cb_buffer: Add script to assemble CB kernel
From: Petri Latvala @ 2020-02-20 10:10 UTC (permalink / raw)
  To: Abodunrin, Akeem G
  Cc: Luck, Tony, Aran, Omer, Nikula, Jani, Wilson, Chris P,
	Stewart, David C, igt-dev@lists.freedesktop.org,
	Pathi, Pragyansri, Bloomfield, Jon, Vetter, Daniel,
	Kuoppala, Mika
In-Reply-To: <CFEEE81102D91947B9CC368106979EBAC8A1549D@ORSMSX102.amr.corp.intel.com>

On Thu, Feb 20, 2020 at 03:06:09AM +0200, Abodunrin, Akeem G wrote:
> > > +export ASSEMBLY_SOURCE=./tools/assembly_source
> > > +
> > > +function get_help {
> > > +        echo "Usage:    asm_eu_kernel.sh [options]"
> > > +        echo "Remember to run this as root"
> > 
> > I can't spot why this would need root.
> Since we are generating new file, and writing to it - the script definitely needs root access... otherwise commands like this " prefix_header $i915_filename "Media CB Kernel for gen7.5 devices"" fails

That's no reason to need root. That's just a reason to need write
access to the directory where you're creating the files.

As you require the script to be run in IGT source root and writing to
$cwd, you need write access to IGT source root. Which shouldn't be
root-owned.


> > 
> > 
> > > +        echo " "
> > > +        echo "Please make sure your MESA tool is compiled, and run this script
> > from igt home directory"
> > 
> > Mesa written as "Mesa" and IGT written as "IGT". And it's "source root
> > directory", not "home directory".
> > 
> > Does the assembler require specific build options for Mesa? Note them here.
> 
> Yes, it does - but the options are hardcoded in this script - so, mentioning them in the help function is irrelevant...

I'm asking about the Mesa _build_ options. This script doesn't build
Mesa, it just uses it.

From a quick check that would be -Dtools=intel that is required.



-- 
Petri Latvala
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply


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.