From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH v3 05/12] OMAP: Serial: Hold console lock for console usage. Date: Mon, 27 Jun 2011 15:41:39 -0700 Message-ID: <878vsm99ss.fsf@ti.com> References: <1307532194-13039-1-git-send-email-govindraj.raja@ti.com> <1307532194-13039-6-git-send-email-govindraj.raja@ti.com> <87boxmsrjt.fsf@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: (Govindraj's message of "Mon, 27 Jun 2011 19:05:06 +0530") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Govindraj Cc: Tony Lindgren , "Govindraj.R" , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-serial@vger.kernel.org List-Id: linux-omap@vger.kernel.org R292aW5kcmFqIDxnb3ZpbmRyYWoudGlAZ21haWwuY29tPiB3cml0ZXM6Cgo+IE9uIFNhdCwgSnVu IDI1LCAyMDExIGF0IDU6MzYgQU0sIEtldmluIEhpbG1hbiA8a2hpbG1hbkB0aS5jb20+IHdyb3Rl Ogo+PiAiR292aW5kcmFqLlIiIDxnb3ZpbmRyYWoucmFqYUB0aS5jb20+IHdyaXRlczoKPj4KPj4+ IEFjcXVpcmUgY29uc29sZSBsb2NrIGJlZm9yZSBlbmFibGluZyBhbmQgd3JpdGluZyB0byBjb25z b2xlLXVhcnQKPj4+IHRvIGF2b2lkIGFueSByZWN1cnNpdmUgcHJpbnRzIGZyb20gY29uc29sZSB3 cml0ZS4KPj4+IGZvciBleDoKPj4+IMKgIMKgIMKgIMKgIC0tPiBwcmludGsKPj4+IMKgIMKgIMKg IMKgIMKgIC0tPiB1YXJ0X2NvbnNvbGVfd3JpdGUKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIC0tPiBn ZXRfc3luYwo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0+IHByaW50ayBmcm9tIG9tYXBfZGV2 aWNlIGVuYWJsZQo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0+IHVhcnRfY29uc29sZSB3 cml0ZQo+Pj4KPj4+IFVzZSBSUE1fU1VTUEVORElORyBjaGVjayB0byBhdm9pZCBiZWxvdyBzY2Vu YXJpbyBkdXJpbmcgYm9vdHVwCj4+PiBBcyBkdXJpbmcgYm9vdHVwIGNvbnNvbGVfbG9jayBpcyBu b3QgYXZhaWxhYmxlLgo+Pj4gwqAgwqAgwqAgwqAtLT4gdWFydF9hZGRfb25lX3BvcnQKPj4+IMKg IMKgIMKgIMKgIMKgIMKgLS0+IGNvbnNvbGVfcmVnaXN0ZXIKPj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgLS0+IGNvbnNvbGVfbG9jawo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0+IGNv bnNvbGVfdW5sb2NrCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC0tPiBjYWxs X2NvbnNvbGVfZHJpdmVycyAoaGVyZSB5ZXQgY29uc29sZV9sb2NrIGlzIG5vdCByZWxlYXNlZCkK Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tPiB1YXJ0X2NvbnNv bGVfd3JpdGUKPj4+Cj4+PiBBY2tlZC1ieTogQWxhbiBDb3ggPGFsYW5AbGludXguaW50ZWwuY29t Pgo+Pj4gU2lnbmVkLW9mZi1ieTogR292aW5kcmFqLlIgPGdvdmluZHJhai5yYWphQHRpLmNvbT4K Pj4+IC0tLQo+Pj4gwqBkcml2ZXJzL3R0eS9zZXJpYWwvb21hcC1zZXJpYWwuYyB8IMKgIDIwICsr KysrKysrKysrKysrKysrKystCj4+PiDCoDEgZmlsZXMgY2hhbmdlZCwgMTkgaW5zZXJ0aW9ucygr KSwgMSBkZWxldGlvbnMoLSkKPj4+Cj4+PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy90dHkvc2VyaWFs L29tYXAtc2VyaWFsLmMgYi9kcml2ZXJzL3R0eS9zZXJpYWwvb21hcC1zZXJpYWwuYwo+Pj4gaW5k ZXggODk3NDE2Zi4uZWU5NDI5MSAxMDA2NDQKPj4+IC0tLSBhL2RyaXZlcnMvdHR5L3NlcmlhbC9v bWFwLXNlcmlhbC5jCj4+PiArKysgYi9kcml2ZXJzL3R0eS9zZXJpYWwvb21hcC1zZXJpYWwuYwo+ Pj4gQEAgLTEwMDgsNyArMTAwOCwyMiBAQCBzZXJpYWxfb21hcF9jb25zb2xlX3dyaXRlKHN0cnVj dCBjb25zb2xlICpjbywgY29uc3QgY2hhciAqcywKPj4+IMKgIMKgIMKgIHN0cnVjdCB1YXJ0X29t YXBfcG9ydCAqdXAgPSBzZXJpYWxfb21hcF9jb25zb2xlX3BvcnRzW2NvLT5pbmRleF07Cj4+PiDC oCDCoCDCoCB1bnNpZ25lZCBsb25nIGZsYWdzOwo+Pj4gwqAgwqAgwqAgdW5zaWduZWQgaW50IGll cjsKPj4+IC0gwqAgwqAgaW50IGxvY2tlZCA9IDE7Cj4+PiArIMKgIMKgIGludCBjb25zb2xlX2xv Y2sgPSAwLCBsb2NrZWQgPSAxOwo+Pj4gKwo+Pj4gKyDCoCDCoCBpZiAoY29uc29sZV90cnlsb2Nr KCkpCj4+PiArIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnNvbGVfbG9jayA9IDE7Cj4+Cj4+IFNvIG5v dyB3ZSB0YWtlIHRoZSBjb25zb2xlIGxvY2sgb24gKmV2ZXJ5KiBjb25zb2xlIHdyaXRlPyDCoEV2 ZW4gaWYgdGhlCj4+IGRldmljZSBpcyBub3QgYWJvdXQgdG8gYmUgaWRsZWQ/IMKgIFRoaXMgaXMg cmF0aGVyIG92ZXItcHJvdGVjdGl2ZSwgZG9uJ3QKPj4geW91IHRoaW5rPwo+Pgo+Cj4gVGhpcyBz Y2VuYXJpbyBpcyBiZWNhdXNlIG9mIHByaW50IGZyb20KPiBvbWFwX3VhcnRfY29uc29sZV93cml0 ZSAtLT4gZ2V0X3N5bmMgLS0+IG9tYXBfZW5hYmxlX2VuYWJsZQo+IHRyeWluZyB0byBwcmludCB3 b3JzdCBhY3RpdmF0ZSBvciBkZWFjdGl2YXRlIGxhdGVuY3kgc29tZSB0aW1lcy4KPgo+IHdpbGwg cmVzdWx0IGluIHJlY3Vyc2l2ZSBwcmludCBzY2VuYXJpby4KPgo+IGhvbGRpbmcgY29uc29sZSBs b2NrIHdpbGwgb25seSBlbnN1cmUgdGhhdCB0aGUgcHJpbnQgZnJvbSBnZXRfc3luYyBnZXRzCj4g bG9nZ2VkIHRvIGJlIHByaW50ZWQgbGF0ZXIgdG8gY29uc29sZS4KClllcywgYnV0IG15IHByb2Js ZW0gaXMgeW91IG5vdyBob2xkIGEgbG9jayBmb3IgKmV2ZXJ5KiBjb25zb2xlIHdyaXRlLApldmVu IHdoZW4gdGhlIFVBUlQgaXMgbm90IGluIHRoZSBwcm9jZXNzIG9mIGJlaW5nIGVuYWJsZWQvZGlz YWJsZWQuCgpUaGUgcG9pbnQgaXMgdGhhdCBpdCBzaG91bGQgb25seSBiZSBoZWxkIHdoZW4geW91 J3JlIGFib3V0IHRvIGRpc2FibGUKdGhlIFVBUlQgKG9yIHlvdSBrbm93IGl0J3MgYWxyZWFkeSBk aXNhYmxlZCksIGFuZCB0aGUgcG9pbnQgd2hlcmUgeW91Cmtub3cgdGhpcyBpcyBleGFjdGx5IGF0 IHRoZSAucnVudGltZV9zdXNwZW5kIGNhbGxiYWNrLgoKPj4+ICsgwqAgwqAgLyoKPj4+ICsgwqAg wqAgwqAqIElmIGNvbnNvbGVfbG9jayBpcyBub3QgYXZhaWxhYmxlIGFuZCB3ZSBhcmUgaW4gc3Vz cGVuZGluZwo+Pj4gKyDCoCDCoCDCoCogc3RhdGUgdGhlbiB3ZSBjYW4gYXZvaWQgdGhlIGNvbnNv bGUgdXNhZ2Ugc2NlbmFyaW8KPj4KPj4gcy9pbiBzdXNwZW5kaW5nIHN0YXRlL3J1bnRpbWUgc3Vz cGVuZGluZy8KPgo+IG9rLgo+Cj4+Cj4+PiArIMKgIMKgIMKgKiBhcyB0aGlzIG1heSBpbnRyb2R1 Y2UgcmVjdXJzaXZlIHByaW50cy4KPj4+ICsgwqAgwqAgwqAqIEJhc2ljYWxseSB0aGlzIHNjZW5h cmlvIG9jY3VycyBkdXJpbmcgYm9vdCB3aGlsZQo+Pj4gKyDCoCDCoCDCoCogcHJpbnRpbmcgZGVi dWcgYm9vdGxvZ3MuCj4+Cj4+IFRoZSBleGFjdCBzY2VuYXJpbyBmb3IgdHJpZ2dlcmluZyB0aGlz IHN0aWxsIG5vdCB3ZWxsIGRlc2NyaWJlZCwgYW5kCj4+IHRodXMgc3RpbGwgSSBkb24ndCBnZXQg aXQuCj4+Cj4KPiBzY2VuYXJpbyBpcyBzYW1lIGFzIHNhaWQgYWJvdmUuCgpXaGljaCBhcyBJIHNh aWQsIGlzIG5vdCB3ZWxsIGRlc2NyaWJlZC4KCj4gb21hcF91YXJ0X2NvbnNvbGVfd3JpdGUgLS0+ IGdldF9zeW5jIC0tPiBvbWFwX2RldmljZQo+Cj4gcHJpbnRrIHdvcnN0IGFjdGl2YXRlIGxhdGVu Y3kgY2FsbHMgb21hcF91YXJ0X2NvbnNvbGUgd3JpdGUuCj4KPiBhZnRlciBib290IHVwIHdlIGhh dmUgYWNjZXNzIHRvIGNvbnNvbGUgbG9jaywKPiBidXQgZHVyaW5nIGJvb3QgdXAgd2UgZG9uJ3Qg aGF2ZSBjb25zb2xlIGxvY2sgYXZhaWxhYmxlCj4gYW5kIHJlc3VsdHMgaW4gcHJpbnRrIHJlY3Vy c2l2ZW5lc3MuCgpUaGVuIGxlYXZlIFVBUlQgcnVudGltZSBQTSBkaXNhYmxlZCBkdXJpbmcgYm9v dHVwLgoKPj4gSSBzdGlsbCBkb24ndCBmdWxseSB1bmRlcnN0YW5kIHRoaXMgcHJvYmxlbSwKPgo+ IGJhc2ljYWxseSBpdHMgZHVlIHRvIHJlY3Vyc2l2ZSBwcmludGsgZHVyaW5nIGJvb3R1cAo+IGFu ZCBhbHNvIGFmdGVyIGJvb3R1cCBhcyBzYWlkIGFib3ZlLgoKWW91J3ZlIHNhaWQgYWxsIG9mIHRo ZXNlIHRoaW5ncywgYnV0IGFyZSBtaXhpbmcgdGhlbSB0b2dldGhlciBpbiBhIHdheQp0aGF0IGlz IHZlcnkgZGlmZmljdWx0IHRvIHVuZGVyc3RhbmQuCgpQbGVhc2Ugc2VwYXJhdGUgb3V0IHRoZSBi b290LXVwIHByb2JsZW0gZnJvbSB0aGUgcmVjdXJzaXZlIHdyaXRlIHByb2JsZW0KYW5kIG1ha2Ug MiBzZXBhcmF0ZSBwYXRjaGVzIHdpdGggdHdvIHNlcGFyYXRlIGRlc2NyaXB0aXZlIGNoYW5nZWxv Z3MgZm9yCnRoZW0uCgo+PiBidXQgaWYgaXQncyBpc29sYXRlZCB0bwo+PiBydW50aW1lIHN1c3Bl bmRpbmcsIG1heWJlIHlvdSBuZWVkIGEgY29uc29sZSBsb2NrIGluIHRoZSBydW50aW1lX3N1c3Bl bmQKPj4gcGF0aCAobGlrZSB5b3UgYWxyZWFkeSBoYXZlIGluIHRoZSBzdGF0aWMgc3VzcGVuZCBw YXRoLikKPgo+IGNvbnNvbGVfbG9jayBpbiBydW50aW1lX3N1c3BlbmQgd2lsbCBub3QgaGVscAo+ IGR1cmluZyBib290dXAgCgpJIHVuZGVyc3RhbmQgaXQgd29udCBoZWxwIHdoZW4gdGhlIGNvbnNv bGUgbG9jayBoYXMgbm90IGJlZW4KaW5pdGlhbGl6ZWQsIGFuZCB0aGlzIGlzIGEgc2VwYXJhdGUg cHJvYmxlbSAoYW5kIG5lZWRzIGEgc2VwYXJhdGUgZml4KSwKYnV0Li4uCgo+IGFuZCBkdWUgdG8g cHJpbnRrIGVtZXJnaW5nIG91dCBmcm9tIG9tYXBfZGV2aWNlIGVuYWJsZSBhZnRlciBzeXN0ZW0K PiBib290dXAuCgpXaHkgZG9lc24ndCBhIHByaW50ayBhZnRlciBhbiBvbWFwX2RldmljZSAqZW5h YmxlKiB3b3JrPyAgVGhlIFVBUlQKc2hvdWxkIGJlIGVuYWJsZWQgYnkgdGhhdCBwb2ludC4KIApJ biBhbnkgY2FzZSwgdGhlIG9tYXBfZGV2aWNlX2VuYWJsZSBpcyB0aGUgcmVzdWx0IG9mIGEgcnVu dGltZSBQTQpyZXF1ZXN0LCBzbyB0aGUgbG9ja2luZyBmb3IgdGhpcyBwcm9ibGVtIHNob3VsZCBi ZSBoYW5kbGVkIGluIHRoZQpydW50aW1lIFBNIGNhbGxiYWNrcy4KCj4KPj4KPj4+ICsgwqAgwqAg wqAqLwo+Pj4gKwo+Pj4gKyDCoCDCoCBpZiAoIWNvbnNvbGVfbG9jayAmJgo+Pj4gKyDCoCDCoCDC oCDCoCDCoCDCoCB1cC0+cGRldi0+ZGV2LnBvd2VyLnJ1bnRpbWVfc3RhdHVzID09IFJQTV9TVVNQ RU5ESU5HKQo+Pj4gKyDCoCDCoCDCoCDCoCDCoCDCoCByZXR1cm47Cj4+Cj4+IEFzc3VtaW5nIHRo aXMgd2FzIGEgcHJpbnRrLCBpdCdzIG5vdyBsb3N0LCByaWdodD8gwqAgTm90IHN1cmUgdGhhdCdz IGFuCj4+IGFjY2VwdGFibGUgc29sdXRpb24uCj4+Cj4KPiBBRkFJSyBpdCBnZXRzIGxvZ2dlZCBw cmludHMgbGF0ZXIuCgpIb3cgd2lsbCBpdCBnZXQgd3JpdHRlbiBsYXRlcj8gIFRoZXJlIGlzIG5v IHJldHVybiB2YWx1ZSB0byB0aGlzCmZ1bmN0aW9uLCBzbyBoZSBjYWxsZXIgY2FuJ3Qga25vdyBp ZiBpdCBoYXMgc3VjY2VlZGVkIG9yIGZhaWxlZCwgc28gaXQKb2J2aW91c2x5IGFzc3VtZXMgdGhh dCB0aGUgZGF0YSB3YXMgd3JpdHRlbiB0byB0aGUgVUFSVC4KCj4gdG8gc3VtbWFyaXplIGhvbGRp bmcgY29uc29sZSBsb2NrIGhlbHBzIGFmdGVyIGJvb3R1cAo+IHNpbmNlIGR1cmluZyBib290IHVw IGNvbnNvbGUgbG9jayBpcyBub3QgYXZhaWxhYmxlIG5lZWQgdG8gdXNlCj4gYWJvdmUgcnVudGlt ZV9zdGF0dXMgY2hlY2suCgpUaGUgcG9pbnQgaXMgeW91J3ZlIGZpeGVkIGEgc21hbGwgcHJvYmxl bSB3aXRoIGEgdmVyeSBiaWctaGFtbWVyCnNvbHV0aW9uLgoKVGhlIHByb2JsZW0geW91IGhhdmUg b2NjdXJzIGJlY2F1c2Ugb2YgdHdvIGRpZmZlcmVudCBjYXVzZXMgdGhhdCBuZWVkCnR3byBkaWZm ZXJlbnQgd2VsbC10YXJnZXRlZCBzb2x1dGlvbnMuCgpLZXZpbgoKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBs aXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5m cmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@ti.com (Kevin Hilman) Date: Mon, 27 Jun 2011 15:41:39 -0700 Subject: [PATCH v3 05/12] OMAP: Serial: Hold console lock for console usage. In-Reply-To: (Govindraj's message of "Mon, 27 Jun 2011 19:05:06 +0530") References: <1307532194-13039-1-git-send-email-govindraj.raja@ti.com> <1307532194-13039-6-git-send-email-govindraj.raja@ti.com> <87boxmsrjt.fsf@ti.com> Message-ID: <878vsm99ss.fsf@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Govindraj writes: > On Sat, Jun 25, 2011 at 5:36 AM, Kevin Hilman wrote: >> "Govindraj.R" writes: >> >>> Acquire console lock before enabling and writing to console-uart >>> to avoid any recursive prints from console write. >>> for ex: >>> ? ? ? ? --> printk >>> ? ? ? ? ? --> uart_console_write >>> ? ? ? ? ? ? --> get_sync >>> ? ? ? ? ? ? ? --> printk from omap_device enable >>> ? ? ? ? ? ? ? ? --> uart_console write >>> >>> Use RPM_SUSPENDING check to avoid below scenario during bootup >>> As during bootup console_lock is not available. >>> ? ? ? ?--> uart_add_one_port >>> ? ? ? ? ? ?--> console_register >>> ? ? ? ? ? ? ? ?--> console_lock >>> ? ? ? ? ? ? ? ? --> console_unlock >>> ? ? ? ? ? ? ? ? ? ? ?--> call_console_drivers (here yet console_lock is not released) >>> ? ? ? ? ? ? ? ? ? ? ? ? ? --> uart_console_write >>> >>> Acked-by: Alan Cox >>> Signed-off-by: Govindraj.R >>> --- >>> ?drivers/tty/serial/omap-serial.c | ? 20 +++++++++++++++++++- >>> ?1 files changed, 19 insertions(+), 1 deletions(-) >>> >>> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c >>> index 897416f..ee94291 100644 >>> --- a/drivers/tty/serial/omap-serial.c >>> +++ b/drivers/tty/serial/omap-serial.c >>> @@ -1008,7 +1008,22 @@ serial_omap_console_write(struct console *co, const char *s, >>> ? ? ? struct uart_omap_port *up = serial_omap_console_ports[co->index]; >>> ? ? ? unsigned long flags; >>> ? ? ? unsigned int ier; >>> - ? ? int locked = 1; >>> + ? ? int console_lock = 0, locked = 1; >>> + >>> + ? ? if (console_trylock()) >>> + ? ? ? ? ? ? console_lock = 1; >> >> So now we take the console lock on *every* console write? ?Even if the >> device is not about to be idled? ? This is rather over-protective, don't >> you think? >> > > This scenario is because of print from > omap_uart_console_write --> get_sync --> omap_enable_enable > trying to print worst activate or deactivate latency some times. > > will result in recursive print scenario. > > holding console lock will only ensure that the print from get_sync gets > logged to be printed later to console. Yes, but my problem is you now hold a lock for *every* console write, even when the UART is not in the process of being enabled/disabled. The point is that it should only be held when you're about to disable the UART (or you know it's already disabled), and the point where you know this is exactly at the .runtime_suspend callback. >>> + ? ? /* >>> + ? ? ?* If console_lock is not available and we are in suspending >>> + ? ? ?* state then we can avoid the console usage scenario >> >> s/in suspending state/runtime suspending/ > > ok. > >> >>> + ? ? ?* as this may introduce recursive prints. >>> + ? ? ?* Basically this scenario occurs during boot while >>> + ? ? ?* printing debug bootlogs. >> >> The exact scenario for triggering this still not well described, and >> thus still I don't get it. >> > > scenario is same as said above. Which as I said, is not well described. > omap_uart_console_write --> get_sync --> omap_device > > printk worst activate latency calls omap_uart_console write. > > after boot up we have access to console lock, > but during boot up we don't have console lock available > and results in printk recursiveness. Then leave UART runtime PM disabled during bootup. >> I still don't fully understand this problem, > > basically its due to recursive printk during bootup > and also after bootup as said above. You've said all of these things, but are mixing them together in a way that is very difficult to understand. Please separate out the boot-up problem from the recursive write problem and make 2 separate patches with two separate descriptive changelogs for them. >> but if it's isolated to >> runtime suspending, maybe you need a console lock in the runtime_suspend >> path (like you already have in the static suspend path.) > > console_lock in runtime_suspend will not help > during bootup I understand it wont help when the console lock has not been initialized, and this is a separate problem (and needs a separate fix), but... > and due to printk emerging out from omap_device enable after system > bootup. Why doesn't a printk after an omap_device *enable* work? The UART should be enabled by that point. In any case, the omap_device_enable is the result of a runtime PM request, so the locking for this problem should be handled in the runtime PM callbacks. > >> >>> + ? ? ?*/ >>> + >>> + ? ? if (!console_lock && >>> + ? ? ? ? ? ? up->pdev->dev.power.runtime_status == RPM_SUSPENDING) >>> + ? ? ? ? ? ? return; >> >> Assuming this was a printk, it's now lost, right? ? Not sure that's an >> acceptable solution. >> > > AFAIK it gets logged prints later. How will it get written later? There is no return value to this function, so he caller can't know if it has succeeded or failed, so it obviously assumes that the data was written to the UART. > to summarize holding console lock helps after bootup > since during boot up console lock is not available need to use > above runtime_status check. The point is you've fixed a small problem with a very big-hammer solution. The problem you have occurs because of two different causes that need two different well-targeted solutions. Kevin