Re: [PATCH v2 4/6] dt: bindings: add mt7621-pll dt binding documentation
Am 18.08.19 um 10:44 schrieb Chuanhong Guo:
> On Sun, Aug 18, 2019 at 4:26 PM Chuanhong Guo wrote:
>>
>> Hi!
>>
>> On Sun, Aug 18, 2019 at 3:59 PM Oleksij Rempel
>> wrote:
>>>
>>> Am 18.08.19 um 09:19 schrieb Chuanhong Guo:
>>>> Hi!
>>>>
>>>> On Sun, Aug 18, 2019 at 2:10 PM Oleksij Rempel
>>>> wrote:
>>>>>
>>>>>>> We have at least 2 know registers:
>>>>>>> SYSC_REG_CPLL_CLKCFG0 - it provides some information about boostrapped
>>>>>>> refclock. PLL and dividers used for CPU and some sort of BUS (AHB?).
>>>>>>> SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for
>>>>>>> all or some ip cores.
>>>>>>> What is probably missing is a set of dividers for
>>>>>>> each ip core. From your words it is not document.
>>>>>>
>>>>>> The specific missing part I was referring to, is parent clocks for
>>>>>> every gates. I'm not going to assume this with current openwrt device
>>>>>> tree because some peripherals doesn't have a clock binding at all or
>>>>>> have a dummy one there.
>>>>>
>>>>> Ok, then I do not understand what is the motivation to upstream
>>>>> something what is not nearly ready for use.
>>>>
>>>> Why isn't it "ready for use" then?
>>>> A complete mt7621-pll driver will contain two parts:
>>>> 1. A clock provider which outputs several clocks
>>>> 2. A clock gate with parent clocks properly configured
>>>>
>>>> Two clocks provided here are just two clocks that can't be controlled
>>>> in kernel no matter where it goes (arch/mips/ralink or drivers/clk).
>>>> Having a working CPU clock provider is better than defining a fixed
>>>> clock in dts because CPU clock can be controlled by bootloader.
>>>> (BTW description for CPU PLL register is also missing in datasheet.)
>>>> Clock gate is an unrelated part and there is no information to
>>>> properly implement it unless MTK decided to release a clock plan
>>>> somehow.
>>>
>>> With other words, your complete system is running with unknown clock
>>> rates.
>>
>> And without this patchset the complete system is running with unknown
>> clock and, even worse, we make assumptions about what clock bootloader
>> uses, hardcoded it in dts and hope it is the correct value.
>>
>>> The source clock in the clock three can be configured differently
>>> by bootloader but you don't know how it is done how and it is not
>>> documented.
>>
>> Actually, I don't know about this and I didn't wrote the original
>> clock calculation code. I just ported it from downstream OpenWrt
>> kernel. Here's a piece of code from Mediatek's SDK kernel:
>>
>> case 0:
>> reg = (*(volatile u32 *)(RALINK_SYSCTL_BASE + 0x44));
>> cpu_fdiv = ((reg >> 8) & 0x1F);
>> cpu_ffrac = (reg & 0x1F);
>> mips_cpu_feq = (500 * cpu_ffrac / cpu_fdiv) * 1000 * 1000;
>> break;
>> case 1: //CPU PLL
>> reg = (*(volatile u32 *)(RALINK_MEMCTRL_BASE + 0x648));
>> fbdiv = ((reg >> 4) & 0x7F) + 1;
>> reg = (*(volatile u32 *)(RALINK_SYSCTL_BASE + 0x10));
>> reg = (reg >> 6) & 0x7;
>> if(reg >= 6) { //25Mhz Xtal
>> mips_cpu_feq = 25 * fbdiv * 1000 * 1000;
>> } else if(reg >=3) { //40Mhz Xtal
>> mips_cpu_feq = 20 * fbdiv * 1000 * 1000;
>> } else { // 20Mhz Xtal
>> /* TODO */
>> }
>> break;
>>
>>
>>
>>>
>>>>> This code is currently on prototyping phase
>>>>
>>>> Code for clock calculation is done, not "prototyping".
>>>>
>>>>> It means, we cannot expect that this driver will be fixed any time soon.
>>>>
>>>> I think clock gating is a separated feature instead of a broken part
>>>> that has to be fixed.
>>>
>>> Ok, i would agree with it. But from what you said, this feature will be
>>> never implemented.
>>>
>>> So, I repeat my question. What is the point to upstream code for a
>>> system, which has not enough information to get proper clock rate even
>>> for uart? or is uart running with cpu or bus clock rate?
Re: [PATCH v2 4/6] dt: bindings: add mt7621-pll dt binding documentation
Am 18.08.19 um 09:19 schrieb Chuanhong Guo: > Hi! > > On Sun, Aug 18, 2019 at 2:10 PM Oleksij Rempel wrote: >> >>>> We have at least 2 know registers: >>>> SYSC_REG_CPLL_CLKCFG0 - it provides some information about boostrapped >>>> refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). >>>> SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for >>>> all or some ip cores. >>>> What is probably missing is a set of dividers for >>>> each ip core. From your words it is not document. >>> >>> The specific missing part I was referring to, is parent clocks for >>> every gates. I'm not going to assume this with current openwrt device >>> tree because some peripherals doesn't have a clock binding at all or >>> have a dummy one there. >> >> Ok, then I do not understand what is the motivation to upstream >> something what is not nearly ready for use. > > Why isn't it "ready for use" then? > A complete mt7621-pll driver will contain two parts: > 1. A clock provider which outputs several clocks > 2. A clock gate with parent clocks properly configured > > Two clocks provided here are just two clocks that can't be controlled > in kernel no matter where it goes (arch/mips/ralink or drivers/clk). > Having a working CPU clock provider is better than defining a fixed > clock in dts because CPU clock can be controlled by bootloader. > (BTW description for CPU PLL register is also missing in datasheet.) > Clock gate is an unrelated part and there is no information to > properly implement it unless MTK decided to release a clock plan > somehow. With other words, your complete system is running with unknown clock rates. The source clock in the clock three can be configured differently by bootloader but you don't know how it is done how and it is not documented. >> This code is currently on prototyping phase > > Code for clock calculation is done, not "prototyping". > >> It means, we cannot expect that this driver will be fixed any time soon. > > I think clock gating is a separated feature instead of a broken part > that has to be fixed. Ok, i would agree with it. But from what you said, this feature will be never implemented. So, I repeat my question. What is the point to upstream code for a system, which has not enough information to get proper clock rate even for uart? or is uart running with cpu or bus clock rate? -- Regards, Oleksij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/6] dt: bindings: add mt7621-pll dt binding documentation
Am 18.08.19 um 04:29 schrieb Chuanhong Guo: > Hi! > > On Sun, Aug 18, 2019 at 2:06 AM Oleksij Rempel wrote: >>>> SYSC_REG_CPLL_CLKCFG1 register is a clock gate controller. It is used to >>>> enable or disable clocks. >>>> Jist wild assumption. All peripheral devices are suing bus clock. >>> >>> This assumption is incorrect. When this patchset is applied in >>> OpenWrt, I asked the author why there's still a fixed clock in >>> mt7621.dtsi, He told me that there's another clock for those unchanged >>> peripherals and he doesn't have time to write a clock provider for it. >> >> Can you please provide a link to this patch or email. > > This discussion is in Chinese and using an IM software so there's no > link available. > >> We have at least 2 know registers: >> SYSC_REG_CPLL_CLKCFG0 - it provides some information about boostrapped >> refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). >> SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for >> all or some ip cores. >> What is probably missing is a set of dividers for >> each ip core. From your words it is not document. > > The specific missing part I was referring to, is parent clocks for > every gates. I'm not going to assume this with current openwrt device > tree because some peripherals doesn't have a clock binding at all or > have a dummy one there. Ok, then I do not understand what is the motivation to upstream something what is not nearly ready for use. This code is currently on prototyping phase and you have no information how to make it ready. It means, we cannot expect that this driver will be fixed any time soon. -- Regards, Oleksij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/6] dt: bindings: add mt7621-pll dt binding documentation
Am 17.08.19 um 18:22 schrieb Chuanhong Guo: > Hi! > > On Sat, Aug 17, 2019 at 11:40 PM Oleksij Rempel wrote: > >> In provided link [0] the ralink_clk_init function is reading >> SYSC_REG_CPLL_CLKCFG0 R/W register. >> This register is used to determine clock source, clock freq and CPU or bus >> clocks. > > This register should only be changed by bootloader, not kernel. So > it's read-only in kernel's perspective. there is no kernel perspective, until you have some kind of privilege separation. There is only: "i decided not to write on to writeable register". >> SYSC_REG_CPLL_CLKCFG1 register is a clock gate controller. It is used to >> enable or disable clocks. >> Jist wild assumption. All peripheral devices are suing bus clock. > > This assumption is incorrect. When this patchset is applied in > OpenWrt, I asked the author why there's still a fixed clock in > mt7621.dtsi, He told me that there's another clock for those unchanged > peripherals and he doesn't have time to write a clock provider for it. Can you please provide a link to this patch or email. > I don't know how many undocumented clocks are there since this piece > of info is missing in datasheet. > >> >> IMO - this information is enough to create full blown >> drivers/clk/mediatek/clk-mt7621.c > > And this information isn't enough because the assumption above is incorrect :P Ok, let's assume I accept this not technical argumentation. We have at least 2 know registers: SYSC_REG_CPLL_CLKCFG0 - it provides some information about boostrapped refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for all or some ip cores. What is probably missing is a set of dividers for each ip core. From your words it is not document. With this information the clk driver will provide gate functionality and a set of hardcoded clocks. With this driver will work part of power management and nice devicetree without fixed clocks. -- Regards, Oleksij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/6] dt: bindings: add mt7621-pll dt binding documentation
Hi,
Am 17.08.19 um 16:42 schrieb Chuanhong Guo:
Hi!
On Tue, Aug 13, 2019 at 11:51 PM Rob Herring wrote:
[...]
+Example:
+ pll {
+ compatible = "mediatek,mt7621-pll";
You didn't answer Stephen's question on v1.
I thought he was asking why there's a syscon in compatible string. I
noticed that the syscon in my previous patch is a copy-paste error
from elsewhere and dropped it.
Based on this binding, there is no way to control/program the PLL. Is
this part of some IP block?
The entire section is called "system control" in datasheet and is
occupied in arch/mips/ralink/mt7621.c [0]
Two clocks provided here is determined by reading some read-only
registers in this part.
There's another register in this section providing clock gates for
every peripherals, but MTK doesn't provide a clock plan in their
datasheet. I can't determine corresponding clock frequencies for every
peripherals, thus unable to write a working clock driver.
In provided link [0] the ralink_clk_init function is reading
SYSC_REG_CPLL_CLKCFG0 R/W register.
This register is used to determine clock source, clock freq and CPU or bus
clocks.
SYSC_REG_CPLL_CLKCFG1 register is a clock gate controller. It is used to enable
or disable clocks.
Jist wild assumption. All peripheral devices are suing bus clock.
IMO - this information is enough to create full blown
drivers/clk/mediatek/clk-mt7621.c
+
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "bus";
+ };
--
2.21.0
Regards,
Chuanhong Guo
[0]
https://elixir.bootlin.com/linux/latest/source/arch/mips/ralink/mt7621.c#L156
--
Regards,
Oleksij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/6] dt: bindings: add mt7621-pll dt binding documentation
Hi,
Am 17.08.19 um 16:42 schrieb Chuanhong Guo:
Hi!
On Tue, Aug 13, 2019 at 11:51 PM Rob Herring wrote:
[...]
+Example:
+ pll {
+ compatible = "mediatek,mt7621-pll";
You didn't answer Stephen's question on v1.
I thought he was asking why there's a syscon in compatible string. I
noticed that the syscon in my previous patch is a copy-paste error
from elsewhere and dropped it.
Based on this binding, there is no way to control/program the PLL. Is
this part of some IP block?
The entire section is called "system control" in datasheet and is
occupied in arch/mips/ralink/mt7621.c [0]
Two clocks provided here is determined by reading some read-only
registers in this part.
There's another register in this section providing clock gates for
every peripherals, but MTK doesn't provide a clock plan in their
datasheet. I can't determine corresponding clock frequencies for every
peripherals, thus unable to write a working clock driver.
In provided link [0] the ralink_clk_init function is reading
SYSC_REG_CPLL_CLKCFG0 R/W register.
This register is used to determine clock source, clock freq and CPU or bus
clocks.
SYSC_REG_CPLL_CLKCFG1 register is a clock gate controller. It is used to enable
or disable clocks.
Jist wild assumption. All peripheral devices are suing bus clock.
IMO - this information is enough to create full blown
drivers/clk/mediatek/clk-mt7621.c
+
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "bus";
+ };
--
2.21.0
Regards,
Chuanhong Guo
[0]
https://elixir.bootlin.com/linux/latest/source/arch/mips/ralink/mt7621.c#L156
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Two rtlwifi drivers?
Am 16.10.2017 um 15:07 schrieb Kalle Valo: > Oleksij Rempel writes: > >>> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I >>>plan to fix them after rtl8723de and rtl8821ce. Because the drivers >>>are developing, the changes will make us hard to integrate. However, >>>I don't have plan to process the magic numbers in the module phydm, >>>because the most of BB/RF registers contain many functions. And >>>it doesn't have a register name but a bit field name instead. >>>Our BB team guys say the use of enumeration or defined name will >>>be unreadable, and the name is meaningless for most people. >> >> Experience with ath9k driver showed, that development was kind of >> balanced between two groups, QCA and Community (Other companies, >> researches, education and so on.). Saying: "you will not understand it >> any way" is nor really helpful :) >> Please don't repeat bad experience of Broadcom. > > I agree with Oleksij here, but I want to still point out that there are > cases when using magic numbers are ok, for example look at > ar5008_initvals.h from ath9k. So it depends on case by case. Beside. It is probably offtopic. I assume this initvals related to BB. Is it possible to force a 802.11n controller to work in 802.11b mode? I can image, it should be possible by reconfiguring BB. Correct? -- Regards, Oleksij signature.asc Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Two rtlwifi drivers?
Hi Just my two cents, :) Am 16.10.2017 um 04:41 schrieb Pkshih: > > >> -Original Message- >> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >> Sent: Thursday, October 12, 2017 6:35 PM >> To: Kalle Valo >> Cc: Larry Finger; Dan Carpenter; Pkshih; 莊彥宣; Johannes Berg; Souptick >> Joarder; >> de...@driverdev.osuosl.org; linux-wirel...@vger.kernel.org; >> kernel-janit...@vger.kernel.org >> Subject: Re: Two rtlwifi drivers? >> >> On Thu, Oct 12, 2017 at 11:38:06AM +0300, Kalle Valo wrote: So what to do? Any ideas? What makes your life easier? You can just ignore the staging tree, as it should not affect your portion of the kernel at all, right? >>> >>> Yes, I automatically ignore anything staging related. But the problem is >>> that we now have two drivers with the same name and people don't always >>> remember to prefix the patch with "staging: ". So on a bad day I might >>> accidentally apply a patch which was meant for your tree. Of course I >>> immediately revert it as soon as I, or someone else, catches that but >>> annoying still. >> >> It doesn't bother me if you apply staging patches, I can handle the >> merge issues :) >> >>> I think we have two options here: >>> >>> 1) We set a deadline (like 12 months or something) for the >>>drivers/staging/rtlwifi and after that you refuse to take any patches >>>for it. Hopefully this makes it clear for everyone that this fork is >>>just temporary. I think Larry is trying to do this, which is great. >> >> Fine with me, if Larry is ok with it. >> >>> 2) We move the whole rtlwifi driver to staging. A very bad option but >>>still better than forking the drivers. >> >> Ick, I don't want that to have to happen, that would not be good for the >> users of other devices that the "real" rtlwifi driver supports. >> > > Hi Larry, Kalle and Gerg, > > This is Realtek engineer, PK. I appreciate your support to submit, review > and merge patch. Since I'm a Linux newbie, I'll describe the situation of > rtlwifi and need your suggestions. > > > 1) New modules in rtlwifi >We add two modules named phydm and halmac, when adding rtl8822be in >staging. The phydm is BB/RF related module containing the parameters >and APIs of BB/RF, and a dynamic mechanism to adapt to different >field environment. The halmac consists of MAC APIs. >The two modules are used by many OSs, so '#ifdef', CamelCase and >so on are existing in original files. Hence, we convert them to Linux >form by script, but it's not perfect. Do you have suggestion to deal >with this problem? > > > 2) The rtlwifi in staging >In staging, the module phydm v13 contains bugs, so I want to upgrade >to v21 (Realtek internal version number). This upgrade contains a >big patch that the difference between v13 and v21, and there are >40+ patches to support this upgrade. I have three options, and >I want to know which one is prefer. > > 2.1) apply 40+ patches to both staging and wireless tree, and apply > the big patch to staging only. After reviewing, we move the module > to wireless tree. > > 2.2) apply 40+ patches to wireless tree, and apply a single bigger > patch containing 40+ patches and the big patch to staging. I think > this can be seen as a new driver in staging. After reviewing, > we move the module to wireless tree. > > 2.3) don't apply anything to staging. Just apply 40+ patches and add > phydm v21 to wireless. > > > 3) Coming drivers -- rtl8723de and rtl8821ce >We're developing the two drivers, and rtl8723de and rtl8821ce will >be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on >rtl8822be that in staging now, so the line of code will be fewer. >The new files will be a new IC folder and IC supported files of >three modules that btcoexist, phydm and halmac. Could I submit >them to wirless tree when they're ready? > > > 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I >plan to fix them after rtl8723de and rtl8821ce. Because the drivers >are developing, the changes will make us hard to integrate. However, >I don't have plan to process the magic numbers in the module phydm, >because the most of BB/RF registers contain many functions. And >it doesn't have a register name but a bit field name instead. >Our BB team guys say the use of enumeration or defined name will >be unreadable, and the name is meaningless for most people. Experience with ath9k driver showed, that development was kind of balanced between two groups, QCA and Community (Other companies, researches, education and so on.). Saying: "you will not understand it any way" is nor really helpful :) Please don't repeat bad experience of Broadcom. > Many Linux users ask Larry about the new drivers, and Realtek will > provide drivers and try to submit them by myself. I hope the Linux > users can yield the drivers as soon as I c
Re: Ralink 6570 / Mediatek MT7601STA (was Re: Addition of a wifi kernel module to the linux source tree)
Am 04.12.2014 um 10:26 schrieb Parth Sane: > Hi, > Guys I'll be using my other account on my private domain laer.in now > onwards. Be sure to add me in your contacts. My new email is > parths...@laer.in > -Parth > > On 4 December 2014 at 14:19, Oleksij Rempel wrote: >> Am 04.12.2014 um 09:23 schrieb Stanislaw Gruszka: >>> On Thu, Dec 04, 2014 at 03:52:52PM +1100, Julian Calaby wrote: >>>> On Thu, Dec 4, 2014 at 3:39 PM, Greg Kroah-Hartman >>>> wrote: >>>>> On Thu, Dec 04, 2014 at 07:07:58AM +0530, Parth Sane wrote: >>>>>> Hi, >>>>>> I'd say I'm midway through with c programming(part of my computer >>>>>> engineering degree course) and know a decent amount of git. So yes I'm >>>>>> comfortable writing code. >>>>> >>>>> Ok great, let's see if it's just a matter of some changes to the >>>>> existing kernel driver before we decide to add the whole huge tarball >>>>> to the staging tree as fixing it up will be a lot of work. >>>> >>>> I believe some people (CC'd) may have been working on / had an >>>> interest in writing such a driver. I'm not sure what the status of >>>> that effort is though. >>> >>> Right. Felix is working on new linux friendly driver for new Mediatek >>> chips. >> >> So far i know, Felix is working on abgn+ac (MT7662 and MT7612) devices. >> MT7601STA is (a)bgn. Are there similar regs? >> >> In mt7601 code i see parts like "if (IS_RT3290(pAd) || IS_RT65XX(pAd) || >> IS_MT7601(pAd))". RT3290 is supported by rt2x00. Am 04.12.2014 um 10:54 schrieb parths...@laer.in:> Hi again, > Please note my new email parths...@laer.in . Also If you guys don't know > there's a working source supplied by mediatek for mt7601. Please find > the attached tarball. Also please apply this patch I mentioned about > earlier. It's at https://gist.github.com/Boggartfly/b18bd86b8eb60fabe160 > > rt_linux.h has the following path in the driver directory. > > /include/os/rt_linux.h > > After you replace the patched file everything works and compiles > successfully!! Any pointers on what should be done to make it kernel > compatible? Well, there is no kernel compatible part in this driver. With other words it should be completely rewritten or cleaned up. As match as possible of existing kernel code should be reused. PS. please keep the topic. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Ralink 6570 / Mediatek MT7601STA (was Re: Addition of a wifi kernel module to the linux source tree)
Am 04.12.2014 um 09:23 schrieb Stanislaw Gruszka: > On Thu, Dec 04, 2014 at 03:52:52PM +1100, Julian Calaby wrote: >> On Thu, Dec 4, 2014 at 3:39 PM, Greg Kroah-Hartman >> wrote: >>> On Thu, Dec 04, 2014 at 07:07:58AM +0530, Parth Sane wrote: Hi, I'd say I'm midway through with c programming(part of my computer engineering degree course) and know a decent amount of git. So yes I'm comfortable writing code. >>> >>> Ok great, let's see if it's just a matter of some changes to the >>> existing kernel driver before we decide to add the whole huge tarball >>> to the staging tree as fixing it up will be a lot of work. >> >> I believe some people (CC'd) may have been working on / had an >> interest in writing such a driver. I'm not sure what the status of >> that effort is though. > > Right. Felix is working on new linux friendly driver for new Mediatek > chips. So far i know, Felix is working on abgn+ac (MT7662 and MT7612) devices. MT7601STA is (a)bgn. Are there similar regs? In mt7601 code i see parts like "if (IS_RT3290(pAd) || IS_RT65XX(pAd) || IS_MT7601(pAd))". RT3290 is supported by rt2x00. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
work on Alcor Micro AU6601
Hello all, i have a ultrabook with Alcor Micro AU6601 pcie card reader. Suddenly there is no driver for it, so i would like to make one. If i see it correctly, Alcor Micro don't wont to be contacted by any one except OEMs. I started collecting all possible information https://wikidevi.com/wiki/Alcor_Micro_AU6601 and already did some RE with documenting registers which i was able to find: https://docs.google.com/document/d/1jnRACLJn14jBpKuYBa4i0OvmwZ9qD8xm1xnIo4H0gGk/pub All this makes fun, but i still ask my self if using legals ways will work too :) Can some body help me contact Alcor Micro? -- Regards, Oleksij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
