Re: [PATCH v2 1/4] android: binder: Don't get mm from task
On Tue, Oct 24, 2017 at 11:36:48AM -0700, Arve Hjønnevåg wrote: > On Tue, Oct 24, 2017 at 12:28 AM, Greg Kroah-Hartman > wrote: > > On Mon, Oct 23, 2017 at 11:18:52AM -0700, Arve Hjønnevåg wrote: > >> On Sat, Oct 21, 2017 at 1:15 AM, Greg Kroah-Hartman > >> wrote: > >> > On Fri, Oct 20, 2017 at 08:58:58PM -0400, Sherry Yang wrote: > >> >> Use binder_alloc struct's mm_struct rather than getting > >> >> a reference to the mm struct through get_task_mm to > >> >> avoid a potential deadlock between lru lock, task lock and > >> >> dentry lock, since a thread can be holding the task lock > >> >> and the dentry lock while trying to acquire the lru lock. > >> >> > >> >> Acked-by: Arve Hjønnevåg > >> >> Signed-off-by: Sherry Yang > >> >> --- > >> >> drivers/android/binder_alloc.c | 22 +- > >> >> drivers/android/binder_alloc.h | 1 - > >> >> 2 files changed, 9 insertions(+), 14 deletions(-) > >> > > >> > I've applied these first 2 patches, but patches 3 and 4 I have already > >> > applied to my char-misc-next tree, right? > >> > > >> > thanks, > >> > > >> > greg k-h > >> > >> I would expect you got a merge conflict from one of those. Using patch > >> 3 and 4 in from this patchset should avoid that conflict if your > >> eventual 4.15 branch is not based on your current char-misc-next > >> branch. > > > > I've resolved the merge conflict so my char-misc-next branch should be > > all caught up now. It would be wonderful if you could verify this. > > > > thanks, > > > > greg k-h > > I have not tested your branch directly, but the relevant code in > char-misc-next is now identical to the code I tested. Wonderful, thanks for verifying. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ccree: Fix lines longer than 80 characters
On Tue, Oct 24, 2017 at 11:52:58PM -0700, Stephen Brennan wrote: > Hi Gilad & Tobin, > > > > Perhaps, if Stephen is willing, re-write the code to be more readable > > > by, for example, using a temp > > > variable for the register address, and in doing so both making the > > > code more readable as well as > > > treating the symptom? > > I'm definitely willing; however, I don't know the hardware, so I'm already > off to a bad start with questions like "which integer type is appropriate > for the register address?" > > > Oh, refactoring, that's a whole 'nother story. I'm a huge fan. And I agree > > with you that that is the > > correct way to deal with 'line over 80' warnings. For me, it helped to get > > a few _trivial_ > > checkpatch fixes in before I moved onto refactoring. 'line over 80' > > warnings are great to fix if > > viewed as an opportunity to refactor but not so great if viewed as a > > trivial white space fix to get > > started with. > > I think this makes the most sense right now. A pure trivial change is what > I'd like, to help get some experience with the development process and > working with the community. I'll look for something else (hopefully within > the same staging driver, since you've all been super welcoming) and submit > a patch for it. Hopefully I'll circle back for some slightly less trivial > refactors after that! When you want to link a few patches together into a series I wrote a blog post a while back, check it out if you want some further guidance http://tobin.cc/blog/kernel-dev-2/ Stick at it. There ain't nothin' to it but to do it Good luck, Tobin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 02/26] staging: most: integrate driver in kernel's device model
On Tue, Oct 24, 2017 at 07:39:02PM +0200, Christian Gromm wrote: > On Fri, 20 Oct 2017 16:56:10 +0200 > Greg KH wrote: > > > On Fri, Oct 20, 2017 at 04:20:33PM +0200, Christian Gromm wrote: > > > On 18.10.2017 16:29, Greg KH wrote: > > > > On Wed, Oct 18, 2017 at 04:02:33PM +0200, Christian Gromm wrote: > > > > > On 18.10.2017 14:12, Greg KH wrote: > > > > > > On Mon, Oct 16, 2017 at 10:46:09AM +0200, Christian Gromm > > > > > > wrote: > > > > > > > The following patch adapts the driver to use the device > > > > > > > model by: > > > > > > > > > > > > > > - adopting the MOST bus_type > > > > > > > - registering the core as a busdriver > > > > > > > - removing private kobject/kset usage > > > > > > > - removing private lists and structures to track > > > > > > > registered modules and making use of the device model API > > > > > > > - removing prefix of modules > > > > > > > - allowing adapter drivers (a.k.a. HDM) to register > > > > > > > MOST devices > > > > > > > - registering AIM modules as components with the > > > > > > > core to build the user space experience of the driver stack > > > > > > > - using attribute groups to create the sysfs files > > > > > > > - renaming variables to prevent collision with the > > > > > > > introduced device structs. > > > > > > > > > > > > Hint, when you have to enumerate a list of different things > > > > > > you do in a single patch, that is a _huge_ sign that the > > > > > > patch needs to be broken up into smaller pieces, each piece > > > > > > only doing one logical thing. > > > > > > > > > > > > > > > > This is a huge reconstruction of the driver architecture that > > > > > requires more than one thing be done at a time. Breaking this > > > > > up into tiny patches might render the sources broken, if you > > > > > don't apply the complete series. (Which is also a no-go, right?) > > > > > > > > > > Since staging is meant to be the place to fix things up, > > > > > I thought I'd get away with this. Anyways, I'll try... > > > > > > > > Try to make it into something that you would want to be able to > > > > review :) > > > > > > > > > > Well... ok then. > > > > > > Do think you can spend an extra minute in Prague next week, so we > > > can talk about what's next? > > > > Sure, but to start with, getting this patch series into a mergable > > state is "what is next" :) > > > > What about Wednesday, the slot right before (or right after) lunch time? > Does this happen to fit in your schedule? Ugh, I missed this email earlier, sorry. How about during the coffee break time today? Want to meet at the registration desk at 3:45? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 02/26] staging: most: integrate driver in kernel's device model
On Wed, 25 Oct 2017 14:22:58 +0200 Greg KH wrote: > On Tue, Oct 24, 2017 at 07:39:02PM +0200, Christian Gromm wrote: > > On Fri, 20 Oct 2017 16:56:10 +0200 > > Greg KH wrote: > > > > > On Fri, Oct 20, 2017 at 04:20:33PM +0200, Christian Gromm wrote: > > > > On 18.10.2017 16:29, Greg KH wrote: > > > > > On Wed, Oct 18, 2017 at 04:02:33PM +0200, Christian Gromm > > > > > wrote: > > > > > > On 18.10.2017 14:12, Greg KH wrote: > > > > > > > On Mon, Oct 16, 2017 at 10:46:09AM +0200, Christian Gromm > > > > > > > wrote: > > > > > > > > The following patch adapts the driver to use the device > > > > > > > > model by: > > > > > > > > > > > > > > > > - adopting the MOST bus_type > > > > > > > > - registering the core as a busdriver > > > > > > > > - removing private kobject/kset usage > > > > > > > > - removing private lists and structures to track > > > > > > > > registered modules and making use of the device model > > > > > > > > API > > > > > > > > - removing prefix of modules > > > > > > > > - allowing adapter drivers (a.k.a. HDM) to > > > > > > > > register MOST devices > > > > > > > > - registering AIM modules as components with the > > > > > > > > core to build the user space experience of the driver > > > > > > > > stack > > > > > > > > - using attribute groups to create the sysfs > > > > > > > > files > > > > > > > > - renaming variables to prevent collision with > > > > > > > > the introduced device structs. > > > > > > > > > > > > > > Hint, when you have to enumerate a list of different > > > > > > > things you do in a single patch, that is a _huge_ sign > > > > > > > that the patch needs to be broken up into smaller pieces, > > > > > > > each piece only doing one logical thing. > > > > > > > > > > > > > > > > > > > This is a huge reconstruction of the driver architecture > > > > > > that requires more than one thing be done at a time. > > > > > > Breaking this up into tiny patches might render the sources > > > > > > broken, if you don't apply the complete series. (Which is > > > > > > also a no-go, right?) > > > > > > > > > > > > Since staging is meant to be the place to fix things up, > > > > > > I thought I'd get away with this. Anyways, I'll try... > > > > > > > > > > Try to make it into something that you would want to be able > > > > > to review :) > > > > > > > > > > > > > Well... ok then. > > > > > > > > Do think you can spend an extra minute in Prague next week, so > > > > we can talk about what's next? > > > > > > Sure, but to start with, getting this patch series into a mergable > > > state is "what is next" :) > > > > > > > What about Wednesday, the slot right before (or right after) lunch > > time? Does this happen to fit in your schedule? > > Ugh, I missed this email earlier, sorry. How about during the coffee > break time today? Want to meet at the registration desk at 3:45? > Too bad, this time I missed it. Seems like email isn't the best choice when trying to arrange a spontaneous meeting, is it? Anyways, I'll try to break down the patches and resend them. This will take me some time, though. I just finished to split #1, which was ok using git's interactive rebase, since the changes were limited to files. But #2 is killing me. regards Chris ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: Fix space before '[' error.
Fix checkpatch.pl error:
ERROR: space prohibited before open square bracket '['.
Signed-off-by: Arvind Yadav
---
drivers/staging/rtl8723bs/os_dep/rtw_proc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/rtw_proc.c
b/drivers/staging/rtl8723bs/os_dep/rtw_proc.c
index 9227745..3f18cb1 100644
--- a/drivers/staging/rtl8723bs/os_dep/rtw_proc.c
+++ b/drivers/staging/rtl8723bs/os_dep/rtw_proc.c
@@ -87,7 +87,7 @@ static ssize_t proc_set_log_level(struct file *file, const
char __user *buffer,
* rtw_drv_proc:
* init/deinit when register/unregister driver
*/
-static const struct rtw_proc_hdl drv_proc_hdls [] = {
+static const struct rtw_proc_hdl drv_proc_hdls[] = {
{"ver_info", proc_get_drv_version, NULL},
{"log_level", proc_get_log_level, proc_set_log_level},
};
@@ -363,7 +363,7 @@ static int proc_get_cam_cache(struct seq_file *m, void *v)
* rtw_adapter_proc:
* init/deinit when register/unregister net_device
*/
-static const struct rtw_proc_hdl adapter_proc_hdls [] = {
+static const struct rtw_proc_hdl adapter_proc_hdls[] = {
{"write_reg", proc_get_dummy, proc_set_write_reg},
{"read_reg", proc_get_read_reg, proc_set_read_reg},
{"fwstate", proc_get_fwstate, NULL},
@@ -598,7 +598,7 @@ ssize_t proc_set_odm_adaptivity(struct file *file, const
char __user *buffer, si
* rtw_odm_proc:
* init/deinit when register/unregister net_device, along with rtw_adapter_proc
*/
-static const struct rtw_proc_hdl odm_proc_hdls [] = {
+static const struct rtw_proc_hdl odm_proc_hdls[] = {
{"dbg_comp", proc_get_odm_dbg_comp, proc_set_odm_dbg_comp},
{"dbg_level", proc_get_odm_dbg_level, proc_set_odm_dbg_level},
{"ability", proc_get_odm_ability, proc_set_odm_ability},
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Searching help for Linux support for RTL8812AU
On 10/24/2017 08:24 AM, txt.file wrote: Hey Linux wireless list, A while ago I bought an ALFA Network AWUS036AC[0] which does not yet seem to be supported in Linux mainline. I would like to get it supported. The problem is that I have not that much experience doing software development. kind regards txt.file PS: Please keep me in CC as I am not subscribed to the lists. [0] https://wikidevi.com/wiki/ALFA_Network_AWUS036AC I can provide you with an out-of-kernel driver for the RTL8812AU. Please be aware that these Realtek USB drivers require many changes before they can be accepted into even the staging tree of the kernel. One other consideration is that staging drivers should (must?) have a definite path for inclusion into the main kernel trees. For wireless, this means using mac80211. For these Realtek drivers with their own MAC code, that is a major change. My suggestion is that you work to get your device handled by driver rtl8xxxu, which is in the kernel. I have no idea how much effort that would be, but certainly a lot less than converting the Realtek driver. Larry PS: Please keep the list in the Cc as I tend to disregard private requests for consulting! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH char-misc 1/1] Hyper-V: Remove x86-isms from architecture independent Hyper-V drivers
From: Michael Kelley
hv_is_hypercall_page_setup() is used to check if Hyper-V is
initialized, but a 'hypercall page' is an x86 implementation detail
that isn't necessarily present on other architectures. Rename to the
architecture independent hv_is_hyperv_initialized(). Use this function
instead of direct references to x86-specific data structures in
vmbus_drv.c, and remove 'x86' from the string name passed to
cpuhp_setup_state().
Signed-off-by: Michael Kelley
---
arch/x86/hyperv/hv_init.c | 4 ++--
arch/x86/include/asm/mshyperv.h | 4 ++--
drivers/hv/hv.c | 2 +-
drivers/hv/vmbus_drv.c | 5 ++---
4 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index a5db63f728a2..38310bd091c2 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -236,7 +236,7 @@ void hyperv_report_panic(struct pt_regs *regs)
}
EXPORT_SYMBOL_GPL(hyperv_report_panic);
-bool hv_is_hypercall_page_setup(void)
+bool hv_is_hyperv_initialized(void)
{
union hv_x64_msr_hypercall_contents hypercall_msr;
@@ -249,4 +249,4 @@ bool hv_is_hypercall_page_setup(void)
return true;
}
-EXPORT_SYMBOL_GPL(hv_is_hypercall_page_setup);
+EXPORT_SYMBOL_GPL(hv_is_hyperv_initialized);
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 530f448fddaf..b001f898ccf3 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -311,11 +311,11 @@ void hyperv_init(void);
void hyperv_setup_mmu_ops(void);
void hyper_alloc_mmu(void);
void hyperv_report_panic(struct pt_regs *regs);
-bool hv_is_hypercall_page_setup(void);
+bool hv_is_hyperv_initialized(void);
void hyperv_cleanup(void);
#else /* CONFIG_HYPERV */
static inline void hyperv_init(void) {}
-static inline bool hv_is_hypercall_page_setup(void) { return false; }
+static inline bool hv_is_hyperv_initialized(void) { return false; }
static inline void hyperv_cleanup(void) {}
static inline void hyperv_setup_mmu_ops(void) {}
#endif /* CONFIG_HYPERV */
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 8267439dd1ee..ebad26053362 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -49,7 +49,7 @@ struct hv_context hv_context = {
*/
int hv_init(void)
{
- if (!hv_is_hypercall_page_setup())
+ if (!hv_is_hyperv_initialized())
return -ENOTSUPP;
hv_context.cpu_context = alloc_percpu(struct hv_per_cpu_context);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 1da8e818f4de..12c51dc6bb7b 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -37,7 +37,6 @@
#include
#include
-#include
#include
#include
#include
@@ -1047,7 +1046,7 @@ static int vmbus_bus_init(void)
* Initialize the per-cpu interrupt state and
* connect to the host.
*/
- ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/hyperv:online",
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "hyperv/vmbus:online",
hv_synic_init, hv_synic_cleanup);
if (ret < 0)
goto err_alloc;
@@ -1695,7 +1694,7 @@ static int __init hv_acpi_init(void)
{
int ret, t;
- if (x86_hyper != &x86_hyper_ms_hyperv)
+ if (!hv_is_hyperv_initialized())
return -ENODEV;
init_completion(&probe_event);
--
2.14.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
