From: "Guzman Lugo, Fernando" <fernando.lugo@ti.com> To: Felipe Contreras <felipe.contreras@nokia.com>, "felipe.contreras@gmail.com" <felipe.contreras@gmail.com> Cc: "gregkh@suse.de" <gregkh@suse.de>, "hiroshi.doyu@nokia.com" <hiroshi.doyu@nokia.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: RE: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map Date: Tue, 26 Oct 2010 13:08:15 -0500 [thread overview] Message-ID: <496565EC904933469F292DDA3F1663E602F49E28BD@dlee06.ent.ti.com> (raw) In-Reply-To: <1288112616-notmuch-felipe.contreras@nokia.com> > -----Original Message----- > From: Felipe Contreras [mailto:felipe.contreras@nokia.com] > Sent: Tuesday, October 26, 2010 12:08 PM > To: Guzman Lugo, Fernando; felipe.contreras@gmail.com > Cc: gregkh@suse.de; hiroshi.doyu@nokia.com; > linux-kernel@vger.kernel.org; andy.shevchenko@gmail.com; > linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org > Subject: RE: [PATCH 1/8] staging: tidspbridge - remove > req_addr from proc_map > > fernando.lugo@ti.com wrote: > > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo > > > <x0095840@ti.com> wrote: > > > > The device address is assigned by tidspbridge no need for > > > that parameter anymore. > > > > > > > > Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com> > > > > > > This would break the API with user-space, right? > > > > Yes, user-space needs to be changed accordingly. > > Wouldn't it make sense to avoid stuffing so many changes at > once including ABI breakage? > > Does user-space really _needs_ to be changed? Can't you just > ignore that argument? Actually, I had a previous version of that patch where I only Ignored that paramteter. But after thinking again and seeing How the long time ago depreacted function are still there I Removed the parameter in order to force apps to make the change. You can ignore that argument at API level, so all users of the API not need to have change (in that momment). That should be Only few line change. > > > > I think this change should be delayed, preferably after we have a > > > working tidspbridge. > > > > The issue you were seeing must be fixed with patch 2/8, and > Having all > > the dependencies tidspbridge has to be working Properly. > > Yes, which might not happen at .37. If we revert the iommu > stuff, we might have a chance at having a working bridge on .37. But havi that merged in tidspbridge make more pressure to merged The dependencies, if not maybe that wont have event for .38. But That is just my opinion if you all are agree revert is the best Option I am ok, but I looks like more work reverting and rebaseing specially because it is a big change. Thanks and regards, Fernando. > > -- > Felipe Contreras >
WARNING: multiple messages have this Message-ID (diff)
From: fernando.lugo@ti.com (Guzman Lugo, Fernando) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map Date: Tue, 26 Oct 2010 13:08:15 -0500 [thread overview] Message-ID: <496565EC904933469F292DDA3F1663E602F49E28BD@dlee06.ent.ti.com> (raw) In-Reply-To: <1288112616-notmuch-felipe.contreras@nokia.com> > -----Original Message----- > From: Felipe Contreras [mailto:felipe.contreras at nokia.com] > Sent: Tuesday, October 26, 2010 12:08 PM > To: Guzman Lugo, Fernando; felipe.contreras at gmail.com > Cc: gregkh at suse.de; hiroshi.doyu at nokia.com; > linux-kernel at vger.kernel.org; andy.shevchenko at gmail.com; > linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org > Subject: RE: [PATCH 1/8] staging: tidspbridge - remove > req_addr from proc_map > > fernando.lugo at ti.com wrote: > > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo > > > <x0095840@ti.com> wrote: > > > > The device address is assigned by tidspbridge no need for > > > that parameter anymore. > > > > > > > > Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com> > > > > > > This would break the API with user-space, right? > > > > Yes, user-space needs to be changed accordingly. > > Wouldn't it make sense to avoid stuffing so many changes at > once including ABI breakage? > > Does user-space really _needs_ to be changed? Can't you just > ignore that argument? Actually, I had a previous version of that patch where I only Ignored that paramteter. But after thinking again and seeing How the long time ago depreacted function are still there I Removed the parameter in order to force apps to make the change. You can ignore that argument at API level, so all users of the API not need to have change (in that momment). That should be Only few line change. > > > > I think this change should be delayed, preferably after we have a > > > working tidspbridge. > > > > The issue you were seeing must be fixed with patch 2/8, and > Having all > > the dependencies tidspbridge has to be working Properly. > > Yes, which might not happen at .37. If we revert the iommu > stuff, we might have a chance at having a working bridge on .37. But havi that merged in tidspbridge make more pressure to merged The dependencies, if not maybe that wont have event for .38. But That is just my opinion if you all are agree revert is the best Option I am ok, but I looks like more work reverting and rebaseing specially because it is a big change. Thanks and regards, Fernando. > > -- > Felipe Contreras >
next prev parent reply other threads:[~2010-10-26 18:08 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-10-26 0:51 [PATCH 0/8] staging: tidspbridge - misc fixes Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` [PATCH 2/8] staging: tidspbridge - add kconfig parameter for DMM size Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` [PATCH 3/8] staging: tidspbridge - change mmufault tasklet to a workqueue Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` [PATCH 4/8] staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` [PATCH 5/8] staging: tidspbridge - use GTP7 for DSP stack dump Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` [PATCH 6/8] staging: tidspbridge - remove disabling twl when printing DSP stack Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` [PATCH 7/8] staging: tidspbridge - fix some issues after iommu patches Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:51 ` Fernando Guzman Lugo 2010-10-26 0:58 ` Felipe Contreras 2010-10-26 0:58 ` Felipe Contreras 2010-10-26 15:50 ` Guzman Lugo, Fernando 2010-10-26 15:50 ` Guzman Lugo, Fernando 2010-10-26 15:50 ` Guzman Lugo, Fernando 2010-10-26 17:03 ` Felipe Contreras 2010-10-26 17:03 ` Felipe Contreras 2010-10-26 17:58 ` Guzman Lugo, Fernando 2010-10-26 17:58 ` Guzman Lugo, Fernando 2010-10-26 17:58 ` Guzman Lugo, Fernando 2010-10-26 19:27 ` Felipe Contreras 2010-10-26 19:27 ` Felipe Contreras 2010-10-26 20:01 ` Guzman Lugo, Fernando 2010-10-26 20:01 ` Guzman Lugo, Fernando 2010-10-26 20:01 ` Guzman Lugo, Fernando 2010-12-06 8:51 ` Ramirez Luna, Omar 2010-12-06 8:51 ` Ramirez Luna, Omar 2010-10-26 11:46 ` [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map Felipe Contreras 2010-10-26 11:46 ` Felipe Contreras 2010-10-26 15:52 ` Guzman Lugo, Fernando 2010-10-26 15:52 ` Guzman Lugo, Fernando 2010-10-26 15:52 ` Guzman Lugo, Fernando 2010-10-26 17:07 ` Felipe Contreras 2010-10-26 17:07 ` Felipe Contreras 2010-10-26 18:08 ` Guzman Lugo, Fernando [this message] 2010-10-26 18:08 ` Guzman Lugo, Fernando 2010-10-26 18:08 ` Guzman Lugo, Fernando 2010-10-26 19:37 ` Felipe Contreras 2010-10-26 19:37 ` Felipe Contreras 2010-10-26 20:39 ` Guzman Lugo, Fernando 2010-10-26 20:39 ` Guzman Lugo, Fernando 2010-10-26 20:39 ` Guzman Lugo, Fernando 2010-10-27 8:19 ` Felipe Contreras 2010-10-27 8:19 ` Felipe Contreras 2010-10-27 8:19 ` Felipe Contreras 2010-10-28 15:38 ` Guzman Lugo, Fernando 2010-10-28 15:38 ` Guzman Lugo, Fernando 2010-10-28 15:38 ` Guzman Lugo, Fernando 2010-10-28 15:56 ` Russell King - ARM Linux 2010-10-28 15:56 ` Russell King - ARM Linux 2010-10-28 15:56 ` Russell King - ARM Linux 2010-10-26 4:06 ` [PATCH 0/8] staging: tidspbridge - misc fixes Greg KH 2010-10-26 4:06 ` Greg KH 2010-10-26 14:43 ` Felipe Contreras 2010-10-26 14:43 ` Felipe Contreras 2010-10-26 14:55 ` Omar Ramirez Luna 2010-10-26 14:55 ` Omar Ramirez Luna 2010-10-26 14:55 ` Omar Ramirez Luna 2010-10-26 15:46 ` Guzman Lugo, Fernando 2010-10-26 15:46 ` Guzman Lugo, Fernando 2010-10-26 15:46 ` Guzman Lugo, Fernando
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=496565EC904933469F292DDA3F1663E602F49E28BD@dlee06.ent.ti.com \ --to=fernando.lugo@ti.com \ --cc=andy.shevchenko@gmail.com \ --cc=felipe.contreras@gmail.com \ --cc=felipe.contreras@nokia.com \ --cc=gregkh@suse.de \ --cc=hiroshi.doyu@nokia.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.