RE: [PATCH 09/18] staging/rdma/hfi1: Correctly limit VLs against SDMA engines

> > From: Dean Luick > > > > Correctly reduce the number of VLs when limited by the number of SDMA > > engines. > > why? What does this "solve"? The hardware has multiple egress mechanisms, SDMA and pio, and multiples of those. These mechanisms are chosen using the VL

RE: [PATCH v3] staging/rdma/hfi1: set Gen3 half-swing for integrated devices

> > + dd_dev_info(dd, "%s: program XMT margin, CcePcieCtrl 0x%llx\n", > > + fname, pcie_ctrl); > > Why spam the log with this all the time? Shouldn't this be a debug line > instead? The current implementation is layered on dev_info(). Are you saying dev_dbg() is a better

RE: [PATCH 02/18] staging/rdma/hfi1: Decode CNP opcode

> > Add CNP opcode decode > > Why? Prior to this patch the trace appeared like: -0 [001] d.h. 94062.578932: input_ibhdr: [:05:00.0] vl 0 lver 0 sl 0 lnh 2,LRH_BTH dlid 0003 len 6 slid 0001 op 0x80,0x80 se 0 m 0 pad 0 tver 0 pkey 0x8001 f 0 b 0 qpn 0x001234 a 0 psn 0x Note the

RE: [PATCH 05/18] staging/rdma/hfi1: Clean up comments

> > Clean up comments > > In what way? > The patch deleted numbering and terms internal to intel. The information on the actual bugs is not deleted. Mike ___ devel mailing list de...@linuxdriverproject.org

Re: Future of Lustre in staging

On 11/20/15, Xose Vazquez Perez wrote: > Hi, > > From https://lwn.net/Articles/662979/ > > --cut-- > Christoph complained a bit about the staging tree. He said that it > breaks allmodconfig builds, but that problem was evidently fixed a while > ago. He also dislikes the

Re: HFI1 code duplication todo

At the beginning when hfi1 was put into staging, then it was easy enough for Greg to take those patches but now it feels awkward. Probably Doug and the linux-r...@vger.kernel.org people should start maintaining the drivers/staging/rdma directory. Like merge Greg's tree and pull in whatever

Future of Lustre in staging

Hi, >From https://lwn.net/Articles/662979/ --cut-- Christoph complained a bit about the staging tree. He said that it breaks allmodconfig builds, but that problem was evidently fixed a while ago. He also dislikes the Lustre filesystem, which has been in staging for some time now; Greg agreed and

[PATCH] staging: unisys: visornic: Removed the blank line

Removed the blank line before the close brace to remove the check detected by the checkpatch.pl CHECK: Blank lines aren't necessary before a close brace '}' Signed-off-by: Anjali Menon --- drivers/staging/unisys/visornic/visornic_main.c | 1 - 1 file changed, 1

Re: HFI1 code duplication todo

On 11/20/2015 11:39 AM, Greg KH wrote: > On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: >> To that end, I've opened my 4.4-rc branch and deleted the three >> deprecated drivers from staging and moved hfi1 to the rdma tree. I've >> sent an email to Linus to see if he's ok taking

RE: [PATCH v2 2/2] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

> > drivers/staging/rdma/hfi1/sdma.c | 12 ++-- > > 1 files changed, 10 insertions(+), 2 deletions(-) > > Doesn't apply to my tree :( Ok. Is the inprocess branch available? Mike ___ devel mailing list de...@linuxdriverproject.org

RE: HFI1 code duplication todo

> > To that end, I've opened my 4.4-rc branch and deleted the three deprecated > drivers from staging and moved hfi1 to the rdma tree. I've sent an email to > Linus to see if he's ok taking those changes, and if so, I'll get them > submitted > and then open up my for-4.5 branch early to be able

RE: [PATCH 18/18] staging/rdma/hfi1: Workaround CONFIG_SDMA_VERBOSITY timing issue

> That sounds like a horrid hack, and this implies that a slower machine will > still have this problem... Greg, I'm NAK'ing this patch for two reasons: 1. Code underneath the CONFIG option is only used during rework 2. It is a hack as you have noted We are going to take this up internally to

Re: HFI1 code duplication todo

Hi Doug, before the drivers stops overloading writev vs write (hfi1_file_ops) it MUST not be moved to the main tree. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH v2 2/2] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

> > > > Is the inprocess branch available? > > I do not understand what you mean here :( Does it fail to apply to staging-next or staging-testing or something else? Mike ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH v2 2/2] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

On Fri, Nov 20, 2015 at 04:43:56PM +, Marciniszyn, Mike wrote: > > > > > > Is the inprocess branch available? > > > > I do not understand what you mean here :( > > Does it fail to apply to staging-next or staging-testing or something else? As both trees are now the same, it fails to apply

RE: [PATCH 07/18] staging/rdma/hfi1: Extend quiet timeout

> > The longest quiet timeout is now 6s. Extend the driver wait. > > To what? And why? What does this fix? > The driver wasn't following the our internal specification: 6 seconds. The patch corrects that issue. Mike ___ devel mailing list

RE: [PATCH v3] staging/rdma/hfi1: set Gen3 half-swing for integrated devices

> > Are you saying dev_dbg() is a better choice? > > Yes, why would a user ever want to see that above line? What can they do > with it? Will do. Mike ___ devel mailing list de...@linuxdriverproject.org

Re: HFI1 code duplication todo

On 11/19/2015 05:23 PM, Dennis Dalessandro wrote: > On Thu, Nov 12, 2015 at 04:13:18PM -0500, Dennis Dalessandro wrote: >> The major todo for the hfi1 driver in staging is getting rid of the >> verbs code duplication between ipath, qib, and now hfi1. The ipath >> driver has been deprecated and is

Re: HFI1 code duplication todo

On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > On 11/19/2015 05:23 PM, Dennis Dalessandro wrote: > > On Thu, Nov 12, 2015 at 04:13:18PM -0500, Dennis Dalessandro wrote: > >> The major todo for the hfi1 driver in staging is getting rid of the > >> verbs code duplication between

Re: [PATCH v2 2/2] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

On Fri, Nov 20, 2015 at 03:23:55PM +, Marciniszyn, Mike wrote: > > > drivers/staging/rdma/hfi1/sdma.c | 12 ++-- > > > 1 files changed, 10 insertions(+), 2 deletions(-) > > > > Doesn't apply to my tree :( > > Ok. > > Is the inprocess branch available? I do not understand what

Re: HFI1 code duplication todo

On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > To that end, I've opened my 4.4-rc branch and deleted the three > deprecated drivers from staging and moved hfi1 to the rdma tree. I've > sent an email to Linus to see if he's ok taking those changes, and if > so, I'll get them

Re: [PATCH v3] staging/rdma/hfi1: set Gen3 half-swing for integrated devices

On Fri, Nov 20, 2015 at 03:14:19PM +, Marciniszyn, Mike wrote: > > > + dd_dev_info(dd, "%s: program XMT margin, CcePcieCtrl 0x%llx\n", > > > + fname, pcie_ctrl); > > > > Why spam the log with this all the time? Shouldn't this be a debug line > > instead? > > The current

Re: HFI1 code duplication todo

On Fri, Nov 20, 2015 at 11:58:18AM -0500, Doug Ledford wrote: > On 11/20/2015 11:39 AM, Greg KH wrote: > > On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > >> To that end, I've opened my 4.4-rc branch and deleted the three > >> deprecated drivers from staging and moved hfi1 to the

Re: HFI1 code duplication todo

On 11/20/2015 12:13 PM, Greg KH wrote: >>> I think it's too late for that, especially given that I have 34+ patches >>> for the staging rdma drivers already in my tree in linux-next. >> >> For hfi1 rename detection should work, for the other three, patches to >> removed files are easily resolved

Re: [PATCH 18/18] staging/rdma/hfi1: Workaround CONFIG_SDMA_VERBOSITY timing issue

On Fri, Nov 20, 2015 at 04:01:18PM +, Marciniszyn, Mike wrote: > > That sounds like a horrid hack, and this implies that a slower machine will > > still have this problem... > > Greg, > > I'm NAK'ing this patch for two reasons: > 1. Code underneath the CONFIG option is only used during

Re: [PATCH 00/14] staging: unisys: add channel interrupt support

On 11/17/2015 05:18 PM, Greg KH wrote: On Tue, Nov 17, 2015 at 09:57:58AM -0500, Benjamin Romer wrote: This patch series adds a centralized infrastructure and device support for channel interrupts sent to s-Par virtual devices. With these changes, the visorhba device is ~80% faster than with

Re: [PATCH 00/14] staging: unisys: add channel interrupt support

On Fri, Nov 20, 2015 at 01:59:02PM -0500, Ben Romer wrote: > On 11/17/2015 05:18 PM, Greg KH wrote: > >On Tue, Nov 17, 2015 at 09:57:58AM -0500, Benjamin Romer wrote: > >>This patch series adds a centralized infrastructure and device support > >>for channel interrupts sent to s-Par virtual

Re: [PATCH 07/18] staging/rdma/hfi1: Extend quiet timeout

On Fri, Nov 20, 2015 at 03:21:14PM +, Marciniszyn, Mike wrote: > > > The longest quiet timeout is now 6s. Extend the driver wait. > > > > To what? And why? What does this fix? > > > > The driver wasn't following the our internal specification: 6 seconds. > > The patch corrects that

Beloved in Christ

Beloved in Christ, I am Mrs Arcelia Santos and was married to Late Mariano Santos who was a farmer and a wine producer in Spain before he died after a few days in the hospital. I have been suffering from cancer, I have a serious issue to discuss with you about my donation project of

RE: [PATCH 03/18] staging/rdma/hfi1: Add aeth name syndrome decode

> > Add aeth name syndrome decode > > Again, why? > This fix is to enhance debugging. The IBTA RC ACK contains an ACK extended transport header. Part of that header is the syndrome field that qualifies the RC ACK as an ACK, NAK, or RNR NAK. Without the patch here is the syndrome decode:

[PATCH] staging: ste_rmi4: avoid unused function warnings

The rmi4 touchscreen driver encloses the power-management functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume functions are only really used when CONFIG_PM_SLEEP is also set, as a frequent gcc warning shows: ste_rmi4/synaptics_i2c_rmi4.c:1050:12: warning: 'synaptics_rmi4_suspend'

[PATCH 16/40] staging: lustre: make local functions static for LNet ni

From: frank zago This reduces the code size by about 400 bytes. Signed-off-by: frank zago Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5396 Reviewed-on: http://review.whamcloud.com/11306 Reviewed-by: James Simmons Reviewed-by: Patrick

[PATCH 18/40] staging: lustre: remove LUSTRE_{,SRV_}LNET_PID

From: John L. Hammond Remove LUSTRE_LNET_PID (12354) and LUSTRE_SRV_LNET_PID (12345) from the libcfs headers and replace their uses with a new macro LNET_PID_LUSTRE (also 12345) in lnet/types.h. Signed-off-by: John L. Hammond Intel-bug-id:

[PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC) show command

From: Amir Shehata This is the fifth patch of a set of patches that enables DLC. This patch adds the new structures which will be used in the IOCTL communication. It also added a set of show operations to show buffers, networks, statistics and peer information.

[PATCH 20/40] staging: lustre: fix kernel crash when network failed to start

From: Amir Shehata When loading Lustre modules without proper network configuration, it always hit the following kernel panic: LNetError: 105-4: Error -100 starting up LNI tcp LNetError: 2145:0:(api-ni.c:823:lnet_unprepare()) ASSERTION( list_empty(_lnet.ln_nis) ) failed:

[PATCH 21/40] staging: lustre: improve LNet clean up code and API

From: Amir Shehata This patch addresses a set of related issues: LU-5734, LU-5839, LU-5849, LU-5850. Create the local lnet_startup_lndni() API. This function starts up one LND. lnet_startup_lndnis() calls this function in a loop on every ni in the list passed in.

[PATCH 08/40] staging: lustre: do not memset after LIBCFS_ALLOC

From: Frank Zago LIBCFS_ALLOC already zero out the memory allocated, so there is no need to zero out the memory again. Signed-off-by: Frank Zago Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5304 Reviewed-on: http://review.whamcloud.com/11012 Reviewed-by:

[PATCH 12/40] staging: lustre: Dynamic LNet Configuration (DLC) IOCTL changes

From: Amir Shehata This is the fourth patch of a set of patches that enables DLC. This patch changes the IOCTL infrastructure in preparation of adding extra IOCTL communication between user and kernel space. The changes include: - adding a common header to be passed to

[PATCH 14/40] staging: lustre: fix crash due to NULL networks string

From: Amir Shehata If there is an invalid networks or ip2nets lnet_parse_networks() gets called with a NULL 'network' string parameter lnet_parse_networks() needs to sanitize its input string now that it's being called from multiple places. Instead, check for a NULL

[PATCH 36/40] staging: lustre: test for sk_sleep presence in compact-2.6.h

Like Lustre external infiniband stacks create a compatibility layer to handle various distributions and kernel versions. Due to this besides the linux kernel sk_sleep can also be defined by the external infiniband stack. We need to examine the infiniband stack's headers to see if sk_sleep is

[PATCH 37/40] staging: lustre: remove unnecessary NULL check in IOC_LIBCFS_GET_NET

From: Amir Shehata In LNetCtl():IOC_LIBCFS_GET_NET there is a check for config == NULL This is not necessary as it'll never be NULL. That's ensured before the call to LNetCtl. Signed-off-by: Amir Shehata Intel-bug-id:

[PATCH v3] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

From: Ira Weiny sdma_select_engine_vl only needs to protect itself from an invalid VL. Something higher up the stack should be warning the user when they try to use an SL which maps to an invalid VL. Reviewed-by: Dean Luick Reviewed-by: Mike Marciniszyn

[PATCH 03/40] staging: lustre: reflect down routes in /proc/sys/lnet/routes

From: Chris Horn We consider routes "down" if the router is down or the router NI for the target network is down. This should be reflected in the output of /proc/sys/lnet/routes Signed-off-by: Chris Horn Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3679

[PATCH 05/40] staging: lustre: eliminate obsolete Cray SeaStar support

Remove the bulk of code for the no longer supported SeaStar interconnect found on older Cray systems. Signed-off-by: James Simmons Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1422 Reviewed-on: http://review.whamcloud.com/7469 Reviewed-by: Liang Zhen

[PATCH 07/40] staging: lustre: return +ve for blocked lnet message

From: Liang Zhen returned value of lnet_post_send_locked and lnet_post_routed_recv_locked are changed to -ve by: http://review.whamcloud.com/#/c/9369/ this is wrong because callers rely on +ve to identify blocked message which is not a failure. To respect linux kernel

[PATCH 01/40] staging: lustre: drop *_t from end of struct lnet_text_buf

When lnet_text_buf data structure was transform from typedef to struct the *_t which is typical of typedef was not drop. This patch removes the *_t to be consistent. Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/lnet/config.c | 57

Re: HFI1 code duplication todo

On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > So, as to the hfi1/qib/rxe transport library. The qib driver is in the > rdma tree, and we aren't going to move it to staging just because it > depends on something in staging, so we need to start adding the library > in the core

[PATCH] staging/rdma/hfi1: Fix error in hfi1 driver build

hfi1 driver build fails with the following error: In function ‘handle_receive_interrupt’: error: implicit declaration of function ‘skip_rcv_packet’ [-Werror=implicit-function-declaration] last = skip_rcv_packet(, thread); ^ This is due to the inclusion of the skip_rcv_packet() in the

[PATCH 00/40] Sync upstream lustre client LNet core

This is the majority of the fixes that have gone into the LNet layer. Outside a few remaining patches this brings LNet close to what is running in production world wide. This patch series needs the remove IOC_LIBCFS_PING_TEST ioctl patch landed first. Amir Shehata (19): staging: lustre:

[PATCH 10/40] staging: lustre: Dynamic LNet Configuration (DLC) dynamic routing

From: Amir Shehata This is the second patch of a set of patches that enables DLC. This patch adds the following features to LNET. Currently these features are not driven by user space. - Enabling Routing on Demand. The default number of router buffers are allocated.

[PATCH 06/40] staging: lustre: remove uses of IS_ERR_VALUE()

From: John L. Hammond Remove most uses of IS_ERR_VALUE(). This macro was often given an int argument coming from PTR_ERR(). This invokes implementation defined behavior since the long value gotten by applying PTR_ERR() to a kernel pointer will usually not be representable

[PATCH 11/40] staging: lustre: DLC Feature dynamic net config

From: Amir Shehata This is the third patch of a set of patches that enables DLC. This patch adds the following features to LNET. Currently these features are not driven by user space. - Adding/Deleting Networks dynamically Two new functions were added: -

[PATCH 04/40] staging: lustre: fix failure handle of create reply

From: Liang Zhen error handler of lnet_create_reply_msg() didn't release lnet_res_lock if lnet_msg_alloc() failed. It can be fixed by moving validation check of msg out from lock. Signed-off-by: Liang Zhen Intel-bug-id:

[PATCH 19/40] staging: lustre: copy out libcfs ioctl inline buffer

From: Liang Zhen - libcfs_ioctl_popdata should copy out inline buffers. - code cleanup for libcfs ioctl handler - error number fix for obd_ioctl_getdata - add new function libcfs_ioctl_unpack for upcoming patches Signed-off-by: Liang Zhen

[PATCH 17/40] staging: lustre: add sparse annotation __user wherever needed for lnet

From: frank zago This fixes sparse warnings such as: .../api-ni.c:1639:33: warning: incorrect type in argument 3 (different address spaces) .../api-ni.c:1639:33: expected struct lnet_process_id_t [noderef]

[PATCH 22/40] staging: lustre: Fixes to make lnetctl function as expected.

During testing of the lnetctl utility I ran into some issues. One of the problems is when you print out help for peer_credits you get help for stats. With this patch the help option for peer_credits is set to return the proper help message. The second problem was for grabbing stats data. No data

[PATCH 15/40] staging: lustre: DLC user/kernel space glue code

From: Amir Shehata This is the sixth patch of a set of patches that enables DLC. This patch enables the user space to call into the kernel space DLC code. Added handlers in the LNetCtl function to call the new functions added for Dynamic Lnet Configuration

[PATCH 23/40] staging: lustre: return appropriate errno when adding route

From: Amir Shehata When adding route it ignored specific scenarios, namely: 1. route already exists 2. route is on a local net 3. route is unreacheable This patch returns the appropriate return codes from the lower level function lnet_add_route(), and then ignores the

[PATCH 24/40] staging: lustre: make some lnet functions static

From: frank zago Some functions and variables are only used in their C file, so reduce their scope. This reduces the code size, and fixes sparse warnings such as: warning: symbol 'proc_lnet_routes' was not declared. Should it be static? warning: symbol

[PATCH 32/40] staging: lustre: prevent assert on LNet module unload

From: Amir Shehata There is a use case where lnet can be unloaded while there are no NIs configured. Removing lnet in this case will cause LNetFini() to be called without a prior call to LNetNIFini(). This will cause the LASSERT(the_lnet.ln_refcount == 0) to be

[PATCH 39/40] staging: lustre: Use lnet_is_route_alive for router aliveness

From: Chris Horn lctl show_route and lctl route_list will output router aliveness information via lnet_get_route(). lnet_get_route() should use the lnet_is_route_alive() function, introduced in e8a1124 http://review.whamcloud.com/7857, to determine route aliveness.

[PATCH 40/40] staging: lustre: Remove LASSERTS from router checker

From: Doug Oucharek In lnet_router_checker(), there are two LASSERTS. Neither protects us from anything and one of them triggered for a customer crashing the system unecessarily. This patch removes them. Signed-off-by: Doug Oucharek

[PATCH 35/40] staging: lustre: avoid race during lnet acceptor thread termination

From: Bruno Faccini This patch will avoid potential race, around socket sleepers wait list, during acceptor thread termination and using sk_callback_lock RW-Lock protection. Signed-off-by: Bruno Faccini Intel-bug-id:

[PATCH 31/40] staging: lustre: assume a kernel build

From: John L. Hammond In lnet/lnet/ and lnet/selftest/ assume a kernel build (assume that __KERNEL__ is defined). Remove some common code only needed for user space LNet. Only part of the work of this patch got merged. This is the final bits. Signed-off-by: John L.

[PATCH 30/40] staging: lustre: improvement to router checker

From: Amir Shehata This patch starts router checker thread all the time. The router checker only checks routes by ping if live_router_check_interval or dead_router_check_interval are set to something other than 0, and there are routes configured. If these conditions are

[PATCH 27/40] staging: lustre: reject invalid net configuration for lnet

From: Amir Shehata Currently if there exists a route that goes over a remote net and then this net is added dynamically as a local net, then traffic stops because the code in lnet_send() determines that the destination nid can be reached from another local_ni, but the

[PATCH 34/40] staging: lustre: remove unnecessary EXPORT_SYMBOL from lnet layer

From: frank zago A lot of symbols don't need to be exported at all because they are only used in the module they belong to. Signed-off-by: frank zago Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5829 Reviewed-on: http://review.whamcloud.com/13320

[PATCH 25/40] staging: lustre: missed a few cases of using NULL instead of 0

From: frank zago It is preferable to use NULL instead of 0 for pointers. This fixes sparse warnings such as: lustre/fld/fld_request.c:126:17: warning: Using plain integer as NULL pointer The second parameter of class_match_param() was changed to a const, to be able to remove a

[PATCH 26/40] staging: lustre: startup lnet acceptor thread dynamically

From: Amir Shehata With DLC it's possible to start up a system with no NIs that require the acceptor thread, and thus it won't start. Later on the user can add an NI that requires the acceptor thread to start, it is then necessary to start it up. If the user removes a

[PATCH 28/40] staging: lustre: return -EEXIST if NI is not unique

From: Amir Shehata Return -EEXIST and not -EINVAL when trying to add a network interface which is not unique. Some minor cleanup in api-ni.c Signed-off-by: Amir Shehata Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5875 Reviewed-on:

[PATCH 38/40] staging: lustre: Allocate the correct number of rtr buffers

From: Amir Shehata This patch ensures that the correct number of router buffers are allocated. It keeps a count that keeps track of the number of buffers allocated. Another count keeps the number of buffers requested. The number of buffers allocated is set when creating

[PATCH 29/40] staging: lustre: handle lnet_check_routes() errors

From: Amir Shehata After adding a route, lnet_check_routes() is called to ensure that the route added doesn't invalidate the routing configuration. If lnet_check_routes() fails then the route just added, which caused the current configuration to be invalidated is

[PATCH 02/40] staging: lustre: fix 'NULL pointer dereference' errors for LNet

From: Sebastien Buisson Fix 'NULL pointer dereference' defects found by Coverity version 6.5.3: Dereference after null check (FORWARD_NULL) For instance, Passing null pointer to a function which dereferences it. Dereference before null check (REVERSE_INULL)

[PATCH 33/40] staging: lustre: remove messages from lazy portal on NI shutdown

From: Amir Shehata When shutting down an NI in a busy system, some messages received on this NI, might be on the lazy portal. They would have grabbed a ref count on the NI. Therefore NI will not be removed until messages are processed. In order to avoid this scenario,

Re: [PATCH v2 2/2] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

On Fri, Nov 20, 2015 at 09:00:23AM -0800, Greg KH wrote: > On Fri, Nov 20, 2015 at 04:43:56PM +, Marciniszyn, Mike wrote: > > > > > > > > Is the inprocess branch available? > > > > > > I do not understand what you mean here :( > > > > Does it fail to apply to staging-next or staging-testing

Re: [PATCH 5/9] staging/rdma/hfi1: Add function stubs for TID caching

On Fri, Nov 20, 2015 at 3:06 AM, Greg Kroah-Hartman wrote: > On Thu, Nov 12, 2015 at 07:58:54AM +0200, Or Gerlitz wrote: >> On Sat, Oct 31, 2015 at 12:41 AM, wrote: >> So this is an wholy orthogonal mechanism for memory registrations or >>

[PATCH] staging: panel: Fixed line over 80 characters long

Moved the comments to the next line to remove the warning detected by the checkpatch.pl. WARNING: line over 80 characters Signed-off-by: Anjali Menon --- drivers/staging/panel/panel.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git