From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C8192C2349; Tue, 18 Nov 2025 18:37:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763491047; cv=none; b=MAc45CuhL6sNNdNPyH/MVLcxfAIQ3um/Yt7ddj3qLduPmAFh3rnCQgDhnrCDH08VrbeoWNa4w8+ZgBXOUmL7ALLQ498nO+xXdLuzy/V08bW0uqZUWNZ2kbyEtPsxNWYyHH5qJz/A2LIlzTGFuqYgd2cNz0+JrpqM1sEa/BN5ZCE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763491047; c=relaxed/simple; bh=iIYEMQjx/M1XUrR5hgrjP+2FqsUWRotw30++B0tJHME=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=AIK6h3yegxDZjUMKd9IwfbE4Ww5+EOLjM9PYIRVQGswLuBaEmkvn6OsXfR/2i8ztj3YSC2N3Z4nsDCpFfGriwA85+y4M8PLmNEFR9KSej96ZIat/UWU7lhCeahFBSJiL3h3zUF05ihbJs1j9cuvxj7u9MQABnisZ8clgC2TTqlI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=NpETt1aw; arc=none smtp.client-ip=192.198.163.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="NpETt1aw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763491045; x=1795027045; h=date:from:to:cc:subject:message-id:mime-version; bh=iIYEMQjx/M1XUrR5hgrjP+2FqsUWRotw30++B0tJHME=; b=NpETt1aw5iFXwLlWhSCW8Kr6Fy2jmoqNzaTxMUP1NpOOAAeTZV5+KqhT wtJf4KUQSvaojysytvWQVLXYlJkck/cIO28pEsq6f4yCJHQoEHfMwV8e7 /eFuUUosDBD3Mpy71r9d8CptkR9bLr85eYE5kMERTS5FBKbVu7IQ/B3jP jRAddhTFCqxkXdCsVU6/CSpQIp+VEOUuerrjAL5d+LN7F7CtEFq/ai8Be z2s5NGZxmQkF/719r0mC1Lj9+uoNJVqWXTXOROZcQSfqNsQg09lQwAALH jtIzbZeeh037lsZTN/tjZycmsoWt77Yq04NRuAqNnGvkBF+W9LTwsbwGe A==; X-CSE-ConnectionGUID: 1laKZg9HQlCYOcuNnIZIbQ== X-CSE-MsgGUID: AxDzOP6CSj60+B2SRyg1UA== X-IronPort-AV: E=McAfee;i="6800,10657,11617"; a="90999881" X-IronPort-AV: E=Sophos;i="6.19,314,1754982000"; d="scan'208";a="90999881" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2025 10:37:24 -0800 X-CSE-ConnectionGUID: 5jsUiwQYTZ+aZm1TcLT33A== X-CSE-MsgGUID: F02ZlehpSQKaQESX8lqbDg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,314,1754982000"; d="scan'208";a="190488586" Received: from dalessan-mobl3.ger.corp.intel.com (HELO localhost) ([10.245.245.97]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2025 10:37:22 -0800 Date: Tue, 18 Nov 2025 20:37:20 +0200 From: Andy Shevchenko To: Vadim Fedorenko Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Richard Cochran , Jonathan Lemon , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Subject: Re: [PATCH v1 0/7] ptp: ocp: A fix and refactoring Message-ID: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Wed, Nov 12, 2025 at 03:27:14PM +0000, Vadim Fedorenko wrote: > On 11/11/2025 16:52, Andy Shevchenko wrote: > > > ptp: ocp: Sort headers alphabetically > > ptp: ocp: don't use "proxy" headers > I don't see benefits of these 2 patches, what's the reason? I may give these reasons: 1. Makes clear what headers are in use (avoids dups and improves long-term maintenance experience). 2. Makes sure we don't "include everything". This might (slightly) improve the module build time, but also shows that we use what we use. There are patches in the history of the Linux kernel for both scenarios in C files (yes, for the h files such a change is much more important). ... TBH, the driver is written in a bad style, it has so-o-o many issues, I even don't know where to start... Oh, wait. -- With Best Regards, Andy Shevchenko