From mboxrd@z Thu Jan 1 00:00:00 1970 From: jbrunet@baylibre.com (Jerome Brunet) Date: Wed, 30 Nov 2016 10:47:26 +0100 Subject: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue In-Reply-To: <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com> References: <1480348229-25672-1-git-send-email-jbrunet@baylibre.com> <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com> Message-ID: <1480499246.17538.208.camel@baylibre.com> To: linus-amlogic@lists.infradead.org List-Id: linus-amlogic.lists.infradead.org On Mon, 2016-11-28 at 09:54 -0800, Florian Fainelli wrote: > On 11/28/2016 07:50 AM, Jerome Brunet wrote: > > > > This patchset fixes an issue with the OdroidC2 board (DWMAC + > > RTL8211F). > > The platform seems to enter LPI on the Rx path too often while > > performing > > relatively high TX transfer. This eventually break the link (both > > Tx and > > Rx), and require to bring the interface down and up again to get > > the Rx > > path working again. > > > > The root cause of this issue is not fully understood yet but > > disabling EEE > > advertisement on the PHY prevent this feature to be negotiated. > > With this change, the link is stable and reliable, with the > > expected > > throughput performance. > > > > The patchset adds options in the generic phy driver to disable EEE > > advertisement, through device tree. The way it is done is very > > similar > > to the handling of the max-speed property. > > > > Patch 4 is provided here for testing purpose only. Please don't > > merge > > patch 4, this change will go through the amlogic's tree. > > Sorry, but I really don't like the route this is going, and I should > have made myself clearer before on that, I really think utilizing a > PHY > fixup is more appropriate here than an extremely generic DT property. > The fixup code can be in the affected PHY driver, or it can be > somewhere > else, your call. There is no shortage of option on how to implement > it, > and this would be something easy to enable/disable for known good > configurations (ala PCI/USB fixups). > > If we start supporting generic "enable", "disable" type of properties > with values that map directly to register definitions of the HW, we > leave too much room for these properties to be utilized to implement > a > specific policy, and this is not acceptable. Florian,? I agree that DT should not be used to setup a policy, but to describe what the HW is. I tried to implement it the way you suggested, using phy fixup, too see what it looks like. There is 2 places in the code that seems (remotely) linked to the issue:? - meson8b_dwmac driver : if the mac, regardless of the board/platform, ?could not tolerate to have EEE activated, it would make sense to have the fixup here. It can provide a C callback for such case. - realtek phy driver: philosophy is kind of the same To be clear, it is doable and it works that way, but I don't think embedding this directly in the code is the right way to do it. It seems we are hiding an information specific about the board inside a generic driver. We have several amlogic's design with the same MAC, sometimes with the same PHY, which have no problem with EEE at all. The issue is really about the board design. What I propose is not an enable/disable configuration switch, but to clearly state that a particular mode of operation is broken. Like the "max-speed" property, it setup a restriction. IMO, this is a description of what the HW is and is capable of, and as such it should be part of the DT. Yes the property directly map to a register, but it does let you directly manipulate it (you can't pass the value you want to write in the register). Having it this way just makes the code simple on both ends (user and driver). Yes people could start abusing this to setup policy. In the end, it is our responsibility, as community, to make sure APIs are used in a proper way, and not let it be used that way. I'm open to suggestion on how improve the solution, maybe something which could bring more confidence that property won't be misused. Jerome From mboxrd@z Thu Jan 1 00:00:00 1970 From: jbrunet@baylibre.com (Jerome Brunet) Date: Wed, 30 Nov 2016 10:47:26 +0100 Subject: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue In-Reply-To: <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com> References: <1480348229-25672-1-git-send-email-jbrunet@baylibre.com> <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com> Message-ID: <1480499246.17538.208.camel@baylibre.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 2016-11-28 at 09:54 -0800, Florian Fainelli wrote: > On 11/28/2016 07:50 AM, Jerome Brunet wrote: > > > > This patchset fixes an issue with the OdroidC2 board (DWMAC + > > RTL8211F). > > The platform seems to enter LPI on the Rx path too often while > > performing > > relatively high TX transfer. This eventually break the link (both > > Tx and > > Rx), and require to bring the interface down and up again to get > > the Rx > > path working again. > > > > The root cause of this issue is not fully understood yet but > > disabling EEE > > advertisement on the PHY prevent this feature to be negotiated. > > With this change, the link is stable and reliable, with the > > expected > > throughput performance. > > > > The patchset adds options in the generic phy driver to disable EEE > > advertisement, through device tree. The way it is done is very > > similar > > to the handling of the max-speed property. > > > > Patch 4 is provided here for testing purpose only. Please don't > > merge > > patch 4, this change will go through the amlogic's tree. > > Sorry, but I really don't like the route this is going, and I should > have made myself clearer before on that, I really think utilizing a > PHY > fixup is more appropriate here than an extremely generic DT property. > The fixup code can be in the affected PHY driver, or it can be > somewhere > else, your call. There is no shortage of option on how to implement > it, > and this would be something easy to enable/disable for known good > configurations (ala PCI/USB fixups). > > If we start supporting generic "enable", "disable" type of properties > with values that map directly to register definitions of the HW, we > leave too much room for these properties to be utilized to implement > a > specific policy, and this is not acceptable. Florian,? I agree that DT should not be used to setup a policy, but to describe what the HW is. I tried to implement it the way you suggested, using phy fixup, too see what it looks like. There is 2 places in the code that seems (remotely) linked to the issue:? - meson8b_dwmac driver : if the mac, regardless of the board/platform, ?could not tolerate to have EEE activated, it would make sense to have the fixup here. It can provide a C callback for such case. - realtek phy driver: philosophy is kind of the same To be clear, it is doable and it works that way, but I don't think embedding this directly in the code is the right way to do it. It seems we are hiding an information specific about the board inside a generic driver. We have several amlogic's design with the same MAC, sometimes with the same PHY, which have no problem with EEE at all. The issue is really about the board design. What I propose is not an enable/disable configuration switch, but to clearly state that a particular mode of operation is broken. Like the "max-speed" property, it setup a restriction. IMO, this is a description of what the HW is and is capable of, and as such it should be part of the DT. Yes the property directly map to a register, but it does let you directly manipulate it (you can't pass the value you want to write in the register). Having it this way just makes the code simple on both ends (user and driver). Yes people could start abusing this to setup policy. In the end, it is our responsibility, as community, to make sure APIs are used in a proper way, and not let it be used that way. I'm open to suggestion on how improve the solution, maybe something which could bring more confidence that property won't be misused. Jerome From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome Brunet Subject: Re: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue Date: Wed, 30 Nov 2016 10:47:26 +0100 Message-ID: <1480499246.17538.208.camel@baylibre.com> References: <1480348229-25672-1-git-send-email-jbrunet@baylibre.com> <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Florian Fainelli , netdev@vger.kernel.org, devicetree@vger.kernel.org Cc: Andrew Lunn , Alexandre TORGUE , Neil Armstrong , Martin Blumenstingl , Kevin Hilman , linux-kernel@vger.kernel.org, Yegor Yefremov , Julia Lawall , Andre Roth , linux-amlogic@lists.infradead.org, Carlo Caione , Giuseppe Cavallaro , Andreas =?ISO-8859-1?Q?F=E4rber?= , linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org T24gTW9uLCAyMDE2LTExLTI4IGF0IDA5OjU0IC0wODAwLCBGbG9yaWFuIEZhaW5lbGxpIHdyb3Rl Ogo+IE9uIDExLzI4LzIwMTYgMDc6NTAgQU0sIEplcm9tZSBCcnVuZXQgd3JvdGU6Cj4gPiAKPiA+ IFRoaXMgcGF0Y2hzZXQgZml4ZXMgYW4gaXNzdWUgd2l0aCB0aGUgT2Ryb2lkQzIgYm9hcmQgKERX TUFDICsKPiA+IFJUTDgyMTFGKS4KPiA+IFRoZSBwbGF0Zm9ybSBzZWVtcyB0byBlbnRlciBMUEkg b24gdGhlIFJ4IHBhdGggdG9vIG9mdGVuIHdoaWxlCj4gPiBwZXJmb3JtaW5nCj4gPiByZWxhdGl2 ZWx5IGhpZ2ggVFggdHJhbnNmZXIuIFRoaXMgZXZlbnR1YWxseSBicmVhayB0aGUgbGluayAoYm90 aAo+ID4gVHggYW5kCj4gPiBSeCksIGFuZCByZXF1aXJlIHRvIGJyaW5nIHRoZSBpbnRlcmZhY2Ug ZG93biBhbmQgdXAgYWdhaW4gdG8gZ2V0Cj4gPiB0aGUgUngKPiA+IHBhdGggd29ya2luZyBhZ2Fp bi4KPiA+IAo+ID4gVGhlIHJvb3QgY2F1c2Ugb2YgdGhpcyBpc3N1ZSBpcyBub3QgZnVsbHkgdW5k ZXJzdG9vZCB5ZXQgYnV0Cj4gPiBkaXNhYmxpbmcgRUVFCj4gPiBhZHZlcnRpc2VtZW50IG9uIHRo ZSBQSFkgcHJldmVudCB0aGlzIGZlYXR1cmUgdG8gYmUgbmVnb3RpYXRlZC4KPiA+IFdpdGggdGhp cyBjaGFuZ2UsIHRoZSBsaW5rIGlzIHN0YWJsZSBhbmQgcmVsaWFibGUsIHdpdGggdGhlCj4gPiBl eHBlY3RlZAo+ID4gdGhyb3VnaHB1dCBwZXJmb3JtYW5jZS4KPiA+IAo+ID4gVGhlIHBhdGNoc2V0 IGFkZHMgb3B0aW9ucyBpbiB0aGUgZ2VuZXJpYyBwaHkgZHJpdmVyIHRvIGRpc2FibGUgRUVFCj4g PiBhZHZlcnRpc2VtZW50LCB0aHJvdWdoIGRldmljZSB0cmVlLiBUaGUgd2F5IGl0IGlzIGRvbmUg aXMgdmVyeQo+ID4gc2ltaWxhcgo+ID4gdG8gdGhlIGhhbmRsaW5nIG9mIHRoZSBtYXgtc3BlZWQg cHJvcGVydHkuCj4gPiAKPiA+IFBhdGNoIDQgaXMgcHJvdmlkZWQgaGVyZSBmb3IgdGVzdGluZyBw dXJwb3NlIG9ubHkuIFBsZWFzZSBkb24ndAo+ID4gbWVyZ2UKPiA+IHBhdGNoIDQsIHRoaXMgY2hh bmdlIHdpbGwgZ28gdGhyb3VnaCB0aGUgYW1sb2dpYydzIHRyZWUuCj4gCj4gU29ycnksIGJ1dCBJ IHJlYWxseSBkb24ndCBsaWtlIHRoZSByb3V0ZSB0aGlzIGlzIGdvaW5nLCBhbmQgSSBzaG91bGQK PiBoYXZlIG1hZGUgbXlzZWxmIGNsZWFyZXIgYmVmb3JlIG9uIHRoYXQsIEkgcmVhbGx5IHRoaW5r IHV0aWxpemluZyBhCj4gUEhZCj4gZml4dXAgaXMgbW9yZSBhcHByb3ByaWF0ZSBoZXJlIHRoYW4g YW4gZXh0cmVtZWx5IGdlbmVyaWMgRFQgcHJvcGVydHkuCj4gVGhlIGZpeHVwIGNvZGUgY2FuIGJl IGluIHRoZSBhZmZlY3RlZCBQSFkgZHJpdmVyLCBvciBpdCBjYW4gYmUKPiBzb21ld2hlcmUKPiBl bHNlLCB5b3VyIGNhbGwuIFRoZXJlIGlzIG5vIHNob3J0YWdlIG9mIG9wdGlvbiBvbiBob3cgdG8g aW1wbGVtZW50Cj4gaXQsCj4gYW5kIHRoaXMgd291bGQgYmUgc29tZXRoaW5nIGVhc3kgdG8gZW5h YmxlL2Rpc2FibGUgZm9yIGtub3duIGdvb2QKPiBjb25maWd1cmF0aW9ucyAoYWxhIFBDSS9VU0Ig Zml4dXBzKS4KPiAKPiBJZiB3ZSBzdGFydCBzdXBwb3J0aW5nIGdlbmVyaWMgImVuYWJsZSIsICJk aXNhYmxlIiB0eXBlIG9mIHByb3BlcnRpZXMKPiB3aXRoIHZhbHVlcyB0aGF0IG1hcCBkaXJlY3Rs eSB0byByZWdpc3RlciBkZWZpbml0aW9ucyBvZiB0aGUgSFcsIHdlCj4gbGVhdmUgdG9vIG11Y2gg cm9vbSBmb3IgdGhlc2UgcHJvcGVydGllcyB0byBiZSB1dGlsaXplZCB0byBpbXBsZW1lbnQKPiBh Cj4gc3BlY2lmaWMgcG9saWN5LCBhbmQgdGhpcyBpcyBub3QgYWNjZXB0YWJsZS4KCkZsb3JpYW4s wqAKCkkgYWdyZWUgdGhhdCBEVCBzaG91bGQgbm90IGJlIHVzZWQgdG8gc2V0dXAgYSBwb2xpY3ks IGJ1dCB0byBkZXNjcmliZQp3aGF0IHRoZSBIVyBpcy4KCkkgdHJpZWQgdG8gaW1wbGVtZW50IGl0 IHRoZSB3YXkgeW91IHN1Z2dlc3RlZCwgdXNpbmcgcGh5IGZpeHVwLCB0b28gc2VlCndoYXQgaXQg bG9va3MgbGlrZS4KVGhlcmUgaXMgMiBwbGFjZXMgaW4gdGhlIGNvZGUgdGhhdCBzZWVtcyAocmVt b3RlbHkpIGxpbmtlZCB0byB0aGUKaXNzdWU6wqAKLSBtZXNvbjhiX2R3bWFjIGRyaXZlciA6IGlm IHRoZSBtYWMsIHJlZ2FyZGxlc3Mgb2YgdGhlIGJvYXJkL3BsYXRmb3JtLArCoGNvdWxkIG5vdCB0 b2xlcmF0ZSB0byBoYXZlIEVFRSBhY3RpdmF0ZWQsIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gaGF2 ZQp0aGUgZml4dXAgaGVyZS4gSXQgY2FuIHByb3ZpZGUgYSBDIGNhbGxiYWNrIGZvciBzdWNoIGNh c2UuCi0gcmVhbHRlayBwaHkgZHJpdmVyOiBwaGlsb3NvcGh5IGlzIGtpbmQgb2YgdGhlIHNhbWUK ClRvIGJlIGNsZWFyLCBpdCBpcyBkb2FibGUgYW5kIGl0IHdvcmtzIHRoYXQgd2F5LCBidXQgSSBk b24ndCB0aGluawplbWJlZGRpbmcgdGhpcyBkaXJlY3RseSBpbiB0aGUgY29kZSBpcyB0aGUgcmln aHQgd2F5IHRvIGRvIGl0LiBJdCBzZWVtcwp3ZSBhcmUgaGlkaW5nIGFuIGluZm9ybWF0aW9uIHNw ZWNpZmljIGFib3V0IHRoZSBib2FyZCBpbnNpZGUgYSBnZW5lcmljCmRyaXZlci4KCldlIGhhdmUg c2V2ZXJhbCBhbWxvZ2ljJ3MgZGVzaWduIHdpdGggdGhlIHNhbWUgTUFDLCBzb21ldGltZXMgd2l0 aCB0aGUKc2FtZSBQSFksIHdoaWNoIGhhdmUgbm8gcHJvYmxlbSB3aXRoIEVFRSBhdCBhbGwuIFRo ZSBpc3N1ZSBpcyByZWFsbHkKYWJvdXQgdGhlIGJvYXJkIGRlc2lnbi4KCldoYXQgSSBwcm9wb3Nl IGlzIG5vdCBhbiBlbmFibGUvZGlzYWJsZSBjb25maWd1cmF0aW9uIHN3aXRjaCwgYnV0IHRvCmNs ZWFybHkgc3RhdGUgdGhhdCBhIHBhcnRpY3VsYXIgbW9kZSBvZiBvcGVyYXRpb24gaXMgYnJva2Vu LiBMaWtlIHRoZQoibWF4LXNwZWVkIiBwcm9wZXJ0eSwgaXQgc2V0dXAgYSByZXN0cmljdGlvbi4g SU1PLCB0aGlzIGlzIGEKZGVzY3JpcHRpb24gb2Ygd2hhdCB0aGUgSFcgaXMgYW5kIGlzIGNhcGFi bGUgb2YsIGFuZCBhcyBzdWNoIGl0IHNob3VsZApiZSBwYXJ0IG9mIHRoZSBEVC4KClllcyB0aGUg cHJvcGVydHkgZGlyZWN0bHkgbWFwIHRvIGEgcmVnaXN0ZXIsIGJ1dCBpdCBkb2VzIGxldCB5b3UK ZGlyZWN0bHkgbWFuaXB1bGF0ZSBpdCAoeW91IGNhbid0IHBhc3MgdGhlIHZhbHVlIHlvdSB3YW50 IHRvIHdyaXRlIGluCnRoZSByZWdpc3RlcikuIEhhdmluZyBpdCB0aGlzIHdheSBqdXN0IG1ha2Vz IHRoZSBjb2RlIHNpbXBsZSBvbiBib3RoCmVuZHMgKHVzZXIgYW5kIGRyaXZlcikuCgpZZXMgcGVv cGxlIGNvdWxkIHN0YXJ0IGFidXNpbmcgdGhpcyB0byBzZXR1cCBwb2xpY3kuIEluIHRoZSBlbmQs IGl0IGlzCm91ciByZXNwb25zaWJpbGl0eSwgYXMgY29tbXVuaXR5LCB0byBtYWtlIHN1cmUgQVBJ cyBhcmUgdXNlZCBpbiBhCnByb3BlciB3YXksIGFuZCBub3QgbGV0IGl0IGJlIHVzZWQgdGhhdCB3 YXkuCgpJJ20gb3BlbiB0byBzdWdnZXN0aW9uIG9uIGhvdyBpbXByb3ZlIHRoZSBzb2x1dGlvbiwg bWF5YmUgc29tZXRoaW5nCndoaWNoIGNvdWxkIGJyaW5nIG1vcmUgY29uZmlkZW5jZSB0aGF0IHBy b3BlcnR5IHdvbid0IGJlIG1pc3VzZWQuCgpKZXJvbWUKCgoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QK bGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRl YWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933423AbcK3Jso (ORCPT ); Wed, 30 Nov 2016 04:48:44 -0500 Received: from mail-wj0-f174.google.com ([209.85.210.174]:36365 "EHLO mail-wj0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753936AbcK3Jr3 (ORCPT ); Wed, 30 Nov 2016 04:47:29 -0500 Message-ID: <1480499246.17538.208.camel@baylibre.com> Subject: Re: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue From: Jerome Brunet To: Florian Fainelli , netdev@vger.kernel.org, devicetree@vger.kernel.org Cc: Carlo Caione , Kevin Hilman , Giuseppe Cavallaro , Alexandre TORGUE , Martin Blumenstingl , Andre Roth , Andrew Lunn , Neil Armstrong , linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Julia Lawall , Yegor Yefremov , Andreas =?ISO-8859-1?Q?F=E4rber?= Date: Wed, 30 Nov 2016 10:47:26 +0100 In-Reply-To: <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com> References: <1480348229-25672-1-git-send-email-jbrunet@baylibre.com> <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2016-11-28 at 09:54 -0800, Florian Fainelli wrote: > On 11/28/2016 07:50 AM, Jerome Brunet wrote: > > > > This patchset fixes an issue with the OdroidC2 board (DWMAC + > > RTL8211F). > > The platform seems to enter LPI on the Rx path too often while > > performing > > relatively high TX transfer. This eventually break the link (both > > Tx and > > Rx), and require to bring the interface down and up again to get > > the Rx > > path working again. > > > > The root cause of this issue is not fully understood yet but > > disabling EEE > > advertisement on the PHY prevent this feature to be negotiated. > > With this change, the link is stable and reliable, with the > > expected > > throughput performance. > > > > The patchset adds options in the generic phy driver to disable EEE > > advertisement, through device tree. The way it is done is very > > similar > > to the handling of the max-speed property. > > > > Patch 4 is provided here for testing purpose only. Please don't > > merge > > patch 4, this change will go through the amlogic's tree. > > Sorry, but I really don't like the route this is going, and I should > have made myself clearer before on that, I really think utilizing a > PHY > fixup is more appropriate here than an extremely generic DT property. > The fixup code can be in the affected PHY driver, or it can be > somewhere > else, your call. There is no shortage of option on how to implement > it, > and this would be something easy to enable/disable for known good > configurations (ala PCI/USB fixups). > > If we start supporting generic "enable", "disable" type of properties > with values that map directly to register definitions of the HW, we > leave too much room for these properties to be utilized to implement > a > specific policy, and this is not acceptable. Florian,  I agree that DT should not be used to setup a policy, but to describe what the HW is. I tried to implement it the way you suggested, using phy fixup, too see what it looks like. There is 2 places in the code that seems (remotely) linked to the issue:  - meson8b_dwmac driver : if the mac, regardless of the board/platform,  could not tolerate to have EEE activated, it would make sense to have the fixup here. It can provide a C callback for such case. - realtek phy driver: philosophy is kind of the same To be clear, it is doable and it works that way, but I don't think embedding this directly in the code is the right way to do it. It seems we are hiding an information specific about the board inside a generic driver. We have several amlogic's design with the same MAC, sometimes with the same PHY, which have no problem with EEE at all. The issue is really about the board design. What I propose is not an enable/disable configuration switch, but to clearly state that a particular mode of operation is broken. Like the "max-speed" property, it setup a restriction. IMO, this is a description of what the HW is and is capable of, and as such it should be part of the DT. Yes the property directly map to a register, but it does let you directly manipulate it (you can't pass the value you want to write in the register). Having it this way just makes the code simple on both ends (user and driver). Yes people could start abusing this to setup policy. In the end, it is our responsibility, as community, to make sure APIs are used in a proper way, and not let it be used that way. I'm open to suggestion on how improve the solution, maybe something which could bring more confidence that property won't be misused. Jerome