From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Jones Subject: Re: [STLinux Kernel] [PATCH 3/8] serial: st-asc: Read in all Pinctrl states Date: Tue, 31 Jan 2017 10:13:56 +0000 Message-ID: <20170131101356.bpg5hamkfgprdbpt@dell> References: <20170124134310.27512-1-lee.jones@linaro.org> <20170124134310.27512-4-lee.jones@linaro.org> <20170125112142.GE5680@griffinp-ThinkPad-X1-Carbon-2nd> <20170127115458.k4edg42nnna3bv4v@dell> <20170130142356.GA18710@griffinp-ThinkPad-X1-Carbon-2nd> <20170130153211.j75qemvwsq3cwqve@dell> <20170130161041.GA21001@griffinp-ThinkPad-X1-Carbon-2nd> <20170130191159.zv5jegvu4fetcmzo@dell> <20170130223521.GA12847@griffinp-ThinkPad-X1-Carbon-2nd> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20170130223521.GA12847@griffinp-ThinkPad-X1-Carbon-2nd> 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: Peter Griffin Cc: devicetree@vger.kernel.org, kernel@stlinux.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, linux-serial@vger.kernel.org, jslaby@suse.com, linux-arm-kernel@lists.infradead.org List-Id: linux-serial@vger.kernel.org T24gTW9uLCAzMCBKYW4gMjAxNywgUGV0ZXIgR3JpZmZpbiB3cm90ZToKPiBPbiBNb24sIDMwIEph biAyMDE3LCBMZWUgSm9uZXMgd3JvdGU6Cj4gPiBPbiBNb24sIDMwIEphbiAyMDE3LCBQZXRlciBH cmlmZmluIHdyb3RlOgo+ID4gPiBPbiBNb24sIDMwIEphbiAyMDE3LCBMZWUgSm9uZXMgd3JvdGU6 Cj4gPiA+ID4gT24gTW9uLCAzMCBKYW4gMjAxNywgUGV0ZXIgR3JpZmZpbiB3cm90ZToKPiA+ID4g PiA+IE9uIEZyaSwgMjcgSmFuIDIwMTcsIExlZSBKb25lcyB3cm90ZToKPiA+ID4gPiA+ID4gT24g V2VkLCAyNSBKYW4gMjAxNywgUGV0ZXIgR3JpZmZpbiB3cm90ZToKPiA+ID4gPiA+ID4gPiBPbiBU dWUsIDI0IEphbiAyMDE3LCBMZWUgSm9uZXMgd3JvdGU6Cj4gPiA+ID4gPiA+ID4gCj4gPiA+ID4g PiA+ID4gPiBUaGVyZSBhcmUgbm93IDIgcG9zc2libGUgc2VwYXJhdGUvZGlmZmVyZW50IFBpbmN0 cmwgc3RhdGVzIHdoaWNoIGNhbgo+ID4gPiA+ID4gPiA+ID4gYmUgcHJvdmlkZWQgZnJvbSBwbGF0 Zm9ybSBkYXRhLiAgT25lIHdoaWNoIGVuY29tcGFzc2VzIHRoZSBsaW5lcwo+ID4gPiA+ID4gPiA+ ID4gcmVxdWlyZWQgZm9yIEhXIGZsb3ctY29udHJvbCAoQ1RTL1JUUykgYW5kIGFub3RoZXIgd2hp Y2ggZG9lcyBub3QKPiA+ID4gPiA+ID4gPiA+IHNwZWNpZnkgdGhlc2UgbGluZXMsIHN1Y2ggdGhh dCB0aGV5IGNhbiBiZSB1c2VkIHZpYSBHUElPIG1lY2hhbmlzbXMKPiA+ID4gPiA+ID4gPiA+IGZv ciBtYW51YWxseSB0b2dnbGluZyAoaS5lLiBmcm9tIGEgcmVxdWVzdCBieSBgc3R0eWApLgo+ID4g PiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBMZWUgSm9uZXMgPGxl ZS5qb25lc0BsaW5hcm8ub3JnPgo+ID4gPiA+ID4gPiA+ID4gLS0tCj4gPiA+ID4gPiA+ID4gPiAg ZHJpdmVycy90dHkvc2VyaWFsL3N0LWFzYy5jIHwgMjggKysrKysrKysrKysrKysrKysrKysrKysr KysrKwo+ID4gPiA+ID4gPiA+ID4gIDEgZmlsZSBjaGFuZ2VkLCAyOCBpbnNlcnRpb25zKCspCj4g PiA+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3R0eS9z ZXJpYWwvc3QtYXNjLmMgYi9kcml2ZXJzL3R0eS9zZXJpYWwvc3QtYXNjLmMKPiA+ID4gPiA+ID4g PiA+IGluZGV4IDM5N2RmNTAuLjAzODAxZWQgMTAwNjQ0Cj4gPiA+ID4gPiA+ID4gPiAtLS0gYS9k cml2ZXJzL3R0eS9zZXJpYWwvc3QtYXNjLmMKPiA+ID4gPiA+ID4gPiA+ICsrKyBiL2RyaXZlcnMv dHR5L3NlcmlhbC9zdC1hc2MuYwo+ID4gCj4gPiBbLi4uXQo+ID4gCj4gPiA+ID4gPiA+ID4gPiAr CQlwaW5jdHJsX2xvb2t1cF9zdGF0ZShhc2Nwb3J0LT5waW5jdHJsLCAibWFudWFsLXJ0cyIpOwo+ ID4gPiA+ID4gPiA+ID4gKwlpZiAoSVNfRVJSKGFzY3BvcnQtPnN0YXRlc1tNQU5VQUxfUlRTXSkp Cj4gPiA+ID4gPiA+ID4gPiArCQlhc2Nwb3J0LT5zdGF0ZXNbTUFOVUFMX1JUU10gPSBOVUxMOwo+ ID4gPiA+ID4gPiA+ID4gKwo+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+IFRoZSBkaWZmZXJl bnQgcGluY3RybCBzdGF0ZXMgbG9va3MgbGlrZSBhIG5lYXQgc29sdXRpb24gdG8gdGhlIHByb2Js ZW0uCj4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gTXkgb25seSBjb25jZXJuIGhlcmUgaXMg dGhhdCAnZGVmYXVsdCcgc3RhdGUgaXMgaW1wbHlpbmcgYSBody1mbG93LWNvbnRyb2wKPiA+ID4g PiA+ID4gPiBwaW5tdXggY29uZmlnLCBhbmQgbWFudWFsLXJ0cyBpcyBpbXBseWluZyB3aGF0IGlz IHRoZSBjdXJyZW50IHVwc3RyZWFtCj4gPiA+ID4gPiA+ID4gJ2RlZmF1bHQnIHBpbm11eCBjb25m aWcuCj4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gV2hpY2ggbWF5YmUgb2sgaWYgeW91IHVw ZGF0ZSBhbGwgdWFydHMsIGJ1dCBjdXJyZW50bHkgb25seSBzZXJpYWwwCj4gPiA+ID4gPiA+ID4g aXMgdXBkYXRlZC4gU28gdGhlIG90aGVyIHVhcnRzIGN1cnJlbnQgJ2RlZmF1bHQnIGlzIGFjdHVh bGx5IHRoZSBzYW1lIGFzIHNlcmlhbDAKPiA+ID4gPiA+ID4gPiAnbWFudWFsLXJ0cycgZ3JvdXBp bmcsIHdoaWNoIGNvbmNlcHR1YWxseSBpcyBvZGQuCj4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ ID4gV291bGQgaXQgbm90IGJlIGJldHRlciB0byBtYWtlICdtYW51YWwtcnRzJyB0aGUgZGVmYXVs dCBzdGF0ZT8gQXMgdGhhdCBhbGlnbnMKPiA+ID4gPiA+ID4gPiB0byB3aGF0IGlzIGN1cnJlbnRs eSBhbHJlYWR5IHRoZSBkZWZhdWx0IGZvciB0aGUgb3RoZXIgVUFSVFM/IEFuZCB0aGVuIG1ha2UK PiA+ID4gPiA+ID4gPiBody1mbG93LWNvbnRyb2wgdGhlIG9wdGlvbmFsIHN0YXRlIGZvciBzZXJp YWwwPwo+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+IFRoYXQgYWxzbyBoYXMgdGhlIGFkdmFu dGFnZSB0aGF0ICdkZWZhdWx0JyBoYXMgdGhlIHNhbWUgbWVhbmluZyB3aXRoIG9sZGVyIERUJ3Mu Cj4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiBUaGUgcmVhc29uIGl0IHdhcyBkb25lIGlzIHRoaXMg d2FzIGJlY2F1c2Ugbm9uZSBvZiB0aGUgb3RoZXIgVUFSVHMKPiA+ID4gPiA+ID4gcmVxdWlyZSAy IHNlcGFyYXRlIFBpbmN0cmwgY29uZmlndXJhdGlvbnMsIG9ubHkgdGhpcyBvbmUuICBNb3Jlb3Zl ciwKPiA+ID4gPiA+ID4gaWYgdGhleSBzdXBwb3J0IFJUUy9DVFMgdGhlbiBJIGJlbGlldmUgdGhh dCB0aGUgbGluZXMgc2hvdWxkIGJlCj4gPiA+ID4gPiA+IGRlZmluZWQgaW4gUGluY3RybC4KPiA+ ID4gPiA+IAo+ID4gPiA+ID4gWWVzIEkgYWdyZWUgd2l0aCB0aGF0Lgo+ID4gPiA+ID4gCj4gPiA+ ID4gPiA+IFRodXMsIGl0IHdhcyBteSBwbGFuIHRvIHVwZGF0ZSBhbGwgVUFSVCdzIGRlZmF1bHQK PiA+ID4gPiA+ID4gUGluY3RybCBjb25maWdzIHRvIGluY2x1ZGUgdGhlIFJUUy9DVFMgbGluZXMu Cj4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gCj4gPiA+ID4gPiBJIHN0aWxsIGRvbid0IHNlZSB0aGUg cG9pbnQgaW4gY2hhbmdpbmcgdGhlIG1lYW5pbmcgb2YgJ2RlZmF1bHQnIGdyb3VwIGFuZCBicmVh a2luZwo+ID4gPiA+ID4gQUJJIGlmIHlvdSBkb24ndCBuZWVkIHRvPwo+ID4gPiA+ID4gCj4gPiA+ ID4gPiBBcyBmYXIgYXMgSSBjYW4gdGVsbCBpZiB5b3Ugc3dhcCB0aGUgbWVhbmluZyBvZiAnZGVm YXVsdCcgYW5kICdtYXVuYWwtcnRzJwo+ID4gPiA+ID4gZ3JvdXBzIHlvdSBnZXQgYWxsIHRoZSBi ZW5lZml0cyBvZiB0aGlzIHNlcmllcyB3aGlsc3QgYWxzbyBtYWludGFpbmluZyBiYWNrd2FyZHMK PiA+ID4gPiA+IGNvbXBhdGJpbGl0eSB3aXRoIG9sZGVyIERUJ3MuCj4gPiA+ID4gCj4gPiA+ID4g V2hhdCBtYWtlcyB5b3UgdGhpbmsgdGhpcyB3aWxsIGJyZWFrIEFCST8KPiA+ID4gCj4gPiA+IEkn dmUgbm90IHRyaWVkIGl0LCBidXQgYW4gb2xkZXIgRFQgZGVmaW5lcyBvbmUgZ3JvdXAsICdkZWZh dWx0JyB3aGljaCBjb250YWlucwo+ID4gPiB0aGUgc2FtZSBwaW4gY29uZmlnIGFzIHlvdXIgbmV3 IG9wdGlvbmFsICdtYW51YWwtcnRzJyBncm91cC4KPiA+ID4gCj4gPiA+IFRoZSBkcml2ZXIgbm93 IHJlYWRzIGxpa2UgdGhlIG1hbnVhbC1ydHMgcGluIGNvbmZpZyBpcyBvcHRpb25hbCBhbmQgc2hv dWxkIGJlIHN0b3JlZCBpbgo+ID4gPiBhc2Nwb3J0LT5zdGF0ZXNbTUFOVUFMX1JUU10uIEFuIG9s ZGVyIERUIHdpbGwgcGFzcyB0aGF0IHNhbWUgcGluIGNvbmZpZyBhcyB0aGUgZGVmYXVsdAo+ID4g PiBncm91cCBhbmQgaXQgd2lsbCBiZSBzdG9yZWQgaW4gYXNjcG9ydC0+c3RhdGVzW0RFRkFVTFRd Lgo+ID4gPiAKPiA+ID4gVGhhdCBzZWVtcyB3cm9uZyB0byBtZSwgYW5kIGlmIGl0IGV4ZWN1dGVz IE9LIGl0IHdvdWxkbid0IGJlIHdoYXQgeW91Cj4gPiA+IGV4cGVjdCBieSByZWFkaW5nIHRoZSBj b2RlLgo+ID4gCj4gPiBUaGlzIG1ha2VzIG5vIHNlbnNlIGF0IGEgZnVuY3Rpb25hbCBsZXZlbC4K PiA+IAo+ID4gT2xkIGtlcm5lbCwgb2xkIERUQjoKPiA+IAo+ID4gQVNDIGRyaXZlciBkb2Vzbid0 IHVuZGVyc3RhbmQgUGluY3RybCwgYnV0IHNpbmNlIG9ubHkgdGhlICJkZWZhdWx0Igo+ID4gc3Rh dGUgaXMgZGVmaW5lZCwgdGhhdCdzIHdoYXQgd2lsbCBiZSB1c2VkIGFzIGEgbWF0dGVyIG9mIGNv dXJzZS4KPiA+IFJUUy9DVFMgYXJlbid0IGNvbmZpZ3VyZWQsIGJ1dCB0aGF0IGRvZXNuJ3QgbWF0 dGVyIGJlY2F1c2UgdGhlIERUUwo+ID4gZG9lcyBub3QgYWR2ZXJ0aXNlIHRoYXQgSFcgZmxvdy1j b250cm9sIGlzIGF2YWlsYWJsZS4gIEluIHRoaXMKPiA+IHVzZS1jYXNlIG5laXRoZXIgSFcgZmxv dy1jb250cm9sLCBub3IgbWFudWFsIHRvZ2dsaW5nIG9mIHRoZSBSVFMgbGluZQo+ID4gaXMgcG9z c2libGUuCj4gPiAKPiA+IE5ldyBrZXJuZWwsIG9sZCBEVEI6Cj4gPiAKPiA+IEFTQyBkcml2ZXIg ZGVtYW5kcyAiZGVmYXVsdCIgYW5kIHJlcXVlc3RzICJtYW51YWwtcnRzIiBQaW5jdHJsIHN0YXRl cywKPiA+IGJ1dCAibWFudWFsLXJ0cyIgaXNuJ3QgYXZhaWxhYmxlIHNvICJkZWZhdWx0IiB3aWxs IGJlIHRoZSBvbmx5Cj4gPiB1dGlsaXNlZCBzdGF0ZS4gIFVubGlrZSB0aGUgZmlyc3QgZXhhbXBs ZSBhYm92ZSwgImRlZmF1bHQiIG5vdwo+ID4gY29udGFpbnMgdGhlIFJUUyBhbmQgQ1RTIGxpbmVz LAo+IAo+IE5vIGl0IGRvZXNuJ3QsIGRlZmF1bHQganVzdCBjb250YWlucyAndHgnICYgJ3J4JyBw aW5zLCBhcyBpdCBoYXMgYWx3YXlzCj4gZG9uZSB1bnRpbCBub3cuCj4gCj4gV2hpY2ggaXMgSU1P IHdoZXJlIHRoZSBjb25kdXNpb24gYXJpc2VzLCBhcyBpdCBpcyB0aGUgc2FtZSBwaW4gY29uZmln dXJhdGlvbgo+IGFzIHdoYXQgeW91IGFyZSBub3cgY2FsbGluZyAnbWFudWFsLXJ0cycgd2hpY2gg dGhlIGRyaXZlciBqdXN0IHRyaWVkIGFuZCBmYWlsZWQKPiB0byBvYnRhaW4gKGFsdGhvdWdoIGlu IHJlYWxpdHkgaXQgaGFzIGFjdHVhbGx5IG9idGFpbmVkIHRob3NlIHBpbnMgYnV0IHN0b3JlZAo+ IHRoZW0gaW4gREVGQVVMVCBpbnN0ZWFkLgo+IAo+IEkgcHJlc3VtZSB0aGlzIGlzIHdoeSBpdCBk aWRuJ3QgbWFrZSBzZW5zZSB0byB5b3UgYWJvdmUuCgpJIGd1ZXNzIHRoaXMgaXMgd2hhdCBoYXBw ZW5zIHdoZW4geW91IHRyeSB0byBleHBsYWluIHNlbWFudGljcyBsYXN0CnRoaW5nLCBhZnRlciBh IGxvbmcgZGF5IGF0IHdvcmsuICBJIGNob3BwZWQgYW5kIGNoYW5nZWQgdGhlCmRlc2NyaXB0aW9u cyBhbmQgdGhlIG9yZGVyaW5nIG9mIHRoZXNlIGFuZCBpdCBsb29rcyBsaWtlIHNvbWUKcGVjdWxp YXJpdGllcyBhcm9zZSBhcyBhIHJlc3VsdC4gIExldCBtZSB0cnkgYWdhaW4gd2l0aCBhIGZyZXNo KGlzaCkKbWluZC4KCk5ldyBrZXJuZWwsIG9sZCBEVEI6CgpBU0MgZHJpdmVyIGRlbWFuZHMgImRl ZmF1bHQiIGFuZCByZXF1ZXN0cyAibWFudWFsLXJ0cyIgUGluY3RybCBzdGF0ZXMsCmJ1dCAibWFu dWFsLXJ0cyIgaXNuJ3QgYXZhaWxhYmxlIHNvICJkZWZhdWx0IiB3aWxsIGJlIHRoZSBvbmx5CnV0 aWxpc2VkIHN0YXRlLiAgVGhlIFJUUyBhbmQgQ1RTIGxpbmVzIHdpbGwgbm90IGJlIHByZXNlbnQs IGJ1dCBzaW5jZQp0aGUgRFRCIGlzIG5vdCBhZHZlcnRpc2luZyBIVyBmbG93LWNvbnRyb2wgYXMg YSBwb3NzaWJpbGl0eSwgdGhlIElQCndpbGwgbm90IHRyeSB0byB1c2UgdGhvc2UgbGluZXMgYW55 d2F5LiAgW0RFRkFVTFRdIHdpbGwgY29udGFpbiB0aGUKImRlZmF1bHQiIHN0YXRlIGFzIHByb3Bv c2VkIGJ5IHRoZSBjdXJyZW50IERUQiwgc28gdGhhdCBpcyBhbHNvCnNlbWFudGljYWxseSBjb3Jy ZWN0LgoKPiA+YnV0IHNpbmNlIHRoZSBEVFMgZG9lcyBub3QgYWR2ZXJ0aXNlCj4gPiBIVyBmbG93 LWNvbnRyb2wgYXMgYXZhaWxhYmxlIHRoZXkgd2lsbCBiZSBoYXJtbGVzc2x5IHVudXNlZC4gIFRo aXMKPiA+IGNvbmZpZ3VyYXRpb24gY3VsbWluYXRlcyBpbiB0aGUgc2FtZSByZXN1bHQgYXMgdGhl IGZpcnN0IGV4YW1wbGUKPiA+IGkuZS4gbm8gSFcgZmxvdy1jb250cm9sIGFuZCBubyBtYW51YWwg dG9nZ2xpbmcuICBIb3dldmVyLCB0aGVyZSBhcmUgbm8KPiA+IGRldHJlbWVudGFsIGVmZmVjdHMg dG8gdGhlIGRyaXZlcidzIGZ1bmN0aW9ucy4gCj4gPgo+IAo+IDxzbmlwPgo+IAo+ID5OZXcga2Vy bmVsLCBuZXcgRFRCOgo+ID4gCj4gPiBBU0MgZHJpdmVyIGRlbWFuZHMgImRlZmF1bHQiIGFuZCBy ZXF1ZXN0cyAibWFudWFsLXJ0cyIgUGluY3RybAo+ID4gc3RhdGVzLiAgSWYgRFRTIGFkdmVydGlz ZXMgdGhhdCBIVyBmbG93LWNvbnRyb2wgaXMgcG9zc2libGUgYW5kIHRoZQo+ID4gY2xpZW50IHJl cXVlc3RzIGl0LCBBU0Mgd2lsbCB1c2UgdGhlICJkZWZhdWx0IiBzdGF0ZSBhbmQgSFcKPiA+IGZs b3ctY29udHJvbCB3aWxsIGNvbW1lbmNlLiAgSWYgSFcgZmxvdy1jb250cm9sIGlzIG5vdCByZXF1 ZXN0ZWQgYnkKPiA+IHRoZSBjbGllbnQgYW5kICJtYW51YWwtcnRzIiBpcyBhdmFpbGFibGUsIHRo ZW4gQVNDIHdpbGwgcmVxdWVzdCB0aGUKPiA+IFJUUyBsaW5lIGlzIGhhbmRsZWQgYnkgR1BJTyB1 bnRpbCBzdWNoIHRpbWVzIGFzIHRoZSBjbGllbnQgcmVxdWVzdHMKPiA+IEhXIGZsb3ctY29udHJv bCwgYXQgd2hpY2ggcG9pbnQgQVNDIHdpbGwgZGlzYWJsZSBHUElPIGFuZCByZXF1ZXN0IHRoZQo+ ID4gImRlZmF1bHQiIHN0YXRlIGFnYWluLgo+IAo+IFVubGVzcyBpdCBpcyB1YXJ0IDEgb3IgMiwg aW4gd2hpY2ggY2FzZSAnZGVmYXVsdCcgc3RpbGwgb25seSBjb250YWlucwo+IHR4ICYgcnggcGlu cywgYW5kIHlvdSBoYXZlIHRoZSBzYW1lIHNpdHVhdGlvbiBhcyBhYm92ZS4gCgpEb2Vzbid0IG1h dHRlci4gICJkZWZhdWx0IiBpcyBub24tZGVzY3JpcHRpdmUuICBJIGNvdWxkIHVuZGVyc3RhbmQg YW4KYXJndW1lbnQgd2VyZSB5b3UgdG8gc2F5IHRoYXQgdGhlICJtYW51YWwtcnRzIiBzaG91bGQg bm90IGNvbnRhaW4gYQpub24tbWFudWFsLXJ0cyBzdGF0ZSwgYnV0IHRoZSAiZGVmYXVsdCIgc3Rh dGUgc2hvdWxkIGp1c3QgY29udGFpbgp3aGF0ZXZlciB0aGUgZGVmYXVsdCBjb25maWd1cmF0aW9u IGlzLCBhbmQgaW4gdGhlIGNhc2Ugb2YgVUFSVCAxIGFuZApVQVJUIDIgdGhlIGRlZmF1bHQgc3Rh dGUgKHVudGlsIHRoZXkgYXJlIEhXIGZsb3ctY29udHJvbCBlbmFibGVkIC0tCndoaWNoIEkgcGxh biB0byBkbyBhcyBhIGZvbGxvdy11cCkgaXMgbm90IHRvIHByb3ZpZGUgSFcgZmxvdy1jb250cm9s CnBpbnMuICBUaGVzZSBzZW1hbnRpY3MgYXJlIHVuY2hhbmdlZCBzaW5jZSBhdXRob3JzaGlwIG9m IHRoZSBkcml2ZXIuCgo+ID4gSXQgaXMgbm90IHBvc3NpYmxlIHRvIHJlYWQgQy1jb2RlIGFuZCBt YWtlIGFzc3VtcHRpb25zIHRoYXQgdGhlIERUQgo+ID4gd2lsbCBiZSBpbiBhIHBhcnRpY3VsYXIg c3RhdGUgYXMgeW91IHN1Z2dlc3QuCj4gPiBObyBkaXNwYXJpdHkgZXZlcgo+ID4gZXhpc3RzIGFu ZCB0aGUgY29kZSBpcyBhbHdheXMgY2xlYXIgSU1ITy4KPiA+IAo+IAo+IFJlYWxseT8KClllcy4K Cj4gYXNjcG9ydC0+c3RhdGVzW0RFRkFVTFRdOiBtYXkgY29udGFpbiAidHgsIHJ4IiBvciAidHgs IHJ4LCBjdHMgJiBydHMiCgpDb3JyZWN0LiAgIkRFRkFVTFQiIGRvZXMgbm90IG1lYW4gIkhXIGZs b3ctY29udHJvbCBvbmx5Ii4gIEl0J3MKd2hhdGV2ZXIgdGhlIGRlZmF1bHQgaXMsIHNvIGNhbiBj b3JyZWN0bHkgY29udGFpbiBlaXRoZXIgc3RhdGUsCmRlcGVuZGluZyBvbiB3aGF0IHRoZSBkZWZh dWx0IHN0YXRlIG9mIHRoZSBEVEIgaXMuCgo+IGFzY3BvcnQtPnN0YXRlc1tNQU5VQUxfUlRTXTog bWF5IGNvbnRhaW4gInR4LCByeCIsIG9yIGl0IGNvdWxkIGJlIHN0b3JlZCBpbiBERUZBVUxUCgpU aGUgbGFzdCBwYXJ0IG9mIHRoaXMgaXMgcmVpdGVyYXRpbmcgeW91ciBwcmV2aW91cyBwb2ludCwg d2hpY2ggSQpqdXN0IGFuc3dlcmVkLiAgVGhlIGNvcnJlY3QgZGVzY3JpcHRpb24gd291bGQgYmU7 ICJtYXkgY29udGFpbiAqb25seSoKInR4LCByeCIsIGFsbG93aW5nICJydHMiIHRvIGJlIG1hbnVh bGx5IGNvbnRyb2xsZWQgT1IsIG1heSBub3QgYmUKcG9wdWxhdGVkIi4gIEluIHRoZSBsYXR0ZXIg Y2FzZSBpdCB3b3VsZCBub3QgYmUgc2VtYW50aWNhbGx5IGluY29ycmVjdApmb3IgREVGQVVMVCB0 byBiZSBlaXRoZXIgSFcgZmxvdy1jb250cm9sIGNhcGFibGUgInR4LCByeCwgcnRzLCBjdHMiIG9y Cm5vdCAidHgsIHJ4IiAtLSB3aGljaGV2ZXIgaXMgdGhlIGRlZmF1bHQgb2YgdGhlIHN1cHBsaWVk IERUQi4KCj4gQW5kIGFzIHRoZSBzZXJpZXMgY3VycmVudGx5IGlzIHlvdSBoYXZlIGEgbWl4dHVy ZSBvZiB0aGUgdHdvIGluIHRoZSBzYW1lIGtlcm5lbAo+IGRlcGVuZGluZyBvbiB3aGF0IGluc3Rh bmNlIG9mIHRoZSBVQVJUIHlvdSBhcmUuCgpBZ2FpbiwgZG9lc24ndCBtYXR0ZXIsIHNpbmNlIGl0 J3MgdGhlIERUQiB0aGF0IHByb3ZpZGVzIHRoZSBkZWZhdWx0CnN0YXRlLiAgU28sIGJhY2sgd2hl biBpdCB3YXMgYXV0aG9yZWQsIHRoZSBkZWZhdWx0IHN0YXRlIHdhcyBIVwpmbG93LWNvbnRyb2wg ZGlzYWJsZWQuICBBbmQgaW4gYSBuZXdlciBEVEIgKGFnYWluLCB1bnRpbCBJIGZvbGxvdy11cAp3 aXRoIG1vcmUgY2hhbmdlcyksIHRoZSBkZWZhdWx0cyBmb3IgVUFSVCAxIGFuZCBVQVJUIDIgYXJl IEhXCmZsb3ctY29udHJvbCBkaXNhYmxlZC4KCllvdXIgaXNzdWUgc2VlbXMgdG8gYmUgdGhhdCB5 b3UndmUgYXNzdW1lZCBzaW5jZSB3ZSBub3cgcHJvdmlkZSB0aGUKcG9zc2liaWxpdHkgb2YgYSAi bWFudWFsLXJ0cyIgc3RhdGUsIHRoZW4gdGhlICJkZWZhdWx0IiBzdGF0ZSBzaG91bGQKKm9ubHkq IGJlIEhXIGZsb3ctY29udHJvbCBjYXBhYmxlLCB3aGljaCBpcyBub3QgdGhlIGNhc2UuICBJdCdz IHRoZQondWFydC1oYXMtcnRzY3RzJyBwcm9wZXJ0eSB3aGljaCBkZXRlcm1pbmVzIHRoaXMgKm5v dCogd2hldGhlciB0aGUKc2Vjb25kIHN0YXRlIGhhcyBiZWVuIHByb3ZpZGVkLiAgSXQgaXMgbm90 IGxvZ2ljYWwgdG8gbWFrZSBhbnkKaW5mZXJlbmNlIHVzaW5nIHNvbGVseSB0aGUgcHJlc2VuY2Ug b3IgYWJzZW5jZSBvZiB0aGUgIm1hbnVhbC1ydHMiCnN0YXRlLgoKLS0gCkxlZSBKb25lcwpMaW5h cm8gU1RNaWNyb2VsZWN0cm9uaWNzIExhbmRpbmcgVGVhbSBMZWFkCkxpbmFyby5vcmcg4pSCIE9w ZW4gc291cmNlIHNvZnR3YXJlIGZvciBBUk0gU29DcwpGb2xsb3cgTGluYXJvOiBGYWNlYm9vayB8 IFR3aXR0ZXIgfCBCbG9nCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxp c3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0 aW5mby9saW51eC1hcm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: lee.jones@linaro.org (Lee Jones) Date: Tue, 31 Jan 2017 10:13:56 +0000 Subject: [STLinux Kernel] [PATCH 3/8] serial: st-asc: Read in all Pinctrl states In-Reply-To: <20170130223521.GA12847@griffinp-ThinkPad-X1-Carbon-2nd> References: <20170124134310.27512-1-lee.jones@linaro.org> <20170124134310.27512-4-lee.jones@linaro.org> <20170125112142.GE5680@griffinp-ThinkPad-X1-Carbon-2nd> <20170127115458.k4edg42nnna3bv4v@dell> <20170130142356.GA18710@griffinp-ThinkPad-X1-Carbon-2nd> <20170130153211.j75qemvwsq3cwqve@dell> <20170130161041.GA21001@griffinp-ThinkPad-X1-Carbon-2nd> <20170130191159.zv5jegvu4fetcmzo@dell> <20170130223521.GA12847@griffinp-ThinkPad-X1-Carbon-2nd> Message-ID: <20170131101356.bpg5hamkfgprdbpt@dell> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 30 Jan 2017, Peter Griffin wrote: > On Mon, 30 Jan 2017, Lee Jones wrote: > > On Mon, 30 Jan 2017, Peter Griffin wrote: > > > On Mon, 30 Jan 2017, Lee Jones wrote: > > > > On Mon, 30 Jan 2017, Peter Griffin wrote: > > > > > On Fri, 27 Jan 2017, Lee Jones wrote: > > > > > > On Wed, 25 Jan 2017, Peter Griffin wrote: > > > > > > > On Tue, 24 Jan 2017, Lee Jones wrote: > > > > > > > > > > > > > > > There are now 2 possible separate/different Pinctrl states which can > > > > > > > > be provided from platform data. One which encompasses the lines > > > > > > > > required for HW flow-control (CTS/RTS) and another which does not > > > > > > > > specify these lines, such that they can be used via GPIO mechanisms > > > > > > > > for manually toggling (i.e. from a request by `stty`). > > > > > > > > > > > > > > > > Signed-off-by: Lee Jones > > > > > > > > --- > > > > > > > > drivers/tty/serial/st-asc.c | 28 ++++++++++++++++++++++++++++ > > > > > > > > 1 file changed, 28 insertions(+) > > > > > > > > > > > > > > > > diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c > > > > > > > > index 397df50..03801ed 100644 > > > > > > > > --- a/drivers/tty/serial/st-asc.c > > > > > > > > +++ b/drivers/tty/serial/st-asc.c > > > > [...] > > > > > > > > > > + pinctrl_lookup_state(ascport->pinctrl, "manual-rts"); > > > > > > > > + if (IS_ERR(ascport->states[MANUAL_RTS])) > > > > > > > > + ascport->states[MANUAL_RTS] = NULL; > > > > > > > > + > > > > > > > > > > > > > > The different pinctrl states looks like a neat solution to the problem. > > > > > > > > > > > > > > My only concern here is that 'default' state is implying a hw-flow-control > > > > > > > pinmux config, and manual-rts is implying what is the current upstream > > > > > > > 'default' pinmux config. > > > > > > > > > > > > > > Which maybe ok if you update all uarts, but currently only serial0 > > > > > > > is updated. So the other uarts current 'default' is actually the same as serial0 > > > > > > > 'manual-rts' grouping, which conceptually is odd. > > > > > > > > > > > > > > Would it not be better to make 'manual-rts' the default state? As that aligns > > > > > > > to what is currently already the default for the other UARTS? And then make > > > > > > > hw-flow-control the optional state for serial0? > > > > > > > > > > > > > > That also has the advantage that 'default' has the same meaning with older DT's. > > > > > > > > > > > > The reason it was done is this was because none of the other UARTs > > > > > > require 2 separate Pinctrl configurations, only this one. Moreover, > > > > > > if they support RTS/CTS then I believe that the lines should be > > > > > > defined in Pinctrl. > > > > > > > > > > Yes I agree with that. > > > > > > > > > > > Thus, it was my plan to update all UART's default > > > > > > Pinctrl configs to include the RTS/CTS lines. > > > > > > > > > > > > > > > > I still don't see the point in changing the meaning of 'default' group and breaking > > > > > ABI if you don't need to? > > > > > > > > > > As far as I can tell if you swap the meaning of 'default' and 'maunal-rts' > > > > > groups you get all the benefits of this series whilst also maintaining backwards > > > > > compatbility with older DT's. > > > > > > > > What makes you think this will break ABI? > > > > > > I've not tried it, but an older DT defines one group, 'default' which contains > > > the same pin config as your new optional 'manual-rts' group. > > > > > > The driver now reads like the manual-rts pin config is optional and should be stored in > > > ascport->states[MANUAL_RTS]. An older DT will pass that same pin config as the default > > > group and it will be stored in ascport->states[DEFAULT]. > > > > > > That seems wrong to me, and if it executes OK it wouldn't be what you > > > expect by reading the code. > > > > This makes no sense at a functional level. > > > > Old kernel, old DTB: > > > > ASC driver doesn't understand Pinctrl, but since only the "default" > > state is defined, that's what will be used as a matter of course. > > RTS/CTS aren't configured, but that doesn't matter because the DTS > > does not advertise that HW flow-control is available. In this > > use-case neither HW flow-control, nor manual toggling of the RTS line > > is possible. > > > > New kernel, old DTB: > > > > ASC driver demands "default" and requests "manual-rts" Pinctrl states, > > but "manual-rts" isn't available so "default" will be the only > > utilised state. Unlike the first example above, "default" now > > contains the RTS and CTS lines, > > No it doesn't, default just contains 'tx' & 'rx' pins, as it has always > done until now. > > Which is IMO where the condusion arises, as it is the same pin configuration > as what you are now calling 'manual-rts' which the driver just tried and failed > to obtain (although in reality it has actually obtained those pins but stored > them in DEFAULT instead. > > I presume this is why it didn't make sense to you above. I guess this is what happens when you try to explain semantics last thing, after a long day at work. I chopped and changed the descriptions and the ordering of these and it looks like some peculiarities arose as a result. Let me try again with a fresh(ish) mind. New kernel, old DTB: ASC driver demands "default" and requests "manual-rts" Pinctrl states, but "manual-rts" isn't available so "default" will be the only utilised state. The RTS and CTS lines will not be present, but since the DTB is not advertising HW flow-control as a possibility, the IP will not try to use those lines anyway. [DEFAULT] will contain the "default" state as proposed by the current DTB, so that is also semantically correct. > >but since the DTS does not advertise > > HW flow-control as available they will be harmlessly unused. This > > configuration culminates in the same result as the first example > > i.e. no HW flow-control and no manual toggling. However, there are no > > detremental effects to the driver's functions. > > > > > > >New kernel, new DTB: > > > > ASC driver demands "default" and requests "manual-rts" Pinctrl > > states. If DTS advertises that HW flow-control is possible and the > > client requests it, ASC will use the "default" state and HW > > flow-control will commence. If HW flow-control is not requested by > > the client and "manual-rts" is available, then ASC will request the > > RTS line is handled by GPIO until such times as the client requests > > HW flow-control, at which point ASC will disable GPIO and request the > > "default" state again. > > Unless it is uart 1 or 2, in which case 'default' still only contains > tx & rx pins, and you have the same situation as above. Doesn't matter. "default" is non-descriptive. I could understand an argument were you to say that the "manual-rts" should not contain a non-manual-rts state, but the "default" state should just contain whatever the default configuration is, and in the case of UART 1 and UART 2 the default state (until they are HW flow-control enabled -- which I plan to do as a follow-up) is not to provide HW flow-control pins. These semantics are unchanged since authorship of the driver. > > It is not possible to read C-code and make assumptions that the DTB > > will be in a particular state as you suggest. > > No disparity ever > > exists and the code is always clear IMHO. > > > > Really? Yes. > ascport->states[DEFAULT]: may contain "tx, rx" or "tx, rx, cts & rts" Correct. "DEFAULT" does not mean "HW flow-control only". It's whatever the default is, so can correctly contain either state, depending on what the default state of the DTB is. > ascport->states[MANUAL_RTS]: may contain "tx, rx", or it could be stored in DEFAULT The last part of this is reiterating your previous point, which I just answered. The correct description would be; "may contain *only* "tx, rx", allowing "rts" to be manually controlled OR, may not be populated". In the latter case it would not be semantically incorrect for DEFAULT to be either HW flow-control capable "tx, rx, rts, cts" or not "tx, rx" -- whichever is the default of the supplied DTB. > And as the series currently is you have a mixture of the two in the same kernel > depending on what instance of the UART you are. Again, doesn't matter, since it's the DTB that provides the default state. So, back when it was authored, the default state was HW flow-control disabled. And in a newer DTB (again, until I follow-up with more changes), the defaults for UART 1 and UART 2 are HW flow-control disabled. Your issue seems to be that you've assumed since we now provide the possibility of a "manual-rts" state, then the "default" state should *only* be HW flow-control capable, which is not the case. It's the 'uart-has-rtscts' property which determines this *not* whether the second state has been provided. It is not logical to make any inference using solely the presence or absence of the "manual-rts" state. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751624AbdAaKk4 (ORCPT ); Tue, 31 Jan 2017 05:40:56 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:38148 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751292AbdAaKkp (ORCPT ); Tue, 31 Jan 2017 05:40:45 -0500 Date: Tue, 31 Jan 2017 10:13:56 +0000 From: Lee Jones To: Peter Griffin Cc: gregkh@linuxfoundation.org, jslaby@suse.com, linux-serial@vger.kernel.org, robh+dt@kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel@stlinux.com Subject: Re: [STLinux Kernel] [PATCH 3/8] serial: st-asc: Read in all Pinctrl states Message-ID: <20170131101356.bpg5hamkfgprdbpt@dell> References: <20170124134310.27512-1-lee.jones@linaro.org> <20170124134310.27512-4-lee.jones@linaro.org> <20170125112142.GE5680@griffinp-ThinkPad-X1-Carbon-2nd> <20170127115458.k4edg42nnna3bv4v@dell> <20170130142356.GA18710@griffinp-ThinkPad-X1-Carbon-2nd> <20170130153211.j75qemvwsq3cwqve@dell> <20170130161041.GA21001@griffinp-ThinkPad-X1-Carbon-2nd> <20170130191159.zv5jegvu4fetcmzo@dell> <20170130223521.GA12847@griffinp-ThinkPad-X1-Carbon-2nd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170130223521.GA12847@griffinp-ThinkPad-X1-Carbon-2nd> User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 Jan 2017, Peter Griffin wrote: > On Mon, 30 Jan 2017, Lee Jones wrote: > > On Mon, 30 Jan 2017, Peter Griffin wrote: > > > On Mon, 30 Jan 2017, Lee Jones wrote: > > > > On Mon, 30 Jan 2017, Peter Griffin wrote: > > > > > On Fri, 27 Jan 2017, Lee Jones wrote: > > > > > > On Wed, 25 Jan 2017, Peter Griffin wrote: > > > > > > > On Tue, 24 Jan 2017, Lee Jones wrote: > > > > > > > > > > > > > > > There are now 2 possible separate/different Pinctrl states which can > > > > > > > > be provided from platform data. One which encompasses the lines > > > > > > > > required for HW flow-control (CTS/RTS) and another which does not > > > > > > > > specify these lines, such that they can be used via GPIO mechanisms > > > > > > > > for manually toggling (i.e. from a request by `stty`). > > > > > > > > > > > > > > > > Signed-off-by: Lee Jones > > > > > > > > --- > > > > > > > > drivers/tty/serial/st-asc.c | 28 ++++++++++++++++++++++++++++ > > > > > > > > 1 file changed, 28 insertions(+) > > > > > > > > > > > > > > > > diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c > > > > > > > > index 397df50..03801ed 100644 > > > > > > > > --- a/drivers/tty/serial/st-asc.c > > > > > > > > +++ b/drivers/tty/serial/st-asc.c > > > > [...] > > > > > > > > > > + pinctrl_lookup_state(ascport->pinctrl, "manual-rts"); > > > > > > > > + if (IS_ERR(ascport->states[MANUAL_RTS])) > > > > > > > > + ascport->states[MANUAL_RTS] = NULL; > > > > > > > > + > > > > > > > > > > > > > > The different pinctrl states looks like a neat solution to the problem. > > > > > > > > > > > > > > My only concern here is that 'default' state is implying a hw-flow-control > > > > > > > pinmux config, and manual-rts is implying what is the current upstream > > > > > > > 'default' pinmux config. > > > > > > > > > > > > > > Which maybe ok if you update all uarts, but currently only serial0 > > > > > > > is updated. So the other uarts current 'default' is actually the same as serial0 > > > > > > > 'manual-rts' grouping, which conceptually is odd. > > > > > > > > > > > > > > Would it not be better to make 'manual-rts' the default state? As that aligns > > > > > > > to what is currently already the default for the other UARTS? And then make > > > > > > > hw-flow-control the optional state for serial0? > > > > > > > > > > > > > > That also has the advantage that 'default' has the same meaning with older DT's. > > > > > > > > > > > > The reason it was done is this was because none of the other UARTs > > > > > > require 2 separate Pinctrl configurations, only this one. Moreover, > > > > > > if they support RTS/CTS then I believe that the lines should be > > > > > > defined in Pinctrl. > > > > > > > > > > Yes I agree with that. > > > > > > > > > > > Thus, it was my plan to update all UART's default > > > > > > Pinctrl configs to include the RTS/CTS lines. > > > > > > > > > > > > > > > > I still don't see the point in changing the meaning of 'default' group and breaking > > > > > ABI if you don't need to? > > > > > > > > > > As far as I can tell if you swap the meaning of 'default' and 'maunal-rts' > > > > > groups you get all the benefits of this series whilst also maintaining backwards > > > > > compatbility with older DT's. > > > > > > > > What makes you think this will break ABI? > > > > > > I've not tried it, but an older DT defines one group, 'default' which contains > > > the same pin config as your new optional 'manual-rts' group. > > > > > > The driver now reads like the manual-rts pin config is optional and should be stored in > > > ascport->states[MANUAL_RTS]. An older DT will pass that same pin config as the default > > > group and it will be stored in ascport->states[DEFAULT]. > > > > > > That seems wrong to me, and if it executes OK it wouldn't be what you > > > expect by reading the code. > > > > This makes no sense at a functional level. > > > > Old kernel, old DTB: > > > > ASC driver doesn't understand Pinctrl, but since only the "default" > > state is defined, that's what will be used as a matter of course. > > RTS/CTS aren't configured, but that doesn't matter because the DTS > > does not advertise that HW flow-control is available. In this > > use-case neither HW flow-control, nor manual toggling of the RTS line > > is possible. > > > > New kernel, old DTB: > > > > ASC driver demands "default" and requests "manual-rts" Pinctrl states, > > but "manual-rts" isn't available so "default" will be the only > > utilised state. Unlike the first example above, "default" now > > contains the RTS and CTS lines, > > No it doesn't, default just contains 'tx' & 'rx' pins, as it has always > done until now. > > Which is IMO where the condusion arises, as it is the same pin configuration > as what you are now calling 'manual-rts' which the driver just tried and failed > to obtain (although in reality it has actually obtained those pins but stored > them in DEFAULT instead. > > I presume this is why it didn't make sense to you above. I guess this is what happens when you try to explain semantics last thing, after a long day at work. I chopped and changed the descriptions and the ordering of these and it looks like some peculiarities arose as a result. Let me try again with a fresh(ish) mind. New kernel, old DTB: ASC driver demands "default" and requests "manual-rts" Pinctrl states, but "manual-rts" isn't available so "default" will be the only utilised state. The RTS and CTS lines will not be present, but since the DTB is not advertising HW flow-control as a possibility, the IP will not try to use those lines anyway. [DEFAULT] will contain the "default" state as proposed by the current DTB, so that is also semantically correct. > >but since the DTS does not advertise > > HW flow-control as available they will be harmlessly unused. This > > configuration culminates in the same result as the first example > > i.e. no HW flow-control and no manual toggling. However, there are no > > detremental effects to the driver's functions. > > > > > > >New kernel, new DTB: > > > > ASC driver demands "default" and requests "manual-rts" Pinctrl > > states. If DTS advertises that HW flow-control is possible and the > > client requests it, ASC will use the "default" state and HW > > flow-control will commence. If HW flow-control is not requested by > > the client and "manual-rts" is available, then ASC will request the > > RTS line is handled by GPIO until such times as the client requests > > HW flow-control, at which point ASC will disable GPIO and request the > > "default" state again. > > Unless it is uart 1 or 2, in which case 'default' still only contains > tx & rx pins, and you have the same situation as above. Doesn't matter. "default" is non-descriptive. I could understand an argument were you to say that the "manual-rts" should not contain a non-manual-rts state, but the "default" state should just contain whatever the default configuration is, and in the case of UART 1 and UART 2 the default state (until they are HW flow-control enabled -- which I plan to do as a follow-up) is not to provide HW flow-control pins. These semantics are unchanged since authorship of the driver. > > It is not possible to read C-code and make assumptions that the DTB > > will be in a particular state as you suggest. > > No disparity ever > > exists and the code is always clear IMHO. > > > > Really? Yes. > ascport->states[DEFAULT]: may contain "tx, rx" or "tx, rx, cts & rts" Correct. "DEFAULT" does not mean "HW flow-control only". It's whatever the default is, so can correctly contain either state, depending on what the default state of the DTB is. > ascport->states[MANUAL_RTS]: may contain "tx, rx", or it could be stored in DEFAULT The last part of this is reiterating your previous point, which I just answered. The correct description would be; "may contain *only* "tx, rx", allowing "rts" to be manually controlled OR, may not be populated". In the latter case it would not be semantically incorrect for DEFAULT to be either HW flow-control capable "tx, rx, rts, cts" or not "tx, rx" -- whichever is the default of the supplied DTB. > And as the series currently is you have a mixture of the two in the same kernel > depending on what instance of the UART you are. Again, doesn't matter, since it's the DTB that provides the default state. So, back when it was authored, the default state was HW flow-control disabled. And in a newer DTB (again, until I follow-up with more changes), the defaults for UART 1 and UART 2 are HW flow-control disabled. Your issue seems to be that you've assumed since we now provide the possibility of a "manual-rts" state, then the "default" state should *only* be HW flow-control capable, which is not the case. It's the 'uart-has-rtscts' property which determines this *not* whether the second state has been provided. It is not logical to make any inference using solely the presence or absence of the "manual-rts" state. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog