Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp91314ybl; Mon, 27 Jan 2020 22:56:49 -0800 (PST) X-Google-Smtp-Source: APXvYqw+uXQDJJe92Yr5mEHskCTRhmm4tAv0KXrNwIK1AjJ045+iZQY7vYO2ntHUHf0uxWrZCvYm X-Received: by 2002:aca:50cd:: with SMTP id e196mr1923652oib.178.1580194609433; Mon, 27 Jan 2020 22:56:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580194609; cv=none; d=google.com; s=arc-20160816; b=IIp7/yadTBGIgJOqKyGHEHQIEawrr99J+gOh8uQVsV595ioYVCdXwHp7uoN5GTUrFS 1TONfJKRrA/JB1lyX15xGWUxxlhSC3GZjxCodzdm24PLAQb9Lxw4WbuCgCa6VWGe59KS DqvdsaNTin/n9+vqbSI9qymxPwMpPEdzpypLBLiqlEd+Z8bqr+JbHm+ztAiqS2hav9/U 6ugt+i7kOr5OXmW5OxbOFOI8Fz3itcVVjCrvwNBiu7Kg/gNMp1NW0Xeya8OY4aqwtqeH v6h67AGlmXzWvRrd6IH5LFpzGQ4fWj4/Rj+JbD84c+KFfUGsoamh1F/CBYyL8i7/8jM1 TKvg== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=V92tIA+Ofd6KyiLCdlOUyV5e8ide3S8GY6AmG9je2Mw=; b=0Wxh370eIFI2CgXvC+E80YCjBUXLxnfmuU71svic0G1R+A5cMwrzY8T4K9+4/qlJME zLkiNDxAnGzGfX4tR8umgv/dsWozRsQkR37B5NbENYNDAfQiPcu9LXjivwTbcLFEDzXT dqJA+X9z7QLBny/ntnNCyxdITMREgNI/bjbpm2+jrbXHBCXqSlKB3bF7ULV8amKvK3bC dXFQFv6XFP8xC6OWMTd6m/WWIig1Va/HrOQXeLBFCeKTgcfiDorQDsS8cBCtU4tFMvqI O9Inl+D3SKwCQ3fWeUEHQ2ix8VveAZk5RNAxqZg2Y9FK5LhD/jT7yYFoK4wToulmcHIn 9tuA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z18si8716113otq.121.2020.01.27.22.56.19; Mon, 27 Jan 2020 22:56:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725829AbgA1GyW (ORCPT + 99 others); Tue, 28 Jan 2020 01:54:22 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:40264 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725776AbgA1GyW (ORCPT ); Tue, 28 Jan 2020 01:54:22 -0500 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id BBFC12852C3; Tue, 28 Jan 2020 06:54:20 +0000 (GMT) Date: Tue, 28 Jan 2020 07:54:17 +0100 From: Boris Brezillon To: Miquel Raynal Cc: Yoshio Furuyama , Richard Weinberger , linux-mtd@lists.infradead.org, vigneshr@ti.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mtd: nand: Rename Toshiba Memory to Kioxia Message-ID: <20200128075417.0fb68e10@collabora.com> In-Reply-To: <20200127165148.1f8ef0f7@xps13> References: <1579766643-4983-1-git-send-email-ytc-mb-yfuruyama7@kioxia.com> <20200127165148.1f8ef0f7@xps13> Organization: Collabora X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 27 Jan 2020 16:51:48 +0100 Miquel Raynal wrote: > Hi Yoshio, > > Yoshio Furuyama wrote on Thu, 23 Jan > 2020 17:04:03 +0900: > > > Rename Toshiba Memory to Kioxia since the company name has changed. > > I wonder how much this is a noisy change compared to its benefits > > I would like more feedback. Richard, Boris, is this the first name we > run into this situation? Ho was this handled in the past? I don't think that's really useful. Maybe just add a comment above the NAND_MFR_TOSHIBA definition stating that Toshiba and Kioxia ID are the same. If Koxia starts producing new chip under the Koxia brand, new files/structs/funcs/... can be prefixed with koxia instead of Toshiba.