Re: [PATCH 0/6] cpuidle: menu: Fixes, optimizations and cleanups
On Tue, Oct 2, 2018 at 11:51 PM Rafael J. Wysocki wrote: > > Hi All, > > This series fixes a couple of issues with the menu governor, optimizes it > somewhat and makes a couple of cleanups in it. Please refer to the > patch changelogs for details. > > All of the changes in the series are straightforward in my view. The > first two patches are fixes, the rest is optimizations and cleanups. I'm inclined to take this stuff in for 4.20 if nobody has problems with it, so please have a look if you care (and you should, because the code in question is run on all tickless systems out there). Thanks, Rafael
[PATCH v3] regulator: bd718x7: Remove struct bd718xx_pmic
All the fields in struct bd718xx_pmic are not really necessary.
Remove struct bd718xx_pmic to simplify the code.
Signed-off-by: Axel Lin
Reviewed-by: Matti Vaittinen
---
v3: Remove the references to struct bd718xx_pmic from
include/linux/mfd/rohm-bd718x7.h
drivers/regulator/bd718x7-regulator.c | 59 +--
include/linux/mfd/rohm-bd718x7.h | 1 -
2 files changed, 20 insertions(+), 40 deletions(-)
diff --git a/drivers/regulator/bd718x7-regulator.c
b/drivers/regulator/bd718x7-regulator.c
index d2522d4e1505..3a47e0372e77 100644
--- a/drivers/regulator/bd718x7-regulator.c
+++ b/drivers/regulator/bd718x7-regulator.c
@@ -15,13 +15,6 @@
#include
#include
-struct bd718xx_pmic {
- struct bd718xx_regulator_data *rdata;
- struct bd718xx *mfd;
- struct platform_device *pdev;
- struct regulator_dev *rdev[BD718XX_REGULATOR_AMOUNT];
-};
-
/*
* BUCK1/2/3/4
* BUCK1RAMPRATE[1:0] BUCK1 DVS ramp rate setting
@@ -33,12 +26,10 @@ struct bd718xx_pmic {
static int bd718xx_buck1234_set_ramp_delay(struct regulator_dev *rdev,
int ramp_delay)
{
- struct bd718xx_pmic *pmic = rdev_get_drvdata(rdev);
- struct bd718xx *mfd = pmic->mfd;
int id = rdev->desc->id;
unsigned int ramp_value = BUCK_RAMPRATE_10P00MV;
- dev_dbg(&pmic->pdev->dev, "Buck[%d] Set Ramp = %d\n", id + 1,
+ dev_dbg(&rdev->dev, "Buck[%d] Set Ramp = %d\n", id + 1,
ramp_delay);
switch (ramp_delay) {
case 1 ... 1250:
@@ -55,12 +46,12 @@ static int bd718xx_buck1234_set_ramp_delay(struct
regulator_dev *rdev,
break;
default:
ramp_value = BUCK_RAMPRATE_10P00MV;
- dev_err(&pmic->pdev->dev,
+ dev_err(&rdev->dev,
"%s: ramp_delay: %d not supported, setting
1mV//us\n",
rdev->desc->name, ramp_delay);
}
- return regmap_update_bits(mfd->regmap, BD718XX_REG_BUCK1_CTRL + id,
+ return regmap_update_bits(rdev->regmap, BD718XX_REG_BUCK1_CTRL + id,
BUCK_RAMPRATE_MASK, ramp_value << 6);
}
@@ -1022,7 +1013,7 @@ struct bd718xx_pmic_inits {
static int bd718xx_probe(struct platform_device *pdev)
{
- struct bd718xx_pmic *pmic;
+ struct bd718xx *mfd;
struct regulator_config config = { 0 };
struct bd718xx_pmic_inits pmic_regulators[] = {
[BD718XX_TYPE_BD71837] = {
@@ -1037,54 +1028,46 @@ static int bd718xx_probe(struct platform_device *pdev)
int i, j, err;
- pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
- if (!pmic)
- return -ENOMEM;
-
- pmic->pdev = pdev;
- pmic->mfd = dev_get_drvdata(pdev->dev.parent);
-
- if (!pmic->mfd) {
+ mfd = dev_get_drvdata(pdev->dev.parent);
+ if (!mfd) {
dev_err(&pdev->dev, "No MFD driver data\n");
err = -EINVAL;
goto err;
}
- if (pmic->mfd->chip_type >= BD718XX_TYPE_AMOUNT ||
- !pmic_regulators[pmic->mfd->chip_type].r_datas) {
+
+ if (mfd->chip_type >= BD718XX_TYPE_AMOUNT ||
+ !pmic_regulators[mfd->chip_type].r_datas) {
dev_err(&pdev->dev, "Unsupported chip type\n");
err = -EINVAL;
goto err;
}
- platform_set_drvdata(pdev, pmic);
-
/* Register LOCK release */
- err = regmap_update_bits(pmic->mfd->regmap, BD718XX_REG_REGLOCK,
+ err = regmap_update_bits(mfd->regmap, BD718XX_REG_REGLOCK,
(REGLOCK_PWRSEQ | REGLOCK_VREG), 0);
if (err) {
- dev_err(&pmic->pdev->dev, "Failed to unlock PMIC (%d)\n", err);
+ dev_err(&pdev->dev, "Failed to unlock PMIC (%d)\n", err);
goto err;
} else {
- dev_dbg(&pmic->pdev->dev, "Unlocked lock register 0x%x\n",
+ dev_dbg(&pdev->dev, "Unlocked lock register 0x%x\n",
BD718XX_REG_REGLOCK);
}
- for (i = 0; i < pmic_regulators[pmic->mfd->chip_type].r_amount; i++) {
+ for (i = 0; i < pmic_regulators[mfd->chip_type].r_amount; i++) {
const struct regulator_desc *desc;
struct regulator_dev *rdev;
const struct bd718xx_regulator_data *r;
- r = &(*pmic_regulators[pmic->mfd->chip_type].r_datas)[i];
+ r = &(*pmic_regulators[mfd->chip_type].r_datas)[i];
desc = &r->desc;
config.dev = pdev->dev.parent;
- config.driver_data = pmic;
- config.regmap = pmic->mfd->regmap;
+ config.regmap = mfd->regmap;
rdev = devm_regulator_register(&pdev->dev, desc, &config);
if (IS_ERR(rdev)) {
- dev_err(pmic->mfd->dev,
+ dev_err(&pdev-
RE: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba
Hi Vignesh,
> -Original Message-
> From: Vignesh R [mailto:vigne...@ti.com]
> Sent: Wednesday, October 3, 2018 10:26 PM
> To: Boris Brezillon ; Marek Vasut
> ; Rob Herring
> Cc: Brian Norris ; Yogesh Narayan Gaur
> ; Linux ARM Mailing List ker...@lists.infradead.org>; linux-...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Vignesh R
>
> Subject: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba
>
> Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It
> supports
> read/write over 8 IO lines simulatenously. Add support for Octal read mode for
> Micron mt35xu512aba.
> Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem
> to support newer JESD216C standard that provides auto detection of Octal
> mode capabilities and opcodes. Therefore, this capability is manually added
> using new SPI_NOR_OCTAL_READ flag.
>
Thanks for sending the patch-set of adding octal support.
If possible, can you share the MT35x datasheet?
I also have the patch ready in which I have added support for Read (1-1-8 and
1-8-8) protocol and Write (1-1-8 and 1-8-8).
Also have added support of Octal in driver/spi/spi.c framework.
IMO, we would collaborate our patches.
--
Regards
Yogesh Gaur
> Signed-off-by: Vignesh R
> ---
> drivers/mtd/spi-nor/spi-nor.c | 11 ++-
> include/linux/mtd/spi-nor.h | 2 ++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index
> aff5e6ff0b2c..4926e805a8cb 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -90,6 +90,7 @@ struct flash_info {
> #define NO_CHIP_ERASEBIT(12) /* Chip does not support chip
> erase */
> #define SPI_NOR_SKIP_SFDPBIT(13) /* Skip parsing of SFDP tables */
> #define USE_CLSR BIT(14) /* use CLSR command */
> +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */
>
> int (*quad_enable)(struct spi_nor *nor);
> };
> @@ -209,6 +210,7 @@ static inline u8 spi_nor_convert_3to4_read(u8 opcode)
> { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B },
> { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B },
> { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B },
> + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B },
>
> { SPINOR_OP_READ_1_1_1_DTR,
> SPINOR_OP_READ_1_1_1_DTR_4B },
> { SPINOR_OP_READ_1_2_2_DTR,
> SPINOR_OP_READ_1_2_2_DTR_4B },
> @@ -1406,7 +1408,7 @@ static const struct flash_info spi_nor_ids[] = {
> { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K |
> USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
>
> /* Micron */
> - { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K |
> USE_FSR | SPI_NOR_4B_OPCODES) },
> + { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K |
> USE_FSR
> +| SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
>
> /* PMC */
> { "pm25lv512", INFO(0,0, 32 * 1024,2, SECT_4K_PMC) },
> @@ -3199,6 +3201,13 @@ static int spi_nor_init_params(struct spi_nor *nor,
> SNOR_PROTO_1_1_4);
> }
>
> + if (info->flags & SPI_NOR_OCTAL_READ) {
> + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8;
> + spi_nor_set_read_settings(¶ms-
> >reads[SNOR_CMD_READ_1_1_8],
> + 0, 8, SPINOR_OP_READ_1_1_8,
> + SNOR_PROTO_1_1_8);
> + }
> +
> /* Page Program settings. */
> params->hwcaps.mask |= SNOR_HWCAPS_PP;
> spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP],
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
> 8b1acf68b7ac..ae9861ed7e0f 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -50,6 +50,7 @@
> #define SPINOR_OP_READ_1_2_2 0xbb/* Read data bytes (Dual I/O
> SPI) */
> #define SPINOR_OP_READ_1_1_4 0x6b/* Read data bytes (Quad
> Output SPI) */
> #define SPINOR_OP_READ_1_4_4 0xeb/* Read data bytes (Quad I/O
> SPI) */
> +#define SPINOR_OP_READ_1_1_8 0x8b/* Read data bytes (Octal
> Output SPI) */
> #define SPINOR_OP_PP 0x02/* Page program (up to 256 bytes) */
> #define SPINOR_OP_PP_1_1_4 0x32/* Quad page program */
> #define SPINOR_OP_PP_1_4_4 0x38/* Quad page program */
> @@ -73,6 +74,7 @@
> #define SPINOR_OP_READ_1_2_2_4B 0xbc/* Read data bytes (Dual I/O
> SPI) */
> #define SPINOR_OP_READ_1_1_4_4B 0x6c/* Read data bytes (Quad
> Output SPI) */
> #define SPINOR_OP_READ_1_4_4_4B 0xec/* Read data bytes (Quad I/O
> SPI) */
> +#define SPINOR_OP_READ_1_1_8_4B 0x7c/* Read data bytes (Octal
> Output SPI) */
> #define SPINOR_OP_PP_4B 0x12/* Page program (up to 256
> bytes) */
> #define SPINOR_OP_PP_1_1_4_4B
Re: [PATCH 01/16] x86/PCI: Replace spin_is_locked() with lockdep
On Wed, Oct 03, 2018 at 11:00:51AM -0500, Bjorn Helgaas wrote:
> On Tue, Oct 02, 2018 at 10:38:47PM -0700, Lance Roy wrote:
> > lockdep_assert_held() is better suited to checking locking requirements,
> > since it won't get confused when someone else holds the lock. This is
> > also a step towards possibly removing spin_is_locked().
> >
> > Signed-off-by: Lance Roy
> > Cc: Bjorn Helgaas
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> > Cc: Borislav Petkov
> > Cc: "H. Peter Anvin"
> > Cc:
> > Cc:
>
> I assume you plan to merge the whole series together. I don't object
> to that, but I don't know enough to be able to formally ack this.
>
> It would be useful to include a tiny bit more detail in the changelog.
> The spin_is_locked() documentation doesn't mention anything about
> differences with respect to the lock being held by self vs by someone
> else, so I can't tell where the confusion arises.
The difference is that spin_is_locked() will return true when someone else holds
the lock, while lockdep_assert_held() asserts that the current thread holds the
lock. How about the following for an new changelog?
lockdep_assert_held() is better suited to checking locking requirements,
since it only checks if the current thread holds the lock regardless of
whether someone else does. This is also a step towards possibly removing
spin_is_locked().
Thanks,
Lance
> Bjorn
>
> > ---
> > arch/x86/pci/i386.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
> > index ed4ac215305d..24bb58a007de 100644
> > --- a/arch/x86/pci/i386.c
> > +++ b/arch/x86/pci/i386.c
> > @@ -59,7 +59,7 @@ static struct pcibios_fwaddrmap
> > *pcibios_fwaddrmap_lookup(struct pci_dev *dev)
> > {
> > struct pcibios_fwaddrmap *map;
> >
> > - WARN_ON_SMP(!spin_is_locked(&pcibios_fwaddrmap_lock));
> > + lockdep_assert_held(&pcibios_fwaddrmap_lock);
> >
> > list_for_each_entry(map, &pcibios_fwaddrmappings, list)
> > if (map->dev == dev)
> > --
> > 2.19.0
> >
Re: [PATCH v2] regulator: bd718x7: Remove struct bd718xx_pmic
Hello Axel,
On Wed, Oct 03, 2018 at 11:32:46PM +0800, Axel Lin wrote:
> All the fields in struct bd718xx_pmic are not really necessary.
> Remove struct bd718xx_pmic to simplify the code.
>
> Signed-off-by: Axel Lin
> ---
> v2:
> Sorry, just update the subject line.
>
> drivers/regulator/bd718x7-regulator.c | 59 +--
> 1 file changed, 20 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/regulator/bd718x7-regulator.c
> b/drivers/regulator/bd718x7-regulator.c
> index d2522d4e1505..3a47e0372e77 100644
> --- a/drivers/regulator/bd718x7-regulator.c
> +++ b/drivers/regulator/bd718x7-regulator.c
> @@ -15,13 +15,6 @@
> #include
> #include
>
> -struct bd718xx_pmic {
> - struct bd718xx_regulator_data *rdata;
> - struct bd718xx *mfd;
> - struct platform_device *pdev;
> - struct regulator_dev *rdev[BD718XX_REGULATOR_AMOUNT];
> -};
You should then also remove the references to struct bd718xx_pmic from
include/linux/mfd/rohm-bd718x7.h. Now we have there:
struct bd71837_pmic;
struct bd71837_clk;
struct bd71837 {
struct device *dev;
struct regmap *regmap;
unsigned long int id;
int chip_irq;
struct regmap_irq_chip_data *irq_data;
struct bd71837_pmic *pmic;
struct bd71837_clk *clk;
};
Other than that - simplifications are always welcome.
Reviewed-by: Matti Vaittinen
[tip:x86/urgent] x86/vdso: Fix vDSO syscall fallback asm constraint regression
Commit-ID: 02e425668f5c9deb42787d10001a3b605993ad15
Gitweb: https://git.kernel.org/tip/02e425668f5c9deb42787d10001a3b605993ad15
Author: Andy Lutomirski
AuthorDate: Wed, 3 Oct 2018 16:23:49 -0700
Committer: Ingo Molnar
CommitDate: Thu, 4 Oct 2018 08:17:50 +0200
x86/vdso: Fix vDSO syscall fallback asm constraint regression
When I added the missing memory outputs, I failed to update the
index of the first argument (ebx) on 32-bit builds, which broke the
fallbacks. Somehow I must have screwed up my testing or gotten
lucky.
Add another test to cover gettimeofday() as well.
Signed-off-by: Andy Lutomirski
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: sta...@vger.kernel.org
Fixes: 715bd9d12f84 ("x86/vdso: Fix asm constraints on vDSO syscall fallbacks")
Link:
http://lkml.kernel.org/r/21bd45ab04b6d838278fa5bebfa9163eceffa13c.1538608971.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/entry/vdso/vclock_gettime.c| 8 ++--
tools/testing/selftests/x86/test_vdso.c | 73 +
2 files changed, 77 insertions(+), 4 deletions(-)
diff --git a/arch/x86/entry/vdso/vclock_gettime.c
b/arch/x86/entry/vdso/vclock_gettime.c
index 134e2d2e8add..e48ca3afa091 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -68,11 +68,11 @@ notrace static long vdso_fallback_gettime(long clock,
struct timespec *ts)
asm (
"mov %%ebx, %%edx \n"
- "mov %2, %%ebx \n"
+ "mov %[clock], %%ebx \n"
"call __kernel_vsyscall \n"
"mov %%edx, %%ebx \n"
: "=a" (ret), "=m" (*ts)
- : "0" (__NR_clock_gettime), "g" (clock), "c" (ts)
+ : "0" (__NR_clock_gettime), [clock] "g" (clock), "c" (ts)
: "memory", "edx");
return ret;
}
@@ -83,11 +83,11 @@ notrace static long vdso_fallback_gtod(struct timeval *tv,
struct timezone *tz)
asm (
"mov %%ebx, %%edx \n"
- "mov %2, %%ebx \n"
+ "mov %[tv], %%ebx \n"
"call __kernel_vsyscall \n"
"mov %%edx, %%ebx \n"
: "=a" (ret), "=m" (*tv), "=m" (*tz)
- : "0" (__NR_gettimeofday), "g" (tv), "c" (tz)
+ : "0" (__NR_gettimeofday), [tv] "g" (tv), "c" (tz)
: "memory", "edx");
return ret;
}
diff --git a/tools/testing/selftests/x86/test_vdso.c
b/tools/testing/selftests/x86/test_vdso.c
index 49f7294fb382..35edd61d1663 100644
--- a/tools/testing/selftests/x86/test_vdso.c
+++ b/tools/testing/selftests/x86/test_vdso.c
@@ -36,6 +36,10 @@ typedef int (*vgettime_t)(clockid_t, struct timespec *);
vgettime_t vdso_clock_gettime;
+typedef long (*vgtod_t)(struct timeval *tv, struct timezone *tz);
+
+vgtod_t vdso_gettimeofday;
+
typedef long (*getcpu_t)(unsigned *, unsigned *, void *);
getcpu_t vgetcpu;
@@ -104,6 +108,11 @@ static void fill_function_pointers()
vdso_clock_gettime = (vgettime_t)dlsym(vdso, "__vdso_clock_gettime");
if (!vdso_clock_gettime)
printf("Warning: failed to find clock_gettime in vDSO\n");
+
+ vdso_gettimeofday = (vgtod_t)dlsym(vdso, "__vdso_gettimeofday");
+ if (!vdso_gettimeofday)
+ printf("Warning: failed to find gettimeofday in vDSO\n");
+
}
static long sys_getcpu(unsigned * cpu, unsigned * node,
@@ -117,6 +126,11 @@ static inline int sys_clock_gettime(clockid_t id, struct
timespec *ts)
return syscall(__NR_clock_gettime, id, ts);
}
+static inline int sys_gettimeofday(struct timeval *tv, struct timezone *tz)
+{
+ return syscall(__NR_gettimeofday, tv, tz);
+}
+
static void test_getcpu(void)
{
printf("[RUN]\tTesting getcpu...\n");
@@ -177,6 +191,14 @@ static bool ts_leq(const struct timespec *a, const struct
timespec *b)
return a->tv_nsec <= b->tv_nsec;
}
+static bool tv_leq(const struct timeval *a, const struct timeval *b)
+{
+ if (a->tv_sec != b->tv_sec)
+ return a->tv_sec < b->tv_sec;
+ else
+ return a->tv_usec <= b->tv_usec;
+}
+
static char const * const clocknames[] = {
[0] = "CLOCK_REALTIME",
[1] = "CLOCK_MONOTONIC",
@@ -248,11 +270,62 @@ static void test_clock_gettime(void)
test_one_clock_gettime(INT_MAX, "invalid");
}
+static void test_gettimeofday(void)
+{
+ struct timeval start, vdso, end;
+ struct timezone sys_tz, vdso_tz;
+ int vdso_ret, end_ret;
+
+ if (!vdso_gettimeofday)
+ return;
+
+ printf("[RUN]\tTesting gettimeofday...\n");
+
+ if (sys_gettimeofday(&start, &sys_tz) < 0) {
+ printf("[FAIL]\tsys_gettimeofday failed (%d)\n", errno);
+ nerrs++;
+ return;
+ }
+
+ vdso_ret = vdso_gettimeofday(&vdso, &vdso_tz);
+ end_ret = sys_gettimeofday(&end, NULL);
+
+ if (vdso_ret != 0 || end_ret != 0) {
+
Re: linux-next: build failure after merge of the slave-dma tree
Hi Stephen,
On 04-10-18, 15:44, Stephen Rothwell wrote:
> Hi Vinod,
>
> After merging the slave-dma tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/dma/fsl-edma.c:67: warning: "EDMA_SEEI_SEEI" redefined
> #define EDMA_SEEI_SEEI(x) ((x) & 0x1F)
>
> In file included from drivers/dma/fsl-edma.c:25:
> drivers/dma/fsl-edma-common.h:21: note: this is the location of the previous
> definition
> #define EDMA_SEEI_SEEI(x) ((x) & GENMASK(4, 0))
>
> ...
>
> drivers/dma/fsl-edma.c:115:6: error: nested redefinition of 'enum
> fsl_edma_pm_state'
> enum fsl_edma_pm_state {
> ^
> drivers/dma/fsl-edma.c:115:6: error: redeclaration of 'enum fsl_edma_pm_state'
> In file included from drivers/dma/fsl-edma.c:25:
> drivers/dma/fsl-edma-common.h:63:6: note: originally defined here
> enum fsl_edma_pm_state {
> ^
>
> and so on ...
>
> Caused by commit
>
> 101d256a45ed ("Merge branch 'testing/dirn_remove' into next")
>
> which reintroduced a whole lot of stuff into drivers/dma/fsl-edma.c that
> had been modev out in commit
>
> 9d831528a656 ("dmaengine: fsl-edma: extract common fsl-edma code (no
> changes in behavior intended)")
I got a merge conflict but for include, so looks like merge went bad.
I will redo it and push
> I used the slave-dma tree from next-20181003 for today.
Thanks for updating
Best Regards,
--
~Vinod
linux-next: manual merge of the userns tree with the y2038 tree
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in:
kernel/signal.c
between commit:
49c39f8464a9 ("y2038: signal: Change rt_sigtimedwait to use
__kernel_timespec")
from the y2038 tree and commit:
ae7795bc6187 ("signal: Distinguish between kernel_siginfo and siginfo")
from the userns tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/signal.c
index 0ff8305a26eb,1c2dd117fee0..
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@@ -3081,8 -3131,8 +3131,8 @@@ int copy_siginfo_from_user32(struct ker
* @info: if non-null, the signal's siginfo is returned here
* @ts: upper bound on process time suspension
*/
- static int do_sigtimedwait(const sigset_t *which, siginfo_t *info,
+ static int do_sigtimedwait(const sigset_t *which, kernel_siginfo_t *info,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
ktime_t *to = NULL, timeout = KTIME_MAX;
struct task_struct *tsk = current;
@@@ -3145,8 -3194,8 +3195,8 @@@ SYSCALL_DEFINE4(rt_sigtimedwait, const
size_t, sigsetsize)
{
sigset_t these;
- struct timespec ts;
+ struct timespec64 ts;
- siginfo_t info;
+ kernel_siginfo_t info;
int ret;
/* XXX: Don't preclude handling different sized sigset_t's. */
@@@ -3174,11 -3223,11 +3224,11 @@@
#ifdef CONFIG_COMPAT
COMPAT_SYSCALL_DEFINE4(rt_sigtimedwait, compat_sigset_t __user *, uthese,
struct compat_siginfo __user *, uinfo,
- struct compat_timespec __user *, uts, compat_size_t, sigsetsize)
+ struct old_timespec32 __user *, uts, compat_size_t, sigsetsize)
{
sigset_t s;
- struct timespec t;
+ struct timespec64 t;
- siginfo_t info;
+ kernel_siginfo_t info;
long ret;
if (sigsetsize != sizeof(sigset_t))
pgpMEQ6vlWXGE.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc
On Wed 03-10-18 15:51:05, David Rientjes wrote: > On Wed, 3 Oct 2018, Michal Hocko wrote: > > > > > So how about this? (not tested yet but it should be pretty > > > > straightforward) > > > > > > Umm, prctl(PR_GET_THP_DISABLE)? > > > > /me confused. I thought you want to query for the flag on a > > _different_ process. > > Why would we want to check three locations (system wide setting, prctl > setting, madvise setting) to determine if a heap can be backed by thp? Because we simply have 3 different ways to control THP? Is this a real problem? > If the nh flag being exported to VmFlag is to be extended beyond what my > patch did, I suggest (1) it does it for the system wide setting as well > and/or (2) calling a helper function to determine if the vma could be > backed by thp in the first place regardless of any setting to determine if > nh/hg is important. > > The last thing I suggest is done is adding a third place to check. But conflating the three ways into a single exported symbol (be it nh or something else) just makes the api more confusing longterm. I am pretty sure we have made that mistake in the past already. What if somebody really wants to check for PR_SET_THP_DISABLE? There is currently no way to do that on a remote process right now AFAICS. So it makes sense to export the state in general. Any exported API should be about consistency. If you want to combine all three checks then just do that in the userspace or in a library function. -- Michal Hocko SUSE Labs
[PATCH] staging: emxx_udc: Remove unused device_desc declaration
Clang warns:
drivers/staging/emxx_udc/emxx_udc.c:1373:37: warning: variable
'device_desc' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static struct usb_device_descriptor device_desc = {
^
1 warning generated.
This definition hasn't been attached to anything since the driver was
introduced in commit 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile
USB Gadget driver") and neither GCC nor Clang emit any reference to the
variable in the final assembly. The only reason GCC doesn't warn about
this variable being unused is the sizeof function.
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
This seems kind of wrong given this is a USB driver but there isn't an
instance of a platform_driver in the kernel tree having a usb device
descriptor declaration so I'm unsure of how to handle this warning aside
from just removing the definition but I'm certainly open to suggestions.
drivers/staging/emxx_udc/emxx_udc.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.c
index 0e8d3f232fe9..65cc3d9af972 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -1368,25 +1368,6 @@ static void _nbu2ss_set_endpoint_stall(
}
}
-/*-*/
-/* Device Descriptor */
-static struct usb_device_descriptor device_desc = {
- .bLength = sizeof(device_desc),
- .bDescriptorType = USB_DT_DEVICE,
- .bcdUSB = cpu_to_le16(0x0200),
- .bDeviceClass = USB_CLASS_VENDOR_SPEC,
- .bDeviceSubClass = 0x00,
- .bDeviceProtocol = 0x00,
- .bMaxPacketSize0 = 64,
- .idVendor = cpu_to_le16(0x0409),
- .idProduct= cpu_to_le16(0xfff0),
- .bcdDevice= 0x,
- .iManufacturer= 0x00,
- .iProduct = 0x00,
- .iSerialNumber= 0x00,
- .bNumConfigurations = 0x01,
-};
-
/*-*/
static void _nbu2ss_set_test_mode(struct nbu2ss_udc *udc, u32 mode)
{
--
2.19.0
[PATCH RFC 1/2] clk: ti: add a usecount for autoidle
We have the scenario that first autoidle is disabled for all clocks,
then it is disabled for selected ones and then enabled for all. So
we should have some counting here, also according to the
comment in _setup_iclk_autoidle()
Signed-off-by: Andreas Kemnade
---
drivers/clk/ti/autoidle.c | 20
include/linux/clk/ti.h| 1 +
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c
index 7bb9afbe4058..be2ce42e4f33 100644
--- a/drivers/clk/ti/autoidle.c
+++ b/drivers/clk/ti/autoidle.c
@@ -48,8 +48,11 @@ int omap2_clk_deny_idle(struct clk *clk)
struct clk_hw_omap *c;
c = to_clk_hw_omap(__clk_get_hw(clk));
- if (c->ops && c->ops->deny_idle)
- c->ops->deny_idle(c);
+ if (c->ops && c->ops->deny_idle) {
+ c->autoidle_count--;
+ if (c->autoidle_count == -1)
+ c->ops->deny_idle(c);
+ }
return 0;
}
@@ -64,8 +67,11 @@ int omap2_clk_allow_idle(struct clk *clk)
struct clk_hw_omap *c;
c = to_clk_hw_omap(__clk_get_hw(clk));
- if (c->ops && c->ops->allow_idle)
- c->ops->allow_idle(c);
+ if (c->ops && c->ops->allow_idle) {
+ c->autoidle_count++;
+ if (c->autoidle_count == 0)
+ c->ops->allow_idle(c);
+ }
return 0;
}
@@ -201,8 +207,7 @@ int omap2_clk_enable_autoidle_all(void)
struct clk_hw_omap *c;
list_for_each_entry(c, &clk_hw_omap_clocks, node)
- if (c->ops && c->ops->allow_idle)
- c->ops->allow_idle(c);
+ omap2_clk_allow_idle(c->hw.clk);
_clk_generic_allow_autoidle_all();
@@ -223,8 +228,7 @@ int omap2_clk_disable_autoidle_all(void)
struct clk_hw_omap *c;
list_for_each_entry(c, &clk_hw_omap_clocks, node)
- if (c->ops && c->ops->deny_idle)
- c->ops->deny_idle(c);
+ omap2_clk_deny_idle(c->hw.clk);
_clk_generic_deny_autoidle_all();
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index a8faa38b1ed6..c460355419c0 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -159,6 +159,7 @@ struct clk_hw_omap {
const char *clkdm_name;
struct clockdomain *clkdm;
const struct clk_hw_omap_ops*ops;
+ int autoidle_count;
};
/*
--
2.11.0
[PATCH RFC 2/2] arm: mach-omap2: setup iclk autoidle according to flags
Deny autoidle for hwmods with the OCPIF_SWSUP_IDLE flag,
that makes hwmods working properly which cannot handle
autoidle properly in lower power states.
Affected is e. g. the omap_hdq.
It also disables CM_AUTOIDLE_DSS. Need to check if
that is wanted or not.
Note: Autoidle is not enabled explicitly because there
might be clocks which do not support that operation and
it is enabled afterwards in arm/mach-omap2/pm.c anyways.
Signed-off-by: Andreas Kemnade
---
arch/arm/mach-omap2/omap_hwmod.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index bb641e6c93d0..6f9687a4f421 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -131,6 +131,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2410,9 +2411,12 @@ static void __init _setup_iclk_autoidle(struct
omap_hwmod *oh)
continue;
if (os->flags & OCPIF_SWSUP_IDLE) {
- /* XXX omap_iclk_deny_idle(c); */
+ omap2_clk_deny_idle(os->_clk);
} else {
- /* XXX omap_iclk_allow_idle(c); */
+ /*
+* no allow_idle here since there is
+* later an allow idle in pm.c
+*/
clk_enable(os->_clk);
}
}
--
2.11.0
[PATCH RFC 0/2] mach-omap2: handle autoidle denial
On the gta04 with a dm3730 omap_hdq does not work properly when the device enters lower power states. Idling uart1 and 2 is enough to show up that problem, if there are no other things enabled. Further research reveals that hdq iclk must not be turned off during transfers, also according to the TRM. That fact is also correctly described in the flags but the code to handle that is incomplete. Since the order is first disable all autoidles, then disable selected and then enable all, we need to either change that order or add a usecount. Since it is done only in init, we could think about changing order. Andreas Kemnade (2): clk: ti: add a usecount for autoidle arm: mach-omap2: setup iclk autoidle according to flags arch/arm/mach-omap2/omap_hwmod.c | 8 ++-- drivers/clk/ti/autoidle.c| 20 include/linux/clk/ti.h | 1 + 3 files changed, 19 insertions(+), 10 deletions(-) -- 2.11.0
Re: [PATCH] ALSA: hda/realtek - Cannot adjust speaker's volume on Dell XPS 27 7760
On Thu, 04 Oct 2018 05:39:42 +0200,
Kai-Heng Feng wrote:
>
> The issue is the same as commit dd9aa335c880 ("ALSA: hda/realtek - Can't
> adjust speaker's volume on a Dell AIO"), the output requires to connect
> to a node with Amp-out capability.
>
> Applying the same fixup ALC298_FIXUP_SPK_VOLUME can fix the issue.
>
> BugLink: https://bugs.launchpad.net/bugs/1775068
> Signed-off-by: Kai-Heng Feng
Applied (with Cc to stable) now, thanks.
Takashi
linux-next: build failure after merge of the slave-dma tree
Hi Vinod,
After merging the slave-dma tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/dma/fsl-edma.c:67: warning: "EDMA_SEEI_SEEI" redefined
#define EDMA_SEEI_SEEI(x) ((x) & 0x1F)
In file included from drivers/dma/fsl-edma.c:25:
drivers/dma/fsl-edma-common.h:21: note: this is the location of the previous
definition
#define EDMA_SEEI_SEEI(x) ((x) & GENMASK(4, 0))
...
drivers/dma/fsl-edma.c:115:6: error: nested redefinition of 'enum
fsl_edma_pm_state'
enum fsl_edma_pm_state {
^
drivers/dma/fsl-edma.c:115:6: error: redeclaration of 'enum fsl_edma_pm_state'
In file included from drivers/dma/fsl-edma.c:25:
drivers/dma/fsl-edma-common.h:63:6: note: originally defined here
enum fsl_edma_pm_state {
^
and so on ...
Caused by commit
101d256a45ed ("Merge branch 'testing/dirn_remove' into next")
which reintroduced a whole lot of stuff into drivers/dma/fsl-edma.c that
had been modev out in commit
9d831528a656 ("dmaengine: fsl-edma: extract common fsl-edma code (no changes
in behavior intended)")
I used the slave-dma tree from next-20181003 for today.
--
Cheers,
Stephen Rothwell
pgpL8218vHcz4.pgp
Description: OpenPGP digital signature
Re: [PATCH] arm_pmu: Delete incorrect cache event mapping for some armv8_pmuv3 events.
Hi Will, can you please pull this patch? On Mon, Oct 1, 2018 at 10:09 PM Ganapatrao Kulkarni wrote: > > Hi Will, > > On Mon, Oct 1, 2018 at 7:58 PM Will Deacon wrote: > > > > Hi Ganapat, > > > > On Mon, Oct 01, 2018 at 10:07:43AM +, Kulkarni, Ganapatrao wrote: > > > Perf events L1-dcache-load-misses, L1-dcache-store-misses are mapped to > > > armv8_pmuv3 (both DT and ACPI) event L1D_CACHE_REFILL. This is incorrect, > > > since L1D_CACHE_REFILL counts both load and store misses. > > > Similarly the events L1-dcache-loads, L1-dcache-stores, dTLB-load-misses > > > and dTLB-loads are wrongly mapped. Hence Deleting all these cache events > > > from armv8_pmuv3 cache mapping. > > > > > > Signed-off-by: Ganapatrao Kulkarni > > > --- > > > arch/arm64/kernel/perf_event.c | 8 > > > 1 file changed, 8 deletions(-) > > > > The "generic" events are really implemented on a best-effort basis, as > > they rarely tend to map exactly to what the hardware supports. I think > > they originally stemmed from the x86 CPU PMU, but that doesn't really > > help us. > > This works fairly well for DT based boots, since almost all SoCs have > added remapping using custom dt object binding. > However we have concluded in the past to drop SoC specific from the > ACPI mapping and use json to add SoC/micro architecture specific > events support. > At present , When we boot with ACPI, it is misleading for these events. > > In fact, this has been pointed internally from benchmark team and > reported it as hardware bug! > IMHO, it would be much simpler to delete these misleading events > mapping rather explaining to perf tool users. > > We already have proper mapping for these events, > armv8_pmuv3_0/l1d_cache_refill/ > armv8_pmuv3_0/l1d_cache/ > [core imp def:] > l1d_cache_rd > l1d_cache_wr > l1d_cache_refill_rd > l1d_cache_refill_wr > > > > > I had a discussion with Ingo back when we originally implemented perf > > because I actually preferred not to implement the generic events at all. > > However, he was strongly of the opinion that a best-effort approach was > > sufficient to get casual users going with the tool, so that's what we went > > with. > > thanks for the background info, these generic mapping fairly works > except these events. > > > > > Will > > thanks, > Ganapat thanks, Ganapat
Re: [BUG] sound: pci: trident: a possible data race
On Thu, 04 Oct 2018 05:08:45 +0200, Jia-Ju Bai wrote: > > Thanks for the reply :) > > > On 2018/10/3 23:54, Takashi Iwai wrote: > > On Wed, 03 Oct 2018 14:50:25 +0200, > > Jia-Ju Bai wrote: > >> CPU0: > >> snd_trident_hw_free > >> snd_trident_free_voice > >> line 3870: spin_lock_irqsave() > >> line 3881: voice->substream = NULL; [WRITE] > >> CPU1: > >> snd_trident_interrupt > >> line 3798: snd_pcm_period_elapsed(voice->substream); [READ] > >> > >> As for voice->substream, the WRITE operation in CPU0 is performed > >> with holding a spinlock, but the READ operation in CPU1 is performed > >> without holding this spinlock, so there may exist a data race. > > Thanks for the report. > > > > The actual crash must be very unlikely, almost 0%, though. > > snd_trident_hw_free() is called always after the PCM stream gets > > stopped via trigger callback, i.e. at the moment, there is no > > corresponding interrupt is generated for that voice entry. > > How about the case that playback and capture are performed concurrently? > Namely, snd_trident_hw_free() is called for playback, and the > interrupt is generated for capture. They are different substreams, hence it won't pick up the substream object. > > And the hardware is very old, I bet only a handful people still using > > in the whole world :) > > I have this hardware, so I am the one of these handful people ;) Wow, that's fun. Then we can really fix the issue, if any. Did you actually hit any relevant bug? thanks, Takashi
linux-next: build failure after merge of the tty tree
e is neither array
nor pointer nor vector
#define rx_enabled(port) ((port)->unused[1])
^
drivers/tty/serial/samsung.c:1015:2: note: in expansion of macro 'rx_enabled'
rx_enabled(port) = 1;
^~
drivers/tty/serial/samsung.c:86:41: error: subscripted value is neither array
nor pointer nor vector
#define tx_enabled(port) ((port)->unused[0])
^
drivers/tty/serial/samsung.c:1029:2: note: in expansion of macro 'tx_enabled'
tx_enabled(port) = 1;
^~
drivers/tty/serial/samsung.c: In function 's3c64xx_serial_startup':
drivers/tty/serial/samsung.c:87:41: error: subscripted value is neither array
nor pointer nor vector
#define rx_enabled(port) ((port)->unused[1])
^
drivers/tty/serial/samsung.c:1080:2: note: in expansion of macro 'rx_enabled'
rx_enabled(port) = 1;
^~
drivers/tty/serial/samsung.c:86:41: error: subscripted value is neither array
nor pointer nor vector
#define tx_enabled(port) ((port)->unused[0])
^
drivers/tty/serial/samsung.c:1082:2: note: in expansion of macro 'tx_enabled'
tx_enabled(port) = 0;
^~
drivers/tty/serial/samsung.c: In function 's3c24xx_serial_resume_noirq':
drivers/tty/serial/samsung.c:86:41: error: subscripted value is neither array
nor pointer nor vector
#define tx_enabled(port) ((port)->unused[0])
^
drivers/tty/serial/samsung.c:1966:8: note: in expansion of macro 'tx_enabled'
if (tx_enabled(port))
^~
drivers/tty/serial/samsung.c:87:41: error: subscripted value is neither array
nor pointer nor vector
#define rx_enabled(port) ((port)->unused[1])
^
drivers/tty/serial/samsung.c:1968:8: note: in expansion of macro 'rx_enabled'
if (rx_enabled(port))
^~
Caused by commit
c550f01c810f ("serial:serial_core: Allow use of CTS for PPS line discipline")
Looks like a suprise from some "interesting" previous development.
I have used the tty tree from next-20181003 for today.
--
Cheers,
Stephen Rothwell
pgpZHro5sZodO.pgp
Description: OpenPGP digital signature
[RESEND PATCHv2] misc: cxl: Fix possible null pointer dereference
It is not safe to dereference an object before a null test. It is
not needed and just remove them. Ftrace can be used instead.
Signed-off-by: zhong jiang
---
drivers/misc/cxl/guest.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
index 3bc0c15..5d28d9e 100644
--- a/drivers/misc/cxl/guest.c
+++ b/drivers/misc/cxl/guest.c
@@ -1018,8 +1018,6 @@ int cxl_guest_init_afu(struct cxl *adapter, int slice,
struct device_node *afu_n
void cxl_guest_remove_afu(struct cxl_afu *afu)
{
- pr_devel("in %s - AFU(%d)\n", __func__, afu->slice);
-
if (!afu)
return;
--
1.7.12.4
[RFC] x86/cpu_entry_area: move part of it back to fixmap
This RFC proposes to return part of the entry-area back to the fixmap to
improve system-call performance. Currently, since the entry-area is
mapped far (more than 2GB) away from the kernel text, an indirect branch
is needed to jump from the trampoline into the kernel. Due to Spectre
v2, vulnerable CPUs need to use a retpoline, which introduces an
overhead of >20 cycles.
Commit 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the fixmap")
moved the CPU entry area, as its name indicate, out of the fixmap, since
it became too big. This patch proposes to do something different: break
it into two. One part holds code+data that is needed for the entry
(trampoline code, entry stack and TSS), which is mapped in the fixmap.
The other part holds the exception_stacks, debug store and buffers, and
is left in its current (new) position.
The entry area is mapped in a different address on each CPU, so we need
to patch the relative address of the branch that jumps into the kernel.
To avoid any improper interaction with jump_labels and friends, which
might modify the entry code-page, another adjacent per-CPU code page is
used for the patched branch (and nothing else). So two direct jumps are
done on entry: one to the CPU trampoline, and then one using the patched
branch into the kernel.
Benchmarks (lmbench) show that a NULL system call is shortened from
266ns to 254ns, and others are shortened similarly. The size of the area
that is mapped into the fixmap with 8192 cores is <200MB, which is
arguably reasonable.
This RFC would probably fail on x86-32 or no PTI setups. The name
"cpu_entry_area_aux" for the second area is awful (ideas are welcomed),
it is too big to be a single patch, and the RFC is also missing some
additional parts to be a patch. It seems reasonable to ask first for
comments before putting an effort into shaping it up.
Cc: David Woodhouse
Cc: Peter Zijlstra
Cc: Andy Lutomirski
Cc: Thomas Gleixner
Signed-off-by: Nadav Amit
---
arch/x86/entry/entry_64.S | 34 +--
arch/x86/events/intel/ds.c | 10 ++--
arch/x86/include/asm/cpu_entry_area.h | 38 +++-
arch/x86/include/asm/desc.h | 2 +-
arch/x86/include/asm/fixmap.h | 23
arch/x86/include/asm/pgtable_32_types.h | 6 +-
arch/x86/include/asm/pgtable_64_types.h | 6 +-
arch/x86/kernel/cpu/common.c| 2 +-
arch/x86/kernel/traps.c | 4 +-
arch/x86/kernel/vmlinux.lds.S | 6 ++
arch/x86/mm/cpu_entry_area.c| 77 +
arch/x86/mm/dump_pagetables.c | 16 +++--
arch/x86/mm/kasan_init_64.c | 33 +++
arch/x86/mm/kaslr.c | 6 +-
arch/x86/mm/pti.c | 7 ++-
arch/x86/xen/mmu_pv.c | 1 +
16 files changed, 194 insertions(+), 77 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 957dfb693ecc..093243e35615 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -142,6 +142,22 @@ END(native_usergs_sysret64)
* with them due to bugs in both AMD and Intel CPUs.
*/
+ .pushsection .entry_cpu_trampoline, "ax"
+
+ENTRY(entry_rel_trampoline)
+ UNWIND_HINT_EMPTY
+ .byte 0xe9
+
+.global entry_rel_trampoline_rel
+entry_rel_trampoline_rel:
+ .long -5
+
+.global entry_rel_trampoline_end
+entry_rel_trampoline_end:
+END(entry_rel_trampoline)
+
+ .popsection
+
.pushsection .entry_trampoline, "ax"
/*
@@ -183,26 +199,10 @@ ENTRY(entry_SYSCALL_64_trampoline)
pushq $__USER_CS /* pt_regs->cs */
pushq %rcx/* pt_regs->ip */
- /*
-* x86 lacks a near absolute jump, and we can't jump to the real
-* entry text with a relative jump. We could push the target
-* address and then use retq, but this destroys the pipeline on
-* many CPUs (wasting over 20 cycles on Sandy Bridge). Instead,
-* spill RDI and restore it in a second-stage trampoline.
-*/
- pushq %rdi
- movq$entry_SYSCALL_64_stage2, %rdi
- JMP_NOSPEC %rdi
END(entry_SYSCALL_64_trampoline)
-
+ jmp entry_rel_trampoline
.popsection
-ENTRY(entry_SYSCALL_64_stage2)
- UNWIND_HINT_EMPTY
- popq%rdi
- jmp entry_SYSCALL_64_after_hwframe
-END(entry_SYSCALL_64_stage2)
-
ENTRY(entry_SYSCALL_64)
UNWIND_HINT_EMPTY
/*
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index b7b01d762d32..329724ccce42 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -360,7 +360,7 @@ static int alloc_pebs_buffer(int cpu)
}
hwev->ds_pebs_vaddr = buffer;
/* Update the cpu entry area mapping */
- cea = &get_cpu_entry_area(cpu)->cpu_debug_buffers.pebs_buffer;
+ cea = &get_cpu_entry_area_aux(cpu)->cpu_debug_buffers.pebs_buffer;
ds->pebs_buffer_base =
Re: [PATCHv2] misc: cxl: delete possible null pointer dereference
On 2018/10/4 12:38, Greg KH wrote:
> On Thu, Oct 04, 2018 at 10:56:48AM +0800, zhong jiang wrote:
>> It is safe to dereference an object below a NULL test. For the sake
>> of debugging. Just delete the call of possible null pointer dereference.
>>
>> Signed-off-by: zhong jiang
>> ---
>> drivers/misc/cxl/guest.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
>> index 3bc0c15..472e8db 100644
>> --- a/drivers/misc/cxl/guest.c
>> +++ b/drivers/misc/cxl/guest.c
>> @@ -1018,7 +1018,7 @@ int cxl_guest_init_afu(struct cxl *adapter, int slice,
>> struct device_node *afu_n
>>
>> void cxl_guest_remove_afu(struct cxl_afu *afu)
>> {
>> -pr_devel("in %s - AFU(%d)\n", __func__, afu->slice);
>> +pr_devel("in %s\n", __func__);
> This call should just be deleted, it's not needed, ftrace can be used
> instead.
Fine. Will do.
Sincerely,
zhong jiang
> thanks,
>
> greg k-h
>
> .
>
Re: [PATCH v3 3/7] drivers: parisc: Avoids building driver if CONFIG_PARISC is disabled
On Wed, 2018-10-03 at 21:31 -0300, Leonardo Bras wrote: > On Fri, Sep 28, 2018 at 4:15 AM James Bottomley > wrote: > > > > On Thu, 2018-09-27 at 23:08 -0300, Leonardo Brás wrote: > > > Avoids building driver if 'make drivers/parisc/' is called and > > > CONFIG_PARISC is disabled. > > > > Is that really a problem? The drivers/Makefile has this: > > > > obj-$(CONFIG_PARISC)+= parisc/ > > And you just overrode that by forcing the build. It's not even > > clear we should refuse the build in that case; how would we know > > you don't have a legitimate reason for the override? > > > > Sorry I did not explained my reasons earlier. I sent everybody > involved an e-mail explaining the full reason of this change. > (For reference it's here: https://lkml.org/lkml/2018/10/3/707) Well it's not really that persuasive. Most people simply let the build run to completion, but if you have a problem with a job control 3h timelimit, then create a job that kills itself at 2:59 and then resubmits itself. That will produce a complete build in 3h chunks without any need to call sub Makefiles. All of our Makefiles are coded assuming the upper level can prevent descent into the lower ones. You're proposing to change that assumption, requiring a fairly large patch set, which doesn't really seem to provide a huge benefit. James > > Signed-off-by: Leonardo Brás > > > --- > > > drivers/parisc/Makefile | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/parisc/Makefile b/drivers/parisc/Makefile > > > index 3cd5e6cb8478..80049d763aa0 100644 > > > --- a/drivers/parisc/Makefile > > > +++ b/drivers/parisc/Makefile > > > @@ -24,5 +24,5 @@ obj-$(CONFIG_EISA) += eisa.o > > > eisa_enumerator.o eisa_eeprom.o > > > obj-$(CONFIG_SUPERIO)+= superio.o > > > obj-$(CONFIG_CHASSIS_LCD_LED)+= led.o > > > obj-$(CONFIG_PDC_STABLE) += pdc_stable.o > > > -obj-y+= power.o > > > +obj-$(CONFIG_PARISC) += power.o > > > > If we conclude the use case is legitimate, that's not enough: the > > two > > inner symbols are PARISC only but CONFIG_EISA isn't. > > You are right. > It worked for my needs because I am only building the drivers, and > not linking them. But i believe doing something like I did in > zorro/Makefile would fix this all. (For reference, > https://lkml.org/lkml/2018/9/28/150 ) > > If you agree, I will send the next patchset with this change. > > Thanks for your help! > > Leonardo Bras >
Re: [PATCHv2] misc: cxl: delete possible null pointer dereference
On Thu, Oct 04, 2018 at 10:56:48AM +0800, zhong jiang wrote:
> It is safe to dereference an object below a NULL test. For the sake
> of debugging. Just delete the call of possible null pointer dereference.
>
> Signed-off-by: zhong jiang
> ---
> drivers/misc/cxl/guest.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
> index 3bc0c15..472e8db 100644
> --- a/drivers/misc/cxl/guest.c
> +++ b/drivers/misc/cxl/guest.c
> @@ -1018,7 +1018,7 @@ int cxl_guest_init_afu(struct cxl *adapter, int slice,
> struct device_node *afu_n
>
> void cxl_guest_remove_afu(struct cxl_afu *afu)
> {
> - pr_devel("in %s - AFU(%d)\n", __func__, afu->slice);
> + pr_devel("in %s\n", __func__);
This call should just be deleted, it's not needed, ftrace can be used
instead.
thanks,
greg k-h
[PATCH v2] kbuild: remove unneeded link_multi_deps
Since commit c8589d1e9e01 ("kbuild: handle multi-objs dependency
appropriately"), $^ really represents all the prerequisite of the
composite object being built.
Hence, $(filter %.o,$^) contains all the objects to link together,
which is much simpler than link_multi_deps calculation.
Please note $(filter-out FORCE,$^) does not work here. When a
single object module is turned into a multi object module, $^ will
contain header files that were previously included for building the
single object, and recorded in the .*.cmd file. $(filter %.o,$^)
should be used to filter out such headers.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Fix regression reported in linux-next.
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1779047.html
scripts/Makefile.build | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index cb03774..f21b48d 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -485,28 +485,12 @@ targets += $(obj)/lib-ksyms.o
endif
-#
-# Rule to link composite objects
-#
-# Composite objects are specified in kbuild makefile as follows:
-#-objs :=
-# or
-#-y:=
-# or
-#-m:=
-# The -m syntax only works if is a module
-link_multi_deps = \
-$(filter $(addprefix $(obj)/, \
-$($(subst $(obj)/,,$(@:.o=-objs)))\
-$($(subst $(obj)/,,$(@:.o=-y))) \
-$($(subst $(obj)/,,$(@:.o=-m, $^)
-
quiet_cmd_link_multi-m = LD [M] $@
-cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(link_multi_deps)
$(cmd_secanalysis)
+cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter %.o,$^)
$(cmd_secanalysis)
$(multi-used-m): FORCE
$(call if_changed,link_multi-m)
- @{ echo $(@:.o=.ko); echo $(link_multi_deps); \
+ @{ echo $(@:.o=.ko); echo $(filter %.o,$^); \
$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
$(call multi_depend, $(multi-used-m), .o, -objs -y -m)
--
2.7.4
linux-next: manual merge of the kvm-arm tree with the arm64 tree
Hi all,
Today's linux-next merge of the kvm-arm tree got conflicts in:
arch/arm/include/asm/kvm_mmu.h
arch/arm64/include/asm/kvm_arm.h
arch/arm64/include/asm/kvm_mmu.h
between commit:
ab510027dc4d ("arm64: KVM: Enable Common Not Private translations")
from the arm64 tree and commit:
0f62f0e95be2 ("kvm: arm64: Set a limit on the IPA size")
595583306434 ("kvm: arm64: Dynamic configuration of VTTBR mask")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/include/asm/kvm_mmu.h
index 847f01fa429d,5ad1a54f98dc..
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@@ -355,11 -358,8 +358,13 @@@ static inline int hyp_map_aux_data(void
#define kvm_phys_to_vttbr(addr) (addr)
+static inline bool kvm_cpu_has_cnp(void)
+{
+ return false;
+}
+
+ static inline void kvm_set_ipa_limit(void) {}
+
#endif/* !__ASSEMBLY__ */
#endif /* __ARM_KVM_MMU_H__ */
diff --cc arch/arm64/include/asm/kvm_arm.h
index b476bc46f0ab,6e324d1f1231..
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@@ -145,38 -143,127 +143,128 @@@
#define VTCR_EL2_COMMON_BITS (VTCR_EL2_SH0_INNER | VTCR_EL2_ORGN0_WBWA | \
VTCR_EL2_IRGN0_WBWA | VTCR_EL2_RES1)
- #ifdef CONFIG_ARM64_64K_PAGES
/*
- * Stage2 translation configuration:
- * 64kB pages (TG0 = 1)
- * 2 level page tables (SL = 1)
+ * VTCR_EL2:SL0 indicates the entry level for Stage2 translation.
+ * Interestingly, it depends on the page size.
+ * See D.10.2.121, VTCR_EL2, in ARM DDI 0487C.a
+ *
+ *-
+ *| Entry level | 4K | 16K/64K |
+ *--
+ *| Level: 0 | 2 | - |
+ *--
+ *| Level: 1 | 1 | 2 |
+ *--
+ *| Level: 2 | 0 | 1 |
+ *--
+ *| Level: 3 | - | 0 |
+ *--
+ *
+ * The table roughly translates to :
+ *
+ *SL0(PAGE_SIZE, Entry_level) = TGRAN_SL0_BASE - Entry_Level
+ *
+ * Where TGRAN_SL0_BASE is a magic number depending on the page size:
+ *TGRAN_SL0_BASE(4K) = 2
+ *TGRAN_SL0_BASE(16K) = 3
+ *TGRAN_SL0_BASE(64K) = 3
+ * provided we take care of ruling out the unsupported cases and
+ * Entry_Level = 4 - Number_of_levels.
+ *
*/
- #define VTCR_EL2_TGRAN_FLAGS (VTCR_EL2_TG0_64K | VTCR_EL2_SL0_LVL1)
- #define VTTBR_X_TGRAN_MAGIC 38
+ #ifdef CONFIG_ARM64_64K_PAGES
+
+ #define VTCR_EL2_TGRANVTCR_EL2_TG0_64K
+ #define VTCR_EL2_TGRAN_SL0_BASE 3UL
+
#elif defined(CONFIG_ARM64_16K_PAGES)
- /*
- * Stage2 translation configuration:
- * 16kB pages (TG0 = 2)
- * 2 level page tables (SL = 1)
- */
- #define VTCR_EL2_TGRAN_FLAGS (VTCR_EL2_TG0_16K | VTCR_EL2_SL0_LVL1)
- #define VTTBR_X_TGRAN_MAGIC 42
+
+ #define VTCR_EL2_TGRANVTCR_EL2_TG0_16K
+ #define VTCR_EL2_TGRAN_SL0_BASE 3UL
+
#else /* 4K */
- /*
- * Stage2 translation configuration:
- * 4kB pages (TG0 = 0)
- * 3 level page tables (SL = 1)
- */
- #define VTCR_EL2_TGRAN_FLAGS (VTCR_EL2_TG0_4K | VTCR_EL2_SL0_LVL1)
- #define VTTBR_X_TGRAN_MAGIC 37
+
+ #define VTCR_EL2_TGRANVTCR_EL2_TG0_4K
+ #define VTCR_EL2_TGRAN_SL0_BASE 2UL
+
#endif
- #define VTCR_EL2_FLAGS(VTCR_EL2_COMMON_BITS |
VTCR_EL2_TGRAN_FLAGS)
- #define VTTBR_X (VTTBR_X_TGRAN_MAGIC -
VTCR_EL2_T0SZ_IPA)
+ #define VTCR_EL2_LVLS_TO_SL0(levels) \
+ ((VTCR_EL2_TGRAN_SL0_BASE - (4 - (levels))) << VTCR_EL2_SL0_SHIFT)
+ #define VTCR_EL2_SL0_TO_LVLS(sl0) \
+ ((sl0) + 4 - VTCR_EL2_TGRAN_SL0_BASE)
+ #define VTCR_EL2_LVLS(vtcr) \
+ VTCR_EL2_SL0_TO_LVLS(((vtcr) & VTCR_EL2_SL0_MASK) >> VTCR_EL2_SL0_SHIFT)
+
+ #define VTCR_EL2_FLAGS(VTCR_EL2_COMMON_BITS |
VTCR_EL2_TGRAN)
+ #define VTCR_EL2_IPA(vtcr)(64 - ((vtcr) & VTCR_EL2_T0SZ_MASK))
+
+ /*
+ * ARM VMSAv8-64 defines an algorithm for finding the translation table
+ * descriptors in section D4.2.8 in ARM DDI 0487C.a.
+ *
+ * The algorithm defines the expectations on the translation table
+ * addresses for each level, based on PAGE_SIZE, entry level
+ * and the translat
[PATCH 3/4] cpufreq: dt: Try freeing static OPPs only if we have added them
We can not call dev_pm_opp_of_cpumask_remove_table() freely anymore
since the latest OPP core updates as that uses reference counting to
free resources. There are cases where no static OPPs are added (using
DT) for a platform and trying to remove the OPP table may end up
decrementing refcount which is already zero and hence generating
warnings.
Lets track if we were able to add static OPPs or not and then only
remove the table based on that. Some reshuffling of code is also done to
do that.
Reported-by: Niklas Cassel
Tested-by: Niklas Cassel
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq-dt.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 0a9ebf00be46..e58bfcb1169e 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -32,6 +32,7 @@ struct private_data {
struct device *cpu_dev;
struct thermal_cooling_device *cdev;
const char *reg_name;
+ bool have_static_opps;
};
static struct freq_attr *cpufreq_dt_attr[] = {
@@ -204,6 +205,15 @@ static int cpufreq_init(struct cpufreq_policy *policy)
}
}
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ ret = -ENOMEM;
+ goto out_put_regulator;
+ }
+
+ priv->reg_name = name;
+ priv->opp_table = opp_table;
+
/*
* Initialize OPP tables for all policy->cpus. They will be shared by
* all CPUs which have marked their CPUs shared with OPP bindings.
@@ -214,7 +224,8 @@ static int cpufreq_init(struct cpufreq_policy *policy)
*
* OPPs might be populated at runtime, don't check for error here
*/
- dev_pm_opp_of_cpumask_add_table(policy->cpus);
+ if (!dev_pm_opp_of_cpumask_add_table(policy->cpus))
+ priv->have_static_opps = true;
/*
* But we need OPP table to function so if it is not there let's
@@ -240,19 +251,10 @@ static int cpufreq_init(struct cpufreq_policy *policy)
__func__, ret);
}
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- ret = -ENOMEM;
- goto out_free_opp;
- }
-
- priv->reg_name = name;
- priv->opp_table = opp_table;
-
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
if (ret) {
dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
- goto out_free_priv;
+ goto out_free_opp;
}
priv->cpu_dev = cpu_dev;
@@ -282,10 +284,11 @@ static int cpufreq_init(struct cpufreq_policy *policy)
out_free_cpufreq_table:
dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
-out_free_priv:
- kfree(priv);
out_free_opp:
- dev_pm_opp_of_cpumask_remove_table(policy->cpus);
+ if (priv->have_static_opps)
+ dev_pm_opp_of_cpumask_remove_table(policy->cpus);
+ kfree(priv);
+out_put_regulator:
if (name)
dev_pm_opp_put_regulators(opp_table);
out_put_clk:
@@ -300,7 +303,8 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
cpufreq_cooling_unregister(priv->cdev);
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
- dev_pm_opp_of_cpumask_remove_table(policy->related_cpus);
+ if (priv->have_static_opps)
+ dev_pm_opp_of_cpumask_remove_table(policy->related_cpus);
if (priv->reg_name)
dev_pm_opp_put_regulators(priv->opp_table);
--
2.18.0.rc1.242.g61856ae69a2c
[PATCH 0/4] OPP: Fix more bugs and improve error handling
Hello, Few more bugs have surfaced recently, few of which have been there forever but came to light only after the recent changes in OPP core. Dave already sent fix for one of them sometime back and as he isn't around for a week, I picked up the patch, modified it and posting V2 of it here. Niklas already helped testing two of these on Qcom hardware where he originally faced the issues. -- Viresh Dave Gerlach (1): PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added Viresh Kumar (3): OPP: Improve error handling in dev_pm_opp_of_cpumask_add_table() OPP: Return error on error from dev_pm_opp_get_opp_count() cpufreq: dt: Try freeing static OPPs only if we have added them drivers/cpufreq/cpufreq-dt.c | 34 +--- drivers/opp/core.c | 2 +- drivers/opp/of.c | 51 ++-- 3 files changed, 52 insertions(+), 35 deletions(-) -- 2.18.0.rc1.242.g61856ae69a2c
[PATCH 1/4] OPP: Improve error handling in dev_pm_opp_of_cpumask_add_table()
The error handling wasn't appropriate in
dev_pm_opp_of_cpumask_add_table(). For example it returns 0 on success
and also for the case where cpumask is empty or cpu_device wasn't found
for any of the CPUs.
It should really return error on such cases, so that the callers can be
aware of the outcome.
Fix it.
Signed-off-by: Viresh Kumar
---
drivers/opp/of.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index a71ff3acca0f..67a384c8ead2 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -614,16 +614,18 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_of_cpumask_remove_table);
int dev_pm_opp_of_cpumask_add_table(const struct cpumask *cpumask)
{
struct device *cpu_dev;
- int cpu, ret = 0;
+ int cpu, ret;
- WARN_ON(cpumask_empty(cpumask));
+ if (WARN_ON(cpumask_empty(cpumask)))
+ return -ENODEV;
for_each_cpu(cpu, cpumask) {
cpu_dev = get_cpu_device(cpu);
if (!cpu_dev) {
pr_err("%s: failed to get cpu%d device\n", __func__,
cpu);
- continue;
+ ret = -ENODEV;
+ goto remove_table;
}
ret = dev_pm_opp_of_add_table(cpu_dev);
@@ -635,12 +637,16 @@ int dev_pm_opp_of_cpumask_add_table(const struct cpumask
*cpumask)
pr_debug("%s: couldn't find opp table for cpu:%d, %d\n",
__func__, cpu, ret);
- /* Free all other OPPs */
- _dev_pm_opp_cpumask_remove_table(cpumask, cpu);
- break;
+ goto remove_table;
}
}
+ return 0;
+
+remove_table:
+ /* Free all other OPPs */
+ _dev_pm_opp_cpumask_remove_table(cpumask, cpu);
+
return ret;
}
EXPORT_SYMBOL_GPL(dev_pm_opp_of_cpumask_add_table);
--
2.18.0.rc1.242.g61856ae69a2c
[PATCH 2/4] OPP: Return error on error from dev_pm_opp_get_opp_count()
Return error number instead of 0 on failures.
Fixes: a1e8c13600bf ("PM / OPP: "opp-hz" is optional for power domains")
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index cdf918aaac34..2c2df4e4fc14 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -318,7 +318,7 @@ int dev_pm_opp_get_opp_count(struct device *dev)
count = PTR_ERR(opp_table);
dev_dbg(dev, "%s: OPP table not found (%d)\n",
__func__, count);
- return 0;
+ return count;
}
count = _get_opp_count(opp_table);
--
2.18.0.rc1.242.g61856ae69a2c
[PATCH V2 4/4] PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added
From: Dave Gerlach
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where _opp_add_static_v2() returns 0 but no new OPP is added to the
list.
This can happen while adding duplicate OPP or if the OPP isn't supported
by hardware.
Because of this the count variable will contain the number of OPP nodes
in the table in device tree but not necessarily the ones that are
actually added.
As this count value is what is checked to determine if there are any
valid OPPs, if a platform has an operating-points-v2 table with all OPP
nodes containing opp-supported-hw values that are not currently
supported, then _of_add_opp_table_v2 will fail to abort as it should due
to an empty table.
Additionally, since commit 3ba98324e81a ("PM / OPP: Get
performance state using genpd helper"), the same count variable is
compared against the number of OPPs containing performance states and
requires that either all or none have pstates set, however in the case
of any opp table that has any entries that do not get added by
_opp_add_static_v2 due to incompatible opp-supported-hw fields, these
numbers will not match and _of_add_opp_table_v2 will incorrectly fail.
We need to clearly identify all the three cases (success, failure,
unsupported/duplicate OPPs) and then increment count only on success
case. Change return type of _opp_add_static_v2() to return the pointer
to the newly added OPP instead of an integer. This routine now returns a
valid pointer if the OPP is really added, NULL for unsupported or
duplicate OPPs, and error value cased as a pointer on errors.
Ideally the fixes tag in this commit should point back to the commit
that introduced OPP v2 initially, as that's where we started incorrectly
accounting for duplicate OPPs:
commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2"
bindings")
But it wasn't a real problem until recently as the count was only used
to check if any OPPs are added or not. And so this commit points to a
rather recent commit where we added more code that depends on the value
of "count".
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Reported-by: Dave Gerlach
Reported-by: Niklas Cassel
Tested-by: Niklas Cassel
Signed-off-by: Dave Gerlach
Signed-off-by: Viresh Kumar
---
V2:
- Dave already sent V1 for this sometime back and I am sending the
updated patch now as he isn't around and other folks are facing these
issues as well.
- Update _opp_add_static_v2() to return the OPP pointer which can now be
used to distinguish all the cases properly.
drivers/opp/of.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 67a384c8ead2..5a4b47958073 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -297,15 +297,21 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
* removed by dev_pm_opp_remove.
*
* Return:
- * 0 On success OR
+ * Valid OPP pointer:
+ * On success
+ * NULL:
* Duplicate OPPs (both freq and volt are same) and opp->available
- * -EEXIST Freq are same and volt are different OR
+ * OR if the OPP is not supported by hardware.
+ * ERR_PTR(-EEXIST):
+ * Freq are same and volt are different OR
* Duplicate OPPs (both freq and volt are same) and !opp->available
- * -ENOMEM Memory allocation failure
- * -EINVAL Failed parsing the OPP node
+ * ERR_PTR(-ENOMEM):
+ * Memory allocation failure
+ * ERR_PTR(-EINVAL):
+ * Failed parsing the OPP node
*/
-static int _opp_add_static_v2(struct opp_table *opp_table, struct device *dev,
- struct device_node *np)
+static struct dev_pm_opp *_opp_add_static_v2(struct opp_table *opp_table,
+ struct device *dev, struct device_node *np)
{
struct dev_pm_opp *new_opp;
u64 rate = 0;
@@ -315,7 +321,7 @@ static int _opp_add_static_v2(struct opp_table *opp_table,
struct device *dev,
new_opp = _opp_allocate(opp_table);
if (!new_opp)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
ret = of_property_read_u64(np, "opp-hz", &rate);
if (ret < 0) {
@@ -390,12 +396,12 @@ static int _opp_add_static_v2(struct opp_table
*opp_table, struct device *dev,
* frequency/voltage list.
*/
blocking_notifier_call_chain(&opp_table->head, OPP_EVENT_ADD, new_opp);
- return 0;
+ return new_opp;
free_opp:
_opp_free(new_opp);
- return ret;
+ return ERR_PTR(ret);
}
/* Initializes OPP tables based on new bindings */
@@ -415,14 +421,15 @@ static int _of_add_opp_table_v2(struct device *dev,
struct opp_table *opp_table)
/* We have opp
linux-next: manual merge of the kvm-arm tree with the arm64 tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
arch/arm64/include/asm/cpufeature.h
between commit:
520ad98871a0 ("arm64/cpufeatures: Factorize emulate_mrs()")
from the arm64 tree and commit:
ce00e3cb4fb4 ("arm64: Add a helper for PARange to physical shift conversion")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/include/asm/cpufeature.h
index 6db48d90ad63,072cc1c970c2..
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@@ -536,7 -530,26 +536,28 @@@ void arm64_set_ssbd_mitigation(bool sta
static inline void arm64_set_ssbd_mitigation(bool state) {}
#endif
+ static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange)
+ {
+ switch (parange) {
+ case 0: return 32;
+ case 1: return 36;
+ case 2: return 40;
+ case 3: return 42;
+ case 4: return 44;
+ case 5: return 48;
+ case 6: return 52;
+ /*
+* A future PE could use a value unknown to the kernel.
+* However, by the "D10.1.4 Principles of the ID scheme
+* for fields in ID registers", ARM DDI 0487C.a, any new
+* value is guaranteed to be higher than what we know already.
+* As a safe limit, we return the limit supported by the kernel.
+*/
+ default: return CONFIG_ARM64_PA_BITS;
+ }
+ }
++
+extern int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
#endif /* __ASSEMBLY__ */
#endif
pgpc5nkoPpjie.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler
On Tue, 2018-10-02 at 21:36 +0200, Jann Horn wrote:
> +Andy for opinions on things in write handlers
> +Mimi Zohar as EVM maintainer
>
> On Tue, Oct 2, 2018 at 9:55 AM joeyli wrote:
> > On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> > > On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi
> > > wrote:
> > > > This patch adds a snapshot keys handler for using the key retention
> > > > service api to create keys for snapshot image encryption and
> > > > authentication.
> > [...snip]
> > > > +static ssize_t disk_kmk_store(struct kobject *kobj, struct
> > > > kobj_attribute *attr,
> > > > + const char *buf, size_t n)
> > > > +{
> > > > + int error = 0;
> > > > + char *p;
> > > > + int len;
> > > > +
> > > > + if (!capable(CAP_SYS_ADMIN))
> > > > + return -EPERM;
> > >
> > > This is wrong, you can't use capable() in a write handler. You'd have
> > > to use file_ns_capable(), and I think sysfs currently doesn't give you
> > > a pointer to the struct file.
> > > If you want to do this in a write handler, you'll have to either get
> > > rid of this check or plumb through the cred struct pointer.
> > > Alternatively, you could use some interface that doesn't go through a
> > > write handler.
> > >
> >
> > Thank you for point out this problem.
> >
> > Actually the evm_write_key() is the example for my code. The
> > difference is that evm creates interface file on securityfs, but my
> > implementation is on sysfs:
> >
> > security/integrity/evm/evm_secfs.c
> >
> > static ssize_t evm_write_key(struct file *file, const char __user *buf,
> > size_t count, loff_t *ppos)
> > {
> > int i, ret;
> >
> > if (!capable(CAP_SYS_ADMIN) || (evm_initialized & EVM_SETUP))
> > return -EPERM;
> > ...
> >
> > On the other hand, the writing handler of /sys/power/wake_lock also
> > uses capable() to check the CAP_BLOCK_SUSPEND capability:
> >
> > kernel/power/main.c
> > static ssize_t wake_lock_store(struct kobject *kobj,
> >struct kobj_attribute *attr,
> >const char *buf, size_t n)
> > {
> > int error = pm_wake_lock(buf);
> > return error ? error : n;
> > }
> > power_attr(wake_lock);
> >
> > kernel/power/wakelock.c
> > int pm_wake_lock(const char *buf)
> > {
> > ...
> > if (!capable(CAP_BLOCK_SUSPEND))
> > return -EPERM;
> > ...
> >
> >
> > So I confused for when can capable() be used in sysfs interface? Is
> > capable() only allowed in reading handler? Why the writing handler
> > of securityfs can use capable()?
>
> They can't, they're all wrong. :P All of these capable() checks in
> write handlers have to be assumed to be ineffective. But it's not a
> big deal because you still need UID 0 to access these files.
Thanks, Jann. At least EVM should be updated to replace the existing
"capable" check with "if (file_ns_capable(file, &init_user_ns,
CAP_SYS_ADMIN))".
>
> > > > +static int user_key_init(void)
> > > > +{
> > > > + struct user_key_payload *ukp;
> > > > + struct key *key;
> > > > + int err = 0;
> > > > +
> > > > + pr_debug("%s\n", __func__);
> > > > +
> > > > + /* find out swsusp-key */
> > > > + key = request_key(&key_type_user, skey.key_name, NULL);
> > >
> > > request_key() looks at current's keyring. That shouldn't happen in a
> > > write handler.
> > >
> >
> > The evm_write_key() also uses request_key() but it's on securityfs. Should
> > I move my sysfs interface to securityfs?
>
> I don't think you should be doing this in the context of any
> filesystem. If EVM does that, EVM is doing it wrong.
This is being executed in the initramfs before pivoting root.
>
> > > > + if (IS_ERR(key)) {
> > > > + pr_err("Request key error: %ld\n", PTR_ERR(key));
> > > > + err = PTR_ERR(key);
> > > > + return err;
> > > > + }
> > > > +
> > > > + down_write(&key->sem);
> > > > + ukp = user_key_payload_locked(key);
> > > > + if (!ukp) {
> > > > + /* key was revoked before we acquired its semaphore */
> > > > + err = -EKEYREVOKED;
> > > > + goto key_invalid;
> > > > + }
> > > > + if (invalid_key(ukp->data, ukp->datalen)) {
> > > > + err = -EINVAL;
> > > > + goto key_invalid;
> > > > + }
> > > > + skey.key_len = ukp->datalen;
> > > > + memcpy(skey.key, ukp->data, ukp->datalen);
> > > > + /* burn the original key contents */
> > > > + memzero_explicit(ukp->data, ukp->datalen);
> > >
> > > You just zero out the contents of the supplied key? That seems very
> > > unidiomatic for the keys subsystem, and makes me wonder why you're
> > > using the keys subsystem for this in the first place. It doesn't look
> > > like normal use of the keys subsystem.
> > >
Right, evm_write_key() is normall
Re: [alsa-devel] [PATCH linux-next v2 9/9] ASoC: rsnd: add busif property to dai stream
Hi Jiada Thank you for your feedback > >> in GEN3 SSI may use different BUSIF for data transfer, > >> this patch adds busif property to each dai stream, > >> to indicate the BUSIF used by playback/capture stream. > >> > >> Also adds rsnd_ssi_select_busif() to automatically select > >> BUSIF (currently only BUSIF0 is selected) > >> > >> Signed-off-by: Jiada Wang > >> --- (snip) > > And this patch selects it on runtime (= hw_param) ? > Because, in order to automatically determine BUSIF number, > information like SSI mode (non-Split/Split/Ex-Split), runtime channel, > are required > (in our internal implementation, SSI mode is selected by kctrl) > because of this, in this patch, BUSIF is selected on runtime > > > But, I think we can/should select it on probe timing from DT connection. > > Am I misunderstanding ? > with the above reasoning, BUSIF is selected on runtime. > what do you think? I have no objection that you are customizing your kernel locally. But, upstreaming kernel based on it is not acceptable for me. I'm not sure detail of your local implementation, but I don't think we need to select SSI mode by kctrl. If my understanding was correct, it can also be selected automatically somehow. Or, am I misunderstanding ? I could understand what you want to do, and yes, I can agree that we want/need to have it on upstream. Thank you very much to indicating it to me. But we need to consider more how to implement it. Especially, it is related to DT bindings. As you already know, if it is implemented on upstream kernel, we need to keep compatibility in the future, and it is very difficult. So, my opinions for BUSIFn support are - SSI mode should be selected automatically - BUSIFn connection should be selected on DT (I think we don't want random sound output position ?) - To select it, we need to have new "ssiu" DT seetings, or parse sound card. Maybe adding ssiu is realistic. Best regards --- Kuninori Morimoto
Re: linux-next: occassional build errors
Hi Masahiro, On Thu, 4 Oct 2018 12:09:54 +0900 Masahiro Yamada wrote: > > OK, confirmed. > > > This is a regression of > > commit bb5de5d28f730eeec0aa1ced51a6f11327cd1201 > Author: Masahiro Yamada > Date: Thu Sep 13 17:20:41 2018 +0900 > > kbuild: remove unneeded link_multi_deps > > > > I will fix like follows for tomorrow's linux-next. Thanks! I am glad that there was a good reason :-) Thanks. -- Cheers, Stephen Rothwell pgpw_E4spk6EQ.pgp Description: OpenPGP digital signature
[PATCH] ALSA: hda/realtek - Cannot adjust speaker's volume on Dell XPS 27 7760
The issue is the same as commit dd9aa335c880 ("ALSA: hda/realtek - Can't
adjust speaker's volume on a Dell AIO"), the output requires to connect
to a node with Amp-out capability.
Applying the same fixup ALC298_FIXUP_SPK_VOLUME can fix the issue.
BugLink: https://bugs.launchpad.net/bugs/1775068
Signed-off-by: Kai-Heng Feng
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 6f3c8e888c2a..69283633ae91 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6409,6 +6409,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1028, 0x0706, "Dell Inspiron 7559",
ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
SND_PCI_QUIRK(0x1028, 0x0725, "Dell Inspiron 3162",
ALC255_FIXUP_DELL_SPK_NOISE),
SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360",
ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+ SND_PCI_QUIRK(0x1028, 0x075c, "Dell XPS 27 7760",
ALC298_FIXUP_SPK_VOLUME),
SND_PCI_QUIRK(0x1028, 0x075d, "Dell AIO", ALC298_FIXUP_SPK_VOLUME),
SND_PCI_QUIRK(0x1028, 0x07b0, "Dell Precision 7520",
ALC295_FIXUP_DISABLE_DAC3),
SND_PCI_QUIRK(0x1028, 0x0798, "Dell Inspiron 17 7000 Gaming",
ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
--
2.17.1
RE: [PATCHv1] RDMA/core: Check error status of rdma_find_ndev_for_src_ip_rcu
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Jason Gunthorpe
> Sent: Wednesday, October 3, 2018 9:48 PM
> To: Parav Pandit
> Cc: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> l...@kernel.org; Daniel Jurgens ;
> dledf...@redhat.com
> Subject: Re: [PATCHv1] RDMA/core: Check error status of
> rdma_find_ndev_for_src_ip_rcu
>
> On Thu, Oct 04, 2018 at 02:28:54AM +, Parav Pandit wrote:
> > Hi Doug, Jason,
> >
> > > From: Parav Pandit
> > > Sent: Friday, September 21, 2018 10:00 AM
> > > To: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > l...@kernel.org; j...@ziepe.ca; syzkaller-b...@googlegroups.com;
> > > Daniel Jurgens ; dledf...@redhat.com
> > > Cc: Parav Pandit
> > > Subject: [PATCHv1] RDMA/core: Check error status of
> > > rdma_find_ndev_for_src_ip_rcu
> > >
> > > rdma_find_ndev_for_src_ip_rcu() returns either valid netdev pointer
> > > or ERR_PTR().
> > > Instead of checking for NULL, check for error.
> > >
> > > Fixes: caf1e3ae9fa6 ("RDMA/core Introduce and use
> > > rdma_find_ndev_for_src_ip_rcu")
> > > Reported-by: syzbot+20c32fa6ff84a2d28...@syzkaller.appspotmail.com
> > > Signed-off-by: Parav Pandit
> > > drivers/infiniband/core/addr.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/infiniband/core/addr.c
> > > b/drivers/infiniband/core/addr.c index c2ca9e4..3c07eeb 100644
> > > +++ b/drivers/infiniband/core/addr.c
> > > @@ -513,8 +513,8 @@ static int rdma_set_src_addr_rcu(struct
> > > rdma_dev_addr *dev_addr,
> > >* loopback IP address.
> > >*/
> > > ndev = rdma_find_ndev_for_src_ip_rcu(dev_net(ndev),
> > > dst_in);
> > > - if (!ndev)
> > > - return -ENODEV;
> > > + if (IS_ERR(ndev))
> > > + return PTR_ERR(ndev);
> > > }
> > >
> > > return copy_src_l2_addr(dev_addr, dst_in, dst, ndev);
> >
> > Can you please review this fix? I got below report from syzbot that
> > it tested the patch and reproducer didn't trigger.
>
> It is very strange, but this patch does not show up in rdma's patch works.
>
> This happened to Dennis as well for one patch, I'm afraid as a general rule,
> people will need to check that patchworks has thier patches, and maybe talk
> to LF IT about why things have gone missing.
>
> I would guess it is some spam filter issue?
Not sure, may be something wrong in my mail client configuration.
Most patches are through Leon so I will continue it that way for now.
>
> I have applied this patch from my email.
Thanks a lot.
Re: Symbols not found for some files
Dear Arnaldo,
Am 03.10.2018 um 22:57 schrieb Arnaldo Carvalho de Melo:
Em Wed, Oct 03, 2018 at 10:42:39PM +0200, Paul Menzel escreveu:
For profiling the boot on my Debian Sid/unstable system (32-bit user space),
the following service unit is used.
You forgot to mention what is the version of the perf tool in that
system, so that I could check if this got fixed somehow after that
version.
Can you please provide it?
Sorry for not mentioning it. I built it from Linus’ Linux master branch.
$ perf --version
perf version 4.19.rc5.gd7887c
Kind regards,
Paul
```
$ systemctl cat perf
# /etc/systemd/system/perf.service
[Unit]
Description=Perf 10 s
DefaultDependencies=no
[Service]
ExecStart=/usr/local/bin/perf record -F 999 -g -a -o /dev/shm/perf.data
sleep 10
[Install]
WantedBy=sysinit.target
```
Running `perf.data` through `perf script`, the messages below are shown.
```
[vdso] with build id 69dd0f0c522f0d3e2a87722d70245ab9725c8b42 not found,
continuing without symbols
/lib/systemd/libsystemd-shared-239.so with build id
196c7922a15fa971d68775522dd16e82da46ebb3 not found, continuing without
symbols
/lib/systemd/systemd-journald with build id
9e31591e8c9bb88de06e96a251f34d8a7e201f6c not found, continuing without
symbols
/lib/systemd/systemd with build id 1b92f342a959b6ff370b82092bfadaf1d470a7b9
not found, continuing without symbols
/lib/systemd/systemd-networkd with build id
9fa8f6abc1f2e5c1018d0a33be058c22e25efaff not found, continuing without
symbols
/lib/systemd/systemd-logind with build id
63d664b5f8f8e85274aff6730ec9e924d74c8fed not found, continuing without
symbols
```
But, the debug symbol packages are installed (`systemd-dbgsym`), and GDB
loads the debug symbols just fine.
```
$ gdb --quiet /lib/systemd/libsystemd-shared-239.so
Reading symbols from /lib/systemd/libsystemd-shared-239.so...Reading symbols
from
/usr/lib/debug/.build-id/19/6c7922a15fa971d68775522dd16e82da46ebb3.debug...done.
done.
(gdb)
```
Tracing `perf`, it also seems to find them, but does not use them.
```
stat64("/home/kodi/.debug/.build-id/a2/03af6935d5ab00f79fe12b4098d27d3f70c19f",
0xbfbd54ac) = -1 ENOENT (No such file or directory)
stat64("/home/kodi/.debug/.build-id/a2/03af6935d5ab00f79fe12b4098d27d3f70c19f/elf",
0xbfbd75bc) = -1 ENOENT (No such file or directory)
stat64("03af6935d5ab00f79fe12b4098d27d3f70c19f.debug", 0xbfbd1bfc) = -1
ENOENT (No such file or directory)
stat64("/lib/i386-linux-gnu/03af6935d5ab00f79fe12b4098d27d3f70c19f.debug",
0xbfbd1bfc) = -1 ENOENT (No such file or directory)
stat64("/lib/i386-linux-gnu/.debug/03af6935d5ab00f79fe12b4098d27d3f70c19f.debug",
0xbfbd1bfc) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/lib/i386-linux-gnu/03af6935d5ab00f79fe12b4098d27d3f70c19f.debug",
0xbfbd1bfc) = -1 ENOENT (No such file or directory)
stat64("/home/kodi/.debug/.build-id/a2/03af6935d5ab00f79fe12b4098d27d3f70c19f",
0xbfbd1b5c) = -1 ENOENT (No such file or directory)
stat64("/home/kodi/.debug/.build-id/a2/03af6935d5ab00f79fe12b4098d27d3f70c19f/elf",
0xbfbd3c6c) = -1 ENOENT (No such file or directory)
stat64("/home/kodi/.debug/.build-id/a2/03af6935d5ab00f79fe12b4098d27d3f70c19f",
0xbfbd1b5c) = -1 ENOENT (No such file or directory)
stat64("/home/kodi/.debug/.build-id/a2/03af6935d5ab00f79fe12b4098d27d3f70c19f/debug",
0xbfbd3c6c) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/.build-id/a2/03af6935d5ab00f79fe12b4098d27d3f70c19f.debug",
{st_mode=S_IFREG|0644, st_size=4524336, ...}) = 0
openat(AT_FDCWD,
"/usr/lib/debug/.build-id/a2/03af6935d5ab00f79fe12b4098d27d3f70c19f.debug",
O_RDONLY|O_LARGEFILE) = 91
```
Looking into `perf` with GDB, the code in `util/symbol.c` below is not
setting `runtime_ss`, because `symsrc__possibly_runtime(ss)` returns false.
Then the for loop is not quit, and continues.
```
if (!syms_ss && symsrc__has_symtab(ss)) {
syms_ss = ss;
next_slot = true;
if (!dso->symsrc_filename)
dso->symsrc_filename = strdup(name);
}
if (!runtime_ss && symsrc__possibly_runtime(ss)) {
runtime_ss = ss;
next_slot = true;
}
if (next_slot) {
ss_pos++;
if (syms_ss && runtime_ss)
break;
} else {
symsrc__destroy(ss);
}
```
Do you have an idea, why the files from the systemd Debian package cause
problems for `perf` but not GDB? The Debian maintainers mentioned, that LTO
is enabled for the Debian package.
Please tell me, if you need other information to look into the problem.
Kind regards,
Paul
Re: [PATCH linux-next v2 1/9] arm64: r8a7795: add dma request number for busif0 ~ busif7
Hi Morimoto-san
On 2018/10/04 9:55, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your patch
From: Jiada Wang
This patch adds dma request number for busif0 ~ busif7
to be used by GEN3 series. GEN2 continues to use rxu/txu
for busif data transfer.
Signed-off-by: Jiada Wang
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 164 ---
1 file changed, 144 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index b5f2273caca4..fc6100eddfed 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1923,53 +1923,177 @@
rcar_sound,ssi {
ssi0: ssi-0 {
interrupts = ;
- dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0
0x15>, <&audma1 0x16>;
- dma-names = "rx", "tx", "rxu", "txu";
+ dmas = <&audma0 0x01>, <&audma1 0x02>,
+ <&audma0 0x15>, <&audma1 0x16>,
+ <&audma0 0x15>, <&audma1 0x16>,
+ <&audma0 0x35>, <&audma1 0x36>,
+ <&audma0 0x37>, <&audma1 0x38>,
+ <&audma0 0x47>, <&audma1 0x48>,
+ <&audma0 0x3f>, <&audma1 0x40>,
+ <&audma0 0x43>, <&audma1 0x44>,
+ <&audma0 0x4f>, <&audma1 0x50>,
+ <&audma0 0x53>, <&audma1 0x54>;
+ dma-names = "rx", "tx",
+ "rxu", "txu",
+ "rxu0", "txu0",
+ "rxu1", "txu1",
+ "rxu2", "txu2",
+ "rxu3", "txu3",
+ "rxu4", "txu4",
+ "rxu5", "txu5",
+ "rxu6", "txu6",
+ "rxu7", "txu7";
In theory, I think DT side patch should be posted/applied
if driver side patch was accepted.
And, Gen3 side DT doesn't need "rxu/txu" I think.
OK, I will separate DT and driver side change,
will remove DT change in next version.
Thanks,
Jiada
Re: [PATCH V2] hid: hid-core: Fix a sleep-in-atomic-context bug in __hid_request()
On 2018/9/30 3:20, Jiri Kosina wrote: On Sat, 29 Sep 2018, Jia-Ju Bai wrote: picolcd_send_and_wait (acquire a spinlock) hid_hw_request __hid_request hid_alloc_report_buf(GFP_KERNEL) picolcd_reset (acquire a spinlock) hid_hw_request __hid_request hid_alloc_report_buf(GFP_KERNEL) lg4ff_play (acquire a spinlock) hid_hw_request __hid_request hid_alloc_report_buf(GFP_KERNEL) lg4ff_set_autocenter_ffex (acquire a spinlock) hid_hw_request __hid_request hid_alloc_report_buf(GFP_KERNEL) Hm, so it's always drivers calling out into core in atomic context. So either we take this, and put our bets on being able to allocate the buffer without sleeping, In my opinion, I prefer this way. Why? Forcing all the report buffer to be limited to be non-sleeping allocations just because of two drivers, looks like an overkill, and actually calls for more issues (as GFP_ATOMIC is of course in principle less likely to succeed). Okay, I thought that using GFP_ATOMIC is the simplest way to fix these bugs. But I check the Linux kernel code again, and find that hid_hw_request() are called at many places. So changing this function may affect many drivers. I agree to only change the two drivers, and explicitly anotate __hid_request() with might_sleep(). Best wishes, Jia-Ju Bai
Re: x86/mm: Found insecure W+X mapping at address (ptrval)/0xc00a0000
Dear Borislav, Am 03.10.2018 um 23:22 schrieb Borislav Petkov: On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote: Sorry for the delay and thanks for the data. A quick diff did not reveal anything obvious. I'll have a closer look and we probably need more (other) information to nail that down. Just a brain dump of what I've found out so far. Thank you for looking into this. On what board are you able to reproduce this? Do you build for 32-bit or 64-bit? Kind regards, Paul
Re: linux-next: occassional build errors
Hi Stephen,
On Thu, Oct 4, 2018 at 10:57 AM Stephen Rothwell wrote:
>
> Hi Masahiro,
>
> On Thu, 4 Oct 2018 10:39:37 +1000 Stephen Rothwell
> wrote:
> >
> > On Wed, 3 Oct 2018 16:55:34 +1000 Stephen Rothwell
> > wrote:
> > >
> > > > > The latest example is this:
> > > > >
> > > > > include/linux/kconfig.h: file not recognized: file format not
> > > > > recognized
> > > > > make[2]: *** [scripts/Makefile.build:492: crypto/crypto_user.o] Error
> > > > > 1
> > > > > make[1]: *** [Makefile:1057: crypto] Error 2
> > > > > make: *** [Makefile:152: sub-make] Error 2
> > > > > Command exited with non-zero status 2
> > > > >
> > > > > It is always complaining about a .h file ...
> > > > >
> > > > > Makefile:152 is the MAKE lien below:
> > > > >
> > > > > # Invoke a second make in the output directory, passing relevant
> > > > > variables
> > > > > sub-make:
> > > > > $(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
> > > > > -f $(CURDIR)/Makefile $(filter-out _all
> > > > > sub-make,$(MAKECMDGOALS))
> > > > >
> > > > > Makefile:1057 is the MAKE line below:
> > > > >
> > > > > PHONY += $(vmlinux-dirs)
> > > > > $(vmlinux-dirs): prepare scripts
> > > > > $(Q)$(MAKE) $(build)=$@ need-builtin=1
> > > > >
> > > > > scripts/Makefile.build:492 is the if_changed line below:
> > > > >
> > > > > $(multi-used-m): FORCE
> > > > > $(call if_changed,link_multi-m)
> > > > > @{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
> > > > >$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
> > > > > $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
> > > > >
> > > > > Not sure what else I can tell you.
> > > >
> > > > Does this happen only when building a module?
> > >
> > > I don't know, sorry, I build with -s and -j80, so it is hard to tell
> > > what it is currently up to.
> >
> > Today, I got this from the x86_64 allmodconfig build after merging the hid
> > tree:
> >
> > x86_64-linux-gnu-ld: include/config/acpi.h: file not recognized: file
> > truncated
> > make[4]: *** [/home/sfr/next/next/scripts/Makefile.build:492:
> > drivers/hid/i2c-hid/i2c-hid.o] Error 1
> > make[3]: *** [/home/sfr/next/next/scripts/Makefile.build:520:
> > drivers/hid/i2c-hid] Error 2
> > make[2]: *** [/home/sfr/next/next/scripts/Makefile.build:520: drivers/hid]
> > Error 2
> > make[1]: *** [/home/sfr/next/next/Makefile:1057: drivers] Error 2
> > make: *** [Makefile:152: sub-make] Error 2
>
> OK, it seems to have to do with an object changing from a simple build
> to a multi object build.
>
> i.e. Tuesday's linux-next has these changes:
>
> obj-$(CONFIG_CRYPTO_USER) += crypto_user.o
> +crypto_user-y := crypto_user_base.o crypto_user_stat.o
> obj-$(CONFIG_CRYPTO_CMAC) += cmac.o
>
> obj-$(CONFIG_I2C_HID) += i2c-hid.o
> +
> +i2c-hid-objs = i2c-hid-core.o
> +i2c-hid-$(CONFIG_DMI) += i2c-hid-dmi-quirks.o
>
OK, confirmed.
This is a regression of
commit bb5de5d28f730eeec0aa1ced51a6f11327cd1201
Author: Masahiro Yamada
Date: Thu Sep 13 17:20:41 2018 +0900
kbuild: remove unneeded link_multi_deps
I will fix like follows for tomorrow's linux-next. Thanks!
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index d7fa203..f21b48d 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -486,11 +486,11 @@ targets += $(obj)/lib-ksyms.o
endif
quiet_cmd_link_multi-m = LD [M] $@
-cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter-out FORCE,$^)
$(cmd_secanalysis)
+cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter %.o,$^)
$(cmd_secanalysis)
$(multi-used-m): FORCE
$(call if_changed,link_multi-m)
- @{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
+ @{ echo $(@:.o=.ko); echo $(filter %.o,$^); \
$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
$(call multi_depend, $(multi-used-m), .o, -objs -y -m)
--
Best Regards
Masahiro Yamada
[PATCHv2] misc: cxl: delete possible null pointer dereference
It is safe to dereference an object below a NULL test. For the sake
of debugging. Just delete the call of possible null pointer dereference.
Signed-off-by: zhong jiang
---
drivers/misc/cxl/guest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
index 3bc0c15..472e8db 100644
--- a/drivers/misc/cxl/guest.c
+++ b/drivers/misc/cxl/guest.c
@@ -1018,7 +1018,7 @@ int cxl_guest_init_afu(struct cxl *adapter, int slice,
struct device_node *afu_n
void cxl_guest_remove_afu(struct cxl_afu *afu)
{
- pr_devel("in %s - AFU(%d)\n", __func__, afu->slice);
+ pr_devel("in %s\n", __func__);
if (!afu)
return;
--
1.7.12.4
Re: [BUG] sound: pci: trident: a possible data race
Thanks for the reply :) On 2018/10/3 23:54, Takashi Iwai wrote: On Wed, 03 Oct 2018 14:50:25 +0200, Jia-Ju Bai wrote: CPU0: snd_trident_hw_free snd_trident_free_voice line 3870: spin_lock_irqsave() line 3881: voice->substream = NULL; [WRITE] CPU1: snd_trident_interrupt line 3798: snd_pcm_period_elapsed(voice->substream); [READ] As for voice->substream, the WRITE operation in CPU0 is performed with holding a spinlock, but the READ operation in CPU1 is performed without holding this spinlock, so there may exist a data race. Thanks for the report. The actual crash must be very unlikely, almost 0%, though. snd_trident_hw_free() is called always after the PCM stream gets stopped via trigger callback, i.e. at the moment, there is no corresponding interrupt is generated for that voice entry. How about the case that playback and capture are performed concurrently? Namely, snd_trident_hw_free() is called for playback, and the interrupt is generated for capture. And the hardware is very old, I bet only a handful people still using in the whole world :) I have this hardware, so I am the one of these handful people ;) Best wishes, Jia-Ju Bai
Re: [PATCH linux-next v2 8/9] ASoC: rsnd: ssi: Request dedicated dma channels for busif0 to 7
Hi Morimoto-san
On 2018/10/04 10:12, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your patch
Currently ssi driver only request dma channel for SSI_0,
which is used to transfer data to/from busif0.
But in GEN3 busif1 to busif7 also maybe used, dedicated dma channels
are requested for data transfer through these busif.
Signed-off-by: Jiada Wang
---
(snip)
+ if (rsnd_ssi_use_busif(io)) {
+ if (is_play)
+ snprintf(name, SSI_DMA_NAME_SIZE, "rxu");
+ else
+ snprintf(name, SSI_DMA_NAME_SIZE, "txu");
+
+ if (rsnd_is_gen3(priv)) {
+ /*
+* Gen3 supports to use all available BUSIF
+*/
+ int busif = rsnd_ssi_get_busif(io);
+
+ snprintf(name, SSI_DMA_NAME_SIZE, "%s%d", name, busif);
+ }
I think unspecified GenX is better idea.
For example, we might want to have same setting on Gen2 in the future.
(and this is not Gen3 HW specific feature
But yes, we have SW side reason)
How about like this ?
We can keep compatibility, and both Gen2/Gen3 can use it.
if (rsnd_ssi_use_busif(io)) {
/*
* 1) try to find txu%d/rxu%d first
* 2) If can't find it, try to find old txu/rxu
*/
}
I think this is a good idea, by doing so,
in case GEN2 DT also starts to support different BUSIF,
then no driver side change is required.
I will update accordingly in next version
Thanks,
Jiada
Re: [PATCHv1] RDMA/core: Check error status of rdma_find_ndev_for_src_ip_rcu
On Thu, Oct 04, 2018 at 02:28:54AM +, Parav Pandit wrote:
> Hi Doug, Jason,
>
> > From: Parav Pandit
> > Sent: Friday, September 21, 2018 10:00 AM
> > To: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > l...@kernel.org; j...@ziepe.ca; syzkaller-b...@googlegroups.com; Daniel
> > Jurgens ; dledf...@redhat.com
> > Cc: Parav Pandit
> > Subject: [PATCHv1] RDMA/core: Check error status of
> > rdma_find_ndev_for_src_ip_rcu
> >
> > rdma_find_ndev_for_src_ip_rcu() returns either valid netdev pointer or
> > ERR_PTR().
> > Instead of checking for NULL, check for error.
> >
> > Fixes: caf1e3ae9fa6 ("RDMA/core Introduce and use
> > rdma_find_ndev_for_src_ip_rcu")
> > Reported-by: syzbot+20c32fa6ff84a2d28...@syzkaller.appspotmail.com
> > Signed-off-by: Parav Pandit
> > drivers/infiniband/core/addr.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
> > index c2ca9e4..3c07eeb 100644
> > +++ b/drivers/infiniband/core/addr.c
> > @@ -513,8 +513,8 @@ static int rdma_set_src_addr_rcu(struct
> > rdma_dev_addr *dev_addr,
> > * loopback IP address.
> > */
> > ndev = rdma_find_ndev_for_src_ip_rcu(dev_net(ndev),
> > dst_in);
> > - if (!ndev)
> > - return -ENODEV;
> > + if (IS_ERR(ndev))
> > + return PTR_ERR(ndev);
> > }
> >
> > return copy_src_l2_addr(dev_addr, dst_in, dst, ndev);
>
> Can you please review this fix? I got below report from syzbot that
> it tested the patch and reproducer didn't trigger.
It is very strange, but this patch does not show up in rdma's patch
works.
This happened to Dennis as well for one patch, I'm afraid as a general
rule, people will need to check that patchworks has thier patches, and
maybe talk to LF IT about why things have gone missing.
I would guess it is some spam filter issue?
I have applied this patch from my email.
Jason
Re: [PATCH] misc: cxl: Move a deference below a NULL test
On 2018/10/3 6:55, Greg KH wrote:
> On Wed, Sep 26, 2018 at 07:41:12PM +0800, zhong jiang wrote:
>> It is safe to move a deference below a NULL test.
>>
>> Signed-off-by: zhong jiang
>> Acked-by: Andrew Donnellan
>> ---
>> drivers/misc/cxl/guest.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
>> index 3bc0c15..559e835 100644
>> --- a/drivers/misc/cxl/guest.c
>> +++ b/drivers/misc/cxl/guest.c
>> @@ -1018,11 +1018,11 @@ int cxl_guest_init_afu(struct cxl *adapter, int
>> slice, struct device_node *afu_n
>>
>> void cxl_guest_remove_afu(struct cxl_afu *afu)
>> {
>> -pr_devel("in %s - AFU(%d)\n", __func__, afu->slice);
>> -
>> if (!afu)
>> return;
>>
>> +pr_devel("in %s - AFU(%d)\n", __func__, afu->slice);
>> +
> This call should just be deleted, ftrace can be used if this type of
> thing is really needed.
Ok, just delete the dereference in advance. Will repost in v2.
Thanks,
zhong jiang
> thanks,
>
> greg k-h
>
> .
>
Re: [alsa-devel] [PATCH linux-next v2 9/9] ASoC: rsnd: add busif property to dai stream
Hi Morimoto-san On 2018/10/04 10:41, Kuninori Morimoto wrote: Hi Jiada Thank you for your patch in GEN3 SSI may use different BUSIF for data transfer, this patch adds busif property to each dai stream, to indicate the BUSIF used by playback/capture stream. Also adds rsnd_ssi_select_busif() to automatically select BUSIF (currently only BUSIF0 is selected) Signed-off-by: Jiada Wang --- sound/soc/sh/rcar/core.c | 3 +++ sound/soc/sh/rcar/dma.c | 31 +++ sound/soc/sh/rcar/rsnd.h | 3 +++ sound/soc/sh/rcar/ssi.c | 30 +- 4 files changed, 66 insertions(+), 1 deletion(-) diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c index 40d7dc4f7839..5e3e6e65bcdf 100644 --- a/sound/soc/sh/rcar/core.c +++ b/sound/soc/sh/rcar/core.c @@ -1158,6 +1158,9 @@ static int rsnd_hw_params(struct snd_pcm_substream *substream, struct rsnd_dai *rdai = rsnd_dai_to_rdai(dai); struct rsnd_dai_stream *io = rsnd_rdai_to_io(rdai, substream); int ret; + int chan = rsnd_runtime_channel_for_ssi_with_params(io, hw_params); + + rsnd_ssi_select_busif(io, chan); If my understanding was correct, the chance to use BUSIFx is when TDM split mode. Yes, only when SSI works in Split/Ex-Split mode, BUSIFx other than 0 is necessary And this patch selects it on runtime (= hw_param) ? Because, in order to automatically determine BUSIF number, information like SSI mode (non-Split/Split/Ex-Split), runtime channel, are required (in our internal implementation, SSI mode is selected by kctrl) because of this, in this patch, BUSIF is selected on runtime But, I think we can/should select it on probe timing from DT connection. Am I misunderstanding ? with the above reasoning, BUSIF is selected on runtime. what do you think? Thanks, Jiada I'm not sure how to select, but adding new ssiuX0 - ssiuX7 is realistic idea (parse sound card is not realistic...) ? If so, your rxu/txu DMA can be more simple ?
[PATCH v2] spi: spi-ep93xx: Change dir type in ep93xx_spi_dma_{finish,prepare}
Clang warns when one enumerated type is implicitly converted to another.
drivers/spi/spi-ep93xx.c:342:62: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
nents = dma_map_sg(chan->device->dev, sgt->sgl, sgt->nents, dir);
^~~~
./include/linux/dma-mapping.h:428:58: note: expanded from macro
'dma_map_sg'
#define dma_map_sg(d, s, n, r) dma_map_sg_attrs(d, s, n, r, 0)
^
drivers/spi/spi-ep93xx.c:348:57: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
dma_unmap_sg(chan->device->dev, sgt->sgl, sgt->nents, dir);
~~^~~~
./include/linux/dma-mapping.h:429:62: note: expanded from macro
'dma_unmap_sg'
#define dma_unmap_sg(d, s, n, r) dma_unmap_sg_attrs(d, s, n, r, 0)
~~ ^
drivers/spi/spi-ep93xx.c:377:56: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
dma_unmap_sg(chan->device->dev, sgt->sgl, sgt->nents, dir);
~~^~~~
./include/linux/dma-mapping.h:429:62: note: expanded from macro
'dma_unmap_sg'
#define dma_unmap_sg(d, s, n, r) dma_unmap_sg_attrs(d, s, n, r, 0)
~~ ^
3 warnings generated.
dma_{,un}map_sg expects an enum of type dma_data_direction but this
driver uses dma_transfer_direction for everything. Converting to
dma_data_direction would be desirable but there are a few shared
structures that expect dma_transfer_direction so it is just simpler to
change the parameter here. dma_transfer_direction and dma_data_direction
are different sizes but this driver only uses the 1 and 2 values which
mean the same thing so this change is safe.
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Fix escaped hash symbols for '#define' lines
drivers/spi/spi-ep93xx.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-ep93xx.c b/drivers/spi/spi-ep93xx.c
index f1526757aaf6..189fc2225b69 100644
--- a/drivers/spi/spi-ep93xx.c
+++ b/drivers/spi/spi-ep93xx.c
@@ -256,8 +256,7 @@ static int ep93xx_spi_read_write(struct spi_master *master)
* in case of failure.
*/
static struct dma_async_tx_descriptor *
-ep93xx_spi_dma_prepare(struct spi_master *master,
- enum dma_transfer_direction dir)
+ep93xx_spi_dma_prepare(struct spi_master *master, int dir)
{
struct ep93xx_spi *espi = spi_master_get_devdata(master);
struct spi_transfer *xfer = master->cur_msg->state;
@@ -359,8 +358,7 @@ ep93xx_spi_dma_prepare(struct spi_master *master,
* Function finishes with the DMA transfer. After this, the DMA buffer is
* unmapped.
*/
-static void ep93xx_spi_dma_finish(struct spi_master *master,
- enum dma_transfer_direction dir)
+static void ep93xx_spi_dma_finish(struct spi_master *master, int dir)
{
struct ep93xx_spi *espi = spi_master_get_devdata(master);
struct dma_chan *chan;
--
2.19.0
[PATCH] spi: spi-ep93xx: Change dir type in ep93xx_spi_dma_{finish,prepare}
Clang warns when one enumerated type is implicitly converted to another.
drivers/spi/spi-ep93xx.c:342:62: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
nents = dma_map_sg(chan->device->dev, sgt->sgl, sgt->nents, dir);
^~~~
./include/linux/dma-mapping.h:428:58: note: expanded from macro
'dma_map_sg'
\#define dma_map_sg(d, s, n, r) dma_map_sg_attrs(d, s, n, r, 0)
^
drivers/spi/spi-ep93xx.c:348:57: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
dma_unmap_sg(chan->device->dev, sgt->sgl, sgt->nents, dir);
~~^~~~
./include/linux/dma-mapping.h:429:62: note: expanded from macro
'dma_unmap_sg'
\#define dma_unmap_sg(d, s, n, r) dma_unmap_sg_attrs(d, s, n, r, 0)
~~ ^
drivers/spi/spi-ep93xx.c:377:56: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
dma_unmap_sg(chan->device->dev, sgt->sgl, sgt->nents, dir);
~~^~~~
./include/linux/dma-mapping.h:429:62: note: expanded from macro
'dma_unmap_sg'
\#define dma_unmap_sg(d, s, n, r) dma_unmap_sg_attrs(d, s, n, r, 0)
~~ ^
3 warnings generated.
dma_{,un}map_sg expects an enum of type dma_data_direction but this
driver uses dma_transfer_direction for everything. Converting to
dma_data_direction would be desirable but there are a few shared
structures that expect dma_transfer_direction so it is just simpler to
change the parameter here. dma_transfer_direction and dma_data_direction
are different sizes but this driver only uses the 1 and 2 values which
mean the same thing so this change is safe.
Signed-off-by: Nathan Chancellor
---
drivers/spi/spi-ep93xx.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-ep93xx.c b/drivers/spi/spi-ep93xx.c
index f1526757aaf6..189fc2225b69 100644
--- a/drivers/spi/spi-ep93xx.c
+++ b/drivers/spi/spi-ep93xx.c
@@ -256,8 +256,7 @@ static int ep93xx_spi_read_write(struct spi_master *master)
* in case of failure.
*/
static struct dma_async_tx_descriptor *
-ep93xx_spi_dma_prepare(struct spi_master *master,
- enum dma_transfer_direction dir)
+ep93xx_spi_dma_prepare(struct spi_master *master, int dir)
{
struct ep93xx_spi *espi = spi_master_get_devdata(master);
struct spi_transfer *xfer = master->cur_msg->state;
@@ -359,8 +358,7 @@ ep93xx_spi_dma_prepare(struct spi_master *master,
* Function finishes with the DMA transfer. After this, the DMA buffer is
* unmapped.
*/
-static void ep93xx_spi_dma_finish(struct spi_master *master,
- enum dma_transfer_direction dir)
+static void ep93xx_spi_dma_finish(struct spi_master *master, int dir)
{
struct ep93xx_spi *espi = spi_master_get_devdata(master);
struct dma_chan *chan;
--
2.19.0
[PATCH] ata: ep93xx: Use proper enums for directions
Clang warns when one enumerated type is implicitly converted to another.
drivers/ata/pata_ep93xx.c:662:36: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
drv_data->dma_rx_data.direction = DMA_FROM_DEVICE;
~ ^~~
drivers/ata/pata_ep93xx.c:670:36: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
drv_data->dma_tx_data.direction = DMA_TO_DEVICE;
~ ^
drivers/ata/pata_ep93xx.c:681:19: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
conf.direction = DMA_FROM_DEVICE;
~ ^~~
drivers/ata/pata_ep93xx.c:692:19: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
conf.direction = DMA_TO_DEVICE;
~ ^
Use the equivalent valued enums from the expected type so that Clang no
longer warns about a conversion.
DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1
DMA_FROM_DEVICE = DMA_DEV_TO_MEM = 2
Signed-off-by: Nathan Chancellor
---
drivers/ata/pata_ep93xx.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_ep93xx.c b/drivers/ata/pata_ep93xx.c
index 0a550190955a..cc6d06c1b2c7 100644
--- a/drivers/ata/pata_ep93xx.c
+++ b/drivers/ata/pata_ep93xx.c
@@ -659,7 +659,7 @@ static void ep93xx_pata_dma_init(struct ep93xx_pata_data
*drv_data)
* start of new transfer.
*/
drv_data->dma_rx_data.port = EP93XX_DMA_IDE;
- drv_data->dma_rx_data.direction = DMA_FROM_DEVICE;
+ drv_data->dma_rx_data.direction = DMA_DEV_TO_MEM;
drv_data->dma_rx_data.name = "ep93xx-pata-rx";
drv_data->dma_rx_channel = dma_request_channel(mask,
ep93xx_pata_dma_filter, &drv_data->dma_rx_data);
@@ -667,7 +667,7 @@ static void ep93xx_pata_dma_init(struct ep93xx_pata_data
*drv_data)
return;
drv_data->dma_tx_data.port = EP93XX_DMA_IDE;
- drv_data->dma_tx_data.direction = DMA_TO_DEVICE;
+ drv_data->dma_tx_data.direction = DMA_MEM_TO_DEV;
drv_data->dma_tx_data.name = "ep93xx-pata-tx";
drv_data->dma_tx_channel = dma_request_channel(mask,
ep93xx_pata_dma_filter, &drv_data->dma_tx_data);
@@ -678,7 +678,7 @@ static void ep93xx_pata_dma_init(struct ep93xx_pata_data
*drv_data)
/* Configure receive channel direction and source address */
memset(&conf, 0, sizeof(conf));
- conf.direction = DMA_FROM_DEVICE;
+ conf.direction = DMA_DEV_TO_MEM;
conf.src_addr = drv_data->udma_in_phys;
conf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
if (dmaengine_slave_config(drv_data->dma_rx_channel, &conf)) {
@@ -689,7 +689,7 @@ static void ep93xx_pata_dma_init(struct ep93xx_pata_data
*drv_data)
/* Configure transmit channel direction and destination address */
memset(&conf, 0, sizeof(conf));
- conf.direction = DMA_TO_DEVICE;
+ conf.direction = DMA_MEM_TO_DEV;
conf.dst_addr = drv_data->udma_out_phys;
conf.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
if (dmaengine_slave_config(drv_data->dma_tx_channel, &conf)) {
--
2.19.0
[PATCH v2 3/3] mm: Maintain randomization of page free lists
When freeing a page with an order >= shuffle_page_order randomly select
the front or back of the list for insertion.
While the mm tries to defragment physical pages into huge pages this can
tend to make the page allocator more predictable over time. Inject the
front-back randomness to preserve the initial randomness established by
shuffle_free_memory() when the kernel was booted.
The overhead of this manipulation is constrained by only being applied
for MAX_ORDER sized pages by default.
Cc: Michal Hocko
Cc: Kees Cook
Cc: Dave Hansen
Signed-off-by: Dan Williams
---
include/linux/mmzone.h |2 ++
mm/page_alloc.c| 27 +--
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index adf9b3a7440d..4a095432843d 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -98,6 +98,8 @@ extern int page_group_by_mobility_disabled;
struct free_area {
struct list_headfree_list[MIGRATE_TYPES];
unsigned long nr_free;
+ u64 rand;
+ u8 rand_bits;
};
/* Used for pages not on another list */
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b4a1598fcab5..e659119351ad 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -746,6 +747,22 @@ static inline int page_is_buddy(struct page *page, struct
page *buddy,
return 0;
}
+static void add_to_free_area_random(struct page *page, struct free_area *area,
+ int migratetype)
+{
+ if (area->rand_bits == 0) {
+ area->rand_bits = 64;
+ area->rand = get_random_u64();
+ }
+
+ if (area->rand & 1)
+ add_to_free_area(page, area, migratetype);
+ else
+ add_to_free_area_tail(page, area, migratetype);
+ area->rand_bits--;
+ area->rand >>= 1;
+}
+
/*
* Freeing function for a buddy system allocator.
*
@@ -851,7 +868,8 @@ static inline void __free_one_page(struct page *page,
* so it's less likely to be used soon and more likely to be merged
* as a higher order page
*/
- if ((order < MAX_ORDER-2) && pfn_valid_within(buddy_pfn)) {
+ if ((order < MAX_ORDER-2) && pfn_valid_within(buddy_pfn)
+ && order < shuffle_page_order) {
struct page *higher_page, *higher_buddy;
combined_pfn = buddy_pfn & pfn;
higher_page = page + (combined_pfn - pfn);
@@ -865,7 +883,12 @@ static inline void __free_one_page(struct page *page,
}
}
- add_to_free_area(page, &zone->free_area[order], migratetype);
+ if (order < shuffle_page_order)
+ add_to_free_area(page, &zone->free_area[order], migratetype);
+ else
+ add_to_free_area_random(page, &zone->free_area[order],
+ migratetype);
+
}
/*
RE: [PATCHv1] RDMA/core: Check error status of rdma_find_ndev_for_src_ip_rcu
Hi Doug, Jason,
> -Original Message-
> From: Parav Pandit
> Sent: Friday, September 21, 2018 10:00 AM
> To: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> l...@kernel.org; j...@ziepe.ca; syzkaller-b...@googlegroups.com; Daniel
> Jurgens ; dledf...@redhat.com
> Cc: Parav Pandit
> Subject: [PATCHv1] RDMA/core: Check error status of
> rdma_find_ndev_for_src_ip_rcu
>
> rdma_find_ndev_for_src_ip_rcu() returns either valid netdev pointer or
> ERR_PTR().
> Instead of checking for NULL, check for error.
>
> Fixes: caf1e3ae9fa6 ("RDMA/core Introduce and use
> rdma_find_ndev_for_src_ip_rcu")
> Reported-by: syzbot+20c32fa6ff84a2d28...@syzkaller.appspotmail.com
> Signed-off-by: Parav Pandit
> ---
> drivers/infiniband/core/addr.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
> index c2ca9e4..3c07eeb 100644
> --- a/drivers/infiniband/core/addr.c
> +++ b/drivers/infiniband/core/addr.c
> @@ -513,8 +513,8 @@ static int rdma_set_src_addr_rcu(struct
> rdma_dev_addr *dev_addr,
>* loopback IP address.
>*/
> ndev = rdma_find_ndev_for_src_ip_rcu(dev_net(ndev),
> dst_in);
> - if (!ndev)
> - return -ENODEV;
> + if (IS_ERR(ndev))
> + return PTR_ERR(ndev);
> }
>
> return copy_src_l2_addr(dev_addr, dst_in, dst, ndev);
> --
> 1.8.3.1
Can you please review this fix?
I got below report from syzbot that it tested the patch and reproducer didn't
trigger.
Report:
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+20c32fa6ff84a2d28...@syzkaller.appspotmail.com
Tested on:
commit: 41ab1cb7d1cd RDMA/cma: Introduce and use cma_ib_acquire_de..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
for-next
kernel config:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fx%2F.config%3Fx%3D112cc1aec8b19ba4&data=02%7C01%7Cparav%40mellanox.com%7Ce0a5662bb6aa4fdee43508d6298c9e60%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636742081267605003&sdata=XiJ9F0gNuDvCWt0m2qzS6SbocXbFXIdWEHe%2BaJuvvcM%3D&reserved=0
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
patch:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fx%2Fpatch.diff%3Fx%3D1055823140&data=02%7C01%7Cparav%40mellanox.com%7Ce0a5662bb6aa4fdee43508d6298c9e60%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636742081267605003&sdata=da0p6AW3YnXmFVrSaR%2FxSrB%2Bj%2Bml%2B5AXx%2B%2FKG4Kjb1M%3D&reserved=0
Note: testing is done by a robot and is best-effort only.
[PATCH v2 1/3] mm: Shuffle initial free memory
Some data exfiltration and return-oriented-programming attacks rely on
the ability to infer the location of sensitive data objects. The kernel
page allocator, especially early in system boot, has predictable
first-in-first out behavior for physical pages. Pages are freed in
physical address order when first onlined.
Introduce shuffle_free_memory(), and its helper shuffle_zone(), to
perform a Fisher-Yates shuffle of the page allocator 'free_area' lists
when they are initially populated with free memory at boot and at
hotplug time.
Quoting Kees:
"While we already have a base-address randomization
(CONFIG_RANDOMIZE_MEMORY), attacks against the same hardware and
memory layouts would certainly be using the predictability of
allocation ordering (i.e. for attacks where the base address isn't
important: only the relative positions between allocated memory).
This is common in lots of heap-style attacks. They try to gain
control over ordering by spraying allocations, etc.
I'd really like to see this because it gives us something similar
to CONFIG_SLAB_FREELIST_RANDOM but for the page allocator."
Another motivation for this change is performance in the presence of a
memory-side cache. In the future, memory-side-cache technology will be
available on generally available server platforms. The proposed
randomization approach has been measured to improve the cache conflict
rate by a factor of 2.5X on a well-known Java benchmark. It avoids
performance peaks and valleys to provide more predictable performance.
While SLAB_FREELIST_RANDOM reduces the predictability of some local slab
caches it leaves vast bulk of memory to be predictably in order
allocated. That ordering can be detected by a memory side-cache.
The shuffling is done in terms of 'shuffle_page_order' sized free pages
where the default shuffle_page_order is MAX_ORDER-1 i.e. 10, 4MB this
trades off randomization granularity for time spent shuffling.
MAX_ORDER-1 was chosen to be minimally invasive to the page allocator
while still showing memory-side cache behavior improvements.
The performance impact of the shuffling appears to be in the noise
compared to other memory initialization work. Also the bulk of the work
is done in the background as a part of deferred_init_memmap().
Cc: Michal Hocko
Cc: Kees Cook
Cc: Dave Hansen
Signed-off-by: Dan Williams
---
include/linux/list.h | 17 +
include/linux/mm.h |5 +
include/linux/mmzone.h |4 +
mm/bootmem.c |9 ++-
mm/memory_hotplug.c|2 +
mm/nobootmem.c |7 ++
mm/page_alloc.c| 172
7 files changed, 211 insertions(+), 5 deletions(-)
diff --git a/include/linux/list.h b/include/linux/list.h
index de04cc5ed536..43f963328d7c 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -150,6 +150,23 @@ static inline void list_replace_init(struct list_head *old,
INIT_LIST_HEAD(old);
}
+/**
+ * list_swap - replace entry1 with entry2 and re-add entry1 at entry2's
position
+ * @entry1: the location to place entry2
+ * @entry2: the location to place entry1
+ */
+static inline void list_swap(struct list_head *entry1,
+struct list_head *entry2)
+{
+ struct list_head *pos = entry2->prev;
+
+ list_del(entry2);
+ list_replace(entry1, entry2);
+ if (pos == entry1)
+ pos = entry2;
+ list_add(entry1, pos);
+}
+
/**
* list_del_init - deletes entry from list and reinitialize it.
* @entry: the element to delete from the list.
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a61ebe8ad4ca..ca1581814fe2 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2040,7 +2040,10 @@ extern void adjust_managed_page_count(struct page *page,
long count);
extern void mem_init_print_info(const char *str);
extern void reserve_bootmem_region(phys_addr_t start, phys_addr_t end);
-
+extern void shuffle_free_memory(pg_data_t *pgdat, unsigned long start_pfn,
+ unsigned long end_pfn);
+extern void shuffle_zone(struct zone *z, unsigned long start_pfn,
+ unsigned long end_pfn);
/* Free the reserved page into the buddy system, so it gets managed. */
static inline void __free_reserved_page(struct page *page)
{
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 1e22d96734e0..8f8fc7dab5cb 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1277,6 +1277,10 @@ void sparse_init(void);
#else
#define sparse_init() do {} while (0)
#define sparse_index_init(_sec, _nid) do {} while (0)
+static inline int pfn_present(unsigned long pfn)
+{
+ return 1;
+}
#endif /* CONFIG_SPARSEMEM */
/*
diff --git a/mm/bootmem.c b/mm/bootmem.c
index 97db0e8e362b..7f5ff899c622 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -210,6 +210,7 @@ void __init free_bootmem_late(unsigned long physaddr,
unsigned long size)
static unsigned long __init
[PATCH v2 2/3] mm: Move buddy list manipulations into helpers
In preparation for runtime randomization of the zone lists, take all
(well, most of) the list_*() functions in the buddy allocator and put
them in helper functions. Provide a common control point for injecting
additional behavior when freeing pages.
Cc: Michal Hocko
Cc: Dave Hansen
Signed-off-by: Dan Williams
---
include/linux/mm.h |3 --
include/linux/mm_types.h |3 ++
include/linux/mmzone.h | 51 ++
mm/compaction.c |4 +--
mm/page_alloc.c | 70 ++
5 files changed, 84 insertions(+), 47 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ca1581814fe2..1d19ec6a2b81 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -473,9 +473,6 @@ static inline void vma_set_anonymous(struct vm_area_struct
*vma)
struct mmu_gather;
struct inode;
-#define page_private(page) ((page)->private)
-#define set_page_private(page, v) ((page)->private = (v))
-
#if !defined(__HAVE_ARCH_PTE_DEVMAP) || !defined(CONFIG_TRANSPARENT_HUGEPAGE)
static inline int pmd_devmap(pmd_t pmd)
{
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index cd2bc939efd0..191610be62bd 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -209,6 +209,9 @@ struct page {
#define PAGE_FRAG_CACHE_MAX_SIZE __ALIGN_MASK(32768, ~PAGE_MASK)
#define PAGE_FRAG_CACHE_MAX_ORDER get_order(PAGE_FRAG_CACHE_MAX_SIZE)
+#define page_private(page) ((page)->private)
+#define set_page_private(page, v) ((page)->private = (v))
+
struct page_frag_cache {
void * va;
#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 8f8fc7dab5cb..adf9b3a7440d 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
/* Free memory management - zoned buddy allocator. */
@@ -98,6 +100,55 @@ struct free_area {
unsigned long nr_free;
};
+/* Used for pages not on another list */
+static inline void add_to_free_area(struct page *page, struct free_area *area,
+int migratetype)
+{
+ list_add(&page->lru, &area->free_list[migratetype]);
+ area->nr_free++;
+}
+
+/* Used for pages not on another list */
+static inline void add_to_free_area_tail(struct page *page, struct free_area
*area,
+ int migratetype)
+{
+ list_add_tail(&page->lru, &area->free_list[migratetype]);
+ area->nr_free++;
+}
+
+/* Used for pages which are on another list */
+static inline void move_to_free_area(struct page *page, struct free_area *area,
+int migratetype)
+{
+ list_move(&page->lru, &area->free_list[migratetype]);
+}
+
+static inline struct page *get_page_from_free_area(struct free_area *area,
+ int migratetype)
+{
+ return list_first_entry_or_null(&area->free_list[migratetype],
+ struct page, lru);
+}
+
+static inline void rmv_page_order(struct page *page)
+{
+ __ClearPageBuddy(page);
+ set_page_private(page, 0);
+}
+
+static inline void del_page_from_free_area(struct page *page,
+ struct free_area *area, int migratetype)
+{
+ list_del(&page->lru);
+ rmv_page_order(page);
+ area->nr_free--;
+}
+
+static inline bool free_area_empty(struct free_area *area, int migratetype)
+{
+ return list_empty(&area->free_list[migratetype]);
+}
+
struct pglist_data;
/*
diff --git a/mm/compaction.c b/mm/compaction.c
index faca45ebe62d..48736044f682 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1358,13 +1358,13 @@ static enum compact_result __compact_finished(struct
zone *zone,
bool can_steal;
/* Job done if page is free of the right migratetype */
- if (!list_empty(&area->free_list[migratetype]))
+ if (!free_area_empty(area, migratetype))
return COMPACT_SUCCESS;
#ifdef CONFIG_CMA
/* MIGRATE_MOVABLE can fallback on MIGRATE_CMA */
if (migratetype == MIGRATE_MOVABLE &&
- !list_empty(&area->free_list[MIGRATE_CMA]))
+ !free_area_empty(area, MIGRATE_CMA))
return COMPACT_SUCCESS;
#endif
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9a1d97655c19..b4a1598fcab5 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -705,12 +705,6 @@ static inline void set_page_order(struct page *page,
unsigned int order)
__SetPageBuddy(page);
}
-static inline void rmv_page_order(struct page *page)
-{
- __ClearPageBuddy(page);
- set_page_private(page, 0);
-}
-
/*
* This function checks whether a page is free && is the buddy
* we can coalesce a page and its
[PATCH v2 0/3] Randomize free memory
Changes since v1: * Add support for shuffling hot-added memory (Andrew) * Update cover letter and commit message to clarify the performance impact and relevance to future platforms [1]: https://lkml.org/lkml/2018/9/15/366 --- Some data exfiltration and return-oriented-programming attacks rely on the ability to infer the location of sensitive data objects. The kernel page allocator, especially early in system boot, has predictable first-in-first out behavior for physical pages. Pages are freed in physical address order when first onlined. Quoting Kees: "While we already have a base-address randomization (CONFIG_RANDOMIZE_MEMORY), attacks against the same hardware and memory layouts would certainly be using the predictability of allocation ordering (i.e. for attacks where the base address isn't important: only the relative positions between allocated memory). This is common in lots of heap-style attacks. They try to gain control over ordering by spraying allocations, etc. I'd really like to see this because it gives us something similar to CONFIG_SLAB_FREELIST_RANDOM but for the page allocator." Another motivation for this change is performance in the presence of a memory-side cache. In the future, memory-side-cache technology will be available on generally available server platforms. The proposed randomization approach has been measured to improve the cache conflict rate by a factor of 2.5X on a well-known Java benchmark. It avoids performance peaks and valleys to provide more predictable performance. More details in the patch1 commit message. --- Dan Williams (3): mm: Shuffle initial free memory mm: Move buddy list manipulations into helpers mm: Maintain randomization of page free lists include/linux/list.h | 17 +++ include/linux/mm.h |8 + include/linux/mm_types.h |3 + include/linux/mmzone.h | 57 ++ mm/bootmem.c |9 +- mm/compaction.c |4 - mm/memory_hotplug.c |2 mm/nobootmem.c |7 + mm/page_alloc.c | 267 +++--- 9 files changed, 321 insertions(+), 53 deletions(-)
[PATCH 2/3 v2] VFS: allow MAY_ flags to be easily extended.
NFSD uses permission flags similar to the MAY_* flags, with some overlap, and depends on the overlap matching. This is currently a little fragile and hard to extend. So add __MAY_UNUSED to identify the first unused flag, and have NFSD use that flag and later flags for its non-standard permissions. Signed-off-by: NeilBrown --- v1 of this patch had an obvious bug which, of course, I couldn't see until after posting. __MAY_UNUSED had the same value as MAY_ACT_AS_OWNER - so it wasn't unused! NeilBrown fs/nfsd/vfs.h | 33 ++--- include/linux/fs.h | 2 ++ 2 files changed, 20 insertions(+), 15 deletions(-) diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h index a7e107309f76..2b1c70d3757a 100644 --- a/fs/nfsd/vfs.h +++ b/fs/nfsd/vfs.h @@ -13,23 +13,26 @@ * Flags for nfsd_permission */ #define NFSD_MAY_NOP 0 -#define NFSD_MAY_EXEC 0x001 /* == MAY_EXEC */ -#define NFSD_MAY_WRITE 0x002 /* == MAY_WRITE */ -#define NFSD_MAY_READ 0x004 /* == MAY_READ */ -#define NFSD_MAY_SATTR 0x008 -#define NFSD_MAY_TRUNC 0x010 -#define NFSD_MAY_LOCK 0x020 -#define NFSD_MAY_MASK 0x03f +#define NFSD_MAY_EXEC MAY_EXEC +#define NFSD_MAY_WRITE MAY_WRITE +#define NFSD_MAY_READ MAY_READ +#define NFSD_MAY_SATTR (__MAY_UNUSED << 0) +#define NFSD_MAY_TRUNC (__MAY_UNUSED << 1) +#define NFSD_MAY_LOCK (__MAY_UNUSED << 2) +#define __NFSD_MAY_FIRST_HINT (__MAY_UNUSED << 3) +#define NFSD_MAY_MASK (__NFSD_MAY_FIRST_HINT - 1) /* extra hints to permission and open routines: */ -#define NFSD_MAY_OWNER_OVERRIDE0x040 -#define NFSD_MAY_LOCAL_ACCESS 0x080 /* for device special files */ -#define NFSD_MAY_BYPASS_GSS_ON_ROOT0x100 -#define NFSD_MAY_NOT_BREAK_LEASE 0x200 -#define NFSD_MAY_BYPASS_GSS0x400 -#define NFSD_MAY_READ_IF_EXEC 0x800 - -#define NFSD_MAY_64BIT_COOKIE 0x1000 /* 64 bit readdir cookies for >= NFSv3 */ +#define NFSD_MAY_OWNER_OVERRIDE(__NFSD_MAY_FIRST_HINT << 0) +/* for device special files */ +#define NFSD_MAY_LOCAL_ACCESS (__NFSD_MAY_FIRST_HINT << 1) +#define NFSD_MAY_BYPASS_GSS_ON_ROOT(__NFSD_MAY_FIRST_HINT << 2) +#define NFSD_MAY_NOT_BREAK_LEASE (__NFSD_MAY_FIRST_HINT << 3) +#define NFSD_MAY_BYPASS_GSS(__NFSD_MAY_FIRST_HINT << 4) +#define NFSD_MAY_READ_IF_EXEC (__NFSD_MAY_FIRST_HINT << 5) + +/* 64 bit readdir cookies for >= NFSv3 */ +#define NFSD_MAY_64BIT_COOKIE (__NFSD_MAY_FIRST_HINT << 6) #define NFSD_MAY_CREATE(NFSD_MAY_EXEC|NFSD_MAY_WRITE) #define NFSD_MAY_REMOVE (NFSD_MAY_EXEC|NFSD_MAY_WRITE|NFSD_MAY_TRUNC) diff --git a/include/linux/fs.h b/include/linux/fs.h index 5a8878a88cbb..9fc914c259f9 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -103,6 +103,8 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset, */ #define MAY_ACT_AS_OWNER 0x0100 +#define__MAY_UNUSED0x0200 + /* * flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond * to O_WRONLY and O_RDWR via the strange trick in do_dentry_open() -- 2.14.0.rc0.dirty signature.asc Description: PGP signature
Re: [PATCH v3 0/7] Remove errors building drivers/DRIVERNAME
On Wed, 3 Oct 2018, Leonardo Bras wrote: > Both ccache and distcc seem very interesting, I will take my time to > study them better as they can solve some situations I face. Thanks for > sharing! > You might also want to check out 'gcc -O0', 'gcc -fopt-info' and 'gcc --help=optimizers' etc to see if you can reduce the compute cost. To reduce IO cost, my build tests always use 'make O=/some/path' where /some/path is on a tmpfs mountpoint. HTH. --
Re: linux-next: occassional build errors
Hi Masahiro,
On Thu, 4 Oct 2018 10:39:37 +1000 Stephen Rothwell
wrote:
>
> On Wed, 3 Oct 2018 16:55:34 +1000 Stephen Rothwell
> wrote:
> >
> > > > The latest example is this:
> > > >
> > > > include/linux/kconfig.h: file not recognized: file format not recognized
> > > > make[2]: *** [scripts/Makefile.build:492: crypto/crypto_user.o] Error 1
> > > > make[1]: *** [Makefile:1057: crypto] Error 2
> > > > make: *** [Makefile:152: sub-make] Error 2
> > > > Command exited with non-zero status 2
> > > >
> > > > It is always complaining about a .h file ...
> > > >
> > > > Makefile:152 is the MAKE lien below:
> > > >
> > > > # Invoke a second make in the output directory, passing relevant
> > > > variables
> > > > sub-make:
> > > > $(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
> > > > -f $(CURDIR)/Makefile $(filter-out _all
> > > > sub-make,$(MAKECMDGOALS))
> > > >
> > > > Makefile:1057 is the MAKE line below:
> > > >
> > > > PHONY += $(vmlinux-dirs)
> > > > $(vmlinux-dirs): prepare scripts
> > > > $(Q)$(MAKE) $(build)=$@ need-builtin=1
> > > >
> > > > scripts/Makefile.build:492 is the if_changed line below:
> > > >
> > > > $(multi-used-m): FORCE
> > > > $(call if_changed,link_multi-m)
> > > > @{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
> > > >$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
> > > > $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
> > > >
> > > > Not sure what else I can tell you.
> > >
> > > Does this happen only when building a module?
> >
> > I don't know, sorry, I build with -s and -j80, so it is hard to tell
> > what it is currently up to.
>
> Today, I got this from the x86_64 allmodconfig build after merging the hid
> tree:
>
> x86_64-linux-gnu-ld: include/config/acpi.h: file not recognized: file
> truncated
> make[4]: *** [/home/sfr/next/next/scripts/Makefile.build:492:
> drivers/hid/i2c-hid/i2c-hid.o] Error 1
> make[3]: *** [/home/sfr/next/next/scripts/Makefile.build:520:
> drivers/hid/i2c-hid] Error 2
> make[2]: *** [/home/sfr/next/next/scripts/Makefile.build:520: drivers/hid]
> Error 2
> make[1]: *** [/home/sfr/next/next/Makefile:1057: drivers] Error 2
> make: *** [Makefile:152: sub-make] Error 2
OK, it seems to have to do with an object changing from a simple build
to a multi object build.
i.e. Tuesday's linux-next has these changes:
obj-$(CONFIG_CRYPTO_USER) += crypto_user.o
+crypto_user-y := crypto_user_base.o crypto_user_stat.o
obj-$(CONFIG_CRYPTO_CMAC) += cmac.o
obj-$(CONFIG_I2C_HID) += i2c-hid.o
+
+i2c-hid-objs = i2c-hid-core.o
+i2c-hid-$(CONFIG_DMI) += i2c-hid-dmi-quirks.o
--
Cheers,
Stephen Rothwell
pgpcVEZ19TOOf.pgp
Description: OpenPGP digital signature
Re: [alsa-devel] [PATCH linux-next v2 9/9] ASoC: rsnd: add busif property to dai stream
Hi Jiada Thank you for your patch > in GEN3 SSI may use different BUSIF for data transfer, > this patch adds busif property to each dai stream, > to indicate the BUSIF used by playback/capture stream. > > Also adds rsnd_ssi_select_busif() to automatically select > BUSIF (currently only BUSIF0 is selected) > > Signed-off-by: Jiada Wang > --- > sound/soc/sh/rcar/core.c | 3 +++ > sound/soc/sh/rcar/dma.c | 31 +++ > sound/soc/sh/rcar/rsnd.h | 3 +++ > sound/soc/sh/rcar/ssi.c | 30 +- > 4 files changed, 66 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c > index 40d7dc4f7839..5e3e6e65bcdf 100644 > --- a/sound/soc/sh/rcar/core.c > +++ b/sound/soc/sh/rcar/core.c > @@ -1158,6 +1158,9 @@ static int rsnd_hw_params(struct snd_pcm_substream > *substream, > struct rsnd_dai *rdai = rsnd_dai_to_rdai(dai); > struct rsnd_dai_stream *io = rsnd_rdai_to_io(rdai, substream); > int ret; > + int chan = rsnd_runtime_channel_for_ssi_with_params(io, hw_params); > + > + rsnd_ssi_select_busif(io, chan); If my understanding was correct, the chance to use BUSIFx is when TDM split mode. And this patch selects it on runtime (= hw_param) ? But, I think we can/should select it on probe timing from DT connection. Am I misunderstanding ? I'm not sure how to select, but adding new ssiuX0 - ssiuX7 is realistic idea (parse sound card is not realistic...) ? If so, your rxu/txu DMA can be more simple ?
Re: [PATCH v3 0/7] Remove errors building drivers/DRIVERNAME
On Wed, Oct 3, 2018 at 8:27 PM Finn Thain wrote: > > On Wed, 3 Oct 2018, Leonardo Bras wrote: > > > > > Sorry, I was not very clear at my reasons why this change is important, > > I will try to briefly explain the whole story. > > > > Some weeks ago I was trying to solve a task that needed to change some > > compiling options, build the whole kernel (allyesconfig) and look for > > errors. The problem was: It would take a long time to build everything > > in my computer. And many friends with slimmer laptops would take much > > longer. > > > > It seems to me that you shouldn't need expensive optimization for > continuous integration. In theory that could make a big difference though > I admit to no experience of build farms. > > Have you looked at ccache? It will save you from having to recompile any > files not changed. > > You could also leverage all of your laptops together using distcc. > > HTH. > > -- Both ccache and distcc seem very interesting, I will take my time to study them better as they can solve some situations I face. Thanks for sharing! Still, I believe my patchset is relevant, as it would enable people to rebuild the whole kernel (with build flags changes, for example) at the cost of only git-pushing the changes to a fork of my Gitlab repo, and waiting 3 hours. Thanks for helping!
[PATCH] staging: rtl8723bs: Remove unnecessary parentheses and dead commented code
Clang warns when multiple pairs of parentheses are used for a single
conditional statement.
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c:3351:20: warning:
equality comparison with extraneous parentheses [-Wparentheses-equality]
The commented code is pointless since _HW_STATE_AP_ is handled right
below this block.
Link: https://github.com/ClangBuiltLinux/linux/issues/168
Signed-off-by: Nathan Chancellor
---
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
index 592917fc00aa..c7e55618b9a8 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
@@ -3348,7 +3348,7 @@ static void hw_var_set_opmode(struct adapter *padapter,
u8 variable, u8 *val)
/* disable atim wnd */
rtw_write8(padapter, REG_BCN_CTRL,
DIS_TSF_UDT|EN_BCN_FUNCTION|DIS_ATIM);
/* rtw_write8(padapter, REG_BCN_CTRL, 0x18); */
- } else if ((mode == _HW_STATE_ADHOC_) /*|| (mode ==
_HW_STATE_AP_)*/) {
+ } else if (mode == _HW_STATE_ADHOC_) {
ResumeTxBeacon(padapter);
rtw_write8(padapter, REG_BCN_CTRL,
DIS_TSF_UDT|EN_BCN_FUNCTION|DIS_BCNQ_SUB);
} else if (mode == _HW_STATE_AP_) {
--
2.19.0
[RESEND PATCH v8 16/16] cpupower: Add Hygon Dhyana support
Tool cpupower is useful to get CPU frequency information and monitor
power stats on Hygon Dhyana platform. So add Hygon Dhyana support to
it by checking vendor and family to share the code path of AMD family
17h.
Signed-off-by: Pu Wen
Acked-by: Shuah Khan (Samsung OSG)
---
tools/power/cpupower/utils/cpufreq-info.c | 6 --
tools/power/cpupower/utils/helpers/amd.c| 4 ++--
tools/power/cpupower/utils/helpers/cpuid.c | 8 +---
tools/power/cpupower/utils/helpers/helpers.h| 2 +-
tools/power/cpupower/utils/helpers/misc.c | 2 +-
tools/power/cpupower/utils/idle_monitor/mperf_monitor.c | 3 ++-
6 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/tools/power/cpupower/utils/cpufreq-info.c
b/tools/power/cpupower/utils/cpufreq-info.c
index df43cd4..56e54ea 100644
--- a/tools/power/cpupower/utils/cpufreq-info.c
+++ b/tools/power/cpupower/utils/cpufreq-info.c
@@ -170,6 +170,7 @@ static int get_boost_mode(unsigned int cpu)
unsigned long pstates[MAX_HW_PSTATES] = {0,};
if (cpupower_cpu_info.vendor != X86_VENDOR_AMD &&
+ cpupower_cpu_info.vendor != X86_VENDOR_HYGON &&
cpupower_cpu_info.vendor != X86_VENDOR_INTEL)
return 0;
@@ -190,8 +191,9 @@ static int get_boost_mode(unsigned int cpu)
printf(_("Supported: %s\n"), support ? _("yes") : _("no"));
printf(_("Active: %s\n"), active ? _("yes") : _("no"));
- if (cpupower_cpu_info.vendor == X86_VENDOR_AMD &&
- cpupower_cpu_info.family >= 0x10) {
+ if ((cpupower_cpu_info.vendor == X86_VENDOR_AMD &&
+cpupower_cpu_info.family >= 0x10) ||
+cpupower_cpu_info.vendor == X86_VENDOR_HYGON) {
ret = decode_pstates(cpu, cpupower_cpu_info.family, b_states,
pstates, &pstate_no);
if (ret)
diff --git a/tools/power/cpupower/utils/helpers/amd.c
b/tools/power/cpupower/utils/helpers/amd.c
index bb41cdd..65beaee 100644
--- a/tools/power/cpupower/utils/helpers/amd.c
+++ b/tools/power/cpupower/utils/helpers/amd.c
@@ -45,7 +45,7 @@ static int get_did(int family, union msr_pstate pstate)
if (family == 0x12)
t = pstate.val & 0xf;
- else if (family == 0x17)
+ else if (family == 0x17 || family == 0x18)
t = pstate.fam17h_bits.did;
else
t = pstate.bits.did;
@@ -59,7 +59,7 @@ static int get_cof(int family, union msr_pstate pstate)
int fid, did, cof;
did = get_did(family, pstate);
- if (family == 0x17) {
+ if (family == 0x17 || family == 0x18) {
fid = pstate.fam17h_bits.fid;
cof = 200 * fid / did;
} else {
diff --git a/tools/power/cpupower/utils/helpers/cpuid.c
b/tools/power/cpupower/utils/helpers/cpuid.c
index 732b0b4..5cc39d4 100644
--- a/tools/power/cpupower/utils/helpers/cpuid.c
+++ b/tools/power/cpupower/utils/helpers/cpuid.c
@@ -8,7 +8,7 @@
#include "helpers/helpers.h"
static const char *cpu_vendor_table[X86_VENDOR_MAX] = {
- "Unknown", "GenuineIntel", "AuthenticAMD",
+ "Unknown", "GenuineIntel", "AuthenticAMD", "HygonGenuine",
};
#if defined(__i386__) || defined(__x86_64__)
@@ -109,6 +109,7 @@ int get_cpu_info(struct cpupower_cpu_info *cpu_info)
fclose(fp);
/* Get some useful CPU capabilities from cpuid */
if (cpu_info->vendor != X86_VENDOR_AMD &&
+ cpu_info->vendor != X86_VENDOR_HYGON &&
cpu_info->vendor != X86_VENDOR_INTEL)
return ret;
@@ -124,8 +125,9 @@ int get_cpu_info(struct cpupower_cpu_info *cpu_info)
if (cpuid_level >= 6 && (cpuid_ecx(6) & 0x1))
cpu_info->caps |= CPUPOWER_CAP_APERF;
- /* AMD Boost state enable/disable register */
- if (cpu_info->vendor == X86_VENDOR_AMD) {
+ /* AMD or Hygon Boost state enable/disable register */
+ if (cpu_info->vendor == X86_VENDOR_AMD ||
+ cpu_info->vendor == X86_VENDOR_HYGON) {
if (ext_cpuid_level >= 0x8007 &&
(cpuid_edx(0x8007) & (1 << 9)))
cpu_info->caps |= CPUPOWER_CAP_AMD_CBP;
diff --git a/tools/power/cpupower/utils/helpers/helpers.h
b/tools/power/cpupower/utils/helpers/helpers.h
index 41da392..9021396 100644
--- a/tools/power/cpupower/utils/helpers/helpers.h
+++ b/tools/power/cpupower/utils/helpers/helpers.h
@@ -61,7 +61,7 @@ extern int be_verbose;
/* cpuid and cpuinfo helpers **/
enum cpupower_cpu_vendor {X86_VENDOR_UNKNOWN = 0, X86_VENDOR_INTEL,
- X86_VENDOR_AMD, X86_VENDOR_MAX};
+ X86_VENDOR_AMD, X86_VENDOR_HYGON, X86_VENDOR_MAX};
#define CPUPOWER_CAP_INV_TSC 0x0001
#define CPUPOWER_CAP_APERF 0x0002
diff --git a/tools/power/cpupower/utils/helpers/misc.c
b/tools/power/cpupower/utils/helpers/misc.c
in
[PATCH] staging: rtlwifi: Remove unnecessary parentheses
Clang warns when multiple pairs of parentheses are used for a single
conditional statement.
drivers/staging/rtlwifi/phydm/phydm_adc_sampling.c:558:33: warning:
equality comparison with extraneous parentheses [-Wparentheses-equality]
} else if ((is_enable_la_mode == 1)) {
~~^~~~
drivers/staging/rtlwifi/phydm/phydm_adc_sampling.c:558:33: note: remove
extraneous parentheses around the comparison to silence this warning
} else if ((is_enable_la_mode == 1)) {
~ ^ ~
drivers/staging/rtlwifi/phydm/phydm_adc_sampling.c:558:33: note: use '='
to turn this equality comparison into an assignment
} else if ((is_enable_la_mode == 1)) {
^~
=
1 warning generated.
Link: https://github.com/ClangBuiltLinux/linux/issues/172
Signed-off-by: Nathan Chancellor
---
drivers/staging/rtlwifi/phydm/phydm_adc_sampling.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtlwifi/phydm/phydm_adc_sampling.c
b/drivers/staging/rtlwifi/phydm/phydm_adc_sampling.c
index 42020101380a..d6cea73fa185 100644
--- a/drivers/staging/rtlwifi/phydm/phydm_adc_sampling.c
+++ b/drivers/staging/rtlwifi/phydm/phydm_adc_sampling.c
@@ -555,7 +555,7 @@ void phydm_lamode_trigger_setting(void *dm_void, char
input[][16], u32 *_used,
output + used, out_len - used,
"{En} {0:BB,1:BB_MAC,2:RF0,3:RF1,4:MAC}\n
{BB:dbg_port[bit],BB_MAC:0-ok/1-fail/2-cca,MAC:ref} {DMA type} {TrigTime}\n
{polling_time/ref_mask} {dbg_port} {0:P_Edge, 1:N_Edge}
{SpRate:0-80M,1-40M,2-20M} {Capture num}\n");
/**/
- } else if ((is_enable_la_mode == 1)) {
+ } else if (is_enable_la_mode == 1) {
PHYDM_SSCANF(input[2], DCMD_DECIMAL, &var1[1]);
trig_mode = (u8)var1[1];
--
2.19.0
Re: [PATCH linux-next v2 8/9] ASoC: rsnd: ssi: Request dedicated dma channels for busif0 to 7
Hi Jiada
Thank you for your patch
> Currently ssi driver only request dma channel for SSI_0,
> which is used to transfer data to/from busif0.
>
> But in GEN3 busif1 to busif7 also maybe used, dedicated dma channels
> are requested for data transfer through these busif.
>
> Signed-off-by: Jiada Wang
> ---
(snip)
> + if (rsnd_ssi_use_busif(io)) {
> + if (is_play)
> + snprintf(name, SSI_DMA_NAME_SIZE, "rxu");
> + else
> + snprintf(name, SSI_DMA_NAME_SIZE, "txu");
> +
> + if (rsnd_is_gen3(priv)) {
> + /*
> + * Gen3 supports to use all available BUSIF
> + */
> + int busif = rsnd_ssi_get_busif(io);
> +
> + snprintf(name, SSI_DMA_NAME_SIZE, "%s%d", name, busif);
> + }
I think unspecified GenX is better idea.
For example, we might want to have same setting on Gen2 in the future.
(and this is not Gen3 HW specific feature
But yes, we have SW side reason)
How about like this ?
We can keep compatibility, and both Gen2/Gen3 can use it.
if (rsnd_ssi_use_busif(io)) {
/*
* 1) try to find txu%d/rxu%d first
* 2) If can't find it, try to find old txu/rxu
*/
}
Re: [ftrace/kprobes PATCH 3/3] tracing/kprobes: Allow kprobe-events to record module symbol
On Wed, 3 Oct 2018 15:12:27 -0400 Steven Rostedt wrote: > On Wed, 29 Aug 2018 01:18:43 +0900 > Masami Hiramatsu wrote: > > > Allow kprobe-events to record module symbols. > > > > Since data symbols in a non-loaded module doesn't exist, it fails to > > define such symbol as an argument of kprobe-event. But if the kprobe > > event is defined on that module, we can defer to resolve the symbol > > address. > > > > Note that if given symbol is not found, the event is kept unavailable. > > User can enable it but the event is not recorded. > > > > > > Hi Masami, > > The first two patches look like they should be applied now and marked > for stable, as they are fixes. This patch looks like an added feature, > and will go into the next merge window. > > Is that what you think too? > Heh, I just realized that this is on my kprobes branch. I was looking at it as if they were in mainline. Nevermind about the "stable" comment ;-) -- Steve
[PATCH 3/3] NFSD - Use MAY_ACT_AS_OWNER
The NFSD_MAY_OWNER_OVERRIDE has exactly the same meaning
as the new MAY_ACT_AS_OWNER flag, so simplify the
code by making use of the identity.
The move NFSD_MAY_OWNER_OVERRIDE into NFSD_MAY_MASK, but that
is not a problem is it is always set together with a flag
that is already in the MASK.
Signed-off-by: NeilBrown
---
fs/nfsd/vfs.c | 11 ++-
fs/nfsd/vfs.h | 14 +++---
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 55a099e47ba2..d89d23e6e2fe 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -2038,12 +2038,13 @@ nfsd_permission(struct svc_rqst *rqstp, struct
svc_export *exp,
* We must trust the client to do permission checking - using "ACCESS"
* with NFSv3.
*/
- if ((acc & NFSD_MAY_OWNER_OVERRIDE) &&
- uid_eq(inode->i_uid, current_fsuid()))
- return 0;
- /* This assumes NFSD_MAY_{READ,WRITE,EXEC} == MAY_{READ,WRITE,EXEC} */
- err = inode_permission(inode, acc & (MAY_READ|MAY_WRITE|MAY_EXEC));
+ /*
+* This works as NFSD_MAY_{READ,WRITE,EXEC} == MAY_{READ,WRITE,EXEC}
+* and NFSD_MAY_OWNER_OVERRIDE == MAY_ACT_AS_OWNER
+*/
+ err = inode_permission(inode, (acc & (MAY_READ|MAY_WRITE|
+ MAY_EXEC|MAY_ACT_AS_OWNER)));
/* Allow read access to binaries even when mode 111 */
if (err == -EACCES && S_ISREG(inode->i_mode) &&
diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h
index 2b1c70d3757a..f6e96dba76a5 100644
--- a/fs/nfsd/vfs.h
+++ b/fs/nfsd/vfs.h
@@ -16,6 +16,7 @@
#define NFSD_MAY_EXEC MAY_EXEC
#define NFSD_MAY_WRITE MAY_WRITE
#define NFSD_MAY_READ MAY_READ
+#define NFSD_MAY_OWNER_OVERRIDEMAY_ACT_AS_OWNER
#define NFSD_MAY_SATTR (__MAY_UNUSED << 0)
#define NFSD_MAY_TRUNC (__MAY_UNUSED << 1)
#define NFSD_MAY_LOCK (__MAY_UNUSED << 2)
@@ -23,16 +24,15 @@
#define NFSD_MAY_MASK (__NFSD_MAY_FIRST_HINT - 1)
/* extra hints to permission and open routines: */
-#define NFSD_MAY_OWNER_OVERRIDE(__NFSD_MAY_FIRST_HINT << 0)
/* for device special files */
-#define NFSD_MAY_LOCAL_ACCESS (__NFSD_MAY_FIRST_HINT << 1)
-#define NFSD_MAY_BYPASS_GSS_ON_ROOT(__NFSD_MAY_FIRST_HINT << 2)
-#define NFSD_MAY_NOT_BREAK_LEASE (__NFSD_MAY_FIRST_HINT << 3)
-#define NFSD_MAY_BYPASS_GSS(__NFSD_MAY_FIRST_HINT << 4)
-#define NFSD_MAY_READ_IF_EXEC (__NFSD_MAY_FIRST_HINT << 5)
+#define NFSD_MAY_LOCAL_ACCESS (__NFSD_MAY_FIRST_HINT << 0)
+#define NFSD_MAY_BYPASS_GSS_ON_ROOT(__NFSD_MAY_FIRST_HINT << 1)
+#define NFSD_MAY_NOT_BREAK_LEASE (__NFSD_MAY_FIRST_HINT << 2)
+#define NFSD_MAY_BYPASS_GSS(__NFSD_MAY_FIRST_HINT << 3)
+#define NFSD_MAY_READ_IF_EXEC (__NFSD_MAY_FIRST_HINT << 4)
/* 64 bit readdir cookies for >= NFSv3 */
-#define NFSD_MAY_64BIT_COOKIE (__NFSD_MAY_FIRST_HINT << 6)
+#define NFSD_MAY_64BIT_COOKIE (__NFSD_MAY_FIRST_HINT << 5)
#define NFSD_MAY_CREATE(NFSD_MAY_EXEC|NFSD_MAY_WRITE)
#define NFSD_MAY_REMOVE
(NFSD_MAY_EXEC|NFSD_MAY_WRITE|NFSD_MAY_TRUNC)
[PATCH 2/3] VFS: allow MAY_ flags to be easily extended.
NFSD uses permission flags similar to the MAY_* flags, with some overlap, and depends on the overlap matching. This is currently a little fragile and hard to extend. So add __MAY_UNUSED to identify the first unused flag, and have NFSD use that flag and later flags for its non-standard permissions. Signed-off-by: NeilBrown --- fs/nfsd/vfs.h | 33 ++--- include/linux/fs.h |2 ++ 2 files changed, 20 insertions(+), 15 deletions(-) diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h index a7e107309f76..2b1c70d3757a 100644 --- a/fs/nfsd/vfs.h +++ b/fs/nfsd/vfs.h @@ -13,23 +13,26 @@ * Flags for nfsd_permission */ #define NFSD_MAY_NOP 0 -#define NFSD_MAY_EXEC 0x001 /* == MAY_EXEC */ -#define NFSD_MAY_WRITE 0x002 /* == MAY_WRITE */ -#define NFSD_MAY_READ 0x004 /* == MAY_READ */ -#define NFSD_MAY_SATTR 0x008 -#define NFSD_MAY_TRUNC 0x010 -#define NFSD_MAY_LOCK 0x020 -#define NFSD_MAY_MASK 0x03f +#define NFSD_MAY_EXEC MAY_EXEC +#define NFSD_MAY_WRITE MAY_WRITE +#define NFSD_MAY_READ MAY_READ +#define NFSD_MAY_SATTR (__MAY_UNUSED << 0) +#define NFSD_MAY_TRUNC (__MAY_UNUSED << 1) +#define NFSD_MAY_LOCK (__MAY_UNUSED << 2) +#define __NFSD_MAY_FIRST_HINT (__MAY_UNUSED << 3) +#define NFSD_MAY_MASK (__NFSD_MAY_FIRST_HINT - 1) /* extra hints to permission and open routines: */ -#define NFSD_MAY_OWNER_OVERRIDE0x040 -#define NFSD_MAY_LOCAL_ACCESS 0x080 /* for device special files */ -#define NFSD_MAY_BYPASS_GSS_ON_ROOT0x100 -#define NFSD_MAY_NOT_BREAK_LEASE 0x200 -#define NFSD_MAY_BYPASS_GSS0x400 -#define NFSD_MAY_READ_IF_EXEC 0x800 - -#define NFSD_MAY_64BIT_COOKIE 0x1000 /* 64 bit readdir cookies for >= NFSv3 */ +#define NFSD_MAY_OWNER_OVERRIDE(__NFSD_MAY_FIRST_HINT << 0) +/* for device special files */ +#define NFSD_MAY_LOCAL_ACCESS (__NFSD_MAY_FIRST_HINT << 1) +#define NFSD_MAY_BYPASS_GSS_ON_ROOT(__NFSD_MAY_FIRST_HINT << 2) +#define NFSD_MAY_NOT_BREAK_LEASE (__NFSD_MAY_FIRST_HINT << 3) +#define NFSD_MAY_BYPASS_GSS(__NFSD_MAY_FIRST_HINT << 4) +#define NFSD_MAY_READ_IF_EXEC (__NFSD_MAY_FIRST_HINT << 5) + +/* 64 bit readdir cookies for >= NFSv3 */ +#define NFSD_MAY_64BIT_COOKIE (__NFSD_MAY_FIRST_HINT << 6) #define NFSD_MAY_CREATE(NFSD_MAY_EXEC|NFSD_MAY_WRITE) #define NFSD_MAY_REMOVE (NFSD_MAY_EXEC|NFSD_MAY_WRITE|NFSD_MAY_TRUNC) diff --git a/include/linux/fs.h b/include/linux/fs.h index 5a8878a88cbb..b0076cb0f738 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -103,6 +103,8 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset, */ #define MAY_ACT_AS_OWNER 0x0100 +#define__MAY_UNUSED0x0100 + /* * flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond * to O_WRONLY and O_RDWR via the strange trick in do_dentry_open()
[GIT PULL] xfs: fixes for 4.19-rc6
Hi Greg, Can you please pull the XFS from the tag listed below. It's a bit bigger than that I'd like this late in the cycle, but we've had a few challenges getting ourselves sorted out this cycle. Details of the contents are in the pull-req output below. This has been be run through xfstests over the past week, and merges against 4.19-rc6 cleanly. FYI, there is likely to be one more XFS fix for this cycle - we've just tracked down the source of a clone_file_range() data corruption so I'll send that as a separate pullreq once Darrick's fix is reviewed and tested. Cheers, Dave. The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux tags/xfs-fixes-for-4.19-rc6 for you to fetch changes up to e55ec4ddbef9897199c307dfb23167e3801fdaf5: xfs: fix error handling in xfs_bmap_extents_to_btree (2018-10-01 08:11:07 +1000) XFS fixes for 4.19-rc6 Accumlated regression and bug fixes for 4.19-rc6, including: o make iomap correctly mark dirty pages for sub-page block sizes o fix regression in handling extent-to-btree format conversion errors o fix torn log wrap detection for new logs o various corrupt inode detection fixes o various delalloc state fixes o cleanup all the missed transaction cancel cases missed from changes merged in 4.19-rc1 o fix lockdep false positive on transaction allocation o fix locking and reference counting on buffer log items Brian Foster (6): xfs: remove last of unnecessary xfs_defer_cancel() callers xfs: don't unlock invalidated buf on aborted tx commit xfs: clean up xfs_trans_brelse() xfs: refactor xfs_buf_log_item reference count handling xfs: remove invalid log recovery first/last cycle check iomap: set page dirty after partial delalloc on mkwrite Christoph Hellwig (2): xfs: don't bring in extents in xfs_bmap_punch_delalloc_range xfs: skip delalloc COW blocks in xfs_reflink_end_cow Darrick J. Wong (1): xfs: don't crash the vfs on a garbage inline symlink Dave Chinner (3): xfs: avoid lockdep false positives in xfs_trans_alloc xfs: fix transaction leak in xfs_reflink_allocate_cow() xfs: fix error handling in xfs_bmap_extents_to_btree Eric Sandeen (2): xfs: don't treat unknown di_flags2 as corruption in scrub xfs: validate inode di_forkoff YueHaibing (1): xfs: remove duplicated include from alloc.c fs/iomap.c | 2 +- fs/xfs/libxfs/xfs_attr.c| 28 +++- fs/xfs/libxfs/xfs_attr_remote.c | 10 +-- fs/xfs/libxfs/xfs_bmap.c| 24 +++ fs/xfs/libxfs/xfs_format.h | 2 + fs/xfs/libxfs/xfs_inode_buf.c | 30 + fs/xfs/scrub/alloc.c| 1 - fs/xfs/scrub/inode.c| 4 +- fs/xfs/xfs_bmap_util.c | 20 ++ fs/xfs/xfs_buf_item.c | 119 ++ fs/xfs/xfs_buf_item.h | 1 + fs/xfs/xfs_inode.c | 10 +-- fs/xfs/xfs_iops.c | 12 +++- fs/xfs/xfs_log_recover.c| 10 --- fs/xfs/xfs_reflink.c| 137 fs/xfs/xfs_trace.h | 1 - fs/xfs/xfs_trans.c | 10 ++- fs/xfs/xfs_trans_buf.c | 99 +++-- 18 files changed, 256 insertions(+), 264 deletions(-) -- Dave Chinner da...@fromorbit.com
[PATCH 0/3] Fix regression in NFSv3 ACL setting
Commit 013cdf1088d7 ("nfs: use generic posix ACL infrastructure for v3
Posix ACLs") introduce a regression for NFSv3 ACL setting.
An owner should be able to set an ACL, but the new code tests for
ownership in a way that is not reliable for NFSv3. For NFSv3 the only
reliable test is to send the request to the server and see if it works.
The first patch introduces MAY_ACT_AS_OWNER and relies on the
filesystem to do the appropriate ownership test. This touches
several filesystems, hence the long 'Cc' list.
Following two patches are small code cleanups relating to this.
Thanks,
NeilBrown
---
NeilBrown (3):
VFS: introduce MAY_ACT_AS_OWNER
VFS: allow MAY_ flags to be easily extended.
NFSD - Use MAY_ACT_AS_OWNER
fs/afs/security.c | 10 ++
fs/attr.c | 12 +---
fs/coda/dir.c | 10 ++
fs/fcntl.c |2 +-
fs/fuse/dir.c | 10 ++
fs/namei.c |9 +
fs/nfs/dir.c |8
fs/nfsd/vfs.c | 11 ++-
fs/nfsd/vfs.h | 33 ++---
fs/posix_acl.c |2 +-
fs/xattr.c |2 +-
include/linux/fs.h | 10 ++
12 files changed, 89 insertions(+), 30 deletions(-)
--
Signature
[PATCH 1/3] VFS: introduce MAY_ACT_AS_OWNER
A few places in VFS, particularly set_posix_acl(), use
inode_owner_or_capable() to check if the caller has "owner"
access to the inode.
This assumes that it is valid to test inode->i_uid, which is not
always the case. Particularly in the case of NFS it is not valid to
us i_uid (or i_mode) for permission tests - the server needs to make
the decision.
As a result if the server is remapping uids
(e.g. all-squash,anon_uid=1000),
then all users should have ownership access, but most users will not
be able to set acls.
This patch moves the ownership test to inode_permission and
i_op->permission.
A new flag for these functions, MAY_ACT_AS_OWNER is introduced.
generic_permission() now handles this correctly and many
i_op->permission functions call this function() and don't need any
changes. A few are changed to handle MAY_ACT_AS_OWNER exactly
as generic_permission() does, using inode_owner_or_capable().
For these filesystems, no behavioural change should be noticed.
For NFS, nfs_permission is changed to always return 0 (success) if
MAY_ACT_AS_OWNER. For NFS, any operations which use this flag should
be sent to the server, and the server will succeed or fail as
appropriate.
Fixes: 013cdf1088d7 ("nfs: use generic posix ACL infrastructure for v3 Posix
ACLs")
Signed-off-by: NeilBrown
---
fs/afs/security.c | 10 ++
fs/attr.c | 12 +---
fs/coda/dir.c | 10 ++
fs/fcntl.c |2 +-
fs/fuse/dir.c | 10 ++
fs/namei.c |9 +
fs/nfs/dir.c |8
fs/posix_acl.c |2 +-
fs/xattr.c |2 +-
include/linux/fs.h |8
10 files changed, 63 insertions(+), 10 deletions(-)
diff --git a/fs/afs/security.c b/fs/afs/security.c
index 81dfedb7879f..ac2e39de8bff 100644
--- a/fs/afs/security.c
+++ b/fs/afs/security.c
@@ -349,6 +349,16 @@ int afs_permission(struct inode *inode, int mask)
if (mask & MAY_NOT_BLOCK)
return -ECHILD;
+ /* Short-circuit for owner */
+ if (mask & MAY_ACT_AS_OWNER) {
+ if (inode_owner_or_capable(inode))
+ return 0;
+ mask &= ~MAY_ACT_AS_OWNER;
+ if (!mask)
+ /* No other permission will suffice */
+ return -EACCES;
+ }
+
_enter("{{%x:%u},%lx},%x,",
vnode->fid.vid, vnode->fid.vnode, vnode->flags, mask);
diff --git a/fs/attr.c b/fs/attr.c
index d22e8187477f..c1160bd9416b 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -87,7 +87,7 @@ int setattr_prepare(struct dentry *dentry, struct iattr *attr)
/* Make sure a caller can chmod. */
if (ia_valid & ATTR_MODE) {
- if (!inode_owner_or_capable(inode))
+ if (inode_permission(inode, MAY_ACT_AS_OWNER) < 0)
return -EPERM;
/* Also check the setgid bit! */
if (!in_group_p((ia_valid & ATTR_GID) ? attr->ia_gid :
@@ -98,7 +98,7 @@ int setattr_prepare(struct dentry *dentry, struct iattr *attr)
/* Check for setting the inode time. */
if (ia_valid & (ATTR_MTIME_SET | ATTR_ATIME_SET | ATTR_TIMES_SET)) {
- if (!inode_owner_or_capable(inode))
+ if (inode_permission(inode, MAY_ACT_AS_OWNER) < 0)
return -EPERM;
}
@@ -246,11 +246,9 @@ int notify_change(struct dentry * dentry, struct iattr *
attr, struct inode **de
if (IS_IMMUTABLE(inode))
return -EPERM;
- if (!inode_owner_or_capable(inode)) {
- error = inode_permission(inode, MAY_WRITE);
- if (error)
- return error;
- }
+ error = inode_permission(inode, MAY_ACT_AS_OWNER | MAY_WRITE);
+ if (error)
+ return error;
}
if ((ia_valid & ATTR_MODE)) {
diff --git a/fs/coda/dir.c b/fs/coda/dir.c
index 00876ddadb43..7e31f68d4973 100644
--- a/fs/coda/dir.c
+++ b/fs/coda/dir.c
@@ -80,6 +80,16 @@ int coda_permission(struct inode *inode, int mask)
if (mask & MAY_NOT_BLOCK)
return -ECHILD;
+ /* Short-circuit for owner */
+ if (mask & MAY_ACT_AS_OWNER) {
+ if (inode_owner_or_capable(inode))
+ return 0;
+ mask &= ~MAY_ACT_AS_OWNER;
+ if (!mask)
+ /* No other permission will suffice */
+ return -EACCES;
+ }
+
mask &= MAY_READ | MAY_WRITE | MAY_EXEC;
if (!mask)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 4137d96534a6..cc1d51150584 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -46,7 +46,7 @@ static int setfl(int fd, struct file * filp, unsigned long
arg)
/* O_NOATIME can only be set by the owner or superuser */
if ((arg & O_NOATIME) && !(filp->f_flags & O_NOATIME))
- if (!in
Re: [PATCH v3 5/7] drivers: s390: Avoids building drivers if ARCH is not s390.
On Mon, Oct 1, 2018 at 9:46 AM Heiko Carstens wrote: > > On Thu, Sep 27, 2018 at 11:08:14PM -0300, Leonardo Brás wrote: > > Avoids building s390 drivers if 'make drivers/s390/' is called but > > ARCH is not s390. > > > > Signed-off-by: Leonardo Brás > > --- > > drivers/s390/Makefile | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/s390/Makefile b/drivers/s390/Makefile > > index a863b0462b43..0575f02dba45 100644 > > --- a/drivers/s390/Makefile > > +++ b/drivers/s390/Makefile > > @@ -3,7 +3,7 @@ > > # Makefile for the S/390 specific device drivers > > # > > > > -obj-y += cio/ block/ char/ crypto/ net/ scsi/ virtio/ > > - > > -drivers-y += drivers/s390/built-in.a > > - > > +ifeq ($(ARCH),s390) > > + obj-y += cio/ block/ char/ crypto/ net/ scsi/ virtio/ > > + drivers-y += drivers/s390/built-in.a > > +endif > > And then somebody wants to build with e.g. "make drivers/s390/cio/" and it > still doesn't work. So _if_ this should be supported then it should work > with all directory levels and all configuration options. Otherwise this is > going to be a never ending story. > It makes sense. I proposed this change to help me solving a problem described here (https://lkml.org/lkml/2018/10/3/707), and for this it was enough if it didn't build when "make drivers/s390/" was called. Sorry I didn't send the e-mail with the reason earlier. For solving my problem it was not necessary, but if you think it's interesting, I could refactor all drivers/s390 Makefiles to make them all build only if we are dealing with the s390 architecture. What do you think? Thanks for the reply, Leonardo Bras
Re: [PATCH linux-next v2 1/9] arm64: r8a7795: add dma request number for busif0 ~ busif7
Hi Jiada
Thank you for your patch
> From: Jiada Wang
>
> This patch adds dma request number for busif0 ~ busif7
> to be used by GEN3 series. GEN2 continues to use rxu/txu
> for busif data transfer.
>
> Signed-off-by: Jiada Wang
> ---
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 164 ---
> 1 file changed, 144 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index b5f2273caca4..fc6100eddfed 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -1923,53 +1923,177 @@
> rcar_sound,ssi {
> ssi0: ssi-0 {
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x01>, <&audma1 0x02>,
> <&audma0 0x15>, <&audma1 0x16>;
> - dma-names = "rx", "tx", "rxu", "txu";
> + dmas = <&audma0 0x01>, <&audma1 0x02>,
> +<&audma0 0x15>, <&audma1 0x16>,
> +<&audma0 0x15>, <&audma1 0x16>,
> +<&audma0 0x35>, <&audma1 0x36>,
> +<&audma0 0x37>, <&audma1 0x38>,
> +<&audma0 0x47>, <&audma1 0x48>,
> +<&audma0 0x3f>, <&audma1 0x40>,
> +<&audma0 0x43>, <&audma1 0x44>,
> +<&audma0 0x4f>, <&audma1 0x50>,
> +<&audma0 0x53>, <&audma1 0x54>;
> + dma-names = "rx", "tx",
> + "rxu", "txu",
> + "rxu0", "txu0",
> + "rxu1", "txu1",
> + "rxu2", "txu2",
> + "rxu3", "txu3",
> + "rxu4", "txu4",
> + "rxu5", "txu5",
> + "rxu6", "txu6",
> + "rxu7", "txu7";
In theory, I think DT side patch should be posted/applied
if driver side patch was accepted.
And, Gen3 side DT doesn't need "rxu/txu" I think.
Re: [PATCH 3/5] rpmsg: Add TIOCMGET/TIOCMSET ioctl support
On Wed 03 Oct 04:34 PDT 2018, Arun Kumar Neelakantam wrote:
> Add TICOMGET and TIOCMSET ioctl support for rpmsg char device nodes
> to get/set the low level transport signals.
>
> Signed-off-by: Arun Kumar Neelakantam
> ---
> drivers/rpmsg/rpmsg_char.c | 54
> +++---
> 1 file changed, 51 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index 86003d5..c983d6c 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -274,15 +275,62 @@ static __poll_t rpmsg_eptdev_poll(struct file *filp,
> poll_table *wait)
> return mask;
> }
>
> +static int rpmsg_eptdev_tiocmset(struct file *fp, unsigned int cmd,
> + unsigned long arg)
Make arg type int __user *
> +{
> + struct rpmsg_eptdev *eptdev = fp->private_data;
> + u32 lsigs, rsigs, val;
> + int ret;
> +
> + ret = get_user(val, (u32 *)arg);
> + if (ret)
> + return ret;
> +
> + ret = rpmsg_get_sigs(eptdev->ept, &lsigs, &rsigs);
> + if (ret < 0)
> + return ret;
> +
> + switch (cmd) {
> + case TIOCMBIS:
> + lsigs |= val;
> + break;
> + case TIOCMBIC:
> + lsigs &= ~val;
> + break;
> + case TIOCMSET:
> + lsigs = val;
> + break;
> + }
> +
> + ret = rpmsg_set_sigs(eptdev->ept, lsigs);
This is racy, as the signals might change while we update them. Mimic
tty_tiocmset() instead and make rpmsg_set_sigs() take a clear and set
mask.
And please do spell out rpmsg_set_signal() and rpmsg_get_signal().
> + return ret;
return rpmsg_set_signals();
> +}
> +
> static long rpmsg_eptdev_ioctl(struct file *fp, unsigned int cmd,
> unsigned long arg)
> {
> struct rpmsg_eptdev *eptdev = fp->private_data;
> + u32 lsigs, rsigs;
> + int ret;
>
> - if (cmd != RPMSG_DESTROY_EPT_IOCTL)
> - return -EINVAL;
> + switch (cmd) {
> + case TIOCMGET:
> + ret = rpmsg_get_sigs(eptdev->ept, &lsigs, &rsigs);
> + if (!ret)
> + ret = put_user(rsigs, (u32 *)arg);
Cast to int __user *
> + break;
> + case TIOCMSET:
> + case TIOCMBIS:
> + case TIOCMBIC:
> + ret = rpmsg_eptdev_tiocmset(fp, cmd, arg);
> + break;
> + case RPMSG_DESTROY_EPT_IOCTL:
> + ret = rpmsg_eptdev_destroy(&eptdev->dev, NULL);
> + default:
> + ret = -EINVAL;
> + }
>
> - return rpmsg_eptdev_destroy(&eptdev->dev, NULL);
> + return ret;
> }
Regards,
Bjorn
[GIT PULL v2] ARM: dts: uniphier: UniPhier DT updates for v4.20
Hi Arnd, Olof, Please pull UniPhier DT updates for the v4.20 MW. This is v2, for which I picked up a little more patches. In this cycle, I queued up all arm/arm64 changes into a single branch to avoid build errors. Thanks! The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git tags/uniphier-dt-v4.20 for you to fetch changes up to 546cba0623df695ac84c10a821cf98fea24b2a18: arm64: dts: uniphier: Add USB2 PHY nodes (2018-10-04 09:41:06 +0900) UniPhier ARM SoC DT updates for v4.20 - Add more clocks to NAND controller nodes - Add SPI controller nodes - Add SD controller nodes - Add USB 3.0 and its PHY nodes - Add PHY nodes for USB 2.0 Kunihiko Hayashi (7): ARM: dts: uniphier: add SPI pin-mux node ARM: dts: uniphier: add SPI node for UniPhier 32bit SoCs arm64: dts: uniphier: add SPI node for LD20, LD11 and PXs3 ARM: dts: uniphier: Add USB3 controller nodes ARM: dts: uniphier: Add USB2 PHY nodes arm64: dts: uniphier: Add USB3 controller nodes arm64: dts: uniphier: Add USB2 PHY nodes Masahiro Yamada (4): ARM: uniphier: dts: add more clocks to Denali NAND controller node arm64: uniphier: dts: add more clocks to Denali NAND controller node ARM: dts: uniphier: add SD/eMMC controller nodes arm64: dts: uniphier: add SD controller nodes arch/arm/boot/dts/uniphier-ld4-ref.dts | 4 + arch/arm/boot/dts/uniphier-ld4.dtsi| 48 +++- arch/arm/boot/dts/uniphier-ld6b-ref.dts| 12 + arch/arm/boot/dts/uniphier-pinctrl.dtsi| 25 ++ arch/arm/boot/dts/uniphier-pro4-ace.dts| 12 + arch/arm/boot/dts/uniphier-pro4-ref.dts| 12 + arch/arm/boot/dts/uniphier-pro4-sanji.dts | 12 + arch/arm/boot/dts/uniphier-pro4.dtsi | 189 ++- arch/arm/boot/dts/uniphier-pro5.dtsi | 59 - arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 12 + arch/arm/boot/dts/uniphier-pxs2-vodka.dts | 8 + arch/arm/boot/dts/uniphier-pxs2.dtsi | 239 ++- arch/arm/boot/dts/uniphier-sld8-ref.dts| 4 + arch/arm/boot/dts/uniphier-sld8.dtsi | 48 +++- arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 52 - arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 4 + arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts| 4 + arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 255 +++- arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts| 12 + arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 283 ++- 20 files changed, 1286 insertions(+), 8 deletions(-) -- Best Regards Masahiro Yamada
Re: [PATCH 1/2] ARM: dts: uniphier: add SD/eMMC controller nodes
On Wed, Oct 3, 2018 at 8:01 AM Masahiro Yamada wrote: > > Add SD controller nodes for LD4, Pro4, sLD8, Pro5, and PXs2. > This is also used as an eMMC controller for LD4, Pro4, and sLD8. > > Signed-off-by: Masahiro Yamada > --- Series, applied. -- Best Regards Masahiro Yamada
Re: [PATCH 1/5] rpmsg: glink: Add GLINK signal support for RPMSG
On Wed 03 Oct 04:34 PDT 2018, Arun Kumar Neelakantam wrote:
> Add support to handle SMD signals to RPMSG over GLINK. SMD signals
> mimic serial protocol signals to notify of ports opening and closing.
> This change affects the rpmsg core, rpmsg char and glink drivers.
>
> Signed-off-by: Chris Lew
> Signed-off-by: Arun Kumar Neelakantam
> ---
> drivers/rpmsg/qcom_glink_native.c | 80
> +++
> drivers/rpmsg/rpmsg_core.c| 41
> drivers/rpmsg/rpmsg_internal.h| 5 +++
> include/linux/rpmsg.h | 25
Please split this patch in one for rpmsg and one for GLINK, and
incorporate the translation from patch 5 in the latter.
> 4 files changed, 151 insertions(+)
>
> diff --git a/drivers/rpmsg/qcom_glink_native.c
> b/drivers/rpmsg/qcom_glink_native.c
[..]
> @@ -954,6 +961,52 @@ static int qcom_glink_rx_open_ack(struct qcom_glink
> *glink, unsigned int lcid)
> return 0;
> }
>
> +/**
> + * qcom_glink_send_signals() - convert a signal cmd to wire format and
> transmit
> + * @glink: The transport to transmit on.
> + * @channel: The glink channel
> + * @sigs:The signals to encode.
> + *
> + * Return: 0 on success or standard Linux error code.
> + */
> +static int qcom_glink_send_signals(struct qcom_glink *glink,
> +struct glink_channel *channel,
> +u32 sigs)
> +{
As this deals with TIOCM_* flags the individual bits are defined as
having "local" or "remote" status. So I believe you should be able to
just pass around one set of bits and extract the ones that makes sense
to send here.
> + struct glink_msg msg;
> +
> + msg.cmd = cpu_to_le16(RPM_CMD_SIGNALS);
> + msg.param1 = cpu_to_le16(channel->lcid);
> + msg.param2 = cpu_to_le32(sigs);
> +
> + return qcom_glink_tx(glink, &msg, sizeof(msg), NULL, 0, true);
> +}
> +
> +static int qcom_glink_handle_signals(struct qcom_glink *glink,
> + unsigned int rcid, unsigned int signals)
> +{
> + struct glink_channel *channel;
> + unsigned long flags;
> + u32 old;
As with send above you should be able to parse out the bits that makes
sense for the remote to set and update the one set of status bits for
the channel here.
> +
> + spin_lock_irqsave(&glink->idr_lock, flags);
> + channel = idr_find(&glink->rcids, rcid);
> + spin_unlock_irqrestore(&glink->idr_lock, flags);
> + if (!channel) {
> + dev_err(glink->dev, "signal for non-existing channel\n");
> + return -EINVAL;
> + }
> +
> + old = channel->rsigs;
> + channel->rsigs = signals;
> +
> + if (channel->ept.sig_cb)
> + channel->ept.sig_cb(channel->ept.rpdev, channel->ept.priv,
> + old, channel->rsigs);
Add {} when block is multiline.
> +
> + return 0;
> +}
[..]
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
[..]
> +/**
> + * rpmsg_get_sigs() - get the signals for this endpoint
> + * @ept: the rpmsg endpoint
> + * @sigs: serial signals bitmask
> + *
> + * Returns 0 on success and an appropriate error value on failure.
> + */
> +int rpmsg_get_sigs(struct rpmsg_endpoint *ept, u32 *lsigs, u32 *rsigs)
> +{
> + if (WARN_ON(!ept))
> + return -EINVAL;
> + if (!ept->ops->get_sigs)
> + return -ENXIO;
I think EOPNOTSUPP would be better here.
> +
> + return ept->ops->get_sigs(ept, lsigs, rsigs);
> +}
> +EXPORT_SYMBOL(rpmsg_get_sigs);
> +
> +/**
> + * rpmsg_set_sigs() - set the remote signals for this endpoint
> + * @ept: the rpmsg endpoint
> + * @sigs: serial signals bitmask
> + *
> + * Returns 0 on success and an appropriate error value on failure.
> + */
> +int rpmsg_set_sigs(struct rpmsg_endpoint *ept, u32 sigs)
> +{
> + if (WARN_ON(!ept))
> + return -EINVAL;
> + if (!ept->ops->set_sigs)
> + return -ENXIO;
Ditto
> +
> + return ept->ops->set_sigs(ept, sigs);
> +}
> +EXPORT_SYMBOL(rpmsg_set_sigs);
> +
Regards,
Bjorn
Re: [PATCH] nfsd: fix fall-through annotations
Thanks, applying.--b. On Tue, Oct 02, 2018 at 12:08:48PM +0200, Gustavo A. R. Silva wrote: > Replace "fallthru" with a proper "fall through" annotation. > > Also, add an annotation were it is expected to fall through. > > These fixes are part of the ongoing efforts to enabling > -Wimplicit-fallthrough > > Signed-off-by: Gustavo A. R. Silva > --- > fs/nfsd/vfs.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c > index d74583f..2751976 100644 > --- a/fs/nfsd/vfs.c > +++ b/fs/nfsd/vfs.c > @@ -1407,6 +1407,7 @@ do_nfsd_create(struct svc_rqst *rqstp, struct svc_fh > *fhp, > *created = 1; > break; > } > + /* fall through */ > case NFS4_CREATE_EXCLUSIVE4_1: > if ( d_inode(dchild)->i_mtime.tv_sec == v_mtime > && d_inode(dchild)->i_atime.tv_sec == v_atime > @@ -1415,7 +1416,7 @@ do_nfsd_create(struct svc_rqst *rqstp, struct svc_fh > *fhp, > *created = 1; > goto set_attr; > } > - /* fallthru */ > + /* fall through */ > case NFS3_CREATE_GUARDED: > err = nfserr_exist; > } > -- > 2.7.4
Re: linux-next: occassional build errors
Hi Masahiro,
On Wed, 3 Oct 2018 16:55:34 +1000 Stephen Rothwell
wrote:
>
> > > The latest example is this:
> > >
> > > include/linux/kconfig.h: file not recognized: file format not recognized
> > > make[2]: *** [scripts/Makefile.build:492: crypto/crypto_user.o] Error 1
> > > make[1]: *** [Makefile:1057: crypto] Error 2
> > > make: *** [Makefile:152: sub-make] Error 2
> > > Command exited with non-zero status 2
> > >
> > > It is always complaining about a .h file ...
> > >
> > > Makefile:152 is the MAKE lien below:
> > >
> > > # Invoke a second make in the output directory, passing relevant variables
> > > sub-make:
> > > $(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
> > > -f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
> > >
> > > Makefile:1057 is the MAKE line below:
> > >
> > > PHONY += $(vmlinux-dirs)
> > > $(vmlinux-dirs): prepare scripts
> > > $(Q)$(MAKE) $(build)=$@ need-builtin=1
> > >
> > > scripts/Makefile.build:492 is the if_changed line below:
> > >
> > > $(multi-used-m): FORCE
> > > $(call if_changed,link_multi-m)
> > > @{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
> > >$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
> > > $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
> > >
> > > Not sure what else I can tell you.
> >
> > Does this happen only when building a module?
>
> I don't know, sorry, I build with -s and -j80, so it is hard to tell
> what it is currently up to.
Today, I got this from the x86_64 allmodconfig build after merging the hid tree:
x86_64-linux-gnu-ld: include/config/acpi.h: file not recognized: file truncated
make[4]: *** [/home/sfr/next/next/scripts/Makefile.build:492:
drivers/hid/i2c-hid/i2c-hid.o] Error 1
make[3]: *** [/home/sfr/next/next/scripts/Makefile.build:520:
drivers/hid/i2c-hid] Error 2
make[2]: *** [/home/sfr/next/next/scripts/Makefile.build:520: drivers/hid]
Error 2
make[1]: *** [/home/sfr/next/next/Makefile:1057: drivers] Error 2
make: *** [Makefile:152: sub-make] Error 2
--
Cheers,
Stephen Rothwell
pgpJlMcwGiYIZ.pgp
Description: OpenPGP digital signature
Re: [PATCH 4/5] rpmsg: wakeup poll to notify signal update
On Wed 03 Oct 04:34 PDT 2018, Arun Kumar Neelakantam wrote:
> Add support to wait on poll to get signal notifications.
> Send POLLPRI mask to indicate the signal change.
>
> Signed-off-by: Arun Kumar Neelakantam
> ---
> drivers/rpmsg/rpmsg_char.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index c983d6c..aee5561 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -64,6 +64,7 @@ struct rpmsg_ctrldev {
> * @queue_lock: synchronization of @queue operations
> * @queue: incoming message queue
> * @readq: wait object for incoming queue
> + * @sig_pending:state of signal notification
> */
> struct rpmsg_eptdev {
> struct device dev;
> @@ -78,6 +79,8 @@ struct rpmsg_eptdev {
> spinlock_t queue_lock;
> struct sk_buff_head queue;
> wait_queue_head_t readq;
> +
> + atomic_t sig_pending;
> };
>
> static int rpmsg_eptdev_destroy(struct device *dev, void *data)
> @@ -125,6 +128,12 @@ static int rpmsg_ept_cb(struct rpmsg_device *rpdev, void
> *buf, int len,
> static int rpmsg_sigs_cb(struct rpmsg_device *rpdev, void *priv,
>u32 old, u32 new)
> {
> + struct rpmsg_eptdev *eptdev = priv;
> +
> + atomic_set(&eptdev->sig_pending, 1);
> +
> + /* wake up any blocking processes, waiting for signal notification */
> + wake_up_interruptible(&eptdev->readq);
This will execute a full memory barrier, so you shouldn't need to use
atomic_t to carry this information.
> return 0;
> }
>
The rest looks good.
Regards,
Bjorn
Re: [PATCH v3 3/7] drivers: parisc: Avoids building driver if CONFIG_PARISC is disabled
On Fri, Sep 28, 2018 at 4:15 AM James Bottomley wrote: > > On Thu, 2018-09-27 at 23:08 -0300, Leonardo Brás wrote: > > Avoids building driver if 'make drivers/parisc/' is called and > > CONFIG_PARISC is disabled. > > Is that really a problem? The drivers/Makefile has this: > > obj-$(CONFIG_PARISC)+= parisc/ > And you just overrode that by forcing the build. It's not even clear > we should refuse the build in that case; how would we know you don't > have a legitimate reason for the override? > Sorry I did not explained my reasons earlier. I sent everybody involved an e-mail explaining the full reason of this change. (For reference it's here: https://lkml.org/lkml/2018/10/3/707) > Signed-off-by: Leonardo Brás > > --- > > drivers/parisc/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/parisc/Makefile b/drivers/parisc/Makefile > > index 3cd5e6cb8478..80049d763aa0 100644 > > --- a/drivers/parisc/Makefile > > +++ b/drivers/parisc/Makefile > > @@ -24,5 +24,5 @@ obj-$(CONFIG_EISA) += eisa.o > > eisa_enumerator.o eisa_eeprom.o > > obj-$(CONFIG_SUPERIO)+= superio.o > > obj-$(CONFIG_CHASSIS_LCD_LED)+= led.o > > obj-$(CONFIG_PDC_STABLE) += pdc_stable.o > > -obj-y+= power.o > > +obj-$(CONFIG_PARISC) += power.o > > If we conclude the use case is legitimate, that's not enough: the two > inner symbols are PARISC only but CONFIG_EISA isn't. You are right. It worked for my needs because I am only building the drivers, and not linking them. But i believe doing something like I did in zorro/Makefile would fix this all. (For reference, https://lkml.org/lkml/2018/9/28/150 ) If you agree, I will send the next patchset with this change. Thanks for your help! Leonardo Bras
Re: [PATCH 2/5] rpmsg: Add signal callback to rpmsg char device
On Wed 03 Oct 04:34 PDT 2018, Arun Kumar Neelakantam wrote:
> Register a callback to get the signal notifications from rpmsg.
>
> Signed-off-by: Arun Kumar Neelakantam
Please incorporate this into patch 4.
Regards,
Bjorn
> ---
> drivers/rpmsg/rpmsg_char.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index a76b963..86003d5 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -5,6 +5,7 @@
> * Copyright (c) 2012, PetaLogix
> * Copyright (c) 2011, Texas Instruments, Inc.
> * Copyright (c) 2011, Google, Inc.
> + * Copyright (c) 2018, The Linux Foundation.
> *
> * Based on rpmsg performance statistics driver by Michal Simek, which in
> turn
> * was based on TI & Google OMX rpmsg driver.
> @@ -120,6 +121,12 @@ static int rpmsg_ept_cb(struct rpmsg_device *rpdev, void
> *buf, int len,
> return 0;
> }
>
> +static int rpmsg_sigs_cb(struct rpmsg_device *rpdev, void *priv,
> + u32 old, u32 new)
> +{
> + return 0;
> +}
> +
> static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
> {
> struct rpmsg_eptdev *eptdev = cdev_to_eptdev(inode->i_cdev);
> @@ -136,6 +143,7 @@ static int rpmsg_eptdev_open(struct inode *inode, struct
> file *filp)
> return -EINVAL;
> }
>
> + ept->sig_cb = rpmsg_sigs_cb;
> eptdev->ept = ept;
> filp->private_data = eptdev;
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
[PATCH v2] arm64: dts: qcom: sdm845: Add UART nodes
This adds nodes for all possible UARTs to sdm845.dtsi. By default
only configure the RX/TX lines with pinctrl. Boards that use UARTs
with flow control can overwrite the configuration in the
.dtsi.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v2:
- use GCC_QUPV3_WRAP1_Sx_CLK for uart8-15, not
GCC_QUPV3_WRAP0_Sx_CLK
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 270 +++
1 file changed, 270 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0c9a2aa6a1b5..c4056c2c3cc5 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -286,6 +286,17 @@
status = "disabled";
};
+ uart0: serial@88 {
+ compatible = "qcom,geni-uart";
+ reg = <0x88 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_uart0_default>;
+ interrupts = ;
+ status = "disabled";
+ };
+
i2c1: i2c@884000 {
compatible = "qcom,geni-i2c";
reg = <0x884000 0x4000>;
@@ -312,6 +323,17 @@
status = "disabled";
};
+ uart1: serial@884000 {
+ compatible = "qcom,geni-uart";
+ reg = <0x884000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_uart1_default>;
+ interrupts = ;
+ status = "disabled";
+ };
+
i2c2: i2c@888000 {
compatible = "qcom,geni-i2c";
reg = <0x888000 0x4000>;
@@ -338,6 +360,17 @@
status = "disabled";
};
+ uart2: serial@888000 {
+ compatible = "qcom,geni-uart";
+ reg = <0x888000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_uart2_default>;
+ interrupts = ;
+ status = "disabled";
+ };
+
i2c3: i2c@88c000 {
compatible = "qcom,geni-i2c";
reg = <0x88c000 0x4000>;
@@ -364,6 +397,17 @@
status = "disabled";
};
+ uart3: serial@88c000 {
+ compatible = "qcom,geni-uart";
+ reg = <0x88c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_uart3_default>;
+ interrupts = ;
+ status = "disabled";
+ };
+
i2c4: i2c@89 {
compatible = "qcom,geni-i2c";
reg = <0x89 0x4000>;
@@ -390,6 +434,17 @@
status = "disabled";
};
+ uart4: serial@89 {
+ compatible = "qcom,geni-uart";
+ reg = <0x89 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_uart4_default>;
+ interrupts = ;
+ status = "disabled";
+ };
+
i2c5: i2c@894000 {
compatible = "qcom,geni-i2c";
reg = <0x894000 0x4000>;
@@ -416,6 +471,17 @@
status = "disabled";
};
+ uart5: serial@894000 {
+ compatible = "qcom,geni-uart";
+ reg = <0x894000 0x4000
[PATCH v5 1/2] dt-bindings: iio: vadc: Update example to include unit address for node 'usb-id-nopull'
The node has a reg property, therefore its name should include a unit
address.
Also change the name from 'usb_id_nopull' to 'usb-id-nopull' to follow
DT conventions.
Signed-off-by: Matthias Kaehlcke
---
Changes in v4:
- patch added to the series
---
Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
index d0c188e5c922..ff7aa5038ba6 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
@@ -112,7 +112,7 @@ Example:
io-channel-ranges;
/* Channel node */
- usb_id_nopull {
+ usb-id-nopull@VADC_LR_MUX10_USB_ID {
reg = ;
qcom,decimation = <512>;
qcom,ratiometric;
--
2.19.0.605.g01d371f741-goog
[PATCH v5 0/2] arm64: dts: qcom: pm8998: Add die temperature channel node to the ADC
This series adds a channel for the die temperature to the QCOM SPMI PMIC5 ADC. It also fixes an example in the DT documentation. The die temperature is going to be used by the temperature alarm driver (https://lore.kernel.org/patchwork/project/lkml/list/?series=361416). The former name of the series was "arm64: dts: qcom: pm8998: Add ADC node and die temperature channel" (https://patchwork.kernel.org/project/linux-arm-msm/list/?series=17165), 2 of the 3 patches of this series already landed in Andy's tree, hence the new name. Matthias Kaehlcke (2): dt-bindings: iio: vadc: Update example to include unit address for node 'usb-id-nopull' arm64: dts: qcom: pm8998: Add die temperature channel node to the ADC Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 2 +- arch/arm64/boot/dts/qcom/pm8998.dtsi | 5 + 2 files changed, 6 insertions(+), 1 deletion(-) -- 2.19.0.605.g01d371f741-goog
[PATCH v5 2/2] arm64: dts: qcom: pm8998: Add die temperature channel node to the ADC
Add a channel node for the die temperature to the ADC.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v4:
- added unit address to 'die-temp' node
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pm8998.dtsi
b/arch/arm64/boot/dts/qcom/pm8998.dtsi
index 048f19fa0150..32b141637d13 100644
--- a/arch/arm64/boot/dts/qcom/pm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8998.dtsi
@@ -75,6 +75,11 @@
#address-cells = <1>;
#size-cells = <0>;
#io-channel-cells = <1>;
+
+ die-temp@ADC5_DIE_TEMP {
+ reg = ;
+ label = "die_temp";
+ };
};
rtc@6000 {
--
2.19.0.605.g01d371f741-goog
Re: [PATCH] rpmsg: glink: smem: Support rx peak for size less than 4 bytes
On Wed 03 Oct 04:38 PDT 2018, Arun Kumar Neelakantam wrote:
> The current rx peak function fails to read the data if size is
> less than 4bytes.
>
> Use memcpy_fromio to support data reads of size less than 4 bytes.
>
> Signed-off-by: Arun Kumar Neelakantam
Applied, with a fixes tag and Cc stable.
Thanks,
Bjorn
> ---
> drivers/rpmsg/qcom_glink_smem.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/rpmsg/qcom_glink_smem.c b/drivers/rpmsg/qcom_glink_smem.c
> index 2b5cf27..7b65443 100644
> --- a/drivers/rpmsg/qcom_glink_smem.c
> +++ b/drivers/rpmsg/qcom_glink_smem.c
> @@ -89,15 +89,11 @@ static void glink_smem_rx_peak(struct qcom_glink_pipe *np,
> tail -= pipe->native.length;
>
> len = min_t(size_t, count, pipe->native.length - tail);
> - if (len) {
> - __ioread32_copy(data, pipe->fifo + tail,
> - len / sizeof(u32));
> - }
> + if (len)
> + memcpy_fromio(data, pipe->fifo + tail, len);
>
> - if (len != count) {
> - __ioread32_copy(data + len, pipe->fifo,
> - (count - len) / sizeof(u32));
> - }
> + if (len != count)
> + memcpy_fromio(data + len, pipe->fifo, (count - len));
> }
>
> static void glink_smem_rx_advance(struct qcom_glink_pipe *np,
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
HALLO FREUND
-- Ich beabsichtige, dir einen Teil meines Reichtums als finanzielle Willenskraft zu geben Spende an Sie, antworten Sie, um teilzunehmen. Wang Jianlin Wanda Gruppe
Re: Sparse warnings from calls to max3() and max
On 10/3/18 5:29 PM, Luc Van Oostenryck wrote: On Tue, Oct 02, 2018 at 06:44:39PM -0500, Larry Finger wrote: Hi, Sparse has suddenly started issuing as many as 11 warnings of "expression using sizeof(void)" for each call to max3(). There are similar warnings for calls to max(), thus I think this is the origin of the problem. My sparse version is 20180324-1.3-x86_64 installed in openSUSE Tumbleweed. My kernel is 4.19.0-rc6. Hi, This problem is resolved in a more recent version of sparse, the one you can find at: git://github.com/lucvoo/sparse-dev See Linus' email about it: https://lore.kernel.org/lkml/ca+55afzyenzr2gzlr-dwponjmnygyody+6awlcvnaywiazu...@mail.gmail.com/T/#u NB. The official version hosted on kernel.org is not uptodate but I hope this will solved in a few weeks. Thanks. I'll ignore those warnings for now. Larry
Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"
I wanted to let you know that I am leaving for a two-week vacation. So if you don't hear from me during that period assume bad network connectivity and not lack of enthusiasm. :) Feel free to go with the backports if we reach an agreement here. Otherwise I'll do it when I get back. Thank you all! smime.p7s Description: S/MIME Cryptographic Signature
hung task in 4.14 (syzbot bug from 2018 April 17)
I think i've run into the bug described here:
https://lkml.org/lkml/2018/4/18/188
I've got a binder-free system that reports a hung task with this backtrace:
[76800.726654] INFO: task systemd:1 blocked for more than 60 seconds.
[76800.726657] Tainted: G OE 4.14.67-solidfire1 #1
[76800.726657] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[76800.726659] systemd D0 1 0 0x
[76800.726662] Call Trace:
[76800.726673] ? __schedule+0x27f/0x870
[76800.726676] schedule+0x28/0x80
[76800.726679] schedule_timeout+0x1e7/0x340
[76800.726685] ? check_preempt_wakeup+0x102/0x230
[76800.726687] ? wait_for_completion+0xb0/0x120
[76800.726689] wait_for_completion+0xb0/0x120
[76800.726693] ? wake_up_q+0x70/0x70
[76800.726698] flush_work+0x10d/0x1c0
[76800.726700] ? worker_detach_from_pool+0xa0/0xa0
[76800.726706] fsnotify_destroy_group+0x34/0xa0
[76800.726708] ? SyS_epoll_ctl+0x1d4/0xe50
[76800.726710] inotify_release+0x1a/0x50
[76800.726714] __fput+0xd8/0x220
[76800.726717] task_work_run+0x8a/0xb0
[76800.726721] exit_to_usermode_loop+0xb9/0xc0
[76800.726723] do_syscall_64+0x10b/0x120
[76800.726727] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[76800.726730] RIP: 0033:0x7fb6957ff900
[76800.726731] RSP: 002b:7ffc685fdd60 EFLAGS: 0293 ORIG_RAX:
0003
[76800.726733] RAX: RBX: 0012 RCX: 7fb6957ff900
[76800.726735] RDX: RSI: RDI: 0012
[76800.726736] RBP: 7fb697167088 R08: 55ae6c9224c0 R09: 55ae6ace92ad
[76800.726737] R10: R11: 0293 R12:
[76800.726738] R13: R14: 00079de4 R15:
[76800.727130] INFO: task kworker/u113:1:29214 blocked for more than 60 seconds.
[76800.727132] Tainted: G OE 4.14.67-solidfire1 #1
[76800.727132] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[76800.727134] kworker/u113:1 D0 29214 2 0x8000
[76800.727139] Workqueue: events_unbound fsnotify_mark_destroy_workfn
[76800.727141] Call Trace:
[76800.727144] ? __schedule+0x27f/0x870
[76800.727146] schedule+0x28/0x80
[76800.727148] schedule_timeout+0x1e7/0x340
[76800.727151] ? __switch_to_asm+0x40/0x70
[76800.727153] ? update_curr+0xe1/0x1a0
[76800.727156] ? wait_for_completion+0xb0/0x120
[76800.727157] wait_for_completion+0xb0/0x120
[76800.727160] ? wake_up_q+0x70/0x70
[76800.727164] __synchronize_srcu.part.13+0x76/0x90
[76800.727167] ? trace_raw_output_rcu_utilization+0x40/0x40
[76800.727169] ? try_to_wake_up+0x44/0x460
[76800.727172] ? fsnotify_mark_destroy_workfn+0x67/0xb0
[76800.727174] fsnotify_mark_destroy_workfn+0x67/0xb0
[76800.727177] process_one_work+0x1da/0x3d0
[76800.727179] worker_thread+0x21f/0x3f0
[76800.727181] ? process_one_work+0x3d0/0x3d0
[76800.727184] kthread+0x119/0x130
[76800.727186] ? kthread_create_on_node+0x40/0x40
[76800.727188] ret_from_fork+0x35/0x40
The kernel is a stock 4.14.67, plus some minor local patches mostly
related to fibre channel, which i believe is not implicated here.
I have a crash dump of this failure, the reaper_work struct has these contents:
crash> print reaper_work
$2 = {
work = {
data = {
counter = -108686497013755
},
entry = {
next = 0x9d2671a395f0,
prev = 0xb2624006fdf8
},
func = 0xb5249df0
},
timer = {
entry = {
next = 0xdead0200,
pprev = 0x0
},
expires = 4302608557,
function = 0xb50778c0,
data = 18446744072468618080,
flags = 195035137
},
wq = 0x9d2680411400,
cpu = 128
}
I'd appreciate help or pointers on how to debug and fix this problem.
--
Sebastian Kuzminsky
Re: [PATCH v3 0/7] Remove errors building drivers/DRIVERNAME
On Wed, 3 Oct 2018, Leonardo Bras wrote: > > Sorry, I was not very clear at my reasons why this change is important, > I will try to briefly explain the whole story. > > Some weeks ago I was trying to solve a task that needed to change some > compiling options, build the whole kernel (allyesconfig) and look for > errors. The problem was: It would take a long time to build everything > in my computer. And many friends with slimmer laptops would take much > longer. > It seems to me that you shouldn't need expensive optimization for continuous integration. In theory that could make a big difference though I admit to no experience of build farms. Have you looked at ccache? It will save you from having to recompile any files not changed. You could also leverage all of your laptops together using distcc. HTH. --
linux-next: Signed-off-by missing for commits in the drm-msm tree
Hi Rob,
Commits
ef02ae3a2f88 ("drm/msm: dpu: Don't reset dpu_enc->cur_master on .disable()")
9875f4b6da02 ("drm/msm/dpu: Revise _dpu_plane_get_aspace")
99e1ced69212 ("drm/msm/dpu: Make dpu_plane_danger_signal_ctrl void")
8fb336bd301e ("drm/msm/dpu: Change _dpu_crtc_vblank_enable_no_lock to void")
0bacddff8ed8 ("drm/msm/dpu: Remove _dpu_crtc_power_enable")
ac8b29aba68f ("drm/msm/dpu: Remove unneeded checks in dpu_crtc.c")
e015a6e97a02 ("drm/msm/dpu: Clean up plane atomic disable/update")
3a6bf2a3dc52 ("drm/msm/dpu: Remove unneeded checks in dpu_plane.c")
9eb37b95bfd6 ("drm/msm: dpu: Don't store/deref pointers in trace ringbuffer")
2626c1cdfa49 ("drm/msm: dpu: Add extra_flush_bits to trigger_flush trace")
f5a342cb8682 ("drm/msm: dpu: Clear frame_busy_mask bit after trace")
8dce281b6126 ("drm/msm: dpu: Don't continue after error in atomic_check")
0dafdcb87483 ("drm/msm: dpu: Make dpu_plane_sspp_atomic_update() void")
659d33c4c63a ("drm/msm: dpu: Remove dpu_plane_enabled()")
9f7583b89d7a ("drm/msm: dpu: Remove dpu_plane_sspp_enabled()")
976a4564ecdb ("drm/msm: dpu: Consolidate atomic_check functions()")
46439c6c78f5 ("drm/msm: dpu: Move atomic_check_plane_state() call to
atomic_check")
b52a9f40d7cf ("drm/msm: dpu: Remove impossible checks")
b34cfea1a6ed ("drm/msm/dpu: Remove an unused enum")
b9c621e8dff1 ("drm/msm/dpu: remove RM topology definition")
82891245fbe2 ("drm/msm/dpu: relax parameter validation in encoders")
fe5f47bad04b ("drm/msm/dpu: remove RM dependency on connector state")
e515ad4369ae ("drm/msm/dpu: remove display H_TILE from encoder")
63090272ac43 ("drm/msm/dpu: remove LOCK/CLEAR support in RM")
c9159537711a ("drm/msm/dpu: remove cdm block support from resource manager")
8b8b91fd3576 ("drm/msm/dpu: clean up destination scaler residue")
f76a527a0a2b ("drm/msm/dpu: rename hw_ctl to lm_ctl")
caf53d6ea3f0 ("drm/msm/dpu: move hw resource tracking to crtc state")
26496d7f55cf ("drm/msm/dpu: make crtc get_mixer_width helper static")
116a0ac329c5 ("drm/msm/dpu: avoid querying for hw intf before assignment")
a87b3b4f0918 ("drm/msm/dpu: iterate for assigned hw ctl in virtual encoder")
efd334265679 ("drm/msm/dpu: use kms stored hw mdp block")
46fc79c15e1f ("drm/msm/dpu: enable master-slave encoders explicitly")
3c0c8c2540cc ("drm/msm/dpu: remove ping pong split topology variables")
d1087d10ca8e ("drm/msm/dpu: remove resource pool manager")
9650e04c19a1 ("drm/msm/dpu: remove scalar config definitions")
1fe0d3a930c6 ("drm/msm/dpu: squash power handle event types")
46f69a1b9533 ("drm/msm/dpu: remove debugfs support for misr")
ab9cd436139b ("drm/msm/dpu: Remove dpu_mdss_isr when dpu_mdss_destroy is
called")
3d80625e00aa ("drm/msm: dpu: Allow planes to extend past active display")
463f3aea2323 ("drm/msm/dpu: use encoder type to identify display type")
774cb941cf3c ("drm/msm/dpu: remove unwanted encoder type mapping")
766b821ebb1b ("drm/msm/dpu: remove stale display port programming")
a1195d221097 ("drm/msm/dpu: fix for cursor blend issue")
ab3e67ffd5cd ("drm/msm/dpu: enable cursor plane on dpu")
32ce4e8c1d94 ("drm/msm/disp/dpu: Use proper define for drm_encoder_init()
'encoder_type'")
450bf8df3d37 ("drm/msm: Don't fail bind if nothing connected to dsi")
8073c1a86310 ("drm/msm: dsi: Return errors whan dt parsing fails")
a0ce66f844ce ("drm/msm: dsi: Initialize msm_dsi->id to -1")
are missing a Signed-off-by from their committer.
(I didn't check all of them by hand, but I did some.)
Presumably caused by rebasing?
--
Cheers,
Stephen Rothwell
pgpM9FyyV0vK5.pgp
Description: OpenPGP digital signature
[PATCH] x86/vdso: Fix vDSO syscall fallback asm constraint regression
When I added the missing memory outputs, I failed to update the
index of the first argument (ebx) on 32-bit builds, which broke the
fallbacks. Somehow I must have screwed up my testing or gotten
lucky.
Add another test to cover gettimeofday() as well.
Cc: sta...@vger.kernel.org
Fixes: 715bd9d12f84 ("x86/vdso: Fix asm constraints on vDSO syscall fallbacks")
Cc: Thomas Gleixner
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/vdso/vclock_gettime.c| 8 +--
tools/testing/selftests/x86/test_vdso.c | 73 +
2 files changed, 77 insertions(+), 4 deletions(-)
diff --git a/arch/x86/entry/vdso/vclock_gettime.c
b/arch/x86/entry/vdso/vclock_gettime.c
index 134e2d2e8add..e48ca3afa091 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -68,11 +68,11 @@ notrace static long vdso_fallback_gettime(long clock,
struct timespec *ts)
asm (
"mov %%ebx, %%edx \n"
- "mov %2, %%ebx \n"
+ "mov %[clock], %%ebx \n"
"call __kernel_vsyscall \n"
"mov %%edx, %%ebx \n"
: "=a" (ret), "=m" (*ts)
- : "0" (__NR_clock_gettime), "g" (clock), "c" (ts)
+ : "0" (__NR_clock_gettime), [clock] "g" (clock), "c" (ts)
: "memory", "edx");
return ret;
}
@@ -83,11 +83,11 @@ notrace static long vdso_fallback_gtod(struct timeval *tv,
struct timezone *tz)
asm (
"mov %%ebx, %%edx \n"
- "mov %2, %%ebx \n"
+ "mov %[tv], %%ebx \n"
"call __kernel_vsyscall \n"
"mov %%edx, %%ebx \n"
: "=a" (ret), "=m" (*tv), "=m" (*tz)
- : "0" (__NR_gettimeofday), "g" (tv), "c" (tz)
+ : "0" (__NR_gettimeofday), [tv] "g" (tv), "c" (tz)
: "memory", "edx");
return ret;
}
diff --git a/tools/testing/selftests/x86/test_vdso.c
b/tools/testing/selftests/x86/test_vdso.c
index 49f7294fb382..35edd61d1663 100644
--- a/tools/testing/selftests/x86/test_vdso.c
+++ b/tools/testing/selftests/x86/test_vdso.c
@@ -36,6 +36,10 @@ typedef int (*vgettime_t)(clockid_t, struct timespec *);
vgettime_t vdso_clock_gettime;
+typedef long (*vgtod_t)(struct timeval *tv, struct timezone *tz);
+
+vgtod_t vdso_gettimeofday;
+
typedef long (*getcpu_t)(unsigned *, unsigned *, void *);
getcpu_t vgetcpu;
@@ -104,6 +108,11 @@ static void fill_function_pointers()
vdso_clock_gettime = (vgettime_t)dlsym(vdso, "__vdso_clock_gettime");
if (!vdso_clock_gettime)
printf("Warning: failed to find clock_gettime in vDSO\n");
+
+ vdso_gettimeofday = (vgtod_t)dlsym(vdso, "__vdso_gettimeofday");
+ if (!vdso_gettimeofday)
+ printf("Warning: failed to find gettimeofday in vDSO\n");
+
}
static long sys_getcpu(unsigned * cpu, unsigned * node,
@@ -117,6 +126,11 @@ static inline int sys_clock_gettime(clockid_t id, struct
timespec *ts)
return syscall(__NR_clock_gettime, id, ts);
}
+static inline int sys_gettimeofday(struct timeval *tv, struct timezone *tz)
+{
+ return syscall(__NR_gettimeofday, tv, tz);
+}
+
static void test_getcpu(void)
{
printf("[RUN]\tTesting getcpu...\n");
@@ -177,6 +191,14 @@ static bool ts_leq(const struct timespec *a, const struct
timespec *b)
return a->tv_nsec <= b->tv_nsec;
}
+static bool tv_leq(const struct timeval *a, const struct timeval *b)
+{
+ if (a->tv_sec != b->tv_sec)
+ return a->tv_sec < b->tv_sec;
+ else
+ return a->tv_usec <= b->tv_usec;
+}
+
static char const * const clocknames[] = {
[0] = "CLOCK_REALTIME",
[1] = "CLOCK_MONOTONIC",
@@ -248,11 +270,62 @@ static void test_clock_gettime(void)
test_one_clock_gettime(INT_MAX, "invalid");
}
+static void test_gettimeofday(void)
+{
+ struct timeval start, vdso, end;
+ struct timezone sys_tz, vdso_tz;
+ int vdso_ret, end_ret;
+
+ if (!vdso_gettimeofday)
+ return;
+
+ printf("[RUN]\tTesting gettimeofday...\n");
+
+ if (sys_gettimeofday(&start, &sys_tz) < 0) {
+ printf("[FAIL]\tsys_gettimeofday failed (%d)\n", errno);
+ nerrs++;
+ return;
+ }
+
+ vdso_ret = vdso_gettimeofday(&vdso, &vdso_tz);
+ end_ret = sys_gettimeofday(&end, NULL);
+
+ if (vdso_ret != 0 || end_ret != 0) {
+ printf("[FAIL]\tvDSO returned %d, syscall errno=%d\n",
+ vdso_ret, errno);
+ nerrs++;
+ return;
+ }
+
+ printf("\t%llu.%06ld %llu.%06ld %llu.%06ld\n",
+ (unsigned long long)start.tv_sec, start.tv_usec,
+ (unsigned long long)vdso.tv_sec, vdso.tv_usec,
+ (unsigned long long)end.tv_sec, end.tv_usec);
+
+ if (!tv_leq(&start, &vdso) || !tv_leq(&vdso, &end)) {
+ printf("[FAIL]\tTimes ar
Re: [PATCH 2/4] mm: introduce put_user_page(), placeholder version
On 10/3/18 9:22 AM, Jan Kara wrote: > On Thu 27-09-18 22:39:48, john.hubb...@gmail.com wrote: >> From: John Hubbard >> >> Introduces put_user_page(), which simply calls put_page(). >> This provides a way to update all get_user_pages*() callers, >> so that they call put_user_page(), instead of put_page(). >> >> Also adds release_user_pages(), a drop-in replacement for >> release_pages(). This is intended to be easily grep-able, >> for later performance improvements, since release_user_pages >> is not batched like release_pages() is, and is significantly >> slower. > > A small nit but can we maybe call this put_user_pages() for symmetry with > put_user_page()? I don't really care too much but it would look natural to > me. > Sure. It started out as "make it a drop-in replacement for release_pages()", but now it's not quite a drop-in replacement anymore. And in any case it's an opportunity to make the name more intuitive, so that seems like a good idea. If anyone hates put_user_pages() and wants to campaign relentlessly for release_pages*(), then now is the time! :) thanks, -- John Hubbard NVIDIA
Re: [PATCH 3/4] infiniband/mm: convert to the new put_user_page() call
On 10/3/18 9:27 AM, Jan Kara wrote:
> On Fri 28-09-18 20:12:33, John Hubbard wrote:
>> static inline void release_user_pages(struct page **pages,
>> - unsigned long npages)
>> + unsigned long npages,
>> + bool set_dirty)
>> {
>> - while (npages)
>> - put_user_page(pages[--npages]);
>> + if (set_dirty)
>> + release_user_pages_dirty(pages, npages);
>> + else
>> + release_user_pages_basic(pages, npages);
>> +}
>
> Is there a good reason to have this with set_dirty argument? Generally bool
> arguments are not great for readability (or greppability for that matter).
> Also in this case callers can just as easily do:
> if (set_dirty)
> release_user_pages_dirty(...);
> else
> release_user_pages(...);
>
> And furthermore it makes the code author think more whether he needs
> set_page_dirty() or set_page_dirty_lock(), rather than just passing 'true'
> and hoping the function magically does the right thing for him.
>
Ha, I went through *precisely* that argument in my head, too--and then
got seduced with the idea that it pretties up the existing calling code,
because it's a drop-in one-liner at the call sites. But yes, I'll change it
back to omit the bool set_dirty argument.
thanks,
--
John Hubbard
NVIDIA
Re: [tip:x86/urgent] x86/vdso: Fix asm constraints on vDSO syscall fallbacks
On Mon, Oct 1, 2018 at 11:30 PM tip-bot for Andy Lutomirski wrote: > > Commit-ID: 715bd9d12f84d8f5cc8ad21d888f9bc304a8eb0b > Gitweb: > https://git.kernel.org/tip/715bd9d12f84d8f5cc8ad21d888f9bc304a8eb0b > Author: Andy Lutomirski > AuthorDate: Mon, 1 Oct 2018 12:52:15 -0700 > Committer: Thomas Gleixner > CommitDate: Tue, 2 Oct 2018 08:28:15 +0200 > > x86/vdso: Fix asm constraints on vDSO syscall fallbacks Ugh, I broke the 32-bit code and failed to test it right. Incremental fix coming.
Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion
On Wed, Oct 3, 2018 at 4:01 PM Jason Gunthorpe wrote: > > On Wed, Oct 03, 2018 at 03:53:58PM -0700, Nick Desaulniers wrote: > > On Wed, Oct 3, 2018 at 3:35 PM Jason Gunthorpe wrote: > > > > > > On Mon, Sep 24, 2018 at 12:57:16PM -0700, Nathan Chancellor wrote: > > > > Clang warns when one enumerated type is implicitly converted to another. > > > > > > > > drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit conversion > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion] > > > > qp_init_attr.init_attr.create_flags = > > > > MLX4_IB_SRIOV_TUNNEL_QP; > > > > ~ > > > > ^~~ > > > > > > > > drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit conversion > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion] > > > > qp_init_attr.init_attr.create_flags = MLX4_IB_SRIOV_SQP; > > > > ~ ^ > > > > > > > > The type mlx4_ib_qp_flags explicitly provides supplemental values to the > > > > type ib_qp_create_flags. Make that clear to Clang by changing the > > > > create_flags type to u32. > > > > > > > > Reported-by: Nick Desaulniers > > > > Signed-off-by: Nathan Chancellor > > > > include/rdma/ib_verbs.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Applied to for-next, thanks > > > > > > BTW, how are you compiling with clang? > > > > https://github.com/ClangBuiltLinux/linux/wiki/Steps-for-compiling-the-kernel-with-Clang > > try it out, let us know bugs you find here: > > https://github.com/ClangBuiltLinux/linux/issues > > Oh I see, you are doing ARM64! Well, it's the first arch I'm focusing on. X86_64 and ARM32 are also a priority. Open source contributors are filing bugs against powerpc, x86, and even risc-v. I'm helping them with code review or putting them in contact with the relevant parties. We're going to talk more about this effort at Linux Plumbers Conference in November if you're going. > > > Still looking into the case you pointed out earlier. I suspect the > > signedness of enums was undefined in c90, then defined as > > implementation specific in c99 (though I'm still researching that > > book report). Thanks for your insights! > > C enums details are a topic that seems more confusing every time it > gets brought up :( > > Jason -- Thanks, ~Nick Desaulniers
Re: [PATCH 4.18 000/228] 4.18.12-stable review
On Wed, Oct 03, 2018 at 02:58:50PM -0500, Dan Rue wrote: > On Tue, Oct 02, 2018 at 06:21:37AM -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.18.12 release. > > There are 228 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Oct 4 13:24:08 UTC 2018. > > Anything received after that time might be too late. > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. Thanks for testing all of these and letting me know. greg k-h
Re: [GIT PULL] parisc fixes for kernel v4.19
On Wed, Oct 03, 2018 at 09:49:08PM +0200, Arnd Bergmann wrote: > On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman > wrote: > > On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote: > > > On 03.10.2018 00:24, Greg Kroah-Hartman wrote: > > > > On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote: > > > >> > > > >> I've tagged it for stable release. > > > >> So, it can go in now, or just wait until -rc1 and go in later. > > > > > > > > Why is a major API change a viable stable change? > > > > > > Of course it's not. > > > Esp. not if an API has been used already. > > > IMHO, this case is really different though... > > > > > > > What bugfix does it provide? > > > > > > It fixes that code in stable kernels which would return wrong > > > time values *if* someone would create a libc for 64-bit parisc > > > and would run it with those "stable" kernels. > > > Fixing it now has no side-effects, the change is a trivial > > > 2-line-removal patch, would bring the code in sync with > > > newer kernel source code, and it really fixes existing code. > > > > > > I still believe that this justifies for a backport. > > > > > > Nevertheless, if you really disagree, I'm fine dropping the > > > backport to stable and will only push it in the next > > > merge window for v4.20. > > > > To clarify, you have no users of this api anywhere (hopefully), and so > > the patch in question prevents anyone from using the api in the future. > > This makes the suseconds_t handling easier for some reason because only > > sparc32 is a "problem" now, right? > > > > So I don't see the "bug" that is being fixed here. I would have pushed > > back on the submission for this for the stable trees as well, this isn't > > anything that anyone is using, so there's nothing to "fix" that I can > > tell. > > > > Yes, doing it in the "future" is fine, to prevent anyone from making > > this mistake (are new machines even being made for this arch?) But I > > don't see how this is a -stable issue. > > The issue here is that glibc has in theory supported 64-bit parisc > user space for a long time, but it has never worked because of the > mismatch. It is very likely that there other problems like it that > /also/ prevent it from working. > > Between changing kernel or glibc, I think it's clear that the glibc > has made the better choice of being compatible with all other > architectures (except sparc64), so changing the kernel is better > here. > > Between fixing it this late, or doing it for the next merge window, > I don't care. There clearly are no users that are affected by it > today, and if there were, this would fix an important bug, both > security (kernel stack information leak) and functionality > (improving accuracy of gettimeofday() from seconds to > microseconds). > > Between backporting it to stable or not, I'd be in favor of the > backport: If we ever want to support 64-bit user space on parisc, > then it's better to have stable kernels get the same working > ABI that new kernels have after the fix (and any other fixes we > may require on top). Or to put it another way: If the argument is > that there won't ever be a 64-bit user space for parisc and we don't > care about it, then we'd be better of removing all native 64-bit > syscalls from arch/parisc/kernel/syscall_table.S. Ok, then let's treat this like any other arch/driver/subsystem that we remove. Drop the file(s) in a -rc1 merge window and then if anyone object to it later on because they really were using it, you can easily revert that change. We do not backport removals of drivers/subsystems/arches to stable kernels, so this shouldn't happen here either. thanks, greg k-h
Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion
On Wed, Oct 03, 2018 at 03:53:58PM -0700, Nick Desaulniers wrote: > On Wed, Oct 3, 2018 at 3:35 PM Jason Gunthorpe wrote: > > > > On Mon, Sep 24, 2018 at 12:57:16PM -0700, Nathan Chancellor wrote: > > > Clang warns when one enumerated type is implicitly converted to another. > > > > > > drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit conversion > > > from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration > > > type 'enum ib_qp_create_flags' [-Wenum-conversion] > > > qp_init_attr.init_attr.create_flags = > > > MLX4_IB_SRIOV_TUNNEL_QP; > > > ~ > > > ^~~ > > > > > > drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit conversion > > > from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration > > > type 'enum ib_qp_create_flags' [-Wenum-conversion] > > > qp_init_attr.init_attr.create_flags = MLX4_IB_SRIOV_SQP; > > > ~ ^ > > > > > > The type mlx4_ib_qp_flags explicitly provides supplemental values to the > > > type ib_qp_create_flags. Make that clear to Clang by changing the > > > create_flags type to u32. > > > > > > Reported-by: Nick Desaulniers > > > Signed-off-by: Nathan Chancellor > > > include/rdma/ib_verbs.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Applied to for-next, thanks > > > > BTW, how are you compiling with clang? > > https://github.com/ClangBuiltLinux/linux/wiki/Steps-for-compiling-the-kernel-with-Clang > try it out, let us know bugs you find here: > https://github.com/ClangBuiltLinux/linux/issues Oh I see, you are doing ARM64! > Still looking into the case you pointed out earlier. I suspect the > signedness of enums was undefined in c90, then defined as > implementation specific in c99 (though I'm still researching that > book report). Thanks for your insights! C enums details are a topic that seems more confusing every time it gets brought up :( Jason
