Re: [PATCH v5 15/15] iio: inv_mpu6050: Use i2c_acpi_get_i2c_resource() helper
+CC linux-iio mostly so I can track it and because others may care.
On Wed, 28 Nov 2018 13:45:35 +0200
Andy Shevchenko wrote:
> ACPI provides a generic helper to get I2C Serial Bus resources.
> Use it instead of open coded variant.
>
> Signed-off-by: Andy Shevchenko
> Reviewed-by: Hans de Goede
Acked-by: Jonathan Cameron
Thanks,
Jonathan
> ---
> drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> index d78a10403bac..a961b5a06fe6 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> @@ -91,18 +91,14 @@ static int asus_acpi_get_sensor_info(struct acpi_device
> *adev,
>
> static int acpi_i2c_check_resource(struct acpi_resource *ares, void *data)
> {
> + struct acpi_resource_i2c_serialbus *sb;
> u32 *addr = data;
>
> - if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
> - struct acpi_resource_i2c_serialbus *sb;
> -
> - sb = >data.i2c_serial_bus;
> - if (sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
> - if (*addr)
> - *addr |= (sb->slave_address << 16);
> - else
> - *addr = sb->slave_address;
> - }
> + if (i2c_acpi_get_i2c_resource(ares, )) {
> + if (*addr)
> + *addr |= (sb->slave_address << 16);
> + else
> + *addr = sb->slave_address;
> }
>
> /* Tell the ACPI core that we already copied this address */
Re: [PATCH v5 15/15] iio: inv_mpu6050: Use i2c_acpi_get_i2c_resource() helper
+CC linux-iio mostly so I can track it and because others may care.
On Wed, 28 Nov 2018 13:45:35 +0200
Andy Shevchenko wrote:
> ACPI provides a generic helper to get I2C Serial Bus resources.
> Use it instead of open coded variant.
>
> Signed-off-by: Andy Shevchenko
> Reviewed-by: Hans de Goede
Acked-by: Jonathan Cameron
Thanks,
Jonathan
> ---
> drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> index d78a10403bac..a961b5a06fe6 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> @@ -91,18 +91,14 @@ static int asus_acpi_get_sensor_info(struct acpi_device
> *adev,
>
> static int acpi_i2c_check_resource(struct acpi_resource *ares, void *data)
> {
> + struct acpi_resource_i2c_serialbus *sb;
> u32 *addr = data;
>
> - if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
> - struct acpi_resource_i2c_serialbus *sb;
> -
> - sb = >data.i2c_serial_bus;
> - if (sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
> - if (*addr)
> - *addr |= (sb->slave_address << 16);
> - else
> - *addr = sb->slave_address;
> - }
> + if (i2c_acpi_get_i2c_resource(ares, )) {
> + if (*addr)
> + *addr |= (sb->slave_address << 16);
> + else
> + *addr = sb->slave_address;
> }
>
> /* Tell the ACPI core that we already copied this address */
Re: [PATCH v5 06/15] platform/x86: intel_cht_int33fe: Get rid of obsolete conditional
On Wed, 28 Nov 2018 13:45:26 +0200
Andy Shevchenko wrote:
> Now, when i2c_acpi_new_device() never returns NULL, there is no point to check
> for it. Besides that, i2c_acpi_new_device() returns -EPROBE_DEFER directly and
> caller doesn't need to guess is better.
>
> Signed-off-by: Andy Shevchenko
Ah, the code I commented on earlier goes away anyway. Not to worry then!
Jonathan
> ---
> drivers/platform/x86/intel_cht_int33fe.c | 24 +---
> 1 file changed, 5 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/platform/x86/intel_cht_int33fe.c
> b/drivers/platform/x86/intel_cht_int33fe.c
> index 367d6e304ade..616b8853a91f 100644
> --- a/drivers/platform/x86/intel_cht_int33fe.c
> +++ b/drivers/platform/x86/intel_cht_int33fe.c
> @@ -169,13 +169,7 @@ static int cht_int33fe_probe(struct platform_device
> *pdev)
> board_info.properties = max17047_props;
> data->max17047 = i2c_acpi_new_device(dev, 1, _info);
> if (IS_ERR(data->max17047))
> - ret = PTR_ERR(data->max17047);
> - else if (!data->max17047)
> - ret = -EPROBE_DEFER; /* Wait for i2c-adapter to load */
> - else
> - ret = 0;
> - if (ret)
> - return ret;
> + return PTR_ERR(data->max17047);
> }
>
> data->connections[0].endpoint[0] = "port0";
> @@ -200,28 +194,20 @@ static int cht_int33fe_probe(struct platform_device
> *pdev)
> board_info.irq = fusb302_irq;
>
> data->fusb302 = i2c_acpi_new_device(dev, 2, _info);
> - if (IS_ERR(data->fusb302))
> + if (IS_ERR(data->fusb302)) {
> ret = PTR_ERR(data->fusb302);
> - else if (!data->fusb302)
> - ret = -EPROBE_DEFER; /* Wait for the i2c-adapter to load */
> - else
> - ret = 0;
> - if (ret)
> goto out_unregister_max17047;
> + }
>
> memset(_info, 0, sizeof(board_info));
> board_info.dev_name = "pi3usb30532";
> strlcpy(board_info.type, "pi3usb30532", I2C_NAME_SIZE);
>
> data->pi3usb30532 = i2c_acpi_new_device(dev, 3, _info);
> - if (IS_ERR(data->pi3usb30532))
> + if (IS_ERR(data->pi3usb30532)) {
> ret = PTR_ERR(data->pi3usb30532);
> - else if (!data->pi3usb30532)
> - ret = -EPROBE_DEFER; /* Wait for the i2c-adapter to load */
> - else
> - ret = 0;
> - if (ret)
> goto out_unregister_fusb302;
> + }
>
> platform_set_drvdata(pdev, data);
>
Re: [PATCH v5 06/15] platform/x86: intel_cht_int33fe: Get rid of obsolete conditional
On Wed, 28 Nov 2018 13:45:26 +0200
Andy Shevchenko wrote:
> Now, when i2c_acpi_new_device() never returns NULL, there is no point to check
> for it. Besides that, i2c_acpi_new_device() returns -EPROBE_DEFER directly and
> caller doesn't need to guess is better.
>
> Signed-off-by: Andy Shevchenko
Ah, the code I commented on earlier goes away anyway. Not to worry then!
Jonathan
> ---
> drivers/platform/x86/intel_cht_int33fe.c | 24 +---
> 1 file changed, 5 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/platform/x86/intel_cht_int33fe.c
> b/drivers/platform/x86/intel_cht_int33fe.c
> index 367d6e304ade..616b8853a91f 100644
> --- a/drivers/platform/x86/intel_cht_int33fe.c
> +++ b/drivers/platform/x86/intel_cht_int33fe.c
> @@ -169,13 +169,7 @@ static int cht_int33fe_probe(struct platform_device
> *pdev)
> board_info.properties = max17047_props;
> data->max17047 = i2c_acpi_new_device(dev, 1, _info);
> if (IS_ERR(data->max17047))
> - ret = PTR_ERR(data->max17047);
> - else if (!data->max17047)
> - ret = -EPROBE_DEFER; /* Wait for i2c-adapter to load */
> - else
> - ret = 0;
> - if (ret)
> - return ret;
> + return PTR_ERR(data->max17047);
> }
>
> data->connections[0].endpoint[0] = "port0";
> @@ -200,28 +194,20 @@ static int cht_int33fe_probe(struct platform_device
> *pdev)
> board_info.irq = fusb302_irq;
>
> data->fusb302 = i2c_acpi_new_device(dev, 2, _info);
> - if (IS_ERR(data->fusb302))
> + if (IS_ERR(data->fusb302)) {
> ret = PTR_ERR(data->fusb302);
> - else if (!data->fusb302)
> - ret = -EPROBE_DEFER; /* Wait for the i2c-adapter to load */
> - else
> - ret = 0;
> - if (ret)
> goto out_unregister_max17047;
> + }
>
> memset(_info, 0, sizeof(board_info));
> board_info.dev_name = "pi3usb30532";
> strlcpy(board_info.type, "pi3usb30532", I2C_NAME_SIZE);
>
> data->pi3usb30532 = i2c_acpi_new_device(dev, 3, _info);
> - if (IS_ERR(data->pi3usb30532))
> + if (IS_ERR(data->pi3usb30532)) {
> ret = PTR_ERR(data->pi3usb30532);
> - else if (!data->pi3usb30532)
> - ret = -EPROBE_DEFER; /* Wait for the i2c-adapter to load */
> - else
> - ret = 0;
> - if (ret)
> goto out_unregister_fusb302;
> + }
>
> platform_set_drvdata(pdev, data);
>
Re: [PATCH 3.18 14/83] ARM: make lookup_processor_type() non-__init
On Sun, Dec 02, 2018 at 05:15:35PM +0100, Greg Kroah-Hartman wrote:
On Sun, Dec 02, 2018 at 10:17:32AM -0500, Sasha Levin wrote:
On Fri, Nov 30, 2018 at 04:18:43PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> > > Hi,
> > >
> > > As I've already fed back to Sascha about this, this patch on its own
> > > does not fix anything, and is not a stable kernel candidate without
> > > a patch that makes use of it (iow, the spectre fixes.) It is a
> > > preparatory patch for mainline commit 383fb3ee8024.
> > >
> > > Every commit in:
> > >
> > > $ git rev-list v4.16..383fb3ee8024
> > >
> > > are the ARM spectre fixes, which are being back-ported by David Long.
> > >
> > > Please do not cherry-pick commits from within this series for _any_
> > > stable kernel, but please wait for David to send you the back-ported
> > > patches.
> >
> > Ugh, ok, that's a bunch here.
>
> Ok, not that bad, only 4:
>383fb3ee8024 ("ARM: spectre-v2: per-CPU vtables to work around big.Little
systems")
>e209950fdd06 ("ARM: add PROC_VTABLE and PROC_TABLE macros")
>945aceb1db88 ("ARM: clean up per-processor check_bugs method call")
>899a42f83667 ("ARM: make lookup_processor_type() non-__init")
>
> I'll go drop them all from the trees now. Turns out for 4.14 one of
> these patches broke the build anyway. Sasha, how did that past your
> builder tests?
Because it builds :)
Really? It broke Guenter's builds...
I might be missing something, but Guenter's reply to this -rc thread
(https://www.spinics.net/lists/stable/msg272294.html) was:
For v3.18.127-83-gc3953c334bf6:
Build results:
total: 160 pass: 160 fail: 0
Qemu test results:
total: 223 pass: 223 fail: 0
--
Thanks,
Sasha
Re: [PATCH 3.18 14/83] ARM: make lookup_processor_type() non-__init
On Sun, Dec 02, 2018 at 05:15:35PM +0100, Greg Kroah-Hartman wrote:
On Sun, Dec 02, 2018 at 10:17:32AM -0500, Sasha Levin wrote:
On Fri, Nov 30, 2018 at 04:18:43PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> > > Hi,
> > >
> > > As I've already fed back to Sascha about this, this patch on its own
> > > does not fix anything, and is not a stable kernel candidate without
> > > a patch that makes use of it (iow, the spectre fixes.) It is a
> > > preparatory patch for mainline commit 383fb3ee8024.
> > >
> > > Every commit in:
> > >
> > > $ git rev-list v4.16..383fb3ee8024
> > >
> > > are the ARM spectre fixes, which are being back-ported by David Long.
> > >
> > > Please do not cherry-pick commits from within this series for _any_
> > > stable kernel, but please wait for David to send you the back-ported
> > > patches.
> >
> > Ugh, ok, that's a bunch here.
>
> Ok, not that bad, only 4:
>383fb3ee8024 ("ARM: spectre-v2: per-CPU vtables to work around big.Little
systems")
>e209950fdd06 ("ARM: add PROC_VTABLE and PROC_TABLE macros")
>945aceb1db88 ("ARM: clean up per-processor check_bugs method call")
>899a42f83667 ("ARM: make lookup_processor_type() non-__init")
>
> I'll go drop them all from the trees now. Turns out for 4.14 one of
> these patches broke the build anyway. Sasha, how did that past your
> builder tests?
Because it builds :)
Really? It broke Guenter's builds...
I might be missing something, but Guenter's reply to this -rc thread
(https://www.spinics.net/lists/stable/msg272294.html) was:
For v3.18.127-83-gc3953c334bf6:
Build results:
total: 160 pass: 160 fail: 0
Qemu test results:
total: 223 pass: 223 fail: 0
--
Thanks,
Sasha
Re: [PATCH 3.18 14/83] ARM: make lookup_processor_type() non-__init
On Sun, Dec 02, 2018 at 10:17:32AM -0500, Sasha Levin wrote:
> On Fri, Nov 30, 2018 at 04:18:43PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> > > > Hi,
> > > >
> > > > As I've already fed back to Sascha about this, this patch on its own
> > > > does not fix anything, and is not a stable kernel candidate without
> > > > a patch that makes use of it (iow, the spectre fixes.) It is a
> > > > preparatory patch for mainline commit 383fb3ee8024.
> > > >
> > > > Every commit in:
> > > >
> > > > $ git rev-list v4.16..383fb3ee8024
> > > >
> > > > are the ARM spectre fixes, which are being back-ported by David Long.
> > > >
> > > > Please do not cherry-pick commits from within this series for _any_
> > > > stable kernel, but please wait for David to send you the back-ported
> > > > patches.
> > >
> > > Ugh, ok, that's a bunch here.
> >
> > Ok, not that bad, only 4:
> > 383fb3ee8024 ("ARM: spectre-v2: per-CPU vtables to work around
> > big.Little systems")
> > e209950fdd06 ("ARM: add PROC_VTABLE and PROC_TABLE macros")
> > 945aceb1db88 ("ARM: clean up per-processor check_bugs method call")
> > 899a42f83667 ("ARM: make lookup_processor_type() non-__init")
> >
> > I'll go drop them all from the trees now. Turns out for 4.14 one of
> > these patches broke the build anyway. Sasha, how did that past your
> > builder tests?
>
> Because it builds :)
Really? It broke Guenter's builds...
Re: [PATCH 3.18 14/83] ARM: make lookup_processor_type() non-__init
On Sun, Dec 02, 2018 at 10:17:32AM -0500, Sasha Levin wrote:
> On Fri, Nov 30, 2018 at 04:18:43PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> > > > Hi,
> > > >
> > > > As I've already fed back to Sascha about this, this patch on its own
> > > > does not fix anything, and is not a stable kernel candidate without
> > > > a patch that makes use of it (iow, the spectre fixes.) It is a
> > > > preparatory patch for mainline commit 383fb3ee8024.
> > > >
> > > > Every commit in:
> > > >
> > > > $ git rev-list v4.16..383fb3ee8024
> > > >
> > > > are the ARM spectre fixes, which are being back-ported by David Long.
> > > >
> > > > Please do not cherry-pick commits from within this series for _any_
> > > > stable kernel, but please wait for David to send you the back-ported
> > > > patches.
> > >
> > > Ugh, ok, that's a bunch here.
> >
> > Ok, not that bad, only 4:
> > 383fb3ee8024 ("ARM: spectre-v2: per-CPU vtables to work around
> > big.Little systems")
> > e209950fdd06 ("ARM: add PROC_VTABLE and PROC_TABLE macros")
> > 945aceb1db88 ("ARM: clean up per-processor check_bugs method call")
> > 899a42f83667 ("ARM: make lookup_processor_type() non-__init")
> >
> > I'll go drop them all from the trees now. Turns out for 4.14 one of
> > these patches broke the build anyway. Sasha, how did that past your
> > builder tests?
>
> Because it builds :)
Really? It broke Guenter's builds...
Re: XFS patches for stable
As someone who has done xfs stable backports for a while I really don't think the autoselection is helpful at all. Someone who is vaguely familiar with the code needs to manually select the commits and QA them, which takes a fair amount of time, but just needs some manual help if it should work ok. I think we are about ready to have a new xfs stable maintainer lined up if everything works well fortunately.
Re: XFS patches for stable
As someone who has done xfs stable backports for a while I really don't think the autoselection is helpful at all. Someone who is vaguely familiar with the code needs to manually select the commits and QA them, which takes a fair amount of time, but just needs some manual help if it should work ok. I think we are about ready to have a new xfs stable maintainer lined up if everything works well fortunately.
Re: [PATCH v5 02/15] platform/x86: intel_cht_int33fe: Accept errors of i2c_acpi_new_device()
On Wed, 28 Nov 2018 13:45:22 +0200 Andy Shevchenko wrote: > In the future i2c_acpi_new_device() will return error pointer in some cases. > Prepare intel_cht_int33fe driver to support that. > > Signed-off-by: Andy Shevchenko > Reviewed-by: Hans de Goede Really trivial comment inline. I haven't checked back to see if there has been any previous discussion on that bit of code. Otherwise looks sensible to me. Jonathan > --- > drivers/platform/x86/intel_cht_int33fe.c | 28 +++- > 1 file changed, 23 insertions(+), 5 deletions(-) > > diff --git a/drivers/platform/x86/intel_cht_int33fe.c > b/drivers/platform/x86/intel_cht_int33fe.c > index 431151d4e611..367d6e304ade 100644 > --- a/drivers/platform/x86/intel_cht_int33fe.c > +++ b/drivers/platform/x86/intel_cht_int33fe.c > @@ -168,8 +168,14 @@ static int cht_int33fe_probe(struct platform_device > *pdev) > board_info.dev_name = "max17047"; > board_info.properties = max17047_props; > data->max17047 = i2c_acpi_new_device(dev, 1, _info); > - if (!data->max17047) > - return -EPROBE_DEFER; /* Wait for i2c-adapter to load */ > + if (IS_ERR(data->max17047)) > + ret = PTR_ERR(data->max17047); Every so slightly nicer to just return directly in these error cases? > + else if (!data->max17047) > + ret = -EPROBE_DEFER; /* Wait for i2c-adapter to load */ > + else > + ret = 0; Particularly so as then you don't need to set this ret as it's set in all paths where it is used below anyway... > + if (ret) > + return ret; > } > > data->connections[0].endpoint[0] = "port0"; > @@ -194,7 +200,13 @@ static int cht_int33fe_probe(struct platform_device > *pdev) > board_info.irq = fusb302_irq; > > data->fusb302 = i2c_acpi_new_device(dev, 2, _info); > - if (!data->fusb302) > + if (IS_ERR(data->fusb302)) > + ret = PTR_ERR(data->fusb302); > + else if (!data->fusb302) > + ret = -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ > + else > + ret = 0; > + if (ret) > goto out_unregister_max17047; > > memset(_info, 0, sizeof(board_info)); > @@ -202,7 +214,13 @@ static int cht_int33fe_probe(struct platform_device > *pdev) > strlcpy(board_info.type, "pi3usb30532", I2C_NAME_SIZE); > > data->pi3usb30532 = i2c_acpi_new_device(dev, 3, _info); > - if (!data->pi3usb30532) > + if (IS_ERR(data->pi3usb30532)) > + ret = PTR_ERR(data->pi3usb30532); > + else if (!data->pi3usb30532) > + ret = -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ > + else > + ret = 0; > + if (ret) > goto out_unregister_fusb302; > > platform_set_drvdata(pdev, data); > @@ -217,7 +235,7 @@ static int cht_int33fe_probe(struct platform_device *pdev) > > device_connections_remove(data->connections); > > - return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ > + return ret; > } > > static int cht_int33fe_remove(struct platform_device *pdev)
Re: [PATCH v5 02/15] platform/x86: intel_cht_int33fe: Accept errors of i2c_acpi_new_device()
On Wed, 28 Nov 2018 13:45:22 +0200 Andy Shevchenko wrote: > In the future i2c_acpi_new_device() will return error pointer in some cases. > Prepare intel_cht_int33fe driver to support that. > > Signed-off-by: Andy Shevchenko > Reviewed-by: Hans de Goede Really trivial comment inline. I haven't checked back to see if there has been any previous discussion on that bit of code. Otherwise looks sensible to me. Jonathan > --- > drivers/platform/x86/intel_cht_int33fe.c | 28 +++- > 1 file changed, 23 insertions(+), 5 deletions(-) > > diff --git a/drivers/platform/x86/intel_cht_int33fe.c > b/drivers/platform/x86/intel_cht_int33fe.c > index 431151d4e611..367d6e304ade 100644 > --- a/drivers/platform/x86/intel_cht_int33fe.c > +++ b/drivers/platform/x86/intel_cht_int33fe.c > @@ -168,8 +168,14 @@ static int cht_int33fe_probe(struct platform_device > *pdev) > board_info.dev_name = "max17047"; > board_info.properties = max17047_props; > data->max17047 = i2c_acpi_new_device(dev, 1, _info); > - if (!data->max17047) > - return -EPROBE_DEFER; /* Wait for i2c-adapter to load */ > + if (IS_ERR(data->max17047)) > + ret = PTR_ERR(data->max17047); Every so slightly nicer to just return directly in these error cases? > + else if (!data->max17047) > + ret = -EPROBE_DEFER; /* Wait for i2c-adapter to load */ > + else > + ret = 0; Particularly so as then you don't need to set this ret as it's set in all paths where it is used below anyway... > + if (ret) > + return ret; > } > > data->connections[0].endpoint[0] = "port0"; > @@ -194,7 +200,13 @@ static int cht_int33fe_probe(struct platform_device > *pdev) > board_info.irq = fusb302_irq; > > data->fusb302 = i2c_acpi_new_device(dev, 2, _info); > - if (!data->fusb302) > + if (IS_ERR(data->fusb302)) > + ret = PTR_ERR(data->fusb302); > + else if (!data->fusb302) > + ret = -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ > + else > + ret = 0; > + if (ret) > goto out_unregister_max17047; > > memset(_info, 0, sizeof(board_info)); > @@ -202,7 +214,13 @@ static int cht_int33fe_probe(struct platform_device > *pdev) > strlcpy(board_info.type, "pi3usb30532", I2C_NAME_SIZE); > > data->pi3usb30532 = i2c_acpi_new_device(dev, 3, _info); > - if (!data->pi3usb30532) > + if (IS_ERR(data->pi3usb30532)) > + ret = PTR_ERR(data->pi3usb30532); > + else if (!data->pi3usb30532) > + ret = -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ > + else > + ret = 0; > + if (ret) > goto out_unregister_fusb302; > > platform_set_drvdata(pdev, data); > @@ -217,7 +235,7 @@ static int cht_int33fe_probe(struct platform_device *pdev) > > device_connections_remove(data->connections); > > - return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ > + return ret; > } > > static int cht_int33fe_remove(struct platform_device *pdev)
Re: [PATCH] ARM: mmp/mmp2: fix cpu_is_mmp2() on mmp2-dt
On Sun, Dec 2, 2018 at 12:12 PM Lubomir Rintel wrote: > > cpu_is_mmp2() was equivalent to cpu_is_pj4(), wouldn't be correct for > multiplatform kernels. Fix it by also considering mmp_chip_id, as is > done for cpu_is_pxa168() and cpu_is_pxa910() above. > > Moreover, it is only available with CONFIG_CPU_MMP2 and thus doesn't work > on DT-based MMP2 machines. Enable it on CONFIG_MACH_MMP2_DT too. > > Note: CONFIG_CPU_MMP2 is only used for machines that use board files > instead of DT. It should perhaps be renamed. I'm not doing it now, because > I don't have a better idea. > > Signed-off-by: Lubomir Rintel Acked-by: Arnd Bergmann I'd suggest adding Cc: sta...@vger.kernel.org since this fixes bugs on other platforms when CONFIG_MMP2 is enabled in a multiplatform kernel.
Re: [PATCH] ARM: mmp/mmp2: fix cpu_is_mmp2() on mmp2-dt
On Sun, Dec 2, 2018 at 12:12 PM Lubomir Rintel wrote: > > cpu_is_mmp2() was equivalent to cpu_is_pj4(), wouldn't be correct for > multiplatform kernels. Fix it by also considering mmp_chip_id, as is > done for cpu_is_pxa168() and cpu_is_pxa910() above. > > Moreover, it is only available with CONFIG_CPU_MMP2 and thus doesn't work > on DT-based MMP2 machines. Enable it on CONFIG_MACH_MMP2_DT too. > > Note: CONFIG_CPU_MMP2 is only used for machines that use board files > instead of DT. It should perhaps be renamed. I'm not doing it now, because > I don't have a better idea. > > Signed-off-by: Lubomir Rintel Acked-by: Arnd Bergmann I'd suggest adding Cc: sta...@vger.kernel.org since this fixes bugs on other platforms when CONFIG_MMP2 is enabled in a multiplatform kernel.
Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
On Sun, Dec 02, 2018 at 08:47:03AM +, Dexuan Cui wrote: > Hi Greg, > Please use the attached patch: I rebased the patch to today's char-misc's > char-misc-linus branch. It can also cleanly apply to Linus's master branch > today. I can't use an attached patch, you know better. Please fix up and resend properly. greg k-h
Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
On Sun, Dec 02, 2018 at 08:47:03AM +, Dexuan Cui wrote: > Hi Greg, > Please use the attached patch: I rebased the patch to today's char-misc's > char-misc-linus branch. It can also cleanly apply to Linus's master branch > today. I can't use an attached patch, you know better. Please fix up and resend properly. greg k-h
Re: [PATCH] ubi: fastmap: Check each mapping only once
On Sun, Dec 02, 2018 at 04:02:47PM +0100, Richard Weinberger wrote: Sasha, Am Sonntag, 2. Dezember 2018, 15:35:43 CET schrieb Sasha Levin: On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote: >> > Now queued up for 4.14.y, thanks. >> >> can you *please* slow a little down? > >True. It will really help if you can have some sort of fixed schedule >for stable release, like maybe stablerc is ready on Thursday or Friday >and release the stable on Monday. Having a weekend in stablerc will be >helpful for people like me who only get the time in weekends for >upstream or stable kernel. Any sort of schedule will never work for everyone (for example, if it's part of your paid job - you don't necessarily want to review stuff over the weekend). a schedule is not needed, but please give maintainers at least a chance to react on stable inclusion request. In this case Martin asked for inclusion on Monday and the patch was applied two days later. As you noted not everyone works full time on the kernel and gets paid for that. So it might take a few days to react and review such a request. Yes, that's fair, I wasn't arguing against that. -- Thanks, Sasha
Re: [PATCH] ubi: fastmap: Check each mapping only once
On Sun, Dec 02, 2018 at 04:02:47PM +0100, Richard Weinberger wrote: Sasha, Am Sonntag, 2. Dezember 2018, 15:35:43 CET schrieb Sasha Levin: On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote: >> > Now queued up for 4.14.y, thanks. >> >> can you *please* slow a little down? > >True. It will really help if you can have some sort of fixed schedule >for stable release, like maybe stablerc is ready on Thursday or Friday >and release the stable on Monday. Having a weekend in stablerc will be >helpful for people like me who only get the time in weekends for >upstream or stable kernel. Any sort of schedule will never work for everyone (for example, if it's part of your paid job - you don't necessarily want to review stuff over the weekend). a schedule is not needed, but please give maintainers at least a chance to react on stable inclusion request. In this case Martin asked for inclusion on Monday and the patch was applied two days later. As you noted not everyone works full time on the kernel and gets paid for that. So it might take a few days to react and review such a request. Yes, that's fair, I wasn't arguing against that. -- Thanks, Sasha
Re: XFS patches for stable
On Sat, Dec 01, 2018 at 11:09:05AM +0200, Amir Goldstein wrote:
>> It's getting to the point that with the amount of known issues with XFS
>> on LTS kernels it makes sense to mark it as CONFIG_BROKEN.
>
>Really? Where are the bug reports?
In 'git log'! You report these every time you fix something in upstream
xfs but don't backport it to stable trees:
$ git log --oneline v4.18-rc1..v4.18 fs/xfs
d4a34e165557 xfs: properly handle free inodes in extent hint validators
9991274fddb9 xfs: Initialize variables in xfs_alloc_get_rec before using them
d8cb5e423789 xfs: fix fdblocks accounting w/ RMAPBT per-AG reservation
e53c4b598372 xfs: ensure post-EOF zeroing happens after zeroing part of a file
a3a374bf1889 xfs: fix off-by-one error in xfs_rtalloc_query_range
232d0a24b0fc xfs: fix uninitialized field in rtbitmap fsmap backend
5bd88d153998 xfs: recheck reflink state after grabbing ILOCK_SHARED for a write
f62cb48e4319 xfs: don't allow insert-range to shift extents past the maximum
offset
aafe12cee0b1 xfs: don't trip over negative free space in xfs_reserve_blocks
10ee25268e1f xfs: allow empty transactions while frozen
e53946dbd31a xfs: xfs_iflush_abort() can be called twice on cluster writeback
failure
23fcb3340d03 xfs: More robust inode extent count validation
e2ac836307e3 xfs: simplify xfs_bmap_punch_delalloc_range
Since I'm assuming that at least some of them are based on actual issues
users hit, and some of those apply to stable kernels, why would users
want to use an XFS version which is knowingly buggy?
Sasha,
There is one more point to consider.
Until v4.16, reflink and rmapbt features were experimental:
76883f7988e6 xfs: remove experimental tag for reverse mapping
1e369b0e199b xfs: remove experimental tag for reflinks
And MANY of the bug fixes flowing in through XFS tree to master
are related to those new XFS features and also to vfs functionality
that depends on them (e.g. clone/dedupe), so there MAY be no
bug reports at all for XFS in stable trees.
IMO users should NOT be expecting XFS to be stable with those
features enabled (they are still disabled by default)
when running on stable kernels below v4.16.
Allow me to act as a self-appointed mediator here and say:
There is obviously some bad blood between xfs developers and stable
tree maintainers.
The conflicts are caused by long standing frustration on both sides.
We would all be better off with looking forward on how to improve the
situation instead dwelling on past mistakes.
This issue was on the agenda at the XFS team meeting on last LSF/MM.
The path towards compliance has been laid out by xfs maintainers.
Luis, Sasha and myself have been working to improve the filesystem
test coverage for stable tree candidate patches.
We have still some way to go.
The stable candidate patches that triggered the recent flames
was outside of the fs/xfs subsystem, which AUTOSEL already know
to stay away from, so nobody had any intention to stir things up.
At the end of the day, most xfs developers work for companies that
ship enterprise distros and need to maintain stable trees, so I would
hope that it is in the best interest of everyone involved to cooperate
on the goal of better stable-xfs ecosystem.
On my part, I would be happy if AUTOSEL could point me at
candidate patch *series* for review instead of single patches.
I'm afraid it's not smart enough to do that :(
I can grab an entire series if it selects a single patch in a series,
but from my experience it's usually the wrong thing to do.
For that matter, it sure wouldn't hurt if an xfs developer sending
out a patch series would cc:stable on the cover letter and if a developer
would be kind enough to add some backporting hints to the cover letter
text that would be very helpful indeed.
Given that we have folks (Luis, Amir, etc) working on it already, maybe
a step in the right direction would be having the XFS folks tag fixes
some other way ("#wants-a-backport"?) where this would give a hint that
this should be backported after sufficient testing?
We won't pick these commits to stable ourselves, but only after the XFS
maintainers are satisfied that the commit was sufficiently tested on LTS
trees?
--
Thanks,
Sasha
Re: XFS patches for stable
On Sat, Dec 01, 2018 at 11:09:05AM +0200, Amir Goldstein wrote:
>> It's getting to the point that with the amount of known issues with XFS
>> on LTS kernels it makes sense to mark it as CONFIG_BROKEN.
>
>Really? Where are the bug reports?
In 'git log'! You report these every time you fix something in upstream
xfs but don't backport it to stable trees:
$ git log --oneline v4.18-rc1..v4.18 fs/xfs
d4a34e165557 xfs: properly handle free inodes in extent hint validators
9991274fddb9 xfs: Initialize variables in xfs_alloc_get_rec before using them
d8cb5e423789 xfs: fix fdblocks accounting w/ RMAPBT per-AG reservation
e53c4b598372 xfs: ensure post-EOF zeroing happens after zeroing part of a file
a3a374bf1889 xfs: fix off-by-one error in xfs_rtalloc_query_range
232d0a24b0fc xfs: fix uninitialized field in rtbitmap fsmap backend
5bd88d153998 xfs: recheck reflink state after grabbing ILOCK_SHARED for a write
f62cb48e4319 xfs: don't allow insert-range to shift extents past the maximum
offset
aafe12cee0b1 xfs: don't trip over negative free space in xfs_reserve_blocks
10ee25268e1f xfs: allow empty transactions while frozen
e53946dbd31a xfs: xfs_iflush_abort() can be called twice on cluster writeback
failure
23fcb3340d03 xfs: More robust inode extent count validation
e2ac836307e3 xfs: simplify xfs_bmap_punch_delalloc_range
Since I'm assuming that at least some of them are based on actual issues
users hit, and some of those apply to stable kernels, why would users
want to use an XFS version which is knowingly buggy?
Sasha,
There is one more point to consider.
Until v4.16, reflink and rmapbt features were experimental:
76883f7988e6 xfs: remove experimental tag for reverse mapping
1e369b0e199b xfs: remove experimental tag for reflinks
And MANY of the bug fixes flowing in through XFS tree to master
are related to those new XFS features and also to vfs functionality
that depends on them (e.g. clone/dedupe), so there MAY be no
bug reports at all for XFS in stable trees.
IMO users should NOT be expecting XFS to be stable with those
features enabled (they are still disabled by default)
when running on stable kernels below v4.16.
Allow me to act as a self-appointed mediator here and say:
There is obviously some bad blood between xfs developers and stable
tree maintainers.
The conflicts are caused by long standing frustration on both sides.
We would all be better off with looking forward on how to improve the
situation instead dwelling on past mistakes.
This issue was on the agenda at the XFS team meeting on last LSF/MM.
The path towards compliance has been laid out by xfs maintainers.
Luis, Sasha and myself have been working to improve the filesystem
test coverage for stable tree candidate patches.
We have still some way to go.
The stable candidate patches that triggered the recent flames
was outside of the fs/xfs subsystem, which AUTOSEL already know
to stay away from, so nobody had any intention to stir things up.
At the end of the day, most xfs developers work for companies that
ship enterprise distros and need to maintain stable trees, so I would
hope that it is in the best interest of everyone involved to cooperate
on the goal of better stable-xfs ecosystem.
On my part, I would be happy if AUTOSEL could point me at
candidate patch *series* for review instead of single patches.
I'm afraid it's not smart enough to do that :(
I can grab an entire series if it selects a single patch in a series,
but from my experience it's usually the wrong thing to do.
For that matter, it sure wouldn't hurt if an xfs developer sending
out a patch series would cc:stable on the cover letter and if a developer
would be kind enough to add some backporting hints to the cover letter
text that would be very helpful indeed.
Given that we have folks (Luis, Amir, etc) working on it already, maybe
a step in the right direction would be having the XFS folks tag fixes
some other way ("#wants-a-backport"?) where this would give a hint that
this should be backported after sufficient testing?
We won't pick these commits to stable ourselves, but only after the XFS
maintainers are satisfied that the commit was sufficiently tested on LTS
trees?
--
Thanks,
Sasha
Re: [PATCH 3.18 14/83] ARM: make lookup_processor_type() non-__init
On Fri, Nov 30, 2018 at 04:18:43PM +0100, Greg Kroah-Hartman wrote:
On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> Hi,
>
> As I've already fed back to Sascha about this, this patch on its own
> does not fix anything, and is not a stable kernel candidate without
> a patch that makes use of it (iow, the spectre fixes.) It is a
> preparatory patch for mainline commit 383fb3ee8024.
>
> Every commit in:
>
> $ git rev-list v4.16..383fb3ee8024
>
> are the ARM spectre fixes, which are being back-ported by David Long.
>
> Please do not cherry-pick commits from within this series for _any_
> stable kernel, but please wait for David to send you the back-ported
> patches.
Ugh, ok, that's a bunch here.
Ok, not that bad, only 4:
383fb3ee8024 ("ARM: spectre-v2: per-CPU vtables to work around big.Little
systems")
e209950fdd06 ("ARM: add PROC_VTABLE and PROC_TABLE macros")
945aceb1db88 ("ARM: clean up per-processor check_bugs method call")
899a42f83667 ("ARM: make lookup_processor_type() non-__init")
I'll go drop them all from the trees now. Turns out for 4.14 one of
these patches broke the build anyway. Sasha, how did that past your
builder tests?
Because it builds :)
--
Thanks,
Sasha
Re: [PATCH 3.18 14/83] ARM: make lookup_processor_type() non-__init
On Fri, Nov 30, 2018 at 04:18:43PM +0100, Greg Kroah-Hartman wrote:
On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> Hi,
>
> As I've already fed back to Sascha about this, this patch on its own
> does not fix anything, and is not a stable kernel candidate without
> a patch that makes use of it (iow, the spectre fixes.) It is a
> preparatory patch for mainline commit 383fb3ee8024.
>
> Every commit in:
>
> $ git rev-list v4.16..383fb3ee8024
>
> are the ARM spectre fixes, which are being back-ported by David Long.
>
> Please do not cherry-pick commits from within this series for _any_
> stable kernel, but please wait for David to send you the back-ported
> patches.
Ugh, ok, that's a bunch here.
Ok, not that bad, only 4:
383fb3ee8024 ("ARM: spectre-v2: per-CPU vtables to work around big.Little
systems")
e209950fdd06 ("ARM: add PROC_VTABLE and PROC_TABLE macros")
945aceb1db88 ("ARM: clean up per-processor check_bugs method call")
899a42f83667 ("ARM: make lookup_processor_type() non-__init")
I'll go drop them all from the trees now. Turns out for 4.14 one of
these patches broke the build anyway. Sasha, how did that past your
builder tests?
Because it builds :)
--
Thanks,
Sasha
Re: [PATCH] docs: Extend trusted keys documentation for TPM 2.0
On Fri, 2018-11-30 at 15:46 -0800, Jarkko Sakkinen wrote: > On Fri, Nov 30, 2018 at 03:45:07PM -0800, Jarkko Sakkinen wrote: > > On Tue, Nov 06, 2018 at 01:17:34PM -0500, Mimi Zohar wrote: > > > On Tue, 2018-11-06 at 09:46 -0700, Jerry Snitselaar wrote: > > > > On Fri Oct 19 18, Stefan Berger wrote: > > > > >Extend the documentation for trusted keys with documentation for how to > > > > >set up a key for a TPM 2.0 so it can be used with a TPM 2.0 as well. > > > > > > > > > >Signed-off-by: Stefan Berger > > > > >Reviewed-by: Mimi Zohar > > > > > > > > Acked-by: Jerry Snitselaar > > > > > > Thanks! This patch is now staged in the #next-integrity-queued > > > branch. > > > > > > Mimi > > > > Reviewed-by: Jarkko Sakkinen > > Brings to mind, in the long run where the backend code for trusted keys > should reside. Are you asking about coordinating staging the trusted key patches to be upstreamed or about moving portions of the encrypted keys code out of the keyring subsystem? I'm not sure there needs to be a separate encrypted-keys pull request. Either they can be upstreamed via the TPM or the integrity subsystem for now. Mimi
Re: [PATCH] docs: Extend trusted keys documentation for TPM 2.0
On Fri, 2018-11-30 at 15:46 -0800, Jarkko Sakkinen wrote: > On Fri, Nov 30, 2018 at 03:45:07PM -0800, Jarkko Sakkinen wrote: > > On Tue, Nov 06, 2018 at 01:17:34PM -0500, Mimi Zohar wrote: > > > On Tue, 2018-11-06 at 09:46 -0700, Jerry Snitselaar wrote: > > > > On Fri Oct 19 18, Stefan Berger wrote: > > > > >Extend the documentation for trusted keys with documentation for how to > > > > >set up a key for a TPM 2.0 so it can be used with a TPM 2.0 as well. > > > > > > > > > >Signed-off-by: Stefan Berger > > > > >Reviewed-by: Mimi Zohar > > > > > > > > Acked-by: Jerry Snitselaar > > > > > > Thanks! This patch is now staged in the #next-integrity-queued > > > branch. > > > > > > Mimi > > > > Reviewed-by: Jarkko Sakkinen > > Brings to mind, in the long run where the backend code for trusted keys > should reside. Are you asking about coordinating staging the trusted key patches to be upstreamed or about moving portions of the encrypted keys code out of the keyring subsystem? I'm not sure there needs to be a separate encrypted-keys pull request. Either they can be upstreamed via the TPM or the integrity subsystem for now. Mimi
Re: [PATCH] ubi: fastmap: Check each mapping only once
On Sun, Dec 2, 2018 at 2:35 PM Sasha Levin wrote: > > On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote: > >Hi Greg, > > > >On Sun, Dec 2, 2018 at 8:51 AM Richard Weinberger wrote: > >> > >> Greg, > >> > >> Am Donnerstag, 29. November 2018, 09:09:23 CET schrieb Greg KH: > >> > On Mon, Nov 26, 2018 at 11:38:42AM +0100, Martin Kepplinger wrote: > >> > > From: Richard Weinberger > >> > > > >> > > [ Upstream commit 34653fd8c46e771585fce5975e4243f8fd401914 ] > >> > > > > > >> > > >> > Now queued up for 4.14.y, thanks. > >> > >> can you *please* slow a little down? > > > >True. It will really help if you can have some sort of fixed schedule > >for stable release, like maybe stablerc is ready on Thursday or Friday > >and release the stable on Monday. Having a weekend in stablerc will be > >helpful for people like me who only get the time in weekends for > >upstream or stable kernel. > > Any sort of schedule will never work for everyone (for example, if it's > part of your paid job - you don't necessarily want to review stuff over > the weekend). Yes, exactly. But like I said if the stablerc tree is pushed on Thursday, and the stable release is released on Monday then both types of people will get time, and hopefully everyone is happy. :) -- Regards Sudip
Re: [PATCH] ubi: fastmap: Check each mapping only once
On Sun, Dec 2, 2018 at 2:35 PM Sasha Levin wrote: > > On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote: > >Hi Greg, > > > >On Sun, Dec 2, 2018 at 8:51 AM Richard Weinberger wrote: > >> > >> Greg, > >> > >> Am Donnerstag, 29. November 2018, 09:09:23 CET schrieb Greg KH: > >> > On Mon, Nov 26, 2018 at 11:38:42AM +0100, Martin Kepplinger wrote: > >> > > From: Richard Weinberger > >> > > > >> > > [ Upstream commit 34653fd8c46e771585fce5975e4243f8fd401914 ] > >> > > > > > >> > > >> > Now queued up for 4.14.y, thanks. > >> > >> can you *please* slow a little down? > > > >True. It will really help if you can have some sort of fixed schedule > >for stable release, like maybe stablerc is ready on Thursday or Friday > >and release the stable on Monday. Having a weekend in stablerc will be > >helpful for people like me who only get the time in weekends for > >upstream or stable kernel. > > Any sort of schedule will never work for everyone (for example, if it's > part of your paid job - you don't necessarily want to review stuff over > the weekend). Yes, exactly. But like I said if the stablerc tree is pushed on Thursday, and the stable release is released on Monday then both types of people will get time, and hopefully everyone is happy. :) -- Regards Sudip
Re: [PATCH] ubi: fastmap: Check each mapping only once
Sasha, Am Sonntag, 2. Dezember 2018, 15:35:43 CET schrieb Sasha Levin: > On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote: > >> > Now queued up for 4.14.y, thanks. > >> > >> can you *please* slow a little down? > > > >True. It will really help if you can have some sort of fixed schedule > >for stable release, like maybe stablerc is ready on Thursday or Friday > >and release the stable on Monday. Having a weekend in stablerc will be > >helpful for people like me who only get the time in weekends for > >upstream or stable kernel. > > Any sort of schedule will never work for everyone (for example, if it's > part of your paid job - you don't necessarily want to review stuff over > the weekend). a schedule is not needed, but please give maintainers at least a chance to react on stable inclusion request. In this case Martin asked for inclusion on Monday and the patch was applied two days later. As you noted not everyone works full time on the kernel and gets paid for that. So it might take a few days to react and review such a request. Thanks, //richard
Re: [PATCH] ubi: fastmap: Check each mapping only once
Sasha, Am Sonntag, 2. Dezember 2018, 15:35:43 CET schrieb Sasha Levin: > On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote: > >> > Now queued up for 4.14.y, thanks. > >> > >> can you *please* slow a little down? > > > >True. It will really help if you can have some sort of fixed schedule > >for stable release, like maybe stablerc is ready on Thursday or Friday > >and release the stable on Monday. Having a weekend in stablerc will be > >helpful for people like me who only get the time in weekends for > >upstream or stable kernel. > > Any sort of schedule will never work for everyone (for example, if it's > part of your paid job - you don't necessarily want to review stuff over > the weekend). a schedule is not needed, but please give maintainers at least a chance to react on stable inclusion request. In this case Martin asked for inclusion on Monday and the patch was applied two days later. As you noted not everyone works full time on the kernel and gets paid for that. So it might take a few days to react and review such a request. Thanks, //richard
Re: [PATCH] ubi: fastmap: Check each mapping only once
On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote: Hi Greg, On Sun, Dec 2, 2018 at 8:51 AM Richard Weinberger wrote: Greg, Am Donnerstag, 29. November 2018, 09:09:23 CET schrieb Greg KH: > On Mon, Nov 26, 2018 at 11:38:42AM +0100, Martin Kepplinger wrote: > > From: Richard Weinberger > > > > [ Upstream commit 34653fd8c46e771585fce5975e4243f8fd401914 ] > > > > Now queued up for 4.14.y, thanks. can you *please* slow a little down? True. It will really help if you can have some sort of fixed schedule for stable release, like maybe stablerc is ready on Thursday or Friday and release the stable on Monday. Having a weekend in stablerc will be helpful for people like me who only get the time in weekends for upstream or stable kernel. Any sort of schedule will never work for everyone (for example, if it's part of your paid job - you don't necessarily want to review stuff over the weekend). -- Thanks, Sasha
Re: ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined!
On Sun, Dec 2, 2018 at 3:06 PM kbuild test robot wrote:
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 4b78317679c4f3782a3cff0ddb269c1fcfde7621
> commit: 3ab91828166895600efd9cdc3a0eb32001f7204a dm thin metadata: try to
> avoid ever aborting transactions
> date: 3 months ago
> config: i386-randconfig-j0-12020939 (attached as .config)
> compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> reproduce:
> git checkout 3ab91828166895600efd9cdc3a0eb32001f7204a
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
> >> ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined!
Wasn't that fixed in v4.19-rc7 by commit 013ad043906b2bef ("dm thin
metadata: fix __udivdi3 undefined on 32-bit")?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] ubi: fastmap: Check each mapping only once
On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote: Hi Greg, On Sun, Dec 2, 2018 at 8:51 AM Richard Weinberger wrote: Greg, Am Donnerstag, 29. November 2018, 09:09:23 CET schrieb Greg KH: > On Mon, Nov 26, 2018 at 11:38:42AM +0100, Martin Kepplinger wrote: > > From: Richard Weinberger > > > > [ Upstream commit 34653fd8c46e771585fce5975e4243f8fd401914 ] > > > > Now queued up for 4.14.y, thanks. can you *please* slow a little down? True. It will really help if you can have some sort of fixed schedule for stable release, like maybe stablerc is ready on Thursday or Friday and release the stable on Monday. Having a weekend in stablerc will be helpful for people like me who only get the time in weekends for upstream or stable kernel. Any sort of schedule will never work for everyone (for example, if it's part of your paid job - you don't necessarily want to review stuff over the weekend). -- Thanks, Sasha
Re: ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined!
On Sun, Dec 2, 2018 at 3:06 PM kbuild test robot wrote:
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 4b78317679c4f3782a3cff0ddb269c1fcfde7621
> commit: 3ab91828166895600efd9cdc3a0eb32001f7204a dm thin metadata: try to
> avoid ever aborting transactions
> date: 3 months ago
> config: i386-randconfig-j0-12020939 (attached as .config)
> compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> reproduce:
> git checkout 3ab91828166895600efd9cdc3a0eb32001f7204a
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
> >> ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined!
Wasn't that fixed in v4.19-rc7 by commit 013ad043906b2bef ("dm thin
metadata: fix __udivdi3 undefined on 32-bit")?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined!
Hi Joe, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 4b78317679c4f3782a3cff0ddb269c1fcfde7621 commit: 3ab91828166895600efd9cdc3a0eb32001f7204a dm thin metadata: try to avoid ever aborting transactions date: 3 months ago config: i386-randconfig-j0-12020939 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: git checkout 3ab91828166895600efd9cdc3a0eb32001f7204a # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined!
Hi Joe, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 4b78317679c4f3782a3cff0ddb269c1fcfde7621 commit: 3ab91828166895600efd9cdc3a0eb32001f7204a dm thin metadata: try to avoid ever aborting transactions date: 3 months ago config: i386-randconfig-j0-12020939 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: git checkout 3ab91828166895600efd9cdc3a0eb32001f7204a # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH 1/2] PCI: mobiveil: ls_pcie_g4: add Workaround for A-011577
From: Hou Zhiqiang
PCIe configuration access to non-existent function triggered
SERROR interrupt exception.
Workaround:
Disable error reporting on AXI bus during the Vendor ID read
transactions in enumeration.
This ERRATA is only for LX2160A Rev1.0, and it will be fixed
in Rev2.0.
Signed-off-by: Hou Zhiqiang
---
.../controller/mobiveil/pci-layerscape-gen4.c | 24 +++
.../controller/mobiveil/pcie-mobiveil-host.c | 13 +-
.../pci/controller/mobiveil/pcie-mobiveil.h | 2 ++
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
b/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
index 174cbcac4059..1fe56532b288 100644
--- a/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
+++ b/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
@@ -24,6 +24,9 @@
/* LUT and PF control registers */
#define PCIE_LUT_OFF (0x8)
+#define PCIE_LUT_GCR (0x28)
+#define PCIE_LUT_GCR_RRE (0)
+
#define PCIE_PF_OFF(0xc)
#define PCIE_PF_INT_STAT (0x18)
#define PF_INT_STAT_PABRST (31)
@@ -188,8 +191,29 @@ static void ls_pcie_g4_reset(struct work_struct *work)
ls_pcie_g4_reinit_hw(pcie);
}
+static int ls_pcie_g4_read_other_conf(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 *val)
+{
+ struct mobiveil_pcie *pci = bus->sysdata;
+ struct ls_pcie_g4 *pcie = to_ls_pcie_g4(pci);
+ int ret;
+
+ if (where == PCI_VENDOR_ID)
+ ls_pcie_g4_lut_writel(pcie, PCIE_LUT_GCR,
+ 0 << PCIE_LUT_GCR_RRE);
+
+ ret = pci_generic_config_read(bus, devfn, where, size, val);
+
+ if (where == PCI_VENDOR_ID)
+ ls_pcie_g4_lut_writel(pcie, PCIE_LUT_GCR,
+ 1 << PCIE_LUT_GCR_RRE);
+
+ return ret;
+}
+
static struct mobiveil_rp_ops ls_pcie_g4_rp_ops = {
.interrupt_init = ls_pcie_g4_interrupt_init,
+ .read_other_conf = ls_pcie_g4_read_other_conf,
};
static const struct mobiveil_pab_ops ls_pcie_g4_pab_ops = {
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
index c85f00d3cfcf..8b6db38320d7 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
@@ -79,9 +79,20 @@ static void __iomem *mobiveil_pcie_map_bus(struct pci_bus
*bus,
return pcie->rp.config_axi_slave_base + where;
}
+static int mobiveil_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
+int where, int size, u32 *val)
+{
+ struct mobiveil_pcie *pcie = bus->sysdata;
+ struct root_port *rp = >rp;
+
+ if (bus->number > rp->root_bus_nr && rp->ops->read_other_conf)
+ return rp->ops->read_other_conf(bus, devfn, where, size, val);
+
+ return pci_generic_config_read(bus, devfn, where, size, val);
+}
static struct pci_ops mobiveil_pcie_ops = {
.map_bus = mobiveil_pcie_map_bus,
- .read = pci_generic_config_read,
+ .read = mobiveil_pcie_config_read,
.write = pci_generic_config_write,
};
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
index 0ccd6cee5f8f..ef93b41f4419 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
@@ -145,6 +145,8 @@ struct mobiveil_msi { /* MSI
information */
struct mobiveil_rp_ops {
int (*interrupt_init)(struct mobiveil_pcie *pcie);
+ int (*read_other_conf)(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 *val);
};
struct root_port {
--
2.17.1
[PATCH 1/2] PCI: mobiveil: ls_pcie_g4: add Workaround for A-011577
From: Hou Zhiqiang
PCIe configuration access to non-existent function triggered
SERROR interrupt exception.
Workaround:
Disable error reporting on AXI bus during the Vendor ID read
transactions in enumeration.
This ERRATA is only for LX2160A Rev1.0, and it will be fixed
in Rev2.0.
Signed-off-by: Hou Zhiqiang
---
.../controller/mobiveil/pci-layerscape-gen4.c | 24 +++
.../controller/mobiveil/pcie-mobiveil-host.c | 13 +-
.../pci/controller/mobiveil/pcie-mobiveil.h | 2 ++
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
b/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
index 174cbcac4059..1fe56532b288 100644
--- a/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
+++ b/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
@@ -24,6 +24,9 @@
/* LUT and PF control registers */
#define PCIE_LUT_OFF (0x8)
+#define PCIE_LUT_GCR (0x28)
+#define PCIE_LUT_GCR_RRE (0)
+
#define PCIE_PF_OFF(0xc)
#define PCIE_PF_INT_STAT (0x18)
#define PF_INT_STAT_PABRST (31)
@@ -188,8 +191,29 @@ static void ls_pcie_g4_reset(struct work_struct *work)
ls_pcie_g4_reinit_hw(pcie);
}
+static int ls_pcie_g4_read_other_conf(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 *val)
+{
+ struct mobiveil_pcie *pci = bus->sysdata;
+ struct ls_pcie_g4 *pcie = to_ls_pcie_g4(pci);
+ int ret;
+
+ if (where == PCI_VENDOR_ID)
+ ls_pcie_g4_lut_writel(pcie, PCIE_LUT_GCR,
+ 0 << PCIE_LUT_GCR_RRE);
+
+ ret = pci_generic_config_read(bus, devfn, where, size, val);
+
+ if (where == PCI_VENDOR_ID)
+ ls_pcie_g4_lut_writel(pcie, PCIE_LUT_GCR,
+ 1 << PCIE_LUT_GCR_RRE);
+
+ return ret;
+}
+
static struct mobiveil_rp_ops ls_pcie_g4_rp_ops = {
.interrupt_init = ls_pcie_g4_interrupt_init,
+ .read_other_conf = ls_pcie_g4_read_other_conf,
};
static const struct mobiveil_pab_ops ls_pcie_g4_pab_ops = {
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
index c85f00d3cfcf..8b6db38320d7 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
@@ -79,9 +79,20 @@ static void __iomem *mobiveil_pcie_map_bus(struct pci_bus
*bus,
return pcie->rp.config_axi_slave_base + where;
}
+static int mobiveil_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
+int where, int size, u32 *val)
+{
+ struct mobiveil_pcie *pcie = bus->sysdata;
+ struct root_port *rp = >rp;
+
+ if (bus->number > rp->root_bus_nr && rp->ops->read_other_conf)
+ return rp->ops->read_other_conf(bus, devfn, where, size, val);
+
+ return pci_generic_config_read(bus, devfn, where, size, val);
+}
static struct pci_ops mobiveil_pcie_ops = {
.map_bus = mobiveil_pcie_map_bus,
- .read = pci_generic_config_read,
+ .read = mobiveil_pcie_config_read,
.write = pci_generic_config_write,
};
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
index 0ccd6cee5f8f..ef93b41f4419 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
@@ -145,6 +145,8 @@ struct mobiveil_msi { /* MSI
information */
struct mobiveil_rp_ops {
int (*interrupt_init)(struct mobiveil_pcie *pcie);
+ int (*read_other_conf)(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 *val);
};
struct root_port {
--
2.17.1
[PATCH 2/2] PCI: mobiveil: ls_pcie_g4: add Workaround for A-011451
From: Hou Zhiqiang
When LX2 PCIe controller is sending multiple split completions and
ACK latency expires indicating that ACK should be send at priority.
But because of large number of split completions and FC update DLLP,
the controller does not give priority to ACK transmission. This
results into ACK latency timer timeout error at the link partner and
the pending TLPs are replayed by the link partner again.
Workaround:
1. Reduce the ACK latency timeout value to a very small value.
2. Restrict the number of completions from the LX2 PCIe controller
to 1, by changing the Max Read Request Size (MRRS) of link partner
to the same value as Max Packet size (MPS).
This patch implemented part 1, the part 2 can be set by kernel parameter
'pci=pcie_bus_perf'
This ERRATA is only for LX2160A Rev1.0, and it will be fixed
in Rev2.0.
Signed-off-by: Hou Zhiqiang
---
.../pci/controller/mobiveil/pci-layerscape-gen4.c | 14 ++
drivers/pci/controller/mobiveil/pcie-mobiveil.h| 4
2 files changed, 18 insertions(+)
diff --git a/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
b/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
index 1fe56532b288..ef43033e1c2a 100644
--- a/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
+++ b/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
@@ -220,6 +220,18 @@ static const struct mobiveil_pab_ops ls_pcie_g4_pab_ops = {
.link_up = ls_pcie_g4_link_up,
};
+static void workaround_A011451(struct ls_pcie_g4 *pcie)
+{
+ struct mobiveil_pcie *mv_pci = pcie->pci;
+ u32 val;
+
+ /* Set ACK latency timeout */
+ val = csr_readl(mv_pci, GPEX_ACK_REPLAY_TO);
+ val &= ~(ACK_LAT_TO_VAL_MASK << ACK_LAT_TO_VAL_SHIFT);
+ val |= (4 << ACK_LAT_TO_VAL_SHIFT);
+ csr_writel(mv_pci, val, GPEX_ACK_REPLAY_TO);
+}
+
static int __init ls_pcie_g4_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -259,6 +271,8 @@ static int __init ls_pcie_g4_probe(struct platform_device
*pdev)
if (!ls_pcie_g4_is_bridge(pcie))
return -ENODEV;
+ workaround_A011451(pcie);
+
return 0;
}
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
index ef93b41f4419..c75b7c304c46 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
@@ -85,6 +85,10 @@
#define PAB_AXI_AMAP_PEX_WIN_H(win)PAB_REG_ADDR(0x0bac, win)
#define PAB_INTP_AXI_PIO_CLASS 0x474
+#define GPEX_ACK_REPLAY_TO 0x438
+#define ACK_LAT_TO_VAL_MASK 0x1fff
+#define ACK_LAT_TO_VAL_SHIFT 0
+
#define PAB_PEX_AMAP_CTRL(win) PAB_REG_ADDR(0x4ba0, win)
#define AMAP_CTRL_EN_SHIFT0
#define AMAP_CTRL_TYPE_SHIFT 1
--
2.17.1
[PATCH 2/2] PCI: mobiveil: ls_pcie_g4: add Workaround for A-011451
From: Hou Zhiqiang
When LX2 PCIe controller is sending multiple split completions and
ACK latency expires indicating that ACK should be send at priority.
But because of large number of split completions and FC update DLLP,
the controller does not give priority to ACK transmission. This
results into ACK latency timer timeout error at the link partner and
the pending TLPs are replayed by the link partner again.
Workaround:
1. Reduce the ACK latency timeout value to a very small value.
2. Restrict the number of completions from the LX2 PCIe controller
to 1, by changing the Max Read Request Size (MRRS) of link partner
to the same value as Max Packet size (MPS).
This patch implemented part 1, the part 2 can be set by kernel parameter
'pci=pcie_bus_perf'
This ERRATA is only for LX2160A Rev1.0, and it will be fixed
in Rev2.0.
Signed-off-by: Hou Zhiqiang
---
.../pci/controller/mobiveil/pci-layerscape-gen4.c | 14 ++
drivers/pci/controller/mobiveil/pcie-mobiveil.h| 4
2 files changed, 18 insertions(+)
diff --git a/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
b/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
index 1fe56532b288..ef43033e1c2a 100644
--- a/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
+++ b/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
@@ -220,6 +220,18 @@ static const struct mobiveil_pab_ops ls_pcie_g4_pab_ops = {
.link_up = ls_pcie_g4_link_up,
};
+static void workaround_A011451(struct ls_pcie_g4 *pcie)
+{
+ struct mobiveil_pcie *mv_pci = pcie->pci;
+ u32 val;
+
+ /* Set ACK latency timeout */
+ val = csr_readl(mv_pci, GPEX_ACK_REPLAY_TO);
+ val &= ~(ACK_LAT_TO_VAL_MASK << ACK_LAT_TO_VAL_SHIFT);
+ val |= (4 << ACK_LAT_TO_VAL_SHIFT);
+ csr_writel(mv_pci, val, GPEX_ACK_REPLAY_TO);
+}
+
static int __init ls_pcie_g4_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -259,6 +271,8 @@ static int __init ls_pcie_g4_probe(struct platform_device
*pdev)
if (!ls_pcie_g4_is_bridge(pcie))
return -ENODEV;
+ workaround_A011451(pcie);
+
return 0;
}
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
index ef93b41f4419..c75b7c304c46 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
@@ -85,6 +85,10 @@
#define PAB_AXI_AMAP_PEX_WIN_H(win)PAB_REG_ADDR(0x0bac, win)
#define PAB_INTP_AXI_PIO_CLASS 0x474
+#define GPEX_ACK_REPLAY_TO 0x438
+#define ACK_LAT_TO_VAL_MASK 0x1fff
+#define ACK_LAT_TO_VAL_SHIFT 0
+
#define PAB_PEX_AMAP_CTRL(win) PAB_REG_ADDR(0x4ba0, win)
#define AMAP_CTRL_EN_SHIFT0
#define AMAP_CTRL_TYPE_SHIFT 1
--
2.17.1
[PATCH 0/2] PCI: ls_pcie_g4: add 2 workarounds
From: Hou Zhiqiang This patchset adds 2 workarounds for NXP Layerscape Gen4 PCIe controller driver. Hou Zhiqiang (2): PCI: mobiveil: ls_pcie_g4: add Workaround for A-011577 PCI: mobiveil: ls_pcie_g4: add Workaround for A-011451 depends on patchset: https://patchwork.ozlabs.org/project/linux-pci/list/?series=76942 .../controller/mobiveil/pci-layerscape-gen4.c | 38 +++ .../controller/mobiveil/pcie-mobiveil-host.c | 13 ++- .../pci/controller/mobiveil/pcie-mobiveil.h | 6 +++ 3 files changed, 56 insertions(+), 1 deletion(-) -- 2.17.1
[PATCH 0/2] PCI: ls_pcie_g4: add 2 workarounds
From: Hou Zhiqiang This patchset adds 2 workarounds for NXP Layerscape Gen4 PCIe controller driver. Hou Zhiqiang (2): PCI: mobiveil: ls_pcie_g4: add Workaround for A-011577 PCI: mobiveil: ls_pcie_g4: add Workaround for A-011451 depends on patchset: https://patchwork.ozlabs.org/project/linux-pci/list/?series=76942 .../controller/mobiveil/pci-layerscape-gen4.c | 38 +++ .../controller/mobiveil/pcie-mobiveil-host.c | 13 ++- .../pci/controller/mobiveil/pcie-mobiveil.h | 6 +++ 3 files changed, 56 insertions(+), 1 deletion(-) -- 2.17.1
Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()
On Fri, 30 Nov 2018 23:26:25 +0100
Linus Walleij wrote:
> On Thu, Nov 29, 2018 at 7:14 PM Bartosz Golaszewski wrote:
>
> > Thomas, Linus: after commit fa38869b0161 ("gpiolib: Don't support irq
> > sharing for userspace") some libgpiod tests are failing because we can
> > no longer depend on reading the value of a dummy GPIO after detecting
> > an interrupt to know the edge of the interrupt. While these interrupts
> > are triggered from debugfs and debugfs is not required to maintain
> > compatibility, I thing having a working test suite for the GPIO
> > subsystem and uAPI is worth applying these two patches and also the
> > previous one[1].
> >
> > Can we have them applied for 4.20 or are there any objections?
>
> I'm fine with applying them if I can just get an ACK from one of the IRQ
> maintainers (Thomas, Marc).
I'm fine with that patch, with the provision that (nitpick) the edge
field is turned into a bool instead of an int.
With that,
Acked-by: Marc Zyngier
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()
On Fri, 30 Nov 2018 23:26:25 +0100
Linus Walleij wrote:
> On Thu, Nov 29, 2018 at 7:14 PM Bartosz Golaszewski wrote:
>
> > Thomas, Linus: after commit fa38869b0161 ("gpiolib: Don't support irq
> > sharing for userspace") some libgpiod tests are failing because we can
> > no longer depend on reading the value of a dummy GPIO after detecting
> > an interrupt to know the edge of the interrupt. While these interrupts
> > are triggered from debugfs and debugfs is not required to maintain
> > compatibility, I thing having a working test suite for the GPIO
> > subsystem and uAPI is worth applying these two patches and also the
> > previous one[1].
> >
> > Can we have them applied for 4.20 or are there any objections?
>
> I'm fine with applying them if I can just get an ACK from one of the IRQ
> maintainers (Thomas, Marc).
I'm fine with that patch, with the provision that (nitpick) the edge
field is turned into a bool instead of an int.
With that,
Acked-by: Marc Zyngier
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)
Hi,
On 01-11-18 07:55, Mogens Jensen wrote:
‐‐‐ Original Message ‐‐‐
On Wednesday, October 31, 2018 9:29 AM, Hans de Goede
wrote:
Hi,
On 31-10-18 07:02, Mogens Jensen wrote:
‐‐‐ Original Message ‐‐‐
On Tuesday, October 30, 2018 7:10 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 30-10-18 19:56, Mogens Jensen wrote:
‐‐‐ Original Message ‐‐‐
On Tuesday, October 30, 2018 4:04 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 30-10-18 16:46, Hans de Goede wrote:
Hi,
On 30-10-18 16:04, Pierre-Louis Bossart wrote:
In addition I am not aware of any baytrail device using plt_clk_0, so moving a
common machine driver such a cht_bsw_max98090_ti to use plt_clk0 only would
break other devices (e.g. Rambi/Orco). Asking for both clocks to be on might
work though,
Ok, so we need to have a DMI based quirk for the Swanky and maybe also
the clapper to use plt_clk_0 there. Asking for 2 clks if we only need
one does not seem like a good plan.
Dean, Mogens,
To write a proper patch for this I'm going to need DMI strings
from your devices.
Can you please run (as normal user):
grep . /sys/class/dmi/id/* 2> /dev/null
And reply with the output of this command?
I have attached the output from a coreboot seabios based clapper.
Thank you.
Should I still test
0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch with
SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and asoundrc from Dean? There seems to
have been some development in the case since that request was made.
Yes please test that, I expect that to also fix things for the
Clapper, but I need to have that confirmed before submitting a
patch upstream adding a quirk for the Clapper to use pmc_plt_clk_0
instead of pmc_plt_clk_3.
Regards,
Hans
Unfortunately I only have access to longterm kernel 4.14 for building/running
on this system, and
0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch does not patch
against 4.14.78. Can a test patch for 4.14 be created?
Can you run (as root):
for i in /sys/kernel/debug/clk/pmc_plt_clk_?; do echo -n "$i: "; cat
$i/clk_flags; echo; done
When running a kernel with working audio?
Then I can confirm that the Clapper is also using pmc_plt_clk_0, so that I can
fix this for the clapper for 4.18+
I've just checked the 4.14 sources and in 4.14 the
SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH
driver does not support mclk control yet, so for the 4.14 kernel the only way to
fix this is to revert the 648e921888ad ("clk: x86: Stop marking clocks as
CLK_IS_CRITICAL")
commit.
Regards,
Hans
Here is the output from the Clapper with 4.14.78 and working sound:
/sys/kernel/debug/clk/pmc_plt_clk_0: 0x0800
/sys/kernel/debug/clk/pmc_plt_clk_1: 0x
/sys/kernel/debug/clk/pmc_plt_clk_2: 0x
/sys/kernel/debug/clk/pmc_plt_clk_3: 0x
/sys/kernel/debug/clk/pmc_plt_clk_4: 0x
/sys/kernel/debug/clk/pmc_plt_clk_5: 0x
Ok, so your Clapper model indeed is also using clk 0 and not clk 3 as
expected. I've just submitted a patch upstream adding a quirk for this.
As for what the plan is with 4.14, I don't know. I believe that
reverting the commit causing the issue there is fine.
Regards,
Hans
Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)
Hi,
On 01-11-18 07:55, Mogens Jensen wrote:
‐‐‐ Original Message ‐‐‐
On Wednesday, October 31, 2018 9:29 AM, Hans de Goede
wrote:
Hi,
On 31-10-18 07:02, Mogens Jensen wrote:
‐‐‐ Original Message ‐‐‐
On Tuesday, October 30, 2018 7:10 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 30-10-18 19:56, Mogens Jensen wrote:
‐‐‐ Original Message ‐‐‐
On Tuesday, October 30, 2018 4:04 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 30-10-18 16:46, Hans de Goede wrote:
Hi,
On 30-10-18 16:04, Pierre-Louis Bossart wrote:
In addition I am not aware of any baytrail device using plt_clk_0, so moving a
common machine driver such a cht_bsw_max98090_ti to use plt_clk0 only would
break other devices (e.g. Rambi/Orco). Asking for both clocks to be on might
work though,
Ok, so we need to have a DMI based quirk for the Swanky and maybe also
the clapper to use plt_clk_0 there. Asking for 2 clks if we only need
one does not seem like a good plan.
Dean, Mogens,
To write a proper patch for this I'm going to need DMI strings
from your devices.
Can you please run (as normal user):
grep . /sys/class/dmi/id/* 2> /dev/null
And reply with the output of this command?
I have attached the output from a coreboot seabios based clapper.
Thank you.
Should I still test
0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch with
SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and asoundrc from Dean? There seems to
have been some development in the case since that request was made.
Yes please test that, I expect that to also fix things for the
Clapper, but I need to have that confirmed before submitting a
patch upstream adding a quirk for the Clapper to use pmc_plt_clk_0
instead of pmc_plt_clk_3.
Regards,
Hans
Unfortunately I only have access to longterm kernel 4.14 for building/running
on this system, and
0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch does not patch
against 4.14.78. Can a test patch for 4.14 be created?
Can you run (as root):
for i in /sys/kernel/debug/clk/pmc_plt_clk_?; do echo -n "$i: "; cat
$i/clk_flags; echo; done
When running a kernel with working audio?
Then I can confirm that the Clapper is also using pmc_plt_clk_0, so that I can
fix this for the clapper for 4.18+
I've just checked the 4.14 sources and in 4.14 the
SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH
driver does not support mclk control yet, so for the 4.14 kernel the only way to
fix this is to revert the 648e921888ad ("clk: x86: Stop marking clocks as
CLK_IS_CRITICAL")
commit.
Regards,
Hans
Here is the output from the Clapper with 4.14.78 and working sound:
/sys/kernel/debug/clk/pmc_plt_clk_0: 0x0800
/sys/kernel/debug/clk/pmc_plt_clk_1: 0x
/sys/kernel/debug/clk/pmc_plt_clk_2: 0x
/sys/kernel/debug/clk/pmc_plt_clk_3: 0x
/sys/kernel/debug/clk/pmc_plt_clk_4: 0x
/sys/kernel/debug/clk/pmc_plt_clk_5: 0x
Ok, so your Clapper model indeed is also using clk 0 and not clk 3 as
expected. I've just submitted a patch upstream adding a quirk for this.
As for what the plan is with 4.14, I don't know. I believe that
reverting the commit causing the issue there is fine.
Regards,
Hans
Waiting for your response
-- Dear Fund owner, Do you have any pending fund transfer? Or difficulties in receiving money to your account from abroad? World bank has setup a committee to help you. Reply for details Morris Sydor Auditor General
Waiting for your response
-- Dear Fund owner, Do you have any pending fund transfer? Or difficulties in receiving money to your account from abroad? World bank has setup a committee to help you. Reply for details Morris Sydor Auditor General
Re: [PATCH v4 0/20] MMP platform fixes
On Fri, 2018-11-30 at 15:44 -0800, Olof Johansson wrote: > Hi, > > On Wed, Nov 28, 2018 at 10:39:06PM +0100, Arnd Bergmann wrote: > > On Wed, Nov 28, 2018 at 6:53 PM Lubomir Rintel wrote: > > > Hi, > > > > > > this series contains contains a bunch of MMP2 platform fixes. > > > > > > Previous spins of the patch set were sent out over the course of last > > > three months to the MMP platform maintainers, with Arnd and > > > linux-arm-ker...@lists.infradead.org on copy. > > > > > > Unfortunatelly, MMP maintainers (Eric Miao and Haojian Zhuang) don't > > > seem to respond anymore. That's a shame, because the MMP2 support seems to > > > in need for some love. The DT/multiplatform kernels can't even boot > > > without > > > 14/20, 15/20 and perhaps more. > > > > > > I'm wondering if this cat gen in via the arm-soc tree? Would it be > > > appropriate if I followed up with a MAINTAINERS update in that case? > > > > Yes, sounds good to me. I looked through the series again, and > > found one patch that seems wrong to me. Everything else should > > just go in. > > I've applied the DT patches and the ones that touch only arch/arm/mach-*. > There are a few driver patches here that should be reviewed/acked by the > corresponding maintainers as well, so I didn't apply most of them yet. Thank you. > > > The patch set has been tested on an OLPC XO-1.75 laptop. > > > > Excellent! > > OOooh, I have one of those... somewhere. I'm working on adjusting the machine's OFW to provide a devicetree that matches what mainline Linux expects. I'll follow up with a boot script in a few days -- once it's good enough to be actually useful. There also seems to be a good chance that we'll get an updated firmware image at some point. Until then, CONFIG_ARM_APPENDED_DTB can be used, though a zImage header needs to be modified to account for the DTB at the end: https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75 > -Olof Lubo
Re: [PATCH v4 0/20] MMP platform fixes
On Fri, 2018-11-30 at 15:44 -0800, Olof Johansson wrote: > Hi, > > On Wed, Nov 28, 2018 at 10:39:06PM +0100, Arnd Bergmann wrote: > > On Wed, Nov 28, 2018 at 6:53 PM Lubomir Rintel wrote: > > > Hi, > > > > > > this series contains contains a bunch of MMP2 platform fixes. > > > > > > Previous spins of the patch set were sent out over the course of last > > > three months to the MMP platform maintainers, with Arnd and > > > linux-arm-ker...@lists.infradead.org on copy. > > > > > > Unfortunatelly, MMP maintainers (Eric Miao and Haojian Zhuang) don't > > > seem to respond anymore. That's a shame, because the MMP2 support seems to > > > in need for some love. The DT/multiplatform kernels can't even boot > > > without > > > 14/20, 15/20 and perhaps more. > > > > > > I'm wondering if this cat gen in via the arm-soc tree? Would it be > > > appropriate if I followed up with a MAINTAINERS update in that case? > > > > Yes, sounds good to me. I looked through the series again, and > > found one patch that seems wrong to me. Everything else should > > just go in. > > I've applied the DT patches and the ones that touch only arch/arm/mach-*. > There are a few driver patches here that should be reviewed/acked by the > corresponding maintainers as well, so I didn't apply most of them yet. Thank you. > > > The patch set has been tested on an OLPC XO-1.75 laptop. > > > > Excellent! > > OOooh, I have one of those... somewhere. I'm working on adjusting the machine's OFW to provide a devicetree that matches what mainline Linux expects. I'll follow up with a boot script in a few days -- once it's good enough to be actually useful. There also seems to be a good chance that we'll get an updated firmware image at some point. Until then, CONFIG_ARM_APPENDED_DTB can be used, though a zImage header needs to be modified to account for the DTB at the end: https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75 > -Olof Lubo
Re: [PATCH] ubi: fastmap: Check each mapping only once
Hi Greg, On Sun, Dec 2, 2018 at 8:51 AM Richard Weinberger wrote: > > Greg, > > Am Donnerstag, 29. November 2018, 09:09:23 CET schrieb Greg KH: > > On Mon, Nov 26, 2018 at 11:38:42AM +0100, Martin Kepplinger wrote: > > > From: Richard Weinberger > > > > > > [ Upstream commit 34653fd8c46e771585fce5975e4243f8fd401914 ] > > > > > > > Now queued up for 4.14.y, thanks. > > can you *please* slow a little down? True. It will really help if you can have some sort of fixed schedule for stable release, like maybe stablerc is ready on Thursday or Friday and release the stable on Monday. Having a weekend in stablerc will be helpful for people like me who only get the time in weekends for upstream or stable kernel. -- Regards Sudip
Re: [PATCH] ubi: fastmap: Check each mapping only once
Hi Greg, On Sun, Dec 2, 2018 at 8:51 AM Richard Weinberger wrote: > > Greg, > > Am Donnerstag, 29. November 2018, 09:09:23 CET schrieb Greg KH: > > On Mon, Nov 26, 2018 at 11:38:42AM +0100, Martin Kepplinger wrote: > > > From: Richard Weinberger > > > > > > [ Upstream commit 34653fd8c46e771585fce5975e4243f8fd401914 ] > > > > > > > Now queued up for 4.14.y, thanks. > > can you *please* slow a little down? True. It will really help if you can have some sort of fixed schedule for stable release, like maybe stablerc is ready on Thursday or Friday and release the stable on Monday. Having a weekend in stablerc will be helpful for people like me who only get the time in weekends for upstream or stable kernel. -- Regards Sudip
[PATCH] dt-bindings: arm: mrvl: amend Browstone compatible string
The Brownstone board is compatible with "mrvl,mmp2". The actual DTS already contains the string -- add it to the binding doc as well. Signed-off-by: Lubomir Rintel --- Documentation/devicetree/bindings/arm/mrvl/mrvl.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt index 117d741a2e4f..951687528efb 100644 --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt @@ -11,4 +11,4 @@ Required root node properties: MMP2 Brownstone Board Required root node properties: - - compatible = "mrvl,mmp2-brownstone"; + - compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2"; -- 2.19.1
[PATCH] dt-bindings: arm: mrvl: amend Browstone compatible string
The Brownstone board is compatible with "mrvl,mmp2". The actual DTS already contains the string -- add it to the binding doc as well. Signed-off-by: Lubomir Rintel --- Documentation/devicetree/bindings/arm/mrvl/mrvl.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt index 117d741a2e4f..951687528efb 100644 --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt @@ -11,4 +11,4 @@ Required root node properties: MMP2 Brownstone Board Required root node properties: - - compatible = "mrvl,mmp2-brownstone"; + - compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2"; -- 2.19.1
[PATCH] ARM: mmp2: DT: be compatible with mrvl,mmp2
There are more boards that can work with mmp2-dt than just Brownstone.
The OLPC XO-1.75 device tree root is compatible with "mrvl,mmp2" only.
The "mrvl,mmp2-brownstone" string is safe to remove: the Brownstone
device tree contains the "mrvl,mmp2" compatible string too.
Signed-off-by: Lubomir Rintel
---
arch/arm/mach-mmp/mmp2-dt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 0341359b24a4..81232ecf08be 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -31,7 +31,7 @@ static void __init mmp_init_time(void)
}
static const char *const mmp2_dt_board_compat[] __initconst = {
- "mrvl,mmp2-brownstone",
+ "mrvl,mmp2",
NULL,
};
--
2.19.1
[PATCH] ARM: mmp2: DT: be compatible with mrvl,mmp2
There are more boards that can work with mmp2-dt than just Brownstone.
The OLPC XO-1.75 device tree root is compatible with "mrvl,mmp2" only.
The "mrvl,mmp2-brownstone" string is safe to remove: the Brownstone
device tree contains the "mrvl,mmp2" compatible string too.
Signed-off-by: Lubomir Rintel
---
arch/arm/mach-mmp/mmp2-dt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 0341359b24a4..81232ecf08be 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -31,7 +31,7 @@ static void __init mmp_init_time(void)
}
static const char *const mmp2_dt_board_compat[] __initconst = {
- "mrvl,mmp2-brownstone",
+ "mrvl,mmp2",
NULL,
};
--
2.19.1
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sat, Dec 1, 2018 at 5:48 PM Jonathan Cameron
wrote:
>
> On Sun, 25 Nov 2018 16:44:23 +0100
> Tomasz Duszynski wrote:
>
> > On Sun, Nov 25, 2018 at 06:14:44AM -0800, Matt Ranostay wrote:
> > > On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
> > > wrote:
> > > >
> > > > On Sun, 25 Nov 2018 05:51:32 -0800
> > > > Matt Ranostay wrote:
> > > >
> > > > > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski
> > > > > wrote:
> > > > > >
> > > > > > Measuring particulate matter in ug / m3 (micro-grams per cubic
> > > > > > meter)
> > > > > > is de facto standard. Existing air quality sensors usually follow
> > > > > > this convention and are capable of returning measurements using
> > > > > > this unit.
> > > > > >
> > > > > > IIO currently does not offer suitable channel type for this
> > > > > > type of measurements hence this patch adds this.
> > > > > >
> > > > > > In addition, two modifiers are introduced used for distinguishing
> > > > > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > > > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > > > > >
> > > > > > Signed-off-by: Tomasz Duszynski
> > > > > > ---
> > > > > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > > > > drivers/iio/industrialio-core.c | 3 +++
> > > > > > include/uapi/linux/iio/types.h | 3 +++
> > > > > > tools/iio/iio_event_monitor.c | 6 ++
> > > > > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > index 8127a08e366d..ce0ed140660d 100644
> > > > > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > > > > Contact: linux-...@vger.kernel.org
> > > > > > Description:
> > > > > > Raw (unscaled) phase difference reading from
> > > > > > channel Y
> > > > > > - that can be processed to radians.
> > > > > > \ No newline at end of file
> > > > > > + that can be processed to radians.
> > > > > > +
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > > > > +KernelVersion: 4.21
> > > > > > +Contact: linux-...@vger.kernel.org
> > > > > > +Description:
> > > > > > + Mass concentration reading of particulate matter in
> > > > > > ug / m3.
> > > > > > diff --git a/drivers/iio/industrialio-core.c
> > > > > > b/drivers/iio/industrialio-core.c
> > > > > > index a062cfddc5af..2a9ef600c1fb 100644
> > > > > > --- a/drivers/iio/industrialio-core.c
> > > > > > +++ b/drivers/iio/industrialio-core.c
> > > > > > @@ -87,6 +87,7 @@ static const char * const
> > > > > > iio_chan_type_name_spec[] = {
> > > > > > [IIO_GRAVITY] = "gravity",
> > > > > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > > > > [IIO_PHASE] = "phase",
> > > > > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > > > > };
> > > > > >
> > > > > > static const char * const iio_modifier_names[] = {
> > > > > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[]
> > > > > > = {
> > > > > > [IIO_MOD_Q] = "q",
> > > > > > [IIO_MOD_CO2] = "co2",
> > > > > > [IIO_MOD_VOC] = "voc",
> > > > > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > > > > + [IIO_MOD_PM10] = "pm10",
> > > > > > };
> > > > > >
> > > > > > /* relies on pairs of these shared then separate */
> > > > > > diff --git a/include/uapi/linux/iio/types.h
> > > > > > b/include/uapi/linux/iio/types.h
> > > > > > index 92baabc103ac..465044b42af5 100644
> > > > > > --- a/include/uapi/linux/iio/types.h
> > > > > > +++ b/include/uapi/linux/iio/types.h
> > > > > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > > > > IIO_GRAVITY,
> > > > > > IIO_POSITIONRELATIVE,
> > > > > > IIO_PHASE,
> > > > > > + IIO_MASSCONCENTRATION,
> > > > >
> > > > > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > > > > per cubic meter?
> > > >
> > > > Currently concentration is defined as a percentage reading of a
> > > > substance
> > > > (which does make me wonder if it is meant to be percentage of the
> > > > volume or
> > > > percentage of the mass?) Either way, if can't convert to a density
> > > > measurement
> > > > as it's a unit free ratio (I think).
> > >
> > > Seems like it can be both.. guessing all the atmosphere ( CO2, VOC,
> > > etc) ones are mass/density because on how they work.
> >
> > Hmm, but still percentage was picked up for
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sat, Dec 1, 2018 at 5:48 PM Jonathan Cameron
wrote:
>
> On Sun, 25 Nov 2018 16:44:23 +0100
> Tomasz Duszynski wrote:
>
> > On Sun, Nov 25, 2018 at 06:14:44AM -0800, Matt Ranostay wrote:
> > > On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
> > > wrote:
> > > >
> > > > On Sun, 25 Nov 2018 05:51:32 -0800
> > > > Matt Ranostay wrote:
> > > >
> > > > > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski
> > > > > wrote:
> > > > > >
> > > > > > Measuring particulate matter in ug / m3 (micro-grams per cubic
> > > > > > meter)
> > > > > > is de facto standard. Existing air quality sensors usually follow
> > > > > > this convention and are capable of returning measurements using
> > > > > > this unit.
> > > > > >
> > > > > > IIO currently does not offer suitable channel type for this
> > > > > > type of measurements hence this patch adds this.
> > > > > >
> > > > > > In addition, two modifiers are introduced used for distinguishing
> > > > > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > > > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > > > > >
> > > > > > Signed-off-by: Tomasz Duszynski
> > > > > > ---
> > > > > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > > > > drivers/iio/industrialio-core.c | 3 +++
> > > > > > include/uapi/linux/iio/types.h | 3 +++
> > > > > > tools/iio/iio_event_monitor.c | 6 ++
> > > > > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > index 8127a08e366d..ce0ed140660d 100644
> > > > > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > > > > Contact: linux-...@vger.kernel.org
> > > > > > Description:
> > > > > > Raw (unscaled) phase difference reading from
> > > > > > channel Y
> > > > > > - that can be processed to radians.
> > > > > > \ No newline at end of file
> > > > > > + that can be processed to radians.
> > > > > > +
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > > > > +KernelVersion: 4.21
> > > > > > +Contact: linux-...@vger.kernel.org
> > > > > > +Description:
> > > > > > + Mass concentration reading of particulate matter in
> > > > > > ug / m3.
> > > > > > diff --git a/drivers/iio/industrialio-core.c
> > > > > > b/drivers/iio/industrialio-core.c
> > > > > > index a062cfddc5af..2a9ef600c1fb 100644
> > > > > > --- a/drivers/iio/industrialio-core.c
> > > > > > +++ b/drivers/iio/industrialio-core.c
> > > > > > @@ -87,6 +87,7 @@ static const char * const
> > > > > > iio_chan_type_name_spec[] = {
> > > > > > [IIO_GRAVITY] = "gravity",
> > > > > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > > > > [IIO_PHASE] = "phase",
> > > > > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > > > > };
> > > > > >
> > > > > > static const char * const iio_modifier_names[] = {
> > > > > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[]
> > > > > > = {
> > > > > > [IIO_MOD_Q] = "q",
> > > > > > [IIO_MOD_CO2] = "co2",
> > > > > > [IIO_MOD_VOC] = "voc",
> > > > > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > > > > + [IIO_MOD_PM10] = "pm10",
> > > > > > };
> > > > > >
> > > > > > /* relies on pairs of these shared then separate */
> > > > > > diff --git a/include/uapi/linux/iio/types.h
> > > > > > b/include/uapi/linux/iio/types.h
> > > > > > index 92baabc103ac..465044b42af5 100644
> > > > > > --- a/include/uapi/linux/iio/types.h
> > > > > > +++ b/include/uapi/linux/iio/types.h
> > > > > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > > > > IIO_GRAVITY,
> > > > > > IIO_POSITIONRELATIVE,
> > > > > > IIO_PHASE,
> > > > > > + IIO_MASSCONCENTRATION,
> > > > >
> > > > > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > > > > per cubic meter?
> > > >
> > > > Currently concentration is defined as a percentage reading of a
> > > > substance
> > > > (which does make me wonder if it is meant to be percentage of the
> > > > volume or
> > > > percentage of the mass?) Either way, if can't convert to a density
> > > > measurement
> > > > as it's a unit free ratio (I think).
> > >
> > > Seems like it can be both.. guessing all the atmosphere ( CO2, VOC,
> > > etc) ones are mass/density because on how they work.
> >
> > Hmm, but still percentage was picked up for
Get passports, resident cards WhatsApp +19173008136 (puredocumentat...@gmail.com)
Get passports, resident cards WhatsApp +19173008136 (puredocumentat...@gmail.com) -- Sent from: http://linux-kernel.2935.n7.nabble.com/
Get passports, resident cards WhatsApp +19173008136 (puredocumentat...@gmail.com)
Another motivation to utilize Whatsapp..+1(917)-300-8136 a Netherlands Passports for Sale cover is close to home security. Enterprise travelers more often than not go to some remote spots where pickpockets and cheats are numerous. Covering your passport with a masterful and colorful plan will throw off would-be hoodlums on the grounds that your Netherlands passport is camouflaged as a book or some other sort of designer Netherlands passport for sale. Passports are hot things in underdeveloped nations and can get a high dollar sum on the underground market, making your passport a significant thing to neighborhood hooligans. At last, the third most imperative motivation to utilize a passport holder to cover your passport is refinement. Having a one can separate your passport from the group and spare you time as you experience different stations where your passport is gathered. This is particularly valid if traveling in a gathering or with family. Dealing with this and opening every one is a colossal agony and an exercise in futility. GENERAL SUPPORT: Contact E-mail. puredocumentat...@gmail.com whatsapp..+1(917)-300-8136 Kindly visit our site.. http://www.puredocumentation.com -- Sent from: http://linux-kernel.2935.n7.nabble.com/
Get passports, resident cards WhatsApp +19173008136 (puredocumentat...@gmail.com)
Get passports, resident cards WhatsApp +19173008136 (puredocumentat...@gmail.com) -- Sent from: http://linux-kernel.2935.n7.nabble.com/
Get passports, resident cards WhatsApp +19173008136 (puredocumentat...@gmail.com)
Another motivation to utilize Whatsapp..+1(917)-300-8136 a Netherlands Passports for Sale cover is close to home security. Enterprise travelers more often than not go to some remote spots where pickpockets and cheats are numerous. Covering your passport with a masterful and colorful plan will throw off would-be hoodlums on the grounds that your Netherlands passport is camouflaged as a book or some other sort of designer Netherlands passport for sale. Passports are hot things in underdeveloped nations and can get a high dollar sum on the underground market, making your passport a significant thing to neighborhood hooligans. At last, the third most imperative motivation to utilize a passport holder to cover your passport is refinement. Having a one can separate your passport from the group and spare you time as you experience different stations where your passport is gathered. This is particularly valid if traveling in a gathering or with family. Dealing with this and opening every one is a colossal agony and an exercise in futility. GENERAL SUPPORT: Contact E-mail. puredocumentat...@gmail.com whatsapp..+1(917)-300-8136 Kindly visit our site.. http://www.puredocumentation.com -- Sent from: http://linux-kernel.2935.n7.nabble.com/
Re: [PATCH] printk: Add caller information to printk() output.
On 2018/12/01 23:44, Tetsuo Handa wrote:
> On 2018/12/01 0:40, Petr Mladek wrote:
>>> Some examples for console output:
>>>
>>> [0.293000] [T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @
>>> 2.80GHz (family: 0x6, model: 0x3c, stepping: 0x3)
>>> [0.299733] [T1] Performance Events: Haswell events, core PMU driver.
>>> [2.813808] [T35] clocksource: Switched to clocksource tsc
>>> [2.893984] [C0] random: fast init done
>> ^
>>
>> Please, remove the space between the timestamp and the from field.
>
> This space was emitted by print_time(). Do we want to modify print_time()
> not to emit this space if the from field is printed?
>
> If we modify print_time(), I think that the leading spaces inserted by "%5lu"
> makes little sense, for "%5lu" is too small for systems with uptime >= 1.16
> days
> and parsers after all cannot assume fixed length for the timestamp field.
> Then,
> we could change from "%5lu.%06lu" to "%lu.%06lu" so that parsers (like
> /bin/awk)
> can get prefix part using white spaces as a delimiter.
>
> If we want to reduce space, do we want to do like
>
> [0.293000@T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @ 2.80GHz
> (family: 0x6, model: 0x3c, stepping: 0x3)
> [0.299733@T1] Performance Events: Haswell events, core PMU driver.
> [2.813808@T35] clocksource: Switched to clocksource tsc
> [2.893984@C0] random: fast init done
>
> (if printk_time = true) or
>
> [@T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @ 2.80GHz (family: 0x6,
> model: 0x3c, stepping: 0x3)
> [@T1] Performance Events: Haswell events, core PMU driver.
> [@T35] clocksource: Switched to clocksource tsc
> [@C0] random: fast init done
>
> (if printk_time = false) ?
>
> Dmitry, what format/delimiter is convenient for parsing by syzbot?
Here is an updated patch (which uses appropriate PREFIX_MAX definition
after "[PATCH v2] printk: fix printk_time race." is applied).
>From 48603394cc0c8c5ad9ee57bc665dfd2c421e923b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sun, 2 Dec 2018 19:41:02 +0900
Subject: [PATCH v2] printk: Add caller information to printk() output.
Sometimes we want to print a series of printk() messages to consoles
without being disturbed by concurrent printk() from interrupts and/or
other threads. But we can't enforce printk() callers to use their local
buffers because we need to ask them to make too much changes. Also, even
buffering up to one line inside printk() might cause failing to emit
an important clue under critical situation.
Therefore, instead of trying to help buffering, let's try to help
reconstructing messages by saving caller information as of calling
log_store() and adding it as "@T$thread_id" or "@C$processor_id" upon
printing to consoles.
Some examples for console output:
[0.919699]@T1 x86: Booting SMP configuration:
[4.152681]@T271 Fusion MPT base driver 3.04.20
[5.070470]@C0 random: fast init done
[6.587900]@C3 random: crng init done
# Not yet signed-off in order to silence build-bot error reports.
---
kernel/printk/printk.c | 62 ++
lib/Kconfig.debug | 17 ++
2 files changed, 54 insertions(+), 25 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 0b47e34..31151e8 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -356,6 +356,9 @@ struct printk_log {
u8 facility;/* syslog facility */
u8 flags:5; /* internal record flags */
u8 level:3; /* syslog level */
+#ifdef CONFIG_PRINTK_FROM
+ u32 from_id;/* thread id or processor id */
+#endif
}
#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
__packed __aligned(4)
@@ -422,8 +425,14 @@ __packed __aligned(4)
static u64 clear_seq;
static u32 clear_idx;
+#ifdef CONFIG_PRINTK_FROM
+#define PREFIX_FROM_MAX16
+#define PREFIX_MAX (32 + PREFIX_FROM_MAX)
+#define LOG_LINE_MAX (1024 - 32)
+#else
#define PREFIX_MAX 32
#define LOG_LINE_MAX (1024 - PREFIX_MAX)
+#endif
#define LOG_LEVEL(v) ((v) & 0x07)
#define LOG_FACILITY(v)((v) >> 3 & 0xff)
@@ -625,6 +634,12 @@ static int log_store(int facility, int level,
msg->ts_nsec = ts_nsec;
else
msg->ts_nsec = local_clock();
+#ifdef CONFIG_PRINTK_FROM
+ if (in_task())
+ msg->from_id = current->pid;
+ else
+ msg->from_id = 0x8000 + raw_smp_processor_id();
+#endif
memset(log_dict(msg) + dict_len, 0, pad_len);
msg->len = size;
@@ -1227,39 +1242,36 @@ static inline void boot_delay_msec(int level)
static bool printk_time = IS_ENABLED(CONFIG_PRINTK_TIME);
module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
-static size_t print_time(u64 ts, char *buf)
-{
- unsigned long rem_nsec = do_div(ts, 10);
-
- if
Re: [PATCH] printk: Add caller information to printk() output.
On 2018/12/01 23:44, Tetsuo Handa wrote:
> On 2018/12/01 0:40, Petr Mladek wrote:
>>> Some examples for console output:
>>>
>>> [0.293000] [T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @
>>> 2.80GHz (family: 0x6, model: 0x3c, stepping: 0x3)
>>> [0.299733] [T1] Performance Events: Haswell events, core PMU driver.
>>> [2.813808] [T35] clocksource: Switched to clocksource tsc
>>> [2.893984] [C0] random: fast init done
>> ^
>>
>> Please, remove the space between the timestamp and the from field.
>
> This space was emitted by print_time(). Do we want to modify print_time()
> not to emit this space if the from field is printed?
>
> If we modify print_time(), I think that the leading spaces inserted by "%5lu"
> makes little sense, for "%5lu" is too small for systems with uptime >= 1.16
> days
> and parsers after all cannot assume fixed length for the timestamp field.
> Then,
> we could change from "%5lu.%06lu" to "%lu.%06lu" so that parsers (like
> /bin/awk)
> can get prefix part using white spaces as a delimiter.
>
> If we want to reduce space, do we want to do like
>
> [0.293000@T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @ 2.80GHz
> (family: 0x6, model: 0x3c, stepping: 0x3)
> [0.299733@T1] Performance Events: Haswell events, core PMU driver.
> [2.813808@T35] clocksource: Switched to clocksource tsc
> [2.893984@C0] random: fast init done
>
> (if printk_time = true) or
>
> [@T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @ 2.80GHz (family: 0x6,
> model: 0x3c, stepping: 0x3)
> [@T1] Performance Events: Haswell events, core PMU driver.
> [@T35] clocksource: Switched to clocksource tsc
> [@C0] random: fast init done
>
> (if printk_time = false) ?
>
> Dmitry, what format/delimiter is convenient for parsing by syzbot?
Here is an updated patch (which uses appropriate PREFIX_MAX definition
after "[PATCH v2] printk: fix printk_time race." is applied).
>From 48603394cc0c8c5ad9ee57bc665dfd2c421e923b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sun, 2 Dec 2018 19:41:02 +0900
Subject: [PATCH v2] printk: Add caller information to printk() output.
Sometimes we want to print a series of printk() messages to consoles
without being disturbed by concurrent printk() from interrupts and/or
other threads. But we can't enforce printk() callers to use their local
buffers because we need to ask them to make too much changes. Also, even
buffering up to one line inside printk() might cause failing to emit
an important clue under critical situation.
Therefore, instead of trying to help buffering, let's try to help
reconstructing messages by saving caller information as of calling
log_store() and adding it as "@T$thread_id" or "@C$processor_id" upon
printing to consoles.
Some examples for console output:
[0.919699]@T1 x86: Booting SMP configuration:
[4.152681]@T271 Fusion MPT base driver 3.04.20
[5.070470]@C0 random: fast init done
[6.587900]@C3 random: crng init done
# Not yet signed-off in order to silence build-bot error reports.
---
kernel/printk/printk.c | 62 ++
lib/Kconfig.debug | 17 ++
2 files changed, 54 insertions(+), 25 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 0b47e34..31151e8 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -356,6 +356,9 @@ struct printk_log {
u8 facility;/* syslog facility */
u8 flags:5; /* internal record flags */
u8 level:3; /* syslog level */
+#ifdef CONFIG_PRINTK_FROM
+ u32 from_id;/* thread id or processor id */
+#endif
}
#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
__packed __aligned(4)
@@ -422,8 +425,14 @@ __packed __aligned(4)
static u64 clear_seq;
static u32 clear_idx;
+#ifdef CONFIG_PRINTK_FROM
+#define PREFIX_FROM_MAX16
+#define PREFIX_MAX (32 + PREFIX_FROM_MAX)
+#define LOG_LINE_MAX (1024 - 32)
+#else
#define PREFIX_MAX 32
#define LOG_LINE_MAX (1024 - PREFIX_MAX)
+#endif
#define LOG_LEVEL(v) ((v) & 0x07)
#define LOG_FACILITY(v)((v) >> 3 & 0xff)
@@ -625,6 +634,12 @@ static int log_store(int facility, int level,
msg->ts_nsec = ts_nsec;
else
msg->ts_nsec = local_clock();
+#ifdef CONFIG_PRINTK_FROM
+ if (in_task())
+ msg->from_id = current->pid;
+ else
+ msg->from_id = 0x8000 + raw_smp_processor_id();
+#endif
memset(log_dict(msg) + dict_len, 0, pad_len);
msg->len = size;
@@ -1227,39 +1242,36 @@ static inline void boot_delay_msec(int level)
static bool printk_time = IS_ENABLED(CONFIG_PRINTK_TIME);
module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
-static size_t print_time(u64 ts, char *buf)
-{
- unsigned long rem_nsec = do_div(ts, 10);
-
- if
linux-next: Signed-off-by missing for commit in the drm-msm tree
Hi Rob,
Commit
a288ee6eb8d0 ("drm/msm: validate display and event threads")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpBbmV9joR9Y.pgp
Description: OpenPGP digital signature
linux-next: Signed-off-by missing for commit in the drm-msm tree
Hi Rob,
Commit
a288ee6eb8d0 ("drm/msm: validate display and event threads")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpBbmV9joR9Y.pgp
Description: OpenPGP digital signature
[PATCH] MAINTAINERS: update entry for MMP platform
Move Eric Miao and Haojian Zhuang over to CREDITS, since they're AWOL for some time already. The git trees have gone away too. I'm adding myself as a reviewer. I'd like to be Cc'd on patches and will be able to test them, but I don't possess a data sheet thus there might be things I'll be unable to review. Hence the Odd-Fixes status. Signed-off-by: Lubomir Rintel --- CREDITS | 8 MAINTAINERS | 7 ++- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/CREDITS b/CREDITS index c9273393fe14..7d397ee67524 100644 --- a/CREDITS +++ b/CREDITS @@ -2541,6 +2541,10 @@ S: Ormond S: Victoria 3163 S: Australia +N: Eric Miao +E: eric.y.m...@gmail.com +D: MMP support + N: Pauline Middelink E: midde...@polyware.nl D: General low-level bug fixes, /proc fixes, identd support @@ -4115,6 +4119,10 @@ S: 1507 145th Place SE #B5 S: Bellevue, Washington 98007 S: USA +N: Haojian Zhuang +E: haojian.zhu...@gmail.com +D: MMP support + N: Richard Zidlicky E: r...@linux-m68k.org, rdzid...@geocities.com W: http://www.geocities.com/rdzidlic diff --git a/MAINTAINERS b/MAINTAINERS index 380e43f585d3..5741ed390432 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9940,12 +9940,9 @@ S: Odd Fixes F: drivers/media/radio/radio-miropcm20* MMP SUPPORT -M: Eric Miao -M: Haojian Zhuang +R: Lubomir Rintel L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -T: git git://github.com/hzhuang1/linux.git -T: git git://git.linaro.org/people/ycmiao/pxa-linux.git -S: Maintained +S: Odd Fixes F: arch/arm/boot/dts/mmp* F: arch/arm/mach-mmp/ -- 2.19.1
[PATCH] MAINTAINERS: update entry for MMP platform
Move Eric Miao and Haojian Zhuang over to CREDITS, since they're AWOL for some time already. The git trees have gone away too. I'm adding myself as a reviewer. I'd like to be Cc'd on patches and will be able to test them, but I don't possess a data sheet thus there might be things I'll be unable to review. Hence the Odd-Fixes status. Signed-off-by: Lubomir Rintel --- CREDITS | 8 MAINTAINERS | 7 ++- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/CREDITS b/CREDITS index c9273393fe14..7d397ee67524 100644 --- a/CREDITS +++ b/CREDITS @@ -2541,6 +2541,10 @@ S: Ormond S: Victoria 3163 S: Australia +N: Eric Miao +E: eric.y.m...@gmail.com +D: MMP support + N: Pauline Middelink E: midde...@polyware.nl D: General low-level bug fixes, /proc fixes, identd support @@ -4115,6 +4119,10 @@ S: 1507 145th Place SE #B5 S: Bellevue, Washington 98007 S: USA +N: Haojian Zhuang +E: haojian.zhu...@gmail.com +D: MMP support + N: Richard Zidlicky E: r...@linux-m68k.org, rdzid...@geocities.com W: http://www.geocities.com/rdzidlic diff --git a/MAINTAINERS b/MAINTAINERS index 380e43f585d3..5741ed390432 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9940,12 +9940,9 @@ S: Odd Fixes F: drivers/media/radio/radio-miropcm20* MMP SUPPORT -M: Eric Miao -M: Haojian Zhuang +R: Lubomir Rintel L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -T: git git://github.com/hzhuang1/linux.git -T: git git://git.linaro.org/people/ycmiao/pxa-linux.git -S: Maintained +S: Odd Fixes F: arch/arm/boot/dts/mmp* F: arch/arm/mach-mmp/ -- 2.19.1
[PATCH] ARM: mmp/mmp2: fix cpu_is_mmp2() on mmp2-dt
cpu_is_mmp2() was equivalent to cpu_is_pj4(), wouldn't be correct for
multiplatform kernels. Fix it by also considering mmp_chip_id, as is
done for cpu_is_pxa168() and cpu_is_pxa910() above.
Moreover, it is only available with CONFIG_CPU_MMP2 and thus doesn't work
on DT-based MMP2 machines. Enable it on CONFIG_MACH_MMP2_DT too.
Note: CONFIG_CPU_MMP2 is only used for machines that use board files
instead of DT. It should perhaps be renamed. I'm not doing it now, because
I don't have a better idea.
Signed-off-by: Lubomir Rintel
---
arch/arm/mach-mmp/cputype.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/cputype.h b/arch/arm/mach-mmp/cputype.h
index 446edaeb78a7..a96abcf521b4 100644
--- a/arch/arm/mach-mmp/cputype.h
+++ b/arch/arm/mach-mmp/cputype.h
@@ -44,10 +44,12 @@ static inline int cpu_is_pxa910(void)
#define cpu_is_pxa910()(0)
#endif
-#ifdef CONFIG_CPU_MMP2
+#if defined(CONFIG_CPU_MMP2) || defined(CONFIG_MACH_MMP2_DT)
static inline int cpu_is_mmp2(void)
{
- return (((read_cpuid_id() >> 8) & 0xff) == 0x58);
+ return (((read_cpuid_id() >> 8) & 0xff) == 0x58) &&
+ (((mmp_chip_id & 0xfff) == 0x410) ||
+((mmp_chip_id & 0xfff) == 0x610));
}
#else
#define cpu_is_mmp2() (0)
--
2.19.1
[PATCH] ARM: mmp/mmp2: fix cpu_is_mmp2() on mmp2-dt
cpu_is_mmp2() was equivalent to cpu_is_pj4(), wouldn't be correct for
multiplatform kernels. Fix it by also considering mmp_chip_id, as is
done for cpu_is_pxa168() and cpu_is_pxa910() above.
Moreover, it is only available with CONFIG_CPU_MMP2 and thus doesn't work
on DT-based MMP2 machines. Enable it on CONFIG_MACH_MMP2_DT too.
Note: CONFIG_CPU_MMP2 is only used for machines that use board files
instead of DT. It should perhaps be renamed. I'm not doing it now, because
I don't have a better idea.
Signed-off-by: Lubomir Rintel
---
arch/arm/mach-mmp/cputype.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/cputype.h b/arch/arm/mach-mmp/cputype.h
index 446edaeb78a7..a96abcf521b4 100644
--- a/arch/arm/mach-mmp/cputype.h
+++ b/arch/arm/mach-mmp/cputype.h
@@ -44,10 +44,12 @@ static inline int cpu_is_pxa910(void)
#define cpu_is_pxa910()(0)
#endif
-#ifdef CONFIG_CPU_MMP2
+#if defined(CONFIG_CPU_MMP2) || defined(CONFIG_MACH_MMP2_DT)
static inline int cpu_is_mmp2(void)
{
- return (((read_cpuid_id() >> 8) & 0xff) == 0x58);
+ return (((read_cpuid_id() >> 8) & 0xff) == 0x58) &&
+ (((mmp_chip_id & 0xfff) == 0x410) ||
+((mmp_chip_id & 0xfff) == 0x610));
}
#else
#define cpu_is_mmp2() (0)
--
2.19.1
Re: [PATCH v6 1/2] misc: cardreader: add new Alcor Micro Cardreader PCI driver
Am 02.12.18 um 11:30 schrieb Oleksij Rempel: > This driver provides support for Alcor Micro AU6601 and AU6621 > card readers. > > This is single LUN HW and it is expected to work with following standards: > - Support SDR104 / SDR50 > - MultiMedia Card (MMC) > - Memory Stick (MS) > - Memory Stick PRO (MS_Pro) > > Since it is a PCIe controller, it should work on any architecture > supporting PCIe. For now, it was developed and tested only on x86_64. > > This driver is a result of RE work and was created without any > documentation or real knowledge of HW internals. > > Signed-off-by: Oleksij Rempel Forgot to add a changelog for this patchset: 20181202 v6: - split one patch to two patches: cardreader and mmc - use SIMPLE_DEV_PM_OPS in mmc driver - use ida_simple_get/remove - move DRV_NAME_ALCOR_PCI to cardreader driver. Other defines are shared between drivers. - fix some typos - rebase against 4.20-rc4 and test it. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Re: [PATCH v6 1/2] misc: cardreader: add new Alcor Micro Cardreader PCI driver
Am 02.12.18 um 11:30 schrieb Oleksij Rempel: > This driver provides support for Alcor Micro AU6601 and AU6621 > card readers. > > This is single LUN HW and it is expected to work with following standards: > - Support SDR104 / SDR50 > - MultiMedia Card (MMC) > - Memory Stick (MS) > - Memory Stick PRO (MS_Pro) > > Since it is a PCIe controller, it should work on any architecture > supporting PCIe. For now, it was developed and tested only on x86_64. > > This driver is a result of RE work and was created without any > documentation or real knowledge of HW internals. > > Signed-off-by: Oleksij Rempel Forgot to add a changelog for this patchset: 20181202 v6: - split one patch to two patches: cardreader and mmc - use SIMPLE_DEV_PM_OPS in mmc driver - use ida_simple_get/remove - move DRV_NAME_ALCOR_PCI to cardreader driver. Other defines are shared between drivers. - fix some typos - rebase against 4.20-rc4 and test it. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
[PATCH v6 1/2] misc: cardreader: add new Alcor Micro Cardreader PCI driver
This driver provides support for Alcor Micro AU6601 and AU6621
card readers.
This is single LUN HW and it is expected to work with following standards:
- Support SDR104 / SDR50
- MultiMedia Card (MMC)
- Memory Stick (MS)
- Memory Stick PRO (MS_Pro)
Since it is a PCIe controller, it should work on any architecture
supporting PCIe. For now, it was developed and tested only on x86_64.
This driver is a result of RE work and was created without any
documentation or real knowledge of HW internals.
Signed-off-by: Oleksij Rempel
---
drivers/misc/Makefile | 2 +-
drivers/misc/cardreader/Kconfig | 11 +
drivers/misc/cardreader/Makefile| 4 +-
drivers/misc/cardreader/alcor_pci.c | 371
include/linux/alcor_pci.h | 286 +
5 files changed, 671 insertions(+), 3 deletions(-)
create mode 100644 drivers/misc/cardreader/alcor_pci.c
create mode 100644 include/linux/alcor_pci.h
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index af22bbc3d00c..fe3134cf3008 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,4 +57,4 @@ obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
obj-$(CONFIG_OCXL) += ocxl/
-obj-$(CONFIG_MISC_RTSX)+= cardreader/
+obj-y += cardreader/
diff --git a/drivers/misc/cardreader/Kconfig b/drivers/misc/cardreader/Kconfig
index 69e815e32a8c..ed8993b5d058 100644
--- a/drivers/misc/cardreader/Kconfig
+++ b/drivers/misc/cardreader/Kconfig
@@ -1,3 +1,14 @@
+config MISC_ALCOR_PCI
+ tristate "Alcor Micro/Alcor Link PCI-E card reader"
+ depends on PCI
+ select MFD_CORE
+ help
+ This supports for Alcor Micro PCI-Express card reader including
au6601,
+ au6621.
+ Alcor Micro card readers support access to many types of memory cards,
+ such as Memory Stick, Memory Stick Pro, Secure Digital and
+ MultiMediaCard.
+
config MISC_RTSX_PCI
tristate "Realtek PCI-E card reader"
depends on PCI
diff --git a/drivers/misc/cardreader/Makefile b/drivers/misc/cardreader/Makefile
index 9fabfcc6fa7a..9882d2a1025c 100644
--- a/drivers/misc/cardreader/Makefile
+++ b/drivers/misc/cardreader/Makefile
@@ -1,4 +1,4 @@
-rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o rts5227.o rts5249.o
rts5260.o
-
+obj-$(CONFIG_MISC_ALCOR_PCI) += alcor_pci.o
obj-$(CONFIG_MISC_RTSX_PCI)+= rtsx_pci.o
+rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o rts5227.o rts5249.o
rts5260.o
obj-$(CONFIG_MISC_RTSX_USB)+= rtsx_usb.o
diff --git a/drivers/misc/cardreader/alcor_pci.c
b/drivers/misc/cardreader/alcor_pci.c
new file mode 100644
index ..6872b8e29b4d
--- /dev/null
+++ b/drivers/misc/cardreader/alcor_pci.c
@@ -0,0 +1,371 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Oleksij Rempel
+ *
+ * Driver for Alcor Micro AU6601 and AU6621 controllers
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define DRV_NAME_ALCOR_PCI "alcor_pci"
+
+static DEFINE_IDA(alcor_pci_idr);
+
+static struct mfd_cell alcor_pci_cells[] = {
+ [ALCOR_SD_CARD] = {
+ .name = DRV_NAME_ALCOR_PCI_SDMMC,
+ },
+ [ALCOR_MS_CARD] = {
+ .name = DRV_NAME_ALCOR_PCI_MS,
+ },
+};
+
+static const struct alcor_dev_cfg alcor_cfg = {
+ .dma = 0,
+};
+
+static const struct alcor_dev_cfg au6621_cfg = {
+ .dma = 1,
+};
+
+static const struct pci_device_id pci_ids[] = {
+ { PCI_DEVICE(PCI_ID_ALCOR_MICRO, PCI_ID_AU6601),
+ .driver_data = (kernel_ulong_t)_cfg },
+ { PCI_DEVICE(PCI_ID_ALCOR_MICRO, PCI_ID_AU6621),
+ .driver_data = (kernel_ulong_t)_cfg },
+ { },
+};
+MODULE_DEVICE_TABLE(pci, pci_ids);
+
+void alcor_write8(struct alcor_pci_priv *priv, u8 val, unsigned int addr)
+{
+ writeb(val, priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_write8);
+
+void alcor_write16(struct alcor_pci_priv *priv, u16 val, unsigned int addr)
+{
+ writew(val, priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_write16);
+
+void alcor_write32(struct alcor_pci_priv *priv, u32 val, unsigned int addr)
+{
+ writel(val, priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_write32);
+
+void alcor_write32be(struct alcor_pci_priv *priv, u32 val, unsigned int addr)
+{
+ iowrite32be(val, priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_write32be);
+
+u8 alcor_read8(struct alcor_pci_priv *priv, unsigned int addr)
+{
+ return readb(priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_read8);
+
+u32 alcor_read32(struct alcor_pci_priv *priv, unsigned int addr)
+{
+ return readl(priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_read32);
+
+u32 alcor_read32be(struct alcor_pci_priv *priv, unsigned int addr)
+{
+
[PATCH v6 1/2] misc: cardreader: add new Alcor Micro Cardreader PCI driver
This driver provides support for Alcor Micro AU6601 and AU6621
card readers.
This is single LUN HW and it is expected to work with following standards:
- Support SDR104 / SDR50
- MultiMedia Card (MMC)
- Memory Stick (MS)
- Memory Stick PRO (MS_Pro)
Since it is a PCIe controller, it should work on any architecture
supporting PCIe. For now, it was developed and tested only on x86_64.
This driver is a result of RE work and was created without any
documentation or real knowledge of HW internals.
Signed-off-by: Oleksij Rempel
---
drivers/misc/Makefile | 2 +-
drivers/misc/cardreader/Kconfig | 11 +
drivers/misc/cardreader/Makefile| 4 +-
drivers/misc/cardreader/alcor_pci.c | 371
include/linux/alcor_pci.h | 286 +
5 files changed, 671 insertions(+), 3 deletions(-)
create mode 100644 drivers/misc/cardreader/alcor_pci.c
create mode 100644 include/linux/alcor_pci.h
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index af22bbc3d00c..fe3134cf3008 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,4 +57,4 @@ obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
obj-$(CONFIG_OCXL) += ocxl/
-obj-$(CONFIG_MISC_RTSX)+= cardreader/
+obj-y += cardreader/
diff --git a/drivers/misc/cardreader/Kconfig b/drivers/misc/cardreader/Kconfig
index 69e815e32a8c..ed8993b5d058 100644
--- a/drivers/misc/cardreader/Kconfig
+++ b/drivers/misc/cardreader/Kconfig
@@ -1,3 +1,14 @@
+config MISC_ALCOR_PCI
+ tristate "Alcor Micro/Alcor Link PCI-E card reader"
+ depends on PCI
+ select MFD_CORE
+ help
+ This supports for Alcor Micro PCI-Express card reader including
au6601,
+ au6621.
+ Alcor Micro card readers support access to many types of memory cards,
+ such as Memory Stick, Memory Stick Pro, Secure Digital and
+ MultiMediaCard.
+
config MISC_RTSX_PCI
tristate "Realtek PCI-E card reader"
depends on PCI
diff --git a/drivers/misc/cardreader/Makefile b/drivers/misc/cardreader/Makefile
index 9fabfcc6fa7a..9882d2a1025c 100644
--- a/drivers/misc/cardreader/Makefile
+++ b/drivers/misc/cardreader/Makefile
@@ -1,4 +1,4 @@
-rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o rts5227.o rts5249.o
rts5260.o
-
+obj-$(CONFIG_MISC_ALCOR_PCI) += alcor_pci.o
obj-$(CONFIG_MISC_RTSX_PCI)+= rtsx_pci.o
+rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o rts5227.o rts5249.o
rts5260.o
obj-$(CONFIG_MISC_RTSX_USB)+= rtsx_usb.o
diff --git a/drivers/misc/cardreader/alcor_pci.c
b/drivers/misc/cardreader/alcor_pci.c
new file mode 100644
index ..6872b8e29b4d
--- /dev/null
+++ b/drivers/misc/cardreader/alcor_pci.c
@@ -0,0 +1,371 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Oleksij Rempel
+ *
+ * Driver for Alcor Micro AU6601 and AU6621 controllers
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define DRV_NAME_ALCOR_PCI "alcor_pci"
+
+static DEFINE_IDA(alcor_pci_idr);
+
+static struct mfd_cell alcor_pci_cells[] = {
+ [ALCOR_SD_CARD] = {
+ .name = DRV_NAME_ALCOR_PCI_SDMMC,
+ },
+ [ALCOR_MS_CARD] = {
+ .name = DRV_NAME_ALCOR_PCI_MS,
+ },
+};
+
+static const struct alcor_dev_cfg alcor_cfg = {
+ .dma = 0,
+};
+
+static const struct alcor_dev_cfg au6621_cfg = {
+ .dma = 1,
+};
+
+static const struct pci_device_id pci_ids[] = {
+ { PCI_DEVICE(PCI_ID_ALCOR_MICRO, PCI_ID_AU6601),
+ .driver_data = (kernel_ulong_t)_cfg },
+ { PCI_DEVICE(PCI_ID_ALCOR_MICRO, PCI_ID_AU6621),
+ .driver_data = (kernel_ulong_t)_cfg },
+ { },
+};
+MODULE_DEVICE_TABLE(pci, pci_ids);
+
+void alcor_write8(struct alcor_pci_priv *priv, u8 val, unsigned int addr)
+{
+ writeb(val, priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_write8);
+
+void alcor_write16(struct alcor_pci_priv *priv, u16 val, unsigned int addr)
+{
+ writew(val, priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_write16);
+
+void alcor_write32(struct alcor_pci_priv *priv, u32 val, unsigned int addr)
+{
+ writel(val, priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_write32);
+
+void alcor_write32be(struct alcor_pci_priv *priv, u32 val, unsigned int addr)
+{
+ iowrite32be(val, priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_write32be);
+
+u8 alcor_read8(struct alcor_pci_priv *priv, unsigned int addr)
+{
+ return readb(priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_read8);
+
+u32 alcor_read32(struct alcor_pci_priv *priv, unsigned int addr)
+{
+ return readl(priv->iobase + addr);
+}
+EXPORT_SYMBOL_GPL(alcor_read32);
+
+u32 alcor_read32be(struct alcor_pci_priv *priv, unsigned int addr)
+{
+
[PATCH v6 2/2] mmc: add new Alcor Micro Cardreader SD/MMC driver
This driver provides support for Alcor Micro AU6601 and AU6621
SD/MMC controller.
Signed-off-by: Oleksij Rempel
---
drivers/mmc/host/Kconfig |7 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/alcor.c | 1165 +
3 files changed, 1173 insertions(+)
create mode 100644 drivers/mmc/host/alcor.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1b58739d9744..e64e5a59387f 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -441,6 +441,13 @@ config MMC_WBSD
If unsure, say N.
+config MMC_ALCOR
+ tristate "Alcor Micro/Alcor Link SD/MMC controller"
+ depends on MISC_ALCOR_PCI
+ help
+ Say Y here to include driver code to support SD/MMC card interface
+ of Alcor Micro PCI-E card reader
+
config MMC_AU1X
tristate "Alchemy AU1XX0 MMC Card Interface support"
depends on MIPS_ALCHEMY
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 720d3098..0a38e654a2ce 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_MMC_SDHCI_F_SDH30) += sdhci_f_sdh30.o
obj-$(CONFIG_MMC_SDHCI_SPEAR) += sdhci-spear.o
obj-$(CONFIG_MMC_WBSD) += wbsd.o
obj-$(CONFIG_MMC_AU1X) += au1xmmc.o
+obj-$(CONFIG_MMC_ALCOR)+= alcor.o
obj-$(CONFIG_MMC_MTK) += mtk-sd.o
obj-$(CONFIG_MMC_OMAP) += omap.o
obj-$(CONFIG_MMC_OMAP_HS) += omap_hsmmc.o
diff --git a/drivers/mmc/host/alcor.c b/drivers/mmc/host/alcor.c
new file mode 100644
index ..f729a649d7c0
--- /dev/null
+++ b/drivers/mmc/host/alcor.c
@@ -0,0 +1,1165 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Oleksij Rempel
+ *
+ * Driver for Alcor Micro AU6601 and AU6621 controllers
+ */
+
+/* Note: this driver was created without any documentation. Based
+ * on sniffing, testing and in some cases mimic of original driver.
+ * As soon as some one with documentation or more experience in SD/MMC, or
+ * reverse engineering then me, please review this driver and question every
+ * thing what I did. 2018 Oleksij Rempel
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+enum alcor_cookie {
+ COOKIE_UNMAPPED,
+ COOKIE_PRE_MAPPED,
+ COOKIE_MAPPED,
+};
+
+struct alcor_pll_conf {
+ unsigned int clk_src_freq;
+ unsigned int clk_src_reg;
+ unsigned int min_div;
+ unsigned int max_div;
+};
+
+struct alcor_sdmmc_host {
+ struct device *dev;
+ struct alcor_pci_priv *alcor_pci;
+
+ struct mmc_host *mmc;
+ struct mmc_request *mrq;
+ struct mmc_command *cmd;
+ struct mmc_data *data;
+ unsigned int dma_on:1;
+ unsigned int early_data:1;
+
+ struct mutex cmd_mutex;
+
+ struct delayed_work timeout_work;
+
+ struct sg_mapping_iter sg_miter;/* SG state for PIO */
+ struct scatterlist *sg;
+ unsigned int blocks;/* remaining PIO blocks */
+ int sg_count;
+
+ u32 irq_status_sd;
+ unsigned char cur_power_mode;
+};
+
+static const struct alcor_pll_conf alcor_pll_cfg[] = {
+ /* MHZ, CLK src,max div, min div */
+ { 3125, AU6601_CLK_31_25_MHZ, 1, 511},
+ { 4800, AU6601_CLK_48_MHZ, 1, 511},
+ {12500, AU6601_CLK_125_MHZ, 1, 511},
+ {38400, AU6601_CLK_384_MHZ, 1, 511},
+};
+
+static inline void alcor_rmw8(struct alcor_sdmmc_host *host, unsigned int addr,
+ u8 clear, u8 set)
+{
+ struct alcor_pci_priv *priv = host->alcor_pci;
+ u32 var;
+
+ var = alcor_read8(priv, addr);
+ var &= ~clear;
+ var |= set;
+ alcor_write8(priv, var, addr);
+}
+
+/* As soon as irqs are masked, some status updates may be missed.
+ * Use this with care.
+ */
+static inline void alcor_mask_sd_irqs(struct alcor_sdmmc_host *host)
+{
+ struct alcor_pci_priv *priv = host->alcor_pci;
+
+ alcor_write32(priv, 0, AU6601_REG_INT_ENABLE);
+}
+
+static inline void alcor_unmask_sd_irqs(struct alcor_sdmmc_host *host)
+{
+ struct alcor_pci_priv *priv = host->alcor_pci;
+
+ alcor_write32(priv, AU6601_INT_CMD_MASK | AU6601_INT_DATA_MASK |
+ AU6601_INT_CARD_INSERT | AU6601_INT_CARD_REMOVE |
+ AU6601_INT_OVER_CURRENT_ERR,
+ AU6601_REG_INT_ENABLE);
+}
+
+static void alcor_reset(struct alcor_sdmmc_host *host, u8 val)
+{
+ struct alcor_pci_priv *priv = host->alcor_pci;
+ int i;
+
+ alcor_write8(priv, val | AU6601_BUF_CTRL_RESET,
+ AU6601_REG_SW_RESET);
+ for (i = 0; i < 100; i++) {
+ if (!(alcor_read8(priv, AU6601_REG_SW_RESET) & val))
+ return;
+ udelay(50);
+
[PATCH v6 2/2] mmc: add new Alcor Micro Cardreader SD/MMC driver
This driver provides support for Alcor Micro AU6601 and AU6621
SD/MMC controller.
Signed-off-by: Oleksij Rempel
---
drivers/mmc/host/Kconfig |7 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/alcor.c | 1165 +
3 files changed, 1173 insertions(+)
create mode 100644 drivers/mmc/host/alcor.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1b58739d9744..e64e5a59387f 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -441,6 +441,13 @@ config MMC_WBSD
If unsure, say N.
+config MMC_ALCOR
+ tristate "Alcor Micro/Alcor Link SD/MMC controller"
+ depends on MISC_ALCOR_PCI
+ help
+ Say Y here to include driver code to support SD/MMC card interface
+ of Alcor Micro PCI-E card reader
+
config MMC_AU1X
tristate "Alchemy AU1XX0 MMC Card Interface support"
depends on MIPS_ALCHEMY
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 720d3098..0a38e654a2ce 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_MMC_SDHCI_F_SDH30) += sdhci_f_sdh30.o
obj-$(CONFIG_MMC_SDHCI_SPEAR) += sdhci-spear.o
obj-$(CONFIG_MMC_WBSD) += wbsd.o
obj-$(CONFIG_MMC_AU1X) += au1xmmc.o
+obj-$(CONFIG_MMC_ALCOR)+= alcor.o
obj-$(CONFIG_MMC_MTK) += mtk-sd.o
obj-$(CONFIG_MMC_OMAP) += omap.o
obj-$(CONFIG_MMC_OMAP_HS) += omap_hsmmc.o
diff --git a/drivers/mmc/host/alcor.c b/drivers/mmc/host/alcor.c
new file mode 100644
index ..f729a649d7c0
--- /dev/null
+++ b/drivers/mmc/host/alcor.c
@@ -0,0 +1,1165 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Oleksij Rempel
+ *
+ * Driver for Alcor Micro AU6601 and AU6621 controllers
+ */
+
+/* Note: this driver was created without any documentation. Based
+ * on sniffing, testing and in some cases mimic of original driver.
+ * As soon as some one with documentation or more experience in SD/MMC, or
+ * reverse engineering then me, please review this driver and question every
+ * thing what I did. 2018 Oleksij Rempel
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+enum alcor_cookie {
+ COOKIE_UNMAPPED,
+ COOKIE_PRE_MAPPED,
+ COOKIE_MAPPED,
+};
+
+struct alcor_pll_conf {
+ unsigned int clk_src_freq;
+ unsigned int clk_src_reg;
+ unsigned int min_div;
+ unsigned int max_div;
+};
+
+struct alcor_sdmmc_host {
+ struct device *dev;
+ struct alcor_pci_priv *alcor_pci;
+
+ struct mmc_host *mmc;
+ struct mmc_request *mrq;
+ struct mmc_command *cmd;
+ struct mmc_data *data;
+ unsigned int dma_on:1;
+ unsigned int early_data:1;
+
+ struct mutex cmd_mutex;
+
+ struct delayed_work timeout_work;
+
+ struct sg_mapping_iter sg_miter;/* SG state for PIO */
+ struct scatterlist *sg;
+ unsigned int blocks;/* remaining PIO blocks */
+ int sg_count;
+
+ u32 irq_status_sd;
+ unsigned char cur_power_mode;
+};
+
+static const struct alcor_pll_conf alcor_pll_cfg[] = {
+ /* MHZ, CLK src,max div, min div */
+ { 3125, AU6601_CLK_31_25_MHZ, 1, 511},
+ { 4800, AU6601_CLK_48_MHZ, 1, 511},
+ {12500, AU6601_CLK_125_MHZ, 1, 511},
+ {38400, AU6601_CLK_384_MHZ, 1, 511},
+};
+
+static inline void alcor_rmw8(struct alcor_sdmmc_host *host, unsigned int addr,
+ u8 clear, u8 set)
+{
+ struct alcor_pci_priv *priv = host->alcor_pci;
+ u32 var;
+
+ var = alcor_read8(priv, addr);
+ var &= ~clear;
+ var |= set;
+ alcor_write8(priv, var, addr);
+}
+
+/* As soon as irqs are masked, some status updates may be missed.
+ * Use this with care.
+ */
+static inline void alcor_mask_sd_irqs(struct alcor_sdmmc_host *host)
+{
+ struct alcor_pci_priv *priv = host->alcor_pci;
+
+ alcor_write32(priv, 0, AU6601_REG_INT_ENABLE);
+}
+
+static inline void alcor_unmask_sd_irqs(struct alcor_sdmmc_host *host)
+{
+ struct alcor_pci_priv *priv = host->alcor_pci;
+
+ alcor_write32(priv, AU6601_INT_CMD_MASK | AU6601_INT_DATA_MASK |
+ AU6601_INT_CARD_INSERT | AU6601_INT_CARD_REMOVE |
+ AU6601_INT_OVER_CURRENT_ERR,
+ AU6601_REG_INT_ENABLE);
+}
+
+static void alcor_reset(struct alcor_sdmmc_host *host, u8 val)
+{
+ struct alcor_pci_priv *priv = host->alcor_pci;
+ int i;
+
+ alcor_write8(priv, val | AU6601_BUF_CTRL_RESET,
+ AU6601_REG_SW_RESET);
+ for (i = 0; i < 100; i++) {
+ if (!(alcor_read8(priv, AU6601_REG_SW_RESET) & val))
+ return;
+ udelay(50);
+
Re: [PATCH v2 06/15] m68k: define syscall_get_arch()
Hi Dmitry,
On Tue, Nov 20, 2018 at 1:15 AM Dmitry V. Levin wrote:
> syscall_get_arch() is required to be implemented on all architectures
> in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
> request.
>
> Signed-off-by: Dmitry V. Levin
Reviewed-by: Geert Uytterhoeven
What's your plan w.r.t. the upstreaming strategy?
Do you plan to get this series in as a whole, or through individual architecture
maintainers?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 06/15] m68k: define syscall_get_arch()
Hi Dmitry,
On Tue, Nov 20, 2018 at 1:15 AM Dmitry V. Levin wrote:
> syscall_get_arch() is required to be implemented on all architectures
> in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
> request.
>
> Signed-off-by: Dmitry V. Levin
Reviewed-by: Geert Uytterhoeven
What's your plan w.r.t. the upstreaming strategy?
Do you plan to get this series in as a whole, or through individual architecture
maintainers?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] pinctrl: sx150x: handle failure case of devm_kstrdup
devm_kstrdup() may return NULL if internal allocation failed.
Thus using label, name is unsafe without checking. Therefor
in the unlikely case of allocation failure, sx150x_probe() simply
returns -ENOMEM.
Signed-off-by: Nicholas Mc Guire
Fixes: 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver")
---
Problem located with an experimental coccinelle script
Patch was compile tested with: lpc32xx_defconfig (implies PINCTRL_SX150X=y)
Note that while lpc32xx_defconfig contains PINCTRL_SX150X=y after make
lpc32xx_defconfig it is *not* set - seems to be a missing entry in
drivers/pincrtl/Kconfig - so PINCRTL and PINCTRL_SX150X had to be
manually enabled.
Patch is against 4.20-rc4 (localversion-next is next-20181130)
drivers/pinctrl/pinctrl-sx150x.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index cbf58a1..4d87d75 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -1166,7 +1166,6 @@ static int sx150x_probe(struct i2c_client *client,
}
/* Register GPIO controller */
- pctl->gpio.label = devm_kstrdup(dev, client->name, GFP_KERNEL);
pctl->gpio.base = -1;
pctl->gpio.ngpio = pctl->data->npins;
pctl->gpio.get_direction = sx150x_gpio_get_direction;
@@ -1180,6 +1179,10 @@ static int sx150x_probe(struct i2c_client *client,
pctl->gpio.of_node = dev->of_node;
#endif
pctl->gpio.can_sleep = true;
+ pctl->gpio.label = devm_kstrdup(dev, client->name, GFP_KERNEL);
+ if (!pctl->gpio.label)
+ return -ENOMEM;
+
/*
* Setting multiple pins is not safe when all pins are not
* handled by the same regmap register. The oscio pin (present
@@ -1200,13 +1203,15 @@ static int sx150x_probe(struct i2c_client *client,
/* Add Interrupt support if an irq is specified */
if (client->irq > 0) {
- pctl->irq_chip.name = devm_kstrdup(dev, client->name,
- GFP_KERNEL);
pctl->irq_chip.irq_mask = sx150x_irq_mask;
pctl->irq_chip.irq_unmask = sx150x_irq_unmask;
pctl->irq_chip.irq_set_type = sx150x_irq_set_type;
pctl->irq_chip.irq_bus_lock = sx150x_irq_bus_lock;
pctl->irq_chip.irq_bus_sync_unlock = sx150x_irq_bus_sync_unlock;
+ pctl->irq_chip.name = devm_kstrdup(dev, client->name,
+ GFP_KERNEL);
+ if (!pctl->irq_chip.name)
+ return -ENOMEM;
pctl->irq.masked = ~0;
pctl->irq.sense = 0;
--
2.1.4
[PATCH] pinctrl: sx150x: handle failure case of devm_kstrdup
devm_kstrdup() may return NULL if internal allocation failed.
Thus using label, name is unsafe without checking. Therefor
in the unlikely case of allocation failure, sx150x_probe() simply
returns -ENOMEM.
Signed-off-by: Nicholas Mc Guire
Fixes: 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver")
---
Problem located with an experimental coccinelle script
Patch was compile tested with: lpc32xx_defconfig (implies PINCTRL_SX150X=y)
Note that while lpc32xx_defconfig contains PINCTRL_SX150X=y after make
lpc32xx_defconfig it is *not* set - seems to be a missing entry in
drivers/pincrtl/Kconfig - so PINCRTL and PINCTRL_SX150X had to be
manually enabled.
Patch is against 4.20-rc4 (localversion-next is next-20181130)
drivers/pinctrl/pinctrl-sx150x.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index cbf58a1..4d87d75 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -1166,7 +1166,6 @@ static int sx150x_probe(struct i2c_client *client,
}
/* Register GPIO controller */
- pctl->gpio.label = devm_kstrdup(dev, client->name, GFP_KERNEL);
pctl->gpio.base = -1;
pctl->gpio.ngpio = pctl->data->npins;
pctl->gpio.get_direction = sx150x_gpio_get_direction;
@@ -1180,6 +1179,10 @@ static int sx150x_probe(struct i2c_client *client,
pctl->gpio.of_node = dev->of_node;
#endif
pctl->gpio.can_sleep = true;
+ pctl->gpio.label = devm_kstrdup(dev, client->name, GFP_KERNEL);
+ if (!pctl->gpio.label)
+ return -ENOMEM;
+
/*
* Setting multiple pins is not safe when all pins are not
* handled by the same regmap register. The oscio pin (present
@@ -1200,13 +1203,15 @@ static int sx150x_probe(struct i2c_client *client,
/* Add Interrupt support if an irq is specified */
if (client->irq > 0) {
- pctl->irq_chip.name = devm_kstrdup(dev, client->name,
- GFP_KERNEL);
pctl->irq_chip.irq_mask = sx150x_irq_mask;
pctl->irq_chip.irq_unmask = sx150x_irq_unmask;
pctl->irq_chip.irq_set_type = sx150x_irq_set_type;
pctl->irq_chip.irq_bus_lock = sx150x_irq_bus_lock;
pctl->irq_chip.irq_bus_sync_unlock = sx150x_irq_bus_sync_unlock;
+ pctl->irq_chip.name = devm_kstrdup(dev, client->name,
+ GFP_KERNEL);
+ if (!pctl->irq_chip.name)
+ return -ENOMEM;
pctl->irq.masked = ~0;
pctl->irq.sense = 0;
--
2.1.4
Re: [PATCH v2] signal: add procfd_signal() syscall
On Sat, Dec 01, 2018 at 12:52:24PM +1300, Christian Brauner wrote:
> On November 30, 2018 1:28:15 AM GMT+13:00, Florian Weimer
> wrote:
> >Disclaimer: I'm looking at this patch because Christian requested it.
> >I'm not a kernel developer.
>
> Given all your expertise this really doesn't matter. :)
> You're the one having to deal with this
> in glibc after all.
> Thanks for doing this and sorry for the late reply.
> I missed that mail.
>
> >
> >* Christian Brauner:
> >
> >> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
> >b/arch/x86/entry/syscalls/syscall_32.tbl
> >> index 3cf7b533b3d1..3f27ffd8ae87 100644
> >> --- a/arch/x86/entry/syscalls/syscall_32.tbl
> >> +++ b/arch/x86/entry/syscalls/syscall_32.tbl
> >> @@ -398,3 +398,4 @@
> >> 384 i386arch_prctl sys_arch_prctl
> >> __ia32_compat_sys_arch_prctl
> >>
> >385 i386io_pgetevents sys_io_pgetevents
> >__ia32_compat_sys_io_pgetevents
> >> 386 i386rseqsys_rseq
> >> __ia32_sys_rseq
> >>
> >+387 i386procfd_signal sys_procfd_signal
> >__ia32_compat_sys_procfd_signal
> >> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl
> >b/arch/x86/entry/syscalls/syscall_64.tbl
> >> index f0b1709a5ffb..8a30cde82450 100644
> >> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> >> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> >> @@ -343,6 +343,7 @@
> >> 332 common statx __x64_sys_statx
> >> 333 common io_pgetevents __x64_sys_io_pgetevents
> >> 334 common rseq__x64_sys_rseq
> >> +335 64 procfd_signal __x64_sys_procfd_signal
> >>
> >> #
> >> # x32-specific system call numbers start at 512 to avoid cache
> >impact
> >> @@ -386,3 +387,4 @@
> >> 545 x32 execveat__x32_compat_sys_execveat/ptregs
> >> 546 x32 preadv2 __x32_compat_sys_preadv64v2
> >> 547 x32 pwritev2__x32_compat_sys_pwritev64v2
> >> +548 x32 procfd_signal __x32_compat_sys_procfd_signal
> >
> >Is there a reason why these numbers have to be different?
> >
> >(See the recent discussion with Andy Lutomirski.)
> >
> >> +static int do_procfd_signal(int fd, int sig, kernel_siginfo_t
> >*kinfo, int flags,
> >> + bool had_siginfo)
> >> +{
> >> + int ret;
> >> + struct fd f;
> >> + struct pid *pid;
> >> +
> >> + /* Enforce flags be set to 0 until we add an extension. */
> >> + if (flags)
> >> + return -EINVAL;
> >> +
> >> + f = fdget_raw(fd);
> >> + if (!f.file)
> >> + return -EBADF;
> >> +
> >> + /* Is this a process file descriptor? */
> >> + ret = -EINVAL;
> >> + if (!proc_is_tgid_procfd(f.file))
> >> + goto err;
> >[…]
> >> + ret = kill_pid_info(sig, kinfo, pid);
> >
> >I would like to see some comment here what happens to zombie processes.
>
> You'd get ESRCH.
> I'm not sure if that has always been the case.
> Eric recently did some excellent refactoring of the signal code.
> Iirc, part of that involved not delivering signals to zombies.
> That's at least how I remember it.
> I don't have access to source code though atm.
Ok, I finally have access to source code again. Scratch what I said above!
I looked at the code and tested it. If the process has exited but not
yet waited upon aka is a zombie procfd_send_signal() will return 0. This
is identical to kill(2) behavior. It should've been sort-of obvious
since when a process is in zombie state /proc/ will still be around
which means that struct pid must still be around.
>
> >
> >> +/**
> >> + * sys_procfd_signal - send a signal to a process through a process
> >file
> >> + * descriptor
> >> + * @fd: the file descriptor of the process
> >> + * @sig: signal to be sent
> >> + * @info: the signal info
> >> + * @flags: future flags to be passed
> >> + */
> >> +SYSCALL_DEFINE4(procfd_signal, int, fd, int, sig, siginfo_t __user
> >*, info,
> >> + int, flags)
> >
> >Sorry, I'm quite unhappy with the name. “signal” is for signal handler
> >management. procfd_sendsignal, procfd_sigqueueinfo or something like
> >that would be fine. Even procfd_kill would be better IMHO.
>
> Ok. I only have strong opinions to procfd_kill().
> Mainly because the new syscall takes
> the job of multiple other syscalls
> so kill gives the wrong impression.
> I'll come up with a better name in the next iteration.
>
> >
> >Looking at the rt_tgsigqueueinfo interface, is there a way to implement
> >the “tg” part with the current procfd_signal interface? Would you use
> >openat to retrieve the Tgid: line from "status"?
>
> Yes, the tg part can be implemented.
> As I pointed out in another mail my
> I is to make this work by using file
> descriptors for /proc//task/.
> I don't want this in the initial patchset though.
> I prefer to slowly add those
Re: [PATCH v2] signal: add procfd_signal() syscall
On Sat, Dec 01, 2018 at 12:52:24PM +1300, Christian Brauner wrote:
> On November 30, 2018 1:28:15 AM GMT+13:00, Florian Weimer
> wrote:
> >Disclaimer: I'm looking at this patch because Christian requested it.
> >I'm not a kernel developer.
>
> Given all your expertise this really doesn't matter. :)
> You're the one having to deal with this
> in glibc after all.
> Thanks for doing this and sorry for the late reply.
> I missed that mail.
>
> >
> >* Christian Brauner:
> >
> >> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
> >b/arch/x86/entry/syscalls/syscall_32.tbl
> >> index 3cf7b533b3d1..3f27ffd8ae87 100644
> >> --- a/arch/x86/entry/syscalls/syscall_32.tbl
> >> +++ b/arch/x86/entry/syscalls/syscall_32.tbl
> >> @@ -398,3 +398,4 @@
> >> 384 i386arch_prctl sys_arch_prctl
> >> __ia32_compat_sys_arch_prctl
> >>
> >385 i386io_pgetevents sys_io_pgetevents
> >__ia32_compat_sys_io_pgetevents
> >> 386 i386rseqsys_rseq
> >> __ia32_sys_rseq
> >>
> >+387 i386procfd_signal sys_procfd_signal
> >__ia32_compat_sys_procfd_signal
> >> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl
> >b/arch/x86/entry/syscalls/syscall_64.tbl
> >> index f0b1709a5ffb..8a30cde82450 100644
> >> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> >> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> >> @@ -343,6 +343,7 @@
> >> 332 common statx __x64_sys_statx
> >> 333 common io_pgetevents __x64_sys_io_pgetevents
> >> 334 common rseq__x64_sys_rseq
> >> +335 64 procfd_signal __x64_sys_procfd_signal
> >>
> >> #
> >> # x32-specific system call numbers start at 512 to avoid cache
> >impact
> >> @@ -386,3 +387,4 @@
> >> 545 x32 execveat__x32_compat_sys_execveat/ptregs
> >> 546 x32 preadv2 __x32_compat_sys_preadv64v2
> >> 547 x32 pwritev2__x32_compat_sys_pwritev64v2
> >> +548 x32 procfd_signal __x32_compat_sys_procfd_signal
> >
> >Is there a reason why these numbers have to be different?
> >
> >(See the recent discussion with Andy Lutomirski.)
> >
> >> +static int do_procfd_signal(int fd, int sig, kernel_siginfo_t
> >*kinfo, int flags,
> >> + bool had_siginfo)
> >> +{
> >> + int ret;
> >> + struct fd f;
> >> + struct pid *pid;
> >> +
> >> + /* Enforce flags be set to 0 until we add an extension. */
> >> + if (flags)
> >> + return -EINVAL;
> >> +
> >> + f = fdget_raw(fd);
> >> + if (!f.file)
> >> + return -EBADF;
> >> +
> >> + /* Is this a process file descriptor? */
> >> + ret = -EINVAL;
> >> + if (!proc_is_tgid_procfd(f.file))
> >> + goto err;
> >[…]
> >> + ret = kill_pid_info(sig, kinfo, pid);
> >
> >I would like to see some comment here what happens to zombie processes.
>
> You'd get ESRCH.
> I'm not sure if that has always been the case.
> Eric recently did some excellent refactoring of the signal code.
> Iirc, part of that involved not delivering signals to zombies.
> That's at least how I remember it.
> I don't have access to source code though atm.
Ok, I finally have access to source code again. Scratch what I said above!
I looked at the code and tested it. If the process has exited but not
yet waited upon aka is a zombie procfd_send_signal() will return 0. This
is identical to kill(2) behavior. It should've been sort-of obvious
since when a process is in zombie state /proc/ will still be around
which means that struct pid must still be around.
>
> >
> >> +/**
> >> + * sys_procfd_signal - send a signal to a process through a process
> >file
> >> + * descriptor
> >> + * @fd: the file descriptor of the process
> >> + * @sig: signal to be sent
> >> + * @info: the signal info
> >> + * @flags: future flags to be passed
> >> + */
> >> +SYSCALL_DEFINE4(procfd_signal, int, fd, int, sig, siginfo_t __user
> >*, info,
> >> + int, flags)
> >
> >Sorry, I'm quite unhappy with the name. “signal” is for signal handler
> >management. procfd_sendsignal, procfd_sigqueueinfo or something like
> >that would be fine. Even procfd_kill would be better IMHO.
>
> Ok. I only have strong opinions to procfd_kill().
> Mainly because the new syscall takes
> the job of multiple other syscalls
> so kill gives the wrong impression.
> I'll come up with a better name in the next iteration.
>
> >
> >Looking at the rt_tgsigqueueinfo interface, is there a way to implement
> >the “tg” part with the current procfd_signal interface? Would you use
> >openat to retrieve the Tgid: line from "status"?
>
> Yes, the tg part can be implemented.
> As I pointed out in another mail my
> I is to make this work by using file
> descriptors for /proc//task/.
> I don't want this in the initial patchset though.
> I prefer to slowly add those
Re: [PATCH] drop silly "static inline asmlinkage" from dump_stack()
On Sun, Dec 02, 2018 at 12:02:54PM +0300, Alexey Dobriyan wrote: > Empty function will be inlined so asmlinkage doesn't do anything. Yes, that is an example of a perfect explanation to have in the commit message :) Ack from me after that addition. Acked-by: Joey Pabalinas -- Cheers, Joey Pabalinas signature.asc Description: PGP signature
Re: [PATCH] drop silly "static inline asmlinkage" from dump_stack()
On Sun, Dec 02, 2018 at 12:02:54PM +0300, Alexey Dobriyan wrote: > Empty function will be inlined so asmlinkage doesn't do anything. Yes, that is an example of a perfect explanation to have in the commit message :) Ack from me after that addition. Acked-by: Joey Pabalinas -- Cheers, Joey Pabalinas signature.asc Description: PGP signature
Re: [PATCH v5 20/21] m68k/mac: Switch to use %ptR
On Thu, Nov 29, 2018 at 12:04 PM Andy Shevchenko
wrote:
> Use %ptR instead of open coded variant to print content of
> struct rtc_time in human readable format.
>
> Cc: Geert Uytterhoeven
> Cc: linux-m68k
> Signed-off-by: Andy Shevchenko
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 20/21] m68k/mac: Switch to use %ptR
On Thu, Nov 29, 2018 at 12:04 PM Andy Shevchenko
wrote:
> Use %ptR instead of open coded variant to print content of
> struct rtc_time in human readable format.
>
> Cc: Geert Uytterhoeven
> Cc: linux-m68k
> Signed-off-by: Andy Shevchenko
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] psi: fix reference to kernel commandline enable
The kernel commandline parameter named in CONFIG_PSI_DEFAULT_DISABLED
help text contradicts the documentation in kernel-parameters.txt, and
the code. Fix that.
Fixes: e0c274472d ("psi: make disabling/enabling easier for vendor kernels")
Signed-off-by: Baruch Siach
---
init/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index cf5b5a0dcbc2..ed9352513c32 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -515,8 +515,8 @@ config PSI_DEFAULT_DISABLED
depends on PSI
help
If set, pressure stall information tracking will be disabled
- per default but can be enabled through passing psi_enable=1
- on the kernel commandline during boot.
+ per default but can be enabled through passing psi=1 on the
+ kernel commandline during boot.
endmenu # "CPU/Task time and stats accounting"
--
2.19.2
[PATCH] psi: fix reference to kernel commandline enable
The kernel commandline parameter named in CONFIG_PSI_DEFAULT_DISABLED
help text contradicts the documentation in kernel-parameters.txt, and
the code. Fix that.
Fixes: e0c274472d ("psi: make disabling/enabling easier for vendor kernels")
Signed-off-by: Baruch Siach
---
init/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index cf5b5a0dcbc2..ed9352513c32 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -515,8 +515,8 @@ config PSI_DEFAULT_DISABLED
depends on PSI
help
If set, pressure stall information tracking will be disabled
- per default but can be enabled through passing psi_enable=1
- on the kernel commandline during boot.
+ per default but can be enabled through passing psi=1 on the
+ kernel commandline during boot.
endmenu # "CPU/Task time and stats accounting"
--
2.19.2
Re: linux-next: manual merge of the selinux tree with the vfs tree
On Sat, Dec 1, 2018 at 10:32 PM Ondrej Mosnacek wrote:
> On Thu, Nov 29, 2018 at 11:07 AM Ondrej Mosnacek wrote:
> > On Wed, Nov 28, 2018 at 10:52 PM Paul Moore wrote:
> > > On Tue, Nov 27, 2018 at 6:50 AM Stephen Rothwell
> > > wrote:
> > > > Hi Ondrej,
> > > >
> > > > On Tue, 27 Nov 2018 09:53:32 +0100 Ondrej Mosnacek
> > > > wrote:
> > > > >
> > > > > Hm... seems that there was some massive overhaul in the VFS code right
> > > > > at the wrong moment... There are new hooks for mounting now and the
> > > >
> > > > The mount changes have been in linux-next since before the last
> > > > release ...
> > > >
> > > > > code that our commit changes is now here:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/tree/security/selinux/hooks.c?h=for-next#n3131
> > > > >
> > > > > It seems that the logic is still the same, just now our patch (or the
> > > > > VFS one) needs to be updated to change the above line as such
> > > > > (untested pseudo-patch):
> > > > >
> > > > > - if (fc->purpose == FS_CONTEXT_FOR_KERNEL_MOUNT)
> > > > > + if (fc->purpose ==
> > > > > (FS_CONTEXT_FOR_KERNEL_MOUNT|FS_CONTEXT_FOR_SUBMOUNT))
> > > >
> > > > OK, so from tomorrow I will use that merge resolution. Someone needs
> > > > to remember to tell Linus about this when the latter of the vfs and
> > > > selinux trees reach him.
> > >
> > > I will, or at least I'll do my best to remember; since we only have a
> > > few more week until the merge window I like my odds. FWIW, I
> > > typically do a test merge on top of Linus' tree before sending the
> > > SELinux PR just to verify that everything is relatively clean and
> > > there are no surprises.
> > >
> > > Ondrej, please work with David Howells to ensure that submounts are
> > > handled correctly in his mount rework.
> >
> > OK, I will verify that the SELinux submount fix rebased on top of
> > vfs/work.mount in the way I suggested above passes the same testing
> > (seliinux-testsuite + NFS crossmnt reproducer). I am now building two
> > kernels (vfs/work.mount with and without the fix) to test. Let me know
> > if there is anything more to do.
>
> I tested the proposed patch ([1]; fixed as per correction from David
> Howells) applied on top of patches v4.19-rc3..vfs/work.mount applied
> on top of the 4.19.5-300 Fedora 29 kernel.
>
> However, the submount test was still failing, so I looked again at the
> list of the possible 'purpose' values and it turns out the value used
> by NFS et al. is actually FS_CONTEXT_FOR_ROOT_MOUNT (it is actually
> documented nicely in Documentation/filesystems/mount_api.txt). So I'll
> need to build a new test kernel with updated patch ([2]) and retest...
Unfortunately, even with FS_CONTEXT_FOR_ROOT_MOUNT the submount test
is still failing. (Actually, re-reading the description for
FS_CONTEXT_FOR_ROOT_MOUNT it seems it is not actually related to
submounts, although we should probably still skip the check for it,
too.) I will need to dig deeper into this on Monday...
FWIW, the generated AVC denial is still the same so it must be failing
the check in that particular hook (the FILESYSTEM__MOUNT permission is
checked only in that single place):
type=AVC msg=audit(02.12.2018 01:55:03.626:604) : avc: denied {
mount } for pid=4036 comm=cat name=/ dev="0:48" ino=2
scontext=unconfined_u:unconfined_r:test_readnfs_t:s0-s0:c0.c1023
tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem permissive=0
>
> BTW, the vfs/work.mount changes alone seem to cause some overlay test
> failures (I didn't test a clean 4.19.5 so it may be due to some stable
> patch as well):
>
> Test Summary Report
> ---
> overlay/test (Wstat: 3072 Tests: 119 Failed: 12)
> Failed tests: 66, 74, 76-77, 79, 87, 95, 103, 108, 110-111
>117
> Non-zero exit status: 12
>
> The failing tests are all in the context mount section, but I don't
> think this is (directly) related to [3] because there are much more
> tests failing and the kernel I was testing didn't include the
> problematic OverlayFS patch. Perhaps the VFS patches somehow broke the
> parsing of the context= mount option?
>
> [1]
> https://gitlab.com/omos/linux-public/commit/fe5478717ddde92e3ea599e14051ad57522fdf47
> [2]
> https://gitlab.com/omos/linux-public/commit/f5c58adc7babd62e4bfe8cda799459d263dc5186
> [3] https://github.com/SELinuxProject/selinux-kernel/issues/43
>
> --
> Ondrej Mosnacek
> Associate Software Engineer, Security Technologies
> Red Hat, Inc.
--
Ondrej Mosnacek
Associate Software Engineer, Security Technologies
Red Hat, Inc.
Re: linux-next: manual merge of the selinux tree with the vfs tree
On Sat, Dec 1, 2018 at 10:32 PM Ondrej Mosnacek wrote:
> On Thu, Nov 29, 2018 at 11:07 AM Ondrej Mosnacek wrote:
> > On Wed, Nov 28, 2018 at 10:52 PM Paul Moore wrote:
> > > On Tue, Nov 27, 2018 at 6:50 AM Stephen Rothwell
> > > wrote:
> > > > Hi Ondrej,
> > > >
> > > > On Tue, 27 Nov 2018 09:53:32 +0100 Ondrej Mosnacek
> > > > wrote:
> > > > >
> > > > > Hm... seems that there was some massive overhaul in the VFS code right
> > > > > at the wrong moment... There are new hooks for mounting now and the
> > > >
> > > > The mount changes have been in linux-next since before the last
> > > > release ...
> > > >
> > > > > code that our commit changes is now here:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/tree/security/selinux/hooks.c?h=for-next#n3131
> > > > >
> > > > > It seems that the logic is still the same, just now our patch (or the
> > > > > VFS one) needs to be updated to change the above line as such
> > > > > (untested pseudo-patch):
> > > > >
> > > > > - if (fc->purpose == FS_CONTEXT_FOR_KERNEL_MOUNT)
> > > > > + if (fc->purpose ==
> > > > > (FS_CONTEXT_FOR_KERNEL_MOUNT|FS_CONTEXT_FOR_SUBMOUNT))
> > > >
> > > > OK, so from tomorrow I will use that merge resolution. Someone needs
> > > > to remember to tell Linus about this when the latter of the vfs and
> > > > selinux trees reach him.
> > >
> > > I will, or at least I'll do my best to remember; since we only have a
> > > few more week until the merge window I like my odds. FWIW, I
> > > typically do a test merge on top of Linus' tree before sending the
> > > SELinux PR just to verify that everything is relatively clean and
> > > there are no surprises.
> > >
> > > Ondrej, please work with David Howells to ensure that submounts are
> > > handled correctly in his mount rework.
> >
> > OK, I will verify that the SELinux submount fix rebased on top of
> > vfs/work.mount in the way I suggested above passes the same testing
> > (seliinux-testsuite + NFS crossmnt reproducer). I am now building two
> > kernels (vfs/work.mount with and without the fix) to test. Let me know
> > if there is anything more to do.
>
> I tested the proposed patch ([1]; fixed as per correction from David
> Howells) applied on top of patches v4.19-rc3..vfs/work.mount applied
> on top of the 4.19.5-300 Fedora 29 kernel.
>
> However, the submount test was still failing, so I looked again at the
> list of the possible 'purpose' values and it turns out the value used
> by NFS et al. is actually FS_CONTEXT_FOR_ROOT_MOUNT (it is actually
> documented nicely in Documentation/filesystems/mount_api.txt). So I'll
> need to build a new test kernel with updated patch ([2]) and retest...
Unfortunately, even with FS_CONTEXT_FOR_ROOT_MOUNT the submount test
is still failing. (Actually, re-reading the description for
FS_CONTEXT_FOR_ROOT_MOUNT it seems it is not actually related to
submounts, although we should probably still skip the check for it,
too.) I will need to dig deeper into this on Monday...
FWIW, the generated AVC denial is still the same so it must be failing
the check in that particular hook (the FILESYSTEM__MOUNT permission is
checked only in that single place):
type=AVC msg=audit(02.12.2018 01:55:03.626:604) : avc: denied {
mount } for pid=4036 comm=cat name=/ dev="0:48" ino=2
scontext=unconfined_u:unconfined_r:test_readnfs_t:s0-s0:c0.c1023
tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem permissive=0
>
> BTW, the vfs/work.mount changes alone seem to cause some overlay test
> failures (I didn't test a clean 4.19.5 so it may be due to some stable
> patch as well):
>
> Test Summary Report
> ---
> overlay/test (Wstat: 3072 Tests: 119 Failed: 12)
> Failed tests: 66, 74, 76-77, 79, 87, 95, 103, 108, 110-111
>117
> Non-zero exit status: 12
>
> The failing tests are all in the context mount section, but I don't
> think this is (directly) related to [3] because there are much more
> tests failing and the kernel I was testing didn't include the
> problematic OverlayFS patch. Perhaps the VFS patches somehow broke the
> parsing of the context= mount option?
>
> [1]
> https://gitlab.com/omos/linux-public/commit/fe5478717ddde92e3ea599e14051ad57522fdf47
> [2]
> https://gitlab.com/omos/linux-public/commit/f5c58adc7babd62e4bfe8cda799459d263dc5186
> [3] https://github.com/SELinuxProject/selinux-kernel/issues/43
>
> --
> Ondrej Mosnacek
> Associate Software Engineer, Security Technologies
> Red Hat, Inc.
--
Ondrej Mosnacek
Associate Software Engineer, Security Technologies
Red Hat, Inc.
Re: [PATCH] drop silly "static inline asmlinkage" from dump_stack()
On Sat, Dec 01, 2018 at 09:33:38PM -1000, Joey Pabalinas wrote: > On Sat, Nov 24, 2018 at 12:35:30PM +0300, Alexey Dobriyan wrote: > > -static inline asmlinkage void dump_stack(void) > > +static inline void dump_stack(void) > > Why is it "silly"? An explanation in the commit message would be useful. Empty function will be inlined so asmlinkage doesn't do anything.
Re: [PATCH] drop silly "static inline asmlinkage" from dump_stack()
On Sat, Dec 01, 2018 at 09:33:38PM -1000, Joey Pabalinas wrote: > On Sat, Nov 24, 2018 at 12:35:30PM +0300, Alexey Dobriyan wrote: > > -static inline asmlinkage void dump_stack(void) > > +static inline void dump_stack(void) > > Why is it "silly"? An explanation in the commit message would be useful. Empty function will be inlined so asmlinkage doesn't do anything.
[PULL REQUEST] dmaengine fixes for v4.20-rc5
Hi Linus, Here is the pull request for v4.20-rc5. It contains two fixes (cced stable) to fix serial dma memory leak on at_hdmac dma The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) are available in the Git repository at: git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-fix-4.20-rc5 for you to fetch changes up to 77e75fda94d2ebb86aa9d35fb1860f6395bf95de: dmaengine: at_hdmac: fix module unloading (2018-11-29 19:49:41 +0530) dmaengine-4.20-rc5 dmaengine fixes for v4.20-rc5 This contains two fixes to at_hdmac which fixes long standing bus reported recently on serial transfers causing memory leak. These fixes were done by Richard Genoud. Richard Genoud (2): dmaengine: at_hdmac: fix memory leak in at_dma_xlate() dmaengine: at_hdmac: fix module unloading drivers/dma/at_hdmac.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) Thanks -- ~Vinod signature.asc Description: PGP signature
[PULL REQUEST] dmaengine fixes for v4.20-rc5
Hi Linus, Here is the pull request for v4.20-rc5. It contains two fixes (cced stable) to fix serial dma memory leak on at_hdmac dma The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) are available in the Git repository at: git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-fix-4.20-rc5 for you to fetch changes up to 77e75fda94d2ebb86aa9d35fb1860f6395bf95de: dmaengine: at_hdmac: fix module unloading (2018-11-29 19:49:41 +0530) dmaengine-4.20-rc5 dmaengine fixes for v4.20-rc5 This contains two fixes to at_hdmac which fixes long standing bus reported recently on serial transfers causing memory leak. These fixes were done by Richard Genoud. Richard Genoud (2): dmaengine: at_hdmac: fix memory leak in at_dma_xlate() dmaengine: at_hdmac: fix module unloading drivers/dma/at_hdmac.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) Thanks -- ~Vinod signature.asc Description: PGP signature
Re: [PATCH v2] signal: add procfd_signal() syscall
On Sat, Dec 01, 2018 at 09:28:47AM -0600, Eric W. Biederman wrote:
>
> It just occurs to me that the simple way to implement
> procfd_sigqueueinfo info is like:
>
> int copy_siginfo_from_user_any(kernel_siginfo_t *info, siginfo_t *uinfo)
> {
> #ifdef CONFIG_COMPAT
> if (in_compat_syscall)
> return copy_siginfo_from_user32(info, uinfo);
Right, though that would require a cast afaict.
static int __copy_siginfo_from_user_generic(int signo, kernel_siginfo_t *kinfo,
siginfo_t *info)
{
#ifdef CONFIG_COMPAT
if (in_compat_syscall())
return __copy_siginfo_from_user32(
signo, kinfo, (struct compat_siginfo __user *)info);
#endif
return __copy_siginfo_from_user(signo, kinfo, info);
}
It seems that a cast to (compat_siginfo __user *) should be safe in this
context? I've at least seen similar things done for __sys_sendmsg().
> #endif
> return copy_siginfo_from_user(info, uinfo);
> }
>
> long procfd_sigqueueinfo(int fd, siginfo_t *uinfo)
**bikeshedding**
Not a fan of that name. I'm going to go with procfd_send_signal().
sigqueue gives non-native speakers a lot of room for spelling errors and
it always seemed opaque to me what this function is doing without
consulting the manpage. :)
> {
> kernel_siginfo info;
>
> if (copy_siginfo_from_user_any(, uinfo))
> return -EFAULT;
> ...;
> }
>
> It looks like there is already a place in ptrace.c that already
> hand rolls copy_siginfo_from_user_any.
>
> So while I would love to figure out the subset of siginfo_t tha we can
> just pass through, as I think that would make a better more forward
> compatible copy_siginfo_from_user32. I think for this use case we just
> add the in_compat_syscall test and then we just need to ensure this new
> system call is placed in the proper places in the syscall table.
>
> Because we will need 3 call sights: x86_64, x32 and ia32. As the layout
> changes between those three subarchitecuters.
>
> Eric
>
Re: [PATCH v2] signal: add procfd_signal() syscall
On Sat, Dec 01, 2018 at 09:28:47AM -0600, Eric W. Biederman wrote:
>
> It just occurs to me that the simple way to implement
> procfd_sigqueueinfo info is like:
>
> int copy_siginfo_from_user_any(kernel_siginfo_t *info, siginfo_t *uinfo)
> {
> #ifdef CONFIG_COMPAT
> if (in_compat_syscall)
> return copy_siginfo_from_user32(info, uinfo);
Right, though that would require a cast afaict.
static int __copy_siginfo_from_user_generic(int signo, kernel_siginfo_t *kinfo,
siginfo_t *info)
{
#ifdef CONFIG_COMPAT
if (in_compat_syscall())
return __copy_siginfo_from_user32(
signo, kinfo, (struct compat_siginfo __user *)info);
#endif
return __copy_siginfo_from_user(signo, kinfo, info);
}
It seems that a cast to (compat_siginfo __user *) should be safe in this
context? I've at least seen similar things done for __sys_sendmsg().
> #endif
> return copy_siginfo_from_user(info, uinfo);
> }
>
> long procfd_sigqueueinfo(int fd, siginfo_t *uinfo)
**bikeshedding**
Not a fan of that name. I'm going to go with procfd_send_signal().
sigqueue gives non-native speakers a lot of room for spelling errors and
it always seemed opaque to me what this function is doing without
consulting the manpage. :)
> {
> kernel_siginfo info;
>
> if (copy_siginfo_from_user_any(, uinfo))
> return -EFAULT;
> ...;
> }
>
> It looks like there is already a place in ptrace.c that already
> hand rolls copy_siginfo_from_user_any.
>
> So while I would love to figure out the subset of siginfo_t tha we can
> just pass through, as I think that would make a better more forward
> compatible copy_siginfo_from_user32. I think for this use case we just
> add the in_compat_syscall test and then we just need to ensure this new
> system call is placed in the proper places in the syscall table.
>
> Because we will need 3 call sights: x86_64, x32 and ia32. As the layout
> changes between those three subarchitecuters.
>
> Eric
>
Re: [PATCH] ubi: fastmap: Check each mapping only once
Greg,
Am Donnerstag, 29. November 2018, 09:09:23 CET schrieb Greg KH:
> On Mon, Nov 26, 2018 at 11:38:42AM +0100, Martin Kepplinger wrote:
> > From: Richard Weinberger
> >
> > [ Upstream commit 34653fd8c46e771585fce5975e4243f8fd401914 ]
> >
> > This commit got merged along with commit 781932375ffc
> > ("ubi: fastmap: Correctly handle interrupted erasures in EBA") upstream but
> > only the latter has been applied to stable v4.14.54 as commit a23cf10d9abb.
> > This resulted in a performance regression. Startup on i.MX platforms is
> > delayed for up to a few seconds depending on the platform.
> > This fixes ubi fastmap to be of the same performance as it has been before
> > said fastmap changes.
> >
> > Fixes: a23cf10d9abb ("ubi: fastmap: Correctly handle interrupted erasures
> > in EBA")
> > Signed-off-by: Richard Weinberger
> > Signed-off-by: Martin Kepplinger
> > ---
> >
> > Richard, although this fixes a major slowdown regression in -stable, do you
> > consider this "stable" too?
> >
> > This applies and is tested only for the 4.14 stable tree. It seems to be
> > equally relevant for 4.9 and 4.4 though.
>
> Now queued up for 4.14.y, thanks.
can you *please* slow a little down?
There are times (e.g. when I travel, visit customers on-site, being sick,
etc...)
where I don't have the resources to monitor the mailinglists
in detail. Adding patches to stable on shout asks for trouble.
As Sudip points out, this patch needs a further fix patch:
25677478474a ("ubi: Initialize Fastmap checkmapping correctly")
Thanks,
//richard
Re: [PATCH] ubi: fastmap: Check each mapping only once
Greg,
Am Donnerstag, 29. November 2018, 09:09:23 CET schrieb Greg KH:
> On Mon, Nov 26, 2018 at 11:38:42AM +0100, Martin Kepplinger wrote:
> > From: Richard Weinberger
> >
> > [ Upstream commit 34653fd8c46e771585fce5975e4243f8fd401914 ]
> >
> > This commit got merged along with commit 781932375ffc
> > ("ubi: fastmap: Correctly handle interrupted erasures in EBA") upstream but
> > only the latter has been applied to stable v4.14.54 as commit a23cf10d9abb.
> > This resulted in a performance regression. Startup on i.MX platforms is
> > delayed for up to a few seconds depending on the platform.
> > This fixes ubi fastmap to be of the same performance as it has been before
> > said fastmap changes.
> >
> > Fixes: a23cf10d9abb ("ubi: fastmap: Correctly handle interrupted erasures
> > in EBA")
> > Signed-off-by: Richard Weinberger
> > Signed-off-by: Martin Kepplinger
> > ---
> >
> > Richard, although this fixes a major slowdown regression in -stable, do you
> > consider this "stable" too?
> >
> > This applies and is tested only for the 4.14 stable tree. It seems to be
> > equally relevant for 4.9 and 4.4 though.
>
> Now queued up for 4.14.y, thanks.
can you *please* slow a little down?
There are times (e.g. when I travel, visit customers on-site, being sick,
etc...)
where I don't have the resources to monitor the mailinglists
in detail. Adding patches to stable on shout asks for trouble.
As Sudip points out, this patch needs a further fix patch:
25677478474a ("ubi: Initialize Fastmap checkmapping correctly")
Thanks,
//richard
Re: [PATCHv3] ARM: dspi: Provide support for DSPI slave mode operation (Vybryd vf610)
Dear All,
> The NXP's Vybryd vf610 can work as a SPI slave device (the CS and
> clock signals are provided by master).
>
> It is possible to specify a single device to work in that mode. As we
> do use DMA for transferring data, the RX channel must be prepared for
> incoming data.
> Moreover, in slave mode we just set a subset of control fields in
> configuration registers (CTAR0, PUSHR).
>
> For testing the spidev_test program has been used.
> Test script for this patch can be found here:
> https://github.com/lmajewski/tests-spi/blob/master/tests/spi/spi_tests.sh
Gentle ping on this patch. Comments are more than welcome.
>
> Signed-off-by: Lukasz Majewski
> ---
> Changes for v3:
>
> - Rebase to v4.20-rc2 (no code changes needed)
>
> Changes for v2:
>
> - Remove patch which adds extra NXP specific DTS property to support
> slave mode and reuse the generic one (spi-slave)
> - Remove patch which brings back the mcr_register local copy. It is
> not needed as generic SPI slave infrastructure is used.
> - Rewrite the code to use spi_controller_is_slave() helper functions
> ---
> drivers/spi/spi-fsl-dspi.c | 40
> ++-- 1 file changed, 30
> insertions(+), 10 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 3082e72e4f6c..94b6a9690062 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -233,6 +233,9 @@ static u32 dspi_pop_tx_pushr(struct fsl_dspi
> *dspi) {
> u16 cmd = dspi->tx_cmd, data = dspi_pop_tx(dspi);
>
> + if (spi_controller_is_slave(dspi->master))
> + return data;
> +
> if (dspi->len > 0)
> cmd |= SPI_PUSHR_CMD_CONT;
> return cmd << 16 | data;
> @@ -329,6 +332,11 @@ static int dspi_next_xfer_dma_submit(struct
> fsl_dspi *dspi) dma_async_issue_pending(dma->chan_rx);
> dma_async_issue_pending(dma->chan_tx);
>
> + if (spi_controller_is_slave(dspi->master)) {
> +
> wait_for_completion_interruptible(>dma->cmd_rx_complete);
> + return 0;
> + }
> +
> time_left =
> wait_for_completion_timeout(>dma->cmd_tx_complete,
> DMA_COMPLETION_TIMEOUT); if (time_left == 0) {
> @@ -798,14 +806,18 @@ static int dspi_setup(struct spi_device *spi)
> ns_delay_scale(, , sck_cs_delay, clkrate);
>
> chip->ctar_val = SPI_CTAR_CPOL(spi->mode & SPI_CPOL ? 1 : 0)
> - | SPI_CTAR_CPHA(spi->mode & SPI_CPHA ? 1 : 0)
> - | SPI_CTAR_LSBFE(spi->mode & SPI_LSB_FIRST ? 1 : 0)
> - | SPI_CTAR_PCSSCK(pcssck)
> - | SPI_CTAR_CSSCK(cssck)
> - | SPI_CTAR_PASC(pasc)
> - | SPI_CTAR_ASC(asc)
> - | SPI_CTAR_PBR(pbr)
> - | SPI_CTAR_BR(br);
> + | SPI_CTAR_CPHA(spi->mode & SPI_CPHA ? 1 : 0);
> +
> + if (!spi_controller_is_slave(dspi->master)) {
> + chip->ctar_val |= SPI_CTAR_LSBFE(spi->mode &
> + SPI_LSB_FIRST ? 1 :
> 0)
> + | SPI_CTAR_PCSSCK(pcssck)
> + | SPI_CTAR_CSSCK(cssck)
> + | SPI_CTAR_PASC(pasc)
> + | SPI_CTAR_ASC(asc)
> + | SPI_CTAR_PBR(pbr)
> + | SPI_CTAR_BR(br);
> + }
>
> spi_set_ctldata(spi, chip);
>
> @@ -970,8 +982,13 @@ static const struct regmap_config
> dspi_xspi_regmap_config[] = {
> static void dspi_init(struct fsl_dspi *dspi)
> {
> - regmap_write(dspi->regmap, SPI_MCR, SPI_MCR_MASTER |
> SPI_MCR_PCSIS |
> - (dspi->devtype_data->xspi_mode ? SPI_MCR_XSPI :
> 0));
> + unsigned int mcr = SPI_MCR_PCSIS |
> + (dspi->devtype_data->xspi_mode ? SPI_MCR_XSPI : 0);
> +
> + if (!spi_controller_is_slave(dspi->master))
> + mcr |= SPI_MCR_MASTER;
> +
> + regmap_write(dspi->regmap, SPI_MCR, mcr);
> regmap_write(dspi->regmap, SPI_SR, SPI_SR_CLEAR);
> if (dspi->devtype_data->xspi_mode)
> regmap_write(dspi->regmap, SPI_CTARE(0),
> @@ -1027,6 +1044,9 @@ static int dspi_probe(struct platform_device
> *pdev) }
> master->bus_num = bus_num;
>
> + if (of_property_read_bool(np, "spi-slave"))
> + master->slave = true;
> +
> dspi->devtype_data =
> of_device_get_match_data(>dev); if (!dspi->devtype_data) {
> dev_err(>dev, "can't get
> devtype_data\n");
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpj2qaqJ24th.pgp
Description: OpenPGP digital signature
RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
> From: gre...@linuxfoundation.org
> Sent: Saturday, December 1, 2018 11:34 PM
> To: Dexuan Cui
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; a...@canonical.com; vkuznets
> ; o...@aepfle.de; jasow...@redhat.com; Michael
> Kelley
> Subject: Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of
> channels to two workqueues
>
> On Fri, Nov 30, 2018 at 06:09:54PM +, Dexuan Cui wrote:
> > > From: KY Srinivasan
> > > Sent: Friday, November 30, 2018 9:31 AM
> > > > From: Dexuan Cui
> > > > Sent: Thursday, November 29, 2018 12:17 AM
> > > > To: gre...@linuxfoundation.org
> > > > Cc: KY Srinivasan ; Haiyang Zhang
> > > > ; Stephen Hemminger
> > > > ; linux-kernel@vger.kernel.org;
> > > > de...@linuxdriverproject.org; a...@canonical.com; vkuznets
> > > > ; o...@aepfle.de; jasow...@redhat.com;
> Michael
> > > > Kelley
> > > > Subject: RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling
> > > > of
> > > > channels to two workqueues
> > > >
> > > > > From: gre...@linuxfoundation.org
> > > > > Sent: Wednesday, November 28, 2018 11:45 PM
> > > > > >
> > > > > > There is no change in this repost. I just rebased this patch to
> > > > > > today's
> > > > > > char-misc's char-misc-next branch. Previously KY posted the patch
> with
> > > > his
> > > > > > Signed-off-by (which is kept in this repost), but there was a
> > > > > > conflict
> issue.
> > > > > >
> > > > > > Note: the patch can't be cleanly applied to char-misc's
> char-misc-linus
> > > > branch
> > > > > --
> > > > > > to do that, we need to cherry-pick the supporting patch first:
> > > > > > 4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API
> > > > > vmbus_get_outgoing_channel()")
> > > > >
> > > > > That is not going to work for the obvious reason that this dependant
> > > > > patch is not going to be merged into 4.20-final.
> > > >
> > > > It looks the dependent patch (4d3c5c69191f) is going to miss the v4.20
> > > > release.
> > > > This is not a big issue, as the dependent patch isn't really important.
> > > >
> > > > > So, what do you expect us to do here? The only way this can be
> accepted
> > > > > is to have it go into my -next branch, which means it will show up in
> > > > > 4.21-rc1, is that ok?
> > > >
> > > > Is there any chance for this patch ("Drivers: hv: vmbus: Offload the
> handling
> > > > ...") to
> > > > go into v4.20?
> > > >
> > > > If yes, I can quickly do a rebase to char-misc's char-misc-linus branch,
> > > > because actually the conflict can be very easily fixed. And I can help
> > > > to
> fix any
> > > > conflict when the dependent patch is backported to v4.20.1.
> > >
> > > This patch fixes an important bug while the patch this depends on is not
> > > critical.
> > > I suggest we revert the patch that this patch depends on
> > > and we can submit a new version of this patch that can go in now - into
> 4.20
> > > release.
> > >
> > > K. Y
> >
> > I agree.
> >
> > Hi Greg,
> > Please let us know what we can do to try to push this important fix into
> v4.20.
> >
> > Actually it's straightforward, though it looks big. And, we ave done a full
> testing
> > with the patch.
>
> Ok, you all need to figure this out on your own, sorry. Please give me
> a patch that I can actually apply to the tree if you need it merged into
> 4.20-final. This shouldn't be tough, you all have been doing this long
> enough by now...
>
> I have no bandwidth to do this myself for you,
>
> greg k-h
Hi Greg,
Please use the attached patch: I rebased the patch to today's char-misc's
char-misc-linus branch. It can also cleanly apply to Linus's master branch
today.
Please let me know in case you need me to re-post the patch in a new mail
(rather than the attachment here) or you need me to rebase the patch to
a different tree/branch.
Thanks,
Dexuan
0001-Drivers-hv-vmbus-Offload-the-handling-of-channels-to.patch
Description: 0001-Drivers-hv-vmbus-Offload-the-handling-of-channels-to.patch
Re: [PATCHv3] ARM: dspi: Provide support for DSPI slave mode operation (Vybryd vf610)
Dear All,
> The NXP's Vybryd vf610 can work as a SPI slave device (the CS and
> clock signals are provided by master).
>
> It is possible to specify a single device to work in that mode. As we
> do use DMA for transferring data, the RX channel must be prepared for
> incoming data.
> Moreover, in slave mode we just set a subset of control fields in
> configuration registers (CTAR0, PUSHR).
>
> For testing the spidev_test program has been used.
> Test script for this patch can be found here:
> https://github.com/lmajewski/tests-spi/blob/master/tests/spi/spi_tests.sh
Gentle ping on this patch. Comments are more than welcome.
>
> Signed-off-by: Lukasz Majewski
> ---
> Changes for v3:
>
> - Rebase to v4.20-rc2 (no code changes needed)
>
> Changes for v2:
>
> - Remove patch which adds extra NXP specific DTS property to support
> slave mode and reuse the generic one (spi-slave)
> - Remove patch which brings back the mcr_register local copy. It is
> not needed as generic SPI slave infrastructure is used.
> - Rewrite the code to use spi_controller_is_slave() helper functions
> ---
> drivers/spi/spi-fsl-dspi.c | 40
> ++-- 1 file changed, 30
> insertions(+), 10 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 3082e72e4f6c..94b6a9690062 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -233,6 +233,9 @@ static u32 dspi_pop_tx_pushr(struct fsl_dspi
> *dspi) {
> u16 cmd = dspi->tx_cmd, data = dspi_pop_tx(dspi);
>
> + if (spi_controller_is_slave(dspi->master))
> + return data;
> +
> if (dspi->len > 0)
> cmd |= SPI_PUSHR_CMD_CONT;
> return cmd << 16 | data;
> @@ -329,6 +332,11 @@ static int dspi_next_xfer_dma_submit(struct
> fsl_dspi *dspi) dma_async_issue_pending(dma->chan_rx);
> dma_async_issue_pending(dma->chan_tx);
>
> + if (spi_controller_is_slave(dspi->master)) {
> +
> wait_for_completion_interruptible(>dma->cmd_rx_complete);
> + return 0;
> + }
> +
> time_left =
> wait_for_completion_timeout(>dma->cmd_tx_complete,
> DMA_COMPLETION_TIMEOUT); if (time_left == 0) {
> @@ -798,14 +806,18 @@ static int dspi_setup(struct spi_device *spi)
> ns_delay_scale(, , sck_cs_delay, clkrate);
>
> chip->ctar_val = SPI_CTAR_CPOL(spi->mode & SPI_CPOL ? 1 : 0)
> - | SPI_CTAR_CPHA(spi->mode & SPI_CPHA ? 1 : 0)
> - | SPI_CTAR_LSBFE(spi->mode & SPI_LSB_FIRST ? 1 : 0)
> - | SPI_CTAR_PCSSCK(pcssck)
> - | SPI_CTAR_CSSCK(cssck)
> - | SPI_CTAR_PASC(pasc)
> - | SPI_CTAR_ASC(asc)
> - | SPI_CTAR_PBR(pbr)
> - | SPI_CTAR_BR(br);
> + | SPI_CTAR_CPHA(spi->mode & SPI_CPHA ? 1 : 0);
> +
> + if (!spi_controller_is_slave(dspi->master)) {
> + chip->ctar_val |= SPI_CTAR_LSBFE(spi->mode &
> + SPI_LSB_FIRST ? 1 :
> 0)
> + | SPI_CTAR_PCSSCK(pcssck)
> + | SPI_CTAR_CSSCK(cssck)
> + | SPI_CTAR_PASC(pasc)
> + | SPI_CTAR_ASC(asc)
> + | SPI_CTAR_PBR(pbr)
> + | SPI_CTAR_BR(br);
> + }
>
> spi_set_ctldata(spi, chip);
>
> @@ -970,8 +982,13 @@ static const struct regmap_config
> dspi_xspi_regmap_config[] = {
> static void dspi_init(struct fsl_dspi *dspi)
> {
> - regmap_write(dspi->regmap, SPI_MCR, SPI_MCR_MASTER |
> SPI_MCR_PCSIS |
> - (dspi->devtype_data->xspi_mode ? SPI_MCR_XSPI :
> 0));
> + unsigned int mcr = SPI_MCR_PCSIS |
> + (dspi->devtype_data->xspi_mode ? SPI_MCR_XSPI : 0);
> +
> + if (!spi_controller_is_slave(dspi->master))
> + mcr |= SPI_MCR_MASTER;
> +
> + regmap_write(dspi->regmap, SPI_MCR, mcr);
> regmap_write(dspi->regmap, SPI_SR, SPI_SR_CLEAR);
> if (dspi->devtype_data->xspi_mode)
> regmap_write(dspi->regmap, SPI_CTARE(0),
> @@ -1027,6 +1044,9 @@ static int dspi_probe(struct platform_device
> *pdev) }
> master->bus_num = bus_num;
>
> + if (of_property_read_bool(np, "spi-slave"))
> + master->slave = true;
> +
> dspi->devtype_data =
> of_device_get_match_data(>dev); if (!dspi->devtype_data) {
> dev_err(>dev, "can't get
> devtype_data\n");
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpj2qaqJ24th.pgp
Description: OpenPGP digital signature
RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
> From: gre...@linuxfoundation.org
> Sent: Saturday, December 1, 2018 11:34 PM
> To: Dexuan Cui
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; a...@canonical.com; vkuznets
> ; o...@aepfle.de; jasow...@redhat.com; Michael
> Kelley
> Subject: Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of
> channels to two workqueues
>
> On Fri, Nov 30, 2018 at 06:09:54PM +, Dexuan Cui wrote:
> > > From: KY Srinivasan
> > > Sent: Friday, November 30, 2018 9:31 AM
> > > > From: Dexuan Cui
> > > > Sent: Thursday, November 29, 2018 12:17 AM
> > > > To: gre...@linuxfoundation.org
> > > > Cc: KY Srinivasan ; Haiyang Zhang
> > > > ; Stephen Hemminger
> > > > ; linux-kernel@vger.kernel.org;
> > > > de...@linuxdriverproject.org; a...@canonical.com; vkuznets
> > > > ; o...@aepfle.de; jasow...@redhat.com;
> Michael
> > > > Kelley
> > > > Subject: RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling
> > > > of
> > > > channels to two workqueues
> > > >
> > > > > From: gre...@linuxfoundation.org
> > > > > Sent: Wednesday, November 28, 2018 11:45 PM
> > > > > >
> > > > > > There is no change in this repost. I just rebased this patch to
> > > > > > today's
> > > > > > char-misc's char-misc-next branch. Previously KY posted the patch
> with
> > > > his
> > > > > > Signed-off-by (which is kept in this repost), but there was a
> > > > > > conflict
> issue.
> > > > > >
> > > > > > Note: the patch can't be cleanly applied to char-misc's
> char-misc-linus
> > > > branch
> > > > > --
> > > > > > to do that, we need to cherry-pick the supporting patch first:
> > > > > > 4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API
> > > > > vmbus_get_outgoing_channel()")
> > > > >
> > > > > That is not going to work for the obvious reason that this dependant
> > > > > patch is not going to be merged into 4.20-final.
> > > >
> > > > It looks the dependent patch (4d3c5c69191f) is going to miss the v4.20
> > > > release.
> > > > This is not a big issue, as the dependent patch isn't really important.
> > > >
> > > > > So, what do you expect us to do here? The only way this can be
> accepted
> > > > > is to have it go into my -next branch, which means it will show up in
> > > > > 4.21-rc1, is that ok?
> > > >
> > > > Is there any chance for this patch ("Drivers: hv: vmbus: Offload the
> handling
> > > > ...") to
> > > > go into v4.20?
> > > >
> > > > If yes, I can quickly do a rebase to char-misc's char-misc-linus branch,
> > > > because actually the conflict can be very easily fixed. And I can help
> > > > to
> fix any
> > > > conflict when the dependent patch is backported to v4.20.1.
> > >
> > > This patch fixes an important bug while the patch this depends on is not
> > > critical.
> > > I suggest we revert the patch that this patch depends on
> > > and we can submit a new version of this patch that can go in now - into
> 4.20
> > > release.
> > >
> > > K. Y
> >
> > I agree.
> >
> > Hi Greg,
> > Please let us know what we can do to try to push this important fix into
> v4.20.
> >
> > Actually it's straightforward, though it looks big. And, we ave done a full
> testing
> > with the patch.
>
> Ok, you all need to figure this out on your own, sorry. Please give me
> a patch that I can actually apply to the tree if you need it merged into
> 4.20-final. This shouldn't be tough, you all have been doing this long
> enough by now...
>
> I have no bandwidth to do this myself for you,
>
> greg k-h
Hi Greg,
Please use the attached patch: I rebased the patch to today's char-misc's
char-misc-linus branch. It can also cleanly apply to Linus's master branch
today.
Please let me know in case you need me to re-post the patch in a new mail
(rather than the attachment here) or you need me to rebase the patch to
a different tree/branch.
Thanks,
Dexuan
0001-Drivers-hv-vmbus-Offload-the-handling-of-channels-to.patch
Description: 0001-Drivers-hv-vmbus-Offload-the-handling-of-channels-to.patch
