Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1057255ybi; Fri, 14 Jun 2019 07:57:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqx/Elnc0eIQwHQ83lPsDzzr86zfSTjoleFkpyXCRyVw23reRRyJ+kP8QaKbDJYfMuv+S92U X-Received: by 2002:a17:90a:5d15:: with SMTP id s21mr11490820pji.125.1560524246206; Fri, 14 Jun 2019 07:57:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560524246; cv=none; d=google.com; s=arc-20160816; b=nlAdTEvXaYp0OCT18Sf2JUsRhwD/umUw2bGaIbWCOO/lxouo66aMjqZW1yG0i4emA/ VbqxozUHfqmjGVD3eFPn8pbO5k7kiRbP4OQuRl8gyq9kA3OLUcIQdizDbK7RbHynYPGB mZ3GEEfrl5/rpJQed8/9mnChsbFI5ukNUuXlaZFRS2zqyz8QH6ad8oVN2exJha5kKgrl hROFw6fs+b9KNDpHDVlGbBNHSXNYMwvfBulkiJfRXiJ34SsnW6q9Rr0NTCbgP2uf+qH7 kuuheAr4EVLlk0eivOitEcy6nbFPOXkXs7gOw5jcomxYAcBi+aB1CsaZg3zBITpXxrTs 0YEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:to:from:subject:message-id; bh=23/Ea94nAJ6hResPni2Z2RD5QfhJwVmWCYd9ZNFZomc=; b=iVaVnLN58/Yd/kzUwXWUGvGqUn8DBme18LoOuJEsyaQcQYn9/yT3hCt+mPVQsWnXuj bvRYFyNidS5I+yum3YZvLABZ4mgvIZmYrYYy7xrQvVr0RrpEuXd+3x5Iw8L8kcyutNMs PYUCFHh0ziwyiZJL+wGvLJOVsDMhbHLBOMp5Gimm23VrFJqeivhOPsp/aIagTbAefBmN Bz1HoJcYc4VuRY87+fFZ6MQ3TQ5FhdjSeJWmiSyXowRhCuu8qvXBaZXLIjIWrhlW3SGV ledlvhFR+QTrl+0wBQjN05dVshxRfCNw4OYbrYN9Lxqwo8JQdPd2yFW/Zj8GsSx5Aaj1 i10Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t23si2669771pgu.320.2019.06.14.07.57.10; Fri, 14 Jun 2019 07:57:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728233AbfFNO5B (ORCPT + 99 others); Fri, 14 Jun 2019 10:57:01 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:43252 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727272AbfFNO5B (ORCPT ); Fri, 14 Jun 2019 10:57:01 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hbndN-0003Ic-Ll; Fri, 14 Jun 2019 16:56:53 +0200 Message-ID: Subject: Re: [PATCH-v3 1/2] wireless: Support assoc-at-ms timer in sta-info From: Johannes Berg To: Ben Greear , linux-wireless@vger.kernel.org Date: Fri, 14 Jun 2019 16:56:52 +0200 In-Reply-To: <3ad69c55-2b88-a96b-d21e-99f4418466ee@candelatech.com> References: <20190415172123.6532-1-greearb@candelatech.com> <21fa668485f4eb0a8056aac1797854f267d5f1e0.camel@sipsolutions.net> <3ad69c55-2b88-a96b-d21e-99f4418466ee@candelatech.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-2.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Fri, 2019-06-14 at 07:46 -0700, Ben Greear wrote: > > The point of my patch was to allow 'iw' to return a more precise time > that the station has been associated, so I am not sure that BOOTIME is > a good thing to use for that? Depends what you want, really. > + if (sinfo[NL80211_STA_INFO_ASSOC_AT_MS]) > + printf("\n\tassociated at:\t%llu ms", > + (unsigned long long)nla_get_u64(sinfo[NL80211_STA_INFO_ASSOC_AT_MS])); > > - printf("\n"); > + printf("\n\tcurrent time:\t%llu ms\n", now_ms); Since you just print the time in milliseconds, and the current time in milliseconds, you don't even really have any value in the wall clock. Quite the opposite - this lends itself to subtracting to try to figure out how long it was associated, which is the completely wrong thing to do with wall clock - timezone adjustment could've happened inbetween, for example! I really see no point in trying to give the wall clock at assoc time. If no timezone adjustment happened, you can just as well give the boottime and have the userspace figure out the wall clock. If timezone adjustment happened, then any calculations are wrong anyway, what would the point be? johannes