Re: [OpenWrt-Devel] [PATCH] Kernel patch in trunk (version 21251) to support Netgear WNR3500L

2010-05-20 Thread Tathagata Das

What do you mean to say clean up the flash driver you have ?

Regards,
Tathagata


Bernhard Loos wrote:

2010/5/17 Tathagata Das tathag...@alumnux.com:
  

Okay, so I will start working on those drivers (serial and wired). Does
current version of OpenWRT trunk supports WNR3500L ? Otherwise I need to
download latest trunk, modify it to run on WNR3500L and then concentrate on
drivers.



I doesn't but the difference from your version to latest trunk is pretty small.

  

If you elaborate the idea of spi master driver then it would help me to
proceed faster.



I checked out the flash controller code and it isn't plain spi, the
chipcommon core seems to have some control logic for the flash.
So if you clean up the flash driver you have, it should be enough.
Having a proper bus driver for the serial flash code would be nice,
but it's probably overkill.

  

Regards,
Tathagata

Bernhard Loos wrote:


2010/5/17 Tathagata Das tathag...@alumnux.com:

  

Hi,
I have used source code of version 21251. It might be possible that some
fixes has been made after that version which is not reflected in my code.
So
if I use latest code then that issue will be resolved.



The bugs are in the patch, not in the code already in openwrt, so it
won't.


  

You said that kernel patch should not contain any code under #ifdef. But
it
may happen that those changes are specific to WNR3500L. Then what should
be
the porting process ?



Something like this isn't wnr3500l speific:
+#ifndef CONFIG_WNR3500L
 void plat_irq_dispatch(void)
+#else
+void asmlinkage plat_irq_dispatch(void)
+#endif

If there is stuff specific to the wnr, you should wrap it in an
#ifdef-#endif, not #ifdef-#else-#endif, because it has to be possible
to build a kernel which supports both the old and socs.


  

If you tell how to move this patch into a proper form, I can do this.
However I have also one WNR3500L, nothing else.



Those are the worst problems, but you will spend a lot of time and
effort duplicating work I already did. I really suggest you spend your
time on some other area, as for example proper serial flash support (a
spi master driver) or network (both wired and wireless).


  

Regards,
Tathagata

Bernhard Loos wrote:



Hello
Thanks for you work, but as I already told you in the mail for your
last patch, this is not really useable as it is right now.
You can't simply go around and wrap everything you want to add in an
#ifdef, especially not things like that:
+#ifndef CONFIG_WNR3500L
 void plat_irq_dispatch(void)
+#else
+void asmlinkage plat_irq_dispatch(void)
+#endif
This is ugly as hell and unneeded. Such a thing will never get
accepted into mainline.
Those ifdefs also make it impossible to build a kernel supporting both
the new and the old bus type. And this is even besides all the bugs
still present in this code.
I am working on getting this patch into a proper form, but it's a slow
process, partly because I don't have that much time and partially
because I only have an 4716 device and nothing older.
If you could turn you serial driver into a proper spi master driver
and hook the flash up to, this would be very helpful. Changing the
flash map shouldn't be necessary, the rootfs_data partition is created
automatically.

 Bernhard


2010/5/14 Tathagata Das tathag...@alumnux.com:


  

Hi,
Attached is the kernel patch to support Netgear WNR3500L. All changes
are
made under CONFIG_WNR3500L.
I have used trunk source code of version number 21251 to create this
kernel
patch.

Regards,
Tathagata tathag...@alumnux.com



  


  

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


[OpenWrt-Devel] Optware refusal

2010-05-20 Thread Benjamin Henrion
It seems that the OpenWRT devs have entrenched views about optware packages:

https://dev.openwrt.org/ticket/944

-- 
Benjamin Henrion bhenrion at ffii.org
FFII Brussels - +32-484-566109 - +32-2-4148403
In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Configuring IPv6 with new firewall?

2010-05-20 Thread Roland Dreier
 I just committed some more changes to the firewall that allow you to
 selectively apply rules to only ip6tables or iptables. Consider the
 following example:

  config rule
      option src wan
      option proto tcp
      option dest_port 22
      option target ACCEPT
      option family ipv6

 This will add an ip6tables-only rule to accept port 22 on wan.

Thanks, I tried this with trunk built after your commit, and it doesn't
seem to work for me at least.  I think the problem is that I end up with
rules like the following (snipped from ip6tables -S output):

-A zone_wan -j input_wan
-A zone_wan -p ipv6-icmp -j ACCEPT
-A zone_wan -j zone_wan_REJECT
-A zone_wan -p tcp -m tcp --dport 22 -j ACCEPT

so the jump to the REJECT chain happens before the ACCEPT rule
and any connection attempts still get rejected.

I'll try to follow how the ip6tables rules get created in the scripts but
I'm not that familiar with all the code so it may be faster if you try too :)

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


Re: [OpenWrt-Devel] Configuring IPv6 with new firewall?

2010-05-20 Thread Roland Dreier
 Thanks, I tried this with trunk built after your commit, and it doesn't
 seem to work for me at least.  I think the problem is that I end up with
 rules like the following (snipped from ip6tables -S output):

 -A zone_wan -j input_wan
 -A zone_wan -p ipv6-icmp -j ACCEPT
 -A zone_wan -j zone_wan_REJECT
 -A zone_wan -p tcp -m tcp --dport 22 -j ACCEPT

And another really odd thing is that iptables -S shows (for a rule that
appears just before the port 22 / family ipv6 rule in my firewall config):

-A zone_wan -s 72.52.104.74/32 -p ipv6 -j ACCEPT
-A zone_wan -j input_wan
-A zone_wan -j zone_wan_REJECT

so that one gets added in the right order.

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


Re: [OpenWrt-Devel] Optware refusal

2010-05-20 Thread Bas Mevissen
On Thu, 2010-05-20 at 19:23 +0200, Benjamin Henrion wrote:
 It seems that the OpenWRT devs have entrenched views about optware packages:
 
 https://dev.openwrt.org/ticket/944
 

What's your reason for digging up a 4 year old ticket?

Bas.


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


[OpenWrt-Devel] problem connecting usb webcam

2010-05-20 Thread Kövesdi György
Hi,

on Asus WL500 gp V2, Backfire (svn revision #21506)
I have the following problem: 
Connected a Creative webcam (driver gspca_zc3xx) without problem. After some 
time of using, got the following error (messages on the console):

zc3xx: probe 2wr ov vga 0x  
 
ohci_hcd ssb0:1: fatal error
 
ohci_hcd ssb0:1: force halt; handhake b8003814 4000 4000 - -145
 
ohci_hcd ssb0:1: HC died; cleaning up
gspca: set alt 0 err -19
usb 2-1: USB disconnect, address 2
usb 2-1.1: USB disconnect, address 3
usb 2-1.1.1: USB disconnect, address 5
gspca: disconnect complete
usb 2-1.1.2: USB disconnect, address 6
usb 2-1.2: USB disconnect, address 4
.

It seems the whole USB subsystem is crashed. All devices are re-connected, 
including the hard disk.
I don't know what can be the problem. Any suggestions are welcome.
It works well with another, UVC-compatible webcam.

Thanx in advance
K. Gy.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] Kernel patch in trunk (version 21251) to support Netgear WNR3500L

2010-05-20 Thread Bernhard Loos
Your patch contains a driver for the serial flash chip on the
wnr3500l, but it's kinda ugly (excessive ioremaps, duplicated defines,
global statics, ...).
If you could clean this up, it would have a chance of getting accepted.

Bernhard

2010/5/20 Tathagata Das tathag...@alumnux.com:
 What do you mean to say clean up the flash driver you have ?

 Regards,
 Tathagata


 Bernhard Loos wrote:

 2010/5/17 Tathagata Das tathag...@alumnux.com:


 Okay, so I will start working on those drivers (serial and wired). Does
 current version of OpenWRT trunk supports WNR3500L ? Otherwise I need to
 download latest trunk, modify it to run on WNR3500L and then concentrate
 on
 drivers.


 I doesn't but the difference from your version to latest trunk is pretty
 small.



 If you elaborate the idea of spi master driver then it would help me to
 proceed faster.


 I checked out the flash controller code and it isn't plain spi, the
 chipcommon core seems to have some control logic for the flash.
 So if you clean up the flash driver you have, it should be enough.
 Having a proper bus driver for the serial flash code would be nice,
 but it's probably overkill.



 Regards,
 Tathagata

 Bernhard Loos wrote:


 2010/5/17 Tathagata Das tathag...@alumnux.com:



 Hi,
 I have used source code of version 21251. It might be possible that
 some
 fixes has been made after that version which is not reflected in my
 code.
 So
 if I use latest code then that issue will be resolved.



 The bugs are in the patch, not in the code already in openwrt, so it
 won't.




 You said that kernel patch should not contain any code under #ifdef.
 But
 it
 may happen that those changes are specific to WNR3500L. Then what
 should
 be
 the porting process ?



 Something like this isn't wnr3500l speific:
 +#ifndef CONFIG_WNR3500L
  void plat_irq_dispatch(void)
 +#else
 +void asmlinkage plat_irq_dispatch(void)
 +#endif

 If there is stuff specific to the wnr, you should wrap it in an
 #ifdef-#endif, not #ifdef-#else-#endif, because it has to be possible
 to build a kernel which supports both the old and socs.




 If you tell how to move this patch into a proper form, I can do this.
 However I have also one WNR3500L, nothing else.



 Those are the worst problems, but you will spend a lot of time and
 effort duplicating work I already did. I really suggest you spend your
 time on some other area, as for example proper serial flash support (a
 spi master driver) or network (both wired and wireless).




 Regards,
 Tathagata

 Bernhard Loos wrote:



 Hello
 Thanks for you work, but as I already told you in the mail for your
 last patch, this is not really useable as it is right now.
 You can't simply go around and wrap everything you want to add in an
 #ifdef, especially not things like that:
 +#ifndef CONFIG_WNR3500L
  void plat_irq_dispatch(void)
 +#else
 +void asmlinkage plat_irq_dispatch(void)
 +#endif
 This is ugly as hell and unneeded. Such a thing will never get
 accepted into mainline.
 Those ifdefs also make it impossible to build a kernel supporting both
 the new and the old bus type. And this is even besides all the bugs
 still present in this code.
 I am working on getting this patch into a proper form, but it's a slow
 process, partly because I don't have that much time and partially
 because I only have an 4716 device and nothing older.
 If you could turn you serial driver into a proper spi master driver
 and hook the flash up to, this would be very helpful. Changing the
 flash map shouldn't be necessary, the rootfs_data partition is created
 automatically.

         Bernhard


 2010/5/14 Tathagata Das tathag...@alumnux.com:




 Hi,
 Attached is the kernel patch to support Netgear WNR3500L. All changes
 are
 made under CONFIG_WNR3500L.
 I have used trunk source code of version number 21251 to create this
 kernel
 patch.

 Regards,
 Tathagata tathag...@alumnux.com








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


Re: [OpenWrt-Devel] [PATCH] Kernel patch in trunk (version 21251) to support Netgear WNR3500L

2010-05-20 Thread Tathagata Das
Fine, I will clean up this serial flash driver as much as possible and 
submit it again.


Regards,
Tathagata

Bernhard Loos wrote:

Your patch contains a driver for the serial flash chip on the
wnr3500l, but it's kinda ugly (excessive ioremaps, duplicated defines,
global statics, ...).
If you could clean this up, it would have a chance of getting accepted.

Bernhard

2010/5/20 Tathagata Das tathag...@alumnux.com:
  

What do you mean to say clean up the flash driver you have ?

Regards,
Tathagata


Bernhard Loos wrote:


2010/5/17 Tathagata Das tathag...@alumnux.com:

  

Okay, so I will start working on those drivers (serial and wired). Does
current version of OpenWRT trunk supports WNR3500L ? Otherwise I need to
download latest trunk, modify it to run on WNR3500L and then concentrate
on
drivers.



I doesn't but the difference from your version to latest trunk is pretty
small.


  

If you elaborate the idea of spi master driver then it would help me to
proceed faster.



I checked out the flash controller code and it isn't plain spi, the
chipcommon core seems to have some control logic for the flash.
So if you clean up the flash driver you have, it should be enough.
Having a proper bus driver for the serial flash code would be nice,
but it's probably overkill.


  

Regards,
Tathagata

Bernhard Loos wrote:



2010/5/17 Tathagata Das tathag...@alumnux.com:


  

Hi,
I have used source code of version 21251. It might be possible that
some
fixes has been made after that version which is not reflected in my
code.
So
if I use latest code then that issue will be resolved.




The bugs are in the patch, not in the code already in openwrt, so it
won't.



  

You said that kernel patch should not contain any code under #ifdef.
But
it
may happen that those changes are specific to WNR3500L. Then what
should
be
the porting process ?




Something like this isn't wnr3500l speific:
+#ifndef CONFIG_WNR3500L
 void plat_irq_dispatch(void)
+#else
+void asmlinkage plat_irq_dispatch(void)
+#endif

If there is stuff specific to the wnr, you should wrap it in an
#ifdef-#endif, not #ifdef-#else-#endif, because it has to be possible
to build a kernel which supports both the old and socs.



  

If you tell how to move this patch into a proper form, I can do this.
However I have also one WNR3500L, nothing else.




Those are the worst problems, but you will spend a lot of time and
effort duplicating work I already did. I really suggest you spend your
time on some other area, as for example proper serial flash support (a
spi master driver) or network (both wired and wireless).



  

Regards,
Tathagata

Bernhard Loos wrote:




Hello
Thanks for you work, but as I already told you in the mail for your
last patch, this is not really useable as it is right now.
You can't simply go around and wrap everything you want to add in an
#ifdef, especially not things like that:
+#ifndef CONFIG_WNR3500L
 void plat_irq_dispatch(void)
+#else
+void asmlinkage plat_irq_dispatch(void)
+#endif
This is ugly as hell and unneeded. Such a thing will never get
accepted into mainline.
Those ifdefs also make it impossible to build a kernel supporting both
the new and the old bus type. And this is even besides all the bugs
still present in this code.
I am working on getting this patch into a proper form, but it's a slow
process, partly because I don't have that much time and partially
because I only have an 4716 device and nothing older.
If you could turn you serial driver into a proper spi master driver
and hook the flash up to, this would be very helpful. Changing the
flash map shouldn't be necessary, the rootfs_data partition is created
automatically.

Bernhard


2010/5/14 Tathagata Das tathag...@alumnux.com:



  

Hi,
Attached is the kernel patch to support Netgear WNR3500L. All changes
are
made under CONFIG_WNR3500L.
I have used trunk source code of version number 21251 to create this
kernel
patch.

Regards,
Tathagata tathag...@alumnux.com




  
  


  

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