lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 26 Jul 2007 21:45:24 +0400
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	Vitaly Bordug <vitb@...nel.crashing.org>
Cc:	Scott Wood <scottwood@...escale.com>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org
Subject: Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver
 for CF	interface

Hello.

Vitaly Bordug wrote:

>>>   I acn undertand your complaint in the context of an OF driver
>>>(which we don't have yet) but "mmio-ide" just means nothing to the
>>>current driver, and it doesn't convery enough info on the
>>>programming interface for the conceivable OF driver, it also does
>>>need to know at least "reg-stride" (and maybe "reg-size" in case
>>>only 16/32-bit accesses can be used).  Well, if such driver will be
>>>written, I/O mapping support will probably be dropped from it, so
>>>indeed, calling it mmio-ide.c would make sense.  But that can be
>>>added when this driver is done, and for now 

>>I don't think the details of what Linux code currently exists should 
>>drive the device tree binding.  That the current patches use 
>>platform_device glue code is an implementation detail (and one I'd 
>>rather see go away, in favor of a driver that supports both 
>>platform_device and of_device).

>>>I'd really prefer the board name to appear in the "compatible" prop
>>>(to which "mmio-ide" can be appended)...

>>Sure, that's always good...  it was the "instead" that I objected to.

> Hmmm. So what is finally suggested devicetree node for this beast - can somebody refine?

> I am a little bit confused about decided device_type

    My understanding is that "ata" has been already used, so there's no sense 
in introducing "ide". Anyway, Segher will just say that "device_type" shoudn't 
matter and even be present. ;-)

 > and compatible fields...

    In my understanding, as "mmio-ide" currectly makes no sense, it shouldn't 
even appear there.  And since "mpc8349emitx-cf" (or whatever would be most 
generic name for those boards with the same type of CF IDE mapping) should be 
imply the shift value, this property should also be optional, i.e. passing 
hard coded value with platform_device would do.

MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ