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:	Wed, 28 Jan 2009 22:18:42 -0500
From:	Jarod Wilson <jarod@...hat.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	linux1394-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org,
	Kristian Høgsberg <krh@...planet.net>
Subject: Re: [PATCH RFT 7/7] firewire: sbp2: add workarounds for 2nd and 3rd generation iPods

On Wednesday 28 January 2009 18:11:32 Stefan Richter wrote:
> Jarod Wilson wrote:
> > On Saturday 24 January 2009 13:46:44 Stefan Richter wrote:
> >>   - Do 2nd and 3rd gen. iPods actually have a model_id == 0, or do they
> >>     have in fact no model_id at all?
> >
> > So far as I can decipher (using Kristian's csr-dump utility), they really
> > do have model_id == 0.
>
> If model_id weren't there, the older ieee1394/sbp2 driver would log
> model_id 0 (and match against quirks list entries with ID 0), while
> firewire-sbp2 logs model_id 0xff000000 (which is an impossible value and
> thus indicates to those who want to write a new quirks list entry that
> there is actually no model_id...).  I will soon push the patch which
> makes sbp2 behave like firewire-sbp2 in this regard, to eliminate a
> potential source of conflicting user reports.

Okay, so yeah, they definitely both have model_id == 0.

firewire_sbp2: Workarounds for fw2.0: 0x48 (firmware_revision 0x0a2700, 
model_id 0x000000).

On a related note... The fix capacity workaround... I think I need to
observe this failure myself... My own 4th-gen ipod, when connected to a
Mac OS X system, reports the exact capacity I get if the fix capacity
workaround is disabled. Do they just know not to try to access that
last block, or is the need for this workaround a myth? :)

-- 
Jarod Wilson
jarod@...hat.com

--
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