[PATCH 10/12] ASoC: sun4i-codec: Remove unnecessary function call

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

[PATCH 10/12] ASoC: sun4i-codec: Remove unnecessary function call

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

[PATCH 09/12] ASoC: qcom: Remove unnecessary function call

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

[PATCH 09/12] ASoC: qcom: Remove unnecessary function call

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

[PATCH 08/12] ASoC: qcom: Remove useless function call

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.

[PATCH 08/12] ASoC: qcom: Remove useless function call

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.

[PATCH 2/2] ARM: sunxi: add support for R40 SoC

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

[PATCH 2/2] ARM: sunxi: add support for R40 SoC

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

[PATCH 1/2] dt-bindings: add compatible string for Allwinner V3s SoC

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(+)

[PATCH 1/2] dt-bindings: add compatible string for Allwinner V3s SoC

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

[PATCH 07/12] ASoC: mxs-sgtl5000: Remove unnecessary function call

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

[PATCH 07/12] ASoC: mxs-sgtl5000: Remove unnecessary function call

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

[PATCH 06/12] ASoC: rockchip: Remove unnecessary function call

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

[PATCH 06/12] ASoC: rockchip: Remove unnecessary function call

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

[PATCH 05/12] ASoC: atmel: Remove unnecessary function call

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

[PATCH 05/12] ASoC: atmel: Remove unnecessary function call

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

[PATCH 04/12] ASoC: atmel: Remove unnecessary function call

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

[PATCH 04/12] ASoC: atmel: Remove unnecessary function call

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

[PATCH 03/12] ASoC: Intel: Remove unnecessary function call

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

[PATCH 03/12] ASoC: Intel: Remove unnecessary function call

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

[PATCH 01/12] ASoC: s3c24xx_uda134x: Remove unnecessary function call

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

[PATCH 01/12] ASoC: s3c24xx_uda134x: Remove unnecessary function call

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

[PATCH 02/12] ASoC: mediatek: Remove unnecessary function call

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

[PATCH 02/12] ASoC: mediatek: Remove unnecessary function call

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

[PATCH 00/12] Remove unnecessary function call

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

[PATCH 00/12] Remove unnecessary function call

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

Re: [PATCH v2] membarrier: Document scheduler barrier requirements

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

Re: [PATCH v2] membarrier: Document scheduler barrier requirements

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

Re: [PATCH v2 1/4] staging: pi433: Style fix - Correct long lines

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, > >

Re: [PATCH v2 1/4] staging: pi433: Style fix - Correct long lines

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, > >

Re: [PATCH] net: ibm: emac: Fix some error handling path in 'emac_probe()'

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

Re: [PATCH] net: ibm: emac: Fix some error handling path in 'emac_probe()'

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

[PATCH v2] net: ibm: emac: Fix some error handling path in 'emac_probe()'

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

[PATCH v2] net: ibm: emac: Fix some error handling path in 'emac_probe()'

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

Re: [PATCH][netdev-next] bnxt_en: fix spelling mistake: "swtichdev" -> "switchdev"

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.

Re: [PATCH][netdev-next] bnxt_en: fix spelling mistake: "swtichdev" -> "switchdev"

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.

Re: [PATCH][net-next] net: hns3: fix a handful of spelling mistakes

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

Re: [PATCH][net-next] net: hns3: fix a handful of spelling mistakes

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.

Re: [PATCH v6 1/2] PCI: iproc: Retry request when CRS returned from EP

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 >> >

Re: [PATCH v6 1/2] PCI: iproc: Retry request when CRS returned from EP

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: >>

Re: undefined reference to `_GLOBAL_OFFSET_TABLE_'

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

Re: undefined reference to `_GLOBAL_OFFSET_TABLE_'

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

Re: [PATCH v6 2/2] PCI: iproc: add device shutdown for PCI RC

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

Re: [PATCH v6 2/2] PCI: iproc: add device shutdown for PCI RC

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

Teo En Ming's Guide to Passing the Cisco Certified Network Associate (CCNA) Exams

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

Teo En Ming's Guide to Passing the Cisco Certified Network Associate (CCNA) Exams

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

Re: [PATCH v8 09/14] lockdep: Apply crossrelease to completions

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

Re: [PATCH v8 09/14] lockdep: Apply crossrelease to completions

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

Re: [lustre-devel] [PATCH 0/6] dcache/namei fixes for lustre

> 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 >

Re: [lustre-devel] [PATCH 0/6] dcache/namei fixes for lustre

> 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 >

Re: [PATCH v2 01/14] staging: lustre: llite: Remove filtering of seclabel xattr

> 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

Re: [PATCH v2 01/14] staging: lustre: llite: Remove filtering of seclabel xattr

> 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.

Re: [PATCH] staging: lustre: fix structure size for ARM OABI

> 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 > >>

Re: [PATCH] staging: lustre: fix structure size for ARM OABI

> 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

[PATCH RFC] staging: lustre: libcfs: tracepoint implementation

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

[PATCH RFC] staging: lustre: libcfs: tracepoint implementation

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

[PATCH 01/64 v2] staging: lustre: uapi: Move functions out of lustre_idl.h

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

[PATCH 00/64 v2] staging: lustre: uapi: normalize the lustre headers

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

[PATCH 04/64 v2] staging: lustre: uapi: update URL doc link in lustre_fid.h

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:

[PATCH 01/64 v2] staging: lustre: uapi: Move functions out of lustre_idl.h

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

[PATCH 00/64 v2] staging: lustre: uapi: normalize the lustre headers

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

[PATCH 04/64 v2] staging: lustre: uapi: update URL doc link in lustre_fid.h

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:

[PATCH 03/64 v2] staging: lustre: uapi: return error code for ostid_set_id

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

[PATCH 03/64 v2] staging: lustre: uapi: return error code for ostid_set_id

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

[PATCH 07/64 v2] staging: lustre: uapi: remove userland version of obd_ioctl_*()

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:

[PATCH 07/64 v2] staging: lustre: uapi: remove userland version of obd_ioctl_*()

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:

[PATCH 09/64 v2] staging: lustre: uapi: remove obd_ioctl_popdata() wrapper

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

[PATCH 06/64 v2] staging: lustre: uapi: remove unused function in lustre_disk.h

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:

[PATCH 09/64 v2] staging: lustre: uapi: remove obd_ioctl_popdata() wrapper

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

[PATCH 06/64 v2] staging: lustre: uapi: remove unused function in lustre_disk.h

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:

[PATCH 08/64 v2] staging: lustre: uapi: remove obd_ioctl_freedata() wrapper

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

[PATCH 10/64 v2] staging: lustre: uapi: move obd_ioctl_getdata() declaration

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

[PATCH 08/64 v2] staging: lustre: uapi: remove obd_ioctl_freedata() wrapper

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

[PATCH 10/64 v2] staging: lustre: uapi: move obd_ioctl_getdata() declaration

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

[PATCH 11/64 v2] staging: lustre: uapi: move obd_ioctl_is_invalid() to linux-module.c

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

[PATCH 05/64 v2] staging: lustre: uapi: move lu_fid, ost_id funcs out of lustre_idl.h

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

[PATCH 11/64 v2] staging: lustre: uapi: move obd_ioctl_is_invalid() to linux-module.c

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:

[PATCH 05/64 v2] staging: lustre: uapi: move lu_fid, ost_id funcs out of lustre_idl.h

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

[PATCH 15/64 v2] staging: lustre: uapi: label lustre_ioctl.h as a UAPI header

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

[PATCH 14/64 v2] staging: lustre: uapi: cleanup headers for lustre_ioctl.h

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

[PATCH 14/64 v2] staging: lustre: uapi: cleanup headers for lustre_ioctl.h

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

[PATCH 15/64 v2] staging: lustre: uapi: label lustre_ioctl.h as a UAPI header

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

[PATCH 12/64 v2] staging: lustre: uapi: move lustre_ioctl.h to uapi directory

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

[PATCH 12/64 v2] staging: lustre: uapi: move lustre_ioctl.h to uapi directory

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

[PATCH 17/64 v2] staging: lustre: uapi: remove included headers out of lustre_param.h

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

[PATCH 16/64 v2] staging: lustre: uapi: move kernel only prototypes out of lustre_param.h

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

[PATCH 17/64 v2] staging: lustre: uapi: remove included headers out of lustre_param.h

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:

[PATCH 16/64 v2] staging: lustre: uapi: move kernel only prototypes out of lustre_param.h

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.

[PATCH 13/64 v2] staging: lustre: uapi: use __ALIGN_KERNEL for lustre_ioctl.h

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:

[PATCH 19/64 v2] staging: lustre: uapi: label lustre_param.h as an uapi header

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.

[PATCH 19/64 v2] staging: lustre: uapi: label lustre_param.h as an uapi header

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

[PATCH 13/64 v2] staging: lustre: uapi: use __ALIGN_KERNEL for lustre_ioctl.h

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

[PATCH 23/64 v2] staging: lustre: uapi: move lustre_cfg_string() to obd_config.c

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:

[PATCH 20/64 v2] staging: lustre: uapi: style cleanups for lustre_param.h

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

[PATCH 23/64 v2] staging: lustre: uapi: move lustre_cfg_string() to obd_config.c

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:

[PATCH 20/64 v2] staging: lustre: uapi: style cleanups for lustre_param.h

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:

[PATCH 27/64 v2] staging: lustre: uapi: change variable type to match

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

[PATCH 27/64 v2] staging: lustre: uapi: change variable type to match

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

[PATCH 22/64 v2] staging: lustre: uapi: don't memory allocate in UAPI header

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.

[PATCH 24/64 v2] staging: lustre: obdclass: no need to check for kfree

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   2   3   4   5   6   7   >