First of all,the address of pdev->dev is assigned to card->dev in
create_card,then the function platform_set_drvdata copies the value
the variable card to pdev->dev.driver_data, but when calling
snd_soc_register_card,the function dev_set_drvdata(card->dev, card)
will also do the same copy
First of all,the address of pdev->dev is assigned to card->dev in
create_card,then the function platform_set_drvdata copies the value
the variable card to pdev->dev.driver_data, but when calling
snd_soc_register_card,the function dev_set_drvdata(card->dev, card)
will also do the same copy
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
The function platform_set_drvdata(pdev, data) copies the value of
the variable data to pdev->dev.driver_data,but when calling
snd_soc_register_card,the function dev_set_drvdata(card->dev, card)
will override it, so i think that the former copy operation is
useless and can be removed.
The function platform_set_drvdata(pdev, data) copies the value of
the variable data to pdev->dev.driver_data,but when calling
snd_soc_register_card,the function dev_set_drvdata(card->dev, card)
will override it, so i think that the former copy operation is
useless and can be removed.
Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
like A20.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Documentation/arm/sunxi/README | 6 ++
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
arch/arm/mach-sunxi/sunxi.c
Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
like A20.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Documentation/arm/sunxi/README | 6 ++
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
arch/arm/mach-sunxi/sunxi.c
The compatible string for Allwinner V3s SoC used to be missing.
Add it to the binding document.
Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
Signed-off-by: Icenowy Zheng
---
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
1 file changed, 1 insertion(+)
The compatible string for Allwinner V3s SoC used to be missing.
Add it to the binding document.
Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
Signed-off-by: Icenowy Zheng
---
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
The function platform_set_drvdata copies the value the variable
card to card->dev->driver_data, then the address of >dev is
assigned to card->dev in atmel_pdmic_asoc_card_init, but when
calling snd_soc_register_card,the function
dev_set_drvdata(card->dev, card) will do the same copy operation,
so
The function platform_set_drvdata copies the value the variable
card to card->dev->driver_data, then the address of >dev is
assigned to card->dev in atmel_pdmic_asoc_card_init, but when
calling snd_soc_register_card,the function
dev_set_drvdata(card->dev, card) will do the same copy operation,
so
The function platform_set_drvdata copies the value the variable
card to card->dev->driver_data, then the address of >dev is
assigned to card->dev in atmel_classd_asoc_card_init, but when
calling snd_soc_register_card,the function
dev_set_drvdata(card->dev, card) will do the same copy operation,
so
The function platform_set_drvdata copies the value the variable
card to card->dev->driver_data, then the address of >dev is
assigned to card->dev in atmel_classd_asoc_card_init, but when
calling snd_soc_register_card,the function
dev_set_drvdata(card->dev, card) will do the same copy operation,
so
First of all,the address of pdev->dev is assigned to card->dev, when
calling snd_soc_register_card,the function dev_set_drvdata(card->dev, card)
copies the value the variable card to card->dev->driver_data.After
that,the function platform_set_drvdata does the same copy operation,
so i think that
First of all,the address of pdev->dev is assigned to card->dev, when
calling snd_soc_register_card,the function dev_set_drvdata(card->dev, card)
copies the value the variable card to card->dev->driver_data.After
that,the function platform_set_drvdata does the same copy operation,
so i think that
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
First of all,the address of pdev->dev is assigned to card->dev,then
the function platform_set_drvdata copies the value the variable card
to pdev->dev.driver_data, but when calling snd_soc_register_card,the
function dev_set_drvdata(card->dev, card) will also do the same copy
operation,so i think
On Fri, Aug 18, 2017 at 09:39:16PM -0700, Mathieu Desnoyers wrote:
> Document the membarrier requirement on having a full memory barrier in
> __schedule() after coming from user-space, before storing to rq->curr.
> It is provided by smp_mb__before_spinlock() in __schedule().
>
> Document that
On Fri, Aug 18, 2017 at 09:39:16PM -0700, Mathieu Desnoyers wrote:
> Document the membarrier requirement on having a full memory barrier in
> __schedule() after coming from user-space, before storing to rq->curr.
> It is provided by smp_mb__before_spinlock() in __schedule().
>
> Document that
On Wed, 2017-08-16 at 10:31 +0300, Dan Carpenter wrote:
> On Wed, Aug 16, 2017 at 10:53:18AM +0530, Rishabh Hardas wrote:
> > @@ -143,10 +142,13 @@ struct pi433_rx_cfg {
> >
> > #define PI433_IOC_MAGIC'r'
> >
> > -#define PI433_IOC_RD_TX_CFG_IOR(PI433_IOC_MAGIC,
> >
On Wed, 2017-08-16 at 10:31 +0300, Dan Carpenter wrote:
> On Wed, Aug 16, 2017 at 10:53:18AM +0530, Rishabh Hardas wrote:
> > @@ -143,10 +142,13 @@ struct pi433_rx_cfg {
> >
> > #define PI433_IOC_MAGIC'r'
> >
> > -#define PI433_IOC_RD_TX_CFG_IOR(PI433_IOC_MAGIC,
> >
Le 19/08/2017 à 15:22, Christian Lamparter a écrit :
On Saturday, August 19, 2017 1:07:57 AM CEST Christophe JAILLET wrote:
If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is
known to be 0 at this point.
So return -ENODEV instead in the first case and propagate the error
Le 19/08/2017 à 15:22, Christian Lamparter a écrit :
On Saturday, August 19, 2017 1:07:57 AM CEST Christophe JAILLET wrote:
If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is
known to be 0 at this point.
So return -ENODEV instead in the first case and propagate the error
If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is
known to be 0 at this point.
So return -ENODEV instead in the first case and use 'of_iomap()' instead of
the equivalent 'of_address_to_resource()/ioremap()' combinaison in the 2nd
case.
Doing so, the 'rsrc_regs' field of the
If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is
known to be 0 at this point.
So return -ENODEV instead in the first case and use 'of_iomap()' instead of
the equivalent 'of_address_to_resource()/ioremap()' combinaison in the 2nd
case.
Doing so, the 'rsrc_regs' field of the
From: Colin King
Date: Fri, 18 Aug 2017 16:40:00 +0100
> From: Colin Ian King
>
> Trivial fix to spelling mistake in a netdev_info message
>
> Signed-off-by: Colin Ian King
Applied.
From: Colin King
Date: Fri, 18 Aug 2017 16:40:00 +0100
> From: Colin Ian King
>
> Trivial fix to spelling mistake in a netdev_info message
>
> Signed-off-by: Colin Ian King
Applied.
From: Colin King
Date: Fri, 18 Aug 2017 16:30:00 +0100
> From: Colin Ian King
>
> Trival fix to spelling mistakes:
>
> firware -> firmware
> invald -> invalid
> mutilcast -> multicast
>
> Signed-off-by: Colin Ian King
From: Colin King
Date: Fri, 18 Aug 2017 16:30:00 +0100
> From: Colin Ian King
>
> Trival fix to spelling mistakes:
>
> firware -> firmware
> invald -> invalid
> mutilcast -> multicast
>
> Signed-off-by: Colin Ian King
Applied, thanks.
On Sun, Aug 20, 2017 at 1:56 AM, Bjorn Helgaas wrote:
> On Sun, Aug 20, 2017 at 01:02:09AM +0530, Oza Oza wrote:
>> On Sat, Aug 19, 2017 at 11:56 PM, Bjorn Helgaas wrote:
>
>> > I think you should do something like this instead so you don't do the
>> >
On Sun, Aug 20, 2017 at 1:56 AM, Bjorn Helgaas wrote:
> On Sun, Aug 20, 2017 at 01:02:09AM +0530, Oza Oza wrote:
>> On Sat, Aug 19, 2017 at 11:56 PM, Bjorn Helgaas wrote:
>
>> > I think you should do something like this instead so you don't do the
>> > MMIO read any more times than necessary:
>>
On Sun, 20 Aug 2017 08:37:36 +0800
kbuild test robot wrote:
> Hi Nicholas,
>
> FYI, the error/warning still remains.
Still same answer as before, i.e., it seems to be this toolchain bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=21017
I've had no response from
On Sun, 20 Aug 2017 08:37:36 +0800
kbuild test robot wrote:
> Hi Nicholas,
>
> FYI, the error/warning still remains.
Still same answer as before, i.e., it seems to be this toolchain bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=21017
I've had no response from the microblaze
On Sun, Aug 20, 2017 at 2:34 AM, Bjorn Helgaas wrote:
> On Fri, Aug 04, 2017 at 09:18:16PM +0530, Oza Pawandeep wrote:
>> PERST must be asserted around ~500ms before the reboot is applied.
>>
>> During soft reset (e.g., "reboot" from Linux) on some iproc based SOCs
>> LCPLL
On Sun, Aug 20, 2017 at 2:34 AM, Bjorn Helgaas wrote:
> On Fri, Aug 04, 2017 at 09:18:16PM +0530, Oza Pawandeep wrote:
>> PERST must be asserted around ~500ms before the reboot is applied.
>>
>> During soft reset (e.g., "reboot" from Linux) on some iproc based SOCs
>> LCPLL clock and PERST both
Hi Everyone!
You may download the guide in PDF format from the following links.
https://drive.google.com/open?id=0B96mKCooAF0nbDNhUTZMamRQc2M
https://www.scribd.com/document/356726248/Teo-En-Ming-s-Guide-to-Passing-the-CCNA-Exams
Practice makes perfect!
Yours sincerely,
Mr. Turritopsis
Hi Everyone!
You may download the guide in PDF format from the following links.
https://drive.google.com/open?id=0B96mKCooAF0nbDNhUTZMamRQc2M
https://www.scribd.com/document/356726248/Teo-En-Ming-s-Guide-to-Passing-the-CCNA-Exams
Practice makes perfect!
Yours sincerely,
Mr. Turritopsis
On Sat, Aug 19, 2017 at 02:51:17PM +0200, Arnd Bergmann wrote:
[...]
> > Those two "rep movsq"s are very suspicious, because
> > COMPLETION_INITIALIZER_ONSTACK() should initialize the data in-place,
> > rather than move it to some temporary variable and copy it back.
>
> Right. I've seen this
On Sat, Aug 19, 2017 at 02:51:17PM +0200, Arnd Bergmann wrote:
[...]
> > Those two "rep movsq"s are very suspicious, because
> > COMPLETION_INITIALIZER_ONSTACK() should initialize the data in-place,
> > rather than move it to some temporary variable and copy it back.
>
> Right. I've seen this
> This series is a revised version of two patches I sent
> previously (one of which was sadly broken).
> That patch has been broken into multiple parts for easy
> review. The other is included unchanged as the last of
> this series.
>
> I was drawn to look at this code due to the tests on
>
> This series is a revised version of two patches I sent
> previously (one of which was sadly broken).
> That patch has been broken into multiple parts for easy
> review. The other is included unchanged as the last of
> this series.
>
> I was drawn to look at this code due to the tests on
>
> On Mon, Aug 14, 2017 at 12:20:51PM -0400, James Simmons wrote:
> > From: Robin Humble
> >
> > The security.capability xattr is used to implement File
> > Capabilities in recent Linux versions. Capabilities are a
> > fine grained approach to granting executables
> On Mon, Aug 14, 2017 at 12:20:51PM -0400, James Simmons wrote:
> > From: Robin Humble
> >
> > The security.capability xattr is used to implement File
> > Capabilities in recent Linux versions. Capabilities are a
> > fine grained approach to granting executables elevated
> > privileges. eg.
> On Aug 17, 2017, at 10:26, Greg KH wrote:
> >
> > On Wed, Aug 16, 2017 at 05:44:15PM +0300, Cihangir Akturk wrote:
> >> When building the kernel for the ARM architecture without setting
> >> CONFIG_AEABI, size of struct lov_user_md_v3 and struct lov_mds_md_v3
> >>
> On Aug 17, 2017, at 10:26, Greg KH wrote:
> >
> > On Wed, Aug 16, 2017 at 05:44:15PM +0300, Cihangir Akturk wrote:
> >> When building the kernel for the ARM architecture without setting
> >> CONFIG_AEABI, size of struct lov_user_md_v3 and struct lov_mds_md_v3
> >> differs, due to different
The other eye sore for lustre after the UAPI mess is the loony
debugging system. This debugging system was written long before
trace point existed. Well it shows and todays trace point has
surpassed lustre debugging system.
Some of the things implemented are:
1) trace events have a specific
The other eye sore for lustre after the UAPI mess is the loony
debugging system. This debugging system was written long before
trace point existed. Well it shows and todays trace point has
surpassed lustre debugging system.
Some of the things implemented are:
1) trace events have a specific
From: Ben Evans
Migrate functions set/get_mrc_cr_flags, ldlm_res_eq
ldlm_extent_overlap, ldlm_extent_contain,
ldlm_request_bufsize, and all the PTLRPC dump_*
functions out of lustre_idl.h which is a UAPI header
to the places in the kernel code they are actually used.
Delete
The headers for lustre/LNet for a long time lacked a clean separation in
its internal headers which resulted in kernel specific data structures
being exposed in user land code. This work unravels this mess and creates
a clear separation between lustre kernel space and lustre user land.
With this
From: Ben Evans
The wiki has been revived so update the URL about the FID
design in lustre_fid.h.
Signed-off-by: Ben Evans
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on:
From: Ben Evans
Migrate functions set/get_mrc_cr_flags, ldlm_res_eq
ldlm_extent_overlap, ldlm_extent_contain,
ldlm_request_bufsize, and all the PTLRPC dump_*
functions out of lustre_idl.h which is a UAPI header
to the places in the kernel code they are actually used.
Delete unused
The headers for lustre/LNet for a long time lacked a clean separation in
its internal headers which resulted in kernel specific data structures
being exposed in user land code. This work unravels this mess and creates
a clear separation between lustre kernel space and lustre user land.
With this
From: Ben Evans
The wiki has been revived so update the URL about the FID
design in lustre_fid.h.
Signed-off-by: Ben Evans
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/22712
Reviewed-on:
From: Ben Evans
Currently the function ostid_set_id() just logs an error
and just keeps going. This function is also used by user
land tools so having special lustre kernel debugging
code is not desired. So instead just return an error
code and have the calling kernel code print
From: Ben Evans
Currently the function ostid_set_id() just logs an error
and just keeps going. This function is also used by user
land tools so having special lustre kernel debugging
code is not desired. So instead just return an error
code and have the calling kernel code print the error
The header lustre_ioctl.h has both kernel and user space versions
of obd_ioctl_*() functions. Lets remove the user land version
which have been integrated into the lustre tools.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on:
The header lustre_ioctl.h has both kernel and user space versions
of obd_ioctl_*() functions. Lets remove the user land version
which have been integrated into the lustre tools.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on:
Replace obd_ioctl_popdata() with direct copy_to_user() call.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
Reviewed-by: Ben Evans
Delete code that is used by only the server or just in user
land. Now this file is a normal kernel header. The UAPI
version of this header is only needed for server side so
no need to create a new header in uapi directory.
Signed-off-by: James Simmons
Intel-bug-id:
Replace obd_ioctl_popdata() with direct copy_to_user() call.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
Reviewed-by: Ben Evans
Reviewed-by: Oleg Drokin
Signed-off-by: James
Delete code that is used by only the server or just in user
land. Now this file is a normal kernel header. The UAPI
version of this header is only needed for server side so
no need to create a new header in uapi directory.
Signed-off-by: James Simmons
Intel-bug-id:
Replace obd_ioctl_freedata() with direct kvfree() call.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
Reviewed-by: Ben Evans
Move obd_ioctl_getdata() from lustre_ioctl.h to obd_class.h
since this function is only used by kernel space.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
Replace obd_ioctl_freedata() with direct kvfree() call.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
Reviewed-by: Ben Evans
Reviewed-by: Oleg Drokin
Signed-off-by: James
Move obd_ioctl_getdata() from lustre_ioctl.h to obd_class.h
since this function is only used by kernel space.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
Reviewed-by: Ben Evans
The inline function obd_ioctl_is_invalid() is no longer needed by
userland and also the function was pretty bug for a inline function.
Since this is the case we can move this kernel only code to the
linux-module.c which is the only place it is used.
Signed-off-by: James Simmons
From: Ben Evans
Move lu_fid functions into lustre/lustre_fid.h
Move ost_id functions into lustre/lustre_ostid.h
Fix indenting, include new headers as needed.
Several inline functions in the header lustre_ostid.h
are using debug macros instead of returning proper errors.
Remove
The inline function obd_ioctl_is_invalid() is no longer needed by
userland and also the function was pretty bug for a inline function.
Since this is the case we can move this kernel only code to the
linux-module.c which is the only place it is used.
Signed-off-by: James Simmons
Intel-bug-id:
From: Ben Evans
Move lu_fid functions into lustre/lustre_fid.h
Move ost_id functions into lustre/lustre_ostid.h
Fix indenting, include new headers as needed.
Several inline functions in the header lustre_ostid.h
are using debug macros instead of returning proper errors.
Remove the debug macros
Change LUSTRE_IOCTL_H_ to _UAPI_LUSTRE_IOCTL_H_ now that is
a proper UAPI header
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
With the cleanups we no longer need to drag in tons of
user land headers. Lets simplify the include headers.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
With the cleanups we no longer need to drag in tons of
user land headers. Lets simplify the include headers.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
Reviewed-by: Ben Evans
Change LUSTRE_IOCTL_H_ to _UAPI_LUSTRE_IOCTL_H_ now that is
a proper UAPI header
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
Reviewed-by: Ben Evans
Reviewed-by: Oleg Drokin
Move the header lustre_ioctl.h to proper uapi directory.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
Reviewed-by: Ben Evans
Move the header lustre_ioctl.h to proper uapi directory.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
Reviewed-by: Ben Evans
Reviewed-by: Oleg Drokin
Signed-off-by: James
All the included headers in lustre_param.h are lustre kernel
internal headers and they are not even needed. Just remove them.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24325
Reviewed-by: Ben
Move all the kernel specific function prototypes from
lustre_param.h into obd_config.h which is a kernel only
header.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24325
Reviewed-by: Ben Evans
All the included headers in lustre_param.h are lustre kernel
internal headers and they are not even needed. Just remove them.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24325
Reviewed-by: Ben Evans
Reviewed-by:
Move all the kernel specific function prototypes from
lustre_param.h into obd_config.h which is a kernel only
header.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24325
Reviewed-by: Ben Evans
Reviewed-by: John L.
Replace cfs_size_round() standard __ALIGN_KERNEL macro. This
removes the dependency of libcfs.h which is a kernel only
header.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by:
Change LUSTRE_PARAM_H_ to _UAPI_LUSTRE_PARAM_H_ now that is
a proper UAPI header
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24325
Reviewed-by: Ben Evans
Reviewed-by: John L.
Change LUSTRE_PARAM_H_ to _UAPI_LUSTRE_PARAM_H_ now that is
a proper UAPI header
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24325
Reviewed-by: Ben Evans
Reviewed-by: John L. Hammond
Reviewed-by: Oleg Drokin
Replace cfs_size_round() standard __ALIGN_KERNEL macro. This
removes the dependency of libcfs.h which is a kernel only
header.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24568
Reviewed-by: Andreas Dilger
To perserve the truncate warning move lustre_cfg_string()
to obd_config.c. A identical function was created for
userland. This function was a bit big for a inline function.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on:
Remove the white space in the lustre_param.h header and
align the code so its easier to read.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24325
Reviewed-by: Ben Evans
To perserve the truncate warning move lustre_cfg_string()
to obd_config.c. A identical function was created for
userland. This function was a bit big for a inline function.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on:
Remove the white space in the lustre_param.h header and
align the code so its easier to read.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/24325
Reviewed-by: Ben Evans
Reviewed-by: John L. Hammond
Reviewed-by:
Change i from int to __u32 to match lcfg_bufcount field. Also
this matches what the other functions also do.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/26966
Reviewed-by: Quentin Bouget
Change i from int to __u32 to match lcfg_bufcount field. Also
this matches what the other functions also do.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/26966
Reviewed-by: Quentin Bouget
Reviewed-by: Ben Evans
The inline function lustre_cfg_new() calls kzalloc() but
this is a UAPI header. Remove kzalloc() and rename the
function to lustre_cfg_init(). The lustre kernel code
that was calling lustre_cfg_new() can doing the memory
allocation and pass the new buffer to lustre_cfg_init()
to fill in.
In class_config_llog_handler() a flag, inst, was used to
determine if it was safe to call kfree. Its not needed so
remove the flag.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/26966
1 - 100 of 652 matches
Mail list logo