diff for duplicates of <1370433718.509579856@f214.mail.ru> diff --git a/a/1.txt b/N1/1.txt index 0343500..9fac2f0 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,47 +1,52 @@ -CgoK0KHRgNC10LTQsCwgIDUg0LjRjtC90Y8gMjAxMywgMTM6NDUgKzAyOjAwINC+0YIgSmVhbiBE -ZWx2YXJlIDxraGFsaUBsaW51eC1mci5vcmc+Ogo+IE9uIFdlZCwgMDUgSnVuIDIwMTMgMTU6MTQ6 -MzkgKzA0MDAsIEFsZXhhbmRlciBTaGl5YW4gd3JvdGU6Cj4gPiA+IExldCdzIGxvb2sgYXQgaXQg -ZnJvbSBhbm90aGVyIGFuZ2xlLiBXaGF0IHByb2JsZW0gYXJlIHlvdSB0cnlpbmcgdG8KPiA+ID4g -c29sdmU/IEkgc2VlIGFic29sdXRlbHkgbm8gcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IGZ1bmN0 -aW9uIGFuZCBmaWxlCj4gPiA+IG5hbWVzLiBBbG1vc3QgYWxsIExpbnV4IGtlcm5lbCBkcml2ZXJz -IHN1cHBvcnQgbW9yZSBjaGlwcyB0aGFuIHRoZWlyCj4gPiA+IG5hbWUgc2F5cy4KPiA+ID4gCj4g -PiA+IE9uIHRoZSBvdGhlciBoYW5kLCBjaGFuZ2luZyBhbGwgZnVuY3Rpb24gbmFtZXMgbWFrZXMg -YmFja3BvcnRpbmcgZml4ZXMKPiA+ID4gaGFyZGVyLCBhbmQgY2hhbmdpbmcgS2NvbmZpZyBzeW1i -b2wgbmFtZXMgbWFrZXMgdXBncmFkaW5nIHRvIHRoZSBuZXcKPiA+ID4ga2VybmVsIHZlcnNpb24g -aGFyZGVyIGZvciBldmVyeW9uZS4KPiA+ID4gCj4gPiA+IFNvIHRoZSBjb3N0IG9mIHlvdXIgcHJv -cG9zYWwgZmFyIG91dHdlaWdocyB0aGUgYmVuZWZpdHMuCj4gPiAKPiA+IFdlbGwsIGxldCdzIGxl -YXZlIHRoZSBrY29uZmlnIHN5bWJvbCBhcyBpcy4gQnV0IGFib3V0IHRoZSByZXN0LCB0aGF0IG1j -MTM3ODNfKgo+ID4gc3ltYm9scyBpbiB0aGUgbG9nIChkZWJ1Zykgd2lsbCBzYXkgYSBkZXZlbG9w -ZXIgd2hvIGRvZXMgbm90IGtub3cgYWJvdXQKPiA+IG1jMTM4OTIgY29tcGF0aWJpbGl0eSB3aXRo -IG1jMTM3ODM/IEkgc3RpbGwgYmVsaWV2ZSB0aGF0IHRoaXMgc2hvdWxkIGJlIHJlZmxlY3RlZC4K -PiAKPiBZb3UncmUgc3BsaXR0aW5nIGhhaXJzIGhlcmUuIG1jMTM3ODNfKiBzeW1ib2xzIGluIHRo -ZSBsb2cgbWVhbiB0aGlzCj4gY29tZXMgZnJvbSBhIGRyaXZlciBuYW1lZCBtYzEzNzgzLCBwZXJp -b2QuIEEgZGV2ZWxvcGVyIGRyYXdpbmcKPiBjb25jbHVzaW9ucyBiZXlvbmQgdGhhdCBuZWVkcyB0 -byBiZSBlZHVjYXRlZC4gV2hpY2ggZGV2aWNlIHRoZSBkcml2ZXIKPiBpcyBkcml2aW5nIGNhbiBi -ZSByZXRyaWVkIGZyb20gdGhlIGxvZyBpdHNlbGYsIG9yIGZyb20gc3lzZnMuIE9yIHRoZQo+IGhh -cmR3YXJlIGJvYXJkIGRhdGFzaGVldC4gIm1jMTN4eHgiIHdvdWxkIHRlbGwgbm8gbW9yZSwgQlRX -Lgo+IAo+IEFsc28gbm90ZSB0aGF0IHRoZSBuYW1lIG1jMTN4eHggaXMgd3JvbmcgYXMgd2VsbCwg -YXMgdGhlIG1jMTN4eHgtaTJjCj4gYW5kIG1jMTN4eHgtc3BpIGRyaXZlcnMgaGFuZGxlIHRoZSBN -QzM0NzA4IGNoaXAgdG9vLiBTbyB5b3UnZCBoYXZlIHRvCj4gbmFtZSBhbGwgdGhlc2UgZHJpdmVy -cyBhbmQgZnVuY3Rpb25zIG1jeHh4eHgqIHRvIGNvdmVyIGFsbCB0aGUKPiBzdXBwb3J0ZWQgY2hp -cC4gV2hpY2ggbWFrZXMgbm8gc2Vuc2UgYXQgYWxsLCBiZWNhdXNlIHNvIG1hbnkgeCdzIGFyZQo+ -IGNvbmZ1c2luZywgYW5kIGJlY2F1c2UgdGhlIG1hc2sgdGhlbiBtYXRjaGVzIG1hbnkgZGV2aWNl -cyB0aGUgZHJpdmVycwo+IGRvIF9ub3RfIGhhbmRsZS4KPiAKPiBTbyBwbGVhc2UgZm9yZ2V0IGFi -b3V0IHRoaXMgYW5kIG1vdmUgb24gdG8gc29tZXRoaW5nIGVsc2UuIFRoZXJlIGFyZQo+IG1hbnkg -bWFueSBjb2RlIGNsZWFudXBzIGFuZCBpbXByb3ZlbWVudHMsIGFuZCBidWcgZml4ZXMsIGFsbCB3 -YXkgbW9yZQo+IGltcG9ydGFudCB0aGFuIHRoaXMuIFNvIEknbSBzdXJlIHlvdSBjYW4gZmluZCBi -ZXR0ZXIgd2F5cyB0byBzcGVuZCB5b3VyCj4gdGltZSwgYW5kIG1pbmUuCgpBZ3JlZSwgd2UgaGF2 -ZSBhIGxvdCBvZiBwbGFjZXMgaW4gdGhlIGtlcm5lbCB0byBiZSBjbGVhcmVkLgpGb3IgdGhlIHNh -bWUgZHJpdmVyIE1DMTNYWFgsIGF0IGxlYXN0IHdlIG5lZWQgdG8gcmVtb3ZlIGEgdXNlbGVzcyBz -eW1ib2wKTUZEX00xMzc4MyB3aGljaCBpcyBzZWxlY3RlZCBhdXRvbWF0aWNhbGx5IGlmIHdlIHNl -bGVjdCBNRkRfTUMxM1hYWCwgCm1jMTN4eHhfbG9jay91bmxvY2sgZnVuY3Rpb25zIGluIHRoZSBk -cml2ZXIgaGFzIGxvbmcgYmVlbiBub3QgbmVlZGVkIGJlY2F1c2UKd2UgdXNlIHJlZ21hcCBldGMu -CkJ1dCB0byBzdGFydCBpbiBteSBvcGluaW9uIHlvdSBuZWVkIHdpdGgganVzdCBzdWNoIHRyaWZs -ZXMgYXMgcmVuYW1lIGV0Yy4uLgpCdXQgZXZlbiBhdCB0aGlzIHN0YWdlIG9mIG9ic3RhY2xlcyBo -YXZlIGNvbWUgdXAgYWdhaW5zdCAuLi4KV2VsbCwgYnkgYW5kIGxhcmdlIGl0IGRvZXMgbm90IGNo -YW5nZSBjb2RlIGJ1dCByYXRoZXIgYSBncm9vbWluZyBjb2RlLCAKc28gSSBjYW4gZWFzaWx5IGdp -dmUgaXQgdXAuIEJ1dCwgaW4gbXkgb3BpbmlvbiwgdGhlIHB1cml0eSBhbmQgY2xhcml0eSBvZiB0 -aGUgY29kZQpoYXMgbmV2ZXIgaGFybWVkLgpPSywgbGV0cyBkcm9wIHRoZXNlIHBhdGNoZXMuClRo -YW5rcy4KCi0tLQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f -XwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6 -Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM + + + +?????, 5 ???? 2013, 13:45 +02:00 ?? Jean Delvare <khali@linux-fr.org>: +> On Wed, 05 Jun 2013 15:14:39 +0400, Alexander Shiyan wrote: +> > > Let's look at it from another angle. What problem are you trying to +> > > solve? I see absolutely no problem with the current function and file +> > > names. Almost all Linux kernel drivers support more chips than their +> > > name says. +> > > +> > > On the other hand, changing all function names makes backporting fixes +> > > harder, and changing Kconfig symbol names makes upgrading to the new +> > > kernel version harder for everyone. +> > > +> > > So the cost of your proposal far outweighs the benefits. +> > +> > Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_* +> > symbols in the log (debug) will say a developer who does not know about +> > mc13892 compatibility with mc13783? I still believe that this should be reflected. +> +> You're splitting hairs here. mc13783_* symbols in the log mean this +> comes from a driver named mc13783, period. A developer drawing +> conclusions beyond that needs to be educated. Which device the driver +> is driving can be retried from the log itself, or from sysfs. Or the +> hardware board datasheet. "mc13xxx" would tell no more, BTW. +> +> Also note that the name mc13xxx is wrong as well, as the mc13xxx-i2c +> and mc13xxx-spi drivers handle the MC34708 chip too. So you'd have to +> name all these drivers and functions mcxxxxx* to cover all the +> supported chip. Which makes no sense at all, because so many x's are +> confusing, and because the mask then matches many devices the drivers +> do _not_ handle. +> +> So please forget about this and move on to something else. There are +> many many code cleanups and improvements, and bug fixes, all way more +> important than this. So I'm sure you can find better ways to spend your +> time, and mine. + +Agree, we have a lot of places in the kernel to be cleared. +For the same driver MC13XXX, at least we need to remove a useless symbol +MFD_M13783 which is selected automatically if we select MFD_MC13XXX, +mc13xxx_lock/unlock functions in the driver has long been not needed because +we use regmap etc. +But to start in my opinion you need with just such trifles as rename etc... +But even at this stage of obstacles have come up against ... +Well, by and large it does not change code but rather a grooming code, +so I can easily give it up. But, in my opinion, the purity and clarity of the code +has never harmed. +OK, lets drop these patches. +Thanks. + +--- diff --git a/a/content_digest b/N1/content_digest index 7aac1db..c549f38 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,58 +1,63 @@ "ref\01370422628-1073-1-git-send-email-shc_work@mail.ru\0" "ref\01370430879.384973987@f91.mail.ru\0" "ref\020130605134530.12e8b7c2@endymion.delvare\0" - "From\0Alexander Shiyan <shc_work@mail.ru>\0" - "Subject\0Re: [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re\0" - "Date\0Wed, 05 Jun 2013 12:01:58 +0000\0" + "From\0shc_work@mail.ru (Alexander Shiyan)\0" + "Subject\0Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips\0" + "Date\0Wed, 05 Jun 2013 16:01:58 +0400\0" "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" - "CgoK0KHRgNC10LTQsCwgIDUg0LjRjtC90Y8gMjAxMywgMTM6NDUgKzAyOjAwINC+0YIgSmVhbiBE\n" - "ZWx2YXJlIDxraGFsaUBsaW51eC1mci5vcmc+Ogo+IE9uIFdlZCwgMDUgSnVuIDIwMTMgMTU6MTQ6\n" - "MzkgKzA0MDAsIEFsZXhhbmRlciBTaGl5YW4gd3JvdGU6Cj4gPiA+IExldCdzIGxvb2sgYXQgaXQg\n" - "ZnJvbSBhbm90aGVyIGFuZ2xlLiBXaGF0IHByb2JsZW0gYXJlIHlvdSB0cnlpbmcgdG8KPiA+ID4g\n" - "c29sdmU/IEkgc2VlIGFic29sdXRlbHkgbm8gcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IGZ1bmN0\n" - "aW9uIGFuZCBmaWxlCj4gPiA+IG5hbWVzLiBBbG1vc3QgYWxsIExpbnV4IGtlcm5lbCBkcml2ZXJz\n" - "IHN1cHBvcnQgbW9yZSBjaGlwcyB0aGFuIHRoZWlyCj4gPiA+IG5hbWUgc2F5cy4KPiA+ID4gCj4g\n" - "PiA+IE9uIHRoZSBvdGhlciBoYW5kLCBjaGFuZ2luZyBhbGwgZnVuY3Rpb24gbmFtZXMgbWFrZXMg\n" - "YmFja3BvcnRpbmcgZml4ZXMKPiA+ID4gaGFyZGVyLCBhbmQgY2hhbmdpbmcgS2NvbmZpZyBzeW1i\n" - "b2wgbmFtZXMgbWFrZXMgdXBncmFkaW5nIHRvIHRoZSBuZXcKPiA+ID4ga2VybmVsIHZlcnNpb24g\n" - "aGFyZGVyIGZvciBldmVyeW9uZS4KPiA+ID4gCj4gPiA+IFNvIHRoZSBjb3N0IG9mIHlvdXIgcHJv\n" - "cG9zYWwgZmFyIG91dHdlaWdocyB0aGUgYmVuZWZpdHMuCj4gPiAKPiA+IFdlbGwsIGxldCdzIGxl\n" - "YXZlIHRoZSBrY29uZmlnIHN5bWJvbCBhcyBpcy4gQnV0IGFib3V0IHRoZSByZXN0LCB0aGF0IG1j\n" - "MTM3ODNfKgo+ID4gc3ltYm9scyBpbiB0aGUgbG9nIChkZWJ1Zykgd2lsbCBzYXkgYSBkZXZlbG9w\n" - "ZXIgd2hvIGRvZXMgbm90IGtub3cgYWJvdXQKPiA+IG1jMTM4OTIgY29tcGF0aWJpbGl0eSB3aXRo\n" - "IG1jMTM3ODM/IEkgc3RpbGwgYmVsaWV2ZSB0aGF0IHRoaXMgc2hvdWxkIGJlIHJlZmxlY3RlZC4K\n" - "PiAKPiBZb3UncmUgc3BsaXR0aW5nIGhhaXJzIGhlcmUuIG1jMTM3ODNfKiBzeW1ib2xzIGluIHRo\n" - "ZSBsb2cgbWVhbiB0aGlzCj4gY29tZXMgZnJvbSBhIGRyaXZlciBuYW1lZCBtYzEzNzgzLCBwZXJp\n" - "b2QuIEEgZGV2ZWxvcGVyIGRyYXdpbmcKPiBjb25jbHVzaW9ucyBiZXlvbmQgdGhhdCBuZWVkcyB0\n" - "byBiZSBlZHVjYXRlZC4gV2hpY2ggZGV2aWNlIHRoZSBkcml2ZXIKPiBpcyBkcml2aW5nIGNhbiBi\n" - "ZSByZXRyaWVkIGZyb20gdGhlIGxvZyBpdHNlbGYsIG9yIGZyb20gc3lzZnMuIE9yIHRoZQo+IGhh\n" - "cmR3YXJlIGJvYXJkIGRhdGFzaGVldC4gIm1jMTN4eHgiIHdvdWxkIHRlbGwgbm8gbW9yZSwgQlRX\n" - "Lgo+IAo+IEFsc28gbm90ZSB0aGF0IHRoZSBuYW1lIG1jMTN4eHggaXMgd3JvbmcgYXMgd2VsbCwg\n" - "YXMgdGhlIG1jMTN4eHgtaTJjCj4gYW5kIG1jMTN4eHgtc3BpIGRyaXZlcnMgaGFuZGxlIHRoZSBN\n" - "QzM0NzA4IGNoaXAgdG9vLiBTbyB5b3UnZCBoYXZlIHRvCj4gbmFtZSBhbGwgdGhlc2UgZHJpdmVy\n" - "cyBhbmQgZnVuY3Rpb25zIG1jeHh4eHgqIHRvIGNvdmVyIGFsbCB0aGUKPiBzdXBwb3J0ZWQgY2hp\n" - "cC4gV2hpY2ggbWFrZXMgbm8gc2Vuc2UgYXQgYWxsLCBiZWNhdXNlIHNvIG1hbnkgeCdzIGFyZQo+\n" - "IGNvbmZ1c2luZywgYW5kIGJlY2F1c2UgdGhlIG1hc2sgdGhlbiBtYXRjaGVzIG1hbnkgZGV2aWNl\n" - "cyB0aGUgZHJpdmVycwo+IGRvIF9ub3RfIGhhbmRsZS4KPiAKPiBTbyBwbGVhc2UgZm9yZ2V0IGFi\n" - "b3V0IHRoaXMgYW5kIG1vdmUgb24gdG8gc29tZXRoaW5nIGVsc2UuIFRoZXJlIGFyZQo+IG1hbnkg\n" - "bWFueSBjb2RlIGNsZWFudXBzIGFuZCBpbXByb3ZlbWVudHMsIGFuZCBidWcgZml4ZXMsIGFsbCB3\n" - "YXkgbW9yZQo+IGltcG9ydGFudCB0aGFuIHRoaXMuIFNvIEknbSBzdXJlIHlvdSBjYW4gZmluZCBi\n" - "ZXR0ZXIgd2F5cyB0byBzcGVuZCB5b3VyCj4gdGltZSwgYW5kIG1pbmUuCgpBZ3JlZSwgd2UgaGF2\n" - "ZSBhIGxvdCBvZiBwbGFjZXMgaW4gdGhlIGtlcm5lbCB0byBiZSBjbGVhcmVkLgpGb3IgdGhlIHNh\n" - "bWUgZHJpdmVyIE1DMTNYWFgsIGF0IGxlYXN0IHdlIG5lZWQgdG8gcmVtb3ZlIGEgdXNlbGVzcyBz\n" - "eW1ib2wKTUZEX00xMzc4MyB3aGljaCBpcyBzZWxlY3RlZCBhdXRvbWF0aWNhbGx5IGlmIHdlIHNl\n" - "bGVjdCBNRkRfTUMxM1hYWCwgCm1jMTN4eHhfbG9jay91bmxvY2sgZnVuY3Rpb25zIGluIHRoZSBk\n" - "cml2ZXIgaGFzIGxvbmcgYmVlbiBub3QgbmVlZGVkIGJlY2F1c2UKd2UgdXNlIHJlZ21hcCBldGMu\n" - "CkJ1dCB0byBzdGFydCBpbiBteSBvcGluaW9uIHlvdSBuZWVkIHdpdGgganVzdCBzdWNoIHRyaWZs\n" - "ZXMgYXMgcmVuYW1lIGV0Yy4uLgpCdXQgZXZlbiBhdCB0aGlzIHN0YWdlIG9mIG9ic3RhY2xlcyBo\n" - "YXZlIGNvbWUgdXAgYWdhaW5zdCAuLi4KV2VsbCwgYnkgYW5kIGxhcmdlIGl0IGRvZXMgbm90IGNo\n" - "YW5nZSBjb2RlIGJ1dCByYXRoZXIgYSBncm9vbWluZyBjb2RlLCAKc28gSSBjYW4gZWFzaWx5IGdp\n" - "dmUgaXQgdXAuIEJ1dCwgaW4gbXkgb3BpbmlvbiwgdGhlIHB1cml0eSBhbmQgY2xhcml0eSBvZiB0\n" - "aGUgY29kZQpoYXMgbmV2ZXIgaGFybWVkLgpPSywgbGV0cyBkcm9wIHRoZXNlIHBhdGNoZXMuClRo\n" - "YW5rcy4KCi0tLQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f\n" - "XwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6\n" - Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM + "\n" + "\n" + "\n" + "?????, 5 ???? 2013, 13:45 +02:00 ?? Jean Delvare <khali@linux-fr.org>:\n" + "> On Wed, 05 Jun 2013 15:14:39 +0400, Alexander Shiyan wrote:\n" + "> > > Let's look at it from another angle. What problem are you trying to\n" + "> > > solve? I see absolutely no problem with the current function and file\n" + "> > > names. Almost all Linux kernel drivers support more chips than their\n" + "> > > name says.\n" + "> > > \n" + "> > > On the other hand, changing all function names makes backporting fixes\n" + "> > > harder, and changing Kconfig symbol names makes upgrading to the new\n" + "> > > kernel version harder for everyone.\n" + "> > > \n" + "> > > So the cost of your proposal far outweighs the benefits.\n" + "> > \n" + "> > Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_*\n" + "> > symbols in the log (debug) will say a developer who does not know about\n" + "> > mc13892 compatibility with mc13783? I still believe that this should be reflected.\n" + "> \n" + "> You're splitting hairs here. mc13783_* symbols in the log mean this\n" + "> comes from a driver named mc13783, period. A developer drawing\n" + "> conclusions beyond that needs to be educated. Which device the driver\n" + "> is driving can be retried from the log itself, or from sysfs. Or the\n" + "> hardware board datasheet. \"mc13xxx\" would tell no more, BTW.\n" + "> \n" + "> Also note that the name mc13xxx is wrong as well, as the mc13xxx-i2c\n" + "> and mc13xxx-spi drivers handle the MC34708 chip too. So you'd have to\n" + "> name all these drivers and functions mcxxxxx* to cover all the\n" + "> supported chip. Which makes no sense at all, because so many x's are\n" + "> confusing, and because the mask then matches many devices the drivers\n" + "> do _not_ handle.\n" + "> \n" + "> So please forget about this and move on to something else. There are\n" + "> many many code cleanups and improvements, and bug fixes, all way more\n" + "> important than this. So I'm sure you can find better ways to spend your\n" + "> time, and mine.\n" + "\n" + "Agree, we have a lot of places in the kernel to be cleared.\n" + "For the same driver MC13XXX, at least we need to remove a useless symbol\n" + "MFD_M13783 which is selected automatically if we select MFD_MC13XXX, \n" + "mc13xxx_lock/unlock functions in the driver has long been not needed because\n" + "we use regmap etc.\n" + "But to start in my opinion you need with just such trifles as rename etc...\n" + "But even at this stage of obstacles have come up against ...\n" + "Well, by and large it does not change code but rather a grooming code, \n" + "so I can easily give it up. But, in my opinion, the purity and clarity of the code\n" + "has never harmed.\n" + "OK, lets drop these patches.\n" + "Thanks.\n" + "\n" + --- -6b8d628695a6a76d5ae5914872eb2317691d0107e2ebe7ba71f8e5ccd0aa700b +1c182301b839dd00133eb72649953b4d4cb5e57b0bef1319c479bdc23f975f2b
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.