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;
Received-SPF: Pass (esa5.microchip.iphmx.com: domain of
  Eugen.Hristev@microchip.com designates 198.175.253.82 as
  permitted sender) identity=mailfrom;
  client-ip=198.175.253.82; receiver=esa5.microchip.iphmx.com;
  envelope-from="Eugen.Hristev@microchip.com";
  x-sender="Eugen.Hristev@microchip.com";
  x-conformance=spf_only; x-record-type="v=spf1";
  x-record-text="v=spf1 mx a:ushub1.microchip.com
  a:smtpout.microchip.com a:mx1.microchip.iphmx.com
  a:mx2.microchip.iphmx.com include:servers.mcsv.net
  include:mktomail.com include:spf.protection.outlook.com ~all"
Received-SPF: None (esa5.microchip.iphmx.com: no sender
  authenticity information available from domain of
  postmaster@email.microchip.com) identity=helo;
  client-ip=198.175.253.82; receiver=esa5.microchip.iphmx.com;
  envelope-from="Eugen.Hristev@microchip.com";
  x-sender="postmaster@email.microchip.com";
  x-conformance=spf_only
IronPort-SDR: yPTd4nFNtCbQrkRPlEaLQRzDVDetN/j1uINpTJcr7CP5ISmZDtYnSJbUUyRDgCahRxUN+uSWeO
 4Jj47QPFfHCgrqsjq/k/b04Mr6nt4eSjoWPrWrY8MLHzQm0nRN8HjGaqad6WhZYv1KBN5vbMx3
 4+YMZuyEZPMLfPN831a9o3CwYC8a8HFbgUQ5iRbGllT8/nIM21k2QOIjkxl84LExNBcvO0dm5v
 FJaM7LvamlLX+3Ne8l5HJ/oXVJZXkvxNiWZGCvkMXBnOQCPZv2GCnMGc8Mfdm4NMl6pX5E92f5
 Jik=
From:   <Eugen.Hristev@microchip.com>
To:     <wsa@the-dreams.de>
CC:     <mark.rutland@arm.com>, <devicetree@vger.kernel.org>,
        <alexandre.belloni@bootlin.com>, <linux-kernel@vger.kernel.org>,
        <pierre-yves.mordret@st.com>, <Ludovic.Desroches@microchip.com>,
        <robh+dt@kernel.org>, <linux-i2c@vger.kernel.org>,
        <peda@axentia.se>, <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 5/9] i2c: at91: add support for digital filtering
Thread-Topic: [PATCH v3 5/9] i2c: at91: add support for digital filtering
Thread-Index: AQHVNlj4SZXsGDZbFke7Py4QXQ+nT6cVfjQAgAABUYCAAuouAA==
Date:   Mon, 2 Sep 2019 08:54:06 +0000
Message-ID: <d461426b-50ac-bf6c-79e0-71e17a63400e@microchip.com>
References: <1562678049-17581-1-git-send-email-eugen.hristev@microchip.com>
 <1562678049-17581-6-git-send-email-eugen.hristev@microchip.com>
 <20190831121308.GB1032@ninjato> <20190831121751.GC1032@ninjato>
In-Reply-To: <20190831121751.GC1032@ninjato>
Accept-Language: en-US, ro-RO
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tagtoolbar-keys: D20190902114832939
x-originating-ip: [94.177.32.156]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: daf65498-9809-45ba-d170-08d72f831c77
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020);SRVR:DM5PR11MB1930;
x-ms-traffictypediagnostic: DM5PR11MB1930:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM5PR11MB19309F9F45FF2F21FC18A730E8BE0@DM5PR11MB1930.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01480965DA
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(136003)(396003)(346002)(366004)(39860400002)(376002)(199004)(189003)(86362001)(14454004)(31686004)(478600001)(99286004)(66476007)(66556008)(64756008)(66446008)(476003)(53936002)(52116002)(102836004)(81156014)(81166006)(6486002)(966005)(31696002)(6306002)(25786009)(66946007)(76176011)(6916009)(7416002)(2906002)(8676002)(53546011)(6512007)(486006)(6436002)(446003)(305945005)(7736002)(386003)(4326008)(8936002)(2616005)(11346002)(6506007)(229853002)(256004)(6246003)(54906003)(316002)(66066001)(5660300002)(186003)(36756003)(6116002)(71190400001)(71200400001)(3846002)(26005);DIR:OUT;SFP:1101;SCL:1;SRVR:DM5PR11MB1930;H:DM5PR11MB1242.namprd11.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
received-spf: None (protection.outlook.com: microchip.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: MrfrATZwObVjzjVRwgPkkOObfOPDyrLMNVptsA8ejW3NksHDGi9LFhgheFMsy9RG3tDK0iVrK4dqMHfPdSrovBMAz150jJt5eTmbIRqhAvMLdYA6O3gc9OdIHbwLdEOK5P/6ncu7OKjFK/3WPhs2B0jWU5CiHvzM2YolLjxx/oNlERJFS5VUyDBsFTnNZ8NNi7I9bG3BoECaby+6FrbxHUyjvLo2JpyD2EHx/iFcfuNS2m89+O7yXO7m1ivQTSORjzkN5Y9OQB5JmpqZd1DQ0DLRdL+UsaAkmwm3i6tRgircBIOfrzoDRMyeTehtrQuv+sONU0f0jxsnLZSfOIRIk3zNqF7HWYV/pjOi+7fP+wUT5hXwttxMF8CC39L7EIljPVUltDr+ZVxNtr9SOe0/YSULY3kzHOD7nmE0xNShRQc=
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <6F1F9E0097244B4784028B912D065ADD@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: daf65498-9809-45ba-d170-08d72f831c77
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2019 08:54:06.3559
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: eN90fKVx81vqltFaisoCbiMue76A4Xq4yaVnG/165Pn4/h6bwZqWuUTQKomfKO/sk+bYo27Owgcac19gMwp8gctl/xE0ENzRMnKH0FQROGs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1930
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 31.08.2019 15:17, Wolfram Sang wrote:
>=20
>>> +	dev->enable_dig_filt =3D of_property_read_bool(pdev->dev.of_node,
>>> +						     "i2c-dig-filter");
>>> +
>>
>> What do you think of the idea to introduce 'flags' to struct i2c_timings
>> and parse the bindings in the core, too? Then you'd have sth like:
>>
>> 	if (t->flags & I2C_TIMINGS_ANALOG_FILTER)
>>
>> Would that be useful for you?
>=20
> Forgot to say, we can also implement this incrementally to make sure
> your patches land in 5.4 in case you are currently busy with sth else.
>=20

Hi Wolfram,

Your idea looks good but I would prefer to have it as a separate=20
enhancement patch, after this series gets in.
As things are now, this series/patches do just the filtering part. We=20
can then move all the optional 'flags' as another change.
So yes, we can do this incrementally.

Thanks !
Eugen

>=20
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>=20