* [PATCH] pwm: meson: fix the G12A AO clock parents order
From: Neil Armstrong @ 2019-06-20 14:46 UTC (permalink / raw)
To: thierry.reding
Cc: linux-pwm, Neil Armstrong, martin.blumenstingl, linux-kernel,
linux-amlogic, linux-arm-kernel
The Amlogic G12A and G12B Documentation is wrong, the AO xtal and clk81
clock source order is reversed, and validated when adding DVFS support by
using the PWM AO D output to control the CPU supply voltage.
The vendor tree also uses the reversed xtal and clk81 order at [1].
[1] https://github.com/hardkernel/linux/blob/odroidn2-4.9.y/drivers/amlogic/pwm/pwm_meson.c#L462
Fixes: f41efceb46e6 ("pwm: meson: Add clock source configuration for Meson G12A")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/pwm/pwm-meson.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index 5e65b042c240..e15d045947bb 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -453,8 +453,17 @@ static const struct meson_pwm_data pwm_axg_ao_data = {
.num_parents = ARRAY_SIZE(pwm_axg_ao_parent_names),
};
+static const char * const pwm_g12a_ao_ab_parent_names[] = {
+ "xtal", "aoclk81", "fclk_div4", "fclk_div5"
+};
+
+static const struct meson_pwm_data pwm_g12a_ao_ab_data = {
+ .parent_names = pwm_g12a_ao_ab_parent_names,
+ .num_parents = ARRAY_SIZE(pwm_g12a_ao_ab_parent_names),
+};
+
static const char * const pwm_g12a_ao_cd_parent_names[] = {
- "aoclk81", "xtal",
+ "xtal", "aoclk81",
};
static const struct meson_pwm_data pwm_g12a_ao_cd_data = {
@@ -498,7 +507,7 @@ static const struct of_device_id meson_pwm_matches[] = {
},
{
.compatible = "amlogic,meson-g12a-ao-pwm-ab",
- .data = &pwm_axg_ao_data
+ .data = &pwm_g12a_ao_ab_data
},
{
.compatible = "amlogic,meson-g12a-ao-pwm-cd",
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] backlight: gpio-backlight: Set power state instead of brightness at probe
From: Peter Ujfalusi @ 2019-06-20 14:47 UTC (permalink / raw)
To: Daniel Thompson, Paul Kocialkowski, dri-devel, linux-fbdev,
linux-kernel
Cc: Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz,
Thomas Petazzoni, Laurent Pinchart
In-Reply-To: <29712212-0567-702b-fbc9-c0f37806d84c@linaro.org>
Daniel,
On 20/06/2019 16.56, Daniel Thompson wrote:
> On 18/06/2019 13:58, Paul Kocialkowski wrote:
>> Hi,
>>
>> On Fri, 2019-05-17 at 17:05 +0200, Paul Kocialkowski wrote:
>>> On a trivial gpio-backlight setup with a panel using the backlight but
>>> no boot software to enable it beforehand, we fall in a case where the
>>> backlight is disabled (not just blanked) and thus remains disabled when
>>> the panel gets enabled.
>>>
>>> Setting gbl->def_value via the device-tree prop allows enabling the
>>> backlight in this situation, but it will be unblanked straight away,
>>> in compliance with the binding. This does not work well when there
>>> was no
>>> boot software to display something before, since we really need to
>>> unblank
>>> by the time the panel is enabled, not before.
>>>
>>> Resolve the situation by setting the brightness to 1 at probe and
>>> managing the power state accordingly, a bit like it's done in
>>> pwm-backlight.
>>
>> Any feedback on this? I was under the impression that it could be quite
>> controversial, as it implies that the backlight can no longer be
>> enabled without a bound panel (which IMO makes good sense but could be
>> a matter to debate).
>
> My apologies. This patch brought on such severe deja-vu I got rather
> confused. Then when I went digging I've also dropped the ball on the
> same feature previously.
>
> Peter Ujfalusi provided a similar patch to yours but with a slightly
> different implementation:
> https://lore.kernel.org/patchwork/patch/1002359/
>
> On the whole I think it is important to read the GPIO pin since
> otherwise we swap problems when there bootloader does setup the
> backlight for problems where it does not.
>
> The thing I don't get is why both patches try to avoid setting the
> backlight brightness from def_value. Simple displays, especially
> monochrome ones are perfectly readable with the backlight off... zero
> brightness is not a "bad" value.
Because we might have non monochrome displays where the display is not
readable when the backlight is off and for the sake of to be consistent?
Flickering backlight is not really a nice thing during boot.
> Not sure if Peter is still willing to rev his version of this code
> (given how badly we neglected him previously) or whether you want to try
> and combine both ideas.
Nothing special, things sometimes got overlooked.
I should have been nagging you about it ;)
I think the v2 patch from me should apply just fine and it has the gpio
read as well, if not, then I might not be able to resend as I'm out of
office for a while
- Péter
>
>
> Daniel.
>
>
>>
>> Cheers,
>>
>> Paul
>>
>>> Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver")
>>> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>>> ---
>>> drivers/video/backlight/gpio_backlight.c | 19 ++++++++++++++++++-
>>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/backlight/gpio_backlight.c
>>> b/drivers/video/backlight/gpio_backlight.c
>>> index e470da95d806..c9cb97fa13d0 100644
>>> --- a/drivers/video/backlight/gpio_backlight.c
>>> +++ b/drivers/video/backlight/gpio_backlight.c
>>> @@ -57,6 +57,21 @@ static const struct backlight_ops
>>> gpio_backlight_ops = {
>>> .check_fb = gpio_backlight_check_fb,
>>> };
>>> +static int gpio_backlight_initial_power_state(struct
>>> gpio_backlight *gbl)
>>> +{
>>> + struct device_node *node = gbl->dev->of_node;
>>> +
>>> + /* If we absolutely want the backlight enabled at boot. */
>>> + if (gbl->def_value)
>>> + return FB_BLANK_UNBLANK;
>>> +
>>> + /* If there's no panel to unblank the backlight later. */
>>> + if (!node || !node->phandle)
>>> + return FB_BLANK_UNBLANK;
>>> +
>>> + return FB_BLANK_POWERDOWN;
>>> +}
>>> +
>>> static int gpio_backlight_probe_dt(struct platform_device *pdev,
>>> struct gpio_backlight *gbl)
>>> {
>>> @@ -142,7 +157,9 @@ static int gpio_backlight_probe(struct
>>> platform_device *pdev)
>>> return PTR_ERR(bl);
>>> }
>>> - bl->props.brightness = gbl->def_value;
>>> + bl->props.brightness = 1;
>>> + bl->props.power = gpio_backlight_initial_power_state(gbl);
>>> +
>>> backlight_update_status(bl);
>>> platform_set_drvdata(pdev, bl);
>
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH] pwm: meson: fix the G12A AO clock parents order
From: Neil Armstrong @ 2019-06-20 14:46 UTC (permalink / raw)
To: thierry.reding
Cc: Neil Armstrong, linux-pwm, linux-arm-kernel, linux-amlogic,
linux-kernel, martin.blumenstingl
The Amlogic G12A and G12B Documentation is wrong, the AO xtal and clk81
clock source order is reversed, and validated when adding DVFS support by
using the PWM AO D output to control the CPU supply voltage.
The vendor tree also uses the reversed xtal and clk81 order at [1].
[1] https://github.com/hardkernel/linux/blob/odroidn2-4.9.y/drivers/amlogic/pwm/pwm_meson.c#L462
Fixes: f41efceb46e6 ("pwm: meson: Add clock source configuration for Meson G12A")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/pwm/pwm-meson.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index 5e65b042c240..e15d045947bb 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -453,8 +453,17 @@ static const struct meson_pwm_data pwm_axg_ao_data = {
.num_parents = ARRAY_SIZE(pwm_axg_ao_parent_names),
};
+static const char * const pwm_g12a_ao_ab_parent_names[] = {
+ "xtal", "aoclk81", "fclk_div4", "fclk_div5"
+};
+
+static const struct meson_pwm_data pwm_g12a_ao_ab_data = {
+ .parent_names = pwm_g12a_ao_ab_parent_names,
+ .num_parents = ARRAY_SIZE(pwm_g12a_ao_ab_parent_names),
+};
+
static const char * const pwm_g12a_ao_cd_parent_names[] = {
- "aoclk81", "xtal",
+ "xtal", "aoclk81",
};
static const struct meson_pwm_data pwm_g12a_ao_cd_data = {
@@ -498,7 +507,7 @@ static const struct of_device_id meson_pwm_matches[] = {
},
{
.compatible = "amlogic,meson-g12a-ao-pwm-ab",
- .data = &pwm_axg_ao_data
+ .data = &pwm_g12a_ao_ab_data
},
{
.compatible = "amlogic,meson-g12a-ao-pwm-cd",
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] backlight: gpio-backlight: Set power state instead of brightness at probe
From: Peter Ujfalusi @ 2019-06-20 14:47 UTC (permalink / raw)
To: Daniel Thompson, Paul Kocialkowski, dri-devel, linux-fbdev,
linux-kernel
Cc: Jingoo Han, Lee Jones, Laurent Pinchart, Thomas Petazzoni,
Bartlomiej Zolnierkiewicz
In-Reply-To: <29712212-0567-702b-fbc9-c0f37806d84c@linaro.org>
Daniel,
On 20/06/2019 16.56, Daniel Thompson wrote:
> On 18/06/2019 13:58, Paul Kocialkowski wrote:
>> Hi,
>>
>> On Fri, 2019-05-17 at 17:05 +0200, Paul Kocialkowski wrote:
>>> On a trivial gpio-backlight setup with a panel using the backlight but
>>> no boot software to enable it beforehand, we fall in a case where the
>>> backlight is disabled (not just blanked) and thus remains disabled when
>>> the panel gets enabled.
>>>
>>> Setting gbl->def_value via the device-tree prop allows enabling the
>>> backlight in this situation, but it will be unblanked straight away,
>>> in compliance with the binding. This does not work well when there
>>> was no
>>> boot software to display something before, since we really need to
>>> unblank
>>> by the time the panel is enabled, not before.
>>>
>>> Resolve the situation by setting the brightness to 1 at probe and
>>> managing the power state accordingly, a bit like it's done in
>>> pwm-backlight.
>>
>> Any feedback on this? I was under the impression that it could be quite
>> controversial, as it implies that the backlight can no longer be
>> enabled without a bound panel (which IMO makes good sense but could be
>> a matter to debate).
>
> My apologies. This patch brought on such severe deja-vu I got rather
> confused. Then when I went digging I've also dropped the ball on the
> same feature previously.
>
> Peter Ujfalusi provided a similar patch to yours but with a slightly
> different implementation:
> https://lore.kernel.org/patchwork/patch/1002359/
>
> On the whole I think it is important to read the GPIO pin since
> otherwise we swap problems when there bootloader does setup the
> backlight for problems where it does not.
>
> The thing I don't get is why both patches try to avoid setting the
> backlight brightness from def_value. Simple displays, especially
> monochrome ones are perfectly readable with the backlight off... zero
> brightness is not a "bad" value.
Because we might have non monochrome displays where the display is not
readable when the backlight is off and for the sake of to be consistent?
Flickering backlight is not really a nice thing during boot.
> Not sure if Peter is still willing to rev his version of this code
> (given how badly we neglected him previously) or whether you want to try
> and combine both ideas.
Nothing special, things sometimes got overlooked.
I should have been nagging you about it ;)
I think the v2 patch from me should apply just fine and it has the gpio
read as well, if not, then I might not be able to resend as I'm out of
office for a while
- Péter
>
>
> Daniel.
>
>
>>
>> Cheers,
>>
>> Paul
>>
>>> Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver")
>>> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>>> ---
>>> drivers/video/backlight/gpio_backlight.c | 19 ++++++++++++++++++-
>>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/backlight/gpio_backlight.c
>>> b/drivers/video/backlight/gpio_backlight.c
>>> index e470da95d806..c9cb97fa13d0 100644
>>> --- a/drivers/video/backlight/gpio_backlight.c
>>> +++ b/drivers/video/backlight/gpio_backlight.c
>>> @@ -57,6 +57,21 @@ static const struct backlight_ops
>>> gpio_backlight_ops = {
>>> .check_fb = gpio_backlight_check_fb,
>>> };
>>> +static int gpio_backlight_initial_power_state(struct
>>> gpio_backlight *gbl)
>>> +{
>>> + struct device_node *node = gbl->dev->of_node;
>>> +
>>> + /* If we absolutely want the backlight enabled at boot. */
>>> + if (gbl->def_value)
>>> + return FB_BLANK_UNBLANK;
>>> +
>>> + /* If there's no panel to unblank the backlight later. */
>>> + if (!node || !node->phandle)
>>> + return FB_BLANK_UNBLANK;
>>> +
>>> + return FB_BLANK_POWERDOWN;
>>> +}
>>> +
>>> static int gpio_backlight_probe_dt(struct platform_device *pdev,
>>> struct gpio_backlight *gbl)
>>> {
>>> @@ -142,7 +157,9 @@ static int gpio_backlight_probe(struct
>>> platform_device *pdev)
>>> return PTR_ERR(bl);
>>> }
>>> - bl->props.brightness = gbl->def_value;
>>> + bl->props.brightness = 1;
>>> + bl->props.power = gpio_backlight_initial_power_state(gbl);
>>> +
>>> backlight_update_status(bl);
>>> platform_set_drvdata(pdev, bl);
>
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 1/2] ssh: Add ssh_exec_keygen interface
From: Dominick Grift @ 2019-06-20 14:46 UTC (permalink / raw)
To: Alexander Miroshnichenko; +Cc: selinux-refpolicy
In-Reply-To: <20190620144138.15172-2-alex@millerson.name>
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]
On Thu, Jun 20, 2019 at 05:41:37PM +0300, Alexander Miroshnichenko wrote:
> Signed-off-by: Alexander Miroshnichenko <alex@millerson.name>
> ---
> policy/modules/services/ssh.if | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/policy/modules/services/ssh.if b/policy/modules/services/ssh.if
> index b5bd2762ef96..0941f133711e 100644
> --- a/policy/modules/services/ssh.if
> +++ b/policy/modules/services/ssh.if
> @@ -701,6 +701,25 @@ interface(`ssh_read_user_home_files',`
> userdom_search_user_home_dirs($1)
> ')
>
> +########################################
> +## <summary>
> +## Execute the ssh key generator in the caller domain.
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain allowed to transition.
"Domain allowed access." Its not a transition. I suppose you have a use for this interface?
> +## </summary>
> +## </param>
> +#
> +interface(`ssh_exec_keygen',`
> + gen_require(`
> + type ssh_keygen_exec_t;
> + ')
> +
> + corecmd_search_bin($1)
> + can_exec($1, ssh_keygen_exec_t)
> +')
> +
> ########################################
> ## <summary>
> ## Execute the ssh key generator in the ssh keygen domain.
> --
> 2.21.0
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply
* Re: [PATCH V6 04/27] PCI: tegra: Mask AFI_INTR in runtime suspend
From: Manikanta Maddireddy @ 2019-06-20 14:46 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: thierry.reding, bhelgaas, robh+dt, mark.rutland, jonathanh,
vidyas, linux-tegra, linux-pci, devicetree
In-Reply-To: <20190620142702.GA31996@e121166-lin.cambridge.arm.com>
On 20-Jun-19 7:57 PM, Lorenzo Pieralisi wrote:
> On Tue, Jun 18, 2019 at 11:31:43PM +0530, Manikanta Maddireddy wrote:
>> AFI_INTR is unmasked in tegra_pcie_enable_controller(), mask it to avoid
>> unwanted interrupts raised by AFI after pex_rst is asserted.
>>
>> Following sequence triggers such scenario,
>> - tegra_pcie_remove() triggers runtime suspend
>> - pex_rst is asserted in runtime suspend
>> - PRSNT_MAP bit field in RP_PRIV_MISC register changes from EP_PRSNT to
>> EP_ABSNT
>> - This is sensed by AFI and triggers "Slot present pin change" interrupt
>> - tegra_pcie_isr() function accesses AFI register when runtime suspend
>> is going through power off sequence
>>
>> rmmod pci-tegra
>> pci_generic_config_write32: 108 callbacks suppressed
>> pci_bus 0002:00: 2-byte config write to 0002:00:02.0 offset 0x4c may corrupt adjacent RW1C bits
>> pci_bus 0002:00: 2-byte config write to 0002:00:02.0 offset 0x9c may corrupt adjacent RW1C bits
>> pci_bus 0002:00: 2-byte config write to 0002:00:02.0 offset 0x88 may corrupt adjacent RW1C bits
>> pci_bus 0002:00: 2-byte config write to 0002:00:02.0 offset 0x90 may corrupt adjacent RW1C bits
>> pci_bus 0002:00: 2-byte config write to 0002:00:02.0 offset 0x4 may corrupt adjacent RW1C bits
>> igb 0002:04:00.1: removed PHC on enP2p4s0f1
>> igb 0002:04:00.0: removed PHC on enP2p4s0f0
>> pci_bus 0002:00: 2-byte config write to 0002:00:01.0 offset 0x4c may corrupt adjacent RW1C bits
>> pci_bus 0002:00: 2-byte config write to 0002:00:01.0 offset 0x9c may corrupt adjacent RW1C bits
>> pci_bus 0002:00: 2-byte config write to 0002:00:01.0 offset 0x88 may corrupt adjacent RW1C bits
>> pci_bus 0002:00: 2-byte config write to 0002:00:01.0 offset 0x90 may corrupt adjacent RW1C bits
>> pci_bus 0002:00: 2-byte config write to 0002:00:01.0 offset 0x4 may corrupt adjacent RW1C bits
>> rcu: INFO: rcu_preempt self-detected stall on CPU
>> SError Interrupt on CPU0, code 0xbf000002 -- SError
>> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.1.0-rc3-next-20190405-00027-gcd8110499e6f-dirty #42
>> Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
>> pstate: 20000085 (nzCv daIf -PAN -UAO)
>> pc : tegra_pcie_isr+0x58/0x178 [pci_tegra]
>> lr : tegra_pcie_isr+0x40/0x178 [pci_tegra]
>> sp : ffff000010003da0
>> x29: ffff000010003da0 x28: 0000000000000000
>> x27: ffff8000f9e61000 x26: ffff000010fbf420
>> x25: ffff000011427f93 x24: ffff8000fa600410
>> x23: ffff00001129d000 x22: ffff00001129d000
>> x21: ffff8000f18bf3c0 x20: 0000000000000070
>> x19: 00000000ffffffff x18: 0000000000000000
>> x17: 0000000000000000 x16: 0000000000000000
>> x15: 0000000000000000 x14: ffff000008d40a48
>> x13: ffff000008d40a30 x12: ffff000008d40a20
>> x11: ffff000008d40a10 x10: ffff000008d40a00
>> x9 : ffff000008d409e8 x8 : ffff000008d40ae8
>> x7 : ffff000008d40ad0 x6 : ffff000010003e58
>> x5 : ffff8000fac00248 x4 : 0000000000000000
>> x3 : ffff000008d40b08 x2 : fffffffffffffff8
>> x1 : ffff000008d3f4e8 x0 : 00000000ffffffff
>> Kernel panic - not syncing: Asynchronous SError Interrupt
>> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.1.0-rc3-next-20190405-00027-gcd8110499e6f-dirty #42
>> Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
>> Call trace:
>> dump_backtrace+0x0/0x158
>> show_stack+0x14/0x20
>> dump_stack+0xa8/0xcc
>> panic+0x140/0x2f4
>> nmi_panic+0x6c/0x70
>> arm64_serror_panic+0x74/0x80
>> __pte_error+0x0/0x28
>> el1_error+0x84/0xf8
>> tegra_pcie_isr+0x58/0x178 [pci_tegra]
>> __handle_irq_event_percpu+0x70/0x198
>> handle_irq_event_percpu+0x34/0x88
>> handle_irq_event+0x48/0x78
>> handle_fasteoi_irq+0xb4/0x190
>> generic_handle_irq+0x24/0x38
>> __handle_domain_irq+0x5c/0xb8
>> gic_handle_irq+0x58/0xa8
>> el1_irq+0xb8/0x180
>> cpuidle_enter_state+0x138/0x358
>> cpuidle_enter+0x18/0x20
>> call_cpuidle+0x1c/0x48
>> do_idle+0x230/0x2d0
>> cpu_startup_entry+0x20/0x28
>> rest_init+0xd4/0xe0
>> arch_call_rest_init+0xc/0x14
>> start_kernel+0x444/0x470
>>
>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>> Acked-by: Thierry Reding <treding@nvidia.com>
>> ---
>> V6: No change
>>
>> V5:
>> * Added blank line before block-style comment
>>
>> V4: No change
>>
>> V3:
>> * Update the commit log and comment to reflect why this fix is required
>> * MSI interrupt is not disabled
>>
>> V2: This is new patch in V2
>>
>> drivers/pci/controller/pci-tegra.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/pci/controller/pci-tegra.c b/drivers/pci/controller/pci-tegra.c
>> index bb3c0af9c830..0453bfb2726e 100644
>> --- a/drivers/pci/controller/pci-tegra.c
>> +++ b/drivers/pci/controller/pci-tegra.c
>> @@ -1622,6 +1622,15 @@ static int tegra_pcie_disable_msi(struct tegra_pcie *pcie)
>> return 0;
>> }
>>
>> +static void tegra_pcie_disable_interrupts(struct tegra_pcie *pcie)
>> +{
>> + u32 value;
>> +
>> + value = afi_readl(pcie, AFI_INTR_MASK);
>> + value &= ~AFI_INTR_MASK_INT_MASK;
>> + afi_writel(pcie, value, AFI_INTR_MASK);
>> +}
>> +
>> static int tegra_pcie_get_xbar_config(struct tegra_pcie *pcie, u32 lanes,
>> u32 *xbar)
>> {
>> @@ -2467,6 +2476,12 @@ static int __maybe_unused tegra_pcie_pm_suspend(struct device *dev)
>>
>> tegra_pcie_disable_ports(pcie);
>>
>> + /*
>> + * AFI_INTR is unmasked in tegra_pcie_enable_controller(), mask it to
>> + * avoid unwanted interrupts raised by AFI after pex_rst is asserted.
>> + */
>> + tegra_pcie_disable_interrupts(pcie);
> When do you re-enable it ? I assume it is enabled by default for
> a reason, so if you disable on suspend you renable it on resume.
>
> Please explain or I will drop this patch from the series.
>
> Lorenzo
Power on reset value of AFI_INTR_MASK_INT_MASK is 0, it is not enabled by default.
In suspend AFI reset is asserted, so in resume AFI programming has to be done
again including AFI_INTR_MASK_INT_MASK. Even if I don't disable here, in resume
it has to be enabled after bringing AFI out of reset.
tegra_pcie_pm_resume() -> tegra_pcie_enable_controller() will enable it.
Manikanta
>
>> +
>> if (pcie->soc->program_uphy) {
>> err = tegra_pcie_phy_power_off(pcie);
>> if (err < 0)
>> --
>> 2.17.1
>>
^ permalink raw reply
* [usb:usb-testing 46/46] drivers/usb//misc/adutux.c:375:4: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}'
From: kbuild test robot @ 2019-06-20 14:45 UTC (permalink / raw)
To: Daniel M German; +Cc: kbuild-all, linux-usb, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 8127 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
head: f1ac9f310d6d883b3551f4cb948eb441c780b59d
commit: f1ac9f310d6d883b3551f4cb948eb441c780b59d [46/46] usb: clean up some of the computations in adu_read
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f1ac9f310d6d883b3551f4cb948eb441c780b59d
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
In file included from include/linux/printk.h:332:0,
from include/linux/kernel.h:15,
from drivers/usb//misc/adutux.c:19:
drivers/usb//misc/adutux.c: In function 'adu_read':
>> drivers/usb//misc/adutux.c:375:4: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}' [-Wformat=]
"%s : while, data_in_secondary=%lu, status=%d\n",
^
include/linux/dynamic_debug.h:125:15: note: in definition of macro '__dynamic_func_call'
func(&id, ##__VA_ARGS__); \
^~~~~~~~~~~
include/linux/dynamic_debug.h:157:2: note: in expansion of macro '_dynamic_func_call'
_dynamic_func_call(fmt,__dynamic_dev_dbg, \
^~~~~~~~~~~~~~~~~~
include/linux/device.h:1494:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~~~~~
include/linux/device.h:1494:23: note: in expansion of macro 'dev_fmt'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~~~~~
drivers/usb//misc/adutux.c:374:3: note: in expansion of macro 'dev_dbg'
dev_dbg(&dev->udev->dev,
^~~~~~~
vim +375 drivers/usb//misc/adutux.c
339
340 static ssize_t adu_read(struct file *file, __user char *buffer, size_t count,
341 loff_t *ppos)
342 {
343 struct adu_device *dev;
344 size_t bytes_read = 0;
345 size_t bytes_to_read = count;
346 int retval = 0;
347 int timeout = 0;
348 int should_submit = 0;
349 unsigned long flags;
350 DECLARE_WAITQUEUE(wait, current);
351
352 dev = file->private_data;
353 if (mutex_lock_interruptible(&dev->mtx))
354 return -ERESTARTSYS;
355
356 /* verify that the device wasn't unplugged */
357 if (dev->udev == NULL) {
358 retval = -ENODEV;
359 pr_err("No device or device unplugged %d\n", retval);
360 goto exit;
361 }
362
363 /* verify that some data was requested */
364 if (count == 0) {
365 dev_dbg(&dev->udev->dev, "%s : read request of 0 bytes\n",
366 __func__);
367 goto exit;
368 }
369
370 timeout = COMMAND_TIMEOUT;
371 dev_dbg(&dev->udev->dev, "%s : about to start looping\n", __func__);
372 while (bytes_to_read) {
373 size_t data_in_secondary = dev->secondary_tail - dev->secondary_head;
374 dev_dbg(&dev->udev->dev,
> 375 "%s : while, data_in_secondary=%lu, status=%d\n",
376 __func__, data_in_secondary,
377 dev->interrupt_in_urb->status);
378
379 if (data_in_secondary) {
380 /* drain secondary buffer */
381 size_t amount = min(bytes_to_read, data_in_secondary);
382 if (copy_to_user(buffer, dev->read_buffer_secondary+dev->secondary_head, amount)) {
383 retval = -EFAULT;
384 goto exit;
385 }
386 dev->secondary_head += amount;
387 bytes_read += amount;
388 bytes_to_read -= amount;
389 } else {
390 /* we check the primary buffer */
391 spin_lock_irqsave (&dev->buflock, flags);
392 if (dev->read_buffer_length) {
393 /* we secure access to the primary */
394 char *tmp;
395 dev_dbg(&dev->udev->dev,
396 "%s : swap, read_buffer_length = %d\n",
397 __func__, dev->read_buffer_length);
398 tmp = dev->read_buffer_secondary;
399 dev->read_buffer_secondary = dev->read_buffer_primary;
400 dev->read_buffer_primary = tmp;
401 dev->secondary_head = 0;
402 dev->secondary_tail = dev->read_buffer_length;
403 dev->read_buffer_length = 0;
404 spin_unlock_irqrestore(&dev->buflock, flags);
405 /* we have a free buffer so use it */
406 should_submit = 1;
407 } else {
408 /* even the primary was empty - we may need to do IO */
409 if (!dev->read_urb_finished) {
410 /* somebody is doing IO */
411 spin_unlock_irqrestore(&dev->buflock, flags);
412 dev_dbg(&dev->udev->dev,
413 "%s : submitted already\n",
414 __func__);
415 } else {
416 /* we must initiate input */
417 dev_dbg(&dev->udev->dev,
418 "%s : initiate input\n",
419 __func__);
420 dev->read_urb_finished = 0;
421 spin_unlock_irqrestore(&dev->buflock, flags);
422
423 usb_fill_int_urb(dev->interrupt_in_urb, dev->udev,
424 usb_rcvintpipe(dev->udev,
425 dev->interrupt_in_endpoint->bEndpointAddress),
426 dev->interrupt_in_buffer,
427 usb_endpoint_maxp(dev->interrupt_in_endpoint),
428 adu_interrupt_in_callback,
429 dev,
430 dev->interrupt_in_endpoint->bInterval);
431 retval = usb_submit_urb(dev->interrupt_in_urb, GFP_KERNEL);
432 if (retval) {
433 dev->read_urb_finished = 1;
434 if (retval == -ENOMEM) {
435 retval = bytes_read ? bytes_read : -ENOMEM;
436 }
437 dev_dbg(&dev->udev->dev,
438 "%s : submit failed\n",
439 __func__);
440 goto exit;
441 }
442 }
443
444 /* we wait for I/O to complete */
445 set_current_state(TASK_INTERRUPTIBLE);
446 add_wait_queue(&dev->read_wait, &wait);
447 spin_lock_irqsave(&dev->buflock, flags);
448 if (!dev->read_urb_finished) {
449 spin_unlock_irqrestore(&dev->buflock, flags);
450 timeout = schedule_timeout(COMMAND_TIMEOUT);
451 } else {
452 spin_unlock_irqrestore(&dev->buflock, flags);
453 set_current_state(TASK_RUNNING);
454 }
455 remove_wait_queue(&dev->read_wait, &wait);
456
457 if (timeout <= 0) {
458 dev_dbg(&dev->udev->dev,
459 "%s : timeout\n", __func__);
460 retval = bytes_read ? bytes_read : -ETIMEDOUT;
461 goto exit;
462 }
463
464 if (signal_pending(current)) {
465 dev_dbg(&dev->udev->dev,
466 "%s : signal pending\n",
467 __func__);
468 retval = bytes_read ? bytes_read : -EINTR;
469 goto exit;
470 }
471 }
472 }
473 }
474
475 retval = bytes_read;
476 /* if the primary buffer is empty then use it */
477 spin_lock_irqsave(&dev->buflock, flags);
478 if (should_submit && dev->read_urb_finished) {
479 dev->read_urb_finished = 0;
480 spin_unlock_irqrestore(&dev->buflock, flags);
481 usb_fill_int_urb(dev->interrupt_in_urb, dev->udev,
482 usb_rcvintpipe(dev->udev,
483 dev->interrupt_in_endpoint->bEndpointAddress),
484 dev->interrupt_in_buffer,
485 usb_endpoint_maxp(dev->interrupt_in_endpoint),
486 adu_interrupt_in_callback,
487 dev,
488 dev->interrupt_in_endpoint->bInterval);
489 if (usb_submit_urb(dev->interrupt_in_urb, GFP_KERNEL) != 0)
490 dev->read_urb_finished = 1;
491 /* we ignore failure */
492 } else {
493 spin_unlock_irqrestore(&dev->buflock, flags);
494 }
495
496 exit:
497 /* unlock the device */
498 mutex_unlock(&dev->mtx);
499
500 return retval;
501 }
502
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 53197 bytes --]
^ permalink raw reply
* [Buildroot] [PATCH 26/27] package/sqlite: work around build timeout
From: Giulio Benetti @ 2019-06-20 14:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20190620164252.399af7b6@windsurf>
Hello Thomas,
Il 20/06/2019 16:42, Thomas Petazzoni ha scritto:
> Hello Giulio,
>
> On Fri, 14 Jun 2019 23:03:45 +0200
> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:
>
>> With Microblaze Gcc version 4.9 build hangs due to a bug discovered for
>> Gcc 4.9 only. Since Gcc 4.9 is not maintaned anymore it doesn't make
>> sense to report this bug in Gcc bugzilla and use
>> BR2_TOOLCHAIN_HAS_GCC_BUG_. So let's check if we're building for
>> Microblaze with Gcc version < 5.x and work around the bug forcing the
>> use of -O0.
>
> I've applied, but this patch had two issues, which I fixed before
> applying. See below.
>
>> +ifeq ($(BR2_microblaze)$(BR2_TOOLCHAIN_GCC_AT_LEAST_5),y)
>
> This condition is incorrectly written: the way you wrote it, if the
> architecture is *not* Microblaze, but BR2_TOOLCHAIN_GCC_AT_LEAST_5=y,
> the condition will evaluate to true.
Oops, I see.
> So basically this condition not only passes -O0 on Microblaze with gcc
> < 5.x, but it also passes -O0 on all architectures other than
> Microblaze that use gcc >= 5.x. Very bad!
Yes, you're right, I didn't think about drawbacks about it honestly.
> The correct way is:
>
> ifeq ($(BR2_microblaze):$(BR2_TOOLCHAIN_GCC_AT_LEAST_5),y:)
>
> This really tests that BR2_microblaze=y and
> BR2_TOOLCHAIN_GCC_AT_LEAST_5 is empty.
Ah, thank you! New thing learnt :)
>> +SQLITE_CFLAGS += -O0
>
> Here, you completely leave TARGET_CFLAGS unused, which is not good, as
> they were used before (in what is now the else condition).
>
> So I changed to += $(TARGET_CFLAGS) -O0
Aaaah, again... Thanks for fixing and applying.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
^ permalink raw reply
* Re: HiFive Unleashed DT problem with 5.3-rc1 upstream kernel
From: Anup Patel @ 2019-06-20 14:45 UTC (permalink / raw)
To: Bin Meng
Cc: Damien Le Moal, mafm@debian.org, abner.chang@hpe.com,
david.abdurachmanov@gmail.com, khilman@baylibre.com,
mark.corbin@embecosm.com, palmer@sifive.com, rjones@redhat.com,
Atish Patra, Anup Patel, Alistair Francis, yash.shah@sifive.com,
paul.walmsley@sifive.com, merker@debian.org,
schwab@linux-m68k.org, linux-riscv@lists.infradead.org,
hch@lst.de
In-Reply-To: <CAEUhbmUyJKRaP+hHHmc_JuP808CdKCU3sDLD7mN==FDWew3BmA@mail.gmail.com>
On Thu, Jun 20, 2019 at 7:14 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Anup,
>
> On Thu, Jun 20, 2019 at 11:20 AM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Thu, Jun 20, 2019 at 1:36 AM Atish Patra <Atish.Patra@wdc.com> wrote:
> > >
> > > On Wed, 2019-06-19 at 13:02 -0700, Atish Patra wrote:
> > > > Hi All,
> > > >
> > > > We have been waiting for upstream kernel to boot on HiFive Unleashed
> > > > for some time. Finally, all the required drivers will be available in
> > > > 5.3-rc1 as Yash[1] & Paul's[2] patches are queued for merging. Yay!!
> > > >
> > > > However, the DT/drivers in kernel are not backward compatible with
> > > > the
> > > > DT provided by FSBL. That means, everybody need to upgrade to the new
> > > > DT if they want to use upstream kernel. Here are some possible
> > > > approaches to allow a smooth transition.
> > > >
> > > > 1. Embedd the DT in OpenSBI directly and build it by default for
> > > > unleashed platform. (discussed in OpenSBI mailing list [3])
> > > >
> > > > Pros: No change in anybody's build system as long as they use latest
> > > > OpenSBI.
> > > >
> > > > Cons: This sets a bad precedent for future platforms as OpenSBI
> > > > should
> > > > not be the place to keep/maintain device tress.
> > > >
> > > > It will also break non-Linux OS that have not upgraded their DT to
> > > > match with kernel.
> > > >
> > > > 2. Link the updated DTB maintained by kernel using
> > > > FW_PAYLOAD_FDT_PATH
> > > > in OpenSBI.
> > > >
> > > > Pros: DT is maintained by kernel and OpenSBI just use the already
> > > > built
> > > > DTB.
> > > >
> > > > Cons: Creates a dependancy on Linux build system.
> > > > All Linux distro maintainers now have to update their build script to
> > > > add that option and all documentation need to be updated.
> > > >
> > > > 3. Update FSBL:
> > > >
> > > > Pros: Cleanest approach.
> > > >
> > > > Cons: Everybody has to upgrade the FSBL which is not a simple ask for
> > > > everyone. There is no FSBL binary available publicly as well. So
> > > > everybody has to build FSBL first.
> > > >
> > > > Any other possible solutions?
> > > >
> > > > Till now, 2 seems to be the preferred choice for now. Approach 3 is
> > > > also okay for longer term solution (given that FSBL binary and
> > > > instructions are available timely). But approach 2 requires extra
> > > > work
> > > > on distro maintainers. That's why we want to get an agreement with
> > > > them
> > > > before recommonding any specific approach to anybody in the
> > > > community.
> > > >
> > > > Thoughts ?
> > > >
> > >
> > > Argh. I messed up the subject line first time.
> > > Sorry for the noise.
> >
> > I have 4th option which is even cleaner that 3rd option
> >
> > 4. U-Boot_SPL/Coreboot replace FSBL
> > The U-Boot_SPL/Coreboot will replace FSBL and load OpenSBI
> > FW_DYNAMIC, Platform DTB, and U-Boot_S_mode from boot
> > device (MMC/Flash). We can update OpenSBI FW_DYNAMIC,
> > Platform DTB, or U-Boot_S_mode separately anytime without
> > updating other images.
> >
> > Pros: Better than option 3
> >
> > Cons: None that I can think of.
> >
> > IMHO, it's right time replace FSBL with U-Boot_SPL/Coreboot
> > once and for all. Also, running entire U-Boot in M-mode is just
> > an overkill.
> >
>
> I think you mean entire U-Boot "proper" in M-mode? I don't understand
> why running U-Boot in M-mode is an overkill.
I meant in-context of SiFive Unleashed boot-flow. Replacing FSBL with
U-Boot "proper" in M-mode is an overkill (my opinion).
Although, there is one use-case of U-Boot M-mode for SiFive Unleashed
board which is HW validation (mentioned by Troy).
>
> OpenSBI can be built as a generic SBI library with platform
> abstraction and used external firmware and bootloader. With such
> configuration, U-Boot can be linked with OpenSBI in M-mode. I heard
> there is an EDK2 port in progress (also M-mode?). I would say it's not
> an overkill but a validation of OpenSBI as a generic SBI library :)
When you link OpenSBI as library to external firmware (U-Boot M-mode
OR EDK2), it becomes RUNTIME SBI firmware in-addition to being a
bootloaders. This is a very different use-case as compared to replacing
FSBL.
>
> Having said that, I like the option 4 using U-Boot_SPL to replace
> FSBL, for the reason of using the same bootloader technology stack.
Yes, it nicely replaces most SiFive Unleashed boot-flow components
with U-Boot components (SPL and U-Boot proper).
Regards,
Anup
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [Xen-devel] [Qemu-devel] [PATCH v2 1/4] xen: Fix build with public headers
From: Anthony PERARD @ 2019-06-20 14:44 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: xen-devel, Paul Durrant, Stefano Stabellini, qemu-devel
In-Reply-To: <20190618121408.GM28525@redhat.com>
On Tue, Jun 18, 2019 at 01:14:08PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 18, 2019 at 12:23:38PM +0100, Anthony PERARD wrote:
> > Following 37677d7db3 "Clean up a few header guard symbols", QEMU start
> > to fail to build:
> >
> > In file included from ~/xen/tools/../tools/include/xen/io/blkif.h:31:0,
> > from ~/xen/tools/qemu-xen-dir/hw/block/xen_blkif.h:5,
> > from ~/xen/tools/qemu-xen-dir/hw/block/xen-block.c:22:
> > ~/xen/tools/../tools/include/xen/io/ring.h:68:0: error: "__CONST_RING_SIZE" redefined [-Werror]
> > #define __CONST_RING_SIZE(_s, _sz) \
> >
> > In file included from ~/xen/tools/qemu-xen-dir/hw/block/xen_blkif.h:4:0,
> > from ~/xen/tools/qemu-xen-dir/hw/block/xen-block.c:22:
> > ~/xen/tools/qemu-xen-dir/include/hw/xen/io/ring.h:66:0: note: this is the location of the previous definition
> > #define __CONST_RING_SIZE(_s, _sz) \
> >
> > The issue is that some public xen headers have been imported (by
> > f65eadb639 "xen: import ring.h from xen") but not all. With the change
> > in the guards symbole, the ring.h header start to be imported twice.
>
> Ah, so the include/hw/xen/io/ring.h file in tree is a copy of
> /usr/include/xen/io/ring.h from xen-devel. Previously both
> these used "#ifndef __XEN_PUBLIC_IO_RING_H__". After
> the header guard cleanup in 37677d7db3, our local copy used a
> different header guard from the installed copy & thus we're
> not protected from dual inclusion.
>
> IMHO the right solutions here are either
>
> - Don't copy public Xen headers into our tree
> - Keep our Xen header copies identical to the originals
>
> Importing public headers and then changing them locally is the worst
> thing to do. With that in mind I think we should revert the part of
> commit 37677d7db3 that touched the imported Xen headers.
Yes, it's propably a better thing to do. So, I'm going to update the
series and do:
- revert part of 37677d7db3
- import the public headers that depends on ring.h. Or in other words,
the one that describe an interface with a guest.
I'll do some modification on the headers but only to remove the stuff
that QEMU doesn't need (like how to make an hypercall).
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: linux not getting gpio interrupts on xenomai 3.0.8 on raspberrypi raspbian/stretch kernel 4.9
From: Greg Gallagher @ 2019-06-20 14:45 UTC (permalink / raw)
To: Harco Kuppens; +Cc: Jan Kiszka, Xenomai@xenomai.org
In-Reply-To: <c677c9b5-67ed-ee87-1e95-3ee3185c73c4@cs.ru.nl>
Hi,
On Thu, Jun 20, 2019 at 10:36 AM Harco Kuppens <h.kuppens@cs.ru.nl> wrote:
>
>
>
> Op 20/06/2019 om 09:37 schreef Jan Kiszka:
> > On 19.06.19 23:52, Harco Kuppens via Xenomai wrote:
> >>
> >>
> >> Op 19/06/2019 om 17:00 schreef Greg Gallagher:
> >>> On Wed, Jun 19, 2019 at 8:44 AM Harco Kuppens <h.kuppens@cs.ru.nl>
> >>> wrote:
> >>>> The ipipe patched not entirely cleanly on the rpi kernel source; I
> >>>> had to
> >>>> make little changes in the patch, but not anything really
> >>>> seriously. So I
> >>>> expect it to be fine.
> >>>>
> >>>> I used the rasbpian kernel source because it has better support for
> >>>> the
> >>>> raspberry pi's and mainly because it has better support for the
> >>>> gpio pins in
> >>>> its kernel.
> >>>>
> >>>> However to help you debug I did a similar install using the
> >>>> mainline kernel
> >>>> source. The ipipe patch just worked smoothly, however to get the
> >>>> gpio pins
> >>>> running in xenomai I had to still port some code of the file
> >>>>
> >>>> ./drivers/pinctrl/bcm/pinctrl-bcm2835.c
> >>>>
> >>> What did you have to change here to get the pins to work with Xenomai?
> >>> You shouldn't need to change anything here. If you did then it may be
> >>> a bug in the ipipe. Can you try with 4.14 ipipe ?
> >> I did try with ipipe 4.19 and when compiling the kernel I got lot of
> >> errors.
> >> Some I could solve, but at the end I gave up.
> >>
> >> See my notes on
> >> https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/__INSTALL_FAILURES__/install__compile_vanilla_kernel_4.19_with_xenomai_3.0.8__assert_error.txt
> >>
> >> Maybe this is also interesting for you.
> >>
> >
> > 4.19 requires Xenomai master. See our CI (e.g.
> > https://travis-ci.com/xenomai-ci/xenomai/jobs/209347407) for a working
> > setup.
> >
> > Jan
>
> ok, I used the master branch of xenomai, and yes it compiles the kernel
> ok!!
>
> You find my installation description and findings at:
>
> https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/installation_of_xenomai_master_on_mainline_kernel_branch_v4.19.33_from_kernel.org__problem_linux_gpio.md
>
> However I still get the same problem that the xenomai gpio ports are
> wrongly numbered!
> And within linux the gpio pins are also not working.
> In my other builds I fixed this with the pinctrl_bcm2835.c file I
> patched for rpi(raspbian) 4.9 kernel.
> You can find this file at :
> https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/how_pinctrl-bcm2835_patch_for_rpi-4.9_is_derived/rpi-4.9.y.ipipe-patched/pinctrl-bcm2835.c
>
> However using that file didn't work here, because I got errors about
> irq_set_lockdep_class function. However this function wasn't even used
> in the mainline version of pinctrl_bcm2835.c .
> I probably have to patch it somehow to match the much newer kernel.
>
> But I will wait first if Greg Gallagher finds something for the 4.9.51
> build.
> Hopefully he finds what is wrong with that build.
>
Do you have sysfs interface turned on when building the mainline
kernels? Dumb question but it was turned off by default when I was
doing my builds.
Should be under Device Drivers => GPIO Support -> /sys/class/gpio
(sysfs interface) when you do a menuconfig.
> Anyway all builds I did for the raspberry pi 2/3 with mainline kernels
> 4.9/4.14/4.19 with the official pipeline/xenomai patched have xenomai
> running ok. However they don't have the gpio pins working for the
> raspberry pi. Neither in linux nor for the realtime cobalt kernel.
>
> Best regards,
> Harco Kuppens
>
-Greg
^ permalink raw reply
* [U-Boot] [PATCH] fastboot: Add "is-userspace" variable
From: Igor Opaniuk @ 2019-06-20 14:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20190620134026.3587-1-semen.protsenko@linaro.org>
Hi Sam,
On Thu, Jun 20, 2019 at 4:40 PM Sam Protsenko
<semen.protsenko@linaro.org> wrote:
>
> As per documentation [1], Android-Q requires for bootloader to provide
> "is-userspace" variable. "no" value should be always returned. This
> patch implements this fastboot variable.
>
> [1] https://android.googlesource.com/platform/system/core/+/master/fastboot/README.md#client-variables
>
> Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
> ---
> drivers/fastboot/fb_getvar.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index 9ee5054485..fd0823b2bf 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -28,6 +28,7 @@ static void getvar_partition_type(char *part_name, char *response);
> #if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
> static void getvar_partition_size(char *part_name, char *response);
> #endif
> +static void getvar_is_userspace(char *var_parameter, char *response);
>
> static const struct {
> const char *variable;
> @@ -78,6 +79,9 @@ static const struct {
> .variable = "partition-size",
> .dispatch = getvar_partition_size
> #endif
> + }, {
> + .variable = "is-userspace",
> + .dispatch = getvar_is_userspace
> }
> };
>
> @@ -243,6 +247,11 @@ static void getvar_partition_size(char *part_name, char *response)
> }
> #endif
>
> +static void getvar_is_userspace(char *var_parameter, char *response)
> +{
> + fastboot_okay("no", response);
> +}
> +
> /**
> * fastboot_getvar() - Writes variable indicated by cmd_parameter to response.
> *
> --
> 2.20.1
>
Reviewed-by: Igor Opaniuk <igor.opaniuk@toradex.com>
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opaniuk at gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
^ permalink raw reply
* ✓ Fi.CI.IGT: success for GuC messaging enable/disable tweaks
From: Patchwork @ 2019-06-20 14:45 UTC (permalink / raw)
To: Daniele Ceraolo Spurio; +Cc: intel-gfx
In-Reply-To: <20190619214351.12000-1-daniele.ceraolospurio@intel.com>
== Series Details ==
Series: GuC messaging enable/disable tweaks
URL : https://patchwork.freedesktop.org/series/62412/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6312_full -> Patchwork_13354_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_13354_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_eio@in-flight-suspend:
- shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ]) +2 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl3/igt@gem_eio@in-flight-suspend.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-kbl3/igt@gem_eio@in-flight-suspend.html
* igt@gem_persistent_relocs@forked-faulting-reloc-thrashing:
- shard-snb: [PASS][3] -> [DMESG-WARN][4] ([fdo#110789] / [fdo#110913 ])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb6/igt@gem_persistent_relocs@forked-faulting-reloc-thrashing.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-snb4/igt@gem_persistent_relocs@forked-faulting-reloc-thrashing.html
* igt@gem_softpin@noreloc-s3:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108] / [fdo#107773])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl6/igt@gem_softpin@noreloc-s3.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-skl5/igt@gem_softpin@noreloc-s3.html
* igt@gem_tiled_swapping@non-threaded:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108686])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl8/igt@gem_tiled_swapping@non-threaded.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-apl6/igt@gem_tiled_swapping@non-threaded.html
* igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb1/igt@i915_pm_rc6_residency@rc6-accuracy.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-snb2/igt@i915_pm_rc6_residency@rc6-accuracy.html
* igt@i915_suspend@debugfs-reader:
- shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +3 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl2/igt@i915_suspend@debugfs-reader.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-apl6/igt@i915_suspend@debugfs-reader.html
* igt@i915_suspend@sysfs-reader:
- shard-kbl: [PASS][13] -> [INCOMPLETE][14] ([fdo#103665] / [fdo#108767])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl4/igt@i915_suspend@sysfs-reader.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-kbl4/igt@i915_suspend@sysfs-reader.html
* igt@kms_frontbuffer_tracking@fbc-2p-rte:
- shard-hsw: [PASS][15] -> [SKIP][16] ([fdo#109271]) +26 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw8/igt@kms_frontbuffer_tracking@fbc-2p-rte.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-hsw1/igt@kms_frontbuffer_tracking@fbc-2p-rte.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-gtt:
- shard-skl: [PASS][17] -> [FAIL][18] ([fdo#103167])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl7/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-gtt.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-skl2/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-gtt.html
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- shard-skl: [PASS][19] -> [FAIL][20] ([fdo#103191])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl3/igt@kms_pipe_crc_basic@hang-read-crc-pipe-c.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-skl6/igt@kms_pipe_crc_basic@hang-read-crc-pipe-c.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl: [PASS][21] -> [INCOMPLETE][22] ([fdo#103665])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-kbl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145]) +1 similar issue
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-skl6/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][25] -> [FAIL][26] ([fdo#99912])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl6/igt@kms_setmode@basic.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-apl1/igt@kms_setmode@basic.html
#### Possible fixes ####
* igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-snb: [DMESG-WARN][27] ([fdo#110789] / [fdo#110913 ]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb4/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-snb5/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
* igt@gem_persistent_relocs@forked-thrashing:
- shard-apl: [DMESG-WARN][29] ([fdo#110913 ]) -> [PASS][30]
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl5/igt@gem_persistent_relocs@forked-thrashing.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-apl4/igt@gem_persistent_relocs@forked-thrashing.html
* igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-kbl: [DMESG-WARN][31] ([fdo#110913 ]) -> [PASS][32] +1 similar issue
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl4/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-kbl4/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
* igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge:
- shard-snb: [SKIP][33] ([fdo#109271] / [fdo#109278]) -> [PASS][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-snb2/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [FAIL][35] ([fdo#104873]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-glk8/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-glk1/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite:
- shard-hsw: [SKIP][37] ([fdo#109271]) -> [PASS][38] +24 similar issues
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw1/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-hsw7/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl: [DMESG-WARN][39] ([fdo#108566]) -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl3/igt@kms_frontbuffer_tracking@fbc-suspend.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-apl4/igt@kms_frontbuffer_tracking@fbc-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-skl: [INCOMPLETE][41] ([fdo#104108]) -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-skl10/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
* igt@kms_plane@plane-panning-bottom-right-pipe-b-planes:
- shard-snb: [SKIP][43] ([fdo#109271]) -> [PASS][44] +1 similar issue
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@kms_plane@plane-panning-bottom-right-pipe-b-planes.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-snb2/igt@kms_plane@plane-panning-bottom-right-pipe-b-planes.html
* igt@kms_setmode@basic:
- shard-hsw: [FAIL][45] ([fdo#99912]) -> [PASS][46]
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw7/igt@kms_setmode@basic.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/shard-hsw1/igt@kms_setmode@basic.html
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#107773]: https://bugs.freedesktop.org/show_bug.cgi?id=107773
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789
[fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (10 -> 9)
------------------------------
Missing (1): shard-iclb
Build changes
-------------
* Linux: CI_DRM_6312 -> Patchwork_13354
CI_DRM_6312: 034e3ac6a2d180d188da927388b60c7e62c5655b @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5061: c88ced79a7b71aec58f1d9c5c599ac2f431bcf7a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13354: 99d49d7e5f42e6cfdc78d74d7006705ab044bcb5 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13354/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] slub: Don't panic for memcg kmem cache creation failure
From: Shakeel Butt @ 2019-06-20 14:44 UTC (permalink / raw)
To: Michal Hocko
Cc: Johannes Weiner, Christoph Lameter, Andrew Morton, Roman Gushchin,
Pekka Enberg, David Rientjes, Joonsoo Kim, Cgroups, Linux MM,
LKML, Dave Hansen
In-Reply-To: <20190620055028.GA12083@dhcp22.suse.cz>
On Wed, Jun 19, 2019 at 10:50 PM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Wed 19-06-19 16:25:14, Shakeel Butt wrote:
> > Currently for CONFIG_SLUB, if a memcg kmem cache creation is failed and
> > the corresponding root kmem cache has SLAB_PANIC flag, the kernel will
> > be crashed. This is unnecessary as the kernel can handle the creation
> > failures of memcg kmem caches.
>
> AFAICS it will handle those by simply not accounting those objects
> right?
>
The memcg kmem cache creation is async. The allocation has already
been decided not to be accounted on creation trigger. If memcg kmem
cache creation is failed, it will fail silently and the next
allocation will trigger the creation process again.
> > Additionally CONFIG_SLAB does not
> > implement this behavior. So, to keep the behavior consistent between
> > SLAB and SLUB, removing the panic for memcg kmem cache creation
> > failures. The root kmem cache creation failure for SLAB_PANIC correctly
> > panics for both SLAB and SLUB.
>
> I do agree that panicing is really dubious especially because it opens
> doors to shut the system down from a restricted environment. So the
> patch makes sesne to me.
>
> I am wondering whether SLAB_PANIC makes sense in general though. Why is
> it any different from any other essential early allocations? We tend to
> not care about allocation failures for those on bases that the system
> must be in a broken state to fail that early already. Do you think it is
> time to remove SLAB_PANIC altogether?
>
That would need some investigation into the history of SLAB_PANIC. I
will look into it.
> > Reported-by: Dave Hansen <dave.hansen@intel.com>
> > Signed-off-by: Shakeel Butt <shakeelb@google.com>
>
> Acked-by: Michal Hocko <mhocko@suse.com>
Thanks.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v17 02/10] ACPI: add some GHES structures and macros definition
From: gengdongjiu @ 2019-06-20 14:04 UTC (permalink / raw)
To: Igor Mammedov
Cc: peter.maydell, ehabkost, kvm, mst, mtosatti, qemu-devel, linuxarm,
shannon.zhaosl, zhengxiang9, qemu-arm, james.morse, xuwei5,
jonathan.cameron, pbonzini, lersek, rth
In-Reply-To: <20190620141052.370788fb@redhat.com>
Hi Igor,
Thanks for your review.
On 2019/6/20 20:10, Igor Mammedov wrote:
>> + */
>> +struct AcpiGenericErrorStatus {
>> + /* It is a bitmask composed of ACPI_GEBS_xxx macros */
>> + uint32_t block_status;
>> + uint32_t raw_data_offset;
>> + uint32_t raw_data_length;
>> + uint32_t data_length;
>> + uint32_t error_severity;
>> +} QEMU_PACKED;
>> +typedef struct AcpiGenericErrorStatus AcpiGenericErrorStatus;
> there shouldn't be packed structures,
> is it a leftover from previous version?
I remember some people suggest to add QEMU_PACKED before, anyway I will remove it in my next version patch.
>
>> +
>> +/*
>> + * Masks for block_status flags above
>> + */
>> +#define ACPI_GEBS_UNCORRECTABLE 1
>> +
>> +/*
^ permalink raw reply
* [LTP] [PATCH v2] syscalls/ioctl08: add file deduplication testcases
From: Amir Goldstein @ 2019-06-20 14:43 UTC (permalink / raw)
To: ltp
In-Reply-To: <20190325101404.GA20297@dell5510>
On Mon, Mar 25, 2019 at 12:14 PM Petr Vorel <pvorel@suse.cz> wrote:
>
> Hi Christian,
>
> > This adds tests for the ioctl request FIDEDUPERANGE
> > on a btrfs device.
>
> > These tests set the contents of two files, and checks
> > if the following entities are set correctly after
> > the ioctl call:
>
> > - errno (set by ioctl)
> > - number of deduplicated bytes
> > - status field of the file_dedupe_range_info struct
>
> ...
> > +++ b/testcases/kernel/syscalls/ioctl/ioctl08.c
> > @@ -0,0 +1,131 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (c) 2019 SUSE LLC
> > + * Author: Christian Amann <camann@suse.com>
> > + *
> > + */
> > +
> > +/*
> > + * Tests the ioctl functionality to deduplicate fileranges using
> > + * btrfs filesystem.
> > + *
> > + * 1) Sets the same contents for two files and deduplicates it.
> > + * Deduplicates 3 bytes and set the status to
> > + * FILE_DEDUPE_RANGE_SAME.
> > + * 2) Sets different content for two files and tries to
> > + * deduplicate it. 0 bytes get deduplicated and status is
> > + * set to FILE_DEDUPE_RANGE_DIFFERS.
> > + * 3) Sets same content for two files but sets the length to
> > + * deduplicate to -1. ioctl(FIDEDUPERANGE) fails with EINVAL.
> > + */
> > +
> LGTM, going to apply it with adding
> #include "config.h" here (that's needed for detecting HAVE_STRUCT_FILE_DEDUPE_RANGE
FYI, This test fails on kernel without btrfs support.
WARNING: failed to open /dev/btrfs-control, skipping device
registration: No such file or directory
safe_macros.c:757: BROK: tst_test.c:752: mount(/dev/loop0, mnt_point,
btrfs, 0, (nil)) failed: ENODEV
Thanks,
Amir.
^ permalink raw reply
* Re: [PATCH] usb: core: devio: add ioctls for suspend and resume
From: Alan Stern @ 2019-06-20 14:43 UTC (permalink / raw)
To: Mayuresh Kulkarni; +Cc: Oliver Neukum, Greg KH, patches, linux-usb
In-Reply-To: <1561041295.20348.4.camel@opensource.cirrus.com>
On Thu, 20 Jun 2019, Mayuresh Kulkarni wrote:
> > It would be easiest to export the usb_autopm_* API to user space.
>
> AFAIU, usb_autopm_* API operate on interface rather than on device.
> Due to this, they are *indirectly* exposed by appropriate class drivers
> to the user-space class drivers cater to. E.g.: USB audio class driver
> calls usb_autopm_* APIs when user space calls pcm_open(playback_stream).
In fact, the usb_autopm_* API can operate both on interfaces and on
devices. It is used both ways in the kernel.
Alan Stern
^ permalink raw reply
* [PATCH v2 2/2] ssh: Add interface ssh_search_dir
From: Alexander Miroshnichenko @ 2019-06-20 14:41 UTC (permalink / raw)
To: selinux-refpolicy; +Cc: Alexander Miroshnichenko
In-Reply-To: <20190620144138.15172-1-alex@millerson.name>
Create interface ssh_search_dir to allow ssh_server search for keys in non-standard location.
Signed-off-by: Alexander Miroshnichenko <alex@millerson.name>
---
policy/modules/services/ssh.if | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/policy/modules/services/ssh.if b/policy/modules/services/ssh.if
index 0941f133711e..51c64ded00c4 100644
--- a/policy/modules/services/ssh.if
+++ b/policy/modules/services/ssh.if
@@ -680,6 +680,24 @@ interface(`ssh_agent_exec',`
can_exec($1, ssh_agent_exec_t)
')
+########################################
+## <summary>
+## Search for keys in non-standard location
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`ssh_search_dir',`
+ gen_require(`
+ type sshd_t;
+ ')
+
+ allow sshd_t $1:dir search_dir_perms;
+')
+
########################################
## <summary>
## Read ssh home directory content
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] x86/mm: Handle physical-virtual alignment mismatch in phys_p4d_init()
From: Dave Hansen @ 2019-06-20 14:42 UTC (permalink / raw)
To: Kirill A. Shutemov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, Dave Hansen, Andy Lutomirski, Peter Zijlstra
Cc: x86, linux-kernel, Kirill A. Shutemov, Kyle Pelton, Baoquan He
In-Reply-To: <20190620112239.28346-1-kirill.shutemov@linux.intel.com>
On 6/20/19 4:22 AM, Kirill A. Shutemov wrote:
> The commit relaxes KASLR alignment requirements and it can lead to
> mismatch bentween 'i' and 'p4d_index(vaddr)' inside the loop in
> phys_p4d_init(). The mismatch in its turn leads to clearing wrong p4d
> entry and eventually to the oops.
Just curious, but what does it relax the requirement to and from?
I'm just not clearly spotting the actual bug.
^ permalink raw reply
* [PATCH v2 1/2] ssh: Add ssh_exec_keygen interface
From: Alexander Miroshnichenko @ 2019-06-20 14:41 UTC (permalink / raw)
To: selinux-refpolicy; +Cc: Alexander Miroshnichenko
In-Reply-To: <20190620144138.15172-1-alex@millerson.name>
Signed-off-by: Alexander Miroshnichenko <alex@millerson.name>
---
policy/modules/services/ssh.if | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/policy/modules/services/ssh.if b/policy/modules/services/ssh.if
index b5bd2762ef96..0941f133711e 100644
--- a/policy/modules/services/ssh.if
+++ b/policy/modules/services/ssh.if
@@ -701,6 +701,25 @@ interface(`ssh_read_user_home_files',`
userdom_search_user_home_dirs($1)
')
+########################################
+## <summary>
+## Execute the ssh key generator in the caller domain.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed to transition.
+## </summary>
+## </param>
+#
+interface(`ssh_exec_keygen',`
+ gen_require(`
+ type ssh_keygen_exec_t;
+ ')
+
+ corecmd_search_bin($1)
+ can_exec($1, ssh_keygen_exec_t)
+')
+
########################################
## <summary>
## Execute the ssh key generator in the ssh keygen domain.
--
2.21.0
^ permalink raw reply related
* [Buildroot] [PATCH 26/27] package/sqlite: work around build timeout
From: Thomas Petazzoni @ 2019-06-20 14:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20190614210346.121013-27-giulio.benetti@micronovasrl.com>
Hello Giulio,
On Fri, 14 Jun 2019 23:03:45 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:
> With Microblaze Gcc version 4.9 build hangs due to a bug discovered for
> Gcc 4.9 only. Since Gcc 4.9 is not maintaned anymore it doesn't make
> sense to report this bug in Gcc bugzilla and use
> BR2_TOOLCHAIN_HAS_GCC_BUG_. So let's check if we're building for
> Microblaze with Gcc version < 5.x and work around the bug forcing the
> use of -O0.
I've applied, but this patch had two issues, which I fixed before
applying. See below.
> +ifeq ($(BR2_microblaze)$(BR2_TOOLCHAIN_GCC_AT_LEAST_5),y)
This condition is incorrectly written: the way you wrote it, if the
architecture is *not* Microblaze, but BR2_TOOLCHAIN_GCC_AT_LEAST_5=y,
the condition will evaluate to true.
So basically this condition not only passes -O0 on Microblaze with gcc
< 5.x, but it also passes -O0 on all architectures other than
Microblaze that use gcc >= 5.x. Very bad!
The correct way is:
ifeq ($(BR2_microblaze):$(BR2_TOOLCHAIN_GCC_AT_LEAST_5),y:)
This really tests that BR2_microblaze=y and
BR2_TOOLCHAIN_GCC_AT_LEAST_5 is empty.
> +SQLITE_CFLAGS += -O0
Here, you completely leave TARGET_CFLAGS unused, which is not good, as
they were used before (in what is now the else condition).
So I changed to += $(TARGET_CFLAGS) -O0
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 0/2] ssh policy new interfaces
From: Alexander Miroshnichenko @ 2019-06-20 14:41 UTC (permalink / raw)
To: selinux-refpolicy; +Cc: Alexander Miroshnichenko
New interfaces for ssh policy which can be used with git hosting
software.
Alexander Miroshnichenko (2):
ssh: Add ssh_exec_keygen interface
ssh: Add interface ssh_search_dir
policy/modules/services/ssh.if | 37 ++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
--
2.21.0
^ permalink raw reply
* Re: Delivery Status Notification (Failure) ... connection lost
From: Philip Oakley @ 2019-06-20 14:42 UTC (permalink / raw)
To: Xeno Amess, git
In-Reply-To: <CAFF4x5LFYQqHnUSzqd1R9NJ=ZVKs3yFqZA=RdrihVx74BtKWMg@mail.gmail.com>
On 11/06/2019 11:29, Xeno Amess wrote:
> Not all people can afford stable network connection...
> I'm now suffered from connection lost and have to restart the clone/push fully.
> It's OK when dealing with a project of several MB size, but when I try
> to clone a 2GB sized repo I never succeed.
> So I wonder, if there should be some way to resume from break-point for git?
> For example what if we support something like Content-Range in http,
> and make the download be split into smaller files, then make some way
> to auto-resume if some file block failed hash-check?
Is this on a Windows machine using Git for Windows, or a Linux machine,
or even 'Windows Subsystem for Linux (WSL)" on windows?
If it is Windows then you may have hit the "sizeof(long)=32bit" limit.
If it is Linux then maybe adjust your refspec to limit the size of each
fetch or push. There has also been a recent change discussed on list
that added a config variable for some sort of rate limit limit but
haven't looked back at the mail archive to try to remember details - try
searching the https://public-inbox.org/git/
Philip
^ permalink raw reply
* [f2fs-dev] [PATCH] fsf2: Use DIV_ROUND_UP() instead of open-coding
From: Geert Uytterhoeven @ 2019-06-20 14:42 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu; +Cc: Geert Uytterhoeven, linux-kernel, linux-f2fs-devel
Replace the open-coded divisions with round-up by calls to the
DIV_ROUND_UP() helper macro.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
fs/f2fs/f2fs.h | 4 ++--
fs/f2fs/file.c | 6 +++---
fs/f2fs/segment.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 9afe15675dbbd369..52f477eaaee93bc3 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -480,8 +480,8 @@ static inline int get_inline_xattr_addrs(struct inode *inode);
#define NR_INLINE_DENTRY(inode) (MAX_INLINE_DATA(inode) * BITS_PER_BYTE / \
((SIZE_OF_DIR_ENTRY + F2FS_SLOT_LEN) * \
BITS_PER_BYTE + 1))
-#define INLINE_DENTRY_BITMAP_SIZE(inode) ((NR_INLINE_DENTRY(inode) + \
- BITS_PER_BYTE - 1) / BITS_PER_BYTE)
+#define INLINE_DENTRY_BITMAP_SIZE(inode) \
+ DIV_ROUND_UP(NR_INLINE_DENTRY(inode), BITS_PER_BYTE)
#define INLINE_RESERVED_SIZE(inode) (MAX_INLINE_DATA(inode) - \
((SIZE_OF_DIR_ENTRY + F2FS_SLOT_LEN) * \
NR_INLINE_DENTRY(inode) + \
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 1180eca879331eba..fc00d8bdc31c18b0 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1211,7 +1211,7 @@ static int __exchange_data_block(struct inode *src_inode,
static int f2fs_do_collapse(struct inode *inode, loff_t offset, loff_t len)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
- pgoff_t nrpages = (i_size_read(inode) + PAGE_SIZE - 1) / PAGE_SIZE;
+ pgoff_t nrpages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
pgoff_t start = offset >> PAGE_SHIFT;
pgoff_t end = (offset + len) >> PAGE_SHIFT;
int ret;
@@ -1464,7 +1464,7 @@ static int f2fs_insert_range(struct inode *inode, loff_t offset, loff_t len)
pg_start = offset >> PAGE_SHIFT;
pg_end = (offset + len) >> PAGE_SHIFT;
delta = pg_end - pg_start;
- idx = (i_size_read(inode) + PAGE_SIZE - 1) / PAGE_SIZE;
+ idx = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
/* avoid gc operation during block exchange */
down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
@@ -2362,7 +2362,7 @@ static int f2fs_defragment_range(struct f2fs_sb_info *sbi,
if (!fragmented)
goto out;
- sec_num = (total + BLKS_PER_SEC(sbi) - 1) / BLKS_PER_SEC(sbi);
+ sec_num = DIV_ROUND_UP(total, BLKS_PER_SEC(sbi));
/*
* make sure there are enough free section for LFS allocation, this can
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 166ac0f07a4e472d..2ae6df03b9982d12 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -109,7 +109,7 @@
#define START_SEGNO(segno) \
(SIT_BLOCK_OFFSET(segno) * SIT_ENTRY_PER_BLOCK)
#define SIT_BLK_CNT(sbi) \
- ((MAIN_SEGS(sbi) + SIT_ENTRY_PER_BLOCK - 1) / SIT_ENTRY_PER_BLOCK)
+ DIV_ROUND_UP(MAIN_SEGS(sbi), SIT_ENTRY_PER_BLOCK)
#define f2fs_bitmap_size(nr) \
(BITS_TO_LONGS(nr) * sizeof(unsigned long))
--
2.17.1
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply related
* [PATCH] fsf2: Use DIV_ROUND_UP() instead of open-coding
From: Geert Uytterhoeven @ 2019-06-20 14:42 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu; +Cc: linux-f2fs-devel, linux-kernel, Geert Uytterhoeven
Replace the open-coded divisions with round-up by calls to the
DIV_ROUND_UP() helper macro.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
fs/f2fs/f2fs.h | 4 ++--
fs/f2fs/file.c | 6 +++---
fs/f2fs/segment.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 9afe15675dbbd369..52f477eaaee93bc3 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -480,8 +480,8 @@ static inline int get_inline_xattr_addrs(struct inode *inode);
#define NR_INLINE_DENTRY(inode) (MAX_INLINE_DATA(inode) * BITS_PER_BYTE / \
((SIZE_OF_DIR_ENTRY + F2FS_SLOT_LEN) * \
BITS_PER_BYTE + 1))
-#define INLINE_DENTRY_BITMAP_SIZE(inode) ((NR_INLINE_DENTRY(inode) + \
- BITS_PER_BYTE - 1) / BITS_PER_BYTE)
+#define INLINE_DENTRY_BITMAP_SIZE(inode) \
+ DIV_ROUND_UP(NR_INLINE_DENTRY(inode), BITS_PER_BYTE)
#define INLINE_RESERVED_SIZE(inode) (MAX_INLINE_DATA(inode) - \
((SIZE_OF_DIR_ENTRY + F2FS_SLOT_LEN) * \
NR_INLINE_DENTRY(inode) + \
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 1180eca879331eba..fc00d8bdc31c18b0 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1211,7 +1211,7 @@ static int __exchange_data_block(struct inode *src_inode,
static int f2fs_do_collapse(struct inode *inode, loff_t offset, loff_t len)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
- pgoff_t nrpages = (i_size_read(inode) + PAGE_SIZE - 1) / PAGE_SIZE;
+ pgoff_t nrpages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
pgoff_t start = offset >> PAGE_SHIFT;
pgoff_t end = (offset + len) >> PAGE_SHIFT;
int ret;
@@ -1464,7 +1464,7 @@ static int f2fs_insert_range(struct inode *inode, loff_t offset, loff_t len)
pg_start = offset >> PAGE_SHIFT;
pg_end = (offset + len) >> PAGE_SHIFT;
delta = pg_end - pg_start;
- idx = (i_size_read(inode) + PAGE_SIZE - 1) / PAGE_SIZE;
+ idx = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
/* avoid gc operation during block exchange */
down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
@@ -2362,7 +2362,7 @@ static int f2fs_defragment_range(struct f2fs_sb_info *sbi,
if (!fragmented)
goto out;
- sec_num = (total + BLKS_PER_SEC(sbi) - 1) / BLKS_PER_SEC(sbi);
+ sec_num = DIV_ROUND_UP(total, BLKS_PER_SEC(sbi));
/*
* make sure there are enough free section for LFS allocation, this can
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 166ac0f07a4e472d..2ae6df03b9982d12 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -109,7 +109,7 @@
#define START_SEGNO(segno) \
(SIT_BLOCK_OFFSET(segno) * SIT_ENTRY_PER_BLOCK)
#define SIT_BLK_CNT(sbi) \
- ((MAIN_SEGS(sbi) + SIT_ENTRY_PER_BLOCK - 1) / SIT_ENTRY_PER_BLOCK)
+ DIV_ROUND_UP(MAIN_SEGS(sbi), SIT_ENTRY_PER_BLOCK)
#define f2fs_bitmap_size(nr) \
(BITS_TO_LONGS(nr) * sizeof(unsigned long))
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.