On Wed, May 14, 2014 at 11:02:49AM +0900, SASANO Takayoshi wrote:
> Hi,
>
> Simply magic values are rewrited with #define.
> If these values need to be disassembled, please take a while...
>
I think we need to understand what those values mean. When I mentioned
#defines, I meant something like:
Hi,
Simply magic values are rewrited with #define.
If these values need to be disassembled, please take a while...
SASANO Takayoshi
Index: uchcom.c
===
RCS file: /cvs/src/sys/dev/usb/uchcom.c,v
retrieving revision 1.19
diff -u
On 13 May 2014 21:09, Mike Larkin wrote:
> On Wed, May 14, 2014 at 10:01:28AM +0900, SASANO Takayoshi wrote:
>> Hi, Mike.
>>
>> >> + val = 0x501f;
>> >> + idx = 0xd90a;
>> >
>> > What are these magic numbers?
>>
>> These numbers come from Linux driver (ch341.c). I don't know what they mean.
>> M
On Wed, May 14, 2014 at 10:01:28AM +0900, SASANO Takayoshi wrote:
> Hi, Mike.
>
> >> + val = 0x501f;
> >> + idx = 0xd90a;
> >
> > What are these magic numbers?
>
> These numbers come from Linux driver (ch341.c). I don't know what they mean.
> Maybe these numbers represent default character len
Hi, Mike.
>> +val = 0x501f;
>> +idx = 0xd90a;
>
> What are these magic numbers?
These numbers come from Linux driver (ch341.c). I don't know what they mean.
Maybe these numbers represent default character length and baudrate divisor.
http://lxr.cpsc.ucalgary.ca/lxr/#linux+v2.6.31/driver
On Wed, May 14, 2014 at 05:39:38AM +0900, SASANO Takayoshi wrote:
> Hello,
>
> Recently I bought Arduino board which uses Nanjing QinHeng (WinChipHead)
> CH340T USB-UART bridge via eBay, and I found uchcom(4) did not work.
> At misc@, other user reported similar problem. [1]
>
> The uchcom(4) com
On Wed, May 14, 2014 at 05:39:38AM +0900, SASANO Takayoshi wrote:
> Hello,
>
> Recently I bought Arduino board which uses Nanjing QinHeng (WinChipHead)
> CH340T USB-UART bridge via eBay, and I found uchcom(4) did not work.
> At misc@, other user reported similar problem. [1]
>
> The uchcom(4) com
Hello,
Recently I bought Arduino board which uses Nanjing QinHeng (WinChipHead)
CH340T USB-UART bridge via eBay, and I found uchcom(4) did not work.
At misc@, other user reported similar problem. [1]
The uchcom(4) comes from NetBSD and it seems to be worked at that time.
I found that uchcom_set_
The last three hackathons I got sucked into one ugly dark corner of the
network stack. Our radix tree implementation one one particular bug in it
that caused bgpd and ospfd to freak out on semi regular basis.
After a fair amount of versions tested by myself and benno@ I think it is
time to send th
On 13 May 2014 16:05, Mike Belopuhov wrote:
> On 13 May 2014 15:45, Claudio Jeker wrote:
>> With KAME the MTU size of the loopback interface became strange and is
>> actually dependend on the architecture. I see no point in all this
>> just go back to the way it was long long long ago and just us
On 13 May 2014 15:45, Claudio Jeker wrote:
> With KAME the MTU size of the loopback interface became strange and is
> actually dependend on the architecture. I see no point in all this
> just go back to the way it was long long long ago and just use 32k as the
> MTU. AFAIK all of this was only don
With KAME the MTU size of the loopback interface became strange and is
actually dependend on the architecture. I see no point in all this
just go back to the way it was long long long ago and just use 32k as the
MTU. AFAIK all of this was only done to test large IPv6 packets but why
MHLEN and MLEN
On Mon, Apr 28, 2014 at 14:20 +0200, Mike Belopuhov wrote:
> This adds ktable code from bgpd to fetch, store and perform lookups
> in multiple routing tables. Currently it doesn't do anything useful
> but it's a prerequisite for any future work in this direction.
>
> OK to get this in?
>
Any ob
On Mon, May 12, 2014 at 12:48 +0200, Martin Pieuchot wrote:
> On 07/05/14(Wed) 12:46, Martin Pieuchot wrote:
> > Diff below stops abusing nd6_rtrequest() for loopback interfaces, which
> > means we can remove the special hack below and reduce the differences
> > with arp_rtrequest().
> >
> > This
14 matches
Mail list logo