From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBD9AC04AB6 for ; Fri, 31 May 2019 16:16:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9207126BD1 for ; Fri, 31 May 2019 16:16:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SpLk15Xg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726869AbfEaQQc (ORCPT ); Fri, 31 May 2019 12:16:32 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:42486 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726579AbfEaQQc (ORCPT ); Fri, 31 May 2019 12:16:32 -0400 Received: by mail-ed1-f67.google.com with SMTP id g24so5697956eds.9; Fri, 31 May 2019 09:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ppoLqKJDwMX/G3QhRlPCGM9RObcFV44Iy8KgicrJiXs=; b=SpLk15XghWHHC7Bi5S3Uj5v4i/8WjSxU/ADXUgS2+JgBy2zYReu66dUfkDGSax9+S6 I0zYKj/KTJ4f+N6yq31qAeZpBbv3kkocg2y/+V2yG9BnV2WSCLy4w7jh+kkjsOrDhd2K 1S71iB8jk6cI8aUofw5p0eqGamNz36G39EA2uU7T3HzpJZvsBffqRkgurmjIu9l70Dyx utoqiduKY9VXwsX21gyErybse9IcZNOC9gA8QmmdkXRRkhj7rvvNWMiaxJdr3UPZyyCe S/kFdDQHQxbqFQbOG8++UHPHwfaUfFLswi1d385CfnK9q+3QzkQWU4G0/GwEPhoUouCQ 1zlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ppoLqKJDwMX/G3QhRlPCGM9RObcFV44Iy8KgicrJiXs=; b=C3fkIM+vbKijOp3jrM7QzkMbbnAK6h0PdHWFfAOJ9D/AejBfKus/ip44mX605JtL2h RUhBrFpK9TUO6o4Emx10m41e4vq4Lb25vJeIVT4m3fc4ByjIxc46COYaFqjAgUaWlB/I DtsvE10Hi73YPc6OnzXS05qiMJtglZ3+IRoj8/CGUk5ltJYzsJQ33oCP1YXn904DVr7X wpS4CpMk7Azzx2LMpdpwGTwndjxAbZYfNBIQvn9C+YG7yqm+lEDD8DZ+P+TKLB4DtDpl +1jXDaKY9jtcnY39qi5yTa1keyoUmkKJORUjhyRAw1kP01Y1pm4vRtGJTyS2YVT6BvWu vZEQ== X-Gm-Message-State: APjAAAUBJRK264nJAqzwKoW6mEHeUgBu5QKjbNwYRFGEeKiKVnGDdbjt RUlOZezCmE3kFvDHtjx4Byj/yN5rVC0xHwI9xJs= X-Google-Smtp-Source: APXvYqxi6b0K6tTVfA1e0P5XeyJhKW3LdF7NuYrIjBe58v9itIap09JseWXs29+ym3u4i5kdCNQnCDnTjBdfDOxf3ws= X-Received: by 2002:a50:fd0a:: with SMTP id i10mr12161284eds.117.1559319389427; Fri, 31 May 2019 09:16:29 -0700 (PDT) MIME-Version: 1.0 References: <20190530143037.iky5kk3h4ssmec3f@localhost> <20190530150557.iur7fruhyf5bs3qw@localhost> <20190531043417.6phscbpmo6krvxam@localhost> <20190531140841.j4f72rlojmaayqr5@localhost> <20190531151151.k3a2wdf5f334qmqh@localhost> <20190531160909.jh43saqvichukv7p@localhost> In-Reply-To: <20190531160909.jh43saqvichukv7p@localhost> From: Vladimir Oltean Date: Fri, 31 May 2019 19:16:17 +0300 Message-ID: Subject: Re: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver To: Richard Cochran Cc: Florian Fainelli , Vivien Didelot , Andrew Lunn , "David S. Miller" , John Stultz , Thomas Gleixner , Stephen Boyd , lkml , netdev Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 31 May 2019 at 19:09, Richard Cochran wrote: > > On Fri, May 31, 2019 at 06:23:34PM +0300, Vladimir Oltean wrote: > > You mean to queue it and subvert DSA's own RX timestamping callback? > > No, use the callback. > > > Why would I do that? Just so as not to introduce my .can_timestamp > > callback? > > Right, the .can_timestamp is unneeded, AFAICT. > > > > Now I'm starting to understand your series. I think it can be done in > > > simpler way... > > > > > > sja1105_rcv_meta_state_machine - can and should be at the driver level > > > and not at the port level. > > > > > > > Can: yes. Should: why? > > To keep it simple and robust. > > > One important aspect makes this need be a little bit more complicated: > > reconstructing these RX timestamps. > > You see, there is a mutex on the SPI bus, so in practice I do need the > > sja1105_port_rxtstamp_work for exactly this purpose - to read the > > timestamping clock over SPI. > > Sure. But you schedule the work after a META frame. And no busy > waiting is needed. Ok, I suppose this could work. But now comes the question on what to do on error cases - the meta frame didn't arrive. Should I just drop the skb waiting for it? Right now I "goto rcv_anyway" - which linuxptp doesn't like btw. > > Thanks, > Richard