vma_count is used write-only and so fails to be useful. So remove it.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This makes it possible to let gdb access mappings of the process that is
being debugged.
uio_mmap_logical was moved and uio_vm_ops renamed to group related code
and differentiate to new stuff.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the next commit this function will be used in the uio subsystem
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A preparation step.
For now fsync_ts transaction use the pre-calculated log reservation
size of tr_swrite. This patch introduce a new item tr_fsyncts to
mp->m_reservations structure so that we can fetch the log
reservation value for it in a same manner to others.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Both H_IS and H_IE needs to be set to receive H_RDY
interrupt
1. Assert H_IS to clear the interrupts during hw reset
and use mei_me_reg_write instead of mei_hcsr_set as the later
strips down the H_IS
2. fix interrupt disablement embarrassing typo
hcsr |= ~H_IE -> hcsr &= ~H_IE;
this will remove the unwanted interrupt on power down
3. remove useless debug print outs
Cc: Shuah Khan <shuah.kh@samsung.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Introduce a new structure xfs_trans_res to hold transaction
reservation item info per log ticket.
We also need to improve xfs_trans_resv_calc() by initializing the
log count as well as log flags for permanent log reservation.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
This local symbol is used only in this file.
Fix the following sparse warnings:
drivers/fmc/fmc-write-eeprom.c:106:5: warning: symbol 'fwe_probe' was not declared. Should it be static?
drivers/fmc/fmc-write-eeprom.c:147:5: warning: symbol 'fwe_remove' was not declared. Should it be static?
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Alessandro Rubini <rubini@gnudd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no need to have a nlmsghdr pointer to another temporary buffer.
Instead use a full struct nlmsghdr.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
netlink_send is supposed to send just the cn_msg+hv_kvp_msg via netlink.
Currently it sets an incorrect iovec size, as reported by valgrind.
In the case of registering with the kernel the allocated buffer is large
enough to hold nlmsghdr+cn_msg+hv_kvp_msg, no overrun happens. In the
case of responding to the kernel the cn_msg is located in the middle of
recv_buffer, after the nlmsghdr. Currently the code in netlink_send adds
also the size of nlmsghdr to the payload. But nlmsghdr is a separate
iovec. This leads to an (harmless) out-of-bounds access when the kernel
processes the iovec. Correct the iovec size of the cn_msg to be just
cn_msg + its payload.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The struct xfs_perag has many kernel-only definitions in it,
requiring a __KERNEL__ guard so userspace can use it to. Move it to
xfs_mount.h so that it it kernel-only, and let userspace redefine
it's own version of the structure containing only what it needs.
This gets rid of another __KERNEL__ check in the XFS header files.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
I've found some new datasheets which describe some additionally
supported standard baud rates and I've verified them with my HX
(rev. 3A) device. But adding support for individual (chip type
specific) baud rates would add a good amount of extra code (especially
when support for further chips will be added to the driver one day),
which makes no sense as long as we are not using the direct baud rate
encoding method for newer chips.
So for now, just drop a comment about these additionally supported baud
rates.
The second comment is about the baud rate differences between the two
encoding methods. In theory, we could optimize the code a bit by
comparing the resulting baud rates of both methods and selecting the
one which is closer to the requested baud rate. But that seems to be a
bit overkill, because the differences are very small and the device
likely uses the same baud rate generator for both methods so that the
resulting baud rate would be the same.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that the divisor based baud rate encoding method has been fixed and
extended, it can also be used for baud rates < 115200 baud with HX
chips.
This makes it possible to adjust the baud rate almost continuously
instead of just beeing able to select between 16 fixed standard values.
Tested with a PL2303HX 04463A (week 46, 2004, rev 3A).
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reinhard Max has done some tests with a PL2303HX (rev A) and a logic
analyzer and it seems, that although the PL2303HX is specified for baud
rates from 75 to 6M baud, the full divisor range can be used with the
divisor based baud rate encoding method. This corresponds to baud rates
from 46 to 24M baud.
Baud rates down to 46 baud (max. divisor) have been confirmed to work
even under heavy/permanent load, so remove the lower limit.
Baud rates up to 24M baud should really be tested carefully in "real
life" scenarios before removing the upper limit completely.
Anyway, the Windows driver allows maximum baud rates of 110% of the
specified limit, so for now, increase the upper limit to this value.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 0c967e7e "USB: serial: pl2303 works at 500kbps" added 500000
baud to the list of supported standard baud rates.
But the reason why the driver works with this baud rate is, that since
commit 8d48fdf6 "USB: PL2303: correctly handle baudrates above 115200"
a second (divisor based) baud rate encoding method is used for values
above 115200 baud, which is not limited to a fixed set of standard baud
rates.
Remove the 500000 baud value from the list of standard baud rates
again, because this list is only used with the direct baud rate
encoding method and 500000 baud is not supported with this method.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In opposition to the direct baud rate encoding method, the divisor
based method is not limited to a fixed set of standard baud rates.
Hence, there is no need to round to the next nearest standard value.
Reported-by: Mastro Gippo <gipmad@gmail.com>
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Based on the formula in the code description, Reinhard Max and me have
investigated the devices behavior / functional principle of the divisor
based baud rate encoding method.
It turned out, that (although beeing a good starting point) the current
code has some flaws. It doesn't work correctly for a wide range of baud
rates and the divisor resolution can be improved. It also doesn't
report the actually set baud rate.
This patch fixes and improves the code for the divisor based baud rate
encoding method a lot. It can now be used for the whole range of baud
rates from 46 baud to 24M baud with a very good divisor resolution and
userspace can read back the resulting baud rate.
It also documents the formula used for encoding and the hardware
behavior (including special cases).
The basic algorithm, rounding and several code comments/explanations
are provided by Reinhard Max.
I've added some minor fixes, the handling of the special cases and
further code/algorithm descriptions.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the disconnect routine for the hwa_hc interface, it calls
uwb_pal_unregister to unregister itself from the UWB subsystem. This
function attempts to clean up the link to the host controller directory in
the device's UWB radio control interface directory. If the disconnect
routine for the radio control interface has already run, the uwb directory
will be gone so the call to sysfs_remove_link generates a warning.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prevent the USB core from suspending the HWA root hub since bus_suspend
and bus_resume are not yet supported. Otherwise the PM system will chew
up CPU time constantly attempting to suspend and resume the root hub but
never succeeding.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes a kernel panic that can occur when unplugging the HWA
dongle while a downstream device is in the process of disconnecting.
This involved 2 changes. First, call usb_lock_device_for_reset before
usb_reset_device to synchronize the HWA's post_rest and disconnect
routines. Second, set the hwarc->neep_urb and hwarc->rd_buffer to NULL
when they are freed in the error path in the post_reset routine. This
prevents a double free when the disconnect routine is called and attempts
to free those resources again.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Both could want to submit the same URB. Some checks of the flag
intended to prevent that were missing.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As long as the context tracking is enabled on any CPU, even
a single one, all other CPUs need to keep track of their
user <-> kernel boundaries cross as well.
This is because a task can sleep while servicing an exception
that happened in the kernel or in userspace. Then when the task
eventually wakes up and return from the exception, the CPU needs
to know if we resume in userspace or in the kernel. exception_exit()
get this information from exception_enter() that saved the previous
state.
If the CPU where the exception happened didn't keep track of
these informations, exception_exit() doesn't know which state
tracking to restore on the CPU where the task got migrated
and we may return to userspace with the context tracking
subsystem thinking that we are in kernel mode.
This can be fixed in the long term if we move our context tracking
probes on very low level arch fast path user <-> kernel boundary,
although even that is worrisome as an exception can still happen
in the few instructions between the probe and the actual iret.
Also we are not yet ready to set these probes in the fast path given
the potential overhead problem it induces.
So let's fix this by always enable context tracking even on CPUs
that are not in the full dynticks range. OTOH we can spare the
rcu_user_*() and vtime_user_*() calls there because the tick runs
on these CPUs and we can handle RCU state machine and cputime
accounting through it.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Kevin Hilman <khilman@linaro.org>
Update a stale comment from the old vtime era and document some
locking that might be non obvious.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Kevin Hilman <khilman@linaro.org>
1) If context tracking is enabled with native vtime accounting (which
combo is useless except for dev testing), we call vtime_guest_enter()
and vtime_guest_exit() on host <-> guest switches. But those are stubs
in this configurations. As a result, cputime is not correctly flushed
on kvm context switches.
2) If context tracking runs but is disabled on some CPUs, those
CPUs end up calling __guest_enter/__guest_exit which in turn
call vtime_account_system(). We don't want to call this because we
run in tick based accounting for these CPUs.
Refactor the guest_enter/guest_exit code such that all combinations
finally work.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Kevin Hilman <khilman@linaro.org>
preempt_schedule() and preempt_schedule_context() open
code their preemptability checks.
Use the standard API instead for consolidation.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Alex Shi <alex.shi@intel.com>
Cc: Paul Turner <pjt@google.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
attribute groups are much more flexible than just a list of attributes,
due to their support for visibility of the attributes, and binary
attributes. Add bus_groups to struct bus_type which should be used
instead of bus_attrs.
bus_attrs will be removed from the structure soon.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
attribute groups are much more flexible than just a list of attributes,
due to their support for visibility of the attributes, and binary
attributes. Add drv_groups to struct bus_type which should be used
instead of drv_attrs.
drv_attrs will be removed from the structure soon.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
attribute groups are much more flexible than just a list of attributes,
due to their support for visibility of the attributes, and binary
attributes. Add dev_groups to struct bus_type which should be used
instead of dev_attrs.
dev_attrs will be removed from the structure soon.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As result of patches
staging: vt6656: rxtx.c: s_uGetDataDuration remove First Frag or Mid Frag dead code
staging: vt6656: rxtx.c: s_uGetDataDuration remove dead variables.
variables uFragIdx, cbLastFragmentSize, uMACfragNum are dead.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As result of patch
staging: vt6656: rxtx.c s_uGetDataDuration remove First Frag or Mid Frag dead code.
cbFrameLength, wRate, uFragIdx, cbLastFragmentSize, uMACfragNum, byFBOption are
dead variables.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[1] introduced down_write in zram_slot_free_notify to prevent race
between zram_slot_free_notify and zram_bvec_[read|write]. The race
could happen if somebody who has right permission to open swap device
is reading swap device while it is used by swap in parallel.
However, zram_slot_free_notify is called with holding spin_lock of
swap layer so we shouldn't avoid holing mutex. Otherwise, lockdep
warns it.
This patch adds new list to handle free slot and workqueue
so zram_slot_free_notify just registers slot index to be freed and
registers the request to workqueue. If workqueue is expired,
it holds mutex_lock so there is no problem any more.
If any I/O is issued, zram handles pending slot-free request
caused by zram_slot_free_notify right before handling issued
request because workqueue wouldn't be expired yet so zram I/O
request handling function can miss it.
Lastly, when zram is reset, flush_work could handle all of pending
free request so we shouldn't have memory leak.
NOTE: If zram_slot_free_notify's kmalloc with GFP_ATOMIC would be
failed, the slot will be freed when next write I/O write the slot.
[1] [57ab0485, zram: use zram->lock to protect zram_free_page()
in swap free notify path]
* from v2
* refactoring
* from v1
* totally redesign
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Cc: stable@vger.kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[1] tried to fix invalid memory access on zram->disk but it didn't
fix properly because get_disk failed during module exit path.
Actually, we don't need to reset zram->disk's capacity to zero
in module exit path so that this patch introduces new argument
"reset_capacity" on zram_reset_divice and it only reset it when
reset_store is called.
[1] 6030ea9b, zram: avoid invalid memory access in zram_exit()
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Cc: stable@vger.kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reorder the kernel doc comments for 'struct dwc2_core_params' to
match the ordering in the struct itself. Reorder the members of
'struct dwc2_qh' (and its kerneldoc comments) to minimize the
amount of structure padding.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixed a coding style issue of 80 character per line.
Signed-off-by: Andreas Werner <wernerandy@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Removed the unneeded SBE_INCLUDE_SYMBOLS #define, and the associated STATIC
#define, and replaced all occurances of STATIC with 'static'. This was in
response to sparse warnings of the form "symbol 'XYZ' was not declared. Should
it be static?".
Removed a function prototype (musycc_init_port) as adding the 'static'
declaration produced a new gcc warning. (musycc_init_port is only declared if
SBE_WAN256T3_ENABLE is set)
Signed-off-by: Shaun Laing <shaun@xresource.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Checking the return of dev_alloc_skb as stated in the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=60401
Reported-by: RUC_Soft_Sec rucsoftsec@gmail.com
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Convert the drivers with simple, per channel programmable i/o, to use the
comedi_dio_insn_config() helper function.
All of these pass a 'mask' of '0' to comedi_dio_insn_config() this causes
the per channel mask to be used to configure the i/o direction.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Convert this driver to use the comedi_dio_insn_config() helper function.
Tidy up the comments to reflect the new code.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
DIO subdevices always handle the INSN_CONFIG_DIO_{INPUT,OUTPUT} instructions
to configure the DIO channels. They also always handle the INSN_CONFIG_DIO_QUERY
instruction to query the configuration of a DIO channel.
Introduce a helper function to handle the (*insn_config) boilerplate for
comedi DIO subdevices. This function has the same paramters as (*insn_config)
functions with an additional parameter to allow the caller to pass a 'mask'
value for grouped DIO channels.
This function returns:
0 if the instruction was successful but requires additional handling by
the caller (INSN_CONFIG_DIO_{INPUT,OUTPUT}
insn->n if the instruction was handled (INSN_CONFIG_DIO_QUERY)
-EINVAL for all unhandled instructions
The caller is responsible for actually configuring the hardware based on
the configuration (s->io_bits).
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 42ef678bef.
It's incorrect as well... time for more coffee...
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 4f76463d3b.
I applied an incorrect version here as well :(
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
My gcc-4.3.5 fails to compile due to:
|cc1: warnings being treated as errors
|arch/powerpc/platforms/52xx/mpc52xx_pic.c: In function ‘mpc52xx_irqhost_map’:
|arch/powerpc/platforms/52xx/mpc52xx_pic.c:343: error: ‘irqchip’ may be used uninitialized in this function
since commit e34298c ("powerpc: 52xx: nop out unsupported critical
IRQs"). This warning is complete crap since only values 0…3 are possible
which are checked but gcc fails to understand that. I wouldn't care much
but since this is compiled with -Werror I made this patch.
While add it, I replaced the warning from l2irq to l1irq since this is
the number that is evaluated.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Convert the drivers with complex, port programmable i/o, to use the
comedi_dio_insn_config() helper function.
All of these drivers have some sort of 'port' programmable i/o where multiple
i/o channels are configured as a group. The 'mask' associated with the group
is passed to comedi_dio_insn_config() so that all the channels are configured.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To get the name of a file from a pathname we may use kbasename() helper.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit f21c53945c.
I applied the wrong patch :(
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
zcache is obsolete and not used anymore, Bob Liu has rewritten it and is
submitting it for inclusion through the main -mm tree, as it should have
been done in the first place...
Cc: Bob Liu <lliubbo@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xfs_types.h is shared with userspace, so having kernel specific
types defined in it is problematic. Move all the kernel specific
defines to xfs_linux.h so we can remove the __KERNEL__ guards from
xfs_types.h.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Convert the drivers with complex, port programmable i/o, to use the
comedi_dio_insn_config() helper function.
All of these drivers have some sort of 'port' programmable i/o where multiple
i/o channels are configured as a group. The 'mask' associated with the group
is passed to comedi_dio_insn_config() so that all the channels are configured.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
