On 20/04/2021 17:24, Frank Wunderlich wrote:
> Am 20. April 2021 17:18:32 MESZ schrieb Daniel Lezcano
> :
>>
>> Hi Frank,
>
>> The no_hwmon usage is a bit fuzzy in the thermal core code.
>
> Maybe add depency in Kconfig? Else we can get undefined symbols on linking
>
> regards Frank
Nope, ther
Am 20. April 2021 17:18:32 MESZ schrieb Daniel Lezcano
:
>
>Hi Frank,
>The no_hwmon usage is a bit fuzzy in the thermal core code.
Maybe add depency in Kconfig? Else we can get undefined symbols on linking
regards Frank
Hi Frank,
On 20/04/2021 16:59, Frank Wunderlich wrote:
> Hi,
>
>> Gesendet: Dienstag, 20. April 2021 um 14:07 Uhr
>> Von: "Daniel Lezcano"
>
>> No #ifdef in C file.
> ...
>
>> devm_thermal_add_hwmon_sysfs() ?
>
> based on your comments this should be enough/right?
>
> #if IS_ENABLED(CONFIG
Hi,
> Gesendet: Dienstag, 20. April 2021 um 14:07 Uhr
> Von: "Daniel Lezcano"
> No #ifdef in C file.
...
> devm_thermal_add_hwmon_sysfs() ?
based on your comments this should be enough/right?
#if IS_ENABLED(CONFIG_THERMAL_HWMON)
tzdev->tzp->no_hwmon = false;
ret = devm_thermal_add_hwm
Hi,
any opinion (except typo)?
thermanl => thermal
regards Frank
> Gesendet: Samstag, 20. März 2021 um 10:06 Uhr
> Von: "Frank Wunderlich"
> add HWMON-support to mediateks thermanl driver to allow lm-sensors
> userspace tools read soc temperature
Hi René,Ilya
> Gesendet: Freitag, 19. März 2021 um 11:25 Uhr
> Von: "René van Dorst"
> Hi Ilya,
>
> Thanks for fixing this issue.
>
> I remember that Frank also had an issue with TRGMII on his MT7623 ARM board.
> I never found why it did not work but this may be also fix his issue
> on the MT
Hi,
> > From: Hubert Streidl
> >
> > By default the PMIC DA9063 2-wire interface is SMBus compliant. This
> > means the PMIC will automatically reset the interface when the clock
> > signal ceases for more than the SMBus timeout of 35 ms.
> >
> > If the I2C driver / device is not capable of creat
Hi Walter,
On 3/15/21 7:00 PM, Walter Harms wrote:
I have learned the other way around:
#include
Is a general system header to use that may include
the asm/prctrl.h what should never be included by
userspace programms.
Are you sure that includes ?
user@debian:/usr/include$ grep -rn '\bARCH
Hi,
sorry, please ignore this
wireguard was included with 5.6, my 5.4 uses external wireguard
regards Frank
I have learned the other way around:
#include
Is a general system header to use that may include
the asm/prctrl.h what should never be included by
userspace programms.
jm2c,
re,
wh
Von: Alejandro Colomar
Gesendet: Samstag, 13. März 2021 20:25:14
An: mtk.
On 2021-03-01 14:06, Frank Wunderlich wrote:
Gesendet: Montag, 01. März 2021 um 14:31 Uhr
Von: "Marc Zyngier"
Frank,
i guess it's a bug in ath10k driver or my r64 board (it is a v1.1
which has missing capacitors on tx lines).
No, this definitely looks like a bug in the MTK PCIe driver,
wher
Hi Ruslan,
thanks a lot for your quick answer.
> -Ursprüngliche Nachricht-
> Von: Ruslan Bilovol
> Gesendet: Montag, 1. März 2021 22:34
> An: Johannes Freyberger
> Cc: Felipe Balbi ; Jonathan Corbet ;
> Greg Kroah-Hartman ; Glenn Schmottlach
> ; linux-...@vger.kernel.org; linux-
> ker...
> Gesendet: Montag, 01. März 2021 um 14:31 Uhr
> Von: "Marc Zyngier"
>
> Frank,
>
> >> > i guess it's a bug in ath10k driver or my r64 board (it is a v1.1
> >> > which has missing capacitors on tx lines).
> >>
> >> No, this definitely looks like a bug in the MTK PCIe driver,
> >> where the mutex
Frank,
> i guess it's a bug in ath10k driver or my r64 board (it is a v1.1
> which has missing capacitors on tx lines).
No, this definitely looks like a bug in the MTK PCIe driver,
where the mutex is either not properly initialised, corrupted,
or the wrong pointer is passed.
but why does it h
regards Frank
> Gesendet: Montag, 01. März 2021 um 12:49 Uhr
> Von: "Marc Zyngier"
> Frank,
>
> On 2021-03-01 10:43, Frank Wunderlich wrote:
> > tested full series on bananapi-r2 and r64
> >
> > r2 (with mt7615) looks good.
> >
> > on r64 (with atheros card WLE900VX) i see this while loadi
Frank,
On 2021-03-01 10:43, Frank Wunderlich wrote:
tested full series on bananapi-r2 and r64
r2 (with mt7615) looks good.
on r64 (with atheros card WLE900VX) i see this while loading ath10k
driver:
[6.525981] ath10k_pci :01:00.0: enabling device ( -> 0002)
[6.537810] ath10k
tested full series on bananapi-r2 and r64
r2 (with mt7615) looks good.
on r64 (with atheros card WLE900VX) i see this while loading ath10k driver:
[6.525981] ath10k_pci :01:00.0: enabling device ( -> 0002)
[6.537810] ath10k_pci :01:00.0: enabling bus mastering
[6.543831]
On Thu, Feb 25, 2021 at 6:49 PM Jakub Kicinski wrote:
>
> On Wed, 24 Feb 2021 14:55:17 +0100 Andrew Lunn wrote:
> > On Wed, Feb 24, 2021 at 10:46:49AM +0100, Marco Wenzel wrote:
> > > In IEC 62439-3 EntryForgetTime is defined with a value of 400 ms.
> > > When a node does not send any frame withi
On Mon, Feb 22, 2021 at 5:49 PM : George McCollister
wrote:
>
> On Mon, Feb 22, 2021 at 7:38 AM Wenzel, Marco eberle.de> wrote:
> >
> > On Fri, Feb 19, 2021 at 2:14 PM : George McCollister
> wrote:
> > >
> > > On Fri, Feb 19, 2021 at 2:27 AM Wenzel, Marco > > eberle.de> wrote:
> > > >
> > > >
Hi,
> > From: Hubert Streidl
> >
> > By default the PMIC DA9063 2-wire interface is SMBus compliant. This
> > means the PMIC will automatically reset the interface when the clock
> > signal ceases for more than the SMBus timeout of 35 ms.
> >
> > If the I2C driver / device is not capable of creat
Hello Andy,
> Von: Andy Shevchenko
> Gesendet: Freitag, 19. Februar 2021 14:56
> An: Sven Schuchmann
> Cc: Pavel Machek ; Dan Murphy ;
> linux-l...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Betreff: Re: [PATCH v2 2/4] leds: lp50xx: add setting of default intensity
> from DT
>
> > > >
Hello Pavel, hello Andy,
> -Ursprüngliche Nachricht-
> Von: Pavel Machek
> Gesendet: Freitag, 19. Februar 2021 12:17
> An: Sven Schuchmann
> Cc: Dan Murphy ; linux-l...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Betreff: Re: [PATCH v2 2/4] leds: lp50xx: add setting of default int
On Thu, Feb 18, 2021 at 6:06 PM : George McCollister
wrote:
>
> On Thu, Feb 18, 2021 at 9:01 AM Marco Wenzel eberle.de> wrote:
> >
> > In IEC 62439-3 EntryForgetTime is defined with a value of 400 ms. When
> > a node does not send any frame within this time, the sequence number
> > check for ca
I second that ...
Having i unsigned violates the rule of "least surprise".
If you need it unsigned make it clearly visible, also adding
a simple comment may help.
jm2c,
wh
Von: Dan Carpenter
Gesendet: Dienstag, 9. Februar 2021 10:19:23
An: Will Deacon
Cc
thx for info
Von: Christian König
Gesendet: Montag, 8. Februar 2021 13:14:49
An: Walter Harms; Colin King; Alex Deucher; David Airlie; Daniel Vetter; Huang
Rui; Junwei Zhang; amd-...@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Cc: kernel-janit.
i am curious:
what is the win to have a unsigned 64 bit integer in the first
place ?
re,
wh
Von: Christian König
Gesendet: Montag, 8. Februar 2021 10:17:42
An: Colin King; Alex Deucher; David Airlie; Daniel Vetter; Huang Rui; Junwei
Zhang; amd-...@lists.
Sven,
On 2/6/21 2:14 PM, Sven Schuchmann wrote:
Hello Dan,
Von: Jacek Anaszewski
Gesendet: Freitag, 5. Februar 2021 19:37
Hi Pavel,
On 2/5/21 11:23 AM, Pavel Machek wrote:
Hi!
patternProperties:
"(^led-[0-9a-f]$|led)":
@@ -99,6 +104,7 @@ examples:
reg = <
Hello Dan,
> Von: Jacek Anaszewski
> Gesendet: Freitag, 5. Februar 2021 19:37
> Hi Pavel,
>
> On 2/5/21 11:23 AM, Pavel Machek wrote:
> > Hi!
> >
> patternProperties:
> "(^led-[0-9a-f]$|led)":
> @@ -99,6 +104,7 @@ examples:
> reg = <0x1>;
>
Hello Pavel, hello Dan,
> > diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
> > b/Documentation/devicetree/bindings/leds/leds-
> lp50xx.yaml
> > index c192b5feadc7..2bc25b2fc94d 100644
> > --- a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
> > +++ b/Documentation/d
Hello Pavel,
> > > > diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
> > > > index f13117eed976..4b40bf66483c 100644
> > > > --- a/drivers/leds/leds-lp50xx.c
> > > > +++ b/drivers/leds/leds-lp50xx.c
> > > > @@ -267,7 +267,6 @@ struct lp50xx_led {
> > > > struct led_cl
Hello Pavel,
>
> > Signed-off-by: Sven Schuchmann
>
> Check your email headers, empty To: is strange.
>
> > diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
> > index 79bc071c31fb..e8aa36c7e963 100644
> > --- a/drivers/leds/leds-lp50xx.c
> > +++ b/drivers/leds/leds-lp50xx.c
Hello Pavel,
> > diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
> > index f13117eed976..4b40bf66483c 100644
> > --- a/drivers/leds/leds-lp50xx.c
> > +++ b/drivers/leds/leds-lp50xx.c
> > @@ -267,7 +267,6 @@ struct lp50xx_led {
> > struct led_classdev_mc mc_cdev;
> > st
Hi Adam,
> > + if (i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C)) {
> > + dev_info(da9063->dev, "I2C mode");
> > + busmode = 0;
> > + } else {
> > + dev_info(da9063->dev, "SMBus mode");
> > + busmode = 1;
>
> I think this should be 'DA9063_TWOWIRE
Helo Pavel,
> > > Yes, sounds reasonable. Could we get default intensity of 100% on all
> > > channels if nothing else is specified?
> > >
> > > Or maybe simply "if intensity is not specified, start with 100%, and
> > > use explicit =0 if other color is expected".
> > >
> > Mh, if someone is alrea
Hello Pavel, hello Marek
> > Is the property default-intensity documented in DT bindings?
I updated the documentation in leds-lp50xx.yaml. Is it this what you mean?
> > Wouldn't it be better if the property was used in the multi-led node
> > instead of the channel node? I.e.
> > multi-led@3 {
Hello Pavel,
>
> Yes, sounds reasonable. Could we get default intensity of 100% on all
> channels if nothing else is specified?
>
> Or maybe simply "if intensity is not specified, start with 100%, and
> use explicit =0 if other color is expected".
>
Mh, if someone is already using the led drive
Hello Dan, hello Pavel,
> > Do you have set up where this is needed and you can test this? Will
> > you submit the fixes?
>
> No I use an always on regulator in my setup. I have no managed supplies
> exposed.
I am also sorry I do not have a setup ready for testing this.
I think we should ignore t
Hello Pavel,
> > In order to use a multicolor-led together with a trigger
> > from DT the led needs to have an intensity set to see something.
> > The trigger changes the brightness of the led but if there
> > is no intensity we actually see nothing.
> >
> > This patch adds the ability to set the
Hi,
is there any new state?
kernel test robot reports the following problem (i do not see it when compiling
for my arm/arm64 devices):
ARCH=i386
drivers/pci/probe.c: In function 'pci_register_host_bridge':
>> drivers/pci/probe.c:930:39: error: 'struct device' has no member named
>> 'msi_domai
Hi,
sorry to ask but was someone able to look at this? Any thoughts?
Best Regards,
Sven
> -Ursprüngliche Nachricht-
> Von: Sven Schuchmann
> Gesendet: Dienstag, 19. Januar 2021 11:53
> An: Sven Schuchmann
> Cc: Pavel Machek ; Dan Murphy ; Rob Herring
> ; linux-
> l...@vger.kernel.o
Hi Adam,
> > From: Hubert Streidl
> >
> > By default the PMIC DA9063 2-wire interface is SMBus compliant. This
> > means the PMIC will automatically reset the interface when the clock
> > signal ceases for more than the SMBus timeout of 35 ms.
> >
> > If the I2C driver / device is not capable of
On 09/01/2021 17:44, Frank Wunderlich wrote:
> Hi
>
>> Gesendet: Samstag, 09. Januar 2021 um 12:26 Uhr
>> Von: matthias@kernel.org
>
>> Changes in v2:
>> - check for CONFIG_OF
>> - add Fixes tag
>
>> --- a/drivers/regulator/mt6323-regulator.c
>> +++ b/drivers/regulator/mt6323-regulator.c
Hi
> Gesendet: Samstag, 09. Januar 2021 um 12:26 Uhr
> Von: matthias@kernel.org
> Changes in v2:
> - check for CONFIG_OF
> - add Fixes tag
> --- a/drivers/regulator/mt6323-regulator.c
> +++ b/drivers/regulator/mt6323-regulator.c
> @@ -406,9 +406,18 @@ static const struct platform_device_id
Hi,
5.11-rc1 is also affected, here is the relevant part of trace from my
bananapi-r2:
[5.792659] mtk-pcie 1a14.pcie: PCI host bridge to bus :00
[5.798879] pci_bus :00: root bus resource [bus 00-ff]
[5.804412] pci_bus :00: root bus resource [io 0x-0x] (bus
a
Hi Uwe,
> Gesendet: Donnerstag, 10. Dezember 2020 um 12:43 Uhr
> Von: "Uwe Kleine-König"
> An: "Lino Sanfilippo"
> Cc: thierry.red...@gmail.com, lee.jo...@linaro.org, nsaenzjulie...@suse.de,
> f.faine...@gmail.com, r...@broadcom.com, s...@mess.org,
> sbran...@broadcom.com, bcm-kernel-feedback-
Hi Uwe
> Hello Lino,
>
> On Tue, Dec 08, 2020 at 11:01:45PM +0100, Lino Sanfilippo wrote:
> > Use the newer .apply function of pwm_ops instead of .config, .enable,
> > .disable and .set_polarity. This guarantees atomic changes of the pwm
> > controller configuration. It also reduces the size of th
Hi Daniel,
> > Thank you very much for your feedback. We appreciate it.
> >
> > > >>> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> > > >>> b/drivers/gpu/drm/imx/imx-drm-core.c
> > > >>> index 9bf5ad6d18a2..2665040e11c7 100644
> > > >>> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > > >>> +++ b/
Hi,
any new state here?
last fix works, but i have not seen it approved by anyone for merge or sent as
separate Patch
regards Frank
Hi Henning.
We had a short discussion with Andy on coreboot Gerrit
(https://review.coreboot.org/c/coreboot/+/47235) regarding this issue.
We have agreed that we will give Epson a period of two weeks for reaction. If
we will not have a valid HID by then, I will push a patch which will use a
non
Hi Thomas and Daniel,
Thank you very much for your feedback. We appreciate it.
> >>> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> >>> b/drivers/gpu/drm/imx/imx-drm-core.c
> >>> index 9bf5ad6d18a2..2665040e11c7 100644
> >>> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> >>> +++ b/drivers/gpu/drm/
Hello Val,
my name is Johannes Hahn from Siemens AG in Germany.
Our product Open Controller II (OCII)[1] uses the Realtime Clock RX6110SA from
SEIKO EPSON.
Currently there is a merge request ongoing for the Linux Kernel master
branch[2] which adds I²C and ACPI support to your original driver
i
Hello Andy,
when comparing the ACPI IDs used in rtc-ds1307.c, which is already on mainline
https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-ds1307.c#L1141
for example. Every ID listed there is also not formatted the ACPI ID , PNP ID
way defined in the ACPI spec.
How about that ?
On 2020-11-05 23:00, Thomas Gleixner wrote:
On Thu, Nov 05 2020 at 09:20, Marc Zyngier wrote:
On 2020-11-04 23:14, Thomas Gleixner wrote:
/* Resource alignment requirements */
resource_size_t (*align_resource)(struct pci_dev *dev,
If that's the direction of travel, we also nee
On Thu, Nov 05 2020 at 09:20, Marc Zyngier wrote:
> On 2020-11-04 23:14, Thomas Gleixner wrote:
>> /* Resource alignment requirements */
>> resource_size_t (*align_resource)(struct pci_dev *dev,
>
> If that's the direction of travel, we also need something like this
> for configuration wh
Marc's Patch based on thomas' last one also seems to work well for r2, again no
warning, PCI and AHCI (connected to pcie bus) working
regards Frank
On 2020-11-04 23:14, Thomas Gleixner wrote:
[...]
TBH, that's butt ugly. So after staring long enough into the PCI code I
came up with a way to transport that information to the probe code.
That allows a particular device to say 'I can't do MSI' and at the same
time keeps the warning machinery
Frank,
On Wed, Nov 04 2020 at 17:49, Frank Wunderlich wrote:
>> Von: "Thomas Gleixner"
>> Any architecture which selects PCI_MSI_ARCH_FALLBACKS and does not have
>> irqdomain support runs into:
>>
>> if (!d)
>> bus->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
>>
>> which in turn makes pc
> Gesendet: Dienstag, 03. November 2020 um 11:16 Uhr
> Von: "Thomas Gleixner"
> Any architecture which selects PCI_MSI_ARCH_FALLBACKS and does not have
> irqdomain support runs into:
>
> if (!d)
> bus->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
>
> which in turn makes pci_msi_support
On Tue, Nov 03 2020 at 11:41, Marc Zyngier wrote:
> On 2020-11-03 10:31, Thomas Gleixner wrote:
> We can do that, although I worried that it isn't 100% reliable:
>
> pci_host_probe() ends up calling pci_add_device(), and will start
> probing devices if the endpoint drivers have already registered
>
On 2020-11-03 10:31, Thomas Gleixner wrote:
On Tue, Nov 03 2020 at 09:54, Marc Zyngier wrote:
On 2020-11-02 22:18, Thomas Gleixner wrote:
So we really need some other solution and removing the warning is not
an option. If MSI is enabled then we want to get a warning when a PCI
device has no MSI
On Tue, Nov 03 2020 at 09:54, Marc Zyngier wrote:
> On 2020-11-02 22:18, Thomas Gleixner wrote:
>> So we really need some other solution and removing the warning is not
>> an option. If MSI is enabled then we want to get a warning when a PCI
>> device has no MSI domain associated. Explicitly expre
On 2020-11-03 10:16, Thomas Gleixner wrote:
On Tue, Nov 03 2020 at 09:54, Marc Zyngier wrote:
On 2020-11-02 22:18, Thomas Gleixner wrote:
On Mon, Nov 02 2020 at 17:16, Thomas Gleixner wrote:
On Mon, Nov 02 2020 at 11:30, Marc Zyngier wrote:
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
On Tue, Nov 03 2020 at 09:54, Marc Zyngier wrote:
> On 2020-11-02 22:18, Thomas Gleixner wrote:
>> On Mon, Nov 02 2020 at 17:16, Thomas Gleixner wrote:
>>> On Mon, Nov 02 2020 at 11:30, Marc Zyngier wrote:
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -871,6 +871,8 @@ static
On 2020-11-02 22:18, Thomas Gleixner wrote:
On Mon, Nov 02 2020 at 17:16, Thomas Gleixner wrote:
On Mon, Nov 02 2020 at 11:30, Marc Zyngier wrote:
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -871,6 +871,8 @@ static void pci_set_bus_msi_domain(struct pci_bus
*bus)
d =
On Mon, Nov 02 2020 at 17:16, Thomas Gleixner wrote:
> On Mon, Nov 02 2020 at 11:30, Marc Zyngier wrote:
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -871,6 +871,8 @@ static void pci_set_bus_msi_domain(struct pci_bus
>> *bus)
>> d = pci_host_bridge_msi_domain(b);
>>
On Mon, Nov 02 2020 at 11:30, Marc Zyngier wrote:
> On 2020-11-01 22:27, Thomas Gleixner wrote:
> The following patch makes it work for me (GICv3 guest without an ITS)by
> checking for the presence of an MSI domain at the point where we
> actually
> perform this association, and before starting to
> Gesendet: Montag, 02. November 2020 um 14:58 Uhr
> Von: "Marc Zyngier"
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index d15c881e2e7e..5bb1306162c7 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -387,10 +387,20 @@ static ssize_t msi_bus_store(
On 2020-11-02 11:56, Frank Wunderlich wrote:
looks good on bananapi-r2, no warning, pcie-card and hdd recognized
Thanks for giving it a shot. Still needs a bit of tweaking, as I expect
it to break configurations that select CONFIG_PCI_MSI_ARCH_FALLBACKS
(we have to assume that MSIs can be handl
looks good on bananapi-r2, no warning, pcie-card and hdd recognized
regards Frank
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 4289030b0fff..bb363eb103a2 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -871,6 +871,8 @@ static void pci_set_bus_msi_domain(st
On 2020-11-01 22:27, Thomas Gleixner wrote:
On Sun, Nov 01 2020 at 21:47, Marc Zyngier wrote:
On Sun, 01 Nov 2020 18:27:13 +,
Frank Wunderlich wrote:
Thinking of it a bit more, I think this is the wrong solution.
PCI MSIs are optional, and not a requirement. I can trivially spin a
VM with
On Sun, Nov 01 2020 at 21:47, Marc Zyngier wrote:
> On Sun, 01 Nov 2020 18:27:13 +,
> Frank Wunderlich wrote:
> Thinking of it a bit more, I think this is the wrong solution.
>
> PCI MSIs are optional, and not a requirement. I can trivially spin a
> VM with PCI devices and yet no MSI capabilit
On Sun, 01 Nov 2020 18:27:13 +,
Frank Wunderlich wrote:
>
> > Gesendet: Sonntag, 01. November 2020 um 18:54 Uhr
> > Von: "Ryder Lee"
>
> > Yea, mt7623 (mtk_pcie_soc_v1) does not support MSI, so that's a way to
> > handle it.
> >
> > @Frank, could you help to test it?
> >
> > Ryder
>
> comp
> Gesendet: Sonntag, 01. November 2020 um 18:54 Uhr
> Von: "Ryder Lee"
> Yea, mt7623 (mtk_pcie_soc_v1) does not support MSI, so that's a way to
> handle it.
>
> @Frank, could you help to test it?
>
> Ryder
compiles clean for mt7623/armhf and mt7622/aarch64 so far
at least bananapi-r2/mt7623 boo
> Gesendet: Sonntag, 01. November 2020 um 12:43 Uhr
> Von: "Marc Zyngier"
> On Sun, 01 Nov 2020 09:25:04 +,
> Frank Wunderlich wrote:
> > It looks like for mt7623 there is no msi domain setup (done via
> > mtk_pcie_setup_irq callback + mtk_pcie_init_irq_domain) in mtk pcie
> > driver.
>
>
nit picking:
i would without "else" to improve readability:
if (ret == -ERESTARTSYS)
return -ERESTARTSYS;
if (ret < 0)
return -ETIMEDOUT;
return 0;
jm2c
wh
Von: Colin King
Gesendet: Freitag, 30.
this looks like a reimplementation of bsearch()
perhaps the maintainer can add a comment why the
kernel implementation is not suitable here ?
jm2c
wh
Von: Lukas Bulwahn [lukas.bulw...@gmail.com]
Gesendet: Mittwoch, 28. Oktober 2020 13:21
An: Thomas Gleix
To avoid this #ifdef jungle ..
I guess it would be save to search for a governor even
ones that are not enabled.
and a second thing: can we change the subject please ?
jm2c
wh
Von: Peter Zijlstra [pet...@infradead.org]
Gesendet: Donnerstag, 22. Oktobe
i guess the whole thing can be made more simple
we have len and buflen
len=strlen(filter->error_buffer);
if (len >= buflen )
return -1;
strcpy(buf, filter->error_buffer);
jm2c,
Von: Fedor Tokarev [ftoka...@gmail.com]
Gesendet: Donnerstag, 15. Oktobe
if xprt->debugfs->d_name.name can be what ever long
it is more clever to use kasprintf()
the some for link (no idea how many xprt als possible)
jm2c
wh
Von: Fedor Tokarev [ftoka...@gmail.com]
Gesendet: Donnerstag, 15. Oktober 2020 15:59
An: bfie...@field
Andreas,
On Fri, Oct 09 2020 at 11:17, Andreas Meisinger wrote:
please do not top-post and trim your replies.
> Yet we do already have usecases where this can't be done. Additionally
> a lot of discussions at this topic are ongoing in 60802 profile
> creation too. Some of our usecases do requir
Hello Mr Gleixner,
thanks for your feedback we'll fix the issues not related to the time scale
topic as soon as possible.
Regarding your concerns about not using TAI timescale, we do admit that in many
situations TAI makes a lot of things way more easy and therefore is the way to
go.
Yet we do
> Gesendet: Mittwoch, 07. Oktober 2020 um 09:54 Uhr
> Von: "Michael Kao"
> Betreff: [v5 0/2] Add Mediatek thermal dirver and dtsi
Hi,
just a small typo "dirver" => driver and coverletter (v5) does not match series
(v1/without version),
so it is not linked correctly in patchwork. I guess V1 is t
just a gentle ping
regards Frank
> Gesendet: Montag, 07. September 2020 um 09:05 Uhr
> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> @@ -192,6 +192,7 @@ port@6 {
> fixed-link {
> speed = <1000>;
>
> Gesendet: Dienstag, 15. September 2020 um 09:54 Uhr
> Von: "Masahiro Yamada"
> On Tue, Sep 15, 2020 at 2:42 PM Frank Wunderlich
> wrote:
> > Yes i exported it before use at beginning of my script [1] and
> > modules_install used inside install function [2]. It works with
> > build-function [
Hi Walter,
On 9/14/20 11:24 AM, Walter Harms wrote:
> missunderstanding,
> i do not want to discuss sizeof() vs define
I did understand, that was point (3).
>
> in this example you do:
> #define BUFLEN 4096
> char buf[BUFLEN];
> getgrent_r(&grp, buf, sizeof(buf), &grpp);
>
> so there is no re
move BUFLEN
Von: Alejandro Colomar [colomar.6@gmail.com]
Gesendet: Freitag, 11. September 2020 21:17
An: Walter Harms; mtk.manpa...@gmail.com
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Betreff: Re: AW: [PATCH 12/24] getgrent_r.3: Use sizeof() to get
On 2020-09-11 15:07, Walter Harms wrote:
sys/sysinfo.h:extern long int get_phys_pages (void)
for the real world i would say that long int == long but for the same reason
i would say what the include says and stay away from discussions.
jm2c,
wh
I think that the man-pages don't need to
Hi Walter,
On 2020-09-11 14:50, Walter Harms wrote:
BUFLEN should be remove completely or stay
jm2c
wh
Sorry that you weren't CC'd in the conversation we are having about it.
You can have a look at it here:
https://lore.kernel.org/linux-man/ab12151d-6951-2a36-2fc6-ea7eed538...@gmail.com/T
Tested full series on Bananapi-r2 and r64, results as in v3
Tested-By: Frank Wunderlich
regards Frank
I do not think that this is a good idea.
An example should be clear and easy to understand.
(e.g. with reduced error handling)
These C99 macros are over the top for me.
jm2c
wh
Von: linux-man-ow...@vger.kernel.org [linux-man-ow...@vger.kernel.org] im
Auf
the groff commands are ducument in man 7 groff
.nf No filling or adjusting of output-lines.
.fi Fill output lines
(for me) a typical use is like this:
.nf
struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec;/* microseconds */
};
.fi
In the top secti
sys/sysinfo.h:extern long int get_phys_pages (void)
for the real world i would say that long int == long but for the same reason
i would say what the include says and stay away from discussions.
jm2c,
wh
Von: linux-man-ow...@vger.kernel.org [linux-man-
BUFLEN should be remove completely or stay
jm2c
wh
Von: linux-man-ow...@vger.kernel.org [linux-man-ow...@vger.kernel.org] im
Auftrag von Alejandro Colomar [colomar.6@gmail.com]
Gesendet: Donnerstag, 10. September 2020 23:13
An: mtk.manpa...@gmail.com
On Tue, 2020-09-08 at 08:13 +0200, Frank Wunderlich wrote:
> Hi,
>
> i don't see this Patchset in 5.9-rc4
>
> is anything missing?
>
> regards Frank
Thanks for ping this mail,
mali list consider this patchset is SPAM
because of my environmental problems.
I have fixed this problem and send the
Hi,
i don't see this Patchset in 5.9-rc4
is anything missing?
regards Frank
Hi
> Gesendet: Samstag, 05. September 2020 um 10:45 Uhr
> Von: "Frank Wunderlich"
> similar to bananapi-r2 (mt7530)
...
> reverse-mode:
>
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.01 sec 1.05 GBytes 905 Mbits/sec 14533
> sender <<<
>
tested full series on Bananapi-r64 (mt7531) running iperf3-server
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec0 sender
[ 5] 0.00-10.01 sec 1.09 GBytes 935 Mbits/sec receiver
reverse mode (-R
Tested-By: Frank Wunderlich
regards Frank
this Patch is now Part of my hdmi-series v6
https://patchwork.kernel.org/project/linux-mediatek/list/?series=343565
so comments please to this series
regards Frank
On 28/08/2020 01:46, Chun-Kuang Hu wrote:
Hi, Frank:
Matthias Brugger 於 2020年8月27日 週四 下午10:28寫道：
On 27/08/2020 15:41, Frank Wunderlich wrote:
Hi Matthias,
any opinions about the dts-changes?
they look good to me.
maybe series except the tmds-Patch get merged...so i add it only to
1 - 100 of 417 matches
Mail list logo
