On Fri, Oct 19, 2018 at 04:21:09PM +0200, Tom Psyborg wrote:
> On 19/10/2018, Stanislaw Gruszka wrote:
> >
> > I tried to do this, but somehow after update BUILD1 image into device
> > my configuration was wiped out :-( and I have to reconfigure the
> > device now. Anyway I'm going to test and
On 19/10/2018, Stanislaw Gruszka wrote:
>
> I tried to do this, but somehow after update BUILD1 image into device
> my configuration was wiped out :-( and I have to reconfigure the
> device now. Anyway I'm going to test and provide dmesg , but this
> will take some time.
>
> Regards
> Stanislaw
>
On Wed, Oct 17, 2018 at 03:25:58PM +0200, Tom Psyborg wrote:
> On 16/10/2018, Stanislaw Gruszka wrote:
> > On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
> >> I am sending you two builds privately so please check if there are any
> >> differences between the two builds and report
On 16/10/2018, Stanislaw Gruszka wrote:
> Hello
>
> On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
>> I am sending you two builds privately so please check if there are any
>> differences between the two builds and report back. Thanks.
>
> I extracted rt2800lib.ko module from
On 16/10/2018, Stanislaw Gruszka wrote:
> Hello
>
> On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
>> I am sending you two builds privately so please check if there are any
>> differences between the two builds and report back. Thanks.
>
> I extracted rt2800lib.ko module from
Hello
On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
> I am sending you two builds privately so please check if there are any
> differences between the two builds and report back. Thanks.
I extracted rt2800lib.ko module from provided images, did disassembly via:
On 16/10/2018, Stanislaw Gruszka wrote:
> On Fri, Oct 12, 2018 at 02:41:41PM +0200, Tom Psyborg wrote:
>> On 12/10/2018, Stanislaw Gruszka wrote:
>> > On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
>> >> > On upstream tree where this patch is intended
>> >> > additional registers
On 2018-10-16 13:21, Stanislaw Gruszka wrote:
> On Tue, Oct 16, 2018 at 01:19:52PM +0200, Felix Fietkau wrote:
>> > I have no idea how this could be related. But I think I found
>> > somewhat reasonable explenation where the problem is.
>> > I think below code :
>> >
>> >if (a || b || c) {
>>
On Tue, Oct 16, 2018 at 01:19:52PM +0200, Felix Fietkau wrote:
> > I have no idea how this could be related. But I think I found
> > somewhat reasonable explenation where the problem is.
> > I think below code :
> >
> > if (a || b || c) {
> > CODE1();
> > } else if (c) {
> >
On 2018-10-16 10:09, Stanislaw Gruszka wrote:
> On Fri, Oct 12, 2018 at 02:41:41PM +0200, Tom Psyborg wrote:
>> On 12/10/2018, Stanislaw Gruszka wrote:
>> > On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
>> >> > On upstream tree where this patch is intended
>> >> > additional
On Tue, Oct 16, 2018 at 10:11:16AM +0200, Stanislaw Gruszka wrote:
> On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
> > chip version support exist in daniel's tree since a long time ago. so
> > don't disable registers initialization but try to upstream his
> > changes.
>
> Where is
On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
> chip version support exist in daniel's tree since a long time ago. so
> don't disable registers initialization but try to upstream his
> changes.
Where is this patch ? I can not find it.
Thanks
Stanislaw
On Fri, Oct 12, 2018 at 02:41:41PM +0200, Tom Psyborg wrote:
> On 12/10/2018, Stanislaw Gruszka wrote:
> > On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
> >> > On upstream tree where this patch is intended
> >> > additional registers where never programmed as proper branch
> >> >
On Sat, Oct 13, 2018 at 12:46:54PM +0300, Kalle Valo wrote:
> No '#if 0', please. If the code is not needed you can remove it, it's
> available from git history anyway if it's needed later.
Plase drop this patch, other patches from the set can be applied
without it.
Thanks
Stanislaw
Stanislaw Gruszka writes:
> There is duplicated 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that
> causes we do not perform register initialization for RT6352 (MT7620
> SOCs) in correct branch. Fix this and disable registers initialization
> that is specific to particular MT7620 revision.
>
>
On 12/10/2018, Stanislaw Gruszka wrote:
> On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
>> > On upstream tree where this patch is intended
>> > additional registers where never programmed as proper branch
>> > were never used, because of additional check in RT5390 branch.
>> >
>>
On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
> > On upstream tree where this patch is intended
> > additional registers where never programmed as proper branch
> > were never used, because of additional check in RT5390 branch.
> >
>
> on my hardware additional registers were
On 12/10/2018, Stanislaw Gruszka wrote:
> Please stop top-posting.
>
> On Fri, Oct 12, 2018 at 01:51:00PM +0200, Tom Psyborg wrote:
>> it will cause regression on other devices
>
> How exactly ?
the same way your wifi works without TX_SW_CFG entries and mine
doesn't, while both are RT6352
> On
Please stop top-posting.
On Fri, Oct 12, 2018 at 01:51:00PM +0200, Tom Psyborg wrote:
> it will cause regression on other devices
How exactly ? On upstream tree where this patch is intended
additional registers where never programmed as proper branch
were never used, because of additional check
it will cause regression on other devices
On 12/10/2018, Stanislaw Gruszka wrote:
> On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
>> chip version support exist in daniel's tree since a long time ago. so
>> don't disable registers initialization but try to upstream his
>> changes.
On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
> chip version support exist in daniel's tree since a long time ago. so
> don't disable registers initialization but try to upstream his
> changes.
I do not see reason for for blocking this change because some other
changes are not
chip version support exist in daniel's tree since a long time ago. so
don't disable registers initialization but try to upstream his
changes.
changing TX_SW_CFG* entries did not make any noticeable difference in
my tests either, besides small RX improvement with configured
TX_SW_CFG2.
waiting
There is duplicated 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that
causes we do not perform register initialization for RT6352 (MT7620
SOCs) in correct branch. Fix this and disable registers initialization
that is specific to particular MT7620 revision.
Signed-off-by: Stanislaw Gruszka
---
23 matches
Mail list logo
