Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2024-01-17 Thread Varadarajan Narayanan
On Thu, Dec 07, 2023 at 01:23:01PM +, Petr Štetiar wrote:
> Varadarajan Narayanan  [2023-12-07 15:29:23]:
>
> Hi,
>
> > SoC : QCOM IPQ9574
> > RAM : 2GB DDR4
> > Flash   : eMMC 8GB
> > WiFi: 1 x 2.4GHz
> >   1 x 5GHz
> >   1 x 6GHz
>
> BTW it doesn't build here:
>
>  Applying 
> openwrt.git/target/linux/ipq95xx/patches-6.1/0023-arm64-dts-qcom-add-few-more-reserved-memory-region.patch
>  using plaintext:
>  patching file arch/arm64/boot/dts/qcom/ipq6018.dtsi
>  patching file arch/arm64/boot/dts/qcom/ipq8074.dtsi
>  Hunk #1 FAILED at 85.
>  1 out of 1 hunk FAILED -- saving rejects to file 
> arch/arm64/boot/dts/qcom/ipq8074.dtsi.rej
>  Patch failed!  Please fix 
> openwrt.git/target/linux/ipq95xx/patches-6.1/0023-arm64-dts-qcom-add-few-more-reserved-memory-region.patch!
>
> Cheers,
>
> Petr

Have posted a cleaned up PR - https://github.com/openwrt/openwrt/pull/14417
Can you please take that.

Thanks
Varada

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2024-01-17 Thread Varadarajan Narayanan
On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:
>
> On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:
> > SoC : QCOM IPQ9574
> > RAM : 2GB DDR4
> > Flash   : eMMC 8GB
> > WiFi: 1 x 2.4GHz
> >   1 x 5GHz
> >   1 x 6GHz
> >
> > Signed-off-by: Varadarajan Narayanan 
>
> Without even looking at the code, please split this up as its
> not reviewable at all currently.
>
> Also, I would strongly encourage using Github PR for this.
>
>
> Regards,
> Robert

Have create a PR for this - https://github.com/openwrt/openwrt/pull/14417
Kindly review and provide feedback.

This is my first time creating a PR, please let me know if something is amiss.

Thanks
Varada


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-11 Thread Hauke Mehrtens

On 12/11/23 09:34, Robert Marko wrote:

On Mon, 11 Dec 2023 at 06:55, Varadarajan Narayanan
 wrote:


On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:

On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz  wrote:


Hi Robert,

Adding John's correct e-mail to the loop.

On 8.12.2023 11:02, Robert Marko wrote:

On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz  wrote:


Hi Robert,

On 7.12.2023 12:52, Robert Marko wrote:


On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote:

On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:

On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:

SoC : QCOM IPQ9574
RAM : 2GB DDR4
Flash   : eMMC 8GB
WiFi: 1 x 2.4GHz
  1 x 5GHz
  1 x 6GHz

Signed-off-by: Varadarajan Narayanan 

Without even looking at the code, please split this up as its
not reviewable at all currently.

Also, I would strongly encourage using Github PR for this.

This patch just has the base SoC/board support and not drivers for
WiFi/ethernet/USB etc. Can you kindly guide on what kind
of split is acceptable for the community.

Thanks
Varada


Hi,
I would at least split the target itself, patches and then the board
itself for the start.


Would it make sense to rename qualcommax to qualcomm and make ipq95xx
just another subtarget of it (I'm aware of A53 vs. A73)?


That depends on how much is shared between the AX SoC-s and the BE
ones(IPQ95xx and IPQ53xx).


I would say enough to keep them together.


But, I would prefer that or qualcommbe target where new BE SoC-s will
be subtargets.


I'm personally more a fan of limiting number of top targets and deal
with differences under subtargets.


Same here, better than to add more targets especially since a lot is shared.


Thanks for your inputs.

Shall I rename target/linux/qualcommax/ -> target/linux/ipq/ (1st preference
since it is IPQ product family) or target/linux/qualcomm/ and have ipq95xx
as subtarget?


I would prefer qualcomm and not ipq, and then ipq95xx as subtarget.


Hi,

It is probably easier if you add ipq95xx support to the existing 
qualcommax target first and rename it later in a separate step.


Every few days something changes in the qualcommax target and if you 
rename it you probably have to rebase very often.


Hauke

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-11 Thread Hauke Mehrtens

On 12/11/23 06:29, Varadarajan Narayanan wrote:

On Thu, Dec 07, 2023 at 08:36:14PM +0800, Chuanhong Guo wrote:

Hi!

On Thu, Dec 7, 2023 at 7:24 PM Varadarajan Narayanan
 wrote:


On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:


On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:

 SoC : QCOM IPQ9574
 RAM : 2GB DDR4
 Flash   : eMMC 8GB
 WiFi: 1 x 2.4GHz
   1 x 5GHz
   1 x 6GHz

Signed-off-by: Varadarajan Narayanan 


Without even looking at the code, please split this up as its
not reviewable at all currently.

Also, I would strongly encourage using Github PR for this.


This patch just has the base SoC/board support and not drivers for
WiFi/ethernet/USB etc.


An OpenWrt target with only a serial console isn't really useful.
It would be better to submit a complete patchset for a working target
instead.

Is there any plan for upstreaming support for basic functionalities like
ethernet and/or WiFi?


Yes, there is plan to post those functionalities in the coming weeks.


Hi Varada,

Could you share your current development tree already even if it is not 
ready yet. It would be helpful when you also tell us what you plan to 
change. Then we can already have a look and get a better understanding 
on how you expect this to look like in the end.


Hauke

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-11 Thread Robert Marko
On Mon, 11 Dec 2023 at 06:55, Varadarajan Narayanan
 wrote:
>
> On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:
> > On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz  wrote:
> > >
> > > Hi Robert,
> > >
> > > Adding John's correct e-mail to the loop.
> > >
> > > On 8.12.2023 11:02, Robert Marko wrote:
> > > > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz  wrote:
> > > >>
> > > >> Hi Robert,
> > > >>
> > > >> On 7.12.2023 12:52, Robert Marko wrote:
> > > >> >
> > > >> > On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote:
> > > >> >> On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:
> > > >> >>> On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:
> > > >> SoC : QCOM IPQ9574
> > > >> RAM : 2GB DDR4
> > > >> Flash   : eMMC 8GB
> > > >> WiFi: 1 x 2.4GHz
> > > >>   1 x 5GHz
> > > >>   1 x 6GHz
> > > >> 
> > > >>  Signed-off-by: Varadarajan Narayanan 
> > > >> >>> Without even looking at the code, please split this up as its
> > > >> >>> not reviewable at all currently.
> > > >> >>>
> > > >> >>> Also, I would strongly encourage using Github PR for this.
> > > >> >> This patch just has the base SoC/board support and not drivers for
> > > >> >> WiFi/ethernet/USB etc. Can you kindly guide on what kind
> > > >> >> of split is acceptable for the community.
> > > >> >>
> > > >> >> Thanks
> > > >> >> Varada
> > > >> >
> > > >> > Hi,
> > > >> > I would at least split the target itself, patches and then the board
> > > >> > itself for the start.
> > > >>
> > > >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> > > >> just another subtarget of it (I'm aware of A53 vs. A73)?
> > > >
> > > > That depends on how much is shared between the AX SoC-s and the BE
> > > > ones(IPQ95xx and IPQ53xx).
> > >
> > > I would say enough to keep them together.
> > >
> > > > But, I would prefer that or qualcommbe target where new BE SoC-s will
> > > > be subtargets.
> > >
> > > I'm personally more a fan of limiting number of top targets and deal
> > > with differences under subtargets.
> >
> > Same here, better than to add more targets especially since a lot is shared.
>
> Thanks for your inputs.
>
> Shall I rename target/linux/qualcommax/ -> target/linux/ipq/ (1st preference
> since it is IPQ product family) or target/linux/qualcomm/ and have ipq95xx
> as subtarget?

I would prefer qualcomm and not ipq, and then ipq95xx as subtarget.

Regards,
Robert
>
> Kindly let me know.
>
> Thanks
> Varada
>
> >
> > Regards,
> > Robert
> > >
> > > --
> > > Cheers,
> > > Piotr
> > >
> > > >
> > > > Regards,
> > > > Robert
> > > >>
> > > >> --
> > > >> Cheers,
> > > >> Piotr
> > > >>
> > > >> >
> > > >> > Also, please sort the patches by prefix such as:
> > > >> > 0xx are backports (Kernel version from which they are backported 
> > > >> > must be
> > > >> > marked as well)
> > > >> > 1xx are pending
> > > >> > 9xx are usually hacks/stuff that currently cannot be upstreamed.
> > > >> >
> > > >> > Again, I would strongly encourage using Github PR for large changes 
> > > >> > such
> > > >> > as these as its much
> > > >> > easier to comment on certain changes and it has a lot larger reach 
> > > >> > than
> > > >> > the OpenWrt mailing list
> > > >> > as not all interested parties even follow this list.
> > > >> >
> > > >> > Regards,
> > > >> > Robert
> > > >> >
> > > >> >
> > > >> > ___
> > > >> > openwrt-devel mailing list
> > > >> > openwrt-devel@lists.openwrt.org
> > > >> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> > > >>
> > >

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-10 Thread Varadarajan Narayanan
On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:
> On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz  wrote:
> >
> > Hi Robert,
> >
> > Adding John's correct e-mail to the loop.
> >
> > On 8.12.2023 11:02, Robert Marko wrote:
> > > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz  wrote:
> > >>
> > >> Hi Robert,
> > >>
> > >> On 7.12.2023 12:52, Robert Marko wrote:
> > >> >
> > >> > On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote:
> > >> >> On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:
> > >> >>> On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:
> > >> SoC : QCOM IPQ9574
> > >> RAM : 2GB DDR4
> > >> Flash   : eMMC 8GB
> > >> WiFi: 1 x 2.4GHz
> > >>   1 x 5GHz
> > >>   1 x 6GHz
> > >> 
> > >>  Signed-off-by: Varadarajan Narayanan 
> > >> >>> Without even looking at the code, please split this up as its
> > >> >>> not reviewable at all currently.
> > >> >>>
> > >> >>> Also, I would strongly encourage using Github PR for this.
> > >> >> This patch just has the base SoC/board support and not drivers for
> > >> >> WiFi/ethernet/USB etc. Can you kindly guide on what kind
> > >> >> of split is acceptable for the community.
> > >> >>
> > >> >> Thanks
> > >> >> Varada
> > >> >
> > >> > Hi,
> > >> > I would at least split the target itself, patches and then the board
> > >> > itself for the start.
> > >>
> > >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> > >> just another subtarget of it (I'm aware of A53 vs. A73)?
> > >
> > > That depends on how much is shared between the AX SoC-s and the BE
> > > ones(IPQ95xx and IPQ53xx).
> >
> > I would say enough to keep them together.
> >
> > > But, I would prefer that or qualcommbe target where new BE SoC-s will
> > > be subtargets.
> >
> > I'm personally more a fan of limiting number of top targets and deal
> > with differences under subtargets.
>
> Same here, better than to add more targets especially since a lot is shared.

Thanks for your inputs.

Shall I rename target/linux/qualcommax/ -> target/linux/ipq/ (1st preference
since it is IPQ product family) or target/linux/qualcomm/ and have ipq95xx
as subtarget?

Kindly let me know.

Thanks
Varada

>
> Regards,
> Robert
> >
> > --
> > Cheers,
> > Piotr
> >
> > >
> > > Regards,
> > > Robert
> > >>
> > >> --
> > >> Cheers,
> > >> Piotr
> > >>
> > >> >
> > >> > Also, please sort the patches by prefix such as:
> > >> > 0xx are backports (Kernel version from which they are backported must 
> > >> > be
> > >> > marked as well)
> > >> > 1xx are pending
> > >> > 9xx are usually hacks/stuff that currently cannot be upstreamed.
> > >> >
> > >> > Again, I would strongly encourage using Github PR for large changes 
> > >> > such
> > >> > as these as its much
> > >> > easier to comment on certain changes and it has a lot larger reach than
> > >> > the OpenWrt mailing list
> > >> > as not all interested parties even follow this list.
> > >> >
> > >> > Regards,
> > >> > Robert
> > >> >
> > >> >
> > >> > ___
> > >> > openwrt-devel mailing list
> > >> > openwrt-devel@lists.openwrt.org
> > >> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> > >>
> >

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-10 Thread Varadarajan Narayanan
On Thu, Dec 07, 2023 at 08:36:14PM +0800, Chuanhong Guo wrote:
> Hi!
>
> On Thu, Dec 7, 2023 at 7:24 PM Varadarajan Narayanan
>  wrote:
> >
> > On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:
> > >
> > > On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:
> > > > SoC : QCOM IPQ9574
> > > > RAM : 2GB DDR4
> > > > Flash   : eMMC 8GB
> > > > WiFi: 1 x 2.4GHz
> > > >   1 x 5GHz
> > > >   1 x 6GHz
> > > >
> > > > Signed-off-by: Varadarajan Narayanan 
> > >
> > > Without even looking at the code, please split this up as its
> > > not reviewable at all currently.
> > >
> > > Also, I would strongly encourage using Github PR for this.
> >
> > This patch just has the base SoC/board support and not drivers for
> > WiFi/ethernet/USB etc.
>
> An OpenWrt target with only a serial console isn't really useful.
> It would be better to submit a complete patchset for a working target
> instead.
>
> Is there any plan for upstreaming support for basic functionalities like
> ethernet and/or WiFi?

Yes, there is plan to post those functionalities in the coming weeks.

Thanks
Varada

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-08 Thread Elliott Mitchell
On Fri, Dec 08, 2023 at 06:53:31PM +0100, Thibaut wrote:
> 
> > Le 8 déc. 2023 à 16:39, Elliott Mitchell  a écrit :
> > 
> > On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:
> >> On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz  wrote:
> >>> 
> >>> On 8.12.2023 11:02, Robert Marko wrote:
>  On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz  wrote:
> > 
> > Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> > just another subtarget of it (I'm aware of A53 vs. A73)?
>  
>  That depends on how much is shared between the AX SoC-s and the BE
>  ones(IPQ95xx and IPQ53xx).
> >>> 
> >>> I would say enough to keep them together.
> >>> 
>  But, I would prefer that or qualcommbe target where new BE SoC-s will
>  be subtargets.
> >>> 
> >>> I'm personally more a fan of limiting number of top targets and deal
> >>> with differences under subtargets.
> >> 
> >> Same here, better than to add more targets especially since a lot is 
> >> shared.
> > 
> > This leads to needing more levels of organization.  Instead of simply
> > TARGET/SUBTARGET, you end up needing TARGET/SUBTARGET/SUBSUBTARGET.  If
> > this is going to be done, then the implementation should allow for an
> > arbitrary number of levels.
> > 
> > A makefile fragment I created for testing:
> > 
> > foo := foo0
> > SUBfoo := foo1
> > SUBSUBfoo := foo2
> > 
> > define recur
> > $(info current is $(1), value is $($(1
> > ignore := $(if $(filter $(flavor SUB$(1)),undefined),,$(call recur,SUB$(1)))
> > endef
> > 
> > ignore := $(call recur,foo)
> > 
> > all: test.make
> > @true
> > 
> > So an arbitrary number of levels seems doable.
> 
> No.
> 
> >  Will mean rather
> > substantial changes to the build system though.  I tend to favor this
> > as the 2 level limitation is already placing restrictions on the scaling
> > of the build count.
> 
> It appears most people do not understand that {sub}+targets use the exact 
> same amount of build resources *each* as a whole target. There is no benefit, 
> from the PoV of the (phase1) builders, to having more subtargets vs more 
> targets: either way, growing either number indefinitely is simply not 
> sustainable. Please don’t do that.
> 

So, you would prefer to have all of a small cupcake, to a slice of a
much larger cake?

You would prefer to be the big fish in the small pond to the small fish
in the much larger lake?

This is not an invalid choice, but usually projects prefer to grow than
shrink.  Also, while having more levels should allow better organization
and then more growth; making growth possible does not force growth to
occur.


What I've observed from rather a lot of wildly different builds in the
past month differs.  Most of any OpenWRT build is unshared, but some
portions are reused and substantially greater portions could be reused.

Notably the compiler was reused.  If steps were taken to allow reusing
unpacked kernel source, the kernel would only need to be unpacked once
(some of the patches I've sent aim in this direction).

One thing I've noticed is the single-thread portions are a *major*
holdback at this point.  The single-thread unpacking of various tarballs
completely overwhelmed the portions of builds which used multiple
processors.

Right now my storage is sick and providing poor write performance (wow,
that battery-backed cache was *impressive*!), yet all OpenWRT builds
averaged less than a single processor in use.  That is rather concerning.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-08 Thread Thibaut


> Le 8 déc. 2023 à 16:39, Elliott Mitchell  a écrit :
> 
> On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:
>> On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz  wrote:
>>> 
>>> On 8.12.2023 11:02, Robert Marko wrote:
 On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz  wrote:
> 
> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> just another subtarget of it (I'm aware of A53 vs. A73)?
 
 That depends on how much is shared between the AX SoC-s and the BE
 ones(IPQ95xx and IPQ53xx).
>>> 
>>> I would say enough to keep them together.
>>> 
 But, I would prefer that or qualcommbe target where new BE SoC-s will
 be subtargets.
>>> 
>>> I'm personally more a fan of limiting number of top targets and deal
>>> with differences under subtargets.
>> 
>> Same here, better than to add more targets especially since a lot is shared.
> 
> This leads to needing more levels of organization.  Instead of simply
> TARGET/SUBTARGET, you end up needing TARGET/SUBTARGET/SUBSUBTARGET.  If
> this is going to be done, then the implementation should allow for an
> arbitrary number of levels.
> 
> A makefile fragment I created for testing:
> 
> foo := foo0
> SUBfoo := foo1
> SUBSUBfoo := foo2
> 
> define recur
> $(info current is $(1), value is $($(1
> ignore := $(if $(filter $(flavor SUB$(1)),undefined),,$(call recur,SUB$(1)))
> endef
> 
> ignore := $(call recur,foo)
> 
> all: test.make
>   @true
> 
> So an arbitrary number of levels seems doable.

No.

>  Will mean rather
> substantial changes to the build system though.  I tend to favor this
> as the 2 level limitation is already placing restrictions on the scaling
> of the build count.

It appears most people do not understand that {sub}+targets use the exact same 
amount of build resources *each* as a whole target. There is no benefit, from 
the PoV of the (phase1) builders, to having more subtargets vs more targets: 
either way, growing either number indefinitely is simply not sustainable. 
Please don’t do that.

My 2c.

T.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-08 Thread Robert Marko
On Fri, 8 Dec 2023 at 16:39, Elliott Mitchell  wrote:
>
> On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:
> > On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz  wrote:
> > >
> > > On 8.12.2023 11:02, Robert Marko wrote:
> > > > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz  wrote:
> > > >>
> > > >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> > > >> just another subtarget of it (I'm aware of A53 vs. A73)?
> > > >
> > > > That depends on how much is shared between the AX SoC-s and the BE
> > > > ones(IPQ95xx and IPQ53xx).
> > >
> > > I would say enough to keep them together.
> > >
> > > > But, I would prefer that or qualcommbe target where new BE SoC-s will
> > > > be subtargets.
> > >
> > > I'm personally more a fan of limiting number of top targets and deal
> > > with differences under subtargets.
> >
> > Same here, better than to add more targets especially since a lot is shared.
>
> This leads to needing more levels of organization.  Instead of simply
> TARGET/SUBTARGET, you end up needing TARGET/SUBTARGET/SUBSUBTARGET.  If
> this is going to be done, then the implementation should allow for an
> arbitrary number of levels.

Not really, there is no need for SUBSUBTARGET at all.
When I say, they share stuff, I mean drivers are shared and thus
target/subtarget model works just fine here.
>
> A makefile fragment I created for testing:
>
> foo := foo0
> SUBfoo := foo1
> SUBSUBfoo := foo2
>
> define recur
> $(info current is $(1), value is $($(1
> ignore := $(if $(filter $(flavor SUB$(1)),undefined),,$(call recur,SUB$(1)))
> endef
>
> ignore := $(call recur,foo)
>
> all: test.make
> @true
>
> So an arbitrary number of levels seems doable.  Will mean rather
> substantial changes to the build system though.  I tend to favor this
> as the 2 level limitation is already placing restrictions on the scaling
> of the build count.
>
>
> --
> (\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
>  \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
>   \_CS\   |  _  -O #include  O-   _  |   /  _/
> 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
>
>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-08 Thread Elliott Mitchell
On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:
> On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz  wrote:
> >
> > On 8.12.2023 11:02, Robert Marko wrote:
> > > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz  wrote:
> > >>
> > >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> > >> just another subtarget of it (I'm aware of A53 vs. A73)?
> > >
> > > That depends on how much is shared between the AX SoC-s and the BE
> > > ones(IPQ95xx and IPQ53xx).
> >
> > I would say enough to keep them together.
> >
> > > But, I would prefer that or qualcommbe target where new BE SoC-s will
> > > be subtargets.
> >
> > I'm personally more a fan of limiting number of top targets and deal
> > with differences under subtargets.
> 
> Same here, better than to add more targets especially since a lot is shared.

This leads to needing more levels of organization.  Instead of simply
TARGET/SUBTARGET, you end up needing TARGET/SUBTARGET/SUBSUBTARGET.  If
this is going to be done, then the implementation should allow for an
arbitrary number of levels.

A makefile fragment I created for testing:

foo := foo0
SUBfoo := foo1
SUBSUBfoo := foo2

define recur
$(info current is $(1), value is $($(1
ignore := $(if $(filter $(flavor SUB$(1)),undefined),,$(call recur,SUB$(1)))
endef

ignore := $(call recur,foo)

all: test.make
@true

So an arbitrary number of levels seems doable.  Will mean rather
substantial changes to the build system though.  I tend to favor this
as the 2 level limitation is already placing restrictions on the scaling
of the build count.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-08 Thread Robert Marko
On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz  wrote:
>
> Hi Robert,
>
> Adding John's correct e-mail to the loop.
>
> On 8.12.2023 11:02, Robert Marko wrote:
> > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz  wrote:
> >>
> >> Hi Robert,
> >>
> >> On 7.12.2023 12:52, Robert Marko wrote:
> >> >
> >> > On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote:
> >> >> On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:
> >> >>> On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:
> >> SoC : QCOM IPQ9574
> >> RAM : 2GB DDR4
> >> Flash   : eMMC 8GB
> >> WiFi: 1 x 2.4GHz
> >>   1 x 5GHz
> >>   1 x 6GHz
> >> 
> >>  Signed-off-by: Varadarajan Narayanan 
> >> >>> Without even looking at the code, please split this up as its
> >> >>> not reviewable at all currently.
> >> >>>
> >> >>> Also, I would strongly encourage using Github PR for this.
> >> >> This patch just has the base SoC/board support and not drivers for
> >> >> WiFi/ethernet/USB etc. Can you kindly guide on what kind
> >> >> of split is acceptable for the community.
> >> >>
> >> >> Thanks
> >> >> Varada
> >> >
> >> > Hi,
> >> > I would at least split the target itself, patches and then the board
> >> > itself for the start.
> >>
> >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> >> just another subtarget of it (I'm aware of A53 vs. A73)?
> >
> > That depends on how much is shared between the AX SoC-s and the BE
> > ones(IPQ95xx and IPQ53xx).
>
> I would say enough to keep them together.
>
> > But, I would prefer that or qualcommbe target where new BE SoC-s will
> > be subtargets.
>
> I'm personally more a fan of limiting number of top targets and deal
> with differences under subtargets.

Same here, better than to add more targets especially since a lot is shared.

Regards,
Robert
>
> --
> Cheers,
> Piotr
>
> >
> > Regards,
> > Robert
> >>
> >> --
> >> Cheers,
> >> Piotr
> >>
> >> >
> >> > Also, please sort the patches by prefix such as:
> >> > 0xx are backports (Kernel version from which they are backported must be
> >> > marked as well)
> >> > 1xx are pending
> >> > 9xx are usually hacks/stuff that currently cannot be upstreamed.
> >> >
> >> > Again, I would strongly encourage using Github PR for large changes such
> >> > as these as its much
> >> > easier to comment on certain changes and it has a lot larger reach than
> >> > the OpenWrt mailing list
> >> > as not all interested parties even follow this list.
> >> >
> >> > Regards,
> >> > Robert
> >> >
> >> >
> >> > ___
> >> > openwrt-devel mailing list
> >> > openwrt-devel@lists.openwrt.org
> >> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >>
>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-08 Thread Piotr Dymacz

Hi Robert,

Adding John's correct e-mail to the loop.

On 8.12.2023 11:02, Robert Marko wrote:

On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz  wrote:


Hi Robert,

On 7.12.2023 12:52, Robert Marko wrote:
>
> On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote:
>> On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:
>>> On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:
SoC : QCOM IPQ9574
RAM : 2GB DDR4
Flash   : eMMC 8GB
WiFi: 1 x 2.4GHz
  1 x 5GHz
  1 x 6GHz

 Signed-off-by: Varadarajan Narayanan 
>>> Without even looking at the code, please split this up as its
>>> not reviewable at all currently.
>>>
>>> Also, I would strongly encourage using Github PR for this.
>> This patch just has the base SoC/board support and not drivers for
>> WiFi/ethernet/USB etc. Can you kindly guide on what kind
>> of split is acceptable for the community.
>>
>> Thanks
>> Varada
>
> Hi,
> I would at least split the target itself, patches and then the board
> itself for the start.

Would it make sense to rename qualcommax to qualcomm and make ipq95xx
just another subtarget of it (I'm aware of A53 vs. A73)?


That depends on how much is shared between the AX SoC-s and the BE
ones(IPQ95xx and IPQ53xx).


I would say enough to keep them together.


But, I would prefer that or qualcommbe target where new BE SoC-s will
be subtargets.


I'm personally more a fan of limiting number of top targets and deal 
with differences under subtargets.


--
Cheers,
Piotr



Regards,
Robert


--
Cheers,
Piotr

>
> Also, please sort the patches by prefix such as:
> 0xx are backports (Kernel version from which they are backported must be
> marked as well)
> 1xx are pending
> 9xx are usually hacks/stuff that currently cannot be upstreamed.
>
> Again, I would strongly encourage using Github PR for large changes such
> as these as its much
> easier to comment on certain changes and it has a lot larger reach than
> the OpenWrt mailing list
> as not all interested parties even follow this list.
>
> Regards,
> Robert
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-08 Thread Robert Marko
On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz  wrote:
>
> Hi Robert,
>
> On 7.12.2023 12:52, Robert Marko wrote:
> >
> > On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote:
> >> On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:
> >>> On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:
> SoC : QCOM IPQ9574
> RAM : 2GB DDR4
> Flash   : eMMC 8GB
> WiFi: 1 x 2.4GHz
>   1 x 5GHz
>   1 x 6GHz
> 
>  Signed-off-by: Varadarajan Narayanan 
> >>> Without even looking at the code, please split this up as its
> >>> not reviewable at all currently.
> >>>
> >>> Also, I would strongly encourage using Github PR for this.
> >> This patch just has the base SoC/board support and not drivers for
> >> WiFi/ethernet/USB etc. Can you kindly guide on what kind
> >> of split is acceptable for the community.
> >>
> >> Thanks
> >> Varada
> >
> > Hi,
> > I would at least split the target itself, patches and then the board
> > itself for the start.
>
> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> just another subtarget of it (I'm aware of A53 vs. A73)?

That depends on how much is shared between the AX SoC-s and the BE
ones(IPQ95xx and IPQ53xx).
But, I would prefer that or qualcommbe target where new BE SoC-s will
be subtargets.

Regards,
Robert
>
> --
> Cheers,
> Piotr
>
> >
> > Also, please sort the patches by prefix such as:
> > 0xx are backports (Kernel version from which they are backported must be
> > marked as well)
> > 1xx are pending
> > 9xx are usually hacks/stuff that currently cannot be upstreamed.
> >
> > Again, I would strongly encourage using Github PR for large changes such
> > as these as its much
> > easier to comment on certain changes and it has a lot larger reach than
> > the OpenWrt mailing list
> > as not all interested parties even follow this list.
> >
> > Regards,
> > Robert
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-08 Thread Piotr Dymacz

Hi Robert,

On 7.12.2023 12:52, Robert Marko wrote:


On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote:

On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:

On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:

SoC : QCOM IPQ9574
RAM : 2GB DDR4
Flash   : eMMC 8GB
WiFi: 1 x 2.4GHz
  1 x 5GHz
  1 x 6GHz

Signed-off-by: Varadarajan Narayanan 

Without even looking at the code, please split this up as its
not reviewable at all currently.

Also, I would strongly encourage using Github PR for this.

This patch just has the base SoC/board support and not drivers for
WiFi/ethernet/USB etc. Can you kindly guide on what kind
of split is acceptable for the community.

Thanks
Varada


Hi,
I would at least split the target itself, patches and then the board
itself for the start.


Would it make sense to rename qualcommax to qualcomm and make ipq95xx 
just another subtarget of it (I'm aware of A53 vs. A73)?


--
Cheers,
Piotr



Also, please sort the patches by prefix such as:
0xx are backports (Kernel version from which they are backported must be
marked as well)
1xx are pending
9xx are usually hacks/stuff that currently cannot be upstreamed.

Again, I would strongly encourage using Github PR for large changes such
as these as its much
easier to comment on certain changes and it has a lot larger reach than
the OpenWrt mailing list
as not all interested parties even follow this list.

Regards,
Robert


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-07 Thread Petr Štetiar
Varadarajan Narayanan  [2023-12-07 15:29:23]:

Hi,

> SoC   : QCOM IPQ9574
>   RAM : 2GB DDR4
>   Flash   : eMMC 8GB
>   WiFi: 1 x 2.4GHz
> 1 x 5GHz
> 1 x 6GHz

BTW it doesn't build here:

 Applying 
openwrt.git/target/linux/ipq95xx/patches-6.1/0023-arm64-dts-qcom-add-few-more-reserved-memory-region.patch
 using plaintext: 
 patching file arch/arm64/boot/dts/qcom/ipq6018.dtsi
 patching file arch/arm64/boot/dts/qcom/ipq8074.dtsi
 Hunk #1 FAILED at 85.
 1 out of 1 hunk FAILED -- saving rejects to file 
arch/arm64/boot/dts/qcom/ipq8074.dtsi.rej
 Patch failed!  Please fix 
openwrt.git/target/linux/ipq95xx/patches-6.1/0023-arm64-dts-qcom-add-few-more-reserved-memory-region.patch!

Cheers,

Petr

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-07 Thread Chuanhong Guo
Hi!

On Thu, Dec 7, 2023 at 7:24 PM Varadarajan Narayanan
 wrote:
>
> On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:
> >
> > On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:
> > > SoC : QCOM IPQ9574
> > > RAM : 2GB DDR4
> > > Flash   : eMMC 8GB
> > > WiFi: 1 x 2.4GHz
> > >   1 x 5GHz
> > >   1 x 6GHz
> > >
> > > Signed-off-by: Varadarajan Narayanan 
> >
> > Without even looking at the code, please split this up as its
> > not reviewable at all currently.
> >
> > Also, I would strongly encourage using Github PR for this.
>
> This patch just has the base SoC/board support and not drivers for
> WiFi/ethernet/USB etc.

An OpenWrt target with only a serial console isn't really useful.
It would be better to submit a complete patchset for a working target
instead.

Is there any plan for upstreaming support for basic functionalities like
ethernet and/or WiFi?

--
Regards,
Chuanhong Guo

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-07 Thread Robert Marko



On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote:

On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote:

On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote:

SoC : QCOM IPQ9574
RAM : 2GB DDR4
Flash   : eMMC 8GB
WiFi: 1 x 2.4GHz
  1 x 5GHz
  1 x 6GHz

Signed-off-by: Varadarajan Narayanan 

Without even looking at the code, please split this up as its
not reviewable at all currently.

Also, I would strongly encourage using Github PR for this.

This patch just has the base SoC/board support and not drivers for
WiFi/ethernet/USB etc. Can you kindly guide on what kind
of split is acceptable for the community.

Thanks
Varada


Hi,
I would at least split the target itself, patches and then the board 
itself for the start.


Also, please sort the patches by prefix such as:
0xx are backports (Kernel version from which they are backported must be 
marked as well)

1xx are pending
9xx are usually hacks/stuff that currently cannot be upstreamed.

Again, I would strongly encourage using Github PR for large changes such 
as these as its much
easier to comment on certain changes and it has a lot larger reach than 
the OpenWrt mailing list

as not all interested parties even follow this list.

Regards,
Robert


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel